From nobody Tue Jul 1 03:10:54 2014 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 04A631A0035 for ; Tue, 1 Jul 2014 03:10:52 -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 K4YaBFHcA3iw for ; Tue, 1 Jul 2014 03:10:50 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617011A0031 for ; Tue, 1 Jul 2014 03:10:50 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 20so5519778yks.38 for ; Tue, 01 Jul 2014 03:10:49 -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=UBMJW1p0IdjL1H4NzxgChkmCAj8oIhtgzAyM8RLCnkY=; b=ijskeXh7f5+wdjV6bKAUXP++S5nUZE9tuf4JRy5LPlkH4gSUxkBMZ3Ry19vbnPWAJ/ p03yHtO3P/yQsXTjtmdf+JPO5kqBVVfSPNu0eNd340tiR6CNyl1FsDMYTcEwa13GHCjP VPXnxIa2a9lj6be7gTDI+3Ah6nP/b2IDW8ylbOKPhuO34EOdUixbV9x8dKn51UbhSi5j bNyd/f97A5tyTmnoB4axtjTd44VgVMJzjqMeXws+HkTv/+X5W5UB4wYBaHiT5RS1urgs URKiFTe1v6BbcMSGs09W+dWbp8erm9xfEZtjRgdmnrBHQKZdnkctyg4cM6GNIWczfmoG dblA== MIME-Version: 1.0 X-Received: by 10.236.17.194 with SMTP id j42mr12357042yhj.138.1404209449570; Tue, 01 Jul 2014 03:10:49 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Tue, 1 Jul 2014 03:10:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jul 2014 11:10:49 +0100 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: multipart/alternative; boundary=001a11c1e2a86e980f04fd1efd82 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8qomoUsDspEKO-29r-6rWcGCsa8 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] WG document adoption of draft-dearlove-manet-ibs-00.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: Tue, 01 Jul 2014 10:10:52 -0000 --001a11c1e2a86e980f04fd1efd82 Content-Type: text/plain; charset=UTF-8 I reviewed the draft, my comment is that this update work will be defining a new possible function, so in applicability section no need to mention that it is an option (could that confuse that it can be optional function). The introduction mentions the specification work assumptions, which I prefer to mention it in the applicability statement. Overall, this draft adds important security features for RFC5444, so I adopt. AB On Monday, June 30, 2014, Joseph Macker wrote: > Chris/All: > > There has been a request to adopt draft-dearlove-manet-ibs-00.txt as a WG > document. > Please review and comment regarding opinions to adopt. > > The presentation request of this document is also approved for Toronto. > > URL: http://www.ietf.org/internet-drafts/draft-dearlove-manet-ibs-00.txt > > > We will be collecting WG comments on this document for the next 2 weeks > prior to making an adoption decision. > > -Joe > --001a11c1e2a86e980f04fd1efd82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I reviewed the draft, my comment is that this update work=C2=A0will be defi= ning=C2=A0a=C2=A0new possible=C2=A0function, so in applicability section no= need to mention that it is an=C2=A0option (could that confuse that it can = be optional function). The introduction mentions the specification work=C2= =A0assumptions,=C2=A0which I prefer to mention it in the applicability stat= ement. Overall, this draft adds important security=C2=A0features=C2=A0for R= FC5444, so=C2=A0I adopt.=C2=A0

AB

On Monday, June 30, 2014, Joseph Macker wrote:
Chris/All:

<= div> There has been a request to adopt=C2=A0draft-dearlove-manet-ibs-00.txt as a= WG document.
Please review and comment regarding opinions to ado= pt.=C2=A0

The presentation request of this documen= t is also approved for Toronto.

--001a11c1e2a86e980f04fd1efd82-- From nobody Tue Jul 1 06:45:36 2014 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 687C81A02F1 for ; Tue, 1 Jul 2014 06:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 KdlPt7SWimjR for ; Tue, 1 Jul 2014 06:45:28 -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 6BF051A03E7 for ; Tue, 1 Jul 2014 06:45:25 -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 1X1yN9-0006PU-NI; Tue, 01 Jul 2014 15:45:23 +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 1X1yN9-0002r4-Jm; Tue, 01 Jul 2014 15:45:23 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 1 Jul 2014 15:45:23 +0200 Message-ID: <53B2BB6A.8070701@fkie.fraunhofer.de> Date: Tue, 1 Jul 2014 15:45:14 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "manet@ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030302060208010000070204" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19148/Tue Jul 1 12:45:59 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QO0-dVA1MgHRAeIMQeVdCfRU7XI Cc: Christopher Dearlove Subject: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 01 Jul 2014 13:45:32 -0000 --------------ms030302060208010000070204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have been working for the last weeks to adapt my OLSRv2 implementation to draft-dearlove-manet-olsrv2-multitopology. In general the draft is straight-forward to implement, especially when the data structures can be tailored to the draft. The only part of the draft that feels a bit strange and complicated is the handling of the MPR_TYPES and ATTACHED_NETWORK tlvs in the TC. Making the MPR_TYPES tlv optional for TC messages mean that there is no TLV left to directly determine MT-capability of the originator of the TC.= Making the MPR_TYPES depend on the configuration of the locally attached networks "distance" also complicates things a bit. I am not sure we should change this part of the draft, but a few examples of TCs (with/without MPR_TYPES, with common/different distances in attached networks) would help. ---- I am also looking for a chance to do some interop tests for the MT codebase. The code is not that trivial so an interop test would be a good chance to find subtle bugs. 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 --------------ms030302060208010000070204 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 Fw0xNDA3MDExMzQ1MjJaMCMGCSqGSIb3DQEJBDEWBBRVT+Ck2//vf2MEJAeZbnfAWmxq0jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAvStj/e18rwVNzs08NidhS6fDaUZs4ux6W1pIvN1YrHCF M0qo+c/H+3Q7qXwFwHKZmvZO9fgNfok6Lm2tuwZPZjZO7Ogn4aPQxTDGg4jx25cdwoH9Nad9 aweteljH9d9pcfpmvG6Eo+jUFVvrxqPT+uY7SmxANS8x22yQVw1wDpAEwxODPOnPOBgcHfG2 jZVB3AKmztxK87v1T7Z37cFi72WhZij2VJyqaZa9cZJbJdn3KkBePVmHg4zWBZnJduOlo2B4 HHDH9jWh7D5MtJmU0YQACJAR/MIe2v9/WAB2k8k7AawIVFaRgIqlfaSbJAKi1fbDtX0vUfBx hehUSttcNgAAAAAAAA== --------------ms030302060208010000070204-- From nobody Tue Jul 1 09:25:52 2014 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 2C4331B2825 for ; Tue, 1 Jul 2014 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 JCXjuipTFPKF for ; Tue, 1 Jul 2014 09:25:33 -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 6AFAD1B284C for ; Tue, 1 Jul 2014 09:24:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,582,1400022000"; d="scan'208";a="453880858" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Jul 2014 17:24:58 +0100 X-IronPort-AV: E=Sophos;i="5.01,582,1400022000"; d="scan'208";a="56447143" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 01 Jul 2014 17:24:57 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.149]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 17:24:57 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation Thread-Index: AQHPlTLYUeBdGoNg60uGtz9/7v3pHpuLZOSg Date: Tue, 1 Jul 2014 16:24:57 +0000 Message-ID: References: <53B2BB6A.8070701@fkie.fraunhofer.de> In-Reply-To: <53B2BB6A.8070701@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wjTx1R3p-ELi_4YjhTdmJVxmSSI Cc: Christopher Dearlove Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 01 Jul 2014 16:25:38 -0000 Henning Great to hear you've been working on this. I had to dig out the specification to look at the TLV_TYPES issue. And I st= arted to type that you didn't need to know (though of course it was there a= s optional to allow you to know). But thinking about it - though not for lo= ng enough, I'm not so sure about that. Unfortunately I don't have any more = time today, but definitely let's kick around some cases to test that. I'm having a bit of difficulty with the rest of the message. By ATTACHED_NE= TWORK do you mean GATEWAY? And I don't understand the following paragraph. = But let's throw it all in the discussion. Christopher -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 01 July 2014 14:45 To: manet@ietf.org Cc: Christopher Dearlove Subject: [manet] draft-dearlove-manet-olsrv2-multitopology review and imple= mentation Hi, I have been working for the last weeks to adapt my OLSRv2 implementation to= draft-dearlove-manet-olsrv2-multitopology. In general the draft is straight-forward to implement, especially when the = data structures can be tailored to the draft. The only part of the draft that feels a bit strange and complicated is the = handling of the MPR_TYPES and ATTACHED_NETWORK tlvs in the TC. Making the MPR_TYPES tlv optional for TC messages mean that there is no TLV= left to directly determine MT-capability of the originator of the TC. Making the MPR_TYPES depend on the configuration of the locally attached ne= tworks "distance" also complicates things a bit. I am not sure we should change this part of the draft, but a few examples o= f TCs (with/without MPR_TYPES, with common/different distances in attached = networks) would help. ---- I am also looking for a chance to do some interop tests for the MT codebase= . The code is not that trivial so an interop test would be a good chance to= find subtle bugs. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation= , Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) F= raunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Tue Jul 1 09:46:02 2014 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 145081A0395 for ; Tue, 1 Jul 2014 09:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 xyUNgho0Jfwp for ; Tue, 1 Jul 2014 09:45:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9C81A035C for ; Tue, 1 Jul 2014 09:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=225; q=dns/txt; s=iport; t=1404233156; x=1405442756; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=HjxKfx5G5e+IjCIddJzHYquikVJAgVXXRNMDRPO869E=; b=KlTDMfXzAMyZPqKLCxihiaQep1CbFiLb4Nn7Da3bItMvOqh13cgN0YgW bomRNpAPQDeV4RxNMSWsOhU262Mol3tpwph3/NKUq3zryvhV93pSTWaTL /mCoVX2UYPZhFvf8Yw2/5SrsnL2F9M8hFjeyBmuimh5WpdQhvoJT3d3vZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8GAKbkslOtJV2U/2dsb2JhbABagw2BLKs2BQFummkWdYQKOjQdAT5CJwSIVZ1QqzsXhW+MZIEWBZpmlAODQoIw X-IronPort-AV: E=Sophos;i="5.01,582,1400025600"; d="scan'208";a="57501059" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 01 Jul 2014 16:45:56 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s61GjupI017031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Jul 2014 16:45:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 11:45:56 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: draft-ietf-manet-olsrv2-multitopology-02 Thread-Index: AQHPlUvtgnYCP2J2BUy5nE+mbSIHqA== Date: Tue, 1 Jul 2014 16:45:55 +0000 Message-ID: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AE55F324D02C64082B77BFB3D1A1F73@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aZRglqDgRaNedYNu5c8Uv8OjsZo Subject: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 01 Jul 2014 16:45:59 -0000 Working group participants,=20 It is time for a Working Group Last Call on the above mentioned draft. Plea= se review and submit any comments to the mailing list by close of business = on July 14.=20 Regards, Stan= From nobody Tue Jul 1 09:50:15 2014 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 748CB1A039F for ; Tue, 1 Jul 2014 09:50:12 -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 DMIDS34oND-q for ; Tue, 1 Jul 2014 09:50:10 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29361A0298 for ; Tue, 1 Jul 2014 09:50:09 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id w8so7736187qac.22 for ; Tue, 01 Jul 2014 09:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=diZ4kQ3lJIeD7TIwGToM1dy/J8cSE3kVndYr/Qc9ccw=; b=Nq6IEGSUOIvtsuw7POSZrqMbtp5z2BJ5Eu6NBH07vOsuw/32FDqBUComtRf76xYFYG Ds2T6GdNAiMLK+YFf8xw1LvU+44WEZZUjVxbH5MxXPUmOi12uBBB0e3kwYvAZhMBKSUX hZLRh9b1qbkfvN4k8p6SXdIYHz3OuOSOha1ZO3lZWwnYVPcRTRpjA3GAum7YmStrMvLL OLcVwr6WvDaqxbBhXoRpKP2Et+dZirntE2HvXKe92EbezKZ9mb8kUyXeApighSMrN/hR eqy9f9ed+2G7Q2ZMpNfsaQ45Usb0+fs6q3sMWMM3SpQYh2bf8piGuD1MoF1PQw1nKTg2 /u3Q== X-Received: by 10.140.101.86 with SMTP id t80mr44423847qge.108.1404233409115; Tue, 01 Jul 2014 09:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Tue, 1 Jul 2014 09:49:48 -0700 (PDT) In-Reply-To: References: <53B2BB6A.8070701@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 1 Jul 2014 18:49:48 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HOFlNaJUr64m7aes7bzrJBJ0e_Q Cc: "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 01 Jul 2014 16:50:12 -0000 On Tue, Jul 1, 2014 at 6:24 PM, Dearlove, Christopher (UK) wrote: > Henning > > Great to hear you've been working on this. Thank you. > I had to dig out the specification to look at the TLV_TYPES issue. And I = started to type that you didn't need to know (though of course it was there= as optional to allow you to know). But thinking about it - though not for = long enough, I'm not so sure about that. Unfortunately I don't have any mor= e time today, but definitely let's kick around some cases to test that. You only need to know the TLV_TYPES value if you only have link-metric TLVs and nothing with an array (e.g. GATEWAY tlv for TCs). But the code-path to parse this looks a little bit twisted. > I'm having a bit of difficulty with the rest of the message. By ATTACHED_= NETWORK do you mean GATEWAY? And I don't understand the following paragraph= . But let's throw it all in the discussion. Yes, I named the API in my code after the data-structures in the OLSRv2 RFC, thats why I accidentally said "attached network" and not "gateway"... GATEWAY is the correct TLV name for Attached Network Set data. The rules when you need/don't need a TLV_TYPES tlv in a TC message read like an exception with an exception. a) normally you don't need it b) unless you have Gateway TLVs c) unless all Gatways TLVs have the same "distance" for each metric (or have single-byte distance values) This feels a bit strange... so maybe we could add a couple of examples. 1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES tlv) 2) Multitopology TC with two GATEWAY tlvs and random "distances" (this means it needs a TLV_TYPES tlv) 3) Multitopology TC with two GATEWAY tlvs, each of them having a multi-byte "distance" values (but all the same, needs a TLV_TYPES tlv) 4) Multitopology TC with two GATEWAY tlvs, each of them having only a single-byte "distance" value (no TLVTYPES tlv) maybe even one with a mixture of 3) and 4) (to show you can mix both GATEWAY tlv variants. Henning Rogge From nobody Tue Jul 1 16:36:52 2014 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 E05911A0B03 for ; Tue, 1 Jul 2014 16:36:46 -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 J-v8ULbCWZAp for ; Tue, 1 Jul 2014 16:36:42 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBC91A0B00 for ; Tue, 1 Jul 2014 16:36:41 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id k14so10502580wgh.30 for ; Tue, 01 Jul 2014 16:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cxOljjeeSB0HlUudOQAIIn+VdJMoTEB+s5LE5rNS8hk=; b=FrBHN3zeW2kjooDCDuX9qvLLdvTSu7cbNiynwJB9ftAldlflcQ2AgIrwi3azr928LO AEViihcW38v2yiYrHUstnz24sxGeyXE8EG36SgBjfKq3ICD9c2JgFXLSzuIAzC/5swa6 QkVsWUsT6d1M6vDRyO4vS+sOn8Aw4QRCqdl1VzCt0S5XiIxof5h+jom6JcC/F+FRr4r7 OoiOlxV44Nwpp4YkkG16NeOfNu+zti0nrGiS25dRB9aBGpMdtHJRQ4ff8WeUyrzxC9HD fUKapC0pFY2Qz0yiNdVQIytvCOwvxasulFJ2NwXfnE2qNhdt+9fbreTHbGgrDhMrh7PE fddw== X-Received: by 10.181.8.198 with SMTP id dm6mr39078375wid.30.1404257800436; Tue, 01 Jul 2014 16:36:40 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id rw4sm51151214wjb.44.2014.07.01.16.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 16:36:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Wed, 2 Jul 2014 00:36:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B2BB6A.8070701@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ezOFjVff83sxAAMpez5DLUjQ6Vk Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 01 Jul 2014 23:36:47 -0000 Far too late at night for me to consider in detail, but I see what you = are saying. I need to check details (and some more basic ones). Of course one of the things that WGLC is for is to consider if changes = are needed. Possibly examples, possibly less permissive rules. As ever we are pulled in the three directions of simplicity, efficiency = and flexibility. Actually here the last of these isn't the issue. (It = drives the whole design though.) Which is preferable, rules that try to = make something mandatory only when needed, or rules that are simpler = (maybe even right down to simply making the TLV mandatory)? Let's have = the discussion and see if we want to keep it as it is, or change it. = Something that would influence that is is there a use case for wanting = to be able to tell from a TC message that the originator supports = MT-OLSRv2? (Right this second I actually am surprised we don't always = need to know, but it's past midnight and I know I'm not firing on all = cylinders.) On 1 Jul 2014, at 17:49, Henning Rogge wrote: > On Tue, Jul 1, 2014 at 6:24 PM, Dearlove, Christopher (UK) > wrote: >> Henning >>=20 >> Great to hear you've been working on this. >=20 > Thank you. >=20 >> I had to dig out the specification to look at the TLV_TYPES issue. = And I started to type that you didn't need to know (though of course it = was there as optional to allow you to know). But thinking about it - = though not for long enough, I'm not so sure about that. Unfortunately I = don't have any more time today, but definitely let's kick around some = cases to test that. >=20 > You only need to know the TLV_TYPES value if you only have link-metric > TLVs and nothing with an array (e.g. GATEWAY tlv for TCs). But the > code-path to parse this looks a little bit twisted. >=20 >> I'm having a bit of difficulty with the rest of the message. By = ATTACHED_NETWORK do you mean GATEWAY? And I don't understand the = following paragraph. But let's throw it all in the discussion. >=20 > Yes, I named the API in my code after the data-structures in the > OLSRv2 RFC, thats why I accidentally said "attached network" and not > "gateway"... GATEWAY is the correct TLV name for Attached Network Set > data. >=20 > The rules when you need/don't need a TLV_TYPES tlv in a TC message > read like an exception with an exception. >=20 > a) normally you don't need it > b) unless you have Gateway TLVs > c) unless all Gatways TLVs have the same "distance" for each metric > (or have single-byte distance values) >=20 > This feels a bit strange... so maybe we could add a couple of = examples. >=20 > 1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES = tlv) > 2) Multitopology TC with two GATEWAY tlvs and random "distances" (this > means it needs a TLV_TYPES tlv) > 3) Multitopology TC with two GATEWAY tlvs, each of them having a > multi-byte "distance" values (but all the same, needs a TLV_TYPES tlv) > 4) Multitopology TC with two GATEWAY tlvs, each of them having only a > single-byte "distance" value (no TLVTYPES tlv) >=20 > maybe even one with a mixture of 3) and 4) (to show you can mix both > GATEWAY tlv variants. >=20 > Henning Rogge From nobody Wed Jul 2 05:19:50 2014 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 AF4781A006F for ; Wed, 2 Jul 2014 05:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 eMzLI9WxfbZS for ; Wed, 2 Jul 2014 05:19:48 -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 690A51A004B for ; Wed, 2 Jul 2014 05:19:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,587,1400022000"; d="scan'208";a="383767786" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Jul 2014 13:19:45 +0100 X-IronPort-AV: E=Sophos;i="5.01,587,1400022000"; d="scan'208";a="63362740" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 02 Jul 2014 13:19:45 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.85]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 13:19:44 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation Thread-Index: AQHPlUyFtvZDq+Y9wUOFM93xHfhXJpuMsPiA Date: Wed, 2 Jul 2014 12:19:32 +0000 Message-ID: References: <53B2BB6A.8070701@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tR6TnjDZbnT8K1uwGFfsZzyb6Kc Cc: "manet@ietf.org" Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 02 Jul 2014 12:19:49 -0000 Rmlyc3QsIEkgaGF2ZW4ndCBkaXNjdXNzZWQgdGhpcyB3aXRoIG15IGNvLWF1dGhvciwgdGhpcyBp cyBqdXN0IG1lLg0KDQpJJ3ZlIGxvb2tlZCB0aHJvdWdoIHRoZSBkcmFmdCBhZ2FpbiwgYW5kIGZv dW5kIGEgZmV3IG5pdHMgSSB3b24ndCBsaXN0IGhlcmUuIEJ1dCBJIGFsc28gbG9va2VkIGF0IEhl bm5pbmcncyBwb2ludC4NCg0KSW4gc2hvcnQsIEkgdGhpbmsgd2Ugc2hvdWxkIG1ha2UgTVBSX1RZ UEVTIGNvbXB1bHNvcnkgaW4gTVQtT0xTUnYyIFRDIG1lc3NhZ2VzLg0KDQpUaGlzIG1ha2VzIHRo aW5ncyBzaW1wbGVyLCBIZW5uaW5nJ3MgcG9pbnQuIEFsc28gNy4xLjEgZGVzY3JpYmVzIHRoaXMg VExWIGZvciBIRUxMTyBtZXNzYWdlcyAoc2Vjb25kIHBhcmFncmFwaCkgYnV0IGRvZXNuJ3QgaGF2 ZSBhbiBlcXVpdmFsZW50IGZvciBUQyBtZXNzYWdlcy4gVGhhdCBuZWVkcyBhZGRpbmcgcmVnYXJk bGVzcywgdGhpcyB3b3VsZCBtYWtlIHdoYXQncyBhZGRlZCBzaW1wbGVyLiBPZiBjb3Vyc2UgdGhl cmUgYXJlIG90aGVyIHBsYWNlcyB0byBhZGRyZXNzLCBzdWNoIGFzIHRoZSBmaXJzdCBidWxsZXQg aW4gOS4xLg0KDQpCdXQgdGhhdCdzIG5vdCBteSBtYWluIG1vdGl2YXRpb24uIFJhdGhlciBJIHdh bnQgdG8gdXNlIHRoaXMgdG8gcHJvdGVjdCBhZ2FpbnN0IHNvbWV0aGluZyB0aGF0IGlzIG5vdCBz ZW5zaWJsZSwgYnV0IG5vdCBhY3R1YWxseSBiYW5uZWQsIGFuZCBJIGNvdWxkIGludmVudCBhIGRp ZmZlcmVudCBleHRlbnNpb24gdG8gdXNlICh0aG91Z2ggdGhlIG9ubHkgb25lIEkgaGF2ZSBzbyBm YXIgaXMgZm9yY2VkKS4NCg0KVGhpcyBpcyB0aGF0IGluIG5vbi1NVC1PTFNSdjIsIGEgcm91dGVy IHNlbmRzIFRDIG1lc3NhZ2VzIHdpdGggbWV0cmljcyBvZiB0eXBlIExJTktfTUVUUklDX1RZUEUu IEJ1dCBpdCBjYW4gcHV0IG90aGVyIG1ldHJpY3MgaW4uIFRoZXkgYXJlIGlnbm9yZWQsIGJ1dCBs ZWdhbC4gKFBvc3NpYmxlIGV4dGVuc2lvbiB0byB1c2UgdGhlbSwgYWR2ZXJ0aXNpbmcgaW4gYWR2 YW5jZSBvZiBhIGNoYW5nZSBvZiBtZXRyaWMgdHlwZSBmb3Igc29tZSByZWFzb24gSSBjYW4ndCB0 aGluayBvZi4pDQoNClNvIHdoYXQgaWYgYSBub24tTVQtT0xTUnYyIHJvdXRlciBkb2VzIHRoYXQg KHBvaW50bGVzcyBidXQgbGVnYWwpIHRoaW5nPyBBbiBNVC1PTFNSdjIgcm91dGVyIHdpbGwgdHJ5 IHVzaW5nIHRob3NlIG1ldHJpY3MgKG9mIHRoZXkgYXJlIG9mICBhIHR5cGUgaXQgdXNlcykuIEJ1 dCB0aGUgcm91dGVyIGJlaW5nIG5vbi1NVC1PTFNSdjIgd29uJ3Qgcm91dGUgdXNpbmcgdGhlbS4N Cg0KSWYgd2UgcmVxdWlyZSBNVC1PTFNSdjIgcm91dGVycyB0byBwdXQgYW4gTVBSX1RZUEVTIFRM ViBpbnRvIFRDIG1lc3NhZ2VzLCB3ZSBjYW4gbW9kaWZ5IDkuMiB0byB1c2Ugb25seSB0aG9zZSBt ZXRyaWMgdHlwZXMgYWR2ZXJ0aXNlZCBpbiBhbiBNUFJfVFlQRVMgVExWLCBvciBMSU5LX01FVFJJ Q19UWVBFIGlmIG5vbmUsIGF2b2lkaW5nIHRoaXMgKHRoZW9yZXRpY2FsLCBidXQgbGV0J3MgZG8g aXQgcmlnaHQpIHByb2JsZW0uDQoNCklmIHRoaXMgbWFrZXMgc2Vuc2UgKGFuZCBvYnZpb3VzbHkg SSdkIGxpa2UgVGhvbWFzIGFuZCBIZW5uaW5nJ3MgY29tbWVudHMsIHBsdXMgb2YgY291cnNlIGFu eW9uZSBlbHNlKSBJJ2QgY29uc2lkZXIgdGhpcyBhcyBwYXJ0IG9mIHRoZSBjb2xsZWN0ZWQgV0dM QyBjb21tZW50cywgYWZ0ZXIgd2hpY2ggd2UnbGwgcHJvZHVjZSBhIG5ldyBkcmFmdCBhcyB1c3Vh bC4gVW5sZXNzIGJvdGggcGVvcGxlIHdhbnQgaXQgZWFybGllciBhbmQgSSBmaW5kIHRpbWUgdG8g ZG8gaXQgZWFybGllciAod2hpY2ggSSBtYXkgd2VsbCBub3QpLg0KDQotLSANCkNocmlzdG9waGVy IERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFu Y2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2Fw YWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFu bmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRl bDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3Vz ZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwg SGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5 OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGVubmluZyBSb2dn ZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dIA0KU2VudDogMDEgSnVseSAyMDE0IDE3OjUwDQpU bzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBIZW5uaW5nIFJvZ2dlOyBtYW5ldEBp ZXRmLm9yZzsgQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClN1YmplY3Q6IFJlOiBbbWFuZXRdIGRyYWZ0 LWRlYXJsb3ZlLW1hbmV0LW9sc3J2Mi1tdWx0aXRvcG9sb2d5IHJldmlldyBhbmQgaW1wbGVtZW50 YXRpb24NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlz YXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJu ZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQg U3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9u IHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT24gVHVlLCBKdWwgMSwg MjAxNCBhdCA2OjI0IFBNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20+IHdyb3RlOg0KPiBIZW5uaW5nDQo+DQo+IEdyZWF0IHRvIGhlYXIg eW91J3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzLg0KDQpUaGFuayB5b3UuDQoNCj4gSSBoYWQgdG8g ZGlnIG91dCB0aGUgc3BlY2lmaWNhdGlvbiB0byBsb29rIGF0IHRoZSBUTFZfVFlQRVMgaXNzdWUu IEFuZCBJIHN0YXJ0ZWQgdG8gdHlwZSB0aGF0IHlvdSBkaWRuJ3QgbmVlZCB0byBrbm93ICh0aG91 Z2ggb2YgY291cnNlIGl0IHdhcyB0aGVyZSBhcyBvcHRpb25hbCB0byBhbGxvdyB5b3UgdG8ga25v dykuIEJ1dCB0aGlua2luZyBhYm91dCBpdCAtIHRob3VnaCBub3QgZm9yIGxvbmcgZW5vdWdoLCBJ J20gbm90IHNvIHN1cmUgYWJvdXQgdGhhdC4gVW5mb3J0dW5hdGVseSBJIGRvbid0IGhhdmUgYW55 IG1vcmUgdGltZSB0b2RheSwgYnV0IGRlZmluaXRlbHkgbGV0J3Mga2ljayBhcm91bmQgc29tZSBj YXNlcyB0byB0ZXN0IHRoYXQuDQoNCllvdSBvbmx5IG5lZWQgdG8ga25vdyB0aGUgVExWX1RZUEVT IHZhbHVlIGlmIHlvdSBvbmx5IGhhdmUgbGluay1tZXRyaWMgVExWcyBhbmQgbm90aGluZyB3aXRo IGFuIGFycmF5IChlLmcuIEdBVEVXQVkgdGx2IGZvciBUQ3MpLiBCdXQgdGhlIGNvZGUtcGF0aCB0 byBwYXJzZSB0aGlzIGxvb2tzIGEgbGl0dGxlIGJpdCB0d2lzdGVkLg0KDQo+IEknbSBoYXZpbmcg YSBiaXQgb2YgZGlmZmljdWx0eSB3aXRoIHRoZSByZXN0IG9mIHRoZSBtZXNzYWdlLiBCeSBBVFRB Q0hFRF9ORVRXT1JLIGRvIHlvdSBtZWFuIEdBVEVXQVk/IEFuZCBJIGRvbid0IHVuZGVyc3RhbmQg dGhlIGZvbGxvd2luZyBwYXJhZ3JhcGguIEJ1dCBsZXQncyB0aHJvdyBpdCBhbGwgaW4gdGhlIGRp c2N1c3Npb24uDQoNClllcywgSSBuYW1lZCB0aGUgQVBJIGluIG15IGNvZGUgYWZ0ZXIgdGhlIGRh dGEtc3RydWN0dXJlcyBpbiB0aGUNCk9MU1J2MiBSRkMsIHRoYXRzIHdoeSBJIGFjY2lkZW50YWxs eSBzYWlkICJhdHRhY2hlZCBuZXR3b3JrIiBhbmQgbm90ICJnYXRld2F5Ii4uLiBHQVRFV0FZIGlz IHRoZSBjb3JyZWN0IFRMViBuYW1lIGZvciBBdHRhY2hlZCBOZXR3b3JrIFNldCBkYXRhLg0KDQpU aGUgcnVsZXMgd2hlbiB5b3UgbmVlZC9kb24ndCBuZWVkIGEgVExWX1RZUEVTIHRsdiBpbiBhIFRD IG1lc3NhZ2UgcmVhZCBsaWtlIGFuIGV4Y2VwdGlvbiB3aXRoIGFuIGV4Y2VwdGlvbi4NCg0KYSkg bm9ybWFsbHkgeW91IGRvbid0IG5lZWQgaXQNCmIpIHVubGVzcyB5b3UgaGF2ZSBHYXRld2F5IFRM VnMNCmMpIHVubGVzcyBhbGwgR2F0d2F5cyBUTFZzIGhhdmUgdGhlIHNhbWUgImRpc3RhbmNlIiBm b3IgZWFjaCBtZXRyaWMgKG9yIGhhdmUgc2luZ2xlLWJ5dGUgZGlzdGFuY2UgdmFsdWVzKQ0KDQpU aGlzIGZlZWxzIGEgYml0IHN0cmFuZ2UuLi4gc28gbWF5YmUgd2UgY291bGQgYWRkIGEgY291cGxl IG9mIGV4YW1wbGVzLg0KDQoxKSBNdWx0aXRvcG9sb2d5IFRDIHdpdGhvdXQgYW55IEdBVEVXQVkg dGx2ICh0aGlzIG1lYW5zIG5vIFRMVl9UWVBFUyB0bHYpDQoyKSBNdWx0aXRvcG9sb2d5IFRDIHdp dGggdHdvIEdBVEVXQVkgdGx2cyBhbmQgcmFuZG9tICJkaXN0YW5jZXMiICh0aGlzIG1lYW5zIGl0 IG5lZWRzIGEgVExWX1RZUEVTIHRsdikNCjMpIE11bHRpdG9wb2xvZ3kgVEMgd2l0aCB0d28gR0FU RVdBWSB0bHZzLCBlYWNoIG9mIHRoZW0gaGF2aW5nIGEgbXVsdGktYnl0ZSAiZGlzdGFuY2UiIHZh bHVlcyAoYnV0IGFsbCB0aGUgc2FtZSwgbmVlZHMgYSBUTFZfVFlQRVMgdGx2KQ0KNCkgTXVsdGl0 b3BvbG9neSBUQyB3aXRoIHR3byBHQVRFV0FZIHRsdnMsIGVhY2ggb2YgdGhlbSBoYXZpbmcgb25s eSBhIHNpbmdsZS1ieXRlICJkaXN0YW5jZSIgdmFsdWUgKG5vIFRMVlRZUEVTIHRsdikNCg0KbWF5 YmUgZXZlbiBvbmUgd2l0aCBhIG1peHR1cmUgb2YgMykgYW5kIDQpICh0byBzaG93IHlvdSBjYW4g bWl4IGJvdGggR0FURVdBWSB0bHYgdmFyaWFudHMuDQoNCkhlbm5pbmcgUm9nZ2UNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRo ZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIg c3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Wed Jul 2 07:35:31 2014 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 9B3171A01C3 for ; Wed, 2 Jul 2014 07:35:27 -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 ezqdKIYwhtSV for ; Wed, 2 Jul 2014 07:35:23 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9321A004B for ; Wed, 2 Jul 2014 07:35:23 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id vb8so12219499obc.39 for ; Wed, 02 Jul 2014 07:35:23 -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=b4U+HLXXouy8+sKejtXhwwNKb7POI/7JnUh6v5TUCfI=; b=0F2wKL2KJ3gpcs+XB+rRHOokiBm8GCC5UcgXj5yUe8+j8SaJozVUjWRToDfYzhY0Y4 X+JaOw9SfC+rMIiL/T9gTgofcfcLzspWvCKyOhp2OtVV5F2Y8NQsUDQGpGTqAXQtPNYL DtxP27rseAKA0cBXs02gP3Y976OhTCznlBdAafhBM2wh9RtWq90sRJqwvVEdED89vIgt IGA9HzT3+R7bKY1dcIvyBfw44ovzI+j8OUuUoLUN2O4vsVA5E89QEtekrWWLLtIPh8R5 1D5Qcc8OxRCoGdNXtYf910idGx0ua0Ylsh2WI0199u5QNsTmWhDIF49btKRZ45EEawr0 /dvw== MIME-Version: 1.0 X-Received: by 10.182.246.98 with SMTP id xv2mr11202838obc.80.1404311723117; Wed, 02 Jul 2014 07:35:23 -0700 (PDT) Received: by 10.76.89.111 with HTTP; Wed, 2 Jul 2014 07:35:23 -0700 (PDT) In-Reply-To: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> Date: Wed, 2 Jul 2014 15:35:23 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=001a11c2d71069103004fd36cd29 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NK0Flrmsj2cOb6H2dgxrw7W2z1o Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 14:35:27 -0000 --001a11c2d71069103004fd36cd29 Content-Type: text/plain; charset=UTF-8 Hi Stan, I am not ready for last call and IMHO the WG did not discuss it enough, no one reviewed. I think it needs minimum three months for last call. However, I will try to review, and I think I made many issue-questions before to the author but still did not get answers (I will repeat them when I review anyway). Thanks. AB On Tuesday, July 1, 2014, Stan Ratliff (sratliff) wrote: > Working group participants, > > It is time for a Working Group Last Call on the above mentioned draft. > Please review and submit any comments to the mailing list by close of > business on July 14. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c2d71069103004fd36cd29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stan,

I am not ready for last call=C2=A0and IMHO = the WG did not discuss it enough, no one reviewed. I think it needs minimum= three months for last call. However, I will try to review, and I think I m= ade many issue-questions=C2=A0before to the=C2=A0author but still did not g= et answers (I will repeat them when I review anyway). Thanks.=C2=A0

AB
 --001a11c2d71069103004fd36cd29-- From nobody Wed Jul 2 07:39:33 2014 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 A35FE1A01AE for ; Wed, 2 Jul 2014 07:39:30 -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 nn9lGRMx9jLu for ; Wed, 2 Jul 2014 07:39:26 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A351A02D6 for ; Wed, 2 Jul 2014 07:39:25 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id y10so11300675wgg.17 for ; Wed, 02 Jul 2014 07:39:24 -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=VvqAJLanLtTIkQB7PD5gNHt/IiZ+oHtOQYTEBr+UKRc=; b=bMX6zxZ1HgrSCWPw6ZrDIogFu6Old8jvWIWA8QhpJ3nyQcVly5KYOTXmgmLk5LBQye tFTEC1VE/lL+cPf3hpXqIgu242PS5jWUaJhnco4pdWDlFXod0oDso+JIRt/VSIQr/E3v eOEcG8a2/ZAqznNI45X4YlaKrIbsTtXLFT1PtUcVw+WBvvA6XT2gBf80nZ/R8g0BltZV hLvTOcEAhujZlKTGUz8sZbkWtKnOoPfF5OYNoIvGKHGNxz7IPV4lJgpkPp7SsGwbf2MH ibnRVYkSXweK3lyRxuapMNXCm6wZk+TVbXXguO5VJqNlo8U+97kfpxlcpKi5qDEdy991 k/ew== X-Received: by 10.194.122.38 with SMTP id lp6mr3486062wjb.117.1404311961947; Wed, 02 Jul 2014 07:39:21 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id by3sm36196291wjc.10.2014.07.02.07.39.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 07:39:21 -0700 (PDT) Message-ID: <53B41998.7000800@gmail.com> Date: Wed, 02 Jul 2014 15:39:20 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joseph Macker , "Dearlove, Christopher (UK)" , "manet@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020004020302010902020501" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/flAbBwgC5Xw_QBwTr_XmjjHkt4I Subject: Re: [manet] WG document adoption of draft-dearlove-manet-ibs-00.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, 02 Jul 2014 14:39:30 -0000 This is a multi-part message in MIME format. --------------020004020302010902020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This draft is going on my pre-conference reading list. I believe it is solving a problem that is of concern to manet and therefore I am in favour of adoption. Well done Chris. John On 30/06/14 20:11, Joseph Macker wrote: > Chris/All: > > There has been a request to adopt draft-dearlove-manet-ibs-00.txt as a > WG document. > Please review and comment regarding opinions to adopt. > > The presentation request of this document is also approved for Toronto. > URL:http://www.ietf.org/internet-drafts/draft-dearlove-manet-ibs-00.txt > > We will be collecting WG comments on this document for the next 2 > weeks prior to making an adoption decision. > > -Joe > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------020004020302010902020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This draft is going on my pre-conference reading list. I believe it is solving a problem that is of concern to manet and therefore I am in favour of adoption. Well done Chris.

John

On 30/06/14 20:11, Joseph Macker wrote:
Chris/All:

There has been a request to adopt draft-dearlove-manet-ibs-00.txt as a WG document.
Please review and comment regarding opinions to adopt. 

The presentation request of this document is also approved for Toronto.

We will be collecting WG comments on this document for the next 2 weeks prior to making an adoption decision.

-Joe


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

--------------020004020302010902020501-- From nobody Wed Jul 2 07:58:53 2014 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 093401A0344 for ; Wed, 2 Jul 2014 07:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 L2Swx1cMS5Gr for ; Wed, 2 Jul 2014 07:58:49 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5B01A033E for ; Wed, 2 Jul 2014 07:58:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,588,1400022000"; d="scan'208,217";a="454217521" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Jul 2014 15:58:47 +0100 X-IronPort-AV: E=Sophos; i="5.01,588,1400022000"; d="scan'208,217"; a="56578267" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 02 Jul 2014 15:58:47 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.85]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 15:58:47 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "Stan Ratliff (sratliff)" Thread-Topic: [manet] draft-ietf-manet-olsrv2-multitopology-02 Thread-Index: AQHPlUvtgnYCP2J2BUy5nE+mbSIHqJuMyluAgAASOhA= Date: Wed, 2 Jul 2014 14:58:24 +0000 Message-ID: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40330894GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-3Wq59TTrr_fjGcURo4ssQ_WQTM Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 14:58:52 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40330894GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlIHBlcmlvZCBmb3IgV0dMQyBpcyBub3QgYWN0dWFsbHkgbGFpZCBkb3duIGluIEJDUCAyNSwg V0dMQ3MgYXJlIG1hbmFnZWQgYnkgV0cgY2hhaXJzIGluIGNvbnN1bHRhdGlvbiB3aXRoIEFEcy4g QnV0IHRoZSBwZXJpb2QgdGhlIGNoYWlycyBoYXZlIHNldCB0aGlzIHRpbWUgaXMgZmFpcmx5IHR5 cGljYWwuIFRocmVlIG1vbnRocyBpcyBlbnRpcmVseSBpbmFwcHJvcHJpYXRlLg0KDQpBcyBmb3Ig bm8gb25lIHJldmlld2VkLCB0aGF04oCZcyB3aGF0IHRoaXMgcGVyaW9kIGlzIGZvci4gQW5kIHdo aWxlIG5vIG9uZSBoYXMgd3JpdHRlbiB1cCBhIGZvcm1hbCByZXZpZXcsIHBlb3BsZSBoYXZlIHJl YWQgdGhlIGVhcmxpZXIgZHJhZnRzICh0aGUgbGF0ZXN0IGRyYWZ0IGRvZXMgbm90IGluY2x1ZGUg YW55IG1ham9yIGNoYW5nZXMpIGFuZCBpdCB3YXMgcHJlc2VudGVkIGFzIGZhciBiYWNrIGFzIEJl cmxpbi4NCg0KSSBkbyBub3QgcmVjYWxsIGFueSBwcmV2aW91c2x5IGFza2VkIGFuZCB1bmFuc3dl cmVkIHF1ZXN0aW9ucyBmcm9tIHlvdS4NCg0KV2hhdCBJIHdvdWxkIHNheSBpcyB0aGF0IHRoZSBj b25jZXB0IG9mIGEgbXVsdGl0b3BvbG9neSBsaW5rIHN0YXRlIHJvdXRpbmcgcHJvdG9jb2wgaXMg bm90IGJyZWFraW5nIG5ldyBncm91bmQg4oCTIHNlZSBSRkMgNDkxNSBmb3IgT1NQRnYyIGZvciBl eGFtcGxlLiBUaGUgaXNzdWVzIGhlcmUgYXJlIGZpcnN0IGludGVyb3BlcmFiaWxpdHkgd2l0aCBu b24tTVQtT0xTUnYyLCB3aGljaCB0aGUgYXV0aG9ycyB0aGluayBpcyBpbXBvcnRhbnQgYW5kIGhh dmVu4oCZdCBoYWQgYW55IHB1c2ggYmFjayBvbiwgYW5kIHRoZSBkZXZpbCBpbiB0aGUgZGV0YWls cyBhcyBldmVyLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwg RW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5l dHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNl ZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93 LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiAr NDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoN CkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fy d2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJu Ym9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQWJkdXNzYWxhbSBCYXJ5dW4NClNlbnQ6IDAyIEp1bHkgMjAxNCAx NTozNQ0KVG86IFN0YW4gUmF0bGlmZiAoc3JhdGxpZmYpDQpDYzogbWFuZXQgSUVURg0KU3ViamVj dDogUmU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGl0b3BvbG9neS0wMg0K DQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl IGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFp bHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu cGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93 IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv dXMlMjBFbWFpbHMucGRmPi4NCg0KSGkgU3RhbiwNCg0KSSBhbSBub3QgcmVhZHkgZm9yIGxhc3Qg Y2FsbCBhbmQgSU1ITyB0aGUgV0cgZGlkIG5vdCBkaXNjdXNzIGl0IGVub3VnaCwgbm8gb25lIHJl dmlld2VkLiBJIHRoaW5rIGl0IG5lZWRzIG1pbmltdW0gdGhyZWUgbW9udGhzIGZvciBsYXN0IGNh bGwuIEhvd2V2ZXIsIEkgd2lsbCB0cnkgdG8gcmV2aWV3LCBhbmQgSSB0aGluayBJIG1hZGUgbWFu eSBpc3N1ZS1xdWVzdGlvbnMgYmVmb3JlIHRvIHRoZSBhdXRob3IgYnV0IHN0aWxsIGRpZCBub3Qg Z2V0IGFuc3dlcnMgKEkgd2lsbCByZXBlYXQgdGhlbSB3aGVuIEkgcmV2aWV3IGFueXdheSkuIFRo YW5rcy4NCg0KQUINCg0KT24gVHVlc2RheSwgSnVseSAxLCAyMDE0LCBTdGFuIFJhdGxpZmYgKHNy YXRsaWZmKSB3cm90ZToNCldvcmtpbmcgZ3JvdXAgcGFydGljaXBhbnRzLA0KDQpJdCBpcyB0aW1l IGZvciBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIHRoZSBhYm92ZSBtZW50aW9uZWQgZHJh ZnQuIFBsZWFzZSByZXZpZXcgYW5kIHN1Ym1pdCBhbnkgY29tbWVudHMgdG8gdGhlIG1haWxpbmcg bGlzdCBieSBjbG9zZSBvZiBidXNpbmVzcyBvbiBKdWx5IDE0Lg0KDQpSZWdhcmRzLA0KU3Rhbg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1h aWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8amF2YXNjcmlwdDo7Pg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVu dCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0 aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBv c2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40330894GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBwZXJpb2QgZm9yIFdHTEMgaXMgbm90IGFjdHVhbGx5 IGxhaWQgZG93biBpbiBCQ1AgMjUsIFdHTENzIGFyZSBtYW5hZ2VkIGJ5IFdHIGNoYWlycyBpbiBj b25zdWx0YXRpb24gd2l0aCBBRHMuIEJ1dCB0aGUgcGVyaW9kIHRoZSBjaGFpcnMgaGF2ZSBzZXQg dGhpcyB0aW1lDQogaXMgZmFpcmx5IHR5cGljYWwuIFRocmVlIG1vbnRocyBpcyBlbnRpcmVseSBp bmFwcHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgZm9yIG5vIG9uZSByZXZpZXdlZCwgdGhhdOKAmXMg d2hhdCB0aGlzIHBlcmlvZCBpcyBmb3IuIEFuZCB3aGlsZSBubyBvbmUgaGFzIHdyaXR0ZW4gdXAg YSBmb3JtYWwgcmV2aWV3LCBwZW9wbGUgaGF2ZSByZWFkIHRoZSBlYXJsaWVyIGRyYWZ0cyAodGhl IGxhdGVzdCBkcmFmdA0KIGRvZXMgbm90IGluY2x1ZGUgYW55IG1ham9yIGNoYW5nZXMpIGFuZCBp dCB3YXMgcHJlc2VudGVkIGFzIGZhciBiYWNrIGFzIEJlcmxpbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG8gbm90 IHJlY2FsbCBhbnkgcHJldmlvdXNseSBhc2tlZCBhbmQgdW5hbnN3ZXJlZCBxdWVzdGlvbnMgZnJv bSB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5XaGF0IEkgd291bGQgc2F5IGlzIHRoYXQgdGhlIGNvbmNlcHQgb2Yg YSBtdWx0aXRvcG9sb2d5IGxpbmsgc3RhdGUgcm91dGluZyBwcm90b2NvbCBpcyBub3QgYnJlYWtp bmcgbmV3IGdyb3VuZCDigJMgc2VlIFJGQyA0OTE1IGZvciBPU1BGdjIgZm9yIGV4YW1wbGUuIFRo ZSBpc3N1ZXMNCiBoZXJlIGFyZSBmaXJzdCBpbnRlcm9wZXJhYmlsaXR5IHdpdGggbm9uLU1ULU9M U1J2Miwgd2hpY2ggdGhlIGF1dGhvcnMgdGhpbmsgaXMgaW1wb3J0YW50IGFuZCBoYXZlbuKAmXQg aGFkIGFueSBwdXNoIGJhY2sgb24sIGFuZCB0aGUgZGV2aWwgaW4gdGhlIGRldGFpbHMgYXMgZXZl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0b3BoZXIg RGVhcmxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNl IEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBD YXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+ DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4 SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYj NDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPg0KIHwgaHR0cDovL3d3dy5i YWVzeXN0ZW1zLmNvbTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QkFFIFN5c3RlbXMg KE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3Vz ZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwg SGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxl cyBObzogMTk5NjY4NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KPGI+U2Vu dDo8L2I+IDAyIEp1bHkgMjAxNCAxNTozNTxicj4NCjxiPlRvOjwvYj4gU3RhbiBSYXRsaWZmIChz cmF0bGlmZik8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0IElFVEY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGl0b3BvbG9neS0wMjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQg Mi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91 bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Kioq IFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZy b20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0 bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9u Zz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3Ug Y2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0i aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv dGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2Vt PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxv dw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz JTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSGkgU3Rh biw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90 IHJlYWR5IGZvciBsYXN0IGNhbGwmbmJzcDthbmQgSU1ITyB0aGUgV0cgZGlkIG5vdCBkaXNjdXNz IGl0IGVub3VnaCwgbm8gb25lIHJldmlld2VkLiBJIHRoaW5rIGl0IG5lZWRzIG1pbmltdW0gdGhy ZWUgbW9udGhzIGZvciBsYXN0IGNhbGwuIEhvd2V2ZXIsIEkgd2lsbCB0cnkgdG8gcmV2aWV3LCBh bmQgSSB0aGluayBJIG1hZGUgbWFueSBpc3N1ZS1xdWVzdGlvbnMmbmJzcDtiZWZvcmUgdG8gdGhl Jm5ic3A7YXV0aG9yIGJ1dA0KIHN0aWxsIGRpZCBub3QgZ2V0IGFuc3dlcnMgKEkgd2lsbCByZXBl YXQgdGhlbSB3aGVuIEkgcmV2aWV3IGFueXdheSkuIFRoYW5rcy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QUI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxicj4NCk9uIFR1 ZXNkYXksIEp1bHkgMSwgMjAxNCwgU3RhbiBSYXRsaWZmIChzcmF0bGlmZikgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3JraW5nIGdyb3VwIHBhcnRpY2lwYW50 cyw8YnI+DQo8YnI+DQpJdCBpcyB0aW1lIGZvciBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9u IHRoZSBhYm92ZSBtZW50aW9uZWQgZHJhZnQuIFBsZWFzZSByZXZpZXcgYW5kIHN1Ym1pdCBhbnkg Y29tbWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCBieSBjbG9zZSBvZiBidXNpbmVzcyBvbiBKdWx5 IDE0Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU3Rhbjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0iamF2YXNjcmlwdDo7Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4KVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJy PgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0K PC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40330894GLKXM0002VGREEN_-- From nobody Wed Jul 2 08:17:05 2014 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 DDBCB1B2925 for ; Wed, 2 Jul 2014 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 Azh2-Qtarcta for ; Wed, 2 Jul 2014 08:16:56 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332EE1B2916 for ; Wed, 2 Jul 2014 08:16:52 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so9837597wiw.4 for ; Wed, 02 Jul 2014 08:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HJXaVwleDbg3f7OTKD2JqkPdaZAAsIXx8bce/ScM3/Q=; b=Vn4Qjm2fG1oT8TZ+uUhS+1RQ/lRBC5WYrJoknIbUMUzrosZ4DA6092bvs96eVf20bq Nn5IWzk+kRDW5DF58tgDTLy5FANqQGJMn7g3Gsk5aJPrVSBM6Ml+bWVyrICA0IJlHYhE ULUHtPL2PeuMiffs+rUUPSiYelEWGiK+1QX1VwaQ+qiFHqJbgwvl1HOtCS3Wq0p6iZMO Vc1Q8QXp0Qyx4QvQ7Ei0MV/WO7wjrL6Ew4R6M1PTJdzBdBabh8uZJ2Fxa/244Ymg07Cu o+8uuRbpttUXTlJqP0ou8kDeSTd0e6PfesyyzMzV4XuIkm9YbSE/Ar+bzYJoUJ2utJMY kAZQ== MIME-Version: 1.0 X-Received: by 10.180.207.48 with SMTP id lt16mr4060349wic.32.1404314210421; Wed, 02 Jul 2014 08:16:50 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.118.134 with HTTP; Wed, 2 Jul 2014 08:16:50 -0700 (PDT) In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> Date: Wed, 2 Jul 2014 17:16:50 +0200 X-Google-Sender-Auth: bsoHNFMZ8ACYWs3gS0rIIUIRsG4 Message-ID: From: Jiazi YI To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001a11c3f6eaaa53be04fd376133 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rdf96l6yfT08eMnnVIh1sYS9PKM Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 15:16:59 -0000 --001a11c3f6eaaa53be04fd376133 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 2, 2014 at 4:35 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > > Hi Stan, > > I am not ready for last call and IMHO the WG did not discuss it enough, no > one reviewed. > If the draft is discussed enough is very subjective, so I won't comment. But "no one reviewed" is absolutely not true. There have been discussions on the draft. Personally, I gave comments before also (any will give another review). Jiazi > > AB > > On Tuesday, July 1, 2014, Stan Ratliff (sratliff) wrote: > >> Working group participants, >> >> It is time for a Working Group Last Call on the above mentioned draft. >> Please review and submit any comments to the mailing list by close of >> business on July 14. >> >> Regards, >> Stan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c3f6eaaa53be04fd376133 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 2, 2014 at 4:35 PM, Abdussalam Baryun <abdussalambary= un@gmail.com> wrote:

Hi Stan,

I am not rea= dy for last call=C2=A0and IMHO the WG did not discuss it enough, no one rev= iewed.

If the draft is discussed enough is very s= ubjective, so I won't comment.=C2=A0
But "no one reviewe= d" is absolutely not true. There have been discussions on the draft. P= ersonally, I gave comments before also (any will give another review).=C2= =A0

Jiazi
=C2=A0

AB
=C2=A0
On Tuesday, July 1, 2014, Stan Ratliff (sratliff) w= rote:
Working group participants,

It is time for a Working Group Last Call on the above mentioned draft. Plea= se review and submit any comments to the mailing list by close of business = on July 14.

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

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


--001a11c3f6eaaa53be04fd376133-- From nobody Wed Jul 2 08:28:03 2014 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 F09591B290D for ; Wed, 2 Jul 2014 08:28:00 -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 c7f9PJ7HFA3V for ; Wed, 2 Jul 2014 08:27:59 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940091B290A for ; Wed, 2 Jul 2014 08:27:59 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id id10so10547506vcb.38 for ; Wed, 02 Jul 2014 08:27:58 -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=eGXVEBho0D/F8D1U8uiobw33bpsePFVaQZHelDopnqQ=; b=ExyuqYXxh6kPtVbW+v1yK1dq/meLWR0PmB8jA9p2/Hm4KFdKWne6UuRMFO42t14Rhd SFc5cL0bUD38sFOlWUtidI+KjUmFwDv0Cahvu74tvfvNUt++NNodJ6Qki2dEiM1o0aEP VFOWyDNSXHpualuxoQhihK0UcLsPxnzK4E5us= 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=eGXVEBho0D/F8D1U8uiobw33bpsePFVaQZHelDopnqQ=; b=Q14JzW6olAOToaziKKx82ch/7lpKBg1aBz8P2XvTJyk44dPVd0w1V/uAj1XhbJ9zVs thtLdeoQx7CoGRK+6wUsyBPzNDyByqNhzFKV31cqDcVi1wJ5MXiQmWbOJCri/zkbPq3/ uGQrLRdgQEs2lJYIh99hdRLQHH/L9aNElCZLlTCyOGcbVbIEQZrAo8aJTmEZh+5Bb1pY FC/4b9n6nn/Zq9OCH6gw5tQX2CUp3N65nd3xcsqSHHHGNvbZang78EuvwkuKtxbBJ1ia uYCJIz7t6TPmK+ZQJifq11QiyZo7YJCwUrGG/BLYUizkWiet3i49ZjSQCzfIZAiVJnCw uxtA== X-Gm-Message-State: ALoCoQnm9T0GyeFMO5u6RIqW1TTKLCd0Q80W6gtXTs4/6IqvsXI1jAHq2c7Yjy438DEzBRUFnLRa MIME-Version: 1.0 X-Received: by 10.58.69.198 with SMTP id g6mr817370veu.56.1404314878652; Wed, 02 Jul 2014 08:27:58 -0700 (PDT) Received: by 10.220.124.5 with HTTP; Wed, 2 Jul 2014 08:27:58 -0700 (PDT) In-Reply-To: <53B41998.7000800@gmail.com> References: <53B41998.7000800@gmail.com> Date: Wed, 2 Jul 2014 08:27:58 -0700 Message-ID: From: Ulrich Herberg To: John Dowdell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/T5Zcy8RQxD7Jza0cz4uec_M91yk Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] WG document adoption of draft-dearlove-manet-ibs-00.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, 02 Jul 2014 15:28:01 -0000 I also support adoption of this draft. Best regards Ulrich On Wed, Jul 2, 2014 at 7:39 AM, John Dowdell wrote: > This draft is going on my pre-conference reading list. I believe it is > solving a problem that is of concern to manet and therefore I am in favour > of adoption. Well done Chris. > > John > > > On 30/06/14 20:11, Joseph Macker wrote: > > Chris/All: > > There has been a request to adopt draft-dearlove-manet-ibs-00.txt as a WG > document. > Please review and comment regarding opinions to adopt. > > The presentation request of this document is also approved for Toronto. > > URL: http://www.ietf.org/internet-drafts/draft-dearlove-manet-ibs-00.txt > > > We will be collecting WG comments on this document for the next 2 weeks > prior to making an adoption decision. > > -Joe > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Jul 2 08:42:34 2014 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 C93111A0365 for ; Wed, 2 Jul 2014 08:42:31 -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 wiTFodsTgks3 for ; Wed, 2 Jul 2014 08:42:30 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC881A031B for ; Wed, 2 Jul 2014 08:42:30 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so9833963qcy.4 for ; Wed, 02 Jul 2014 08:42: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:from:date:message-id:subject:to :cc:content-type; bh=GNY/UJ7aB01m8JqxvIqOcZ72K0+rwc5OaVEOLjBbmqY=; b=EMiI4Q5sEYAmb1G1gwHQGOe9pK1hgjEjuYaiWQE+KRGeVJcd8jigT8eAFu/Rth/ScT 9DYED/ybFv4SrJacuS8LcTMN+jc1kHtjtk9TfMHFtf337mtQJMP+0hlj05cKUuulOTUN JVVCCKHr6JFcMalsiaOl5VYL1r+ynAqnkj4XJw0bAhh8fRWJ9H57ZuigfefXWC9DahTs pb6KdNMvSDXKE7Kn2tpNWvY9bQz1YGIpefbDTM85FmESpbx4SAn5QPqlT7uh1uKx7Xmc tl6p+wA8qtudEeO3/SumVZh5Wj1622+3PjkDe27Z9XIgz7sN/fHGp+5JaPmRce0jUTMe BSlg== X-Received: by 10.140.47.173 with SMTP id m42mr56959844qga.9.1404315749518; Wed, 02 Jul 2014 08:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Wed, 2 Jul 2014 08:42:09 -0700 (PDT) In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> From: Henning Rogge Date: Wed, 2 Jul 2014 17:42:09 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/o2SzxAue0t1VRzpSXiouy2t9Tmc Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 15:42:31 -0000 On Wed, Jul 2, 2014 at 4:35 PM, Abdussalam Baryun wrote: > > Hi Stan, > > I am not ready for last call and IMHO the WG did not discuss it enough, no > one reviewed. I disagree strongly. I did implement it and the point is that just a few points came up. All of them were mentioned on the list. Henning Rogge From nobody Wed Jul 2 08:44:34 2014 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 53E7D1A034F for ; Wed, 2 Jul 2014 08:44:32 -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 snJKYdXfqQks for ; Wed, 2 Jul 2014 08:44:29 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DAE1A035E for ; Wed, 2 Jul 2014 08:44:28 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q107so5032586qgd.13 for ; Wed, 02 Jul 2014 08:44:28 -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=HwK6KGz76aqqG4sNvxRuAwCKygWi09BLcJGwurBsDVE=; b=Psoy4gfI9yTCxaNZvfj6QTVz0waC77i98tJBf5heKMA35WGfV2y6Del1EB6x8lUIHe qqvuUb0V0phqo5K/hSvjXkm6d+D/cnOzY+r9Ps8prMtkQSuvTDqdCowE8+wrrgSY4Hlx S9NvDGgiVNh+eqdG9KbQKGUkmy7tTkoUg+237VZO6VdbhdivPPfkczzZ1th5WktydPi+ LvttJByA9k8H9OXgs++xdA/rHuHdgW4cW5W/d1hdeZkVs2H0aHdep4vQ2dVD1wagpYah Uao1A4CxWXfIVcFW3DCWLbRMU4YZU7Jr2hGoiZRjgQ6WZQCdLYphMjDcFjhylVMuEszh k6mA== X-Received: by 10.140.31.133 with SMTP id f5mr34189810qgf.8.1404315868257; Wed, 02 Jul 2014 08:44:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Wed, 2 Jul 2014 08:44:08 -0700 (PDT) In-Reply-To: References: <53B41998.7000800@gmail.com> From: Henning Rogge Date: Wed, 2 Jul 2014 17:44:08 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8-Qm1e7NMVh1BNEeUnT_W1DY5_4 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] WG document adoption of draft-dearlove-manet-ibs-00.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, 02 Jul 2014 15:44:32 -0000 On Wed, Jul 2, 2014 at 5:27 PM, Ulrich Herberg wrote: > I also support adoption of this draft. Adopting it would also give us a good alternative to the Shared-Key mechanism mentioned in RFC7181. Lets adopt it. Henning Rogge From nobody Wed Jul 2 09:35:52 2014 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 48F1C1A03E9 for ; Wed, 2 Jul 2014 09:35:50 -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 lCLNZgsm7nqc for ; Wed, 2 Jul 2014 09:35:49 -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 58C4E1A00AA for ; Wed, 2 Jul 2014 09:35:49 -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/46573) with ESMTP id s62GZjbc002495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Jul 2014 18:35:45 +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/46573) with ESMTP id s62GZjTH021496; Wed, 2 Jul 2014 18:35:45 +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 0DCCC2C095D; Wed, 2 Jul 2014 18:35:45 +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 n8RPEl-DXUIA; Wed, 2 Jul 2014 18:35:43 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 928A72C0955; Wed, 2 Jul 2014 18:35:43 +0200 (CEST) Date: Wed, 02 Jul 2014 18:35:49 +0200 Message-ID: <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Stan Ratliff (sratliff)" In-Reply-To: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.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]); Wed, 02 Jul 2014 18:35:45 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 02 Jul 2014 18:35:45 +0200 (CEST) X-Miltered: at korolev with ID 53B434E1.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53B434E1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B434E1.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53B434E1.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 : 53B434E1.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53B434E1.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: http://mailarchive.ietf.org/arch/msg/manet/Wnzx0YgwMS2iZYbkcl91hecy9ZU Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 16:35:50 -0000 I support publication of this draft as an Experimental RFC. Experimental RFCs are cool. I have one major concern about this draft, and some minor nits. While the title implies that it defines fully general multi-topology routing, the actual protocol strongly links the topologies to metric types. I'm not sure if that's intended. In particular, multi-topology seems like a useful extension to implement routing policies, say "avoid links that don't enforce link-layer encryption" or "avoid routers that belong to Henning". It would seem at first sight that I would need to encode such policies in a metric in order to make use of this extension. Minor nits: It would be good to state the invariants enforced and not enforced. I could be wrong, but I understand that the topologies can be different for different metrics, but every topology must be a subgraph of the topology advertised to non-MT routers. If that's right, that's a useful property to help the reader get an intuitive feel. 1. Introduction "it would be desirable to be able to use alternative metrics for different packet routing." Sounds strange. I suggest "for routing different packets". 3. Applicability Statement I'd like to know whether the data plane mechanism is expected to revert to a default metric if no route is found to a given destination or not. I assume not (which would confirm my guess that this is policy routing). I'm also a little worried about delegating this mechanism to an external mechanism. If different routers implement different mechanisms, won't persistent routing loops arise? 4. Protocol Overview I found this section difficult to read for purely syntactic reasons. "However there may be deployments where routers, that do not implement MT-OLSRv2 (non-MT-OLSRv2 routers), are to participate in a MANET with MT-OLSRv2 routers." Remove both commas. Or perhaps reformulate as "There may be deployments where both MT-OLSv2 and non-MT-OLSRv2 routers participate in a single routing domain" or somesuch. "advertised neighbor status, is maintained per supported neighbor". Remove the comma. "More so than OLSRv2, the use of multiple metric types across the MANET must be managed, by administrative configuration or otherwise." Strange syntax. 12. Management considerations It's still not clear to me how the protocol avoids loops if different routers map the same DSCP to different metrics. If you're assuming the mapping is uniform, it should be stated in this section. Shouldn't the last three bullet points be a single point? -- Juliusz From nobody Wed Jul 2 09:48:02 2014 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 B49931A05CB for ; Wed, 2 Jul 2014 09:47:58 -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 PMgo2zWzML9v for ; Wed, 2 Jul 2014 09:47:57 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6699B1B2993 for ; Wed, 2 Jul 2014 09:47:57 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id cm18so9240276qab.28 for ; Wed, 02 Jul 2014 09:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jpMXIWGB+VgRK5JIQq6gMDE5mXaO46TIzZI+4G/8S6U=; b=a/+t16fsORSGucH5doIbpT3kYyKzyS5EYGUe12RM1hlfoFjofDD7ClgR+zFcoqv5C2 Z8982fdnNbnSyD4JXB5F4ALHkKzayBKNKbTF8emdDlfFLuIgAJBn8hsIsC0BYUMQOnYT upX52fpadn9OqHP74g/isr3S5+d6pcJGe1FSjepBl30IvRfpdfyYCBziwKVT1JhNCemE r98Xm3rsHg6eXkzQ4AqWyNtigZJGvRgaqb6bRCCEALh1EDxqomi1GVV0Ts09DXbB/NNZ svYRwzbofTSfE9AK/V77Eohd0uPLai2I6PzMrBa6PgnnJPE5Kl7vTsL8vCUxFr37yeZ5 IPfQ== X-Received: by 10.140.101.86 with SMTP id t80mr55151377qge.108.1404319676629; Wed, 02 Jul 2014 09:47:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Wed, 2 Jul 2014 09:47:36 -0700 (PDT) In-Reply-To: <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Wed, 2 Jul 2014 18:47:36 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SCMplDl-VFgAxxeogyAFbY5rUQc Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 16:47:58 -0000 On Wed, Jul 2, 2014 at 6:35 PM, Juliusz Chroboczek wrote: > I support publication of this draft as an Experimental RFC. > Experimental RFCs are cool. > > I have one major concern about this draft, and some minor nits. > > While the title implies that it defines fully general multi-topology > routing, the actual protocol strongly links the topologies to metric > types. I'm not sure if that's intended. > > In particular, multi-topology seems like a useful extension to implement > routing policies, say "avoid links that don't enforce link-layer encryption" > or "avoid routers that belong to Henning". It would seem at first sight > that I would need to encode such policies in a metric in order to make use > of this extension. I had the same discussion with Christopher before... its more a "multi-metric" draft, but you can argue about the name. In theory you could announce the same metric value twice, once for each "sub-topology" and then leave out the metric for links you don't like, but that is a lot of overhead. But I have an idea for a "sub-topology" extension for this draft. Henning Rogge From nobody Wed Jul 2 09:50:37 2014 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 A58911B283B for ; Wed, 2 Jul 2014 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 Aaat9-LkVMCY for ; Wed, 2 Jul 2014 09:50:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9E81B282F for ; Wed, 2 Jul 2014 09:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=173; q=dns/txt; s=iport; t=1404319829; x=1405529429; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=sTLbZ27m/B6eoazLn0NtX2MqqJWDGFjghPcDLeiiXj0=; b=F7vdZPpark1f4En4oUJadcRIjeRAQYAa15LHwKOQu12qXgg4p18XeIiQ zs1yFIGYx32qB2TeN8lm42X3iuMmfAbLp2Z4sQBCJebdytcXpTM0L53od wkbCKf0Ka9cuXQeXW34dRDvzm2oGIkxr097X0B6SNTVQn9RCPFjteBHWl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8JAAU4tFOtJV2Q/2dsb2JhbABagw2BLI0SnioBAQEBAQEFAW4Bmm0WdYQKOlEBPkInBIhVnAeqVReFcIxmgRYFmm2UCoNDgjA X-IronPort-AV: E=Sophos;i="5.01,589,1400025600"; d="scan'208";a="337383185" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2014 16:50:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s62GoSOc031216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jul 2014 16:50:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 11:50:28 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Call to adopt draft-dearlove-manet-nhdp-optimization-01 Thread-Index: AQHPlhW66w1KEnMlykyI1n9BXV80Yg== Date: Wed, 2 Jul 2014 16:50:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <1713B9301892204AB06CA9FD24931D01@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lgCLeV6u8mbYWTjRJ01zkVT6wPk Subject: [manet] Call to adopt draft-dearlove-manet-nhdp-optimization-01 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, 02 Jul 2014 16:50:33 -0000 Working group participants,=20 There is a request for the WG to adopt draft-dearlove-manet-nhdp-optimizati= on-01 as a WG document. What say you?=20 Regards, Stan= From nobody Wed Jul 2 10:20:07 2014 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 861AB1A039B for ; Wed, 2 Jul 2014 10:20:03 -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 r9myT5QvwwuT for ; Wed, 2 Jul 2014 10:20:00 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973041A031F for ; Wed, 2 Jul 2014 10:20:00 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so11560871wes.10 for ; Wed, 02 Jul 2014 10:19:59 -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=sSZRZuYjRBZ30uH3XLzsCOuGYpkiNisE2HUVnJw7ES4=; b=B5Jk9TCkr9t6GmCbjBSLFsfLvkgxOLelX+QMaP3gRNYUQehTV6EWbLHYusFGHXD81M eUHblvlwq7qxicvvpJoC5HXiux28919aQtOVGdmCcFp8HB/VOp4JkPlP6XXrETOcTXZn peIplFAWQn804JRWqMo2jfrnHNylqp8QRm2Bo3rgo6yk6qnhnIhtj5mQVQH8/QWX+rJy rf8VAryQJltCwi6G2lqWvdwT4/vhEL7RaobUZwdQ5A0iL5lECRxGw0DK2Fpz9f3re9ib Le2/b2hz7BIvV1sk0VtvPFYPapyasJmemEFmuJYjMIhfBCqRUhtYzLQJBzbFxizKjpbO 75xw== X-Received: by 10.194.63.196 with SMTP id i4mr62014100wjs.50.1404321598952; Wed, 02 Jul 2014 10:19:58 -0700 (PDT) Received: from [10.0.251.90] (dab-ell1-h-40-3.dab.02.net. [82.132.237.94]) by mx.google.com with ESMTPSA id da9sm57272566wib.5.2014.07.02.10.19.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:19:58 -0700 (PDT) References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> Mime-Version: 1.0 (1.0) In-Reply-To: <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5979EB2C-B71E-43C5-ADEA-A0C8ACF9B092@gmail.com> X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Wed, 2 Jul 2014 18:19:47 +0100 To: Juliusz Chroboczek Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-_miPeZlotWmdWuBjsiJy12B0MI Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 17:20:03 -0000 It is intended that metric =3D topology, because no one (authors included, w= ho have tried) has come up with a solution that separates the two, interwork= s correctly with non-MT-OLSRv2, and isn't truly horrible. (Much greater need= for planned conformity of routers can also be a problem.) That challenge h= ad been on the table for months. No one even produced one that just failed t= he truly horrible test. It's also nothing unusual - look at OSPFv2 (RFC 4915= ) which essentially does the same. Note that by ensuring that 8 (the authors also considered 16, and would be o= pen to changing that) metrics are administratively configured, there's alway= s scope for a reasonable number of topologies. I'm not going to address all the points now (I'm on a mobile phone) but with= regard to looping, because a packet travels by one metric and one metric on= ly - no default fallback - it should not loop. In fact that's exactly why th= at behaviour. Where is there a suggestion of mapping one DSCP to multiple metrics? That's e= xactly backwards. Of course the mapping of packet to metric is outside the s= cope of this draft (even whether to use DSCP) except it should be clear that= the mapping must be well-defined and produce the same result at each router= for each packet. That may need to be said more clearly (I don't have draft i= n front of me to see what exactly is said). --=20 Christopher Dearlove > On 2 Jul 2014, at 17:35, Juliusz Chroboczek wrote: >=20 > I support publication of this draft as an Experimental RFC. > Experimental RFCs are cool. >=20 > I have one major concern about this draft, and some minor nits. >=20 > While the title implies that it defines fully general multi-topology > routing, the actual protocol strongly links the topologies to metric > types. I'm not sure if that's intended. >=20 > In particular, multi-topology seems like a useful extension to implement > routing policies, say "avoid links that don't enforce link-layer encryptio= n" > or "avoid routers that belong to Henning". It would seem at first sight > that I would need to encode such policies in a metric in order to make use= > of this extension. >=20 >=20 > Minor nits: >=20 > It would be good to state the invariants enforced and not enforced. > I could be wrong, but I understand that the topologies can be different > for different metrics, but every topology must be a subgraph of the > topology advertised to non-MT routers. If that's right, that's a useful > property to help the reader get an intuitive feel. >=20 >=20 > 1. Introduction >=20 > "it would be desirable to be able to use alternative metrics for different= > packet routing." Sounds strange. I suggest "for routing different packet= s". >=20 > 3. Applicability Statement >=20 > I'd like to know whether the data plane mechanism is expected to revert to= > a default metric if no route is found to a given destination or not. > I assume not (which would confirm my guess that this is policy routing). >=20 > I'm also a little worried about delegating this mechanism to an external > mechanism. If different routers implement different mechanisms, won't > persistent routing loops arise? >=20 > 4. Protocol Overview >=20 > I found this section difficult to read for purely syntactic reasons. >=20 > "However there may be deployments where routers, that do not implement > MT-OLSRv2 (non-MT-OLSRv2 routers), are to participate in a MANET with > MT-OLSRv2 routers." Remove both commas. Or perhaps reformulate as "There= > may be deployments where both MT-OLSv2 and non-MT-OLSRv2 routers > participate in a single routing domain" or somesuch. >=20 > "advertised neighbor status, is maintained per supported neighbor". > Remove the comma. >=20 > "More so than OLSRv2, the use of multiple metric types across the MANET > must be managed, by administrative configuration or otherwise." Strange > syntax. >=20 > 12. Management considerations >=20 > It's still not clear to me how the protocol avoids loops if different > routers map the same DSCP to different metrics. If you're assuming the > mapping is uniform, it should be stated in this section. >=20 > Shouldn't the last three bullet points be a single point? >=20 >=20 > -- Juliusz >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 2 10:25:40 2014 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 0C7131A038C for ; Wed, 2 Jul 2014 10:25:39 -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 MuHwFtkhA1I5 for ; Wed, 2 Jul 2014 10:25:37 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027B81A034D for ; Wed, 2 Jul 2014 10:25:36 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id x13so2657219wgg.11 for ; Wed, 02 Jul 2014 10:25:35 -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=7oT9s0TAVApXCjWgKgmKqKmenw46SnWEgi3jMVJIT04=; b=qEAh/X8LV5fc/s9cBVM9zQb/NOB/8Xn0jAcd3FTH/VfGby/TI4rMKHm4HY5B0VxdC9 thv6oRDLRqLWDwWEoNja/xWOj4MLeH2jWiRJEYjMfrvrDYB3yMfmCsnMYPC0uDsfTx4H FBXkTzgSjNcHwxldUFK+1165WpqTzIihyQ3GrDBwQ4lls6qklhj0bNw202BZ0/qlSktp HNNsFT3UXZoo4eEpcLiwXzvzhr4L61QerB5+J3CuGOyyQpI/V/i/EktEmvAZzz+laOKi zUbKF0tBUe3j1jSp0qBrQz4lyhuav2Y4y506+TBhRduvwwHS2owhwuUr7avfONapIGAJ AQxg== X-Received: by 10.194.57.208 with SMTP id k16mr61189281wjq.51.1404321935529; Wed, 02 Jul 2014 10:25:35 -0700 (PDT) Received: from [10.0.251.90] (dab-ell1-h-40-9.dab.02.net. [82.132.239.116]) by mx.google.com with ESMTPSA id lo18sm57336977wic.1.2014.07.02.10.25.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:25:35 -0700 (PDT) References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Wed, 2 Jul 2014 18:25:20 +0100 To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/dpMRvhXkJePR1jFOEpglCHK9CmQ Cc: manet IETF , "Stan Ratliff \(sratliff\)" , Juliusz Chroboczek Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 17:25:39 -0000 If you can come up with one that works, we'd like to see it. (We'd have even= more liked to have seen it earlier.) Note that some apparent ideas turn out= not to work - I've tried some. I (note the change from we) also wouldn't find a solution that forces over-m= anagement acceptable. Note that the current design allows all routers to mak= e independent choices as to which metrics/topologies to support. (I also don't agree it's not multi-topology. If so, neither is RFC 4915.) --=20 Christopher Dearlove > On 2 Jul 2014, at 17:47, Henning Rogge wrote: >=20 > On Wed, Jul 2, 2014 at 6:35 PM, Juliusz Chroboczek > wrote: >> I support publication of this draft as an Experimental RFC. >> Experimental RFCs are cool. >>=20 >> I have one major concern about this draft, and some minor nits. >>=20 >> While the title implies that it defines fully general multi-topology >> routing, the actual protocol strongly links the topologies to metric >> types. I'm not sure if that's intended. >>=20 >> In particular, multi-topology seems like a useful extension to implement >> routing policies, say "avoid links that don't enforce link-layer encrypti= on" >> or "avoid routers that belong to Henning". It would seem at first sight >> that I would need to encode such policies in a metric in order to make us= e >> of this extension. >=20 > I had the same discussion with Christopher before... its more a > "multi-metric" draft, but you can argue about the name. >=20 > In theory you could announce the same metric value twice, once for > each "sub-topology" and then leave out the metric for links you don't > like, but that is a lot of overhead. >=20 > But I have an idea for a "sub-topology" extension for this draft. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 2 10:33:06 2014 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 BF0071B29BE for ; Wed, 2 Jul 2014 10:33:01 -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 uezgDb3_1qrH for ; Wed, 2 Jul 2014 10:33:01 -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 E32041B29B2 for ; Wed, 2 Jul 2014 10:33:00 -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/46573) with ESMTP id s62HWx8T021205; Wed, 2 Jul 2014 19:32:59 +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 3FB942C0967; Wed, 2 Jul 2014 19:32:59 +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 6wiYFiM0lTRG; Wed, 2 Jul 2014 19:32:57 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D43532C0964; Wed, 2 Jul 2014 19:32:57 +0200 (CEST) Date: Wed, 02 Jul 2014 19:33:03 +0200 Message-ID: <87a98r7jjk.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Christopher Dearlove In-Reply-To: <5979EB2C-B71E-43C5-ADEA-A0C8ACF9B092@gmail.com> References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> <5979EB2C-B71E-43C5-ADEA-A0C8ACF9B092@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 [194.254.61.138]); Wed, 02 Jul 2014 19:32:59 +0200 (CEST) X-Miltered: at korolev with ID 53B4424B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B4424B.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 : 53B4424B.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: http://mailarchive.ietf.org/arch/msg/manet/7lPfq91hYXw2eiER7zFznHW4eAA Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 17:33:03 -0000 > It is intended that metric = topology, because no one (authors included, > who have tried) has come up with a solution that separates the two, > interworks correctly with non-MT-OLSRv2, and isn't truly horrible. Ok, that's a very good reason. I suggest putting that in the introduction. > Where is there a suggestion of mapping one DSCP to multiple metrics? There's nothing that says that the DSCP mapping must be consistent between distinct routers. > it should be clear that the mapping must [..] produce the same result at > each router for each packet. That may need to be said more clearly Yes, please. -- Juliusz From nobody Wed Jul 2 10:45:11 2014 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 B40811A03BB for ; Wed, 2 Jul 2014 10:45:07 -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 f64-n_xo-26l for ; Wed, 2 Jul 2014 10:45:05 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3241A03B4 for ; Wed, 2 Jul 2014 10:45:05 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so11502046wes.41 for ; Wed, 02 Jul 2014 10:45:04 -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=iwjYvImCcemfhm7CnqhUTnZURRUDfXiwCHk2PjhpaI8=; b=e4LCdgEJNcHDmgP3dIkBjRffFWmL2UsH6uGbF9VYydiqt6erZtm+0l3cIHMKRxtnc3 /K9JU4PG1HAPwEgiTUbGQ19N4w8zkVDGH23VGPS9r9UlLfRDXkDCl/7Bu5rIQI5tJ548 LSbeLndB4te22Egi/4C7UlKGJuftlS9Iga3N97zTdlOgiMn6gYYjFl6gflZrw8JtxaMJ YACjXbtx5P33sXo3UZmseC2r1BKvshhje84OzzDZLpbUDfLm684VL0Sfxs6Ph+IqZ1aU Gxb2l0AdZwor6rc7SoMjmcz1yw4oLBElR70Vp0Imtr1nK4AKoNJtWXlvVuJc02qt8sKk pEaA== X-Received: by 10.180.87.161 with SMTP id az1mr5847022wib.63.1404323104164; Wed, 02 Jul 2014 10:45:04 -0700 (PDT) Received: from [10.0.251.90] (dab-ell1-h-1-5.dab.02.net. [82.132.237.233]) by mx.google.com with ESMTPSA id hq20sm5873136wib.0.2014.07.02.10.45.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:45:03 -0700 (PDT) References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> <5979EB2C-B71E-43C5-ADEA-A0C8ACF9B092@gmail.com> <87a98r7jjk.wl.jch@pps.univ-paris-diderot.fr> Mime-Version: 1.0 (1.0) In-Reply-To: <87a98r7jjk.wl.jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3F4CD21F-9621-4DB7-BD6F-1E4661466011@gmail.com> X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Wed, 2 Jul 2014 18:44:53 +0100 To: Juliusz Chroboczek Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bs3KWYEJUVPtP-FNEe4VzJktzn4 Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 17:45:07 -0000 Well, before we say it's not possible, let's see if Henning (or anyone else,= but he seems most likely to succeed) has an idea that works. All I can say i= s that the authors haven't found one. I wouldn't want to wait indefinitely f= or an idea, this is of course only aimed at Experimental, but an idea (enoug= h to assess) before WGLC deadline would need to be considered as to whether t= o adopt. (We did have to give up on one idea that looked promising at one point, of a= llowing inter working with more than one non-MT-OLSRv2 network using differe= nt metrics. It's possible we could treat the one metric we now do recognise a= s non-MT-OLSRv2 as a special case. Which already puts a kink in things as th= at's likely to be the "best" metric. The problems then start arising as to h= ow to define topology to metric mapping, especially without making the netwo= rk ad hoc in name only.) --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 2 Jul 2014, at 18:33, Juliusz Chroboczek w= rote: >> It is intended that metric =3D topology, because no one (authors included= , >> who have tried) has come up with a solution that separates the two, >> interworks correctly with non-MT-OLSRv2, and isn't truly horrible. >=20 > Ok, that's a very good reason. I suggest putting that in the introduction= . >=20 >> Where is there a suggestion of mapping one DSCP to multiple metrics? >=20 > There's nothing that says that the DSCP mapping must be consistent between= > distinct routers. >=20 >> it should be clear that the mapping must [..] produce the same result at >> each router for each packet. That may need to be said more clearly >=20 > Yes, please. >=20 > -- Juliusz >=20 From nobody Wed Jul 2 10:59:59 2014 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 2BF3B1B29B7 for ; Wed, 2 Jul 2014 10:59:58 -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 tSuyAVnZlejp for ; Wed, 2 Jul 2014 10:59:56 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824481B287E for ; Wed, 2 Jul 2014 10:59:56 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so5119770qgd.10 for ; Wed, 02 Jul 2014 10:59:55 -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=pOAgoFT+C+2aFAxFL/WZVHzPKYXOoBcgDG3mmCRyL8k=; b=EEgB2Ox6vZYoB7u2TPjH1DO9Rt+pjG1OClNTtoO+2FbPaYuy5u3I+I46CrVxeqaZlv 7qrO2CZZX8s1xWPBhdzzAj/fzZ6asBoVK3th9rSljrI6+3hth4fxTkG1z6jtnnaxJb2M 8CTWi0JwhfjeO0qw+4glD9HEb0kWLMb1izzgRv08I6m1eTx6aO5Ul8LCi/zaIg/MgPxv Mqn9m+ex/iAlwTR3jQwfAblv05YxKlthUW4fD6bY+ttXk7rCPwuKLUD433Npm1Ho//Op xXrd9K/f6DcYPO+ohpgNBRuCGUTN+TXtu16qgqKDX/Y3IUlmVak5ryglcz4FN9eQLh2W OpNQ== X-Received: by 10.140.108.99 with SMTP id i90mr69754472qgf.56.1404323995696; Wed, 02 Jul 2014 10:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Wed, 2 Jul 2014 10:59:35 -0700 (PDT) In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Wed, 2 Jul 2014 19:59:35 +0200 Message-ID: To: Christopher Dearlove Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Ztd5IASol54N1cMfdj-78IKWeng Cc: manet IETF , "Stan Ratliff \(sratliff\)" , Juliusz Chroboczek Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 17:59:58 -0000 Hmm, my idea would be to have a second TLV similar to TLV_TYPES, which defines a mapping of an index to a "full topology/metric" (can use the same topology number multiple times). The MPR bitarray and Willingness array just gets extended by a number of entries according to the length of the new mapping TLV. Each address in a TC needs an additional TLV with a bitarray that defines if the link is available for each of the mappings. This should allow you to save a lot of bytes because you don't have to announce the same metrics multiple times. I still have to go through the details (earlier I thought I would not need a TLV for each address in the TCs), but I think it could work. Henning Rogge On Wed, Jul 2, 2014 at 7:25 PM, Christopher Dearlove wrote: > If you can come up with one that works, we'd like to see it. (We'd have even more liked to have seen it earlier.) Note that some apparent ideas turn out not to work - I've tried some. > > I (note the change from we) also wouldn't find a solution that forces over-management acceptable. Note that the current design allows all routers to make independent choices as to which metrics/topologies to support. > > (I also don't agree it's not multi-topology. If so, neither is RFC 4915.) > > -- > Christopher Dearlove > >> On 2 Jul 2014, at 17:47, Henning Rogge wrote: >> >> On Wed, Jul 2, 2014 at 6:35 PM, Juliusz Chroboczek >> wrote: >>> I support publication of this draft as an Experimental RFC. >>> Experimental RFCs are cool. >>> >>> I have one major concern about this draft, and some minor nits. >>> >>> While the title implies that it defines fully general multi-topology >>> routing, the actual protocol strongly links the topologies to metric >>> types. I'm not sure if that's intended. >>> >>> In particular, multi-topology seems like a useful extension to implement >>> routing policies, say "avoid links that don't enforce link-layer encryption" >>> or "avoid routers that belong to Henning". It would seem at first sight >>> that I would need to encode such policies in a metric in order to make use >>> of this extension. >> >> I had the same discussion with Christopher before... its more a >> "multi-metric" draft, but you can argue about the name. >> >> In theory you could announce the same metric value twice, once for >> each "sub-topology" and then leave out the metric for links you don't >> like, but that is a lot of overhead. >> >> But I have an idea for a "sub-topology" extension for this draft. >> >> Henning Rogge >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 2 11:12:52 2014 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 C230E1B280D for ; Wed, 2 Jul 2014 11:12:48 -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 GeRVcktyzBGw for ; Wed, 2 Jul 2014 11:12:42 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F3B1B2A01 for ; Wed, 2 Jul 2014 11:12:40 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so1183371wgh.14 for ; Wed, 02 Jul 2014 11:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Nvuq/7nmJ5zwG/gsEnITVXaxSUsBZYupt/0I3CDCqg=; b=0Q8x3MLHJGT/DojLGWTMp9VRf7i+WbY6maxC2hoiF9hobYShvpPOQRoo4lElypT3CF 5SSwffevIP5Bycu6wCtlR+hNcjHf643DCf5pNWcLVLGF+IieQoLwhpcGhMRT9hEdxGAY icj0e9gRum1PGsGbVBGmke3Q4F1iAezG8F50qVdSo+34qh/87XZ9f/1HR7PJ83n+r+Vd yKZov3ftqC7g9zXuiazWUfPHhgPSV3sVeJjBt+DkgcrmJGp9ERL6bo//T6M/H+Q6cim6 a88r9N8rk1BF2pThHXawKU5IEnZCRH48LVjM9Litdvxe42ioyPPDKM9NrxA8F7w1zZjo 6RTg== X-Received: by 10.180.221.133 with SMTP id qe5mr5935463wic.79.1404324758959; Wed, 02 Jul 2014 11:12:38 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id e18sm10089081wic.0.2014.07.02.11.12.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 11:12:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Wed, 2 Jul 2014 19:12:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <764F9936-5B35-4AC6-ADBD-368F4E5918D9@gmail.com> References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> To: Henning Rogge X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/omq13rB1r7yiJOiTSbVTsVrmdUs Cc: manet IETF , "Stan Ratliff \(sratliff\)" , Juliusz Chroboczek Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 18:12:50 -0000 I'm not liking it so far, for a number of reasons, but let's see where = it goes, as none are fatal yet. On 2 Jul 2014, at 18:59, Henning Rogge wrote: > Hmm, >=20 > my idea would be to have a second TLV similar to TLV_TYPES, which > defines a mapping of an index to a "full topology/metric" (can use the > same topology number multiple times). >=20 > The MPR bitarray and Willingness array just gets extended by a number > of entries according to the length of the new mapping TLV. >=20 > Each address in a TC needs an additional TLV with a bitarray that > defines if the link is available for each of the mappings. >=20 > This should allow you to save a lot of bytes because you don't have to > announce the same metrics multiple times. >=20 > I still have to go through the details (earlier I thought I would not > need a TLV for each address in the TCs), but I think it could work. >=20 > Henning Rogge >=20 > On Wed, Jul 2, 2014 at 7:25 PM, Christopher Dearlove > wrote: >> If you can come up with one that works, we'd like to see it. (We'd = have even more liked to have seen it earlier.) Note that some apparent = ideas turn out not to work - I've tried some. >>=20 >> I (note the change from we) also wouldn't find a solution that forces = over-management acceptable. Note that the current design allows all = routers to make independent choices as to which metrics/topologies to = support. >>=20 >> (I also don't agree it's not multi-topology. If so, neither is RFC = 4915.) >>=20 >> -- >> Christopher Dearlove >>=20 >>> On 2 Jul 2014, at 17:47, Henning Rogge wrote: >>>=20 >>> On Wed, Jul 2, 2014 at 6:35 PM, Juliusz Chroboczek >>> wrote: >>>> I support publication of this draft as an Experimental RFC. >>>> Experimental RFCs are cool. >>>>=20 >>>> I have one major concern about this draft, and some minor nits. >>>>=20 >>>> While the title implies that it defines fully general = multi-topology >>>> routing, the actual protocol strongly links the topologies to = metric >>>> types. I'm not sure if that's intended. >>>>=20 >>>> In particular, multi-topology seems like a useful extension to = implement >>>> routing policies, say "avoid links that don't enforce link-layer = encryption" >>>> or "avoid routers that belong to Henning". It would seem at first = sight >>>> that I would need to encode such policies in a metric in order to = make use >>>> of this extension. >>>=20 >>> I had the same discussion with Christopher before... its more a >>> "multi-metric" draft, but you can argue about the name. >>>=20 >>> In theory you could announce the same metric value twice, once for >>> each "sub-topology" and then leave out the metric for links you = don't >>> like, but that is a lot of overhead. >>>=20 >>> But I have an idea for a "sub-topology" extension for this draft. >>>=20 >>> Henning Rogge >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 2 11:23:20 2014 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 B2EDD1B2864 for ; Wed, 2 Jul 2014 11:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 NRRoD5EVHjou for ; Wed, 2 Jul 2014 11:23:16 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E53D1A03D1 for ; Wed, 2 Jul 2014 11:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=650; q=dns/txt; s=iport; t=1404325397; x=1405534997; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2Z8TfCvWtcwhiHhg5Lm4JhrlLET7NMe4aNlGhhUcoJ0=; b=PBXI0FkkfIs8bQo7eb6neGoqRjplC/+mJS6WG/KzU+cO3Cc4Jt114EKS KUzmslPsUFzrsVKK1LIRlmdLCtog8AYGchWaF7jPdxka1A0pLYL90emb7 AFMccyWMql460UmxhebaJUiP6A2lmogGjqS2nBb7grccHy7I4rHvyh37e o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUJAOhMtFOtJA2B/2dsb2JhbABagw2BLKs8AQEBAQEBBQFuAZllgQgWdYQKOj8SAT5CJwQOiEfHQheFcIhQEQFQgzSBFgWabZQKg0OBdzk X-IronPort-AV: E=Sophos;i="5.01,589,1400025600"; d="scan'208";a="57769379" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 02 Jul 2014 18:23:16 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s62INFn5006873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 18:23:15 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 13:23:15 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Chairs will not be present in Toronto Thread-Index: AQHPliKw2ljAb2jbW0OPp2GNzIbkVg== Date: Wed, 2 Jul 2014 18:23:15 +0000 Message-ID: <8B9E9E56-14A8-4CC9-90AB-4E9C17AE2034@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <113053AADDB89044BF4F8D2D9DB0A2C7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yCTOJqIDmpUY5v6ivF3Zuk16gVc Subject: [manet] Chairs will not be present in Toronto 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, 02 Jul 2014 18:23:17 -0000 Working group participants,=20 For various personal and business reasons Joe and I are unable to make it t= o Toronto despite wishing to be there.=20 In our absence we have asked Ulrich and Justin Dean to coordinate the meeti= ng, and we are sure they will do a great job with your support. We don't an= ticipate that they will need to call consensus on any issues during the mee= ting, but the AD (Adrian) will be around to help if that turns out to be ne= cessary. If you have any issues or concerns about this or that you would normally ha= ve raised with us face-to-face, please don't hesitate to send us email. Regards, Stan From nobody Wed Jul 2 12:03:15 2014 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 B684F1B2A2E for ; Wed, 2 Jul 2014 12:03:12 -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 lVMDw9NJVwFQ for ; Wed, 2 Jul 2014 12:03:04 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34461B2A43 for ; Wed, 2 Jul 2014 12:03:02 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id va2so12882884obc.32 for ; Wed, 02 Jul 2014 12:03: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:date:message-id:subject:from:to :cc:content-type; bh=IZHdgMQCF+WgeBaAnV18WnzlM6XjMgajgxIl8ZjAF1A=; b=VMp3+V87nSkfRRk+CWh1wYlPQYOgnh2jLG5XAgvnmVvfmoHRH4pGvmjTInjkASAy4s +B5Nd+ciS2NmFfmXpT/wMsH45iqYILGqzvyDa3Z1C4n08rAVO2xnVuzDx/ww4clVaInq wBAYR0LSlamJEw3XhuMzi7bc39fX6YqnBCHxQyDNWP+5wCZ5o2iZT5LZ3a12HrTvvhSu kyub4Oa2sTpnnNqU7Y2la3Pqp5jmalFdA/dTwNTsZCV0+2+Iy8EOP43+Xk1qmMQm93YD M6L2QCwkG2C1MY2o1iKEsjHN2mvNm5jS0VXF4AXHsvqeMtm0/zNTr8CeF1yDo+ZlZ4Yo stIg== MIME-Version: 1.0 X-Received: by 10.60.65.170 with SMTP id y10mr38089965oes.45.1404327782195; Wed, 02 Jul 2014 12:03:02 -0700 (PDT) Received: by 10.76.89.111 with HTTP; Wed, 2 Jul 2014 12:03:01 -0700 (PDT) In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> Date: Wed, 2 Jul 2014 20:03:01 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c211949c448904fd3a8a47 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0sjjU5iCoiYyFAnbwaGaRtutIgA Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 19:03:12 -0000 --001a11c211949c448904fd3a8a47 Content-Type: text/plain; charset=UTF-8 I am sorry Henning, I try my best to track reviews, I still did not review but I seen your review to individual draft and did not see the WG document as mentioned by Chair. However, I still not have time to check but if there was no changes between draft before adopted and after, then that was the reason of my misunderstanding of your review. (I usually check reviews of WG drafts more than individuals, even if they have same title and abstract, I had confused my progress with one NHDP individual draft before, because there may be few changes done by authors after adopted, and reviews cannot be tracked). AB On Wednesday, July 2, 2014, Henning Rogge wrote: > On Wed, Jul 2, 2014 at 4:35 PM, Abdussalam Baryun > > wrote: > > > > Hi Stan, > > > > I am not ready for last call and IMHO the WG did not discuss it enough, > no > > one reviewed. > > I disagree strongly. I did implement it and the point is that just a > few points came up. All of them were mentioned on the list. > > Henning Rogge > --001a11c211949c448904fd3a8a47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am sorry Henning, I try my best to track reviews,=C2=A0I still did not re= view but I seen your=C2=A0review to individual draft and=C2=A0did not see t= he WG document as mentioned by Chair.=C2=A0However, I still not have time t= o check but if there was no changes between=C2=A0draft before adopted and a= fter, then that was the reason of my misunderstanding of your review.=C2=A0=

(I usually check reviews of WG drafts more than individuals,= =C2=A0even if they have=C2=A0same title and abstract, I had confused my pro= gress with one=C2=A0NHDP individual draft before,=C2=A0because there may be= few=C2=A0changes done by authors after adopted, and reviews cannot be trac= ked).=C2=A0

AB

On Wednesday, July 2, 2014, Henning Rogge wrote:<= br>
On Wed, Jul 2, 2014 at 4:35 PM, Abdussala= m Baryun
<abdussalambaryun@gmail.com> wrote:
>
> Hi Stan,
>
> I am not ready for last call and IMHO the WG did not discuss it enough= , no
> one reviewed.

I disagree strongly. I did implement it and the point is that just a
few points came up. All of them were mentioned on the list.

Henning Rogge
--001a11c211949c448904fd3a8a47-- From nobody Wed Jul 2 14:14:15 2014 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 9801B1B2A9E for ; Wed, 2 Jul 2014 14:14:12 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uw23V0PkSpNn for ; Wed, 2 Jul 2014 14:14:11 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DB31A03EB for ; Wed, 2 Jul 2014 14:14:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id B74C89A139A; Wed, 2 Jul 2014 14:14:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 463FA9A1396; Wed, 2 Jul 2014 14:14:10 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AE812D14-8554-4C14-910A-79EAAAA8532E Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Wed, 2 Jul 2014 23:14:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0A552AE4-E7A2-4EEE-A6BD-5431F92BE62D@thomasclausen.org> References: To: Joseph Macker Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Q5A6zfLaZYzUuURYrLLqYU4QVKE Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] WG document adoption of draft-dearlove-manet-ibs-00.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, 02 Jul 2014 21:14:12 -0000 --Apple-Mail-AE812D14-8554-4C14-910A-79EAAAA8532E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think that I already have expressed strong support for this, but in case i= t didn't register, then here it is again:=20 Good idea, well written doc; there'd be a few nits I'd want to pick= , but that can easily=20 happen /after/ the document has been adopted by the WG. I.e., strong support for adopting. Thomas Sent from my iPad > On 30 Jun 2014, at 21:11, Joseph Macker wrote: >=20 > Chris/All: >=20 > There has been a request to adopt draft-dearlove-manet-ibs-00.txt as a WG d= ocument. > Please review and comment regarding opinions to adopt.=20 >=20 > The presentation request of this document is also approved for Toronto. > URL: http://www.ietf.org/internet-drafts/draft-dearlove-manet-ibs-00.txt >=20 > We will be collecting WG comments on this document for the next 2 weeks pr= ior to making an adoption decision. >=20 > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-AE812D14-8554-4C14-910A-79EAAAA8532E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think that I already have expressed s= trong support for this, but in case it didn't register, then here it is agai= n: 

Good idea, well written doc; there'd be a few n= its I'd want to pick, but that can easily 
happen /after/ the document h= as been adopted by the WG.

I.e., strong support for= adopting.

Thomas

Sent from my iPad

On 30 Jun 2014, at 21:11, Joseph Macker <jpmacker@gmail.com> wrote:

Chris/All:

There ha= s been a request to adopt draft-dearlove-manet-ibs-00.txt as a WG docum= ent.
Please review and comment regarding opinions to adopt. <= /div>

The presentation request of this document is also a= pproved for Toronto.

We will be collecting WG comments on this document for the ne= xt 2 weeks prior to making an adoption decision.

-J= oe
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-AE812D14-8554-4C14-910A-79EAAAA8532E-- From nobody Wed Jul 2 14:18:19 2014 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 D61261B2AAA for ; Wed, 2 Jul 2014 14:18:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jOuuzNnqIgVU for ; Wed, 2 Jul 2014 14:18:14 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658B51B2AA7 for ; Wed, 2 Jul 2014 14:18:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 2A7C09A1442; Wed, 2 Jul 2014 14:18:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 9F2799A1444; Wed, 2 Jul 2014 14:18:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Wed, 2 Jul 2014 23:18:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> To: Christopher Dearlove Archived-At: http://mailarchive.ietf.org/arch/msg/manet/00ibUu8bEFazG1OKwT73vFm8lSY Cc: manet IETF , Juliusz Chroboczek , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 21:18:16 -0000 > On 02 Jul 2014, at 19:25, Christopher Dearlove wrote: >=20 > If you can come up with one that works, we'd like to see it. (We'd have ev= en more liked to have seen it earlier.) Note that some apparent ideas turn o= ut not to work - I've tried some. > I (note the change from we) also wouldn't find a solution that forces over= -management acceptable. Oh, you could write "we" instead of "I" here, if you intended to mean "the a= uthors" ;) Thomas > Note that the current design allows all routers to make independent choice= s as to which metrics/topologies to support. >=20 > (I also don't agree it's not multi-topology. If so, neither is RFC 4915.) >=20 > --=20 > Christopher Dearlove >=20 >> On 2 Jul 2014, at 17:47, Henning Rogge wrote: >>=20 >> On Wed, Jul 2, 2014 at 6:35 PM, Juliusz Chroboczek >> wrote: >>> I support publication of this draft as an Experimental RFC. >>> Experimental RFCs are cool. >>>=20 >>> I have one major concern about this draft, and some minor nits. >>>=20 >>> While the title implies that it defines fully general multi-topology >>> routing, the actual protocol strongly links the topologies to metric >>> types. I'm not sure if that's intended. >>>=20 >>> In particular, multi-topology seems like a useful extension to implement= >>> routing policies, say "avoid links that don't enforce link-layer encrypt= ion" >>> or "avoid routers that belong to Henning". It would seem at first sight= >>> that I would need to encode such policies in a metric in order to make u= se >>> of this extension. >>=20 >> I had the same discussion with Christopher before... its more a >> "multi-metric" draft, but you can argue about the name. >>=20 >> In theory you could announce the same metric value twice, once for >> each "sub-topology" and then leave out the metric for links you don't >> like, but that is a lot of overhead. >>=20 >> But I have an idea for a "sub-topology" extension for this draft. >>=20 >> Henning Rogge >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 2 15:17:02 2014 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 901041B2AEE for ; Wed, 2 Jul 2014 15:17:01 -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 UVJDqrWqsu1v for ; Wed, 2 Jul 2014 15:17:00 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE801A037D for ; Wed, 2 Jul 2014 15:16:59 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so10389413wiv.8 for ; Wed, 02 Jul 2014 15:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WjFIadJPFcSgQ6wsSipUQjzt3PRUpKx03UzNdI5Ha3o=; b=tziOX2RKvubLqTWG1wy6wd1GYB19DDnaGOgSlUq6u+G7ntZZ+jQEnsvLGAVaPGeiXS LYn7Tr8VTWZekowXcoRtCIGRO+SKPcmtKDXZgiVsvbA9eLROAdNTHCUOVrdZDHF0mPwo m7lAAd21q4Iw8gcnD07Vebm0Fb1Ao9ogJzjKFOckEZf0RrzdwxO8chDzXaHtfVoUFDpo fkrVS5I7iTZAZXimrtuMhBzY1VEVxq/A/NKH6iZtPlEoAWS9tLbjtd41RpWKE7j4KlAl bf071nVxIarS/vlZ+UaWuATfq8ifFvDSSnrBImDbLjlWPET6Q0tgUG0i/tOqk1hGo+2Q ztUQ== X-Received: by 10.180.210.165 with SMTP id mv5mr6863152wic.70.1404339418510; Wed, 02 Jul 2014 15:16:58 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id di7sm57758229wjb.34.2014.07.02.15.16.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 15:16:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Wed, 2 Jul 2014 23:16:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E70678D-39D3-4885-8BB6-E8E0E42BF5ED@gmail.com> References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> To: Thomas Clausen X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZZM5rXaWGajX9nqJS3Frmp8XlpI Cc: manet IETF , Juliusz Chroboczek , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 02 Jul 2014 22:17:01 -0000 I hadn't checked that with you, so although you don't surprise me, that = needed to be I then. On 2 Jul 2014, at 22:18, Thomas Clausen wrote: >> On 02 Jul 2014, at 19:25, Christopher Dearlove = wrote: >>=20 >> If you can come up with one that works, we'd like to see it. (We'd = have even more liked to have seen it earlier.) Note that some apparent = ideas turn out not to work - I've tried some. >> I (note the change from we) also wouldn't find a solution that forces = over-management acceptable. >=20 > Oh, you could write "we" instead of "I" here, if you intended to mean = "the authors" ;) >=20 > Thomas >=20 >> Note that the current design allows all routers to make independent = choices as to which metrics/topologies to support. >>=20 >> (I also don't agree it's not multi-topology. If so, neither is RFC = 4915.) >>=20 >> --=20 >> Christopher Dearlove >>=20 >>> On 2 Jul 2014, at 17:47, Henning Rogge wrote: >>>=20 >>> On Wed, Jul 2, 2014 at 6:35 PM, Juliusz Chroboczek >>> wrote: >>>> I support publication of this draft as an Experimental RFC. >>>> Experimental RFCs are cool. >>>>=20 >>>> I have one major concern about this draft, and some minor nits. >>>>=20 >>>> While the title implies that it defines fully general = multi-topology >>>> routing, the actual protocol strongly links the topologies to = metric >>>> types. I'm not sure if that's intended. >>>>=20 >>>> In particular, multi-topology seems like a useful extension to = implement >>>> routing policies, say "avoid links that don't enforce link-layer = encryption" >>>> or "avoid routers that belong to Henning". It would seem at first = sight >>>> that I would need to encode such policies in a metric in order to = make use >>>> of this extension. >>>=20 >>> I had the same discussion with Christopher before... its more a >>> "multi-metric" draft, but you can argue about the name. >>>=20 >>> In theory you could announce the same metric value twice, once for >>> each "sub-topology" and then leave out the metric for links you = don't >>> like, but that is a lot of overhead. >>>=20 >>> But I have an idea for a "sub-topology" extension for this draft. >>>=20 >>> Henning Rogge >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 2 21:51:27 2014 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 3C8731A02F4 for ; Wed, 2 Jul 2014 21:51:25 -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 Fz1bpJ4zv_Ze for ; Wed, 2 Jul 2014 21:51:23 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73801A0296 for ; Wed, 2 Jul 2014 21:51:23 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id j17so13414936oag.24 for ; Wed, 02 Jul 2014 21:51:23 -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=CDOcWiRKZamsvmWsJDTM/P6R9BfqBTN35aJp3rV+/wM=; b=EnYSX+LLa1lqM5FekJlmCdK+YAWRZ4RMEPSBTCiAeq62Z7JERH3BtP51VHZOT1podX js4DOaJSUEw0G/B0SkpljknvCijUBhSHXx7rgOV4yppfMyb5ffQHU3YsZBqatv31ja/o 2yUrFcBj7zsMXkYudXOIYXdFZ0ZXXJwR0xjkDIuxrWaUbBsUmEz9pDMrcF6/89v1O/pk MuKICbVDVcVVUh9Ai9RC9eveykjvp2F+3kOguNxY/95botKrKi1J4hGNX1oOwhtGfCgC uXRxTuKqtaJ89JWckkZhpH9RogxtdQOaTjSnx3tHse2p2hzoYBGtejV8gb27QFZYIlRm P4Wg== MIME-Version: 1.0 X-Received: by 10.60.145.196 with SMTP id sw4mr2122207oeb.72.1404363083080; Wed, 02 Jul 2014 21:51:23 -0700 (PDT) Received: by 10.76.89.111 with HTTP; Wed, 2 Jul 2014 21:51:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jul 2014 05:51:22 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7b5d427eb3e9ac04fd42c2b3 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2KnkpYhu5Oq8fKhokr9ahEKLuSk Cc: manet IETF Subject: [manet] Call to adopt draft-dearlove-manet-nhdp-optimization-01 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, 03 Jul 2014 04:51:25 -0000 --047d7b5d427eb3e9ac04fd42c2b3 Content-Type: text/plain; charset=UTF-8 Hi WG Chair, IMHO the proposal updates our two tested standards function related to lost nieghbors, but I am not sure of the tests of this optimisation approach compared with standards. Furthermore, the optimisation is not determined, or the draft does not explain how to determine the threshods to ensure optimisation. The draft is with a general approach with no test references, and I searched for credibility of the draft approach and had no engineering test results (no published/presented test of the draft approach in the world, if I am mistaken please point me to a reference). So I say: to suggest that draft authors show WG the performance results in one meeting. I vote don't adopt until seeing a presented results of optimisation performance in terms of net data rate and delay with MANET size scenarios and with determined thresholds (experiments or simulations). AB On Wednesday, July 2, 2014, Stan Ratliff (sratliff) wrote: > Working group participants, > > There is a request for the WG to adopt > draft-dearlove-manet-nhdp-optimization-01 as a WG document. What say you? > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b5d427eb3e9ac04fd42c2b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi WG Chair,

IMHO the=C2=A0proposal=C2=A0updates o= ur two tested=C2=A0standards function related to lost=C2=A0nieghbors,=C2=A0= but I am not sure of the tests of this optimisation approach=C2=A0compared = with standards.=C2=A0Furthermore, the optimisation is not determined, or th= e=C2=A0draft does not explain how to determine the threshods to ensure opti= misation.=C2=A0The draft is with a general approach with no test references= , and I searched for credibility of the=C2=A0draft approach and had no engi= neering test=C2=A0results (no published/presented test=C2=A0of the draft ap= proach in the world, if I am mistaken please point me to a reference).=C2= =A0

So=C2=A0I say: to=C2=A0suggest that draft authors show WG th= e=C2=A0performance results in one meeting.=C2=A0I vote=C2=A0don't adopt= until seeing a=C2=A0presented results of optimisation performance in terms= of=C2=A0net=C2=A0data rate and delay=C2=A0with MANET size=C2=A0scenarios a= nd with=C2=A0determined thresholds=C2=A0(experiments or simulations).=C2=A0=

AB

On Wednesday, July 2, 2014, Stan Ratliff (sratliff) wrote:
Working group participants,

There is a request for the WG to adopt draft-dearlove-manet-nhdp-optimizati= on-01 as a WG document. What say you?

Regards,
Stan
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--047d7b5d427eb3e9ac04fd42c2b3-- From nobody Wed Jul 2 23:55:21 2014 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 07D781A083D for ; Wed, 2 Jul 2014 23:55:19 -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 2q1YWPZhmzqN for ; Wed, 2 Jul 2014 23:55:17 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23FF1A03D9 for ; Wed, 2 Jul 2014 23:55:16 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so10753076qcx.41 for ; Wed, 02 Jul 2014 23:55:16 -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=A01MNo8VXDVBt9jD6wJC3gz0Ko4J7p+xIPizPqNh+Sw=; b=mS6vFKLMaM2pxSyr42xMI6B3BW+96tghSOQlX47acU/M8t3LuBCzOOHXhU4J7S9xCh XmFwbZ9z3tgvZ4YwL5KO8fIigtdcMbZkHDWgWcVxI5Bwm7i6RjiEwo/ZAAelF0dMDF9Q PQOWilYf6JtHapLc0TIf8uYgVQE05dodHaiTKVDB7Icg/bXbIZznrA1g/SWU5+H6sogs j11J3UVEKKUwdZiOb9O+gm4hFFPEP555k4nvn7TsIgOLuXvSdWShgd16MMRJPtANJZBx Eh6nGRmKKHKBMLy3dYRN34FUcuTjk5voy8TnSAmcVTH/5qz964lL3ir8XmcL5PogJ997 /ung== X-Received: by 10.224.60.137 with SMTP id p9mr4426315qah.70.1404370516089; Wed, 02 Jul 2014 23:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Wed, 2 Jul 2014 23:54:56 -0700 (PDT) In-Reply-To: References: <53B2BB6A.8070701@fkie.fraunhofer.de> From: Henning Rogge Date: Thu, 3 Jul 2014 08:54:56 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QyQNeiZQt_p6AmF3mpsxlI2oSp4 Cc: "manet@ietf.org" Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 03 Jul 2014 06:55:19 -0000 Hi, I think this change makes sense... it adds some overhead, but it makes it easier to create new extensions which require metric values. I assume that a MT capable node which is configured to use only a single metric could still drop the MPR_TYPES tlv? Henning Rogge On Wed, Jul 2, 2014 at 2:19 PM, Dearlove, Christopher (UK) wrote: > First, I haven't discussed this with my co-author, this is just me. > > I've looked through the draft again, and found a few nits I won't list he= re. But I also looked at Henning's point. > > In short, I think we should make MPR_TYPES compulsory in MT-OLSRv2 TC mes= sages. > > This makes things simpler, Henning's point. Also 7.1.1 describes this TLV= for HELLO messages (second paragraph) but doesn't have an equivalent for T= C messages. That needs adding regardless, this would make what's added simp= ler. Of course there are other places to address, such as the first bullet = in 9.1. > > But that's not my main motivation. Rather I want to use this to protect a= gainst something that is not sensible, but not actually banned, and I could= invent a different extension to use (though the only one I have so far is = forced). > > This is that in non-MT-OLSRv2, a router sends TC messages with metrics of= type LINK_METRIC_TYPE. But it can put other metrics in. They are ignored, = but legal. (Possible extension to use them, advertising in advance of a cha= nge of metric type for some reason I can't think of.) > > So what if a non-MT-OLSRv2 router does that (pointless but legal) thing? = An MT-OLSRv2 router will try using those metrics (of they are of a type it= uses). But the router being non-MT-OLSRv2 won't route using them. > > If we require MT-OLSRv2 routers to put an MPR_TYPES TLV into TC messages,= we can modify 9.2 to use only those metric types advertised in an MPR_TYPE= S TLV, or LINK_METRIC_TYPE if none, avoiding this (theoretical, but let's d= o it right) problem. > > If this makes sense (and obviously I'd like Thomas and Henning's comments= , plus of course anyone else) I'd consider this as part of the collected WG= LC comments, after which we'll produce a new draft as usual. Unless both pe= ople want it earlier and I find time to do it earlier (which I may well not= ). > > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com] > Sent: 01 July 2014 17:50 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; manet@ietf.org; Christopher Dearlove > Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and= implementation > > ----------------------! WARNING ! ---------------------- This message ori= ginates from outside our organisation, either from an external partner or f= rom the internet. > Consider carefully whether you should click on any links, open any attach= ments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions= on reporting suspicious email messages. > -------------------------------------------------------- > > On Tue, Jul 1, 2014 at 6:24 PM, Dearlove, Christopher (UK) wrote: >> Henning >> >> Great to hear you've been working on this. > > Thank you. > >> I had to dig out the specification to look at the TLV_TYPES issue. And I= started to type that you didn't need to know (though of course it was ther= e as optional to allow you to know). But thinking about it - though not for= long enough, I'm not so sure about that. Unfortunately I don't have any mo= re time today, but definitely let's kick around some cases to test that. > > You only need to know the TLV_TYPES value if you only have link-metric TL= Vs and nothing with an array (e.g. GATEWAY tlv for TCs). But the code-path = to parse this looks a little bit twisted. > >> I'm having a bit of difficulty with the rest of the message. By ATTACHED= _NETWORK do you mean GATEWAY? And I don't understand the following paragrap= h. But let's throw it all in the discussion. > > Yes, I named the API in my code after the data-structures in the > OLSRv2 RFC, thats why I accidentally said "attached network" and not "gat= eway"... GATEWAY is the correct TLV name for Attached Network Set data. > > The rules when you need/don't need a TLV_TYPES tlv in a TC message read l= ike an exception with an exception. > > a) normally you don't need it > b) unless you have Gateway TLVs > c) unless all Gatways TLVs have the same "distance" for each metric (or h= ave single-byte distance values) > > This feels a bit strange... so maybe we could add a couple of examples. > > 1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES tlv) > 2) Multitopology TC with two GATEWAY tlvs and random "distances" (this me= ans it needs a TLV_TYPES tlv) > 3) Multitopology TC with two GATEWAY tlvs, each of them having a multi-by= te "distance" values (but all the same, needs a TLV_TYPES tlv) > 4) Multitopology TC with two GATEWAY tlvs, each of them having only a sin= gle-byte "distance" value (no TLVTYPES tlv) > > maybe even one with a mixture of 3) and 4) (to show you can mix both GATE= WAY tlv variants. > > Henning Rogge > ******************************************************************** > 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 Thu Jul 3 00:32:38 2014 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 9E1EE1A059F for ; Thu, 3 Jul 2014 00:32:35 -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 Z7PlJ7--fD3W for ; Thu, 3 Jul 2014 00:32:33 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC8A1A04AC for ; Thu, 3 Jul 2014 00:32:32 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so1732373wiv.2 for ; Thu, 03 Jul 2014 00:32:31 -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=Rk3UPlAu1BQAgWuqPXRamf89CkE6K5kAPEQy9RMtEzo=; b=PogNCs6CMqQcAs9/RilUc6zHAbzyeTRI3uJk1tU2d1znPzlYWRpaiGFmuHN/ekHc8B oIS+q4/PpJqH2jKdyHYtOQtVYBV8FarE/aDSHDeBL5l46bM5ee13pMdYCuG4958V38sa ufouedW1rhMn1RkolU3MT+lUJzWsy/nv3Xs/NLeMNjopYSITJ51Es2hcR1GGiDNYUYNq gdKJUTmExHSWmVGQZcGyqbgpUUPFWYyao2iO0Uz1eCivf2l4U/5JuZDv0JCBeYkEAIsc PM8pvHFN9HXmKNKtREh6opRM59c9qG7LNtN+P4GLmqBZ3ZRqIAo3/7XLyxPRGOJBuXtZ 7dww== X-Received: by 10.194.58.180 with SMTP id s20mr994925wjq.119.1404372751379; Thu, 03 Jul 2014 00:32:31 -0700 (PDT) Received: from [192.168.254.2] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id cj8sm60236862wjb.5.2014.07.03.00.32.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 00:32:30 -0700 (PDT) References: <53B2BB6A.8070701@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1992B6ED-A52F-479C-9629-CCBD3B2FDA6C@gmail.com> X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Thu, 3 Jul 2014 08:32:28 +0100 To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YnZdJcKySL3mDFg3tpvucubCFW8 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 03 Jul 2014 07:32:35 -0000 It would have to be supporting just the LINK_METRIC_TYPE type. Supporting ju= st one type, but another one, it would still need to include it. Good point.= --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 3 Jul 2014, at 07:54, Henning Rogge wrote: >=20 > Hi, >=20 > I think this change makes sense... it adds some overhead, but it makes > it easier to create new extensions which require metric values. >=20 > I assume that a MT capable node which is configured to use only a > single metric could still drop the MPR_TYPES tlv? >=20 > Henning Rogge >=20 > On Wed, Jul 2, 2014 at 2:19 PM, Dearlove, Christopher (UK) > wrote: >> First, I haven't discussed this with my co-author, this is just me. >>=20 >> I've looked through the draft again, and found a few nits I won't list he= re. But I also looked at Henning's point. >>=20 >> In short, I think we should make MPR_TYPES compulsory in MT-OLSRv2 TC mes= sages. >>=20 >> This makes things simpler, Henning's point. Also 7.1.1 describes this TLV= for HELLO messages (second paragraph) but doesn't have an equivalent for TC= messages. That needs adding regardless, this would make what's added simple= r. Of course there are other places to address, such as the first bullet in 9= .1. >>=20 >> But that's not my main motivation. Rather I want to use this to protect a= gainst something that is not sensible, but not actually banned, and I could i= nvent a different extension to use (though the only one I have so far is for= ced). >>=20 >> This is that in non-MT-OLSRv2, a router sends TC messages with metrics of= type LINK_METRIC_TYPE. But it can put other metrics in. They are ignored, b= ut legal. (Possible extension to use them, advertising in advance of a chang= e of metric type for some reason I can't think of.) >>=20 >> So what if a non-MT-OLSRv2 router does that (pointless but legal) thing? A= n MT-OLSRv2 router will try using those metrics (of they are of a type it u= ses). But the router being non-MT-OLSRv2 won't route using them. >>=20 >> If we require MT-OLSRv2 routers to put an MPR_TYPES TLV into TC messages,= we can modify 9.2 to use only those metric types advertised in an MPR_TYPES= TLV, or LINK_METRIC_TYPE if none, avoiding this (theoretical, but let's do i= t right) problem. >>=20 >> If this makes sense (and obviously I'd like Thomas and Henning's comments= , plus of course anyone else) I'd consider this as part of the collected WGL= C comments, after which we'll produce a new draft as usual. Unless both peop= le want it earlier and I find time to do it earlier (which I may well not). >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Information Assurance Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@gmail.com] >> Sent: 01 July 2014 17:50 >> To: Dearlove, Christopher (UK) >> Cc: Henning Rogge; manet@ietf.org; Christopher Dearlove >> Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and= implementation >>=20 >> ----------------------! WARNING ! ---------------------- This message ori= ginates from outside our organisation, either from an external partner or fr= om the internet. >> Consider carefully whether you should click on any links, open any attach= ments or reply. >> Follow the 'Report Suspicious Emails' link on IT matters for instructions= on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >>> On Tue, Jul 1, 2014 at 6:24 PM, Dearlove, Christopher (UK) wrote: >>> Henning >>>=20 >>> Great to hear you've been working on this. >>=20 >> Thank you. >>=20 >>> I had to dig out the specification to look at the TLV_TYPES issue. And I= started to type that you didn't need to know (though of course it was there= as optional to allow you to know). But thinking about it - though not for l= ong enough, I'm not so sure about that. Unfortunately I don't have any more t= ime today, but definitely let's kick around some cases to test that. >>=20 >> You only need to know the TLV_TYPES value if you only have link-metric TL= Vs and nothing with an array (e.g. GATEWAY tlv for TCs). But the code-path t= o parse this looks a little bit twisted. >>=20 >>> I'm having a bit of difficulty with the rest of the message. By ATTACHED= _NETWORK do you mean GATEWAY? And I don't understand the following paragraph= . But let's throw it all in the discussion. >>=20 >> Yes, I named the API in my code after the data-structures in the >> OLSRv2 RFC, thats why I accidentally said "attached network" and not "gat= eway"... GATEWAY is the correct TLV name for Attached Network Set data. >>=20 >> The rules when you need/don't need a TLV_TYPES tlv in a TC message read l= ike an exception with an exception. >>=20 >> a) normally you don't need it >> b) unless you have Gateway TLVs >> c) unless all Gatways TLVs have the same "distance" for each metric (or h= ave single-byte distance values) >>=20 >> This feels a bit strange... so maybe we could add a couple of examples. >>=20 >> 1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES tlv)= >> 2) Multitopology TC with two GATEWAY tlvs and random "distances" (this me= ans it needs a TLV_TYPES tlv) >> 3) Multitopology TC with two GATEWAY tlvs, each of them having a multi-by= te "distance" values (but all the same, needs a TLV_TYPES tlv) >> 4) Multitopology TC with two GATEWAY tlvs, each of them having only a sin= gle-byte "distance" value (no TLVTYPES tlv) >>=20 >> maybe even one with a mixture of 3) and 4) (to show you can mix both GATE= WAY tlv variants. >>=20 >> Henning Rogge >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jul 3 01:30:34 2014 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 D8ED71A0077 for ; Thu, 3 Jul 2014 01:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 elO9UmKuesXP for ; Thu, 3 Jul 2014 01:30: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 35B011A0318 for ; Thu, 3 Jul 2014 01:30:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,593,1400022000"; d="scan'208";a="383983277" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Jul 2014 09:30:28 +0100 X-IronPort-AV: E=Sophos;i="5.01,593,1400022000"; d="scan'208";a="63465524" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 03 Jul 2014 09:30:28 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.85]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 09:30:28 +0100 From: "Dearlove, Christopher (UK)" To: Christopher Dearlove , Henning Rogge Thread-Topic: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation Thread-Index: AQHPlUyFtvZDq+Y9wUOFM93xHfhXJpuMsPiAgAErEACAAAp9AIAAILZw Date: Thu, 3 Jul 2014 08:30:27 +0000 Message-ID: References: <53B2BB6A.8070701@fkie.fraunhofer.de> <1992B6ED-A52F-479C-9629-CCBD3B2FDA6C@gmail.com> In-Reply-To: <1992B6ED-A52F-479C-9629-CCBD3B2FDA6C@gmail.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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nSuDGVhMQR1I1z8uAVy8Ug4-uIA Cc: "manet@ietf.org" Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation 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, 03 Jul 2014 08:30:33 -0000 In that case, it can (I think) also be allowed to not include it in a HELLO= message. After all, to the outside it just looks like non-MT-OLSRv2. --=20 Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com]=20 Sent: 03 July 2014 08:32 To: Henning Rogge Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and i= mplementation ----------------------! 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. -------------------------------------------------------- It would have to be supporting just the LINK_METRIC_TYPE type. Supporting j= ust one type, but another one, it would still need to include it. Good poin= t. -- Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 3 Jul 2014, at 07:54, Henning Rogge wrote: >=20 > Hi, >=20 > I think this change makes sense... it adds some overhead, but it makes=20 > it easier to create new extensions which require metric values. >=20 > I assume that a MT capable node which is configured to use only a=20 > single metric could still drop the MPR_TYPES tlv? >=20 > Henning Rogge >=20 > On Wed, Jul 2, 2014 at 2:19 PM, Dearlove, Christopher (UK)=20 > wrote: >> First, I haven't discussed this with my co-author, this is just me. >>=20 >> I've looked through the draft again, and found a few nits I won't list h= ere. But I also looked at Henning's point. >>=20 >> In short, I think we should make MPR_TYPES compulsory in MT-OLSRv2 TC me= ssages. >>=20 >> This makes things simpler, Henning's point. Also 7.1.1 describes this TL= V for HELLO messages (second paragraph) but doesn't have an equivalent for = TC messages. That needs adding regardless, this would make what's added sim= pler. Of course there are other places to address, such as the first bullet= in 9.1. >>=20 >> But that's not my main motivation. Rather I want to use this to protect = against something that is not sensible, but not actually banned, and I coul= d invent a different extension to use (though the only one I have so far is= forced). >>=20 >> This is that in non-MT-OLSRv2, a router sends TC messages with=20 >> metrics of type LINK_METRIC_TYPE. But it can put other metrics in.=20 >> They are ignored, but legal. (Possible extension to use them,=20 >> advertising in advance of a change of metric type for some reason I=20 >> can't think of.) >>=20 >> So what if a non-MT-OLSRv2 router does that (pointless but legal) thing?= An MT-OLSRv2 router will try using those metrics (of they are of a type i= t uses). But the router being non-MT-OLSRv2 won't route using them. >>=20 >> If we require MT-OLSRv2 routers to put an MPR_TYPES TLV into TC messages= , we can modify 9.2 to use only those metric types advertised in an MPR_TYP= ES TLV, or LINK_METRIC_TYPE if none, avoiding this (theoretical, but let's = do it right) problem. >>=20 >> If this makes sense (and obviously I'd like Thomas and Henning's comment= s, plus of course anyone else) I'd consider this as part of the collected W= GLC comments, after which we'll produce a new draft as usual. Unless both p= eople want it earlier and I find time to do it earlier (which I may well no= t). >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Information Assurance Group=20 >> Communications, Networks and Image Analysis Capability BAE Systems=20 >> Advanced Technology Centre West Hanningfield Road, Great Baddow,=20 >> Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124=20 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=20 >> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England &=20 >> Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@gmail.com] >> Sent: 01 July 2014 17:50 >> To: Dearlove, Christopher (UK) >> Cc: Henning Rogge; manet@ietf.org; Christopher Dearlove >> Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review=20 >> and implementation >>=20 >> ----------------------! WARNING ! ---------------------- This message or= iginates from outside our organisation, either from an external partner or = from the internet. >> Consider carefully whether you should click on any links, open any attac= hments or reply. >> Follow the 'Report Suspicious Emails' link on IT matters for instruction= s on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >>> On Tue, Jul 1, 2014 at 6:24 PM, Dearlove, Christopher (UK) wrote: >>> Henning >>>=20 >>> Great to hear you've been working on this. >>=20 >> Thank you. >>=20 >>> I had to dig out the specification to look at the TLV_TYPES issue. And = I started to type that you didn't need to know (though of course it was the= re as optional to allow you to know). But thinking about it - though not fo= r long enough, I'm not so sure about that. Unfortunately I don't have any m= ore time today, but definitely let's kick around some cases to test that. >>=20 >> You only need to know the TLV_TYPES value if you only have link-metric T= LVs and nothing with an array (e.g. GATEWAY tlv for TCs). But the code-path= to parse this looks a little bit twisted. >>=20 >>> I'm having a bit of difficulty with the rest of the message. By ATTACHE= D_NETWORK do you mean GATEWAY? And I don't understand the following paragra= ph. But let's throw it all in the discussion. >>=20 >> Yes, I named the API in my code after the data-structures in the >> OLSRv2 RFC, thats why I accidentally said "attached network" and not "ga= teway"... GATEWAY is the correct TLV name for Attached Network Set data. >>=20 >> The rules when you need/don't need a TLV_TYPES tlv in a TC message read = like an exception with an exception. >>=20 >> a) normally you don't need it >> b) unless you have Gateway TLVs >> c) unless all Gatways TLVs have the same "distance" for each metric=20 >> (or have single-byte distance values) >>=20 >> This feels a bit strange... so maybe we could add a couple of examples. >>=20 >> 1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES=20 >> tlv) >> 2) Multitopology TC with two GATEWAY tlvs and random "distances"=20 >> (this means it needs a TLV_TYPES tlv) >> 3) Multitopology TC with two GATEWAY tlvs, each of them having a=20 >> multi-byte "distance" values (but all the same, needs a TLV_TYPES=20 >> tlv) >> 4) Multitopology TC with two GATEWAY tlvs, each of them having only a=20 >> single-byte "distance" value (no TLVTYPES tlv) >>=20 >> maybe even one with a mixture of 3) and 4) (to show you can mix both GAT= EWAY tlv variants. >>=20 >> Henning Rogge >> ******************************************************************** >> This email and any attachments are confidential to the intended=20 >> recipient and may also be privileged. If you are not the intended=20 >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or=20 >> distribute its contents to any other person. >> ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jul 3 02:22:36 2014 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 B86081B280A for ; Thu, 3 Jul 2014 02:22:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bARn5GBboxgD for ; Thu, 3 Jul 2014 02:22:34 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45061A0AB1 for ; Thu, 3 Jul 2014 02:22:33 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s639MVTL012440 for ; Thu, 3 Jul 2014 10:22:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s639MU1L012408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 Jul 2014 10:22:31 +0100 From: "Adrian Farrel" To: Date: Thu, 3 Jul 2014 10:22:25 +0100 Message-ID: <0b7201cf96a0$4ded6110$e9c82330$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+WoEvDuAjZe1jOSeaMdi2EYH8ONA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20794.006 X-TM-AS-Result: No--2.352-10.0-31-10 X-imss-scan-details: No--2.352-10.0-31-10 X-TMASE-MatchedRID: 925uuIfLBwv5fsKY4rK/JCgAQWWdzz5F9yS7vvkvVUYKXKtfi06bFKPF jJEFr+olfeZdJ1XsorgUBfgS1SLQ+AtuKBGekqUpnH7sbImOEBTFT2K0kcK35OdYSOdu3zBVCG3 Hcj6cxSxLPDtO00tAsTSCCIHGaFyOuet5r9Bdhvd06cjxY8Ylm1csa0AGV/Sb+6IMxy/8vznAvp LE+mvX8g== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tE93aoTFnzMNyCMB-VGxICrUQLo Subject: [manet] Errata on RFC 7186 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 09:22:34 -0000 The two errata reports that Thomas just raised seem completely correct and are, presumably, a fumble during the parallel publishing of a set of MANET RFCs. I will combine the two reports into one since that will be a little more obvious for the reader. Thanks, Adrian From nobody Thu Jul 3 02:24:27 2014 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 20B101B2810; Thu, 3 Jul 2014 02:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 YYQB3hFW8i2g; Thu, 3 Jul 2014 02:24:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA81B280D; Thu, 3 Jul 2014 02:24:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C6E9318001B; Thu, 3 Jul 2014 02:24:10 -0700 (PDT) To: T.clausen@computer.org, jiazi@jiaziyi.com, ulrich@herberg.name, T.Clausen@computer.org X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140703092410.C6E9318001B@rfc-editor.org> Date: Thu, 3 Jul 2014 02:24:10 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2cwJRd9jFsrlyZdMvEuzQRMykTY Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Rejected] RFC7186 (4035) 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, 03 Jul 2014 09:24:23 -0000 The following errata report has been rejected for RFC7186, "Security Threats for the Neighborhood Discovery Protocol (NHDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7186&eid=4035 -------------------------------------- Status: Rejected Type: Editorial Reported by: Thomas Clausen Date Reported: 2014-07-03 Rejected by: Adrian Farrel (IESG) Section: GLOBAL Original Text ------------- [RFC7185] Corrected Text -------------- [RFC7183] Notes ----- Related to errata 4034, which corrects the reference in the references section, the actual citation keys (which are RFC7185 in the document) should be corrected to [RFC7183] also. Not quite sure if this should be a separate errata or the two should be combined? --VERIFIER NOTES-- This is rejected as a duplicate of report 4034. That report can be used to capture all of the information required. -------------------------------------- RFC7186 (draft-ietf-manet-nhdp-sec-threats-06) -------------------------------------- Title : Security Threats for the Neighborhood Discovery Protocol (NHDP) Publication Date : April 2014 Author(s) : J. Yi, U. Herberg, T. Clausen Category : INFORMATIONAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Jul 3 06:12:11 2014 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 3CEC01B2978 for ; Thu, 3 Jul 2014 06:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 zCKOwiMVC7cs for ; Thu, 3 Jul 2014 06:12:03 -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 3CFAF1B2955 for ; Thu, 3 Jul 2014 06:12:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,595,1400022000"; d="scan'208";a="384110364" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Jul 2014 14:12:00 +0100 X-IronPort-AV: E=Sophos;i="5.01,595,1400022000"; d="scan'208";a="63530060" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 03 Jul 2014 14:12:00 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.143]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 14:11:57 +0100 From: "Dearlove, Christopher (UK)" To: Juliusz Chroboczek , "Stan Ratliff (sratliff)" Thread-Topic: [manet] draft-ietf-manet-olsrv2-multitopology-02 Thread-Index: AQHPlUvtgnYCP2J2BUy5nE+mbSIHqJuM7AGAgAFhG9A= Date: Thu, 3 Jul 2014 13:11:51 +0000 Message-ID: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> In-Reply-To: <87k37v7m6y.wl.jch@pps.univ-paris-diderot.fr> 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: http://mailarchive.ietf.org/arch/msg/manet/idpXDL--1AMVxlv0HMEGhK6z-oo Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 03 Jul 2014 13:12:07 -0000 Comments below, CMD: Thanks for your comments. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Juliusz Chroboczek Sent: 02 July 2014 17:36 To: Stan Ratliff (sratliff) Cc: manet IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 ----------------------! 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. -------------------------------------------------------- I support publication of this draft as an Experimental RFC. Experimental RFCs are cool. I have one major concern about this draft, and some minor nits. While the title implies that it defines fully general multi-topology routin= g, the actual protocol strongly links the topologies to metric types. I'm = not sure if that's intended. In particular, multi-topology seems like a useful extension to implement ro= uting policies, say "avoid links that don't enforce link-layer encryption" or "avoid routers that belong to Henning". It would seem at first sight th= at I would need to encode such policies in a metric in order to make use of= this extension. CMD: Commented previously, and an ongoing discussion. Minor nits: It would be good to state the invariants enforced and not enforced. I could be wrong, but I understand that the topologies can be different for= different metrics, but every topology must be a subgraph of the topology a= dvertised to non-MT routers. If that's right, that's a useful property to = help the reader get an intuitive feel. CMD: I noted that the mapping packet -> metric (topology) needs to be state= d as well-defined, same at all routers. That belongs in Section 3. CMD: It's not actually necessary for the property you suggest to be true. I= t's only necessary to support the default metric if you can communicate dir= ectly with a non-MT router. And thus you could have a non-default part of t= he network. Simplest (but stupid) case is A - B - C, where B talks to A and= C on different and non-compatible interfaces (say, different frequencies).= Default metric 0, supported by non-MT C. A supports metric types 1 and 2, = B supports metric types 1 and 2 on interface to A and (at least) 0 on inter= face to C. This assumes A and C never talk directly. Slightly more sensible= is A - B - C - D where A, B and C support metric type 1 and B, C and D sup= port metric type 2, on physically different interfaces. D is non-MT. B and = C are doubly connected. 1. Introduction "it would be desirable to be able to use alternative metrics for different = packet routing." Sounds strange. I suggest "for routing different packets= ". CMD: I think more extensive surgery on that sentence would be even better. 3. Applicability Statement I'd like to know whether the data plane mechanism is expected to revert to = a default metric if no route is found to a given destination or not. I assume not (which would confirm my guess that this is policy routing). I'm also a little worried about delegating this mechanism to an external me= chanism. If different routers implement different mechanisms, won't persis= tent routing loops arise? CMD: See above. But it really has to be an external mechanism - it's happen= ing in a different process, typically using concepts (like DSCP - but not t= ied to that) that are outside OLSRv2. It is a management issue, and I need = to check it's mentioned in the management section. 4. Protocol Overview I found this section difficult to read for purely syntactic reasons. "However there may be deployments where routers, that do not implement MT-OLSRv2 (non-MT-OLSRv2 routers), are to participate in a MANET with MT-OLSRv2 routers." Remove both commas. Or perhaps reformulate as "There = may be deployments where both MT-OLSv2 and non-MT-OLSRv2 routers participat= e in a single routing domain" or somesuch. CMD: Iprefer removing the commas (I'm not sure why they are there) as at th= is point we haven't actually defined non-MT-OLSRv2 router. "advertised neighbor status, is maintained per supported neighbor". Remove the comma. CMD: It needs moving rather than removing, before for. "More so than OLSRv2, the use of multiple metric types across the MANET mus= t be managed, by administrative configuration or otherwise." Strange synta= x. CMD: I know what it means, but ... 12. Management considerations It's still not clear to me how the protocol avoids loops if different route= rs map the same DSCP to different metrics. If you're assuming the mapping = is uniform, it should be stated in this section. CMD: Yes, this should be said here as well as in Section 3. Shouldn't the last three bullet points be a single point? CMD: I think what I prefer is that the last two bullets should be sub-bulle= ts of the currently pre-penultimate bullet. -- Juliusz _______________________________________________ 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 Thu Jul 3 06:34:35 2014 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 6316D1B29C9 for ; Thu, 3 Jul 2014 06:34:33 -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 iq8dxYK-UZ7T for ; Thu, 3 Jul 2014 06:34:32 -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 7E0CD1B29C4 for ; Thu, 3 Jul 2014 06:34:32 -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/46573) with ESMTP id s63DYPiv015607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jul 2014 15:34:25 +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/46573) with ESMTP id s63DYPF8025196; Thu, 3 Jul 2014 15:34:25 +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 171ED2C0CA3; Thu, 3 Jul 2014 15:34:25 +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 KZfYvRPEeyk4; Thu, 3 Jul 2014 15:34:24 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0F9B82C0CA6; Thu, 3 Jul 2014 15:34:24 +0200 (CEST) Date: Thu, 03 Jul 2014 15:34:31 +0200 Message-ID: <87simiwopk.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Dearlove, Christopher (UK)" In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.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]); Thu, 03 Jul 2014 15:34:25 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 03 Jul 2014 15:34:25 +0200 (CEST) X-Miltered: at korolev with ID 53B55BE1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53B55BE1.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B55BE1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53B55BE1.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 : 53B55BE1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53B55BE1.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: http://mailarchive.ietf.org/arch/msg/manet/OUxt-jwyp0yJXc0SxdEl5EzCBco Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 03 Jul 2014 13:34:33 -0000 >> I'm also a little worried about delegating this mechanism to an external >> mechanism. If different routers implement different mechanisms, won't >> persistent routing loops arise? > it really has to be an external mechanism - it's happening in > a different process, typically using concepts [...] that are outside > OLSRv2. I was thinking about advertising the mapping over the protocol, and refusing to use a metric for which two neighbours have different mappings. But that's probably overdoing it at this stage -- only implementation experience will tell if the requirement to manually ensure uniformity is too onerous, and publishing this as Experimental seems like a good way to encourage experimentation. -- Juliusz P.S. Wow, all your e-mails get defaced like that? From nobody Thu Jul 3 06:46:22 2014 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 480601B29D9 for ; Thu, 3 Jul 2014 06:46:20 -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 lucqR_JN5B-Q for ; Thu, 3 Jul 2014 06:46:19 -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 83A591B29D4 for ; Thu, 3 Jul 2014 06:46:19 -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/46573) with ESMTP id s63DkFVF022112; Thu, 3 Jul 2014 15:46:15 +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 ED1A32C0CA9; Thu, 3 Jul 2014 15:46:14 +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 1nP7Qmc2IUGO; Thu, 3 Jul 2014 15:46:03 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2082E2C0CAB; Thu, 3 Jul 2014 15:46:03 +0200 (CEST) Date: Thu, 03 Jul 2014 15:46:09 +0200 Message-ID: <87pphmwo66.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Dearlove, Christopher (UK)" In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> <87k37v7m6y.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, 03 Jul 2014 15:46:15 +0200 (CEST) X-Miltered: at korolev with ID 53B55EA7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B55EA7.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 : 53B55EA7.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: http://mailarchive.ietf.org/arch/msg/manet/IXDZ35OXZ4Spcda4pEmX0fXrX9k Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 03 Jul 2014 13:46:20 -0000 > CMD: It's not actually necessary for the property you suggest to be true... I got it, thanks. I think it would be helpful to include a slightly more abstract version of this explanation in the introduction to the document. -- Juliusz From nobody Thu Jul 3 08:04:04 2014 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 9431A1A04E7 for ; Thu, 3 Jul 2014 00:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 51RcCaXUvfoQ for ; Thu, 3 Jul 2014 00:00:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB21A0AC1 for ; Thu, 3 Jul 2014 00:00:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2E74A18001B; Thu, 3 Jul 2014 00:00:29 -0700 (PDT) To: jiazi@jiaziyi.com, ulrich@herberg.name, T.Clausen@computer.org, akatlas@gmail.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140703070029.2E74A18001B@rfc-editor.org> Date: Thu, 3 Jul 2014 00:00:29 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qsYu68C3CrhrIsZChXcblbl362U X-Mailman-Approved-At: Thu, 03 Jul 2014 08:03:51 -0700 Cc: manet@ietf.org, T.clausen@computer.org, rfc-editor@rfc-editor.org Subject: [manet] [Editorial Errata Reported] RFC7186 (4034) 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, 03 Jul 2014 07:00:52 -0000 The following errata report has been submitted for RFC7186, "Security Threats for the Neighborhood Discovery Protocol (NHDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7186&eid=4034 -------------------------------------- Type: Editorial Reported by: Thomas Clausen Section: 9.2 Original Text ------------- [RFC7185] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7185, April 2014. Corrected Text -------------- [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014. Notes ----- Apparently, the wrong RFC number was cited: RFC7185 is "Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)" Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7186 (draft-ietf-manet-nhdp-sec-threats-06) -------------------------------------- Title : Security Threats for the Neighborhood Discovery Protocol (NHDP) Publication Date : April 2014 Author(s) : J. Yi, U. Herberg, T. Clausen Category : INFORMATIONAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Jul 3 08:04:05 2014 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 A9D911A0AB4 for ; Thu, 3 Jul 2014 00:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 QmCVPtXRbgOw for ; Thu, 3 Jul 2014 00:03:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A42C91A04E7 for ; Thu, 3 Jul 2014 00:03:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C5E7B18001B; Thu, 3 Jul 2014 00:03:00 -0700 (PDT) To: jiazi@jiaziyi.com, ulrich@herberg.name, T.Clausen@computer.org, akatlas@gmail.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140703070300.C5E7B18001B@rfc-editor.org> Date: Thu, 3 Jul 2014 00:03:00 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BJW-QWvdNDFr6bBclkzcVhu2qFU X-Mailman-Approved-At: Thu, 03 Jul 2014 08:03:53 -0700 Cc: manet@ietf.org, T.clausen@computer.org, rfc-editor@rfc-editor.org Subject: [manet] [Editorial Errata Reported] RFC7186 (4035) 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, 03 Jul 2014 07:03:12 -0000 The following errata report has been submitted for RFC7186, "Security Threats for the Neighborhood Discovery Protocol (NHDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7186&eid=4035 -------------------------------------- Type: Editorial Reported by: Thomas Clausen Section: GLOBAL Original Text ------------- [RFC7185] Corrected Text -------------- [RFC7183] Notes ----- Related to errata 4034, which corrects the reference in the references section, the actual citation keys (which are RFC7185 in the document) should be corrected to [RFC7183] also. Not quite sure if this should be a separate errata or the two should be combined? Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7186 (draft-ietf-manet-nhdp-sec-threats-06) -------------------------------------- Title : Security Threats for the Neighborhood Discovery Protocol (NHDP) Publication Date : April 2014 Author(s) : J. Yi, U. Herberg, T. Clausen Category : INFORMATIONAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Jul 4 06:38:14 2014 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 CE2CB1B2D3D for ; Fri, 4 Jul 2014 06:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 LLqu1EMIT0zc for ; Fri, 4 Jul 2014 06:38:11 -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 545AC1B2D2C for ; Fri, 4 Jul 2014 06:38:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,601,1400022000"; d="scan'208,217";a="384406339" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Jul 2014 14:38:08 +0100 X-IronPort-AV: E=Sophos; i="5.01,601,1400022000"; d="scan'208,217"; a="63677680" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 04 Jul 2014 14:38:08 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.144]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Fri, 4 Jul 2014 14:38:08 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: Topologies and Metrics Thread-Index: Ac+XjEhKNmJK6bqYQw2Cxxdeg+Rvdw== Date: Fri, 4 Jul 2014 13:38:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40C6390CGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GUvjMqp16YFz4d7EMRkkFMWEN8c Subject: [manet] Topologies and Metrics 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, 04 Jul 2014 13:38:13 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40C6390CGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable The more I think about this, the more I believe that the correct approach i= s to go with what we currently have, topology =3D metric, in the current Ex= perimental draft. This gives us something where we don't try to make a rush= ed approach to whether we can split the concepts well, that we can implemen= t more easily and experiment with, in particular to find out how useful it = is. The only downside is possibly larger messages. We can then later, if someone comes up with a good idea that we can kick ar= ound, update to a new Experimental RFC, or not if nothing good comes along.= Otherwise we run the risk of not taking something that (I hope) is good to= day rather than the possibility of something better later. Without throwing= away that latter possibility. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40C6390CGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

The more I think about this, the more I believe that= the correct approach is to go with what we currently have, topology =3D me= tric, in the current Experimental draft. This gives us something where we d= on’t try to make a rushed approach to whether we can split the concepts well, that we can implement more easily = and experiment with, in particular to find out how useful it is. The only d= ownside is possibly larger messages.

 

We can then later, if someone comes up with a good i= dea that we can kick around, update to a new Experimental RFC, or not if no= thing good comes along. Otherwise we run the risk of not taking something t= hat (I hope) is good today rather than the possibility of something better later. Without throwing away that= latter possibility.

 

-- <= /p>

Christopher Dearlove

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

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

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

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40C6390CGLKXM0002VGREEN_-- From nobody Fri Jul 4 06:59:09 2014 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 34AF81B299B for ; Fri, 4 Jul 2014 06:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 9iwHKVQ1CrgB for ; Fri, 4 Jul 2014 06:59:07 -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 945201B2998 for ; Fri, 4 Jul 2014 06:59:06 -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/46573) with ESMTP id s64Dx1P9032588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jul 2014 15:59:01 +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/46573) with ESMTP id s64Dx1q8022259; Fri, 4 Jul 2014 15:59:01 +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 5AF582C116E; Fri, 4 Jul 2014 15:59:01 +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 rmvjmaXDlBKg; Fri, 4 Jul 2014 15:59:00 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5FF792C116D; Fri, 4 Jul 2014 15:59:00 +0200 (CEST) Date: Fri, 04 Jul 2014 15:59:00 +0200 Message-ID: <87wqbtgr8b.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Dearlove, Christopher (UK)" 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]); Fri, 04 Jul 2014 15:59:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 04 Jul 2014 15:59:01 +0200 (CEST) X-Miltered: at korolev with ID 53B6B325.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53B6B325.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B6B325.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53B6B325.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 : 53B6B325.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53B6B325.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: http://mailarchive.ietf.org/arch/msg/manet/u7Do4HPP8LA26DEHIm_E3FnjqTc Cc: "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 13:59:08 -0000 > The more I think about this, the more I believe that the correct approach is > to go with what we currently have, topology = metric, in the current > Experimental draft. It's experimental. There's certainly space for multiple simultaneous experiments. -- Juliusz From nobody Fri Jul 4 07:08:03 2014 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 6F4ED1B2978 for ; Fri, 4 Jul 2014 07:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, 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 EcHNdTL7SF1H for ; Fri, 4 Jul 2014 07:08:00 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAB41B2971 for ; Fri, 4 Jul 2014 07:07:59 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so1752819wes.31 for ; Fri, 04 Jul 2014 07:07:58 -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=DJwNTVbiVIhJoizq6jimaenoqocyPTQmD43ZKXWx8s8=; b=bxiiyBxPqAUXJn1+iFDm6YyO+x9OTQ9FyuYtKK8gOC/aU22vYKL++q4RWOLl18m6fR YgEhcuNwHwTC/lIapflueJH7Uwezmtf1lz3xD0hqDilX9ZqQJdUbM9LTiuXkmaUg2/Dh IVgl034KRzgG506fGmlnDdTBdsqEpDXU9QGrI0ilO9FhYBNwSYx5hWr8Srm6+WAAosFV 71l+oDitYLXvnaMYmYJ3/GW4QNskUG+PanHJm+sm/3UapiludRdQb2sftl/UnKe+UH19 kpyYnLanD5uLkv+t76YrrR3mGVmqW8YBqTACmyg+w0sK5T4F1n6tg5z+AwG3ijaldQ6b TBbQ== X-Received: by 10.194.190.78 with SMTP id go14mr3309925wjc.128.1404482877823; Fri, 04 Jul 2014 07:07:57 -0700 (PDT) Received: from [10.7.121.110] (dab-rcn1-h-1-8.dab.02.net. [82.132.246.244]) by mx.google.com with ESMTPSA id do5sm79608331wib.16.2014.07.04.07.07.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 07:07:57 -0700 (PDT) References: <87wqbtgr8b.wl.jch@pps.univ-paris-diderot.fr> Mime-Version: 1.0 (1.0) In-Reply-To: <87wqbtgr8b.wl.jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Fri, 4 Jul 2014 15:07:53 +0100 To: Juliusz Chroboczek Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pPvRrhQqT9qq5GCOi5T5xVMTJeQ Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 14:08:01 -0000 Indeed, though I think starting with this one (as Henning already has) is wh= at I'd do. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 4 Jul 2014, at 14:59, Juliusz Chroboczek w= rote: >> The more I think about this, the more I believe that the correct approach= is >> to go with what we currently have, topology =3D metric, in the current >> Experimental draft. >=20 > It's experimental. There's certainly space for multiple simultaneous > experiments. >=20 > -- Juliusz >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Jul 4 07:12:24 2014 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 01D2A1B29A3 for ; Fri, 4 Jul 2014 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5TrgA7Uky5BV for ; Fri, 4 Jul 2014 07:12:16 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A271B29A0 for ; Fri, 4 Jul 2014 07:12:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id ED02525A8B; Fri, 4 Jul 2014 07:12:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 6623C25A8A; Fri, 4 Jul 2014 07:12:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D6C0C31-3377-4CE4-85EC-6F2506E069A6" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Fri, 4 Jul 2014 16:12:10 +0200 Message-Id: <322BB165-0B26-41D7-B7A4-71CFBC5D5769@thomasclausen.org> References: To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uHVd8SRFY-zFZMCLqxFgUwi_gsE Cc: "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 14:12:18 -0000 --Apple-Mail=_2D6C0C31-3377-4CE4-85EC-6F2506E069A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chris, all, On Jul 4, 2014, at 15:38, Dearlove, Christopher (UK) = wrote: > The more I think about this, the more I believe that the correct = approach is to go with what we currently have, topology =3D metric, in = the current Experimental draft. This gives us something where we don=92t = try to make a rushed approach to whether we can split the concepts well, = that we can implement more easily and experiment with, in particular to = find out how useful it is. The only downside is possibly larger = messages. > =20 > We can then later, if someone comes up with a good idea that we can = kick around, update to a new Experimental RFC, or not if nothing good = comes along. Otherwise we run the risk of not taking something that (I = hope) is good today rather than the possibility of something better = later. Without throwing away that latter possibility. I fully agree with you on the above. A bit of a backstory might be in = order=85. When the initial versions of this I-D were posted, the authors (together = and apart) tried to work out different ways of separating =93metric=94 = and =93topology=94 =97 turns out that a lot of the =93simple, easy=94 = (as well as not-so-simple and a good deal harder) approaches don=92t = work, and that those that might (emphasis on might) work were quite = horrible.... Contemplating the =93deployment space=94 that I know of, I think that = what we came up with in this specification is a reasonable compromise: = considering the =93metrics=94 as =93topology type=94 extending the = administratively assigned metrics code-point space. The advantage is that we know it works (yes, there=92s running code), = and is fairly clean and simple. As Chris says, this is experimental - i.e., non-prescriptive. The idea = is to get more experiences with multi-topology routing. Part of that = experience will (I hope) lead to an epiphany as to how to do something = that=92s better (or a realization that we either need no more, or can=92t = do better). That=92s when we should spin a new either experimental or PS = version. Thomas > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 --Apple-Mail=_2D6C0C31-3377-4CE4-85EC-6F2506E069A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Chris, = all,

On Jul 4, 2014, at 15:38, Dearlove, Christopher = (UK) <chris.dearlove@baesystems.co= m> wrote:

The more I think = about this, the more I believe that the correct approach is to go with = what we currently have, topology =3D metric, in the current Experimental = draft. This gives us something where we don=92t try to make a rushed = approach to whether we can split the concepts well, that we can = implement more easily and experiment with, in particular to find out how = useful it is. The only downside is possibly larger = messages.
 
We can = then later, if someone comes up with a good idea that we can kick = around, update to a new Experimental RFC, or not if nothing good comes = along. Otherwise we run the risk of not taking something that (I hope) = is good today rather than the possibility of something better later. = Without throwing away that latter = possibility.

I fully agree = with you on the above. A bit of a backstory might be in = order=85.

When the initial versions of this I-D = were posted, the authors (together and apart) tried to work out = different ways of separating =93metric=94 and =93topology=94 =97 turns = out that a lot of the =93simple, easy=94 (as well as not-so-simple and a = good deal harder) approaches don=92t work, and that those that might = (emphasis on might) work were quite = horrible....

Contemplating the =93deployment = space=94 that I know of, I think that what we came up with in this = specification is a reasonable compromise: considering the =93metrics=94 = as =93topology type=94 extending the administratively assigned metrics = code-point space.

The advantage is that we know = it works (yes, there=92s running code), and is fairly clean and = simple.

As Chris says, this is experimental - = i.e., non-prescriptive. The idea is to get more experiences with = multi-topology routing. Part of that experience will (I hope) lead to an = epiphany as to how to do something that=92s better (or a realization = that we either need no more, or can=92t do better). That=92s when we = should spin a new either experimental or PS = version.

Thomas



--
Christopher Dearlove
Senior Principal = Engineer, Information Assurance Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

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

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


= --Apple-Mail=_2D6C0C31-3377-4CE4-85EC-6F2506E069A6-- From nobody Fri Jul 4 07:19:40 2014 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 9937B1B2850; Fri, 4 Jul 2014 07:19:37 -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 H0fF1DucdrPL; Fri, 4 Jul 2014 07:19:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 792161B29B9; Fri, 4 Jul 2014 07:19:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704141934.7303.83520.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 07:19:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_aRLK4RCWcFB3Qt5MboSFkdyO0E Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-03.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: Fri, 04 Jul 2014 14:19:38 -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 : Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-olsrv2-multitopology-03.txt Pages : 20 Date : 2014-07-04 Abstract: This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multitopology-03 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 Jul 4 07:23:07 2014 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 978771B2C6B for ; Fri, 4 Jul 2014 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ni7alst4njFp for ; Fri, 4 Jul 2014 07:23:01 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B261B29C5 for ; Fri, 4 Jul 2014 07:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 9186F25B56 for ; Fri, 4 Jul 2014 07:23:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 835A725B57 for ; Fri, 4 Jul 2014 07:23:00 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_43F3128C-0191-4A82-8921-3068051F5086" Date: Fri, 4 Jul 2014 16:22:57 +0200 References: <20140704141934.7303.86168.idtracker@ietfa.amsl.com> To: manet IETF Message-Id: <70FFD58F-933D-4EF6-8854-FFE706F30779@thomasclausen.org> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xKKGEeVFqFrbqlQkVlmQ2Ry9Gnw Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-multitopology-03.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, 04 Jul 2014 14:23:04 -0000 --Apple-Mail=_43F3128C-0191-4A82-8921-3068051F5086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, We thought that we=92d spin a revision with the comments received so far = - still, within the metrics=3D=3Dtopology framework. A big thank you to those who=92ve offered constructive comments, we hope = that we=92ve capture them in the document (and you, in the = acknowledgements). For the authors, Thomas Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-manet-olsrv2-multitopology-03.txt > Date: July 4, 2014 at 16:19:34 GMT+2 > To: Thomas Heide Clausen , "Christopher = Dearlove" , "Thomas H. Clausen" = , Christopher Dearlove = >=20 >=20 > A new version of I-D, draft-ietf-manet-olsrv2-multitopology-03.txt > has been successfully submitted by Thomas Heide Clausen and posted to = the > IETF repository. >=20 > Name: draft-ietf-manet-olsrv2-multitopology > Revision: 03 > Title: Multi-Topology Extension for the Optimized Link = State Routing Protocol version 2 (OLSRv2) > Document date: 2014-07-04 > Group: manet > Pages: 20 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-multitopology-= 03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multitopology-0= 3 >=20 > Abstract: > This specification describes an extension to the Optimized Link = State > Routing Protocol version 2 (OLSRv2) to support multiple routing > topologies, while retaining interoperability with OLSRv2 routers = that > do not implement this extension. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_43F3128C-0191-4A82-8921-3068051F5086 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 All,

We thought that we=92d spin = a revision with the comments received so far - still, within the = metrics=3D=3Dtopology framework.

A big thank = you to those who=92ve offered constructive comments, we hope that we=92ve = capture them in the document (and you, in the = acknowledgements).

For the = authors,

Thomas

Begin forwarded message:

Subject: = New Version = Notification for = draft-ietf-manet-olsrv2-multitopology-03.txt
Date: July 4, 2014 at 16:19:34 = GMT+2
To: = Thomas Heide Clausen = <t.clausen@computer.org>, = "Christopher Dearlove" <chris.dearlove@baesystems.co= m>, "Thomas H. Clausen" <T.Clausen@computer.org>, = Christopher Dearlove <chris.dearlove@baesystems.co= m>


A new version of I-D, = draft-ietf-manet-olsrv2-multitopology-03.txt
has been successfully = submitted by Thomas Heide Clausen and posted to the
IETF = repository.

Name: = draft-ietf-manet-olsrv2-multitopology
Revision: = 03
Title: Multi-Topology Extension for the = Optimized Link State Routing Protocol version 2 (OLSRv2)
Document = date: = 2014-07-04
Group: manet
Pages: = 20
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv= 2-multitopology-03.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopol= ogy/
Htmlized:       http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-03=
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mult= itopology-03

Abstract:
  This specification = describes an extension to the Optimized Link State
=   Routing Protocol version 2 (OLSRv2) to support multiple = routing
  topologies, while retaining interoperability = with OLSRv2 routers that
  do not implement this = extension.




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

The IETF = Secretariat


= --Apple-Mail=_43F3128C-0191-4A82-8921-3068051F5086-- From nobody Fri Jul 4 07:27:18 2014 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 25DFC1B2C9E for ; Fri, 4 Jul 2014 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 zoenN8oSUGM3 for ; Fri, 4 Jul 2014 07:27:16 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1911B2C9D for ; Fri, 4 Jul 2014 07:27:16 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so3996678wib.12 for ; Fri, 04 Jul 2014 07:27:14 -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=tIAc1N7ILrhtNQ4KlKtF/u3wZDwyO0B3qS6BPXCLv+Y=; b=ZuO5MUOzKCRIWIrXdS1fF2zkBQWtHkRRVk1G0cTEttLymCquPysI58HLQt09p6vt31 foXM77yH7JIrXWxGxiccJ51bLJidL1vFS9HlvUT/ENV/vwuZV5Qxmbym21QOm7NEAC0/ b/QnjkY9frq6Gb51zuUW33FwQXX0WXgkSMMVw0qhdk0UCnDe4/th1ngt50B0XYy6K67r opXVfzZCrkkVDdx0+R1+gwk6anVl/pdtO2/Kxxtk/73SWDycBT+p47+Wk6L7FCw3l1yW HcpgT8EF6jSTfzoMpaTqVJzYdaG9hDo7EplCCMmVlNBu0kBMuP5BFS9em3zOvsns+OPC mtzw== X-Received: by 10.180.73.106 with SMTP id k10mr56189875wiv.11.1404484034901; Fri, 04 Jul 2014 07:27:14 -0700 (PDT) Received: from [10.7.121.110] (dab-rcn1-h-1-8.dab.02.net. [82.132.246.244]) by mx.google.com with ESMTPSA id pj4sm17545932wic.12.2014.07.04.07.27.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 07:27:14 -0700 (PDT) References: <20140704141934.7303.86168.idtracker@ietfa.amsl.com> <70FFD58F-933D-4EF6-8854-FFE706F30779@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: <70FFD58F-933D-4EF6-8854-FFE706F30779@thomasclausen.org> Content-Type: multipart/alternative; boundary=Apple-Mail-25DDEBCD-CAAA-439D-982A-063F89F5F9B3 Content-Transfer-Encoding: 7bit Message-Id: <37FA26DE-17BD-489B-A06C-39F488DC4C93@gmail.com> X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Fri, 4 Jul 2014 15:27:06 +0100 To: Thomas Clausen Archived-At: http://mailarchive.ietf.org/arch/msg/manet/iwehJxEpRY9z--88vnBh1_DINM8 Cc: manet IETF Subject: Re: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-multitopology-03.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, 04 Jul 2014 14:27:18 -0000 --Apple-Mail-25DDEBCD-CAAA-439D-982A-063F89F5F9B3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What Thomas said. If you think we've missed a comment (especially if your na= me isn't in the acknowledgements, as we then likely have missed - I don't re= call any comments not quite enough to ack, but worth doing, such as an odd t= ypo) please let us have a pointer or them again. Or of course anything else.= --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 4 Jul 2014, at 15:22, Thomas Clausen wrote: >=20 > All, >=20 > We thought that we=E2=80=99d spin a revision with the comments received so= far - still, within the metrics=3D=3Dtopology framework. >=20 > A big thank you to those who=E2=80=99ve offered constructive comments, we h= ope that we=E2=80=99ve capture them in the document (and you, in the acknowl= edgements). >=20 > For the authors, >=20 > Thomas >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-ietf-manet-olsrv2-multitopolo= gy-03.txt >> Date: July 4, 2014 at 16:19:34 GMT+2 >> To: Thomas Heide Clausen , "Christopher Dearlove"= , "Thomas H. Clausen" , Christopher Dearlove >>=20 >>=20 >> A new version of I-D, draft-ietf-manet-olsrv2-multitopology-03.txt >> has been successfully submitted by Thomas Heide Clausen and posted to the= >> IETF repository. >>=20 >> Name: draft-ietf-manet-olsrv2-multitopology >> Revision: 03 >> Title: Multi-Topology Extension for the Optimized Link Sta= te Routing Protocol version 2 (OLSRv2) >> Document date: 2014-07-04 >> Group: manet >> Pages: 20 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr= v2-multitopology-03.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-= multitopology/ >> Htmlized: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multit= opology-03 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv= 2-multitopology-03 >>=20 >> Abstract: >> This specification describes an extension to the Optimized Link State >> Routing Protocol version 2 (OLSRv2) to support multiple routing >> topologies, while retaining interoperability with OLSRv2 routers that >> do not implement this extension. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-25DDEBCD-CAAA-439D-982A-063F89F5F9B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What Thomas said. If you think we've m= issed a comment (especially if your name isn't in the acknowledgements, as w= e then likely have missed - I don't recall any comments not quite enough to a= ck, but worth doing, such as an odd typo) please let us have a pointer or th= em again. Or of course anything else.

-- 
Christopher Dearlo= ve

On 4 J= ul 2014, at 15:22, Thomas Clausen <ietf@thomasclausen.org> wrote:

All,

We thought that we=E2=80=99d spin a rev= ision with the comments received so far - still, within the metrics=3D=3Dtop= ology framework.

A big thank you to those who=E2=80= =99ve offered constructive comments, we hope that we=E2=80=99ve capture them= in the document (and you, in the acknowledgements).

For the authors,

Thomas

=

Begin forwarded message:

Subject: New Version Notification for draft-ietf-manet-= olsrv2-multitopology-03.txt
Date: July 4, 2014 at 16:19:34 GMT+2
To: Thoma= s Heide Clausen <t.clausen@comp= uter.org>, "Christopher Dearlove" <chris.dearlove@baesystems.com>, "Thomas H. Clausen"= <T.Clausen@computer.org>= ;, Christopher Dearlove <chris.dearlove@baesystems.com>


A new ve= rsion of I-D, draft-ietf-manet-olsrv2-multitopology-03.txt
has been succe= ssfully submitted by Thomas Heide Clausen and posted to the
IETF reposito= ry.

Name:= draft-ietf-manet-olsrv2-multitopology
Revision: 03
Title: Multi-Topology Extension for= the Optimized Link State Routing Protocol version 2 (OLSRv2)
Document da= te: 2014= -07-04
Group:= manet
Pages:= = 20
URL:          &nb= sp; http://www.ietf.org/internet-drafts/draft-ietf-man= et-olsrv2-multitopology-03.txt
Status:      =    https://datatracker.ietf.org/doc/draft-ietf-manet-= olsrv2-multitopology/
Htmlized:       <= a href=3D"http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-0= 3">http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-03Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multitopology-0= 3

Abstract:
  This specification describes an exten= sion to the Optimized Link State
  Routing Protocol version 2 (= OLSRv2) to support multiple routing
  topologies, while retain= ing interoperability with OLSRv2 routers that
  do not impleme= nt this extension.




Please note that it may take a couple o= f minutes from the time of submission
until the htmlized version and diff= are available at tools.ietf.org.
<= br>The IETF Secretariat


______________________________= _________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet
= --Apple-Mail-25DDEBCD-CAAA-439D-982A-063F89F5F9B3-- From nobody Fri Jul 4 07:49:28 2014 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 7FBD31B2A1C for ; Fri, 4 Jul 2014 07:49:26 -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 kj81VHcZqbyK for ; Fri, 4 Jul 2014 07:49:25 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800161B29B5 for ; Fri, 4 Jul 2014 07:49:25 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so1566226qcy.18 for ; Fri, 04 Jul 2014 07:49:24 -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=JuZ3rGlyfbIaD9dkYLNP7KxX2uakBBiK6anBO9eqp1U=; b=kdqjMQSHWZAOr+i22vUAKfaiYRHu1quFJxaHPP0UpEdcWnsfsmn9TAtWmaSBeW9YoM Tgt+FJ5kgRO49OkUl2zF/QSCUlm61wm5dzSJo81/BYeQi5U56OgZ2I8Mp0GVPjixWpA8 HFWbwggHxMhBND5HZU56LvloyCkc06lSwBCARSsRVpPHwsLkSrujMKGH77RNM6I2K8GK e1EeUU9DCgsYOxxetRNaVd/ZzZhaxg6g4tokxzuXx7/AdO3OYjmcIfOXwgV7rQJDKNwE y3by6wWAP6p6M/PIUM83liNXpBT4gO1QUxWuq9KOi5+aPf+Ypdo2STxVob+6OmfmxWFS dZrA== X-Received: by 10.224.137.9 with SMTP id u9mr20250126qat.24.1404485364763; Fri, 04 Jul 2014 07:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Fri, 4 Jul 2014 07:49:04 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 4 Jul 2014 16:49:04 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nPlaEQ8OjuAL9VGfyYG0mh9004U Cc: "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 14:49:26 -0000 On Fri, Jul 4, 2014 at 3:38 PM, Dearlove, Christopher (UK) wrote: > We can then later, if someone comes up with a good idea that we can kick > around, update to a new Experimental RFC, or not if nothing good comes > along. Otherwise we run the risk of not taking something that (I hope) is > good today rather than the possibility of something better later. Without > throwing away that latter possibility. I have no problem with this... the new experimental draft should only be "compatible" with this one, so we can combine both of them. Henning From nobody Fri Jul 4 08:21:04 2014 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 1BAFC1B29B9 for ; Fri, 4 Jul 2014 08:21:00 -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 bLT__TfHVYX6 for ; Fri, 4 Jul 2014 08:20:54 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EF41B29F8 for ; Fri, 4 Jul 2014 08:20:52 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so13210343wiv.2 for ; Fri, 04 Jul 2014 08:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:references:from :mime-version:in-reply-to:message-id:date:cc:to; bh=mAMGXcP9CimTRakgIjLfFVHKe8b4Hte5KcqLFRTvimw=; b=tFWNU5JU8dR6ReuBk4pe92ZhrrLREBFjVwnY+aJzGRmubREiqAiIZ+HYlzZzvWxRO1 n2g4aoX/Yava+fyvAvdsS8sTan0RoPRwXb/c1l6erR9cd90Peupz7zyFecQaY9DcmIUI JoDCmDuEXSdWkxITY9ivdK04twfGk2ME+3d44ETNFzhWdTX3FO2MIkNrhXYthbg2h8e2 RR7/VAC7+Yjkhqg1g4eXY0xr9PJR0jAWJW1Ee+UyY7aFlpzbKbu/6HBqukUCoxi9tWWL J4rAo73kkfxTN2FFVURIETqQ1KMnniTeTXnbP42dX7pZbHSoIFJ5dlZEiEiiirhXxofG QpQA== X-Received: by 10.194.71.12 with SMTP id q12mr13176724wju.5.1404487249484; Fri, 04 Jul 2014 08:20:49 -0700 (PDT) Received: from [10.7.121.110] (dab-rcn1-h-23-10.dab.02.net. [82.132.247.188]) by mx.google.com with ESMTPSA id gc5sm80305199wic.6.2014.07.04.08.20.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 08:20:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: From: Christopher Dearlove Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <93B5A02D-A03D-4267-8284-2EC9CE266D0F@gmail.com> Date: Fri, 4 Jul 2014 16:12:52 +0100 To: Henning Rogge X-Mailer: iPhone Mail (11D201) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9241ozMPBn7cpTbAVsT3_BnO6bA Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 15:21:01 -0000 A hypothetical replacement draft could even be incompatible with this one, a= lthough compatibility would be ideal of course. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 4 Jul 2014, at 15:49, Henning Rogge wrote: >=20 > On Fri, Jul 4, 2014 at 3:38 PM, Dearlove, Christopher (UK) > wrote: >> We can then later, if someone comes up with a good idea that we can kick >> around, update to a new Experimental RFC, or not if nothing good comes >> along. Otherwise we run the risk of not taking something that (I hope) is= >> good today rather than the possibility of something better later. Without= >> throwing away that latter possibility. >=20 > I have no problem with this... the new experimental draft should only > be "compatible" with this one, so we can combine both of them. >=20 > Henning >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Jul 4 08:40:34 2014 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 85C891B2DA7 for ; Fri, 4 Jul 2014 08:40:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 EWBBOkI65xUE for ; Fri, 4 Jul 2014 08:40:26 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E42B1B2AD7 for ; Fri, 4 Jul 2014 08:40:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id D971426241; Fri, 4 Jul 2014 08:40:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 996B62621B; Fri, 4 Jul 2014 08:39:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: <93B5A02D-A03D-4267-8284-2EC9CE266D0F@gmail.com> Date: Fri, 4 Jul 2014 17:39:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23FB8E43-54EA-4BFC-A24C-87A516F76480@thomasclausen.org> References: <93B5A02D-A03D-4267-8284-2EC9CE266D0F@gmail.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/dRdvSrciy0y7sdW88TyBLSnS6dg Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 15:40:31 -0000 On Jul 4, 2014, at 17:12, Christopher Dearlove = wrote: > A hypothetical replacement draft could even be incompatible with this = one, although compatibility would be ideal of course. >=20 I=92m guessing that what Henning means by =93compatible=94 means =93the = two can run on the same devices at the same time and provide = complementary functionalities/services=94.=20 I=92m guessing that what Chris means when he talks about a =93replacement = draft=94 is that =93interoperability between old and new would be good, = but not required=94 > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 >> On 4 Jul 2014, at 15:49, Henning Rogge wrote: >>=20 >> On Fri, Jul 4, 2014 at 3:38 PM, Dearlove, Christopher (UK) >> wrote: >>> We can then later, if someone comes up with a good idea that we can = kick >>> around, update to a new Experimental RFC, or not if nothing good = comes >>> along. Otherwise we run the risk of not taking something that (I = hope) is >>> good today rather than the possibility of something better later. = Without >>> throwing away that latter possibility. >>=20 >> I have no problem with this... the new experimental draft should only >> be "compatible" with this one, so we can combine both of them. >>=20 >> Henning >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Jul 4 09:11:26 2014 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 475171B2827; Fri, 4 Jul 2014 09:11:23 -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 1z8Fj4cMQKRW; Fri, 4 Jul 2014 09:11:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E44E1B2AB0; Fri, 4 Jul 2014 09:11:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704161110.8553.84425.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 09:11:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SjLYuTGbYI4nLUzM4NagNf1DOXk Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-management-snapshot-01.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: Fri, 04 Jul 2014 16:11:23 -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 : Snapshot of OLSRv2-Routed MANET Management Authors : Thomas Clausen Ulrich Herberg Filename : draft-ietf-manet-olsrv2-management-snapshot-01.txt Pages : 13 Date : 2014-07-04 Abstract: This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the Optimized Link State Routing protocol version 2 (OLSRv2) and its constituent MANET NehgiborHood Discovery Protocol (NHDP). Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single parameter (called "C"). Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers. This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols). In addition, for debugging purposes, monitoring data and performance related counters, as well as notifications ("traps") can be sent to the Network Management System (NMS) via standardized management protocols. This document The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-management-snapshot-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-management-snapshot-01 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 Jul 4 09:18:28 2014 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 73E391B2C37 for ; Fri, 4 Jul 2014 09:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JGFBTV1y7Ulb for ; Fri, 4 Jul 2014 09:18:25 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46A51B2AF9 for ; Fri, 4 Jul 2014 09:18:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 82C8D2412B7 for ; Fri, 4 Jul 2014 09:18:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7BBC1240CF9 for ; Fri, 4 Jul 2014 09:18:24 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_5DD170FE-EB1F-48C2-BB16-AB416066B0E3" Date: Fri, 4 Jul 2014 18:18:21 +0200 References: <20140704161110.8553.84425.idtracker@ietfa.amsl.com> To: manet IETF Message-Id: <400A9F34-F037-4CAA-8FB8-3F153A2FE0A8@thomasclausen.org> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5CehdkrsLpnNzWk_xmDeY5XA8JY Subject: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-management-snapshot-01.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, 04 Jul 2014 16:18:27 -0000 --Apple-Mail=_5DD170FE-EB1F-48C2-BB16-AB416066B0E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello all y=92all, We=92ve put together a new version of this I-D, and we pretty much = believe that it reflects all the feedback that we have gotten since the = previous version - so the authors also pretty much feel that we=92re = getting close to done with this document. Would y'all give it a once-over and let=92s have your feedback of it, = then we=92d mighty appreciate it? =3D> If there=92s something that you feel is missing, from = how *you* mange *your*=20 OLSRv2-MANETs, then a paragraph of text would be awesome = for making progress. I mean, who knows *your* network better than *you*, right? In an ideal world, we=92d like to get feedback before Toronto (where = we=92ve requested a brief slot on the agenda), then spin a new version = during the IETF week, and ask to have it WGLCed immediately = thereafter. We=92ll also both be in Toronto, in case there=92s something = that needs f2f discussion. But, bottom line, we=92d like to see this move along rather than linger = ;) Cheers, Thomas Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: = draft-ietf-manet-olsrv2-management-snapshot-01.txt > Date: July 4, 2014 at 18:11:10 GMT+2 > To: i-d-announce@ietf.org > Cc: manet@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > 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. >=20 > Title : Snapshot of OLSRv2-Routed MANET Management > Authors : Thomas Clausen > Ulrich Herberg > Filename : = draft-ietf-manet-olsrv2-management-snapshot-01.txt > Pages : 13 > Date : 2014-07-04 >=20 > Abstract: > This document describes how Mobile Ad Hoc Networks (MANETs) are > typically managed, in terms of pre-deployment management, as well as > rationale and means of monitoring and management of MANET routers > running the Optimized Link State Routing protocol version 2 (OLSRv2) > and its constituent MANET NehgiborHood Discovery Protocol (NHDP). > Apart from pre-deployment management for setting up IP addresses and > security related credentials, OLSRv2 only needs routers to agree one > single parameter (called "C"). Other parameters for tweaking = network > performance may be determined during operation of the network, and > need not be the same in all routers. This, using MIB modules and > related management protocols such as SNMP (or possibly other, less > "chatty", protocols). In addition, for debugging purposes, > monitoring data and performance related counters, as well as > notifications ("traps") can be sent to the Network Management System > (NMS) via standardized management protocols. This document >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapsh= ot/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-manet-olsrv2-management-snapshot-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-management-snap= shot-01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_5DD170FE-EB1F-48C2-BB16-AB416066B0E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = all y=92all,

We=92ve put together a new version of = this I-D, and we pretty much believe that it reflects all the feedback = that we have gotten since the previous version - so the authors also = pretty much feel that we=92re getting close to done with this = document.

Would y'all give it a once-over and = let=92s have your feedback of it, then we=92d mighty appreciate = it?

=3D> If = there=92s something that you feel is missing, from how *you* mange = *your* 
OLSRv2-MANETs, then a = paragraph of text would be awesome for making progress. I = mean,
= who knows *your* network better than *you*, = right?

In an ideal world, we=92d like to get = feedback before  Toronto (where we=92ve requested a brief slot on = the agenda), then spin a new version during the IETF week, and ask =  to have it WGLCed  immediately thereafter. We=92ll also both = be in Toronto, in case there=92s something that needs f2f = discussion.

But, bottom line, we=92d like to = see this move along rather than linger = ;)

Cheers,

Thomas

Begin forwarded message:

Subject: = I-D Action: = draft-ietf-manet-olsrv2-management-snapshot-01.txt
Date: July 4, 2014 at 18:11:10 = GMT+2
Reply-To: internet-drafts@ietf.org
<= /span>


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 =           : Snapshot = of OLSRv2-Routed MANET Management
=        Authors =         : Thomas Clausen
=             &n= bsp;           &nbs= p;Ulrich Herberg
Filename =        : = draft-ietf-manet-olsrv2-management-snapshot-01.txt
Pages =           : = 13
= Date =            : = 2014-07-04

Abstract:
  This document describes how = Mobile Ad Hoc Networks (MANETs) are
  typically managed, = in terms of pre-deployment management, as well as
=   rationale and means of monitoring and management of MANET = routers
  running the Optimized Link State Routing = protocol version 2 (OLSRv2)
  and its constituent MANET = NehgiborHood Discovery Protocol (NHDP).
  Apart from = pre-deployment management for setting up IP addresses and
=   security related credentials, OLSRv2 only needs routers to = agree one
  single parameter (called "C").  Other = parameters for tweaking network
  performance may be = determined during operation of the network, and
  need not = be the same in all routers.  This, using MIB modules and
=   related management protocols such as SNMP (or possibly = other, less
  "chatty", protocols).  In addition, for = debugging purposes,
  monitoring data and performance = related counters, as well as
  notifications ("traps") can = be sent to the Network Management System
  (NMS) via = standardized management protocols.  This document


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mana= gement-snapshot/

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-management-snaps= hot-01

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


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/

________________________= _______________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
= --Apple-Mail=_5DD170FE-EB1F-48C2-BB16-AB416066B0E3-- From nobody Fri Jul 4 14:55:35 2014 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 241321A0058 for ; Fri, 4 Jul 2014 14:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 1SjPuJvAXTJ7 for ; Fri, 4 Jul 2014 14:55:31 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4E41A0002 for ; Fri, 4 Jul 2014 14:55:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id CB66F1031FA for ; Fri, 4 Jul 2014 14:55:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.1.47] (cha75-1-78-192-0-189.fbxo.proxad.net [78.192.0.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id B96031031F9 for ; Fri, 4 Jul 2014 14:55:29 -0700 (PDT) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Content-Type: multipart/alternative; boundary="Apple-Mail=_C8FFEFCD-DE8D-4AAD-958C-8D2954231895" Date: Fri, 4 Jul 2014 23:55:26 +0200 References: <20140704214348.30683.97182.idtracker@ietfa.amsl.com> To: "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xE2lORwShGrC4Y9IWNpy_j0RAm4 Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-03.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, 04 Jul 2014 21:55:32 -0000 --Apple-Mail=_C8FFEFCD-DE8D-4AAD-958C-8D2954231895 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear WG, We just posted a new revision of draft-gerla-manet-odmrp, reflecting the = comments made during and after IETF 89. All comments are welcome. We're still working on getting it to work with interfaces that have = multiple addresses, and writing the security considerations section. If possible, we would like to request a slot to present the draft in = Toronto. Thanks, Best, Axel D=E9but du message r=E9exp=E9di=E9 : > De: internet-drafts@ietf.org > Objet: New Version Notification for draft-gerla-manet-odmrp-03.txt > Date: 4 juillet 2014 23:43:48 UTC+2 > =C0: "William Su" , "Yunjung Yi" = , "Axel Coli Verdiere" = , Mario Gerla , "Professor Mario = Gerla" , William Su , Axel = Colin de Verdiere >=20 >=20 > A new version of I-D, draft-gerla-manet-odmrp-03.txt > has been successfully submitted by Axel Colin de Verdiere and posted = to the > IETF repository. >=20 > Name: draft-gerla-manet-odmrp > Revision: 03 > Title: On-Demand Multicast Routing Protocol (ODMRP) for = Ad Hoc Networks > Document date: 2014-07-04 > Group: Individual Submission > Pages: 33 > URL: = http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-03.txt > Status: = https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/ > Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-03 >=20 > Abstract: > The On-Demand Multicast Routing Protocol (ODMRP) is a multicast > routing protocol designed for ad hoc networks with mobile hosts. > ODMRP is a mesh-based, rather than a conventional tree-based, > multicast scheme and uses a forwarding group concept (only a subset > of nodes forwards the multicast packets via scoped flooding). It > applies on-demand procedures to dynamically build routes and = maintain > multicast group membership. ODMRP is well suited for ad hoc = wireless > networks with mobile hosts where bandwidth is limited, topology > changes frequently and rapidly, and power is constrained. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_C8FFEFCD-DE8D-4AAD-958C-8D2954231895 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = WG,

We just posted a new revision of = draft-gerla-manet-odmrp, reflecting the comments made during and after = IETF 89. All comments are welcome.
We're still working on = getting it to work with interfaces that have multiple addresses, and = writing the security considerations section.
If possible, we = would like to request a slot to present the draft in = Toronto.

Thanks,

Best,

Axel

D=E9but du message = r=E9exp=E9di=E9 :

Objet: = New Version = Notification for draft-gerla-manet-odmrp-03.txt
Date: 4 juillet 2014 23:43:48 = UTC+2
=C0: = "William Su" <william.su@boeing.com>, = "Yunjung Yi" <unknown-email-Yunj= ung-Yi@ietfa.amsl.com>, "Axel Coli Verdiere" <axel@axelcdv.com>, Mario Gerla = <gerla@cs.ucla.edu>, = "Professor Mario Gerla" <gerla@cs.ucla.edu>, William Su = <william.su@boeing.com>, = Axel Colin de Verdiere <axel@axelcdv.com>
=

A new version of I-D, draft-gerla-manet-odmrp-03.txt
has = been successfully submitted by Axel Colin de Verdiere and posted to = the
IETF repository.

Name: = draft-gerla-manet-odmrp
Revision: 03
Title: On-Demand = Multicast Routing Protocol (ODMRP) for Ad Hoc Networks
Document = date: = 2014-07-04
Group: Individual = Submission
Pages: 33
URL: =            http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-03.txtStatus:         https:/= /datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
Htmlized: =       http://tool= s.ietf.org/html/draft-gerla-manet-odmrp-03
Diff: =           htt= p://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-03

Abst= ract:
  The On-Demand Multicast Routing Protocol (ODMRP) = is a multicast
  routing protocol designed for ad hoc = networks with mobile hosts.
  ODMRP is a mesh-based, = rather than a conventional tree-based,
  multicast scheme = and uses a forwarding group concept (only a subset
  of = nodes forwards the multicast packets via scoped flooding).  It
=   applies on-demand procedures to dynamically build routes and = maintain
  multicast group membership.  ODMRP is well = suited for ad hoc wireless
  networks with mobile hosts = where bandwidth is limited, topology
  changes frequently = and rapidly, and power is constrained.




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

The IETF = Secretariat


= --Apple-Mail=_C8FFEFCD-DE8D-4AAD-958C-8D2954231895-- From nobody Fri Jul 4 15:16:31 2014 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 7579D1A00A8 for ; Fri, 4 Jul 2014 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=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 rpQBpWxrfDji for ; Fri, 4 Jul 2014 15:16:25 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0931A0085 for ; Fri, 4 Jul 2014 15:16:25 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id v1so872679yhn.6 for ; Fri, 04 Jul 2014 15:16:24 -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=qWlWX2GqG/1nurgLNOhNROhDaVUkfRw99ofeMBcWdaE=; b=OSuNqX549INgDyfx0nWD7m2VXgXEsylMHfzfbo9ylg6Fcka738S6ReDaBCGo0KSUQt wgIfXdGxllAI8lsQjXQQWxZ8pA36kAhaOc+thAN7H4urx4st2r1Qqx+rsDjD5u3x073T 1d/iYt6oooDYG3rGB2Pwd6eK+ymIr9J5in7GKPHTc7AJq2Neh6PHkSFDW6IfsaFbIP1h 4Q4AIvkxqN+0hmugij+AOSkUToCrwZCMGjK0qMtTOJbTgUzlwyaFPJdgxqGw6BZ8fpoV 01yPMuV6GEb2SThBNmFukInTmFDbLiECgJMYEjaQ+IAzD8X/iK+fIeqgEZE5zMWAQAFE rp8w== X-Received: by 10.236.157.138 with SMTP id o10mr20886036yhk.48.1404512184468; Fri, 04 Jul 2014 15:16:24 -0700 (PDT) Received: from [192.168.0.10] (173-31-121-223.client.mchsi.com. [173.31.121.223]) by mx.google.com with ESMTPSA id o42sm48679404yhe.51.2014.07.04.15.16.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 15:16:23 -0700 (PDT) References: <20140704214348.30683.97182.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-71F2F070-70AD-4007-A9E9-DB797959DE87 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Joe Macker Date: Fri, 4 Jul 2014 18:16:21 -0400 To: =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2tUproT5qf6ftA34oQqEX7Zqg2g Cc: "" Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-03.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, 04 Jul 2014 22:16:26 -0000 --Apple-Mail-71F2F070-70AD-4007-A9E9-DB797959DE87 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable yes on presentation please work with ulrich on logistics -joe > On Jul 4, 2014, at 5:55 PM, Axel Colin de Verdi=C3=A8re = wrote: >=20 > Dear WG, >=20 > We just posted a new revision of draft-gerla-manet-odmrp, reflecting the c= omments made during and after IETF 89. All comments are welcome. > We're still working on getting it to work with interfaces that have multip= le addresses, and writing the security considerations section. > If possible, we would like to request a slot to present the draft in Toron= to. >=20 > Thanks, >=20 > Best, >=20 > Axel >=20 > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 >> De: internet-drafts@ietf.org >> Objet: New Version Notification for draft-gerla-manet-odmrp-03.txt >> Date: 4 juillet 2014 23:43:48 UTC+2 >> =C3=80: "William Su" , "Yunjung Yi" , "Axel Coli Verdiere" , Mario G= erla , "Professor Mario Gerla" , Willi= am Su , Axel Colin de Verdiere >>=20 >>=20 >> A new version of I-D, draft-gerla-manet-odmrp-03.txt >> has been successfully submitted by Axel Colin de Verdiere and posted to t= he >> IETF repository. >>=20 >> Name: draft-gerla-manet-odmrp >> Revision: 03 >> Title: On-Demand Multicast Routing Protocol (ODMRP) for Ad= Hoc Networks >> Document date: 2014-07-04 >> Group: Individual Submission >> Pages: 33 >> URL: http://www.ietf.org/internet-drafts/draft-gerla-manet-odm= rp-03.txt >> Status: https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/= >> Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-03 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmr= p-03 >>=20 >> Abstract: >> The On-Demand Multicast Routing Protocol (ODMRP) is a multicast >> routing protocol designed for ad hoc networks with mobile hosts. >> ODMRP is a mesh-based, rather than a conventional tree-based, >> multicast scheme and uses a forwarding group concept (only a subset >> of nodes forwards the multicast packets via scoped flooding). It >> applies on-demand procedures to dynamically build routes and maintain >> multicast group membership. ODMRP is well suited for ad hoc wireless >> networks with mobile hosts where bandwidth is limited, topology >> changes frequently and rapidly, and power is constrained. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-71F2F070-70AD-4007-A9E9-DB797959DE87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
yes on presentation please work with u= lrich on logistics

-joe

On Jul 4, 2014, at 5:55 PM, Axe= l Colin de Verdi=C3=A8re <axel@axelcd= v.com> wrote:

Dear WG,
We just posted a new revision of draft-gerla-manet-odmrp, r= eflecting the comments made during and after IETF 89. All comments are welco= me.
We're still working on getting it to work with interfaces that= have multiple addresses, and writing the security considerations section.
If possible, we would like to request a slot to present the draft i= n Toronto.

Thanks,

Best,

Axel

D=C3=A9but du message r=C3=A9e= xp=C3=A9di=C3=A9 :

Objet: New Version Notification for draft-gerla-manet-odmrp-03.txt
Date: 4= juillet 2014 23:43:48 UTC+2
=C3=80: "William Su" <william.su@boeing.com>, "Yunjung Yi" <unknown-email-Yunjung-Yi@ietf= a.amsl.com>, "Axel Coli Verdiere" <axel@axelcdv.com>, Mario Gerla <gerla@cs.ucla.edu>, "Professor Mario Gerla" <gerla@cs.ucla.edu>, William Su <william.su@boeing.com>, Axel Colin de V= erdiere <axel@axelcdv.com>
=


A new version of I-D, draft-gerla-manet-odmrp-03.t= xt
has been successfully submitted by Axel Colin de Verdiere and posted t= o the
IETF repository.

Name: draft-gerla-manet-odmrp
Revision: 03
Title: On-Demand Multicast R= outing Protocol (ODMRP) for Ad Hoc Networks
Document date: 2014-07-04
Group:= Individual S= ubmission
Pages:= = 33
URL:          &nb= sp; http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-03.t= xt
Status:         https://datatrac= ker.ietf.org/doc/draft-gerla-manet-odmrp/
Htmlized:    = ;   http://tools.ietf.org/html/draft-gerla-manet-odmrp-03
Diff: &= nbsp;         http://www.ietf.org= /rfcdiff?url2=3Ddraft-gerla-manet-odmrp-03

Abstract:
 &n= bsp;The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
&nbs= p; routing protocol designed for ad hoc networks with mobile hosts.
=   ODMRP is a mesh-based, rather than a conventional tree-based,   multicast scheme and uses a forwarding group concept (only a s= ubset
  of nodes forwards the multicast packets via scoped flo= oding).  It
  applies on-demand procedures to dynamically= build routes and maintain
  multicast group membership.  = ;ODMRP is well suited for ad hoc wireless
  networks with mobi= le hosts where bandwidth is limited, topology
  changes freque= ntly and rapidly, and power is constrained.




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

The IETF Secretariat

=

____= ___________________________________________
manet mailing li= st
manet@ietf.org
https://= www.ietf.org/mailman/listinfo/manet
= = --Apple-Mail-71F2F070-70AD-4007-A9E9-DB797959DE87-- From nobody Fri Jul 4 16:55:23 2014 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 699251A02EE for ; Fri, 4 Jul 2014 16:55: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 0l3Jli7lOMF3 for ; Fri, 4 Jul 2014 16:55:19 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2301A028A for ; Fri, 4 Jul 2014 16:55:19 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so2143056wev.20 for ; Fri, 04 Jul 2014 16:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w6rZZQ0otUfHlL21bMmcOU0XFSg+Sybrz4LkgPyjfdw=; b=AP8vLxg9QFsrdnVeJl2XPSoZIXgby+fK6sIHB8Q0yNI2hpN2tNrpHsPimw/NT/g6X8 YNR6ffsx2ZTzRPfOa7V6o5Zzw6xTPRWgNHRvjVioFUI/3NqjIb8IgtyVWLtEtGnrUCfd /+irvUNvNSh1t8yUBaNfRHCRCBtEsFkVALi3t0M6x5gKP2I5EUD/x9sQSWQe3VFew8lp 84wbKjq4Uz0Lij45tSs+K8xn+DBGvNM3pfTU7TUlH25r82yNF/gQ2zIfvZbjs2oZo2n2 few/2x0R/n9Sf/aVZaFeP4gzbwUhwAmHWlzQCE6CzmHTd2rdFkeEI5sHsnoDA/JG7egx um0Q== MIME-Version: 1.0 X-Received: by 10.194.219.70 with SMTP id pm6mr15098825wjc.53.1404518117733; Fri, 04 Jul 2014 16:55:17 -0700 (PDT) Received: by 10.180.89.161 with HTTP; Fri, 4 Jul 2014 16:55:17 -0700 (PDT) In-Reply-To: <322BB165-0B26-41D7-B7A4-71CFBC5D5769@thomasclausen.org> References: <322BB165-0B26-41D7-B7A4-71CFBC5D5769@thomasclausen.org> Date: Sat, 5 Jul 2014 00:55:17 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a11c1b31c7cfaaf04fd66dbdf Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BuM2uXZ1a9yav_CN_b83ofiu6nw Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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, 04 Jul 2014 23:55:21 -0000 --001a11c1b31c7cfaaf04fd66dbdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with not separating them, which seems the simpler multitopology routing, but we can add one section in the draft to identify WG future considerations of multitopology as with separation and may identify the challenges that Thomas and Chris observed. AB On Friday, July 4, 2014, Thomas Clausen wrote: > Chris, all, > > On Jul 4, 2014, at 15:38, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com > > wrote: > > The more I think about this, the more I believe that the correct approach > is to go with what we currently have, topology =3D metric, in the current > Experimental draft. This gives us something where we don=E2=80=99t try to= make a > rushed approach to whether we can split the concepts well, that we can > implement more easily and experiment with, in particular to find out how > useful it is. The only downside is possibly larger messages. > > We can then later, if someone comes up with a good idea that we can kick > around, update to a new Experimental RFC, or not if nothing good comes > along. Otherwise we run the risk of not taking something that (I hope) is > good today rather than the possibility of something better later. Without > throwing away that latter possibility. > > > I fully agree with you on the above. A bit of a backstory might be in > order=E2=80=A6. > > When the initial versions of this I-D were posted, the authors (together > and apart) tried to work out different ways of separating =E2=80=9Cmetric= =E2=80=9D and > =E2=80=9Ctopology=E2=80=9D =E2=80=94 turns out that a lot of the =E2=80= =9Csimple, easy=E2=80=9D (as well as > not-so-simple and a good deal harder) approaches don=E2=80=99t work, and = that those > that might (emphasis on might) work were quite horrible.... > > Contemplating the =E2=80=9Cdeployment space=E2=80=9D that I know of, I th= ink that what we > came up with in this specification is a reasonable compromise: considerin= g > the =E2=80=9Cmetrics=E2=80=9D as =E2=80=9Ctopology type=E2=80=9D extendin= g the administratively assigned > metrics code-point space. > > The advantage is that we know it works (yes, there=E2=80=99s running code= ), and is > fairly clean and simple. > > As Chris says, this is experimental - i.e., non-prescriptive. The idea is > to get more experiences with multi-topology routing. Part of that > experience will (I hope) lead to an epiphany as to how to do something > that=E2=80=99s better (or a realization that we either need no more, or c= an=E2=80=99t do > better). That=E2=80=99s when we should spin a new either experimental or = PS version. > > Thomas > > > > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com > | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > --001a11c1b31c7cfaaf04fd66dbdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with not separating them, which seems=C2=A0the simpler=C2=A0multito= pology routing,=C2=A0but we can add one section in the draft to identify WG= =C2=A0future considerations of multitopology as with separation and may ide= ntify the challenges that Thomas and Chris observed.=C2=A0

AB

On Friday, July 4, 2014, Thomas Clausen wrote:
Chris, = all,

On Jul 4, 2014, at 15:38, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
The more I think about this, the more I believe that the cor= rect approach is to go with what we currently have, topology =3D metric, in= the current Experimental draft. This gives us something where we don=E2=80= =99t try to make a rushed approach to whether we can split the concepts wel= l, that we can implement more easily and experiment with, in particular to = find out how useful it is. The only downside is possibly larger messages.
=C2=A0
We can then later, if someone= comes up with a good idea that we can kick around, update to a new Experim= ental RFC, or not if nothing good comes along. Otherwise we run the risk of= not taking something that (I hope) is good today rather than the possibili= ty of something better later. Without throwing away that latter possibility= .

I fully agree with you on the above= . A bit of a backstory might be in order=E2=80=A6.

When the initial versions of this I-D were posted, the authors (together a= nd apart) tried to work out different ways of separating =E2=80=9Cmetric=E2= =80=9D and =E2=80=9Ctopology=E2=80=9D =E2=80=94 turns out that a lot of the= =E2=80=9Csimple, easy=E2=80=9D (as well as not-so-simple and a good deal h= arder) approaches don=E2=80=99t work, and that those that might (emphasis o= n might) work were quite horrible....

Contemplating the =E2=80=9Cdeployment space=E2=80=9D th= at I know of, I think that what we came up with in this specification is a = reasonable compromise: considering the =E2=80=9Cmetrics=E2=80=9D as =E2=80= =9Ctopology type=E2=80=9D extending the administratively assigned metrics c= ode-point space.

The advantage is that we know it works (yes, there=E2= =80=99s running code), and is fairly clean and simple.

=
As Chris says, this is experimental - i.e., non-prescriptive. The idea= is to get more experiences with multi-topology routing. Part of that exper= ience will (I hope) lead to an epiphany as to how to do something that=E2= =80=99s better (or a realization that we either need no more, or can=E2=80= =99t do better). That=E2=80=99s when we should spin a new either experiment= al or PS version.

Thomas



--
Christopher Dearlove<= u>
Senior Principal Engineer, Information= Assurance Group
Communications, Networks and Image Analysis Capability<= br>BAE Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=C2=A0|=C2=A0 Fax: +44 1245 242124=
chris.dearlove@baesystems.co= m=C2=A0|=C2=A0http://www.baesystems.com

BAE Systems (Operations) Li= mited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wa= les No: 1996687
=C2=A0

******************************= **************************************
This email and any attachments ar= e confidential to the intended
recipient and may also be privileged. If you are not the intended
recipi= ent 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 con= tents to any other person.
********************************************************************


--001a11c1b31c7cfaaf04fd66dbdf-- From nobody Fri Jul 4 23:11:39 2014 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 134CA1A0341 for ; Fri, 4 Jul 2014 23:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 bG_t1lHFFxHq for ; Fri, 4 Jul 2014 23:11:33 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA131A0346 for ; Fri, 4 Jul 2014 23:11:32 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so2328439wes.36 for ; Fri, 04 Jul 2014 23:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=P0LFBKULj6gL5yxOs7YsduLnT3AKeXj3aIGXgGQl9Cs=; b=sRI5mJnohXojT/ppNWSl2FQUJDUV/ZB1NmRiWiPXtaiidGt5TCkYU7pNdJ1s8haggM nd4FriTGD2H81Ba+l65sL29qnIQtkQUMCHCiOQ2Ds/IEzvWExIqSgkuL71xDKjl/lHVJ h1PYyABak5wgJsxauEPS5Frx/T6L5BuVmPtg+riprpUY4URwl3UxUNuJTbWoW4aqYQGv NBThLT/MzCgcX1mKxU153ovChYFpRKkrYFfIWndpTPJRWh9EEZOzWnR4lqeX7DOHRHPG D9mnGiH9/h3CUpcYXsXrWPrHGNfVmNzOputs5/nOg1sZ+hqp1gjRMF7Q7/vaL5g+2G2u zFDA== MIME-Version: 1.0 X-Received: by 10.194.24.36 with SMTP id r4mr16909510wjf.35.1404540691569; Fri, 04 Jul 2014 23:11:31 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Fri, 4 Jul 2014 23:11:31 -0700 (PDT) In-Reply-To: <20140704215231.18946.25001.idtracker@ietfa.amsl.com> References: <20140704215231.18946.25001.idtracker@ietfa.amsl.com> Date: Sat, 5 Jul 2014 08:11:31 +0200 X-Google-Sender-Auth: 9zYOCeB5VW1uPo9j1VD-KzTSVDI Message-ID: From: Jiazi YI To: manet , "Stan Ratliff (sratliff)" , Joe Macker Content-Type: multipart/alternative; boundary=047d7b5d2deafe639604fd6c1c55 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NHcSlXyRHMhZQmuFRy8Kd4zcZiI Cc: Thomas Heide Clausen Subject: [manet] Fwd: New Version Notification for draft-yi-manet-smf-sec-threats-00.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: Sat, 05 Jul 2014 06:11:37 -0000 --047d7b5d2deafe639604fd6c1c55 Content-Type: text/plain; charset=UTF-8 Dear all, We have submitted a new draft, Security Threats for Simplified Multicast Forwarding (draft-yi-manet-smf-sec-threats). It follows the format of RFC7186 (nhdp-sec-threats), and analyzes the vulnerabilities of SMF. We are also working on draft-clausen-manet-olsrv2-sec-threats, which is for OLSRv2. We would like to request a 10-minute slot for the above two documents in the next IETF meeting. Thomas Clausen will present the drafts. regards Jiazi ---------- Forwarded message ---------- From: Date: Fri, Jul 4, 2014 at 11:52 PM Subject: New Version Notification for draft-yi-manet-smf-sec-threats-00.txt To: Ulrich Herberg , "Thomas H. Clausen" < T.Clausen@computer.org>, Jiazi Yi , Thomas Heide Clausen A new version of I-D, draft-yi-manet-smf-sec-threats-00.txt has been successfully submitted by Jiazi Yi and posted to the IETF repository. Name: draft-yi-manet-smf-sec-threats Revision: 00 Title: Security Threats for Simplified Multicast Forwarding (SMF) Document date: 2014-07-04 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-yi-manet-smf-sec-threats-00.txt Status: https://datatracker.ietf.org/doc/draft-yi-manet-smf-sec-threats/ Htmlized: http://tools.ietf.org/html/draft-yi-manet-smf-sec-threats-00 Abstract: This document analyzes security threats of the Simplified Multicast Forwarding (SMF), including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7b5d2deafe639604fd6c1c55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

We have subm= itted a new draft, =C2=A0Security Threats for Simplified Multicast Forwardi= ng (draft-yi-manet-smf-sec-threats).=C2=A0
It follows the format = of RFC7186 (nhdp-sec-threats), and analyzes the vulnerabilities of SMF.=C2= =A0
We are also working on draft-clausen-manet-olsrv2-sec-threats, which i= s for OLSRv2.=C2=A0

We would like to request a 10-= minute slot for the above two documents in the next IETF meeting.=C2=A0
Thomas Clausen will present the drafts.=C2=A0

rega= rds

Jiazi

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jul 4, 2014 at 11:52 PM
Subject: New Version Notification for= draft-yi-manet-smf-sec-threats-00.txt
To: Ulrich Herberg <ulrich@herberg.name>, "Thomas H. C= lausen" <T.Clausen@comput= er.org>, Jiazi Yi <jiazi@jia= ziyi.com>, Thomas Heide Clausen <t.clausen@computer.org>



A new version of I-D, draft-yi-manet-smf-sec-threats-00.txt
has been successfully submitted by Jiazi Yi and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-yi-manet-smf-sec-threats
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Security Threats for Simplified Mu= lticast Forwarding (SMF)
Document date: =C2=A02014-07-04
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= http://www.ietf.org/internet-drafts/draft-yi-manet-smf-sec-threats-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker= .ietf.org/doc/draft-yi-manet-smf-sec-threats/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/d= raft-yi-manet-smf-sec-threats-00


Abstract:
=C2=A0 =C2=A0This document analyzes security threats of the Simplified Mult= icast
=C2=A0 =C2=A0Forwarding (SMF), including the vulnerabilities of duplicate p= acket
=C2=A0 =C2=A0detection and relay set selection mechanisms. =C2=A0This docum= ent is not
=C2=A0 =C2=A0intended to propose solutions to the threats described.




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

The IETF Secretariat


--047d7b5d2deafe639604fd6c1c55-- From nobody Sat Jul 5 15:15:17 2014 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 8F4BC1A004D for ; Sat, 5 Jul 2014 15:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 yVR9IA5KwwuQ for ; Sat, 5 Jul 2014 15:15:13 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39131A0037 for ; Sat, 5 Jul 2014 15:15:12 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2864903wgg.20 for ; Sat, 05 Jul 2014 15:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=rY0I6jSqq1YWUitaIVEqKXAMD3mkunSp8vZja53ZvUM=; b=vDZ1q5hkvw5+U00StrGWEut9qNxVg4D2+KzsqJ/G6eCRI/nAsw9f6eqhjIcZPEsXAZ 0zcH73/xoino9b4swOesFZjfpmgp16jCCRggSkobnxiX550fZ7LtlN5eb0voewBto00k vY+mkfcjMCZNDuYR2Bw5ffa86QqM0pfSyXrGDx3kX1fwRorhuJe9oYA8h2BP/sUw7IHQ tNghWhdqnNIqZzP8gdybuMGUfeY/OwmdjHnyBQI7k99hnWd8dOy2F9TTsDCTs/FCi3/j A/iS2W53ErRag1MPsHqr439DT5R6aG4AHpE4V7gHAdwGIafBUekZ1wclqYJWomgMDCmX HTQw== MIME-Version: 1.0 X-Received: by 10.180.207.48 with SMTP id lt16mr25773854wic.32.1404598511175; Sat, 05 Jul 2014 15:15:11 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Sat, 5 Jul 2014 15:15:11 -0700 (PDT) In-Reply-To: <20140704192129.17494.45875.idtracker@ietfa.amsl.com> References: <20140704192129.17494.45875.idtracker@ietfa.amsl.com> Date: Sun, 6 Jul 2014 00:15:11 +0200 X-Google-Sender-Auth: 3_B0TEZuYIGOm_Hds1rtxpeUqV8 Message-ID: From: Jiazi YI To: manet , Ulrich Herberg , "Stan Ratliff (sratliff)" , Joe Macker Content-Type: multipart/alternative; boundary=001a11c3f6ea4f8f8c04fd799357 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KSnVRn-sTikt9idVKNVse7wQscw Subject: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-00.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: Sat, 05 Jul 2014 22:15:14 -0000 --001a11c3f6ea4f8f8c04fd799357 Content-Type: text/plain; charset=UTF-8 Hi, A new draft draft-yi-manet-olsrv2-multipath ( http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-00.txt) has been submitted. It is a multipath extension of OLSRv2 (and fully interoperable with OLSRv2), which explores multiple disjoint paths to improve the reliability of data forwarding in MANETs. Several open source implementations of the protocol (for both testbed and simulations) have been existed for years, and a lot of study has been conducted. More details about the implementations can be found at: http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-00#section-10 We have requested a slot in the next IETF meeting. Your comments on the draft are appreciated. regards Jiazi ---------- Forwarded message ---------- From: Date: Fri, Jul 4, 2014 at 9:21 PM Subject: New Version Notification for draft-yi-manet-olsrv2-multipath-00.txt To: Jiazi Yi , Benoit Parrein < benoit.parrein@polytech.univ-nantes.fr>, Benoit Parrein < Benoit.Parrein@polytech.univ-nantes.fr> A new version of I-D, draft-yi-manet-olsrv2-multipath-00.txt has been successfully submitted by Jiazi Yi and posted to the IETF repository. Name: draft-yi-manet-olsrv2-multipath Revision: 00 Title: Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Document date: 2014-07-04 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-00.txt Status: https://datatracker.ietf.org/doc/draft-yi-manet-olsrv2-multipath/ Htmlized: http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-00 Abstract: This document specifies a multi-path extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11c3f6ea4f8f8c04fd799357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

A new draft=C2=A0=C2=A0draft-= yi-manet-olsrv2-multipath (http://www.ietf.or= g/internet-drafts/draft-yi-manet-olsrv2-multipath-00.txt) has been subm= itted.=C2=A0

It is a multipath extension of OLSRv2 (and fully intero= perable with OLSRv2), which explores multiple disjoint paths to improve the= reliability of data forwarding in MANETs.=C2=A0

S= everal open source implementations of the protocol (for both testbed and si= mulations) have been existed for years, and a lot of study has been conduct= ed. More details about the implementations can be found at: =C2=A0

We have requested a slot in t= he next IETF meeting. Your comments on the draft are appreciated.=C2=A0

regards

Jiazi

---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername"> <internet-drafts@ietf.org>=
Date: Fri, Jul 4, 2014 at 9:21 PM
Subject: New Version Notification for = draft-yi-manet-olsrv2-multipath-00.txt
To: Jiazi Yi <jiazi@jiaziyi.com>, Benoit Pa= rrein <benoit.parrein@polytech.univ-nantes.fr>, Benoit Parrein = <Benoit.Parrein@polytech.univ-nantes.fr>



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

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-yi-manet-olsrv2-multipath Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Multi-path Extension for the Optim= ized Link State Routing Protocol version 2 (OLSRv2)
Document date: =C2=A02014-07-04
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-00.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracke= r.ietf.org/doc/draft-yi-manet-olsrv2-multipath/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/= draft-yi-manet-olsrv2-multipath-00


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




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

The IETF Secretariat


--001a11c3f6ea4f8f8c04fd799357-- From nobody Sun Jul 6 16:20:43 2014 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 DAF281A0019 for ; Sun, 6 Jul 2014 16:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 OU-Sd5qGWc1p for ; Sun, 6 Jul 2014 16:20:39 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49EF1A0015 for ; Sun, 6 Jul 2014 16:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8480; q=dns/txt; s=iport; t=1404688840; x=1405898440; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tTejNQaCJTcBTt7K+D9xcjR0E2DDM6bLOER5w9liKXE=; b=OYN3SLh9DeUjkAt0awYdxqft5Ma5Y00djYd0pf49HlBha/A2PManBPW9 Bm55NSMEBNHkL4pL3m9MhuquCLvzp0ieuwCHGS8ghWf++7vW3i6IE5sGg x2/ORQ9fZSTa39RT+3A0BItQMNNX0LwQX73a+igTus6mfe48Txym8pyZ7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAFADfZuVOtJA2K/2dsb2JhbABagkdHUlq+bQGHPgGBDBZ1hAQBAQQBAQFSGQsQAgEIBzgHJwsUEQEBBA4FiEINySUXiWWEWwoHAUsBBAcJgySBFgWadpQMg0OBbgkXIg X-IronPort-AV: E=Sophos; i="5.01,614,1400025600"; d="scan'208,217"; a="58664921" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 06 Jul 2014 23:20:39 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s66NKbq6031365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Jul 2014 23:20:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Sun, 6 Jul 2014 18:20:37 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Topologies and Metrics Thread-Index: Ac+XjEhKNmJK6bqYQw2Cxxdeg+RvdwCDoSwA Date: Sun, 6 Jul 2014 23:20:37 +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.116.179.216] Content-Type: multipart/alternative; boundary="_000_D9B26FCE1D764F55924EEC4FE095B755ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IHho1QR59oOyjW2pVn6iPkCNuK8 Cc: "manet@ietf.org" Subject: Re: [manet] Topologies and Metrics 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: Sun, 06 Jul 2014 23:20:41 -0000 --_000_D9B26FCE1D764F55924EEC4FE095B755ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Chris, Speaking as a WG participant - I completely agree with you here. If we're = going to publish as experimental, then let's publish what we have. If peopl= e want to experiment further, that's great. The further experiments may (or= may not) result in follow-on drafts. Either way, let's move forward with t= he current approach. Just my 2-cents-worth. Regards, Stan On Jul 4, 2014, at 9:38 AM, "Dearlove, Christopher (UK)" > wrote: The more I think about this, the more I believe that the correct approach i= s to go with what we currently have, topology =3D metric, in the current Ex= perimental draft. This gives us something where we don=92t try to make a ru= shed approach to whether we can split the concepts well, that we can implem= ent more easily and experiment with, in particular to find out how useful i= t is. The only downside is possibly larger messages. We can then later, if someone comes up with a good idea that we can kick ar= ound, update to a new Experimental RFC, or not if nothing good comes along.= Otherwise we run the risk of not taking something that (I hope) is good to= day rather than the possibility of something better later. Without throwing= away that latter possibility. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_D9B26FCE1D764F55924EEC4FE095B755ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <62C0CB261ED34E4DBBEB0DD22F72CFB7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Chris, 

Speaking as  a WG participant - I completely agree with you here.= If we're going to publish as experimental, then let's publish what we have= . If people want to experiment further, that's great. The further experimen= ts may (or may not) result in follow-on drafts. Either way, let's move forward with the current approach. 

Just my 2-cents-worth. 

Regards,
Stan


On Jul 4, 2014, at 9:38 AM, "Dearlove, Christopher (UK)" <= ;chris.dearlove@baesystems= .com> wrote:

The more I think about this, the more I believe that the correct approach i= s to go with what we currently have, topology =3D metric, in the current Ex= perimental draft. This gives us something where we don=92t try to make a ru= shed approach to whether we can split the concepts well, that we can implement more easily and experiment with, = in particular to find out how useful it is. The only downside is possibly l= arger messages.
 
We can then later, if someone comes up with a good idea that we can kick ar= ound, update to a new Experimental RFC, or not if nothing good comes along.= Otherwise we run the risk of not taking something that (I hope) is good to= day rather than the possibility of something better later. Without throwing away that latter possibility.<= o:p>
 
--
Christopher Dearlove
Senior Principal Engineer, Inform= ation Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@= baesystems.com | http= ://www.baesystems.com

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

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

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

--_000_D9B26FCE1D764F55924EEC4FE095B755ciscocom_-- From nobody Sun Jul 6 17:33:31 2014 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 CA22B1A0066 for ; Sun, 6 Jul 2014 17:33:28 -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 5bU0TE83l5KX for ; Sun, 6 Jul 2014 17:33:27 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378D51A0064 for ; Sun, 6 Jul 2014 17:33:27 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so3363905veb.16 for ; Sun, 06 Jul 2014 17:33:26 -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=ohQnyAfzTNIKUpGQxIIAL4BJploy7BSgkKEnIgXC9EI=; b=w74bqzOBXrC7Cr/9hDses1hCve45tybkGnzQDuq0FUnTazwXm/l4e3MI8QM8UG3dlU fK7usVs+6jCpHwoWnw6Yu043FFwugYsECfe4wLKzSt6Y+kEALWYuIHhpfjVeaB6iqmtb VNBcujPKYOnS+b0+EK5FspgwQ72gr42bliQag= 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=ohQnyAfzTNIKUpGQxIIAL4BJploy7BSgkKEnIgXC9EI=; b=Yrsm6zaO5XSK93FGet7/ZmaKO+J8nUlDj74PCJ4cZXFhIR6bYJiYoqA3lZapgcdp+9 aF5Wp8vw8OJNovMfO6Mq23pQ417ImA0gcoS/Vru8jLmr1thjTFd4i5goom3ibyWXqA9+ W9jYSAjgy+PwqPdW2Ttqj2jdkUOPduFm0yI7bWE6U5GqmN40JjZkGCVNguU9K8H4+8Ha 0NmrXqSolVJktjMtDGVP7DfC4tBR5hkVoWXZetGR1wlgBFInqi351Ys9Ux5gamP0wwn7 ncSSVpCXjuMpB/8TJGKHtQi58UA32rLsfFkukIxQsz35JyQXEgLxiw9cyXYqb2q+h14c gLCQ== X-Gm-Message-State: ALoCoQkuduD3IVpJ4Ql54BY78hhwlbVePSeM7sCeUDY1wKTmpefgS5JLf2klOtoS8R4RkQUgcyNl MIME-Version: 1.0 X-Received: by 10.220.161.8 with SMTP id p8mr24185332vcx.4.1404693206272; Sun, 06 Jul 2014 17:33:26 -0700 (PDT) Received: by 10.220.124.5 with HTTP; Sun, 6 Jul 2014 17:33:26 -0700 (PDT) Date: Sun, 6 Jul 2014 17:33:26 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/thQ47pv2Je1pPIR-WRI700Flz84 Subject: [manet] Preliminary agenda 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, 07 Jul 2014 00:33:28 -0000 Hi, I uploaded a preliminary agenda at: http://www.ietf.org/proceedings/90/agenda/agenda-90-manet Please let me know any comments or suggestions. Best regards Ulrich From nobody Tue Jul 8 00:26:47 2014 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 3D8941B2A88; Tue, 8 Jul 2014 00:26:47 -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 T6qUPR1aDpws; Tue, 8 Jul 2014 00:26:46 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFAD1B2A62; Tue, 8 Jul 2014 00:26:45 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so4647204qcv.19 for ; Tue, 08 Jul 2014 00:26:45 -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=9gb7/xyEhqt8Ve5B6CU8kQm0GAZ97nzN5gKFmLwAHt0=; b=gXjRRGAa7BjqXulGOOerSrHNtQ2+5MI6bChFAXi33Pl1QX0TDLskCxDRdAWENGKlBZ JtZ75HvaXhtcL4wHjN0tQfQ/Ql3zCPbgNuArBXCORyM9Wzvlt4HWRY2N0olmGKj5oUHz 9fpUM+n3xwtAkVG+/OHnaOmglC2NNZnBsV63oN7qZpkPMqremHub8GR6FhT5pBvUOgWe l/M9TMVi5nEBJTL6Qp0ZaudxVcpuy0CI8JIWg7Bp9ZZjSIOz+IZQe3nqpBHKn857hJhD TfQjTy+uu66rwnzU83wnrJcOhLQJGAJInz2FEnIRs8IGA4tddgGwpUxCYTifXSdaRsKV rLgw== X-Received: by 10.224.41.65 with SMTP id n1mr56277271qae.75.1404804405192; Tue, 08 Jul 2014 00:26:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Tue, 8 Jul 2014 00:26:25 -0700 (PDT) In-Reply-To: <20140704141934.7303.83520.idtracker@ietfa.amsl.com> References: <20140704141934.7303.83520.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 8 Jul 2014 09:26:25 +0200 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zCyVkwRO5ZVIka6pz4Vrg_p_bPA Cc: MANET IETF , i-d-announce@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-03.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: Tue, 08 Jul 2014 07:26:47 -0000 On Fri, Jul 4, 2014 at 4:19 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) > Authors : Christopher Dearlove > Thomas Heide Clausen > Filename : draft-ietf-manet-olsrv2-multitopology-03.txt The new draft looks fine... have to check my implementation again that it does the right job. could you maybe replace the (FGAN) reference to (Fraunhofer FKIE)? FGAN doesn't exist anymore, it became three Fraunhofer institutes in 2009 (and my institute is Fraunhofer FKIE). Henning Rogge From nobody Tue Jul 8 00:36:44 2014 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 316F91B2A8C for ; Tue, 8 Jul 2014 00:36:42 -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 cKltm-1zZFyP for ; Tue, 8 Jul 2014 00:36:40 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EA31B2A8A for ; Tue, 8 Jul 2014 00:36:40 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id j15so4524466qaq.40 for ; Tue, 08 Jul 2014 00:36:40 -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=duTZAJ0iepUCSkfDUk791GVR1VQ6paxDU/IRNowlMxg=; b=nu10b7XKDVnuZFpSrzO2eKOt8FP4k9HdIzErpafSt1fnlVys4ZuKy6uLjtAqKmu8HZ ETjQMnPSHndGfoiMiTCJCXopWnJukANjy5mnyuJtJFL7ZAZYMikwyBSXOuavd689LCTB qfqgVHTIi5/lBZSw50jMNuiW+ijdPFUvSpxTFR1epkVMkrKB0XxWyJTzqO5wLmf8VWXO vN912YUwVwwvYoiVNufQwdTywMZutFNTvH15dOIMEFAEbE1mcMNcz0rb0FnXWwK+JToj lS7H7Bxg4akzSA30QVAipWfIn5HSCMfskYOc1dIVcwMeYut2Sae7ceO2Rvu2gt7gsLzY g8xg== X-Received: by 10.140.47.173 with SMTP id m42mr54891222qga.9.1404804999966; Tue, 08 Jul 2014 00:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Tue, 8 Jul 2014 00:36:18 -0700 (PDT) In-Reply-To: <400A9F34-F037-4CAA-8FB8-3F153A2FE0A8@thomasclausen.org> References: <20140704161110.8553.84425.idtracker@ietfa.amsl.com> <400A9F34-F037-4CAA-8FB8-3F153A2FE0A8@thomasclausen.org> From: Henning Rogge Date: Tue, 8 Jul 2014 09:36:18 +0200 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zDpb5olJrn3dsH1xtTFzst6cB30 Cc: manet IETF Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-management-snapshot-01.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: Tue, 08 Jul 2014 07:36:42 -0000 On Fri, Jul 4, 2014 at 6:18 PM, Thomas Clausen w= rote: > Hello all y=E2=80=99all, > > We=E2=80=99ve put together a new version of this I-D, and we pretty much = believe > that it reflects all the feedback that we have gotten since the previous > version - so the authors also pretty much feel that we=E2=80=99re getting= close to > done with this document. > > Would y'all give it a once-over and let=E2=80=99s have your feedback of i= t, then > we=E2=80=99d mighty appreciate it? I think section 3.1 is worded a bit strong... its true that RFC5444 messages can only contain a single address type as addresses, but RFC5444 packets can contain messages with different address lengths. The section reads (for me) that you cannot support both IPv4 and IPv6 within the same routing daemon, which is not true. The olsr.org implementation does exactly this (even without my optimization tricks), it even runs a single dijkstra over a set of both IPv4 and IPv6 OLSRv2 nodes and edges. ---- Do we want to mention that most Freifunk/Funkfeuer networks use TCP based queries (either pure text of HTML) with JSON output to query the state of the OLSR (v1) implementation... the OLSRv2 implementation of olsr.org will allow to do the same. Would it be interesting to see if we can standardize a JSON query interface? Or if we can map the SNMP definitions to JSON in a reasonable way? Henning Rogge From nobody Tue Jul 8 01:14:48 2014 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 E39071B278D for ; Tue, 8 Jul 2014 01:14:43 -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 0Qb33QmfoXjJ for ; Tue, 8 Jul 2014 01:14:42 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0261B278C for ; Tue, 8 Jul 2014 01:14:42 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so562358qap.32 for ; Tue, 08 Jul 2014 01:14: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=G/i+SHCyrDlcfLLHTeejBSqsRhUkpY5KNp0sgghcqJM=; b=05mO/8+lu0hbFccl3x6+jLqlWejZBiGKytpwCSyhJBvxrMhSpkfluj5rNHdy4j8CE8 z1w3LgTL02PKbUovvlxhLgpGaz34vapqsSVWnDaQQfEBwN2XGqf1kFNmhk41+F5jgRLX P7kpKzYhYN7QDpb8PXC6Jz3T1gUmvCfMfRZfEJ81LMljT1sFFbrnD8QtcCfHSSATnzhf eJDYR5AypMHbP9ZzfSuccBvWy1FB4HnfJdkC6bDga7hik4VHE+h/Iu36TcgsnVe68vsm LgvEWOtdTvOgJfELi74c6TutFeSVtsQNEuwp+/KjJVAYncCnEST8UKHKyRZlP5hMNv52 wP+Q== X-Received: by 10.224.137.9 with SMTP id u9mr58325400qat.24.1404807281205; Tue, 08 Jul 2014 01:14:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Tue, 8 Jul 2014 01:14:21 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98011399A404@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98011399A404@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 8 Jul 2014 10:14:21 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zTHDhQtZ_K7JeYtPig1TRFxQjuo Cc: "manet-dlep-rg@ietf.org Group, \(manet-dlep-rg@ietf.org\)" , "manet@ietf.org" Subject: Re: [manet] [manet-dlep-rg] DLEP extension draft submitted 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, 08 Jul 2014 08:14:44 -0000 On Mon, Jun 30, 2014 at 5:18 PM, Rick Taylor wrote: > For those who are interested, > > We have just submitted an individual draft with a proposed extension to DLEP for layer-3 forwarding modems: http://www.ietf.org/internet-drafts/draft-taylor-manet-l3-dlep-00.txt > > We have a slot at IETF90 to present and field any questions. > > Of course, any feedback on the list is always welcome. How does this extension of DLEP interact with a peer (radio or router) that does NOT support this extension? Can I expect that a standard DLEP router drops the connection the the "extended DLEP" radio? We specified that we ignore unknown TLVs in known signals... Henning Rogge From nobody Tue Jul 8 01:46:56 2014 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 E35AC1B2ABB; Tue, 8 Jul 2014 01:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 Of6JDxinyZu9; Tue, 8 Jul 2014 01:46:47 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C7E1B2AB7; Tue, 8 Jul 2014 01:46:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,624,1400022000"; d="scan'208";a="455619727" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Jul 2014 09:46:43 +0100 X-IronPort-AV: E=Sophos;i="5.01,624,1400022000"; d="scan'208";a="57099719" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 08 Jul 2014 09:46:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.212]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 09:46:44 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "internet-drafts@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-03.txt Thread-Index: AQHPl5MBR+gfLAQ5aEGAXHxSnojT/JuVu++AgAAmbWA= Date: Tue, 8 Jul 2014 08:46:43 +0000 Message-ID: References: <20140704141934.7303.83520.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OU0mON1i09MBtFAW-juYeSb7Sdg Cc: MANET IETF , "i-d-announce@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-03.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: Tue, 08 Jul 2014 08:46:55 -0000 We'll put that in our next working draft version, so when we change for ano= ther reason (I live in hope it will be somewhere down the line) we'll make it. That will be before an RFC! I suspect your implementation will need a few minor changes, first to simpl= y always put the MPR_TYPES TLV in, and second to treat a message with and without it differently. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 08 July 2014 08:26 To: internet-drafts@ietf.org Cc: MANET IETF; i-d-announce@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-03.t= xt ----------------------! 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. -------------------------------------------------------- On Fri, Jul 4, 2014 at 4:19 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of= the IETF. > > Title : Multi-Topology Extension for the Optimized Link= State Routing Protocol version 2 (OLSRv2) > Authors : Christopher Dearlove > Thomas Heide Clausen > Filename : draft-ietf-manet-olsrv2-multitopology-03.txt The new draft looks fine... have to check my implementation again that it d= oes the right job. could you maybe replace the (FGAN) reference to (Fraunhofer FKIE)? FGAN doesn't exist anymore, it became three Fraunhofer institutes in 2009 (and my institute is Fraunhofer FKIE). Henning Rogge _______________________________________________ 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 Tue Jul 8 05:38:46 2014 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 AD8E21B2824 for ; Tue, 8 Jul 2014 05:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 o5R76TXINpA6 for ; Tue, 8 Jul 2014 05:38:43 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADED1B2827 for ; Tue, 8 Jul 2014 05:38:42 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id f8so410584wiw.10 for ; Tue, 08 Jul 2014 05:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EKlF8FE2jMGhUQflBuylC1ZGypGPgGy7bPnmlmr0Fls=; b=XA2N4i//jZTvmBNqAmLhc3Kd2bT2KWpLR4gBf71U2qpPrMmltKm1cb/gGcBUzANS5r FGcnLCW2OLYvMkx+rpTXbu9i47eQ8PT4qUJGgYboNppbXiEFzxOvJdeFyIjJo+LCWNvm vQc/ZmLAQRzVStC/7NVMBiCxAkWUqWCjGpetlH5yXCGXFlpGijCLVvgMND+bsgskgSNG 2Eu3FjI9vAfff/+Tvj/VUJaP1syoxC7nbY2P06lYA3h8T8GixEn9crLUc3YgqnTgzyrH MJRjNeL+aPPfTutMWTeGbD19YuxkgynLnGDYOw3SFGhk6ApPCSHByHUiTFWbvOOUXuyt tSYA== MIME-Version: 1.0 X-Received: by 10.180.81.37 with SMTP id w5mr3518575wix.65.1404823121356; Tue, 08 Jul 2014 05:38:41 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Tue, 8 Jul 2014 05:38:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jul 2014 14:38:41 +0200 X-Google-Sender-Auth: w2tul4wnMVwW1T10LLdmxjREpKc Message-ID: From: Jiazi YI To: Joseph Macker Content-Type: multipart/alternative; boundary=f46d04428dc01fcb8c04fdaddf1c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yuvLDiKE7pOaU-CxsAPgBrGDWMk Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] WG document adoption of draft-dearlove-manet-ibs-00.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: Tue, 08 Jul 2014 12:38:44 -0000 --f46d04428dc01fcb8c04fdaddf1c Content-Type: text/plain; charset=UTF-8 Hi, After reading the draft, I find it's an interesting and useful security extension. I support adopting it as WG document. regards Jiazi On Mon, Jun 30, 2014 at 9:11 PM, Joseph Macker wrote: > Chris/All: > > There has been a request to adopt draft-dearlove-manet-ibs-00.txt as a WG > document. > Please review and comment regarding opinions to adopt. > > The presentation request of this document is also approved for Toronto. > > URL: http://www.ietf.org/internet-drafts/draft-dearlove-manet-ibs-00.txt > > > We will be collecting WG comments on this document for the next 2 weeks > prior to making an adoption decision. > > -Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d04428dc01fcb8c04fdaddf1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

After reading the draft, I fi= nd it's an interesting and useful security extension.=C2=A0
I= support adopting it as WG document.=C2=A0

regards=

Jiazi


On Mon, Jun 30, 2014 at 9:11 PM, Joseph Macker <jpmack= er@gmail.com> wrote:
Chris/All:

There has been a request to adopt=C2=A0draft-dearlove-manet-ibs-00.txt a= s a WG document.
Please review and comment regarding opinions to adopt.=C2=A0

The presentation request of this document is also approved = for Toronto.


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


--f46d04428dc01fcb8c04fdaddf1c-- From nobody Tue Jul 8 09:22:23 2014 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 68F991B2B93; Tue, 8 Jul 2014 09:22:10 -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 7hSl5m7frnhy; Tue, 8 Jul 2014 09:22:06 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638BA1B2BA8; Tue, 8 Jul 2014 09:22:03 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id r5so5452616qcx.39 for ; Tue, 08 Jul 2014 09:22: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=7+QugL9IjyvyshAQhu7ZkScnx/DBdVbB0T0ByJmmb3M=; b=FzgGiY9RABTsqUGSRMyhnLq0UsnGTiGNOMRiK/VLDYBCXdRwFo1Wz3vwLiH/7pmve3 Vtsu/tSYW59+7VI7wAy1tuAEs6CWXF3PlyhBGRXH/icpUTjcsZpQYW4iQsddt2r+WJpS odGR0iVTz4/pa8HHYnEwEEZyfeh0yu6EIV+1nd9po9kLOoiqwvTm97D/prd0EeSZZxXx nsCYQZgQsG+PIuqOEkWIoQ9jsgyW+EgrIvBWsjbw6ybch6GmN31J/19Coq1k0huNwejX LOBeE59bQPA965mCUS2TDXB39D+T7RjqlpkpWoG7jDCWkoF66zFXJ4N0ReTcfCOql+F3 Dzhw== X-Received: by 10.224.41.65 with SMTP id n1mr61056974qae.75.1404836522308; Tue, 08 Jul 2014 09:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.113.141 with HTTP; Tue, 8 Jul 2014 09:21:42 -0700 (PDT) In-Reply-To: References: <20140704141934.7303.83520.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 8 Jul 2014 18:21:42 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6XvYXQjZuD2G_kh25Ie4cgefA3s Cc: MANET IETF , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-03.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: Tue, 08 Jul 2014 16:22:10 -0000 On Tue, Jul 8, 2014 at 10:46 AM, Dearlove, Christopher (UK) wrote: > We'll put that in our next working draft version, so when we change for another reason (I live in hope it will be > somewhere down the line) we'll make it. That will be before an RFC! Thank you. > I suspect your implementation will need a few minor changes, first to simply always put the MPR_TYPES > TLV in, and second to treat a message with and without it differently. The implementation is only on -02 level (with a few bugs I assume). I will inform you when I think its -03 capable. Henning Rogge From nobody Tue Jul 8 09:40:20 2014 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 36B291B2BBD for ; Tue, 8 Jul 2014 09:40:19 -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 NJiXXn1WpThY for ; Tue, 8 Jul 2014 09:40:17 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7AD1B2B73 for ; Tue, 8 Jul 2014 09:40:13 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jx11so5903831veb.20 for ; Tue, 08 Jul 2014 09:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rZBeVtitJ8516vmgOq7rAKGiu9RCg8fciVHBqavkbsw=; b=1BQ51WBACdanLHy6lLlLwDUgvSeEUP05Xikei0Iu/LeaeuHm0WTh5kCXU38xD4k03/ krSFeU3jQahAdOnr15M0jDENgTQnOp5cQP1gSZTmA1FrN4x0Rs8ZnqyxU1Qi8+X1vUqG mANXnGeFnwm0IbKP/gYRRAe51T3R0ZdeKpLaU= 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=rZBeVtitJ8516vmgOq7rAKGiu9RCg8fciVHBqavkbsw=; b=PM0pX3OCKwp2u+wL4lTZDxFzg/7FwuqkTJ6Swf/oGug0UEYN5ZIefNYON7/Caei8IX rAFomZhHK7bTaEvph6n9UFwtz91XMg+2fB33M6jbnc3pvvmiYcvTYN9poqYP5YvvQmua KyRoyC7D+pIT3Y8kIa/HIKiVVGZt7oDt633Cpv17zcYhSkSAjTzqWwJRJ3jkQBBzVSRq kYjUcc/XITzpCFIpS3qERRo/mq38tkCwVzQ/HPpzz6wNPgH8hveKsad6PIRbh5azLgKG Ox4OZ3tOrCW/5lX1mL2boNXphkEJVhbXpvlE4sENSTQwTFqq/XgasdUJY1LrlknFXCLF wYrg== X-Gm-Message-State: ALoCoQnfTPlyHwf3DC4Lnbypa3kxdiWDTwTdg8HlRGJ1fb8XYrxZPSPBVj6e2/nA3aBNQc90GnJ5 MIME-Version: 1.0 X-Received: by 10.58.235.130 with SMTP id um2mr34557351vec.18.1404837612333; Tue, 08 Jul 2014 09:40:12 -0700 (PDT) Received: by 10.220.124.5 with HTTP; Tue, 8 Jul 2014 09:40:12 -0700 (PDT) In-Reply-To: References: <20140704161110.8553.84425.idtracker@ietfa.amsl.com> <400A9F34-F037-4CAA-8FB8-3F153A2FE0A8@thomasclausen.org> Date: Tue, 8 Jul 2014 09:40:12 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fUFsA4c5dFAgolkIKBPpZinDn78 Cc: manet IETF , Thomas Clausen Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-management-snapshot-01.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: Tue, 08 Jul 2014 16:40:19 -0000 Hi Henning, thanks for your review! See inline (only my comments, not yet discussed with my co-author) On Tue, Jul 8, 2014 at 12:36 AM, Henning Rogge wrote: > [...] > > I think section 3.1 is worded a bit strong... its true that RFC5444 > messages can only contain a single address type as addresses, but > RFC5444 packets can contain messages with different address lengths. > > The section reads (for me) that you cannot support both IPv4 and IPv6 > within the same routing daemon, which is not true. The olsr.org > implementation does exactly this (even without my optimization > tricks), it even runs a single dijkstra over a set of both IPv4 and > IPv6 OLSRv2 nodes and edges. I agree that this section needs some word-smiting. Good points! > Do we want to mention that most Freifunk/Funkfeuer networks use TCP > based queries (either pure text of HTML) with JSON output to query the > state of the OLSR (v1) implementation... the OLSRv2 implementation of > olsr.org will allow to do the same. We could indeed mention that as an example of alternative interfaces for managing MANET routers. I think it's a good idea. > Would it be interesting to see if we can standardize a JSON query > interface? Or if we can map the SNMP definitions to JSON in a > reasonable way? That is a bigger question than can (or should IMO) be handled in this draft, but a very interesting one. And it may be even bigger than MANET. Are you aware of the COMAN mailing list? They have discussed management of constrained devices for some time, although so far no BoF has resulted from these discussions. In the 6lo WG, we have similar discussions for how to manage constrained devices. There are proposals to reuse Yang models via HTTP (draft-bierman-netconf-restconf-04) or COAP (raft-vanderstok-core-comi-04). It would definitely be good to reuse existing management interfaces (such as MIB modules and YANG). The IESG has released a statement to prefer YANG over MIB modules for writable configuration: http://www.ietf.org/iesg/statement/writable-mib-module.html I just recently had a phone call with three "B"-ADs on this topic (Benoit, Barry and Brian), and they promised to send out an email to multiple WGs regarding this topic, as it may require a cross-WG effort (the email is still pending). Coming back to your suggestion, JSON may be a good approach to manage devices. And it's good to see that you already have an implementation. I think we should discuss this more in Toronto. Will you be there? Best regards Ulrich From nobody Tue Jul 8 10:12:35 2014 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 EF3B11B2BC9 for ; Tue, 8 Jul 2014 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 Hi_tklHrQmOH for ; Tue, 8 Jul 2014 10:12:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F9A1B2B40 for ; Tue, 8 Jul 2014 10:12:29 -0700 (PDT) Received: from CO1PR07MB345.namprd07.prod.outlook.com (10.141.51.25) by CO1PR07MB347.namprd07.prod.outlook.com (10.141.51.18) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 17:12:26 +0000 Received: from CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.159]) by CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.159]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 17:12:26 +0000 From: "Soyata, Tolga" To: "manet@ietf.org" Thread-Topic: Call for Papers (one week left for submission) - CSNA 2014 Publicity Thread-Index: Ac+az8AXRPZemCwDQsOjEYHueeNjBg== Date: Tue, 8 Jul 2014 17:12:24 +0000 Message-ID: <6d2fc607765e4296b65e4bc071cf6a4d@CO1PR07MB345.namprd07.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.151.160.221] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(76482001)(77096002)(77982001)(101416001)(46102001)(85306003)(107886001)(80022001)(75432001)(15202345003)(88552001)(99286002)(86362001)(4396001)(92566001)(50986999)(95666004)(54356999)(99396002)(19300405004)(74662001)(19609705001)(15975445006)(79102001)(87936001)(31966008)(66066001)(105586002)(81542001)(16799955002)(81342001)(16601075003)(106356001)(19580395003)(89122001)(64706001)(229853001)(76576001)(2351001)(107046002)(16236675004)(110136001)(74502001)(18717965001)(19625215002)(20776003)(2656002)(21056001)(83322001)(33646001)(85852003)(74316001)(83072002)(225293001)(108616002)(24736002)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB347; H:CO1PR07MB345.namprd07.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_6d2fc607765e4296b65e4bc071cf6a4dCO1PR07MB345namprd07pro_" MIME-Version: 1.0 X-OriginatorOrg: rochester.edu Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rIJR7SCMUhSzTfqIaWRLKA62jdM Subject: [manet] Call for Papers (one week left for submission) - CSNA 2014 Publicity 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, 08 Jul 2014 17:12:34 -0000 --_000_6d2fc607765e4296b65e4bc071cf6a4dCO1PR07MB345namprd07pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE International Workshop on Cloud Computing Systems, Networks, and Applications (CCSNA) (Apologies for multiple copies) Organized in conjunction with IEEE Global Communications Conference (GLOBECOM 2014) 8-12 December 2014, Austin, Texas, USA Workshop web: http://cloud.it.teithe.gr/ EDAS submission web link: https://edas.info/newPaper.php?c=3D17545 Paper submission deadline: July 15, 2014 Cloud Computing, as well as Cloud-inspired business models, enable on-deman= d access to a shared pool of resources, namely computing, storage, networks= , services, and applications. With the advent of Cloud-based systems, cloud= operators have been aiming at reliable, secured, privacy-preserving and co= st-efficient cloud design and management. As the Cloud infrastructure aims = at offering various IT resources as services, requirements of Cloud applica= tions vary based on the resources which are requested as services. Thus, th= e resources may refer to heavy computation resources, massive storage resou= rces, high-capacity network resources and so on. The heterogeneity of cloud= applications leads to the challenge of holistic design of a robust Cloud s= ystem which can oversee and handle the diverse needs of numerous types of a= pplications. On the other hand, these challenges enforce cooperation of var= ious players in the Cloud system, each of which focuses on a different segm= ent such as network, computing, applications, and systems. The Second Inter= national workshop on Cloud Computing Systems, Networks, and Applications (C= CSNA-2014) aims at the crossroads between scientists, researchers, practiti= oners and students from diverse domains in Cloud computing research. The wo= rkshop aims at attracting contributions of system and network design that c= an support existing and future applications and services. Researchers are e= ncouraged to submit original research contributions in all major areas, whi= ch include, but not limited to: *Cloud computing systems and networking- principles, designs, analyses, and= performance -Theoretical analysis for cloud systems -Cloud system and network design -Optimization for cloud computing, networking, and applications -Green cloud systems and networking -Storage, data, and analytics for clouds design and networking -Virtualization for cloud computing systems and networking -Modeling and performance analysis for cloud system, network and storage -Intra-cloud/inter-cloud computing and networking -Cloud computing architectures and cloud solution design patterns -Cloud migration, composition, federation, bridging, and bursting -Cloud provisioning and migration -Cloud DevOps -Cloud system design with FPGA, GPU, APU -Network Programmability, Software-Defined Networking and Virtual Ethernet = Switching *Big data, data centers, and cloud managements -Big data storage and networking -Real-time resource reporting and monitoring for cloud management -Cloud quality management and service level agreement (SLA) -Cloud configuration, performance, and capacity management -Cloud workload profiling and deployment control -Autonomic business process and workflow management in clouds -Collaboration, management, and administration of clouds and services -Quality of service on clouds and applications, including reliability, avai= lability -Scalability, performance, and load balance -Knowledge engineering and data mining techniques and systems on clouds -Data center network management, reliability, optimization, and bridging -Distributed data center architectures -Cloud traffic engineering and control-plane architectures *Cloud services, applications, security, and interdisciplinary topics -Cloud system and storage security -Mobile cloud system design -Cloud media and storage design -Security, privacy, and compliance management for clouds -Self-service cloud portal, dashboard, and analytics -Infrastructure, platform, application, business, social, and mobile clouds -Security, privacy, and compliance management for public, private, and hybr= id clouds -Innovative cloud applications and experiences -Economic, business and ROI models for cloud computing -Mobile-aware networking, protocols, and infrastructures -Content and service distribution in clouds -Audit, authentication and authorization in clouds -Service-oriented architecture in clouds -Cloud support for IoTs and their services -Cloud for service discovery -Image processing and efficient video transmission on clouds -Multimedia service provisioning on clouds -MapReduce -Resilience, fault tolerance *Surveys -Surveys on any topics above Submission Procedure Submitted papers must represent original material which is not currently un= der review in any other conference or journal and has not been previously p= ublished. Paper length should not exceed five-page standard IEEE conference= two-column format (including all text, figures, and references). Please se= e the Author Information page for submission guidelines in the IEEE GLOBECO= M 2014 website http://www.ieee-globecom.org. All submitted papers will go t= hrough a peer review process. All accepted and presented papers will be inc= luded in the IEEE GLOBECOM 2014 proceedings and IEEE digital library. IEEE = reserves the right to exclude an accepted and registered but not presented = paper from the IEEE digital library. Selected papers will be invited to be= peer-reviewed for a special issue in an IEEE journal and another journal s= pecial issue. Honorary General Chair Rajkumar Buyya, University of Melbourne, Australia General co-Chairs: Andy Rindos, IBM Research, USA Periklis Chatzimisios, Alexander TEI of Thessaloniki, Greece Technical Program co-Chairs: Burak Kantarci, University of Ottawa, Canada Kun Yang, University of Essex, U.K, Di Wu, Sun Yat-sen University, China Invited Speaker and Panel Co-Chairs: Luca Foschini (University of Bologna, Italy) Sun Zhili (University of Surrey, UK) Fen Hou ( University of Macau, China) Publication and EDAS Co-Chairs: Ranga Rao Venkatesha Prasad (Delft University of Technology, Netherlands) Berk Canberk (Istanbul Technical University, Turkey) Publicity Co-chairs Elhadj Benkhelifa, (Staffordshire University, UK) Tolga Soyata (University of Rochester) Ying Qian (East China Normal University, China) Christos Kouroupetroglou (Alexander TEI of Thessaloniki, Greece) Liang Zhou, Nanjing University of Posts and Telecommunications, China) Steering Committee Chuan Heng Foh (University of Surrey,UK) Jinsong Wu (Alcatel-Lucent, China) Yaser Jararweh (Jordan University of Science and Technology, Jordan) Mladen Vouk (North Carolina State University, USA) Important Dates Paper submission deadline: July 15, 2014 Author notification: August 20, 2014 Camera ready: October 1, 2014 --_000_6d2fc607765e4296b65e4bc071cf6a4dCO1PR07MB345namprd07pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

IEEE International Workshop= on

Cloud Computing Systems, Networks, and Applications (CCSNA= )

 

(Apologies for multip= le copies)

 

Organized in conjunction wi= th

IEEE Global Communicatio= ns Conference (GLOBECOM 2014) 

8-12 December 2014, Austin,= Texas, USA

Workshop web: http://cloud.it.teithe.gr/ 

 

EDAS submission web link: https://edas.info/newPaper.php?c=3D1= 7545

 =

Paper submission deadline: July 15= , 2014

 =

Cloud Computing, as well as Cloud-inspired business model= s, enable on-demand access to a shared pool of resources, namely computing,= storage, networks, services, and applications. With the advent of Cloud-based systems, cloud operators have been aiming a= t reliable, secured, privacy-preserving and cost-efficient cloud design and= management. As the Cloud infrastructure aims at offering various IT resour= ces as services, requirements of Cloud applications vary based on the resources which are requested as serv= ices. Thus, the resources may refer to heavy computation resources, massive= storage resources, high-capacity network resources and so on. The heteroge= neity of cloud applications leads to the challenge of holistic design of a robust Cloud system which can ove= rsee and handle the diverse needs of numerous types of applications. On the= other hand, these challenges enforce cooperation of various players in the= Cloud system, each of which focuses on a different segment such as network, computing, applications, and syste= ms. The Second International workshop on Cloud Computing Systems, Networks,= and Applications (CCSNA-2014) aims at the crossroads between scientists, r= esearchers, practitioners and students from diverse domains in Cloud computing research. The workshop aims at att= racting contributions of system and network design that can support existin= g and future applications and services. Researchers are encouraged to submi= t original research contributions in all major areas, which include, but not limited to:

*C= loud computing systems and networking- principles, designs, analyses, and p= erformance

-T= heoretical analysis for cloud systems

-C= loud system and network design

-O= ptimization for cloud computing, networking, and applications

-G= reen cloud systems and networking

-S= torage, data, and analytics for clouds design and networking

-V= irtualization for cloud computing systems and networking<= /p>

-M= odeling and performance analysis for cloud system, network and storage=

-I= ntra-cloud/inter-cloud computing and networking

-C= loud computing architectures and cloud solution design patterns<= /span>

-C= loud migration, composition, federation, bridging, and bursting<= /span>

-C= loud provisioning and migration

-C= loud DevOps

-C= loud system design with FPGA, GPU, APU

-N= etwork Programmability, Software-Defined Networking and Virtual Ethernet Sw= itching

&n= bsp;

&n= bsp;

*B= ig data, data centers, and cloud managements

-B= ig data storage and networking

-R= eal-time resource reporting and monitoring for cloud management<= /span>

-C= loud quality management and service level agreement (SLA)=

-C= loud configuration, performance, and capacity management<= /p>

-C= loud workload profiling and deployment control

-A= utonomic business process and workflow management in clouds

-C= ollaboration, management, and administration of clouds and services

-Q= uality of service on clouds and applications, including reliability, availa= bility

-S= calability, performance, and load balance

-K= nowledge engineering and data mining techniques and systems on clouds<= /o:p>

-D= ata center network management, reliability, optimization, and bridging=

-D= istributed data center architectures

-C= loud traffic engineering and control-plane architectures<= /p>

&n= bsp;

*C= loud services, applications, security, and interdisciplinary topics

-C= loud system and storage security

-M= obile cloud system design

-C= loud media and storage design

-S= ecurity, privacy, and compliance management for clouds

-S= elf-service cloud portal, dashboard, and analytics

-I= nfrastructure, platform, application, business, social, and mobile clouds

-S= ecurity, privacy, and compliance management for public, private, and hybrid= clouds

-I= nnovative cloud applications and experiences

-E= conomic, business and ROI models for cloud computing

-M= obile-aware networking, protocols, and infrastructures

-C= ontent and service distribution in clouds

-A= udit, authentication and authorization in clouds

-S= ervice-oriented architecture in clouds

-C= loud support for IoTs and their services

-C= loud for service discovery

-I= mage processing and efficient video transmission on clouds

-M= ultimedia service provisioning on clouds

-M= apReduce

-R= esilience, fault tolerance

&n= bsp;

*S= urveys

-S= urveys on any topics above

 

Submission Procedure

Submitted papers must represe= nt original material which is not currently under review in a= ny other conference or journal and has not been previously published. Paper= length should not exceed five-page standard IEEE conference two-c= olumn format (including all text,= figures, and references). Please see the Autho= r Information page for submission guidelines in the IEEE GLOBECOM 2014 webs= ite http://www.ieee-globecom.org. All submitted papers= will go through a peer review process. All accepted and pre= sented papers will be included in the IEEE GLOBECOM 2014 proceedings and IE= EE digital library. IEEE reserves the right to exclude an accepted and regi= stered but not presented paper from the IEEE digital library.  Selected papers will be invited to be p= eer-reviewed for a special issue in an IEEE journal and another journal spe= cial issue.

 

Honorary General Chair

Rajkumar Buyya, University of Melbo= urne, Australia

 <= o:p>

General co-Chairs:

Andy Rindos, IBM Research, USA

Periklis Chatzimisios, Alexander TE= I of Thessaloniki, Greece

 

Technical Program co-Chairs:

Burak Kantarci, University of Ottaw= a, Canada

Kun Yang, University of Essex, U.K,

Di Wu, Sun Yat-sen University, Chin= a

 

Invited Speaker and Panel Co-Cha= irs: 

Luca Foschini (University of Bologn= a, Italy)

Sun Zhili (University of Surrey, UK= )

Fen Hou ( University of Macau, Chin= a)

 

Publication and EDAS Co-Chairs:&= nbsp;

Ranga Rao Venkatesha Prasad (Delft = University of Technology, Netherlands)

Berk Canberk (Istanbul Technical Un= iversity, Turkey)

 

Publicity Co-chairs

Elhadj Benkhelifa, (Staffordshire U= niversity, UK)

Tolga Soyata (University of Rochest= er)

Ying Qian (East China Normal Univer= sity, China)

Christos Kouroupetroglou (Alexander= TEI of Thessaloniki, Greece) <= /span>

Liang Zhou, Nanjing University of P= osts and Telecommunications, China)<= /span>

 

Steering Committee

Chuan Heng Foh (University of Surre= y,UK) 

Jinsong Wu (Alcatel-Lucent, China) =  

Yaser Jararweh (Jordan University o= f Science and Technology, Jordan) 

Mladen Vouk (North Carolina State U= niversity, USA)

&= nbsp;

I= mportant Dates

Paper submission deadline: July 15, 2014

Author notification: August 20, 2014

Camera ready: October 1, 2014

 =

 

 

--_000_6d2fc607765e4296b65e4bc071cf6a4dCO1PR07MB345namprd07pro_-- From nobody Tue Jul 8 23:55:18 2014 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 EF7071A01D9 for ; Tue, 8 Jul 2014 23:55:16 -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 wLC7dVORxVz0 for ; Tue, 8 Jul 2014 23:55:15 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2453A1A037F for ; Tue, 8 Jul 2014 23:55:15 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so5909141qgd.38 for ; Tue, 08 Jul 2014 23:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aSxmH8+jlFhS3NnslUAOMltMJJyuSNi+sGW6JrlOzpw=; b=b6hKjMiAhS5gshL7S4uXaFrCAhRIShs+SgkiWwjss039SUIEDkPtp+GY57NMWmWiu7 ix35JLTSIbi2X3v6sP7TIM8vxbZV7Qo+VmTqEuHsadRzZfPT5J3VOImPpOYvzLE+9lB3 34CwtOr9YTn8Jpe3qyHqawrCGq5IiTs3NdqrKrfHPxRdZS6brse4SSnnEaK6mgJ5XZft WDIO4iCGDLm/VA7SmqnJKqArLWqFScvkgCnDBpnZeAgwG82Zkr9frbY5f8GV+6oc5vor 9eNy2lZO8QDGTl3y9LC4n8ttBqdfplvpKpgCqprCPbW9RFdIk40rCq1FVhplBuQIM4u0 W8Yw== X-Received: by 10.140.108.99 with SMTP id i90mr64432376qgf.56.1404888914353; Tue, 08 Jul 2014 23:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 8 Jul 2014 23:54:54 -0700 (PDT) In-Reply-To: References: <20140704161110.8553.84425.idtracker@ietfa.amsl.com> <400A9F34-F037-4CAA-8FB8-3F153A2FE0A8@thomasclausen.org> From: Henning Rogge Date: Wed, 9 Jul 2014 08:54:54 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ciBgd9laa17WivZEBDnyVAmPngc Cc: manet IETF , Thomas Clausen Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-management-snapshot-01.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, 09 Jul 2014 06:55:17 -0000 On Tue, Jul 8, 2014 at 6:40 PM, Ulrich Herberg wrote: >> Would it be interesting to see if we can standardize a JSON query >> interface? Or if we can map the SNMP definitions to JSON in a >> reasonable way? > > That is a bigger question than can (or should IMO) be handled in this > draft, but a very interesting one. And it may be even bigger than > MANET. Are you aware of the COMAN mailing list? No. > They have discussed > management of constrained devices for some time, although so far no > BoF has resulted from these discussions. In the 6lo WG, we have > similar discussions for how to manage constrained devices. There are > proposals to reuse Yang models via HTTP > (draft-bierman-netconf-restconf-04) or COAP > (raft-vanderstok-core-comi-04). It would definitely be good to reuse > existing management interfaces (such as MIB modules and YANG). The > IESG has released a statement to prefer YANG over MIB modules for > writable configuration: > http://www.ietf.org/iesg/statement/writable-mib-module.html I need to look at these drafts when I find the necessary time. > I just recently had a phone call with three "B"-ADs on this topic > (Benoit, Barry and Brian), and they promised to send out an email to > multiple WGs regarding this topic, as it may require a cross-WG effort > (the email is still pending). > > Coming back to your suggestion, JSON may be a good approach to manage > devices. And it's good to see that you already have an implementation. One reason for JSON seems to be that it can be easily parsed by shell scripts and LUA scripts (which is common on OpenWRT because the interpreter is very compact). > I think we should discuss this more in Toronto. Will you be there? Unfortunately not. Henning Rogge From nobody Wed Jul 9 05:07:29 2014 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 E416D1A04A2 for ; Wed, 9 Jul 2014 05:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.795 X-Spam-Level: ** X-Spam-Status: No, score=2.795 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 trGGWO0Y7i9H for ; Wed, 9 Jul 2014 05:07:25 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 B3E371A04A1 for ; Wed, 9 Jul 2014 05:07:24 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 9 Jul 2014 13:06:56 +0100 From: Rick Taylor To: Henning Rogge Thread-Topic: [manet-dlep-rg] DLEP extension draft submitted Thread-Index: AQHPmoSsLF6luvJHIkuVJODPYcCk+ZuXpomg Date: Wed, 9 Jul 2014 12:06:58 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98011399E53B@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98011399A404@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/994OyJdOp25kXinCiAWGwEjWflc Cc: "manet-dlep-rg@ietf.org Group, \(manet-dlep-rg@ietf.org\)" , "manet@ietf.org" Subject: Re: [manet] [manet-dlep-rg] DLEP extension draft submitted 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, 09 Jul 2014 12:07:27 -0000 PkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwuY29tXSANCg0KPiBIb3cg ZG9lcyB0aGlzIGV4dGVuc2lvbiBvZiBETEVQIGludGVyYWN0IHdpdGggYSBwZWVyIChyYWRpbyBv ciByb3V0ZXIpIHRoYXQgZG9lcyBOT1Qgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbj8gQ2FuIEkgZXhw ZWN0IHRoYXQgYSBzdGFuZGFyZCBETEVQIHJvdXRlciBkcm9wcyB0aGUgY29ubmVjdGlvbiB0aGUg dGhlICJleHRlbmRlZCBETEVQIiByYWRpbz8gV2Ugc3BlY2lmaWVkIHRoYXQgd2UgaWdub3JlIHVu a25vd24gVExWcyBpbiBrbm93biBzaWduYWxzLi4uDQoNClRoaXMgaXMgb25lIG9mIHRoZSBhcmVh cyBJIGFtIHJlYWxseSBob3BpbmcgdGhhdCB0aGUgY29yZSBETEVQIHNwZWMgc29ydHMgb3V0LiAg VGhlIGVycm9yIGhhbmRsaW5nIGZvciB0aGlzIGtpbmQgb2YgdGhpbmcgaXMgY3VycmVudGx5IHRv byBsb29zZSBmb3IgbXkgbGlraW5nLCBhbmQgSSBleHBlY3QgdG8gaGF2ZSB0byBjaGFuZ2UgdGhh dCBwYXJ0IG9mIHRoZSB0ZXh0IGFzIHRoZSBuZXh0IGRyYWZ0IG9mIERMRVAgY29tZXMgb3V0Lg0K DQpSaWNrDQo= From nobody Wed Jul 9 05:12:17 2014 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 4A07A1A04CA for ; Wed, 9 Jul 2014 05:12:15 -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 3EnjdOonaTtP for ; Wed, 9 Jul 2014 05:12:13 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFCB1A04B0 for ; Wed, 9 Jul 2014 05:12:13 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so6399567qcx.22 for ; Wed, 09 Jul 2014 05:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=G6NWOxB/IumqddMeB41HhVHQOgVV+pvst/D6VqE4cq4=; b=Dxo0yZA6WdNMid+lSt6/MWhSh4VOzIhNUiUJ83QM83SlJV2sUhbItAJ6ebxt4/LeQy WwDe6dO152+yDD9xFT/OdmDpdPocbkT2gA9xupMndjiLoZQa9wjaERhEdDzXxJvTh4Of jgxORxMuRIQbFBvtT897w7FiCrgeZfJy8744vtJGq9Itwbb8VkmkMXH7u22R2AFfRpk8 40/Qv0DimgB36lgQmfYcohZH9Dq5mvmvbNGAdzZXukHLzWs81fy3/aoG56WVbHwGLnus 1ykyGYOfdn/pcFWbrLVqxhAl55PuNTdTwrXTyns5jV7+V7VKog8CjPNYN9UlywWkJtgQ 4eJQ== X-Received: by 10.229.117.136 with SMTP id r8mr66521091qcq.17.1404907931368; Wed, 09 Jul 2014 05:12:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 9 Jul 2014 05:11:51 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98011399E53B@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98011399A404@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98011399E53B@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Wed, 9 Jul 2014 14:11:51 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1ucJn1tE_cDJX_n3UoCaKtVEIhQ Cc: "manet-dlep-rg@ietf.org Group, \(manet-dlep-rg@ietf.org\)" , "manet@ietf.org" Subject: Re: [manet] [manet-dlep-rg] DLEP extension draft submitted 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, 09 Jul 2014 12:12:15 -0000 On Wed, Jul 9, 2014 at 2:06 PM, Rick Taylor wrote: >>From: Henning Rogge [mailto:hrogge@gmail.com] > >> How does this extension of DLEP interact with a peer (radio or router) t= hat does NOT support this extension? Can I expect that a standard DLEP rout= er drops the connection the the "extended DLEP" radio? We specified that we= ignore unknown TLVs in known signals... > > This is one of the areas I am really hoping that the core DLEP spec sorts= out. The error handling for this kind of thing is currently too loose for= my liking, and I expect to have to change that part of the text as the nex= t draft of DLEP comes out. The problem I see is that this specification breaks the basic assumptions of DLEP (the bridged radio). This means its not an extenstion of the DLEP draft but it shares some signalling. Henning Rogge From nobody Wed Jul 9 23:23:51 2014 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 DBED91A034F for ; Wed, 9 Jul 2014 23:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 dVlOj1Vod-XX for ; Wed, 9 Jul 2014 23:23:49 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3063C1A026F for ; Wed, 9 Jul 2014 23:23:48 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so8455961wes.29 for ; Wed, 09 Jul 2014 23:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E6a+FZIaf6K2H4rxgTxSor9xfP1JclBndyPLAZ6J0UE=; b=yvWEr9XMopluufwQJ3ao0QqTrwlVQ4+Rr1CUzxPsWnbgSLzEFmKAclDeQ7EO7v7ZPz GlV0vQ91RHll43dKyD37Jraag3o+jTNLWFsz2kllfKGM5PW/YQZXgur+wbL7lCpItx6F /i0Tdhr2I7mC+jznqleMO+PhRkM10f3xw+aA39wOULzxCnJaURFUKn/3DEWEqDeEWqEc c6yr8P4ksaNrE786wdsoYFsxSnTc6XKq0UeJbIxfj7TyIjN33zhCxnX514BYn2WbTE8z wDT/O93GLEyMCvetCNXvuiF4McK7SWPD5Ftx54p1yuHsT23gmhMu92BpYLqAg/Hra08o c3Zw== MIME-Version: 1.0 X-Received: by 10.180.210.132 with SMTP id mu4mr16352885wic.18.1404973427514; Wed, 09 Jul 2014 23:23:47 -0700 (PDT) Received: by 10.180.89.161 with HTTP; Wed, 9 Jul 2014 23:23:47 -0700 (PDT) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F98011399A404@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98011399E53B@tss-server1.home.tropicalstormsoftware.com> Date: Thu, 10 Jul 2014 07:23:47 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c25daa10e2a604fdd0de4c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BIL2clCYOP4_gNQ5iNKzRnXjxWE Cc: "manet-dlep-rg@ietf.org Group, \(manet-dlep-rg@ietf.org\)" , "manet@ietf.org" Subject: Re: [manet] [manet-dlep-rg] DLEP extension draft submitted 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, 10 Jul 2014 06:23:51 -0000 --001a11c25daa10e2a604fdd0de4c Content-Type: text/plain; charset=UTF-8 I see this extension reasonable, it is not able to be interacting with our DLEPv1 but it may be called DLEP-E to distinguish that it is not interacting with DLEP. I hope we finish DLEP to look into this interesting draft. AB On Wed, Jul 9, 2014 at 1:11 PM, Henning Rogge wrote: > On Wed, Jul 9, 2014 at 2:06 PM, Rick Taylor > wrote: > >>From: Henning Rogge [mailto:hrogge@gmail.com] > > > >> How does this extension of DLEP interact with a peer (radio or router) > that does NOT support this extension? Can I expect that a standard DLEP > router drops the connection the the "extended DLEP" radio? We specified > that we ignore unknown TLVs in known signals... > > > > This is one of the areas I am really hoping that the core DLEP spec > sorts out. The error handling for this kind of thing is currently too > loose for my liking, and I expect to have to change that part of the text > as the next draft of DLEP comes out. > > The problem I see is that this specification breaks the basic > assumptions of DLEP (the bridged radio). This means its not an > extenstion of the DLEP draft but it shares some signalling. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c25daa10e2a604fdd0de4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see this extension reasonable, it is not able to be= =C2=A0interacting with our=C2=A0DLEPv1 but it may be=C2=A0called DLEP-E to = distinguish that it is not interacting with DLEP. I hope we finish DLEP to = look into this interesting draft.

AB


On Wed, Jul 9, 2014 at 1:11 PM, Henning Rogge <hrogge@= gmail.com> wrote:
On Wed, Jul 9, 2014 at 2:06 PM, Rick Ta= ylor
<rick@tropicalstormsof= tware.com> wrote:
>>From: Henning Rogge [mailto:hro= gge@gmail.com]
>
>> How does this extension of DLEP interact with a peer (radio or rou= ter) that does NOT support this extension? Can I expect that a standard DLE= P router drops the connection the the "extended DLEP" radio? We s= pecified that we ignore unknown TLVs in known signals...
>
> This is one of the areas I am really hoping that the core DLEP spec so= rts out. =C2=A0The error handling for this kind of thing is currently too l= oose for my liking, and I expect to have to change that part of the text as= the next draft of DLEP comes out.

The problem I see is that this specification breaks the basic
assumptions of DLEP (the bridged radio). This means its not an
extenstion of the DLEP draft but it shares some signalling.

Henning Rogge

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

--001a11c25daa10e2a604fdd0de4c-- From nobody Thu Jul 10 21:37:53 2014 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 11FAF1A02EE for ; Thu, 10 Jul 2014 21:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 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, RP_MATCHES_RCVD=-0.651] 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 a1gbk11IoDe7 for ; Thu, 10 Jul 2014 21:37:50 -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 295331A02E6 for ; Thu, 10 Jul 2014 21:37:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=R7cOxSRzoTNNwgz3Eyy+UAald7ysunurJd36o3IUM+0MDv2bp5QAbIm9Cf16X4C0; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X5SZU-0008RT-WF; Fri, 11 Jul 2014 00:36:33 -0400 Message-ID: <53BF69CE.7060702@earthlink.net> Date: Thu, 10 Jul 2014 21:36:30 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ulrich Herberg , manet@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7e87c8846c8891dce40fa1b0bf118ce49350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/58t-D_41aVJJbBrWDAF1GYwFf78 Subject: Re: [manet] Slot requests 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, 11 Jul 2014 04:37:52 -0000 Hello Ulrich, Please schedule at least 30 minutes for reporting on the current status of AODVv2. Regards, Charlie P. On 6/23/2014 11:34 AM, Ulrich Herberg wrote: > Hi, > > the MANET meeting has been scheduled (preliminarily): > > manet Session 1 (2:00:00) > Tuesday, Afternoon Session II 1420-1620 > Room Name: Manitoba > > Please send your requests for slots during the meeting. > > Thanks > Ulrich > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Thu Jul 10 21:45:06 2014 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 B5EA01A0290 for ; Thu, 10 Jul 2014 21:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 WE3gro2kQiTW for ; Thu, 10 Jul 2014 21:45:02 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id DD0831A028E for ; Thu, 10 Jul 2014 21:45:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QfmYOtPssWjj1wdFV2/F3XjnjiBUVnQVSnSQoF36JLtgszolYHROg8U6MbAzjVEJ; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X5Shh-0006eg-6H for manet@ietf.org; Fri, 11 Jul 2014 00:45:01 -0400 Message-ID: <53BF6BCA.1050900@earthlink.net> Date: Thu, 10 Jul 2014 21:44:58 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7bf450f257335a936e82db7df6394b2b4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/A1VHW_rOm3f66jXL7F_5oyS-Yjo Subject: [manet] Updated version of AODVv2 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, 11 Jul 2014 04:45:03 -0000 Hello folks, I have posted an updated version of AODVv2 at the following URL: The biggest change by far is the inclusion of the appendix containing the algorithms. The other changes have to do with issue resolution as we have discussed in preceding weeks. I have not resolved any new issues except by way of including the algorithms. http://www.psg.com/~charliep/ietf90/draft-ietf-manet-aodvv2-pre04.txt I had intended to upload this before the deadline, but then I found out that the deadline was Friday instead of Monday. That was a big disappointment, sorry about that; I used the last few days for some additional proofreading. The appendix containing the algorithms still needs more polishing, but it is ready for review by interested WG members. During the preparation of this revision, I have identified some more issues that I will insert into the issue tracker shortly. Also to come, a new revision of the draft for Intermediate RREP, a feature that was (perhaps mistakenly) isolated from the main AODVv2 specification. Regards, Charlie P. From nobody Fri Jul 11 07:24:52 2014 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 A44001B2B52 for ; Fri, 11 Jul 2014 07:24:47 -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 lyqsr7XEkXb1 for ; Fri, 11 Jul 2014 07:24:46 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253E21B2B23 for ; Fri, 11 Jul 2014 07:24:25 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id ij19so2233396vcb.9 for ; Fri, 11 Jul 2014 07:24:25 -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=Sve7eh7JT73xCvrzTckPUXrgGZeNmlDxrXTE3hiEiww=; b=YSgITK9OKUoUcuCF3HLXSauKcFWYPCjl7i6KiHbK++QXUfemjh/IM3l4QJIh+2m9ID x9EsnfpqONm3QXMo9Gdeaba9GqUIUhrzDJUTIOLiyidL9kv/K9ir2tYw5YYZBmggMLOz okn4pQVZ3aEkl9PAJZ1ygS3DysR0K9ndON2FI= 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=Sve7eh7JT73xCvrzTckPUXrgGZeNmlDxrXTE3hiEiww=; b=S/yL0OfJv7rvkUY50lWIRHcyFezVoBO8sqSAYsgwGAhjvN5sucEoe/zzBQbkbK/iyQ ItJV+mftM9HtqQTe5n+jH9DGmqjVQ7/N6Ty9zgl6dXpiV2vdLF/PxG102KbEBIHv+MND tdDluooD2fb1/fzVprWWxNasMbXLG/sDRSkNIlKiWmPoLj+lS9D3r6vmuOdM2tk9+0py QQXjhoWcbuiI4UgqOByhcDVb5Ancs506E9lTc1ZGVtbALP+HIghGM84ovKuH8hTHQ4W6 p6IpyyhlGu8Hki0rGhNHZR2B3muKVHu16JTZkiwzxnJscmjN/3QZDJZi8prpUnlNtZoj 9y0g== X-Gm-Message-State: ALoCoQnIH8LtEfGdN46tTxG+WIt4vHdH9DJRH0hhKEPltP0dcPYGK7wC6p2FoXUbTAm3IB7PUr5f MIME-Version: 1.0 X-Received: by 10.220.160.67 with SMTP id m3mr1032946vcx.56.1405088664986; Fri, 11 Jul 2014 07:24:24 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Fri, 11 Jul 2014 07:24:24 -0700 (PDT) In-Reply-To: <53BF69CE.7060702@earthlink.net> References: <53BF69CE.7060702@earthlink.net> Date: Fri, 11 Jul 2014 07:24:24 -0700 Message-ID: From: Ulrich Herberg To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vWcjG3MVXjNfpZ29s6PjDcV-ZzA Cc: manet@ietf.org Subject: Re: [manet] Slot requests 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, 11 Jul 2014 14:24:47 -0000 Hello Charlie, I will discuss this with the chairs and let you know. Regardless of what they decide, I'd really appreciate in the future to receive slot requests (in particular such large ones) several days *before* the first draft agenda deadline, not one business day before the final deadline. As you can see, the agenda is already very dense, so this will make it more difficult for me to schedule the meeting. Thanks Ulrich On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins wrote: > Hello Ulrich, > > Please schedule at least 30 minutes for reporting on the > current status of AODVv2. > > Regards, > Charlie P. > > > > On 6/23/2014 11:34 AM, Ulrich Herberg wrote: >> >> Hi, >> >> the MANET meeting has been scheduled (preliminarily): >> >> manet Session 1 (2:00:00) >> Tuesday, Afternoon Session II 1420-1620 >> Room Name: Manitoba >> >> Please send your requests for slots during the meeting. >> >> Thanks >> Ulrich >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > From nobody Fri Jul 11 08:12:41 2014 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 144B01B2B06 for ; Fri, 11 Jul 2014 08:12:39 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ttns8igMlWEp for ; Fri, 11 Jul 2014 08:12:37 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9400F1B2B17 for ; Fri, 11 Jul 2014 08:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 3FCE62203CE; Fri, 11 Jul 2014 08:12:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 754632203CF; Fri, 11 Jul 2014 08:12:35 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-250C7A27-BBE9-41E9-98B8-546E2EF21294 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Fri, 11 Jul 2014 17:12:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1947E21B-820A-44DF-AB03-DDB33DFB04EC@thomasclausen.org> References: <53BF69CE.7060702@earthlink.net> To: Ulrich Herberg Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_xDdPcbTYnC5dS5l2N3nkGcyaoY Cc: Charlie Perkins , "" , "manet@ietf.org" , "" Subject: Re: [manet] Slot requests 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, 11 Jul 2014 15:12:39 -0000 --Apple-Mail-250C7A27-BBE9-41E9-98B8-546E2EF21294 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ulrich, Chairs, All, Other than the issues regarding making a meaningful agenda for the upcoming m= eeting that Ulrich correctly points out of course, I do note that ample time= for reviewing documents is a prerequisite for spending the (scarce) WG meet= ing time during IETF weeks in a meaningful fashion.=20 Announcement of an update as late as this - given that some of us have long t= ravel times to get to the venue (and, *gasp*, do follow other WGs requiring p= reparation, and do have other jobs to attend to) essentially makes it unlike= ly that time spent on this document during the meeting will be spent in a me= aningful fashion. I also note an inherent incoherence in the demand for 'at least 30min', and a= statement that this document doesn't solve any new issues. By all means, if there's a few minutes left at the end of the meeting and on= ce all other discussions have concluded, let's have an update.=20 Just don't cut other presentations/discussions short for it, don't call for a= ny decisions to be made on this doc, don't call for consensus to be express= ed on anything regarding this doc or protocol -- and do have the minutes ex= plicitly reflect that this was late update and that whatever discussions fol= low cannot be taken as indicators of position of the WG (or, of the individu= als, given that there wasn't enough time to properly read the doc in questio= n. Best, Thomas > On 11 Jul 2014, at 16:24, Ulrich Herberg wrote: >=20 > Hello Charlie, >=20 > I will discuss this with the chairs and let you know. >=20 > Regardless of what they decide, I'd really appreciate in the future to > receive slot requests (in particular such large ones) several days > *before* the first draft agenda deadline, not one business day before > the final deadline. As you can see, the agenda is already very dense, > so this will make it more difficult for me to schedule the meeting. >=20 > Thanks > Ulrich >=20 > On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins > wrote: >> Hello Ulrich, >>=20 >> Please schedule at least 30 minutes for reporting on the >> current status of AODVv2. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >>=20 >>> On 6/23/2014 11:34 AM, Ulrich Herberg wrote: >>>=20 >>> Hi, >>>=20 >>> the MANET meeting has been scheduled (preliminarily): >>>=20 >>> manet Session 1 (2:00:00) >>> Tuesday, Afternoon Session II 1420-1620 >>> Room Name: Manitoba >>>=20 >>> Please send your requests for slots during the meeting. >>>=20 >>> Thanks >>> Ulrich >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-250C7A27-BBE9-41E9-98B8-546E2EF21294 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ulrich, Chairs, All,

Other t= han the issues regarding making a meaningful agenda for the upcoming meeting= that Ulrich correctly points out of course, I do note that ample time for r= eviewing documents is a prerequisite for spending the (scarce) WG meeting ti= me during IETF weeks in a meaningful fashion. 

Announcement of an update as late as this -= given that some of us have long travel times to get to the venue (and, *gas= p*, do follow other WGs requiring preparation, and do have other jobs to att= end to) essentially makes it unlikely that time spent on this document durin= g the meeting will be spent in a meaningful fashion.

I also note an inherent incoherence in the= demand for 'at least 30min', and a statement that this document doesn't sol= ve any new issues.

By all means, if there's a few minutes left at the end of the meetin= g and once all other discussions have concluded, let's have an update. =

Just don't= cut other presentations/discussions short for it, don't call for any decisions to be made on this doc, don't c= all for  consensus to be expressed on anything regarding this doc or pr= otocol --  and do have the minutes explicitly reflect tha= t this was late update and that whatever discussions follow cannot be taken a= s indicators of position of the WG (or, of the individuals, given that there= wasn't enough time to properly read the doc in question.
<= span style=3D"-webkit-text-size-adjust: auto;">
Best,

Thomas

<= br>

On 11 Jul 2014, at 16:24, Ulrich Herber= g <ulrich@herberg.name> wro= te:

Hello Charlie,

I will d= iscuss this with the chairs and let you know.

Regardless of what they decide, I'd really appreciate in the future to
receive slot requests (in particular such large ones) several d= ays
*before* the first draft agenda deadline, not one busine= ss day before
the final deadline. As you can see, the agenda= is already very dense,
so this will make it more difficult f= or me to schedule the meeting.

Thanks
Ulrich

On Thu, Jul 10, 2014 at 9= :36 PM, Charlie Perkins
<charles.perkins@earthlink.net> wrote:
Hello Ulrich,

Please schedule at least 30 minutes for reporting on the
current status of AODVv2.

Regards,
Charlie P.
=


On 6/23/2014 11:34 AM, Ulrich Herberg wrote:
Hi,
<= blockquote type=3D"cite">
the MANET meeting has been= scheduled (preliminarily):

manet Sessio= n 1 (2:00:00)
=
    Tuesday, Afternoon S= ession II 1420-1620
    Room Name: Ma= nitoba

Please send your requests for sl= ots during the meeting.

Thanks
Ulrich

______________________= _________________________
manet mailing list
<= span>manet@ietf.org
= https://www.ietf.org= /mailman/listinfo/manet


<= br>_______________________________________________
man= et mailing list
manet@ietf= .org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-250C7A27-BBE9-41E9-98B8-546E2EF21294-- From nobody Fri Jul 11 08:27:05 2014 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 B6CE91B2B51 for ; Fri, 11 Jul 2014 08:27:03 -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 RJiGnIY7GM6W for ; Fri, 11 Jul 2014 08:27:02 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A2C1B2911 for ; Fri, 11 Jul 2014 08:27:02 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id id10so2329025vcb.24 for ; Fri, 11 Jul 2014 08:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wqWOZUMAtm+rO1oz9XA8TWaJWjCYbH5WyVh/wHxV0F0=; b=bt6QNEXwJhdhuhA4J61NPYq6AFkSye4/2ANOp8Yel4Z3DYE1Y2it9tKn6t5RwLvXGg oSWbjmdgmF6ySVb31ePcKBEVfAHVERebGIhuEb8U9rDrwm/f87EETQ4sMDHAyBEd7PTq yzeCXyrqvRwZcbyGUDbht5sx7dQ0KeAslq1bQ= 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=wqWOZUMAtm+rO1oz9XA8TWaJWjCYbH5WyVh/wHxV0F0=; b=dC0utMX9yAktJizW30PNRq1Zw8wluDN77fzqVUxEPvta233mFcsilx1LPEFyyU82DB JK2GJ/CPuv89dqbcnzj3xLDFEf7BWEoEQkiRtzHYuWizCVeQTo3S88EEXuCBbYu9dZg7 uwYtJJBPT1tPEzOVTJH4b4M+ZHx7p0eQw6tR8wvqVbYO4qRyx8wxAW57TeHR9BSZ948z Sf9YU0OfKgO1pLTMdP9uoNNg7Bsi/LT/q0egQmxJGRCC0DsHbxtf2mh2D+i1tqQzGVv8 hVwwlXFWzjtNHjZl0SQnIBwNnfSyAYXlA7AbxEjAWK4yXgYYT/7lhUKWRC6B965pMvXl PBrA== X-Gm-Message-State: ALoCoQmG4obHICkEwIEn5fhjbzWn2rDfkFSVagd4H6bC6g5gQs1vX3vRO5a/VEky3G5/dI/LUECu MIME-Version: 1.0 X-Received: by 10.52.239.6 with SMTP id vo6mr1449615vdc.59.1405092421834; Fri, 11 Jul 2014 08:27:01 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Fri, 11 Jul 2014 08:27:01 -0700 (PDT) In-Reply-To: References: <53BF69CE.7060702@earthlink.net> Date: Fri, 11 Jul 2014 08:27:01 -0700 Message-ID: From: Ulrich Herberg To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/X3XHWMDSXJFuQS8XdN9PP7da2vc Cc: manet@ietf.org Subject: Re: [manet] Slot requests 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, 11 Jul 2014 15:27:03 -0000 Hello Charlie, I have uploaded an updated agenda. The chairs allocated you a slot of up to 20 minutes (assuming enough time is remaining at that point of the meeting). @All: As there is risk that the "open mike" slot will fall off the table, please let me know if there is anything you would like to announce during that slot (e.g., a new interop event, a new implementation, etc.) Regards Ulrich On Fri, Jul 11, 2014 at 7:24 AM, Ulrich Herberg wrote: > Hello Charlie, > > I will discuss this with the chairs and let you know. > > Regardless of what they decide, I'd really appreciate in the future to > receive slot requests (in particular such large ones) several days > *before* the first draft agenda deadline, not one business day before > the final deadline. As you can see, the agenda is already very dense, > so this will make it more difficult for me to schedule the meeting. > > Thanks > Ulrich > > On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins > wrote: >> Hello Ulrich, >> >> Please schedule at least 30 minutes for reporting on the >> current status of AODVv2. >> >> Regards, >> Charlie P. >> >> >> >> On 6/23/2014 11:34 AM, Ulrich Herberg wrote: >>> >>> Hi, >>> >>> the MANET meeting has been scheduled (preliminarily): >>> >>> manet Session 1 (2:00:00) >>> Tuesday, Afternoon Session II 1420-1620 >>> Room Name: Manitoba >>> >>> Please send your requests for slots during the meeting. >>> >>> Thanks >>> Ulrich >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> From nobody Fri Jul 11 09:21:58 2014 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 B5B7F1B2B0B for ; Fri, 11 Jul 2014 09:21:52 -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 oW_iuLa2MAXd for ; Fri, 11 Jul 2014 09:21:52 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1D01A854B for ; Fri, 11 Jul 2014 09:21:51 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id im17so2485475vcb.39 for ; Fri, 11 Jul 2014 09:21:50 -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=pEu/XC7tJCZCQmDH3yDgcZb9+z1qYyEn6nx8B66/1VU=; b=V9Bn3NkNddWEGHI9dROvi3gdG0ia6iY+fQea7pFDxyMvIce1Ez2O7ymB3q1+oQIx0Y Ec14VNM7Z7lX8Xd+smlJ/fVK32eUbQGQpEujxonjBBU+9xhGhnCUAsxU7nD/Vs1panHB /vdevqiKuYCXsYioOBQwDYpV+cAzTX2OlX0Yw= 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=pEu/XC7tJCZCQmDH3yDgcZb9+z1qYyEn6nx8B66/1VU=; b=f3mWuztdCBpSLuXGDVxRJ2zaQbEWNjn+S9kuU5oonsiTZohrCnHw8pei0XgO1LXaiU 6jkHZBw/WKCMl6A3rbyTPXoRgSBLptTy91FODGb85oankpqUr5CILLr89DNeEbxURW8m 4zbUFYjibhDMruoU2K3i0t9soFUp/GOGOjETzPqjV1kWUHgHWY4NH3af3kHgo8/ltNAe MHOYJtieiQ+hZcThBFIKX3w24hewANKnv4EcAuXkKV8S1SIhWba0HLKL5QjXqpM7XIt9 x5E2V0jHpdN7EkSci96ZHF3N82WlYg1e+/oW+ffLdSXJc5IvR2VzcXIXCVFNjQKFsx3R S1ug== X-Gm-Message-State: ALoCoQncCI1KeQoowIQJ88saNyqf9iWbhwmfBVdJDa4PYr65ODY+he5YCEAGhJ9zple7raphGSu5 MIME-Version: 1.0 X-Received: by 10.58.165.106 with SMTP id yx10mr54267073veb.17.1405095710780; Fri, 11 Jul 2014 09:21:50 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Fri, 11 Jul 2014 09:21:50 -0700 (PDT) Date: Fri, 11 Jul 2014 09:21:50 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gkPOSm-tkiTgo0JhbD8vnN5QG28 Subject: [manet] Slides by July 18 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, 11 Jul 2014 16:21:52 -0000 Hi, all presenters, please send me your slides by Friday, July 18. Thanks Ulrich From nobody Fri Jul 11 09:25:32 2014 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 A5A111B2B5D for ; Fri, 11 Jul 2014 09:25:24 -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 66mO7ZDyLmVc for ; Fri, 11 Jul 2014 09:25:23 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C20B1B2B49 for ; Fri, 11 Jul 2014 09:25:23 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so2513197vcb.2 for ; Fri, 11 Jul 2014 09:25:22 -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=7c6VAyiZCqIaYMxBH5wWI+20Fp5/CARCZMQL0vqWcuc=; b=d6IbCIPAt7NUcc5+o8m+qAWh0QVkrE4XNMxp234wEn7WB0Yw4FoAzq2cjUYCzpgLnW +U5FPRftFlK3EgBZsHYTivYkuNcptcAJ0ZXtKLoMNEGTigV05bgAzwAaxETQolZ88eI1 Lp0wFCyXEYpXomKLn72yU8WG9rd6cWasr5Ze8= 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=7c6VAyiZCqIaYMxBH5wWI+20Fp5/CARCZMQL0vqWcuc=; b=fR93IAaPyq7mIHkGMA7y8PqdaY/8yV+/16KMHoY3dmqRbEdVG7a8SCN8jBCO+E56I+ mYpexQ+ROV4NnhP1hUnjZw946C8hco6JTEPWlZHWor53dWwEQtCQC3RwtRAK2QgFDxrT Zjra14xqsfO+V8D/M0lQdSa+9E4Z3ltlBAiV/DjjUXyjOy6cgCGRmgTxPFsDbe8FCMDX 3MjOwuBKVjIVZrxkVeNKIu8QY9xWOK9KpqxJ4aC4neCMKxsDRZ0HZ8NbJMGl4svdC/oy rckxc5HEUUvbNnokcFQ9rVc2mJNedzUz5vqwEXyq7L0/Nx7EgTDjqAeKm95QK5SwYZMu EKww== X-Gm-Message-State: ALoCoQmeme4Q+Zb0wAIes1m1bZMzwhIKt32pxZJwKD5HXQ3SPb8W30L4jhT2BZuzLE/YEuKlTWUe MIME-Version: 1.0 X-Received: by 10.58.89.162 with SMTP id bp2mr1463216veb.78.1405095922431; Fri, 11 Jul 2014 09:25:22 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Fri, 11 Jul 2014 09:25:22 -0700 (PDT) Date: Fri, 11 Jul 2014 09:25:22 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/TH4GmCbWclG2Ifd0eXNev6hKqXY Subject: [manet] Minutes taker and jabber scribe volunteers 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, 11 Jul 2014 16:25:24 -0000 Hi, please volunteer for either taking minutes or being the scribe. Thanks in advance, your help is much appreciated! Regards Ulrich From nobody Fri Jul 11 09:37:54 2014 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 464041B2BB7 for ; Fri, 11 Jul 2014 09:37:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rcf7w8vHH1hY for ; Fri, 11 Jul 2014 09:37:49 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B760D1B2BB6 for ; Fri, 11 Jul 2014 09:37:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 7A042880E42; Fri, 11 Jul 2014 09:37:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id DFDB6880E3C; Fri, 11 Jul 2014 09:37:48 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: Date: Fri, 11 Jul 2014 18:37:44 +0200 To: Ulrich Herberg X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hyYoXwrcSTqMwoaFYObmQG3JB0o Cc: Charlie Perkins , "" , "manet@ietf.org" Subject: Re: [manet] Slot requests 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, 11 Jul 2014 16:37:51 -0000 Dear Ulrich, all I have a few I-Ds, that I am working on -- but which I didn't manage to get i= n under the deadline. I therefore had the decency to show enough respect for= my fellow WG participants and not request a slot for presenting this un-sub= mitted work.=20 I had hoped to be able to - at least - announce their existence and the subj= ects during the "Open Mike" in case there were willing victims for discussio= ns and work on progressing them during the IETF week. Not sure if that falls under what you are requesting here? I'm a little befu= ddled at this whole process/situation... Thomas Sent from my iPad > On 11 Jul 2014, at 17:27, Ulrich Herberg wrote: >=20 > Hello Charlie, >=20 > I have uploaded an updated agenda. The chairs allocated you a slot of > up to 20 minutes (assuming enough time is remaining at that point of > the meeting). >=20 > @All: As there is risk that the "open mike" slot will fall off the > table, please let me know if there is anything you would like to > announce during that slot (e.g., a new interop event, a new > implementation, etc.) >=20 > Regards > Ulrich >=20 >> On Fri, Jul 11, 2014 at 7:24 AM, Ulrich Herberg wro= te: >> Hello Charlie, >>=20 >> I will discuss this with the chairs and let you know. >>=20 >> Regardless of what they decide, I'd really appreciate in the future to >> receive slot requests (in particular such large ones) several days >> *before* the first draft agenda deadline, not one business day before >> the final deadline. As you can see, the agenda is already very dense, >> so this will make it more difficult for me to schedule the meeting. >>=20 >> Thanks >> Ulrich >>=20 >> On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins >> wrote: >>> Hello Ulrich, >>>=20 >>> Please schedule at least 30 minutes for reporting on the >>> current status of AODVv2. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>>=20 >>>> On 6/23/2014 11:34 AM, Ulrich Herberg wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> the MANET meeting has been scheduled (preliminarily): >>>>=20 >>>> manet Session 1 (2:00:00) >>>> Tuesday, Afternoon Session II 1420-1620 >>>> Room Name: Manitoba >>>>=20 >>>> Please send your requests for slots during the meeting. >>>>=20 >>>> Thanks >>>> Ulrich >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Jul 11 13:19:36 2014 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 6C3761B2C54 for ; Fri, 11 Jul 2014 13:19:34 -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 nekAgJH1tqqs for ; Fri, 11 Jul 2014 13:19:32 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A791E1A0406 for ; Fri, 11 Jul 2014 13:19:32 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id ij19so3055413vcb.37 for ; Fri, 11 Jul 2014 13:19:31 -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=c5Cl2Md3U8AuWuNnXPj73y34CC5kL5IFiY7sXSEYptA=; b=B800Zd7I0v4yxI7iX44+SzdIZseISgC88QEY1R1nSHfRbNDcXECX6IqUyKFBZakZZB I9bTZl0guoCXZR65/yDZvPfCeRKv4wC6NYEa3+X/LpxWE6I/kU9iPMRHNZHrsoSZHiP4 DK2mV5U9qmJkyYkXy9lXU1bGRoQ37ZfZWbohR3FAk3b3owRR7V1XFuZUO7JkglMOG1ld mMxa3O+UO5ip/G/sYWHiNrs50bhG+RscfNxQ+eTO4TcRsUlMdocQfqTZSh52fkAmXfNq 3jfAtISMWhLWSyZRRZjRgbqwJ0nDNYxyv67ezx/Qfh368b5IaQtXuRar0SQMqLg49WKZ NcDQ== MIME-Version: 1.0 X-Received: by 10.58.179.39 with SMTP id dd7mr254832vec.75.1405109971711; Fri, 11 Jul 2014 13:19:31 -0700 (PDT) Received: by 10.58.19.198 with HTTP; Fri, 11 Jul 2014 13:19:31 -0700 (PDT) In-Reply-To: References: <53BF69CE.7060702@earthlink.net> Date: Fri, 11 Jul 2014 21:19:31 +0100 Message-ID: From: John Dowdell To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b6dc6c2bc27c604fdf0a8c9 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kSjMOgDIPrPCsR7W-iyCll5s93Q Cc: Charlie Perkins , "manet@ietf.org" Subject: Re: [manet] Slot requests 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, 11 Jul 2014 20:19:34 -0000 --047d7b6dc6c2bc27c604fdf0a8c9 Content-Type: text/plain; charset=UTF-8 Ulrich I have an interop event announcement to make that will take 30 seconds. Regards John On Friday, July 11, 2014, Ulrich Herberg wrote: > Hello Charlie, > > I have uploaded an updated agenda. The chairs allocated you a slot of > up to 20 minutes (assuming enough time is remaining at that point of > the meeting). > > @All: As there is risk that the "open mike" slot will fall off the > table, please let me know if there is anything you would like to > announce during that slot (e.g., a new interop event, a new > implementation, etc.) > > Regards > Ulrich > > On Fri, Jul 11, 2014 at 7:24 AM, Ulrich Herberg > wrote: > > Hello Charlie, > > > > I will discuss this with the chairs and let you know. > > > > Regardless of what they decide, I'd really appreciate in the future to > > receive slot requests (in particular such large ones) several days > > *before* the first draft agenda deadline, not one business day before > > the final deadline. As you can see, the agenda is already very dense, > > so this will make it more difficult for me to schedule the meeting. > > > > Thanks > > Ulrich > > > > On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins > > > wrote: > >> Hello Ulrich, > >> > >> Please schedule at least 30 minutes for reporting on the > >> current status of AODVv2. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> On 6/23/2014 11:34 AM, Ulrich Herberg wrote: > >>> > >>> Hi, > >>> > >>> the MANET meeting has been scheduled (preliminarily): > >>> > >>> manet Session 1 (2:00:00) > >>> Tuesday, Afternoon Session II 1420-1620 > >>> Room Name: Manitoba > >>> > >>> Please send your requests for slots during the meeting. > >>> > >>> Thanks > >>> Ulrich > >>> > >>> _______________________________________________ > >>> 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 > --047d7b6dc6c2bc27c604fdf0a8c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulrich

I have an interop event announcement to make that= will take 30 seconds.

Regards
John
<= br>On Friday, July 11, 2014, Ulrich Herberg <ulrich@herberg.name> wrote:
Hello Charlie,

I have uploaded an updated agenda. The chairs allocated you a slot of
up to 20 minutes (assuming enough time is remaining at that point of
the meeting).

@All: As there is risk that the "open mike" slot will fall off th= e
table, please let me know if there is anything you would like to
announce during that slot (e.g., a new interop event, a new
implementation, etc.)

Regards
Ulrich

On Fri, Jul 11, 2014 at 7:24 AM, Ulrich Herberg <ulri= ch@herberg.name> wrote:
> Hello Charlie,
>
> I will discuss this with the chairs and let you know.
>
> Regardless of what they decide, I'd really appreciate in the futur= e to
> receive slot requests (in particular such large ones) several days
> *before* the first draft agenda deadline, not one business day before<= br> > the final deadline. As you can see, the agenda is already very dense,<= br> > so this will make it more difficult for me to schedule the meeting. >
> Thanks
> Ulrich
>
> On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins
> <charles.perkins@earthlink.net>= wrote:
>> Hello Ulrich,
>>
>> Please schedule at least 30 minutes for reporting on the
>> current status of AODVv2.
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>> On 6/23/2014 11:34 AM, Ulrich Herberg wrote:
>>>
>>> Hi,
>>>
>>> the MANET meeting has been scheduled (preliminarily):
>>>
>>> manet Session 1 (2:00:00)
>>> =C2=A0 =C2=A0 =C2=A0Tuesday, Afternoon Session II 1420-1620 >>> =C2=A0 =C2=A0 =C2=A0Room Name: Manitoba
>>>
>>> Please send your requests for slots during the meeting.
>>>
>>> Thanks
>>> Ulrich
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--047d7b6dc6c2bc27c604fdf0a8c9-- From nobody Sat Jul 12 00:50:18 2014 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 2D3E91B2A14 for ; Sat, 12 Jul 2014 00:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.071 X-Spam-Level: * X-Spam-Status: No, score=1.071 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RAZOR2_CHECK=0.922, RP_MATCHES_RCVD=-0.651] 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 vrg1DbdhOzOn for ; Sat, 12 Jul 2014 00:50:15 -0700 (PDT) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FA21B2A13 for ; Sat, 12 Jul 2014 00:50:13 -0700 (PDT) Received: from [192.168.255.122] ([192.168.255.122]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id s6C7o9kf020939 for ; Sat, 12 Jul 2014 10:50:11 +0300 Message-ID: <53C0E8B3.7020106@it.teithe.gr> Date: Sat, 12 Jul 2014 10:50:11 +0300 From: Periklis Chatzimisios Organization: Alexander TEI of Thessaloniki User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1SQr1vCwCnerPmEqjZsUf1ELwqk Subject: [manet] Third IEEE Workshop on Telecom Standards - From Research to Standards (Firm deadline: 15th July!) 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: Sat, 12 Jul 2014 07:50:17 -0000 We would like to attract your attention to the fast-approaching submission deadline of the third "IEEE Workshop on Telecommunication Standards: From Research to Standards" as part of IEEE Globecom Dec. 8-12, 2014, Austin, Texas, USA Important relevant notes follow: 1- Work is under progress to make of the workshop a standalone IEEE conference from next year. 2- The workshop's BEST PAPERS will be recommended for publication at the IEEE Communications Magazine's supplement on "Communications Standards", including the following feature topic: "Research & Standards: Advanced Cloud Technologies & Network Function Virtualization Techniques in 5 G". 3- A specific track will be dedicated for papers on research projects with potential impact on standards bodies, including and not limited to, ITU-T, IEEE, IETF, 3GPP, ETSI, OMA, Broadband Forum, and oneM2M. Visionary papers on hot topics, such as Advanced 5G Network Infrastructure, Software Defined Networks and Services, and Network Functions Virtualization (NFV) are highly welcome. Further details about the workshop are available at its official website: http://www.research2standards.org Important Dates for Paper Submission: - Submission Deadline: July 15, 2014 (firm deadline) - Acceptance Notification: September 01, 2014 - Camera-Ready Submission: October 01, 2014 Workshop General Chair: - Dr. Tarik Taleb, NEC Europe, Germany Panel and Keynotes Co-Chairs: - Dr. David Soldani, Huawei European Research Centre (ERC), Germany - Dr. Anass Benjebbour, NTT DoCoMo, Japan TPC Co-Chairs: - Dr. Adlen Ksentini, INRIA/Univ. of Rennes, France - Dr. Amitav Mukherjee, Hitachi America Ltd. USA - Mr. Athul Prasad, Nokia, Finland - Dr. JaeSeung Song, Sejong Uni., Korea - Dr. Tuncer Baykas, Tohoku Uni., Japan - Dr. Klaus Doppler, Nokia Research Center, USA Standards Relevant EU Projects Co-Chairs: - Prof. Luis M. Correia, IST – University of Lisbon, Portugal - Dr. Bernard Barani, European Commission, Belgium - Prof. Matti Latva-aho,University of Oulu, Finland Publicity Co-Chairs: - Dr. Alexander D. Gelman, IEEE ComSoc and NETovations, USA - Dr. Adel Al-Hezmi, Fraunhofer Fokus, Germany - Dr. SM Hasan, GE Global Research, USA - Dr. Periklis Chatzimisios, Alexander TEI of Thessaloniki, Greece From nobody Sat Jul 12 12:25:34 2014 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 631251A0250 for ; Sat, 12 Jul 2014 12:25:33 -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 vPl1mbHsxii1 for ; Sat, 12 Jul 2014 12:25:32 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1B81A0062 for ; Sat, 12 Jul 2014 12:25:31 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so681068vcb.40 for ; Sat, 12 Jul 2014 12:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=K2jTmh8TQWOWAY5uLztnAdKwgBwIcYvcW9ur1PyfBLI=; b=iwx9BqsjUjdj/YquC5vHHIJJFhqLy+s0qRLdosnGmpJAh8BL/OmzdGWZyiJeSvQLBf DRCfq1Pw0vWuJiC8GpmrytLo8xDUqNouMhDyTXjGBkvtkimYKud1qacSpkCHJVn6CerS 1mTkrLhJ+QNo2yHq2r8B40JvQxApN0mQz2hWc= 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:content-type; bh=K2jTmh8TQWOWAY5uLztnAdKwgBwIcYvcW9ur1PyfBLI=; b=iqWScX96Xy0lSRrIaLB5WBh1/ahhOSrcCB/WeZnQh3qrGE5SI1XSm/lWKli3UwtTfb 3TrEkmfGHWVfvb6IUjrTkpqUOx27QrvDJyNfZE9xGS0dkTUbl+YZbf7RE8oelFJ6EVXx VCfdmB3kIMlmEXUliC1Yv18OhioJ5XbDjuqnQ7wMCmObJUI/obd55ZYFxT1u5LdYgdG0 rJlh7vr10zHLHkzNuwPgWbcKzZUXKaQXXeEdo7eVlbUvWvhjy1C+Q1zpMxo8JmmzL1E0 WCEfMkhAkcbIAlWibMXFJ+wPuH9YjAUieELBDJug5+G/SQslYfoR24ICrOMMz2AEATQo sB6A== X-Gm-Message-State: ALoCoQmb6os02/9tRS7wU4JpRnZnPWq9Uzny5Zyl7kEkTRFa5uBPpjoRKFE4J5gH1SN5DDlx/ugo MIME-Version: 1.0 X-Received: by 10.58.8.108 with SMTP id q12mr6816015vea.2.1405193130897; Sat, 12 Jul 2014 12:25:30 -0700 (PDT) Received: by 10.220.178.74 with HTTP; Sat, 12 Jul 2014 12:25:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 12 Jul 2014 12:25:30 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UCyhzA0ZeU8kdi2XZCrYZE0gDPQ Subject: [manet] Fwd: [OPSAWG] Coman Drafts v02 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: Sat, 12 Jul 2014 19:25:33 -0000 FYI: I recently mentioned the COMAN mailing list, dealing with management of constrained devices. Two drafts initially started out inside the COMAN "group" are now in WGLC of OPSAWG. In my opinion, this is somewhat related to the activities of management of MANET routers, the use case draft particularly addresses MANETs. ---------- Forwarded message ---------- From: Warren Kumari Date: Tue, Jul 8, 2014 at 1:30 PM Subject: Re: [OPSAWG] Coman Drafts v02 To: "Ersue, Mehmet (NSN - DE/Munich)" Cc: "opsawg@ietf.org" , "a.sehgal@jacobs-university.de" , "opsawg-chairs@tools.ietf.org" Dear OpsAWG WG, The authors of draft-ietf-opsawg-coman-probstate-reqs-02 and draft-ietf-opsawg-coman-use-cases-02 have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs-02/ and here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ Please review this draft to see if you think it is ready for publication and send comments to the list, **clearly** stating your view. IETF90 is Toronto is nearly upon us, and so folk are busy / may have questions about this document. Because of this we are doing an extended (3 week) WGLC - It ends Tue 29-Jul-2014. Thanks, Warren Kumari (as OpsAWG WG co-chair) On Fri, Jul 4, 2014 at 5:01 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear OPSAWG Chairs, > > we submitted v02 of the Coman drafts. > > As discussed in IETF #89, the authors think that the two documents are ready > for WGLC. > Please consider to start the WGLC procedure. Thank you. > > Management of Networks with Constrained Devices: Problem Statement and > Requirements > http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-02 > > Management of Networks with Constrained Devices: Use Cases > http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-02 > > Regards, > Mehmet > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Jul 14 02:21:20 2014 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 899111A0167 for ; Mon, 14 Jul 2014 02:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 7hWOtJWvDKeQ for ; Mon, 14 Jul 2014 02:21:17 -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 D54501A00AD for ; Mon, 14 Jul 2014 02:21:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,657,1400022000"; d="scan'208";a="386332640" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Jul 2014 10:21:15 +0100 X-IronPort-AV: E=Sophos;i="5.01,657,1400022000"; d="scan'208";a="64590232" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 14 Jul 2014 10:21:18 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.106]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 10:21:15 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , "Mobile Ad Hoc Networks mailing list" Thread-Topic: [manet] Updated version of AODVv2 Thread-Index: AQHPnMLnSo4DNBfrx0aR24fsEcnRt5ufR3VQ Date: Mon, 14 Jul 2014 09:21:12 +0000 Message-ID: References: <53BF6BCA.1050900@earthlink.net> In-Reply-To: <53BF6BCA.1050900@earthlink.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ovDUQqsTs8LJh1Dai_kQ91q17Ys Subject: Re: [manet] Updated version of AODVv2 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, 14 Jul 2014 09:21:19 -0000 I've read this draft, I'm not sure which was the last draft I read (a DYMO = one). I actually still haven't read some of the detailed sections at this t= ime. While I have noted various other points on my copy, I'm just going to consi= der what I think are the major problems with this draft. The protocol relies on links being didirectional. It must therefore provide= a means to ensue that. It's not good enough to list several possibilities = - that will not offer interoperability. It is fine of course to offer allow= ing additional reasons to exclude links, but there needs to be a basic non-= optional mechanism for something that the protocol will not work without. (Not a draft problem directly, but I think most if not all of those mechani= sms make the protocol not fully reactive. That removes one of the motivatio= ns for interest in a reactive protocol in some use cases.) The document is completely noncompliant with the RFC 5444 multiplexing mech= anism, mandated by RFC 5498 (on the manet port/protocol). It does many thin= gs that are not within its competence. There's a number of things I will roll together and express as there is a n= eed to understand the architecture. The protocol needs many things from IP,= such as failed routing notification, and interacts with it in ways such as= queuing packets. It also interacts (sends and receives) with ICMP, and I'm= not sure what else. This needs to be put together, so the reader can see w= hat is needed to be able to implement this. Despite saying that hop count is inadequate, it's the only metric supported= . And unlike OLSRv2, which is designed so that the protocol can handle any = future metric without change, that's not true here. That's a definite proto= col weakness. I think there will be compatibility issues with the optional features. As a= point of IETF protocol, I don't think quoting two year expired Internet Dr= afts is acceptable. But I haven't dug into this. The security approach is - and I've said this before, as others have made t= he above points before - completely unacceptable. The security directorate = and ADs refused to accept this from OLSRv2. They will refuse to accept this= from this protocol. Incidentally note that references to RFC 6621 should b= e to RFC 6622, except now to RFC 7182. Appendix A. If pseudo-code is needed to explain the algorithms, it needs to= be in the main body. If the main body is considered complete (and this is = at the detail level I've not read) I'm not sure exactly what this is offeri= ng. I's also too C-lie (NULL for example) while not being C (use of :=3D - = although not fully consistently). I don't think the balance is right here. The model is of routers with a single address per interface. In OLSRv2 this= wasn't considered acceptable. The authors defined multiple addresses per i= nterface, the WG required supporting unnumbered interfaces which shared add= resses. Do we want a less capable protocol here? Also gateway support is we= ak - OLSRv2 can support multiple gateways with the same, or overlapping, ad= dress ranges. Again, is something less functional good enough? My conclusion is that this document is still a long way from being in a sta= te that could be published. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charlie Perkins Sent: 11 July 2014 05:45 To: Mobile Ad Hoc Networks mailing list Subject: [manet] Updated version of AODVv2 ----------------------! 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. -------------------------------------------------------- Hello folks, I have posted an updated version of AODVv2 at the following URL: The biggest change by far is the inclusion of the appendix containing the a= lgorithms. The other changes have to do with issue resolution as we have d= iscussed in preceding weeks. I have not resolved any new issues except by = way of including the algorithms. http://www.psg.com/~charliep/ietf90/draft-ietf-manet-aodvv2-pre04.txt I had intended to upload this before the deadline, but then I found out tha= t the deadline was Friday instead of Monday. That was a big disappointment= , sorry about that; I used the last few days for some additional proofreadi= ng. The appendix containing the algorithms still needs more polishing, but it i= s ready for review by interested WG members. During the preparation of this revision, I have identified some more issues= that I will insert into the issue tracker shortly. Also to come, a new re= vision of the draft for Intermediate RREP, a feature that was (perhaps mist= akenly) isolated from the main AODVv2 specification. Regards, Charlie P. _______________________________________________ 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 Jul 14 23:23:49 2014 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 8BAF41A0AEA for ; Mon, 14 Jul 2014 23:23:46 -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 L36FPTNQO68H for ; Mon, 14 Jul 2014 23:23:45 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08A01A0178 for ; Mon, 14 Jul 2014 23:23:44 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id r5so3745190qcx.24 for ; Mon, 14 Jul 2014 23:23:44 -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=1a7RFK+wkYcSiGcJVn+MgEiR5X029HtjUnAAIkgvtdE=; b=KSGm4dgNhopUgfRPcaW8+Hjc6qC3sf5dgqR1OkEL/8scAwTpSTqaMAop1fCeuNHUiz MJPpXSChUbmTfJNQD98C+YdjyyYXrK7QdM8ZjZWwYsjAqwIucdw2xg5/+5gACfcrQ5Tp rNndLG3jgy044agihwtpqrIomLAXRvZxvFYsz9ikte5o0x/ZWmhL9Ey9MItI9AQEmNM8 dHhZduepW7CdhaHRHcDpbXRyKYT1r1g2wtuGrjkF+Q1hxuBa2GotS3xzRCnCOhYegEt+ O/oFrkqh5KIsdEuRQikfrhPRTAp/D8i7ZMpwJ5p1Iqz+I0BcJhb7WLXEED25+HPZcBI5 Ikeg== X-Received: by 10.140.25.51 with SMTP id 48mr18900239qgs.9.1405405424179; Mon, 14 Jul 2014 23:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Mon, 14 Jul 2014 23:23:24 -0700 (PDT) In-Reply-To: References: <20140704192129.17494.45875.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 15 Jul 2014 08:23:24 +0200 Message-ID: To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lx2LvJvmSWT-chnlZ-MpInHZFzo Cc: manet , Joe Macker , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-00.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: Tue, 15 Jul 2014 06:23:46 -0000 On Sun, Jul 6, 2014 at 12:15 AM, Jiazi YI wrote: > Hi, > > A new draft draft-yi-manet-olsrv2-multipath > (http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-00.txt) > has been submitted. > > It is a multipath extension of OLSRv2 (and fully interoperable with OLSRv2), > which explores multiple disjoint paths to improve the reliability of data > forwarding in MANETs. Is this extension inter-operable with the Multi-Topology extension of Christopher? > Several open source implementations of the protocol (for both testbed and > simulations) have been existed for years, OLSRv2 implementations? Is there an open source implementation of OLSRv2 (RFC7181 compliant) that could be used for an interop test? > and a lot of study has been > conducted. More details about the implementations can be found at: > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-00#section-10 The source code link for SEREADMO gives me a 404 error. The other implementation(s) seem to be simulation only, right? Henning Rogge From nobody Tue Jul 15 03:25:50 2014 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 653151B2837 for ; Tue, 15 Jul 2014 03:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 RhbDTtDc1xgA for ; Tue, 15 Jul 2014 03:25:44 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EBB1B283D for ; Tue, 15 Jul 2014 03:25:43 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so2953713wiw.5 for ; Tue, 15 Jul 2014 03:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sNcaRar5U5n6SZUii+USul5wIOWnTF/W/VBg7AlYymo=; b=vDJ/MkuHx/WYkxQcFrFoidjTnwNTl+/ORHrWo+uVIrYrfpsysb8EWYpZndrwpNQVyf D3vchyxLrgWOMXesYKp0vOjZVz+BP2OScUYpTIx5GHR4856WONemT3C3vDqgd0rQ/Zpd GmQQMgDUYGEJX4oykv2sAcYuTT5aHaoNweLZq8Rk7lXLN04VQDeOuFt7uC1EOjj8r5vw XoOfOqSrTP2yoa37z6Yb0bhJD+7rewqH+n8X+tXx9RYiFxw42r9ifTLjqLQgmILzanXO G6/vY+9Y+zhqPGIb9ZxosNDs0/PCNI60kHDRsrBhfH4r8wsC5kmlA3sAeg8FkIIXM9Oi CBXg== MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr2864239wib.32.1405419942539; Tue, 15 Jul 2014 03:25:42 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Tue, 15 Jul 2014 03:25:42 -0700 (PDT) In-Reply-To: References: <20140704192129.17494.45875.idtracker@ietfa.amsl.com> Date: Tue, 15 Jul 2014 12:25:42 +0200 X-Google-Sender-Auth: qfge_u0Hw8GggQy9w2zwYNFx_9E Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c37e566fea7904fe38d446 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LVH5c5JJPXVdltz6XnZaigIDTK0 Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-00.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: Tue, 15 Jul 2014 10:25:46 -0000 --001a11c37e566fea7904fe38d446 Content-Type: text/plain; charset=UTF-8 Hi Henning, On Tue, Jul 15, 2014 at 8:23 AM, Henning Rogge wrote: > On Sun, Jul 6, 2014 at 12:15 AM, Jiazi YI wrote: > > Hi, > > > > A new draft draft-yi-manet-olsrv2-multipath > > ( > http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-00.txt > ) > > has been submitted. > > > > It is a multipath extension of OLSRv2 (and fully interoperable with > OLSRv2), > > which explores multiple disjoint paths to improve the reliability of data > > forwarding in MANETs. > > Is this extension inter-operable with the Multi-Topology extension of > Christopher? > Yes. The multipath extension just makes use of the topology information obtained by OLSRv2. It doesn't care what kind of metric is used. In fact, it might be even interesting to make use of the multi-topology information to build multiple paths. > > > Several open source implementations of the protocol (for both testbed and > > simulations) have been existed for years, > > OLSRv2 implementations? > > Is there an open source implementation of OLSRv2 (RFC7181 compliant) > that could be used for an interop test? > > and a lot of study has been > > conducted. More details about the implementations can be found at: > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-00#section-10 > > The source code link for SEREADMO gives me a 404 error. > > Sorry. should work now. > The other implementation(s) seem to be simulation only, right? > The umOLSR and olsrd based implementations are OLSR implementations. The umOLSR is for NS2 simulation. The implementation based on nOLSRv2 is now mainly for Qualnet simulations. But as nOLSRv2 can run with both simulation and real devices, the multipath extension can be exported to run with real network interface in the future. Although some of the implementations are for OLSR (when the extension was first developed, OLSRv2 was still in preliminary phase), the multipath algorithm can be applied to both OLSR and OLSRv2. The experience obtained can be helpful to understand the performance of the algorithm. The reasons that the simulation code is developed and published are 1) it can allow us to estimate the performance in large-scale networks (of course, it's still have some distance to the real world :). 2) for a lot of developers and researchers, the simulation is still the most convenient and cost effective way to study and analyse a protocol. best Jiazi > > Henning Rogge > --001a11c37e566fea7904fe38d446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Henning,


On Tue, Jul 15, 2014 at 8:23 AM, Henning Rogge <hrogge@g= mail.com> wrote:
On Sun, Jul 6, 2014 at 12:15 AM, Jiazi YI = <ietf@jiaziyi.com> wrote:
> Hi,
>
> A new draft =C2=A0draft-yi-manet-olsrv2-multipath
> (http://www.ietf.org/internet-drafts/dra= ft-yi-manet-olsrv2-multipath-00.txt)
> has been submitted.
>
> It is a multipath extension of OLSRv2 (and fully interoperable with OL= SRv2),
> which explores multiple disjoint paths to improve the reliability of d= ata
> forwarding in MANETs.

Is this extension inter-operable with the Multi-Topology extension of=
Christopher?

Yes. The multipath extensi= on just makes use of the topology information obtained by OLSRv2. It doesn&= #39;t care what kind of metric is used. In fact, it might be even interesti= ng to make use of the multi-topology information to build multiple paths.= =C2=A0

=C2=A0

> Several open source implementations of the protocol (for both testbed = and
> simulations) have been existed for years,

OLSRv2 implementations?

Is there an open source implementation of OLSRv2 (RFC7181 compliant)
that could be used for an interop test?=C2=A0

> and a lot of study has been
> conducted. More details about the implementations can be found at:
> http://tools.ietf.org/html/draft-yi-manet-= olsrv2-multipath-00#section-10

The source code link for SEREADMO gives me a 404 error.


Sorry. should work now.=C2=A0
=C2=A0
The other implementation(s) seem to be simulation only, right?


The umOLSR and olsrd based implement= ations are OLSR implementations. The umOLSR is for NS2 simulation.=C2=A0
The implementation based on nOLSRv2 is now mainly for Qualnet simulati= ons. But as nOLSRv2 can run with both simulation and real devices, the mult= ipath extension can be exported to run with real network interface in the f= uture.=C2=A0

Although some of the implementations are for OLSR (when= the extension was first developed, OLSRv2 was still in preliminary phase),= the multipath algorithm can be applied to both OLSR and OLSRv2. The experi= ence obtained can be helpful to understand the performance of the algorithm= .=C2=A0

The reasons that the simulation code is developed and p= ublished are 1) it can allow us to estimate the performance in large-scale = networks (of course, it's still have some distance to the real world :)= . =C2=A02) for a lot of developers and researchers, the simulation is still= the most convenient and cost effective way to study and analyse a protocol= .=C2=A0

best

Jiazi
=C2=A0

Henning Rogge

--001a11c37e566fea7904fe38d446-- From nobody Wed Jul 16 03:27:12 2014 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 D0E4A1B2B1A for ; Wed, 16 Jul 2014 03:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 QbtJHSERlwLJ for ; Wed, 16 Jul 2014 03:27:09 -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 39D571B2B14 for ; Wed, 16 Jul 2014 03:27:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,671,1400022000"; d="scan'208,217";a="386983683" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Jul 2014 11:27:07 +0100 X-IronPort-AV: E=Sophos; i="5.01,671,1400022000"; d="scan'208,217"; a="64920467" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 16 Jul 2014 11:27:12 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.106]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 11:27:09 +0100 From: "Dearlove, Christopher (UK)" To: "manet-chairs@tools.ietf.org" Thread-Topic: Three drafts to progress Thread-Index: Ac+g4AzL/nr5eDepTmK3VGcbYl9zyA== Date: Wed, 16 Jul 2014 10:27:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CCEE71GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BPnErRc1Zl2mpxuAq3uPDpl5WnM Cc: "manet@ietf.org" , "manet-ads@tools.ietf.org" Subject: [manet] Three drafts to progress 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, 16 Jul 2014 10:27:12 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CCEE71GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Joe, Stan, All The call to adopt draft-dearlove-manet-ibs-00.txt as a WG document was made= on 30th June for comment within 2 weeks, which has now passed. The WGLC for draft-ietf-manet-olsrv2-multitopology-02 (updated to draft-iet= f-manet-olsrv2-multitopology-03 on 4th July based on comments made) was mad= e on 1st July, for comments by 14th July, which has now passed. The call to adopt draft-dearlove-manet-nhdp-optimization-01 was made on 2nd= July, with no period stated (which I overlooked) but has had a period of 2= weeks since then. I've seen various positive comments, especially on the first two, and no ne= gative ones. I'd like therefore to ask the chairs to take the appropriate a= ctions (some of which then come back to the authors). Christopher -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CCEE71GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Joe, Stan, All

 

The call to adopt draft-dearlove-manet-ibs-00.txt as= a WG document was made on 30th June for comment within 2 weeks, which has = now passed.

 

The WGLC for draft-ietf-manet-olsrv2-multitopology-0= 2 (updated to draft-ietf-manet-olsrv2-multitopology-03 on 4th July based on= comments made) was made on 1st July, for comments by 14th July, which has = now passed.

 

The call to adopt draft-dearlove-manet-nhdp-optimiza= tion-01 was made on 2nd July, with no period stated (which I overlooked) bu= t has had a period of 2 weeks since then.

 

I’ve seen various positive comments, especiall= y on the first two, and no negative ones. I’d like therefore to ask t= he chairs to take the appropriate actions (some of which then come back to = the authors).

 

Christopher

 

-- <= /p>

Christopher Dearlove

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

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

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

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CCEE71GLKXM0002VGREEN_-- From nobody Wed Jul 16 05:22:12 2014 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 6A0331B27E8 for ; Wed, 16 Jul 2014 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.039 X-Spam-Level: ** X-Spam-Status: No, score=2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, T_FROM_MISSP_DKIM=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 9DLVxP_l4MZo for ; Wed, 16 Jul 2014 05:22:02 -0700 (PDT) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CA31B2836 for ; Wed, 16 Jul 2014 05:22:01 -0700 (PDT) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id EBC52C06EF for ; Wed, 16 Jul 2014 14:21:59 +0200 (CEST) Date: Wed, 16 Jul 2014 14:34:01 +0200 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <53c67139.3cRVU79mIw5OCr4q%comcom_osn_special@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kvIHDeemZrnvr4QQa0QYqh2Bhmc Subject: [manet] Elsevier ComCom Special Issue on Online Social Networks 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, 16 Jul 2014 12:22:10 -0000 CALL FOR PAPERS Elsevier - Computer Communications Journal Special Issue on Online Social Networks http://www.journals.elsevier.com/computer-communications/call-for-papers/special-issue-on-online-social-networks1/ Submission Deadline: 19 October 2014 Online Social Networks are a massively successful phenomenon, used by billions of users to interact. Nowadays they are key platforms for, among others, content dissemination, social and professional networking, recommendation, scouting, alerting, and political campaigns. The research interest in OSNs is multi-faceted, and exploits an unmatched source of large-scale data about the human behavior. It spans a number of disciplines, across numerous fields in and beyond computer science, all the way up to the analysis of human social relationships and how they evolve and mature over time. Moreover, the pervasive presence of users' mobile devices (e.g., smartphones) has opened new avenues in the design of mobile social networking services, and in the study of the interplay between mobility and social interactions. Research in OSN is a fertile ground also for industry, to develop innovative ideas fostering the design of the new generation of communication platforms and their services. This special issue seeks contributions pushing the state of the art in all facets of Online Social Networks highlighted above. We also encourage original work based on an interdisciplinary research (at the boundary between computer science and humanistic disciplines such as sociology and anthropology) where quantitative evidence is available demonstrating the mutual advantage of such an approach. Therefore, purely methodological papers or papers that do not present quantitative results with real Online or Mobile Social Networking technologies are considered out of scope. Moreover, special attention is expected in interpreting the proposed research results in order to shed light towards what users may need and wish in terms of novel, practical services and application. Topics of interest include (but are not limited to) the following: - Design of OSN platforms based on human behavioural models - Analysis of OSN users' behaviour and its evolution over time - Comparison of human social behaviour in Online and "offline" Social Networks, and across OSNs - Impact of Online Social Networks on human social behaviour - Analysis of the use of social-networking sites in the urban context - OSNs for supporting novel, social-oriented applications and services - Mobile and Location-aware Online Social Networks - OSN services enabled by the analysis of mobility and social behaviour - Crowdsourcing for Online and Mobile Social Networks - Dynamics of trends, information and opinion diffusion in OSN - Smart recommendations and advertising in Online Social Networks - Information extraction and search in Online Social Networks - Privacy in management and analysis of Online and Mobile Social Networks data - Privacy, Security, Trust and Reputation in Online Social Networks - Prevention of misbehaviours (spamming, phishing, ...) in Online Social Networks - Modelling of Online Social Networks characteristics and mechanisms - Graph analysis applied to Online Social Networks - Complex networks techniques applied to the investigation of OSN - Data Mining and Machine Learning to gain novel insights on Online Social Networks - Novel distributed solutions for designing, supporting and operating Online Social Networks - Networking, computation and data infrastructure support for Online Social Network systems Schedule Submission deadline: 19 October 2014 Author notification: 31 January 2015 Revised paper due: 15 March 2015 Final author notification: 15 April 2015 Publication (tentative): 3rd Quarter 2015 Guest Editors Xiaoming Fu, Georg-August-University of Goettingen, Germany Andrea Passarella, IIT-CNR, Italy Daniele Quercia, Yahoo Labs, Spain Alessandra Sala, Bell Labs, Ireland Thorsten Strufe, TU Dresden, Germany Instructions for submission --------------------------- Manuscripts must not have been previously published nor currently under review by other journals or conferences. If prior work was published in a conference, the submitted manuscript should include a substantial extension of at least 35% novel contributions. In this case, authors are also required to submit their published conference articles and a summary document explaining the enhancements made in the journal version. Papers must be submitted through the Computer Communications website at http://ees.elsevier.com/comcom, where guidelines for manuscript preparation can also be found (http://www.elsevier.com/journals/computer-communications/0140-3664/guide-for-authors). To ensure that all manuscripts are correctly identified for consideration by the Special Issue, the authors should select "Special Issue: OSN" when they reach the "Article Type" step in the submission process. For further information, please contact the guest editors at comcomsi_osn at iit.cnr.it From nobody Wed Jul 16 10:11:56 2014 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 9EE3F1A0097 for ; Wed, 16 Jul 2014 10:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 By9tq_HZS7jA for ; Wed, 16 Jul 2014 10:11:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B39211A0089 for ; Wed, 16 Jul 2014 10:11:49 -0700 (PDT) Received: from localhost ([::1]:49045 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X7Sjz-0002kA-Nn; Wed, 16 Jul 2014 10:11:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-manet-aodvv2@tools.ietf.org, lotte.steenbrink@fu-berlin.de X-Trac-Project: manet Date: Wed, 16 Jul 2014 17:11:39 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/42 Message-ID: <069.dc1798c89def0b64c3317643b3bd6ef2@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-aodvv2@tools.ietf.org, lotte.steenbrink@fu-berlin.de, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: charliep@computer.org, charles.perkins@earthlink.net, john.dowdell@cassidian.com, sratliff@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2EVwGTxYQqlII2hNO8lRB8x1_I4 Cc: manet@ietf.org Subject: [manet] #42 (aodvv2): What happens if Active routes exceed RERR packet size? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:11:55 -0000 #42: What happens if Active routes exceed RERR packet size? Section 8.3.2. states that {{{ After the Active Routes using the broken link have all been included as UnreachableNodes, Idle routes MAY also be included, if allowed by the setting of ENABLE_IDLE_UNREACHABLE, as long as the packet size of the RERR does not exceed the MTU (interface "Maximum Transfer Unit") of the physical medium. }}} However, it is not specified what happens if the listing of all ''Active'' routes already exceeds the packet size. In a large-scale network using IEEE 802.15.4., this is not unlikely to happen, and I think it should be defined how to handle this situation. -- -------------------------------------+------------------------------------- Reporter: lotte.steenbrink@fu- | Owner: draft-ietf-manet- berlin.de | aodvv2@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: manet From nobody Wed Jul 16 14:08:20 2014 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 932D51A0339 for ; Wed, 16 Jul 2014 14:08:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 6Lfhu2S9MNhc for ; Wed, 16 Jul 2014 14:08:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D38F1A0316 for ; Wed, 16 Jul 2014 14:08:00 -0700 (PDT) Received: from CO1PR07MB345.namprd07.prod.outlook.com (10.141.51.25) by CO1PR07MB347.namprd07.prod.outlook.com (10.141.51.18) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 16 Jul 2014 21:07:55 +0000 Received: from CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.159]) by CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.159]) with mapi id 15.00.0980.000; Wed, 16 Jul 2014 21:07:55 +0000 From: "Soyata, Tolga" To: "manet@ietf.org" Thread-Topic: New Extended Deadline: IEEE GLOBECOM Workshop on Cloud Computing Systems Networks and Applications (CCSNA) Thread-Index: Ac+hOgHDAs1gTeyoQeCpUJLhoyoFGg== Date: Wed, 16 Jul 2014 21:07:54 +0000 Message-ID: <5eef8047ce414ec08a7af8490ab3f2ab@CO1PR07MB345.namprd07.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.151.160.221] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(19300405004)(74502001)(2656002)(31966008)(92566001)(85852003)(54356999)(89122001)(107046002)(83072002)(101416001)(85306003)(74316001)(19625215002)(110136001)(16236675004)(95666004)(80022001)(50986999)(229853001)(77982001)(19617315012)(81342001)(18717965001)(77096002)(106356001)(15975445006)(74662001)(21056001)(86362001)(87936001)(76576001)(19580395003)(15202345003)(79102001)(76482001)(81542001)(75432001)(107886001)(99286002)(99396002)(4396001)(64706001)(83322001)(2351001)(20776003)(46102001)(16799955002)(66066001)(33646002)(105586002)(16601075003)(88552001)(108616002)(24736002)(217873001)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB347; H:CO1PR07MB345.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_5eef8047ce414ec08a7af8490ab3f2abCO1PR07MB345namprd07pro_" MIME-Version: 1.0 X-OriginatorOrg: rochester.edu Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZRIE3VL6M3ZJyybftUm1cTxlCOU Subject: [manet] New Extended Deadline: IEEE GLOBECOM Workshop on Cloud Computing Systems Networks and Applications (CCSNA) 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, 16 Jul 2014 21:08:17 -0000 --_000_5eef8047ce414ec08a7af8490ab3f2abCO1PR07MB345namprd07pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE International Workshop on Cloud Computing Systems, Networks, and Applications (CCSNA) (apologies for multiple copies) Organized in conjunction with IEEE Global Communications Conference (GLOBECOM 2014) 8-12 December 2014, Austin, Texas, USA Workshop web: http://cloud.it.teithe.gr/ EDAS submission web link: https://edas.info/newPaper.php?c=3D17545 Paper submission deadline: 21 July 2014 (Extended firm deadline; no further= extensions will be provided) Cloud Computing, as well as Cloud-inspired business models, enable on-deman= d access to a shared pool of resources, namely computing, storage, networks= , services, and applications. With the advent of Cloud-based systems, cloud= operators have been aiming at reliable, secured, privacy-preserving and co= st-efficient cloud design and management. As the Cloud infrastructure aims = at offering various IT resources as services, requirements of Cloud applica= tions vary based on the resources which are requested as services. Thus, th= e resources may refer to heavy computation resources, massive storage resou= rces, high-capacity network resources and so on. The heterogeneity of cloud= applications leads to the challenge of holistic design of a robust Cloud s= ystem which can oversee and handle the diverse needs of numerous types of a= pplications. On the other hand, these challenges enforce cooperation of var= ious players in the Cloud system, each of which focuses on a different segm= ent such as network, computing, applications, and systems. The Second Inter= national workshop on Cloud Computing Systems, Networks, and Applications (C= CSNA-2014) aims at the crossroads between scientists, researchers, practiti= oners and students from diverse domains in Cloud computing research. The wo= rkshop aims at attracting contributions of system and network design that c= an support existing and future applications and services. Researchers are e= ncouraged to submit original research contributions in all major areas, whi= ch include, but not limited to: *Cloud computing systems and networking- principles, designs, analyses, and= performance -Theoretical analysis for cloud systems -Cloud system and network design -Optimization for cloud computing, networking, and applications -Green cloud systems and networking -Storage, data, and analytics for clouds design and networking -Virtualization for cloud computing systems and networking -Modeling and performance analysis for cloud system, network and storage -Intra-cloud/inter-cloud computing and networking -Cloud computing architectures and cloud solution design patterns -Cloud migration, composition, federation, bridging, and bursting -Cloud provisioning and migration -Cloud DevOps -Cloud system design with FPGA, GPU, APU -Network Programmability, Software-Defined Networking and Virtual Ethernet = Switching *Big data, data centers, and cloud managements -Big data storage and networking -Real-time resource reporting and monitoring for cloud management -Cloud quality management and service level agreement (SLA) -Cloud configuration, performance, and capacity management -Cloud workload profiling and deployment control -Autonomic business process and workflow management in clouds -Collaboration, management, and administration of clouds and services -Quality of service on clouds and applications, including reliability, avai= lability -Scalability, performance, and load balance -Knowledge engineering and data mining techniques and systems on clouds -Data center network management, reliability, optimization, and bridging -Distributed data center architectures -Cloud traffic engineering and control-plane architectures *Cloud services, applications, security, and interdisciplinary topics -Cloud system and storage security -Mobile cloud system design -Cloud media and storage design -Security, privacy, and compliance management for clouds -Self-service cloud portal, dashboard, and analytics -Infrastructure, platform, application, business, social, and mobile clouds -Security, privacy, and compliance management for public, private, and hybr= id clouds -Innovative cloud applications and experiences -Economic, business and ROI models for cloud computing -Mobile-aware networking, protocols, and infrastructures -Content and service distribution in clouds -Audit, authentication and authorization in clouds -Service-oriented architecture in clouds -Cloud support for IoTs and their services -Cloud for service discovery -Image processing and efficient video transmission on clouds -Multimedia service provisioning on clouds -MapReduce -Resilience, fault tolerance *Surveys -Surveys on any topics above Submission Procedure Submitted papers must represent original material which is not currently un= der review in any other conference or journal and has not been previously p= ublished. Paper length should not exceed five-page standard IEEE conference= two-column format (including all text, figures, and references). Please se= e the Author Information page for submission guidelines in the IEEE GLOBECO= M 2014 website http://www.ieee-globecom.org. All submitted papers will go t= hrough a peer review process. All accepted and presented papers will be inc= luded in the IEEE GLOBECOM 2014 proceedings and IEEE digital library. IEEE = reserves the right to exclude an accepted and registered but not presented = paper from the IEEE digital library. Selected papers will be invited to be= peer-reviewed for a special issue in an IEEE journal and another journal s= pecial issue. Honorary General Chair Rajkumar Buyya, University of Melbourne, Australia General co-Chairs: Andy Rindos, IBM Research, USA Periklis Chatzimisios, Alexander TEI of Thessaloniki, Greece Technical Program co-Chairs: Burak Kantarci, University of Ottawa, Canada Kun Yang, University of Essex, U.K, Di Wu, Sun Yat-sen University, China Invited Speaker and Panel Co-Chairs: Luca Foschini (University of Bologna, Italy) Sun Zhili (University of Surrey, UK) Fen Hou ( University of Macau, China) Publication and EDAS Co-Chairs: Ranga Rao Venkatesha Prasad (Delft University of Technology, Netherlands) Berk Canberk (Istanbul Technical University, Turkey) Publicity Co-chairs Elhadj Benkhelifa, (Staffordshire University, UK) Tolga Soyata (University of Rochester) Ying Qian (East China Normal University, China) Christos Kouroupetroglou (Alexander TEI of Thessaloniki, Greece) Liang Zhou, Nanjing University of Posts and Telecommunications, China) Steering Committee Chuan Heng Foh (University of Surrey,UK) Jinsong Wu (Alcatel-Lucent, China) Yaser Jararweh (Jordan University of Science and Technology, Jordan) Mladen Vouk (North Carolina State University, USA) Important Dates Paper submission deadline: 21 July 2014 (Extended firm deadline; no extensi= ons will be provided) Author notification: 20 August 2014 Camera ready: 1 October 2014 --_000_5eef8047ce414ec08a7af8490ab3f2abCO1PR07MB345namprd07pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IEEE International Workshop on

Cloud Computing Systems, Networks, and Applications (CCSNA= )

 

(apologies for multiple copies)=

 

Organized in conjunction wi= th

IEEE Global Communicatio= ns Conference (GLOBECOM 2014) 

8-12 December 2014, Austin,= Texas, USA

Workshop web: http://cloud.it.teithe.gr/ 

<= /o:p>

EDAS submission web link: https://edas.info/newPaper.php?c=3D1= 7545

 =

Paper submission deadline: 21 July= 2014 (Extended firm deadline; no further extensions will be provided)

 =

Cloud Computing, as well as Cloud-inspired business model= s, enable on-demand access to a shared pool of resources, namely computing,= storage, networks, services, and applications. With the advent of Cloud-based systems, cloud operators have been aiming a= t reliable, secured, privacy-preserving and cost-efficient cloud design and= management. As the Cloud infrastructure aims at offering various IT resour= ces as services, requirements of Cloud applications vary based on the resources which are requested as serv= ices. Thus, the resources may refer to heavy computation resources, massive= storage resources, high-capacity network resources and so on. The heteroge= neity of cloud applications leads to the challenge of holistic design of a robust Cloud system which can ove= rsee and handle the diverse needs of numerous types of applications. On the= other hand, these challenges enforce cooperation of various players in the= Cloud system, each of which focuses on a different segment such as network, computing, applications, and syste= ms. The Second International workshop on Cloud Computing Systems, Networks,= and Applications (CCSNA-2014) aims at the crossroads between scientists, r= esearchers, practitioners and students from diverse domains in Cloud computing research. The workshop aims at att= racting contributions of system and network design that can support existin= g and future applications and services. Researchers are encouraged to submi= t original research contributions in all major areas, which include, but not limited to:

 

*C= loud computing systems and networking- principles, designs, analyses, and p= erformance

-T= heoretical analysis for cloud systems

-C= loud system and network design

-O= ptimization for cloud computing, networking, and applications

-G= reen cloud systems and networking

-S= torage, data, and analytics for clouds design and networking

-V= irtualization for cloud computing systems and networking

-M= odeling and performance analysis for cloud system, network and storage

-I= ntra-cloud/inter-cloud computing and networking=

-C= loud computing architectures and cloud solution design patterns

-C= loud migration, composition, federation, bridging, and bursting

-C= loud provisioning and migration

-C= loud DevOps

-C= loud system design with FPGA, GPU, APU

-N= etwork Programmability, Software-Defined Networking and Virtual Ethernet Sw= itching

&n= bsp;

&n= bsp;

*B= ig data, data centers, and cloud managements

-B= ig data storage and networking

-R= eal-time resource reporting and monitoring for cloud management

-C= loud quality management and service level agreement (SLA)

-C= loud configuration, performance, and capacity management

-C= loud workload profiling and deployment control<= o:p>

-A= utonomic business process and workflow management in clouds

-C= ollaboration, management, and administration of clouds and services<= span lang=3D"EN-CA">

-Q= uality of service on clouds and applications, including reliability, availa= bility

-S= calability, performance, and load balance<= /o:p>

-K= nowledge engineering and data mining techniques and systems on clouds

-D= ata center network management, reliability, optimization, and bridging

-D= istributed data center architectures=

-C= loud traffic engineering and control-plane architectures

&n= bsp;

*C= loud services, applications, security, and interdisciplinary topics<= span lang=3D"EN-CA">

-C= loud system and storage security

-M= obile cloud system design

-C= loud media and storage design=

-S= ecurity, privacy, and compliance management for clouds

-S= elf-service cloud portal, dashboard, and analytics

-I= nfrastructure, platform, application, business, social, and mobile clouds

-S= ecurity, privacy, and compliance management for public, private, and hybrid= clouds

-I= nnovative cloud applications and experiences

-E= conomic, business and ROI models for cloud computing

-M= obile-aware networking, protocols, and infrastructures

-C= ontent and service distribution in clouds<= /o:p>

-A= udit, authentication and authorization in clouds

-S= ervice-oriented architecture in clouds

-C= loud support for IoTs and their services

-C= loud for service discovery

-I= mage processing and efficient video transmission on clouds

-M= ultimedia service provisioning on clouds

-M= apReduce

-R= esilience, fault tolerance

&n= bsp;

*S= urveys

-S= urveys on any topics above

 Submission Procedure

Submitted papers must represe= nt original material which is not currently under review in a= ny other conference or journal and has not been previously published. Paper= length should not exceed five-page standard IEEE conference two-c= olumn format (including all text,= figures, and references). Please see the Autho= r Information page for submission guidelines in the IEEE GLOBECOM 2014 webs= ite http://www.ieee-globecom.org. All submitted papers= will go through a peer review pr= ocess. All accepted and pre= sented papers will be included in the IEEE GLOBECOM 2014 proceedings and IE= EE digital library. IEEE reserves the right to exclude an accepted and regi= stered but not presented paper from the IEEE digital library.  Selected papers will be invited to be p= eer-reviewed for a special issue in an IEEE journal and another journal spe= cial issue.

 

Honorary General Chair

Rajkumar Buyya, University of Melbo= urne, Australia

 <= o:p>

General co-Chairs:

Andy Rindos, IBM Research, USA

Periklis Chatzimisios, Alexander TE= I of Thessaloniki, Greece

 

Technical Program co-Chairs:

Burak Kantarci, University of Ottaw= a, Canada

Kun Yang, University of Essex, U.K,

Di Wu, Sun Yat-sen University, Chin= a

 

Invited Speaker and Panel Co-Cha= irs: 

Luca Foschini (University of Bologn= a, Italy)

Sun Zhili (University of Surrey, UK= )

Fen Hou ( University of Macau, Chin= a)

 

Publication and EDAS Co-Chairs:&= nbsp;

Ranga Rao Venkatesha Prasad (Delft = University of Technology, Netherlands)

Berk Canberk (Istanbul Technical Un= iversity, Turkey)

 

Publicity Co-chairs

Elhadj Benkhelifa, (Staffordshire U= niversity, UK)

Tolga Soyata (University of Rochest= er)

Ying Qian (East China Normal Univer= sity, China)

Christos Kouroupetroglou (Alexander= TEI of Thessaloniki, Greece) <= /span>

Liang Zhou, Nanjing University of P= osts and Telecommunications, China)<= /span>

 

Steering Committee

Chuan Heng Foh (University of Surre= y,UK) 

Jinsong Wu (Alcatel-Lucent, China) =  

Yaser Jararweh (Jordan University o= f Science and Technology, Jordan) 

Mladen Vouk (North Carolina State U= niversity, USA)

&= nbsp;

I= mportant Dates

Paper submission deadline: 21 July 2014 = (Extended firm deadline; no extensions will be provided)

Author notification: 20 August 2014

Camera ready: 1 October 2014<= /b>

 =

--_000_5eef8047ce414ec08a7af8490ab3f2abCO1PR07MB345namprd07pro_-- From nobody Thu Jul 17 04:36:57 2014 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 46DE71A0564 for ; Thu, 17 Jul 2014 04:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 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, 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 rXmLw2VjHP4Z for ; Thu, 17 Jul 2014 04:36:39 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ACC1A05C0 for ; Thu, 17 Jul 2014 04:36:39 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so2510883wes.19 for ; Thu, 17 Jul 2014 04:36:37 -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=yfGascCoIjcrsMpmjRJumFgI+UWir0Fgu6VKMzwy78Q=; b=C/oZWDjwPOm1N0axN1y1dMk2Pdv8WtMkCtChjG9RyaTpLFwSmTR/su1puNSpZ3j6FU wEqJYeW1zT7eouvp/ZETA4ww9s3RwCSNnlk8kEsqqqR3wRH22eTi4bGZQF+M8+zd4+U9 o8eTT8j1CrEymKkL8EJ1MbWGafJuT86EzL3EG9PXxxGLaRKWkPi0ZkFtZHKEuyX9/m6P P8GOWKk3RyOer9qlWVQddi35iFsoDPf0m2Om3dWJJgCwz4Au2A7nDfiWeEQjwlB9th4g IT0sYXgqTJjd1JAIFpZh+oBwZSEZak729mjcspESlpLaSVCH/i3NsyslfLmmrueSVELG YRtg== MIME-Version: 1.0 X-Received: by 10.194.158.164 with SMTP id wv4mr3145665wjb.124.1405596997839; Thu, 17 Jul 2014 04:36:37 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Thu, 17 Jul 2014 04:36:37 -0700 (PDT) In-Reply-To: References: <53BF69CE.7060702@earthlink.net> Date: Thu, 17 Jul 2014 12:36:37 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=089e013c6262c0f33204fe620de2 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/u51UrohGyRLfcuq6E4Q8lHpTVrk Cc: Charlie Perkins , "manet-chairs@tools.ietf.org" , manet Subject: Re: [manet] Slot requests 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, 17 Jul 2014 11:36:45 -0000 --089e013c6262c0f33204fe620de2 Content-Type: text/plain; charset=UTF-8 Hi Ulrich, I support 30-40 minutes for AODVv2 (includes present and discuss), to make more progress for the WG. This work has a discussion problem (on list and in meeting) as many IETF items have, so giving 15-20 minutes for discussing this work will help its progress. I suggest starting presentations of WG items before individual items, so we can make progress. IMHO, the WG needs to focus on priorities and its items' milestones, however, I recommend the agenda direction may not be per request/deadline but per priority or per consensus. On Friday, July 11, 2014, Ulrich Herberg wrote: > Hello Charlie, > > I have uploaded an updated agenda. The chairs allocated you a slot of > up to 20 minutes (assuming enough time is remaining at that point of > the meeting). > > @All: As there is risk that the "open mike" slot will fall off the > table, please let me know if there is anything you would like to > announce during that slot (e.g., a new interop event, a new > implementation, etc.) We can limit time of input from participants as 1 minute and maximum 3 inputs per item. > > Regards > Ulrich > > On Fri, Jul 11, 2014 at 7:24 AM, Ulrich Herberg > wrote: > > Hello Charlie, > > > > I will discuss this with the chairs and let you know. > > > > Regardless of what they decide, I'd really appreciate in the future to > > receive slot requests (in particular such large ones) several days > > *before* the first draft agenda deadline, Usually WG agenda can be flexible deadlines, so that we discuss it openly (both chairs are not attending, and we hoping more people attend, so flexible solves attendance problems). > not one business day before > > the final deadline. As you can see, the agenda is already very dense, WGs can request rooms and more time to discuss their important issues. > > so this will make it more difficult for me to schedule the meeting. Also we don't forget our milestones and progress. Any WG item is the responsibility of all participants, so we need to discuss them even if the editors of such item don't show up. My priority is AODVv2 and DLEP in this meeting. AB > > > > Thanks > > Ulrich > > > > On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins > > > wrote: > >> Hello Ulrich, > >> > >> Please schedule at least 30 minutes for reporting on the > >> current status of AODVv2. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> On 6/23/2014 11:34 AM, Ulrich Herberg wrote: > >>> > >>> Hi, > >>> > >>> the MANET meeting has been scheduled (preliminarily): > >>> > >>> manet Session 1 (2:00:00) > >>> Tuesday, Afternoon Session II 1420-1620 > >>> Room Name: Manitoba > >>> > >>> Please send your requests for slots during the meeting. > >>> > >>> Thanks > >>> Ulrich > >>> > >>> _______________________________________________ > >>> 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 > --089e013c6262c0f33204fe620de2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ulrich,

I support 30-40=C2=A0minutes for AODVv2 (incl= udes present and discuss), to make more progress for the WG. This work has = a discussion problem (on list and in meeting)=C2=A0as many IETF items have,= so giving 15-20 minutes for discussing this work will help its=C2=A0progre= ss. I suggest starting presentations of WG items before individual items, s= o we can make progress.=C2=A0

=C2=A0IMHO, the=C2=A0WG needs to focus on priorities an= d its=C2=A0items'=C2=A0milestones, however, I recommend=C2=A0the agenda= direction may not be per request/deadline=C2=A0but per priority or per con= sensus.=C2=A0


On Friday, July 11, 2014, Ulrich Herberg wrote:
Hello Charlie,

I have uploaded an updated agenda. The chairs allocated you a slot of
up to 20 minutes (assuming enough time is remaining at that point of
the meeting).

@All: As there is risk that the "open mike" slot will fall off th= e
table, please let me know if there is anything you would like to
announce during that slot (e.g., a new interop event, a new
implementation, etc.)

We can limit time of = input from participants as 1 minute and maximum 3 inputs per item.=C2=A0
=C2=A0

Regards
Ulrich

On Fri, Jul 11, 2014 at 7:24 AM, Ulrich Herberg <ulri= ch@herberg.name> wrote:
> Hello Charlie,
>
> I will discuss this with the chairs and let you know.
>
> Regardless of what they decide, I'd really appreciate in the futur= e to
> receive slot requests (in particular such large ones) several days
> *before* the first draft agenda deadline,=C2=A0

Usually WG agenda can= be flexible deadlines,=C2=A0so that we discuss it openly (both chairs are = not attending, and we hoping more people attend, so flexible solves attenda= nce problems).=C2=A0
=C2=A0
not one business day before=
> the final deadline. As you can see, the agenda is already very dense,<= /blockquote>

=C2=A0WGs can=C2=A0request rooms and=C2=A0m= ore time to discuss their important issues.=C2=A0
=C2=A0
> so this will make it more difficult for me to schedule the meeting.

Also we don't forget our milestones and p= rogress. Any WG item is the responsibility of all participants, so we need = to discuss them even if the editors of such item don't show up. My prio= rity is AODVv2 and DLEP in this meeting.=C2=A0

AB
=C2=A0
>
> Thanks
> Ulrich
>
> On Thu, Jul 10, 2014 at 9:36 PM, Charlie Perkins
> <charles.perkins@earthlink.net>= wrote:
>> Hello Ulrich,
>>
>> Please schedule at least 30 minutes for reporting on the
>> current status of AODVv2.
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>> On 6/23/2014 11:34 AM, Ulrich Herberg wrote:
>>>
>>> Hi,
>>>
>>> the MANET meeting has been scheduled (preliminarily):
>>>
>>> manet Session 1 (2:00:00)
>>> =C2=A0 =C2=A0 =C2=A0Tuesday, Afternoon Session II 1420-1620 >>> =C2=A0 =C2=A0 =C2=A0Room Name: Manitoba
>>>
>>> Please send your requests for slots during the meeting.
>>>
>>> Thanks
>>> Ulrich
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--089e013c6262c0f33204fe620de2-- From nobody Fri Jul 18 02:59:36 2014 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 6127C1A0173 for ; Fri, 18 Jul 2014 02:59:34 -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 MYFnNqLghPWr for ; Fri, 18 Jul 2014 02:59:32 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C4B1A0113 for ; Fri, 18 Jul 2014 02:59:32 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so3182581wgh.20 for ; Fri, 18 Jul 2014 02:59:31 -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=RRaVLudwV1978yQvGUy17k/nyM6xN1ZjctU7tuzRbew=; b=T6ECHi8514x3sB2g+9hzGijJY9KEyu/hKA1qt4+4eL9bbrXzAOT20G8SD47TIYfE9f kYbya04CnGLl1ZH6KbWRPMNlEX0ZOPbbxRDCblrn8CoV7mouV6ta3oNbcB2nLzpGoXsF +BJ/upqN6YzhlDk7s5mrIsodl5kgK5G/HDb/Ur2YxZUwpo2SKuBHACLClJG7jbm5eaaO 5RFCmf0ZOGBr8nn7mNxUJpLpxbqpGl8SVc34MbrjlkcO/Xnu8+71+b8p8sbx957104PP o7yuSaDHNC/Nfe6W4bxLH4xiRUOcYoDdHg2ecgf0O/s0hRlLLttJEdbMkBulDUrk6sSe l7hw== MIME-Version: 1.0 X-Received: by 10.194.92.115 with SMTP id cl19mr5022834wjb.29.1405677571199; Fri, 18 Jul 2014 02:59:31 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Fri, 18 Jul 2014 02:59:31 -0700 (PDT) In-Reply-To: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> Date: Fri, 18 Jul 2014 10:59:31 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7bfcf88e4cdc3604fe74d075 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GIu6ZX6XxTJtfkANFNnvjRW_D5w Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 18 Jul 2014 09:59:34 -0000 --047d7bfcf88e4cdc3604fe74d075 Content-Type: text/plain; charset=UTF-8 On Wednesday, July 2, 2014, Dearlove, Christopher (UK) wrote: > > I do not recall any previously asked and unanswered questions from you. > > > http://www.ietf.org/mail-archive/web/manet/current/msg15850.html The questions were for the draft before adoption, but if answered will help the experiment of this adopted protocol. I am sorry for not complete review but will submit shortly before meeting. AB --047d7bfcf88e4cdc3604fe74d075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, July 2, 2014, Dearlove, Christopher (UK) wrote:

I do not recall any previ= ously asked and unanswered questions from you.



The questions were for the draft before adoption, but if answered will help= the experiment=C2=A0of this adopted protocol. I am sorry for not complete = review but will submit shortly before meeting.=C2=A0

AB
--047d7bfcf88e4cdc3604fe74d075-- From nobody Fri Jul 18 07:49:28 2014 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 272B71A0AF2 for ; Fri, 18 Jul 2014 07:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 txpKKCNL-TTF for ; Fri, 18 Jul 2014 07:49:23 -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 572ED1A8BB0 for ; Fri, 18 Jul 2014 07:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9224; q=dns/txt; s=iport; t=1405694963; x=1406904563; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=szFKOBfN5X0lj5ROzCaFiCZ630t+/Zb9HJRuBl7ARTg=; b=h+KDI5AwY/RLLlrkdoEUn8YwkfczxT8lGKUGWTwtcOWnUwcfmoYYUZq6 uQTY+etrJtHF7OvagYqxr5LZQAUkY4H2Jjj4nLi5r20ehtS6chPJYOkbX sfv7lfwyKSQdsorCY5LJFXV9c+oqTej7FSg0wQLdzGjWdngFWnU8Mg1MQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADQzyVOtJA2L/2dsb2JhbABZgkdHUlvEZgEJh0MBgQgWdoQEAQEEAQEBUhkLEAIBCAc4BycLFBEBAQQOBYhCDcQ4F45pCgcBSwEEBwmDJYEYBZsllC+DRGyBAwkXIg X-IronPort-AV: E=Sophos;i="5.01,685,1400025600"; d="scan'208,217";a="341078722" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2014 14:49:22 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6IEnMIf004810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 14:49:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 09:49:21 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Three drafts to progress Thread-Index: Ac+g4AzL/nr5eDepTmK3VGcbYl9zyAB4VDQA Date: Fri, 18 Jul 2014 14:49:20 +0000 Message-ID: <2269A8ED-73CC-4334-A819-7D79521DE08B@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: multipart/alternative; boundary="_000_2269A8ED73CC4334A8197D79521DE08Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_mMWS40nIjhOuDL9RsF3g-H-xSQ Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] Three drafts to progress 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, 18 Jul 2014 14:49:25 -0000 --_000_2269A8ED73CC4334A8197D79521DE08Bciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Chris/All, draft-dearlove-manet-ibs-00 and draft-dearlove-manet-nhdp-optimization-01 a= re accepted as working group drafts. As Chris notes, draft-ietf-manet-olsrv2-multitopology-03 has cleared WGLC. = We'll work to get a document shepherd assigned and push for publication. Regards, Stan On Jul 16, 2014, at 6:27 AM, "Dearlove, Christopher (UK)" > wrote: Joe, Stan, All The call to adopt draft-dearlove-manet-ibs-00.txt as a WG document was made= on 30th June for comment within 2 weeks, which has now passed. The WGLC for draft-ietf-manet-olsrv2-multitopology-02 (updated to draft-iet= f-manet-olsrv2-multitopology-03 on 4th July based on comments made) was mad= e on 1st July, for comments by 14th July, which has now passed. The call to adopt draft-dearlove-manet-nhdp-optimization-01 was made on 2nd= July, with no period stated (which I overlooked) but has had a period of 2= weeks since then. I=92ve seen various positive comments, especially on the first two, and no = negative ones. I=92d like therefore to ask the chairs to take the appropria= te actions (some of which then come back to the authors). Christopher -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2269A8ED73CC4334A8197D79521DE08Bciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Chris/All, 

draft-dearlove-manet-ibs-00 and draft-dearlove-manet-nhdp-optimization= -01 are accepted as working group drafts. 

As Chris notes, draft-ietf-manet-olsrv2-multitopology-03 has cleared W= GLC. We'll work to get a document shepherd assigned and push for publicatio= n. 

Regards,
Stan

On Jul 16, 2014, at 6:27 AM, "Dearlove, Christopher (UK)" &l= t;chris.dearlove@baesystem= s.com> wrote:

Joe, Stan, All
 
The call to adopt draft-dearlove-manet-ibs-00.txt as a WG document was made= on 30th June for comment within 2 weeks, which has now passed.<= /div>
 
The WGLC for draft-ietf-manet-olsrv2-multitopology-02 (updated to draft-iet= f-manet-olsrv2-multitopology-03 on 4th July based on comments made) was mad= e on 1st July, for comments by 14th July, which has now passed.<= /div>
 
The call to adopt draft-dearlove-manet-nhdp-optimization-01 was made on 2nd= July, with no period stated (which I overlooked) but has had a period of 2= weeks since then.
 
I=92ve seen various positive comments, especially on the first two, and no = negative ones. I=92d like therefore to ask the chairs to take the appropria= te actions (some of which then come back to the authors).
 
Christopher
 
--
Christopher Dearlove
Senior Principal Engineer, Inform= ation Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@= baesystems.com | http= ://www.baesystems.com

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

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

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

--_000_2269A8ED73CC4334A8197D79521DE08Bciscocom_-- From nobody Fri Jul 18 10:47:19 2014 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 545071A0AAB for ; Fri, 18 Jul 2014 10:47:15 -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 medyob1eyYxc for ; Fri, 18 Jul 2014 10:47:14 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB091A000B for ; Fri, 18 Jul 2014 10:47:13 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so7873629vcb.29 for ; Fri, 18 Jul 2014 10:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BpiruT3ujnlb50pd/k0KIjj8fD7E/bfy2sdbb5Btkrw=; b=esTs98dcYNs9DWdBBIsjvEgeTtzlNGBIXB9nKRT3TyeZGJB87iSSl+26wJAMzIttj3 if55bb04ge8uyDU/Ru5FArljUHj4iiH+aF0c4VkeqXypNS9J6mxk8UUJOupAzNSRnQKM Rhtgy6RjQD6PsL2PDqg1cuSSzaEmax4yPq2Qw= 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:content-type; bh=BpiruT3ujnlb50pd/k0KIjj8fD7E/bfy2sdbb5Btkrw=; b=b+GhBBBxmjCgmSkre5Sfva9MoxT3wWvYEh4cG4D8cr4NNi+eHQYR75fxB5/TYWNUqZ HDj7nBl7KBoGh0mZkUwVoXHtXjXNE354KEXUE0GcVPY0O8MTScAo/erO+/3OAa2jrr8S vBNgsLg0yKXxWOczpmLMGk2R2V6OJlXuAcKlJIQQ/jT7atuZZvERVyX34DYm87EuO/TS ALzLlo8LGRJoOJaFxO/1uPDNmXRrki/FteLsabrn3Q9bIfiQrDUU/x3Jdqd9Rg6FiqZq Y/vKZH+AfRY6pHNJiuD7f2ywQ4m1fVTQaegVVTVXi0TvjDQjeWQH/GAX10aiZfhzkAG/ ax5A== X-Gm-Message-State: ALoCoQn6NJbUhpyJegfNfI+H+8eZz5rJCWvLBkwTBxht/s6mGnlsBBmZTWnMNKUPIpTDFMgcAIHb MIME-Version: 1.0 X-Received: by 10.52.171.233 with SMTP id ax9mr7056049vdc.76.1405705631335; Fri, 18 Jul 2014 10:47:11 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Fri, 18 Jul 2014 10:47:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Jul 2014 10:47:11 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qcHqE1tNQZaD37WZwgMpXl3o_n0 Subject: Re: [manet] Slides by July 18 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, 18 Jul 2014 17:47:15 -0000 Reminder: Those who haven't yet, please send me the slides today. Also, we still need a volunteer for minutes taker (thanks to Rick for volunteering for Jabber scribe!) Thanks Ulrich On Fri, Jul 11, 2014 at 9:21 AM, Ulrich Herberg wrote: > Hi, > > all presenters, please send me your slides by Friday, July 18. > > Thanks > Ulrich From nobody Sun Jul 20 06:25:48 2014 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 01F051B2C2D; Sun, 20 Jul 2014 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 pPf3Ndsz7Q3X; Sun, 20 Jul 2014 06:25:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9F48C1B2803; Sun, 20 Jul 2014 06:25:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3907C18001B; Sun, 20 Jul 2014 06:24:39 -0700 (PDT) To: T.clausen@computer.org, jiazi@jiaziyi.com, ulrich@herberg.name, T.Clausen@computer.org X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140720132439.3907C18001B@rfc-editor.org> Date: Sun, 20 Jul 2014 06:24:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0fiywg8RlIaPHZrSAYlkTrcwKaM Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Verified] RFC7186 (4034) 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: Sun, 20 Jul 2014 13:25:46 -0000 The following errata report has been verified for RFC7186, "Security Threats for the Neighborhood Discovery Protocol (NHDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7186&eid=4034 -------------------------------------- Status: Verified Type: Editorial Reported by: Thomas Clausen Date Reported: 2014-07-02 Verified by: Adrian Farrel (IESG) Section: 9.2 Original Text ------------- [RFC7185] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7185, April 2014. Corrected Text -------------- [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014. Notes ----- Apparently, the wrong RFC number was cited: RFC7185 is "Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)" Additionally, all references to RFC7185 in the document (Section 1 and Section 6) should read RFC7183. -------------------------------------- RFC7186 (draft-ietf-manet-nhdp-sec-threats-06) -------------------------------------- Title : Security Threats for the Neighborhood Discovery Protocol (NHDP) Publication Date : April 2014 Author(s) : J. Yi, U. Herberg, T. Clausen Category : INFORMATIONAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Jul 20 20:37:16 2014 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 CFCA31B2ABA for ; Sun, 20 Jul 2014 20:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 uLwShDWv4V8U for ; Sun, 20 Jul 2014 20:37:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B1B561A033E for ; Sun, 20 Jul 2014 20:37:13 -0700 (PDT) Received: from localhost ([::1]:35335 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94PZ-0002BD-FE; Sun, 20 Jul 2014 20:37:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:37:13 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/43 Message-ID: <061.7e05e09a5a981863ce7bf1d07b303583@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tWeJg6cCpRDI9INKAMWm-Z3qKXE Cc: manet@ietf.org Subject: [manet] #43 (aodvv2): Reliance on bidirectional paths (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:37:15 -0000 #43: Reliance on bidirectional paths (submitted for Chris Dearlove) The protocol relies on links being bidirectional. It must therefore provide a means to ensue that. It's not good enough to list several possibilities - that will not offer interoperability. It is fine of course to offer allowing additional reasons to exclude links, but there needs to be a basic non-optional mechanism for something that the protocol will not work without. -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: bidirectional -----------------------------------+----------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:38:44 2014 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 553F71B2B1B for ; Sun, 20 Jul 2014 20:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 jscNJanLUT9P for ; Sun, 20 Jul 2014 20:38:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 4DA1B1B2ABA for ; Sun, 20 Jul 2014 20:38:41 -0700 (PDT) Received: from localhost ([::1]:35357 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94Qz-0002Gi-6F; Sun, 20 Jul 2014 20:38:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:38:41 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/44 Message-ID: <061.da9873dd6d5b2c594251eb39ecba54b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pIysTE68c_8BMPtBjZNB58QNJIc Cc: manet@ietf.org Subject: [manet] #44 (aodvv2): Hop count (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:38:42 -0000 #44: Hop count (submitted for Chris Dearlove) Despite saying that hop count is inadequate, it's the only metric supported. And unlike OLSRv2, which is designed so that the protocol can handle any future metric without change, that's not true here. That's a definite protocol weakness. -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: hop count -----------------------------------+----------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:40:26 2014 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 7330B1B2ABA for ; Sun, 20 Jul 2014 20:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 LRIdd9M-bmPa for ; Sun, 20 Jul 2014 20:40:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 080231A033E for ; Sun, 20 Jul 2014 20:40:23 -0700 (PDT) Received: from localhost ([::1]:35407 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94SX-0002hx-Nm; Sun, 20 Jul 2014 20:40:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:40:17 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/45 Message-ID: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: charliep@computer.org, charles.perkins@earthlink.net, john.dowdell@cassidian.com, sratliff@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zh-DIsd4aGkVZvwXy26oXvvDN-A Cc: manet@ietf.org Subject: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:40:24 -0000 #45: RFC 5498 non-compliance (submitted for Chris Dearlove) The document is completely noncompliant with the RFC 5444 multiplexing mechanism, mandated by RFC 5498 (on the manet port/protocol). It does many things that are not within its competence. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-manet- charliep@computer.org | aodvv2@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG | Keywords: RFC 5498 Document | -------------------------+------------------------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:42:32 2014 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 731C81B2B1B for ; Sun, 20 Jul 2014 20:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qTy8fWqkIF3a for ; Sun, 20 Jul 2014 20:42:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1F0191A033E for ; Sun, 20 Jul 2014 20:42:29 -0700 (PDT) Received: from localhost ([::1]:35471 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94Ud-0003EC-BA; Sun, 20 Jul 2014 20:42:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:42:27 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/46 Message-ID: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: charliep@computer.org, charles.perkins@earthlink.net, john.dowdell@cassidian.com, sratliff@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/L1_yFAx_FoJ2NiLSje327nLywBc Cc: manet@ietf.org Subject: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:42:30 -0000 #46: What is needed from IP and ICMP (submitted for Chris Dearlove) The protocol needs many things from IP, such as failed routing notification, and interacts with it in ways such as queuing packets. It also interacts (sends and receives) with ICMP, and I'm not sure what else. This needs to be put together, so the reader can see what is needed to be able to implement this. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-manet- charliep@computer.org | aodvv2@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG | Keywords: IP/ICMP interaction Document | -------------------------+------------------------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:44:21 2014 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 1AF781B2C96 for ; Sun, 20 Jul 2014 20:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 mLFNDTpByzgZ for ; Sun, 20 Jul 2014 20:44:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 71F861B2ABA for ; Sun, 20 Jul 2014 20:44:00 -0700 (PDT) Received: from localhost ([::1]:35510 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94W6-0003O1-LM; Sun, 20 Jul 2014 20:43:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:43:58 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/47 Message-ID: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: charliep@computer.org, charles.perkins@earthlink.net, john.dowdell@cassidian.com, sratliff@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_Ry-GYkviZkgTgaIbfs3qTjb1t8 Cc: manet@ietf.org Subject: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:44:06 -0000 #47: Security approach unacceptable (submitted for Chris Dearlove) The security approach is unacceptable. The security directorate and ADs refused to accept this from OLSRv2. They will refuse to accept this from this protocol. Incidentally note that references to RFC 6621 should be to RFC 6622, except now to RFC 7182. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-manet- charliep@computer.org | aodvv2@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG | Keywords: security Document | -------------------------+------------------------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:46:03 2014 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 A12721B2CAA for ; Sun, 20 Jul 2014 20:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BQTP19bg3tX0 for ; Sun, 20 Jul 2014 20:46:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 7F8DB1B2CA0 for ; Sun, 20 Jul 2014 20:46:00 -0700 (PDT) Received: from localhost ([::1]:35633 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94Y4-0003u7-5v; Sun, 20 Jul 2014 20:46:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:46:00 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/48 Message-ID: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/TXkT81j1KCA6V3mpuIYH1--iuXo Cc: manet@ietf.org Subject: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:46:01 -0000 #48: Single address per interface per router (submitted for Chris Dearlove) The model is of routers with a single address per interface. In OLSRv2 this wasn't considered acceptable. The authors defined multiple addresses per interface, the WG required supporting unnumbered interfaces which shared addresses. -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: Router addressability -----------------------------------+----------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:47:46 2014 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 83C4E1B2A9E for ; Sun, 20 Jul 2014 20:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8gFJ_pXYGMjI for ; Sun, 20 Jul 2014 20:47:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 05CF71B2A46 for ; Sun, 20 Jul 2014 20:47:43 -0700 (PDT) Received: from localhost ([::1]:35691 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94Zi-0006jk-St; Sun, 20 Jul 2014 20:47:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:47:42 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/49 Message-ID: <061.f1fddacae41ce5f0356d026067b21ce1@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/F2ppv5PyX5tIwcfHXK9gK4NiXoo Cc: manet@ietf.org Subject: [manet] #49 (aodvv2): Locating pseudocode in appendix (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:47:44 -0000 #49: Locating pseudocode in appendix (submitted for Chris Dearlove) Appendix A. If pseudo-code is needed to explain the algorithms, it needs to be in the main body. If the main body is considered complete (and this is at the detail level I've not read) I'm not sure exactly what this is offering. I's also too C-like (NULL for example) while not being C (use of := - although not fully consistently). I don't think the balance is right here. -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: Algorithm pseudocode -----------------------------------+----------------------------------- Ticket URL: manet From nobody Sun Jul 20 20:49:40 2014 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 5C5931B2CC6 for ; Sun, 20 Jul 2014 20:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 N4AfMfzs8FSL for ; Sun, 20 Jul 2014 20:49:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1D4841B2A9E for ; Sun, 20 Jul 2014 20:49:32 -0700 (PDT) Received: from localhost ([::1]:35748 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X94bT-0002WF-W8; Sun, 20 Jul 2014 20:49:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 21 Jul 2014 03:49:31 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/50 Message-ID: <061.611a86a3d3f3e1919d0b2478801e1534@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/94g_KvfYKuL_MoCtelJ5hOH6kik Cc: manet@ietf.org Subject: [manet] #50 (aodvv2): Weak gateway support (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:49:38 -0000 #50: Weak gateway support (submitted for Chris Dearlove) Gateway support is weak - OLSRv2 can support multiple gateways with the same, or overlapping, address ranges. -- -----------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: Gateway -----------------------------------+----------------------------------- Ticket URL: manet From nobody Sun Jul 20 21:08:32 2014 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 D547A1B2CA1 for ; Sun, 20 Jul 2014 21:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 6M7xdkGKKK_1 for ; Sun, 20 Jul 2014 21:08:27 -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 B83911B2A46 for ; Sun, 20 Jul 2014 21:08:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WuEz7qa8orQUHq9zwwesgVCPoubTPVYzEKFldAkOvyW8L++NRtn0gbBLn9VGaC/u; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.149.207] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X94ti-0007cR-D4; Mon, 21 Jul 2014 00:08:22 -0400 Message-ID: <53CC9234.4010502@earthlink.net> Date: Sun, 20 Jul 2014 21:08:20 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org, lotte.steenbrink@fu-berlin.de References: <069.dc1798c89def0b64c3317643b3bd6ef2@trac.tools.ietf.org> In-Reply-To: <069.dc1798c89def0b64c3317643b3bd6ef2@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac70a69f45fa6699587d4513ec817ad3210350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cyWnIIMSbsRcvXygYwje6fNPJNQ Subject: Re: [manet] #42 (aodvv2): What happens if Active routes exceed RERR packet size? 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, 21 Jul 2014 04:08:30 -0000 Hello Lotte, I can indeed imagine it happening, but I am not sure what the proper resolution should be. While it is true that many routes *might* be active in a large network, I suspect that the problem would only arise in a few nodes that are situated as the main point of connectivity between two subgraphs. Anyway, the problem needs a solution. It seems that the active routes SHOULD be reported as broken, and that the order of reporting SHOULD be in order of time of use. I don't think the ordering should be mandated, because some implementations might not want to do the extra code, and it wouldn't affect interoperability. Performance might be adversely affected in the rare cases where there are many active routes in service. A node would report the overflow active routes by creating another RERR message and putting in as many active routes as possible. If this is acceptable, I think it will be quite straightforward to revise the draft accordingly. Maybe the text should go into a new subsection. Comments? Regards, Charlie P. On 7/16/2014 10:11 AM, manet issue tracker wrote: > #42: What happens if Active routes exceed RERR packet size? > > Section 8.3.2. states that > > > {{{ > After the Active Routes using > the broken link have all been included as UnreachableNodes, Idle > routes MAY also be included, if allowed by the setting of > ENABLE_IDLE_UNREACHABLE, as long as the packet size of the RERR > does > not exceed the MTU (interface "Maximum Transfer Unit") of the > physical medium. > }}} > > > However, it is not specified what happens if the listing of all ''Active'' > routes already exceeds the packet size. In a large-scale network using > IEEE 802.15.4., this is not unlikely to happen, and I think it should be > defined how to handle this situation. > From nobody Sun Jul 20 21:12:48 2014 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 6D1871B2A9E for ; Sun, 20 Jul 2014 21:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 hwp1jTkiCtNV for ; Sun, 20 Jul 2014 21:12:46 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE451A0338 for ; Sun, 20 Jul 2014 21:12:46 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X94xx-000351-Hp; Mon, 21 Jul 2014 00:12:45 -0400 Message-ID: <53CC9339.50103@computer.org> Date: Sun, 20 Jul 2014 21:12:41 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, "Dearlove, Christopher (UK)" , draft-ietf-manet-aodvv2@tools.ietf.org References: <061.7e05e09a5a981863ce7bf1d07b303583@trac.tools.ietf.org> In-Reply-To: <061.7e05e09a5a981863ce7bf1d07b303583@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac70ffad106b132cb2541a8377ab11459a9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YWaGFjL7n86ONZUNcGPc1U2qCRE Subject: Re: [manet] #43 (aodvv2): Reliance on bidirectional paths (submitted for Chris Dearlove) 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, 21 Jul 2014 04:12:47 -0000 Hello Chris, Perhaps it would be better to identify the proper protocol method as part of the applicability statement. If no other means are available, then AODVv2 nodes could be required to use the blacklist mechanism, which is intended to provide bidirectionality. It seems unwise to require additional protocol mechanisms for cases in which layer 2 already guarantees bidirectional links. This could also be included as a statement within the applicability section. Regards, Charlie P. On 7/20/2014 8:37 PM, manet issue tracker wrote: > #43: Reliance on bidirectional paths (submitted for Chris Dearlove) > > The protocol relies on links being bidirectional. It must therefore > provide a means to ensue that. It's not good enough to list several > possibilities - that will not offer interoperability. It is fine of course > to offer allowing additional reasons to exclude links, but there needs to > be a basic non-optional mechanism for something that the protocol will not > work without. > -- Regards, Charlie P. From nobody Sun Jul 20 21:16:46 2014 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 C97CC1B2A9E for ; Sun, 20 Jul 2014 21:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 2U-6DgkMFamQ for ; Sun, 20 Jul 2014 21:16:45 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0284A1B2D1A for ; Sun, 20 Jul 2014 21:16:45 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X951j-0006t7-Mk; Mon, 21 Jul 2014 00:16:39 -0400 Message-ID: <53CC9423.1010502@computer.org> Date: Sun, 20 Jul 2014 21:16:35 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, "Dearlove, Christopher (UK)" , draft-ietf-manet-aodvv2@tools.ietf.org References: <061.da9873dd6d5b2c594251eb39ecba54b5@trac.tools.ietf.org> In-Reply-To: <061.da9873dd6d5b2c594251eb39ecba54b5@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7bdf56a770fb56aeab016f3f1fec14be3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/oqBJ8KGVzK7KPU7ItCB0epFK474 Subject: Re: [manet] #44 (aodvv2): Hop count (submitted for Chris Dearlove) 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, 21 Jul 2014 04:16:46 -0000 Hello Chris, I do not understand why you make the claim that AODVv2 cannot handle future metric changes. If nodes wish to use alternate metrics, the current draft specifies mechanisms to insure that routes will be selected based on the costs associated to those routes as computed by the alternate metric. If this is not true, could you be more specific about how the intended mechanisms fail to do so? Regards, Charlie P. On 7/20/2014 8:38 PM, manet issue tracker wrote: > #44: Hop count (submitted for Chris Dearlove) > > Despite saying that hop count is inadequate, it's the only metric > supported. And unlike OLSRv2, which is designed so that the protocol > can handle any future metric without change, that's not true here. > That's a definite protocol weakness. > -- Regards, Charlie P. From nobody Sun Jul 20 21:32:53 2014 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 A57411B2CC8 for ; Sun, 20 Jul 2014 21:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 yzZvPYCBZUTe for ; Sun, 20 Jul 2014 21:32:51 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id DA3CC1B2AC4 for ; Sun, 20 Jul 2014 21:32:50 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X95HN-0006MN-KF; Mon, 21 Jul 2014 00:32:49 -0400 Message-ID: <53CC97ED.4050308@computer.org> Date: Sun, 20 Jul 2014 21:32:45 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org, "Dearlove, Christopher (UK)" References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> In-Reply-To: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac75333698d63446487cd684d1b443531fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZU_BcA3hCdtmU8Q7NBQaCHcu2io Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) 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, 21 Jul 2014 04:32:51 -0000 Hello Chris, The document states: > In its default mode of operation, AODVv2 sends messages using the > parameters for port number and IP protocol specified in [RFC5498] to > carry protocol packets. By default, AODVv2 messages are sent with > the IP destination address set to the link-local multicast address > LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore, > all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to > receiving AODVv2 messages. So, I suspect the problem lies elsewhere. Could you point to the noncompliant part of the AODVv2 specification, and the protocol mandate for which the AODVv2 specification is noncompliant? On 7/20/2014 8:40 PM, manet issue tracker wrote: > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) > > The document is completely noncompliant with the RFC 5444 multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. > -- Regards, Charlie P. From nobody Sun Jul 20 21:39:45 2014 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 D048C1B2D5B for ; Sun, 20 Jul 2014 21:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 x53ThingPIQT for ; Sun, 20 Jul 2014 21:39:42 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id C33DB1B2CC8 for ; Sun, 20 Jul 2014 21:39:42 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X95Nz-0007td-La; Mon, 21 Jul 2014 00:39:39 -0400 Message-ID: <53CC9987.6060104@computer.org> Date: Sun, 20 Jul 2014 21:39:35 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org, "Dearlove, Christopher (UK)" References: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> In-Reply-To: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac722f24ad18e314e662d1fc5a9572455ab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SthSnXHlMr4UnXVUH27NvgyOvl4 Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) 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, 21 Jul 2014 04:39:44 -0000 Hello Chris, I am pretty sure that the only things needed from IP and ICMP are features that are already mandated by IP (including ICMP). If there were danger that AODVv2 might require optional features of IP or optional features of ICMP, I could understand your concern. As it is, I do not understand exactly what is needed to enhance implementability of the specification. The only thing expected from ICMP is delivery of Destination Unreachable (Type 3 Code 1). Is this something that implementations are unlikely to provide? I am confused about what (other than ICMP) AODVv2 "needs" from IP that could cause a problem. True, we do expect IP to find the proper outgoing interface, and to perform longest-prefix-first matching, and so on... Do you have an example of some other protocol specification that lists these kinds of dependencies? On 7/20/2014 8:42 PM, manet issue tracker wrote: > #46: What is needed from IP and ICMP (submitted for Chris Dearlove) > > The protocol needs many things from IP, such as failed routing > notification, and interacts with it in ways such as queuing packets. > It also interacts (sends and receives) with ICMP, and I'm not sure > what else. This needs to be put together, so the reader can see what > is needed to be able to implement this. > -- Regards, Charlie P. From nobody Sun Jul 20 21:41:33 2014 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 CA9181B2D62 for ; Sun, 20 Jul 2014 21:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 RbSa1iu-eZap for ; Sun, 20 Jul 2014 21:41:30 -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 DDF221B2D61 for ; Sun, 20 Jul 2014 21:41:29 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X95Pi-0002Ip-RO; Mon, 21 Jul 2014 00:41:26 -0400 Message-ID: <53CC99F2.5050103@computer.org> Date: Sun, 20 Jul 2014 21:41:22 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org, "Dearlove, Christopher (UK)" References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> In-Reply-To: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7216f4c87cd7e58feff99f8bee936bfb9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0bVELWbqJX5GZn5tlgwlINQmF3w Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 21 Jul 2014 04:41:31 -0000 Hello Chris, I have thought about this for a long time. Finally, after some good discussion here at the IETF, I have identified a way forward. I will post it to the list after getting some proper security review for it. On 7/20/2014 8:43 PM, manet issue tracker wrote: > #47: Security approach unacceptable (submitted for Chris Dearlove) > > The security approach is unacceptable. The security > directorate and ADs refused to accept this from OLSRv2. They will > refuse to accept this from this protocol. Incidentally note that > references to RFC 6621 should be to RFC 6622, except now to RFC 7182. > -- Regards, Charlie P. From nobody Sun Jul 20 21:45:40 2014 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 48E361B2D67 for ; Sun, 20 Jul 2014 21:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 tOKXcZAvlpDa for ; Sun, 20 Jul 2014 21:45:33 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id B76511B2D62 for ; Sun, 20 Jul 2014 21:45:33 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X95Te-0004ee-JF; Mon, 21 Jul 2014 00:45:30 -0400 Message-ID: <53CC9AE6.7090800@computer.org> Date: Sun, 20 Jul 2014 21:45:26 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, "Dearlove, Christopher (UK)" , draft-ietf-manet-aodvv2@tools.ietf.org References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> In-Reply-To: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7a9c7e44e41919df32543127d2f03194f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6ByCOJ4FTi0PJsP29ZTw1E__ygM Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 21 Jul 2014 04:45:38 -0000 Hello Chris, AODVv2 does not impose this restriction. It has, for a long time, enabled multiple router addresses per interface. I will look again, but as of now I do not see where any such restriction has been imposed. If you have identified where this restriction is implied or stated directly, please let me know as soon as possible. Unnumbered interfaces have never been suggested as appropriate for inclusion of the feature set for any reactive protocol that was under consideration within [manet], all the way since the very initiation of the working group. At least not within my memory. On 7/20/2014 8:46 PM, manet issue tracker wrote: > #48: Single address per interface per router (submitted for Chris Dearlove) > > The model is of routers with a single address per interface. In OLSRv2 > this wasn't considered acceptable. The authors defined multiple addresses > per interface, the WG required supporting unnumbered interfaces which > shared addresses. > -- Regards, Charlie P. From nobody Sun Jul 20 21:54:54 2014 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 9ED231B2D58 for ; Sun, 20 Jul 2014 21:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 Vp4nIXIiLdYw for ; Sun, 20 Jul 2014 21:54:47 -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 ADBA51B2D53 for ; Sun, 20 Jul 2014 21:54:47 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X95cc-0007Hj-D9; Mon, 21 Jul 2014 00:54:46 -0400 Message-ID: <53CC9D14.1030102@computer.org> Date: Sun, 20 Jul 2014 21:54:44 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org, "Dearlove, Christopher (UK)" , draft-ietf-manet-aodvv2@tools.ietf.org References: <061.f1fddacae41ce5f0356d026067b21ce1@trac.tools.ietf.org> In-Reply-To: <061.f1fddacae41ce5f0356d026067b21ce1@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7bb4d52a78f326ffa8db70bef924de3ac350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kF4_HgMEK6o9XhNISUFq9NeG0EY Subject: Re: [manet] #49 (aodvv2): Locating pseudocode in appendix (submitted for Chris Dearlove) 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, 21 Jul 2014 04:54:48 -0000 Hello Chris, Appendix A was developed in response to issue #23. It is intended to assist with code development. The main body is intended to contain the complete specification, and the appendix is intended to offer another way of guiding the development of the code. The explanation of the protocol in the main body should not only provide the mandates and options, but also provide the explanation and understanding for the inclusion of the protocol features. Appendix A is certainly not intended to be confused with compilable code. I used various syntactic devices that I have seen elsewhere in many places; terminology like "NULL" and ":=" is pretty unambiguous. Nevertheless, I am definitely open to suggestion. What are your preferences? I don't yet understand the manner in which the algorithms are not balanced. However, this appendix has been undergoing many changes during the last several weeks, and I expect that there will be more corrections and improvements. On 7/20/2014 8:47 PM, manet issue tracker wrote: > #49: Locating pseudocode in appendix (submitted for Chris Dearlove) > > Appendix A. If pseudo-code is needed to explain the algorithms, it > needs to be in the main body. If the main body is considered complete > (and this is at the detail level I've not read) I'm not sure exactly > what this is offering. I's also too C-like (NULL for example) while > not being C (use of := - although not fully consistently). I don't > think the balance is right here. > -- Regards, Charlie P. From nobody Sun Jul 20 22:44:31 2014 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 DF90A1B2DA8 for ; Sun, 20 Jul 2014 22:44:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Neek4NfWxNmd for ; Sun, 20 Jul 2014 22:44:22 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9487F1B2D9E for ; Sun, 20 Jul 2014 22:44:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GPBcZdTxLx9Y4GbH4APUT66IEOnhPYtyVngFSeu9gFwezYjTN6bJKph2w63KvkXB; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.149.207] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X96OY-0004Qj-U5; Mon, 21 Jul 2014 01:44:19 -0400 Message-ID: <53CCA8B1.5050705@earthlink.net> Date: Sun, 20 Jul 2014 22:44:17 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lotte Steenbrink , manet@ietf.org References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <05CD0538-85C5-4986-A49A-D74965634262@thomasclausen.org> <768F7407-94BE-41F1-ABA6-0FC0131F8B5D@fu-berlin.de> In-Reply-To: <768F7407-94BE-41F1-ABA6-0FC0131F8B5D@fu-berlin.de> Content-Type: multipart/alternative; boundary="------------090205020903040105050300" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac720a3adf0edd299cc2fefe61d8c299a88350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/TBvO--6W-uyS5S5-VHRWpDI03gA Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK 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, 21 Jul 2014 05:44:28 -0000 This is a multi-part message in MIME format. --------------090205020903040105050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Lotte and all, To review and summarize: The AckReq TLV is to be included with the RREP, in cases where the the node sending the RREP must ascertain that the intended receiver of the RREP will actually receive it. When a node receives an RREP that includes the AckReq TLV, then that node must send back a response. The discussion has been about whether or not to mandate that the RREP_Ack is to be sent as that response. AckReq and RREP_Ack not technically required. The nodes can verify bidirectionality in other ways. Some layer 2 protocols provide bidirectionality. Even for cases where a layer-3 solution is desired, additional AODVv2 protocol is not required. Ping is a time-tested and well understood mechanism for verifying connectivity. Henning has suggested including and perhaps even mandating RREP_Ack to be used in preference to existing protocol mechanisms. For me, this is a minor issue. It has been stated many times that AODVv2 should be a "lean" protocol, and that sentiment had led me to favor exclusion of RREP_Ack from the protocol. I was later persuaded to include it as an optional feature. I can be persuaded either way -- leaner versus more self-contained. I do not really care. I feel that the "self-contained" argument is weak, because no protocol running on top of IP is self contained (by definition). But whether or not the argument is weak, if AODVv2 is considered to need this feature, I am happy to retain the specification for it, as well as supporting text for when it should be used. Another alternative would be to *mandate* the use of ping for this purpose. To me it seems unwise to mandate ping when the link is known to be bidirectional (by way of any other mechanism, layer 2 or layer 3). This is perhaps especially true because, when any mechanism (including Ping) would be mandated, is exactly the time when congestion on the wireless link should be avoided, and mandating unnecessary control traffic is often considered to be improper protocol design. But, to reiterate, the mandate can be included without serious problem other than additional code and some small percentage of increased congestion. In some previous messages, there was confusion between the AckReq TLV and the RREP_Ack response to that TLV. I hope this long-ish message will erase this small bit of earlier confusion. On 5/29/2014 8:15 AM, Lotte Steenbrink wrote: > Hello, > > Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen > >: > >> It would be interesting to understand why AckReq was included in the >> first place - given that that seems redundant with the well-known >> rrep_ack mechanism, and given that (it seems to me) that there are >> potential huge downsides to AckReq. > > Of course. I forgot to check whether my E-Mail client messed up the > order of my mails again before I sent my reply, that's why my reply > was a bit redundant. Sorry about that. > > The reason I opted for a removal of RREP_ACKs instead of AckReqs was > that, to me, the description of RREP_ACKs in the AODVv2 draft seemed > like an afterthought. Being somewhat new to the topic, I'm as familiar > with RREP_ACKs as I am with AckReqs, with the difference being that > I'd have no idea how to implement RREP_ACKs, at least not from the > AODVV2 specification: > How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume > that, because Section 5.2. demands that AckReqs should be requested by > adding an appropriate message TLV, the same applies to RREP_ACKs, but > that kind of guesswork could lead to interoperability issues. > Why doesn't the draft remind me that (and how) a RREP "with the 'A' > flag set" should be handled? Why doesn't it remind me that (and how) a > RREP_ACK should be handled? > > Using other sources, i'd probably be able to cobble *something* > together, but I'd guess that the probability that another programmer > will come up with the same interpretation is not that high. > > So, what I was basically saying is just: Having two ways of ensuring > bidirectionality is confusing (and maybe standing in the way of > interoperability?), and one of the ways is confusing in itself, and I > think that needs to be sorted out-- by ditching one of the approaches > and being more specific in case RREP_ACKs are here to stay. > > Cheers, > Lotte Steenbrink > > >> >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org >> >> "Today's scientists have substituted mathematics for >> experiments, and they wander off through equation >> after equation, and eventually build a structure >> which has no relation to reality." >> - Nikola Tesla, >> Modern Mechanics and Inventions, July, 1934 >> >> On 29 mai 2014, at 15:05, Lotte Steenbrink >> > > wrote: >> >>> Hello Yuichi, >>> >>> Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI >>> >> >: >>> >>>> Hi Charlie, >>>> >>>> It says in sec.4 that "AODVv2 only supports bidirectional links". >>>> But, if you remove RREP_ACK from the spec, how does AODVv2 itself >>>> ensure all links are bi-directional? >>> >>> AODVv2 proposes the inclusion of an AckReq TLV to ensure >>> bidirectional connectivity. My point was that, given the existence >>> of this AckReq mechanism, the additional inclusion of RREP_ACK seems >>> redundant. >>> >>> Cheers, >>> Lotte >>> >>> [1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2 >>> >>>> AODVv2 requires all routes to implement other protocol for >>>> verifying bi-directionality of links? I am sure that would cause >>>> interoperability problems. >>>> Also, this is related to tickets #26 and #27, I think. >>>> >>>> Regards, >>>> Yuichi >>>> (2014/05/29 2:34), Charlie Perkins wrote: >>>>> >>>>> Hello Lotte, >>>>> >>>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>>> some discussion a while back about compatibility, but I have not >>>>> seen anyone defending the RREP_ACK in this discussion and it was >>>>> not present in the previous DYMO drafts. >>>>> >>>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>>> some more detailed specification for handling it, which will be >>>>> basically the way it was handled by AODV. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>>> #41: AckReq vs RREP_ACK >>>>>> >>>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>>>> called >>>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>>> described >>>>>> in section 5.2. >>>>>> While RFC 3561, which is referenced in section 13.5., explains >>>>>> that a >>>>>> RREP-ACK is sent when a packet with the 'A' bit set is received, the >>>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>>> Additionally, the draft does not specify how a RREP_ACK should be >>>>>> handled. >>>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>>> explanation >>>>>> should be added. Otherwise, removing it could be a step towards de- >>>>>> cluttering the draft. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>> >>>> -- >>>> Hitachi, Ltd., Yokohama Research Laboratory >>>> Yuichi Igarashi >>>> Mail: yuichi.igarashi.hb@hitachi.com >>>> >>>> Tel : +81-(0)50-3135-3457 >>> >>> _______________________________________________ >>> 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 --------------090205020903040105050300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Lotte and all,

To review and summarize:

The AckReq TLV is to be included with the RREP, in cases where the
the node sending the RREP must ascertain that the intended receiver
of the RREP will actually receive it.

When a node receives an RREP that includes the AckReq TLV, then that
node must send back a response.  The discussion has been about
whether or not to mandate that the RREP_Ack is to be sent as that
response.

AckReq and RREP_Ack not technically required.  The nodes can verify
bidirectionality in other ways.  Some layer 2 protocols provide
bidirectionality.  Even for cases where a layer-3 solution is desired,
additional AODVv2 protocol is not required.  Ping is a time-tested
and well understood mechanism for verifying connectivity.

Henning has suggested including and perhaps even mandating
RREP_Ack to be used in preference to existing protocol mechanisms.

For me, this is a minor issue.  It has been stated many times that
AODVv2 should be a "lean" protocol, and that sentiment had led me
to favor exclusion of RREP_Ack from the protocol.   I was later
persuaded to include it as an optional feature.  I can be persuaded
either way -- leaner versus more self-contained.  I do not really care.
I feel that the "self-contained" argument is weak, because no
protocol running on top of IP is self contained (by definition).
But whether or not the argument is weak, if AODVv2 is considered
to need this feature, I am happy to retain the specification for it,
as well as supporting text for when it should be used.

Another alternative would be to *mandate* the use of ping for
this purpose.  To me it seems unwise to mandate ping when the
link is known to be bidirectional (by way of any other mechanism,
layer 2 or layer 3).  This is perhaps especially true because, when
any mechanism (including Ping) would be mandated, is exactly
the time when congestion on the wireless link should be avoided,
and mandating unnecessary control traffic is often considered to
be improper protocol design.

But, to reiterate, the mandate can be included without serious
problem other than additional code and some small percentage
of increased congestion.

In some previous messages, there was confusion between the
AckReq TLV and the RREP_Ack response to that TLV.  I hope this
long-ish message will erase this small bit of earlier confusion.



On 5/29/2014 8:15 AM, Lotte Steenbrink wrote:
Hello,

Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen <ietf@thomasclausen.org>:

It would be interesting to understand why AckReq was included in the first place - given that that seems redundant with the well-known rrep_ack mechanism, and given that (it seems to me) that there are potential huge downsides to AckReq. 

Of course. I forgot to check whether my E-Mail client messed up the order of my mails again before I sent my reply, that's why my reply was a bit redundant. Sorry about that.

The reason I opted for a removal of RREP_ACKs instead of AckReqs was that, to me, the description of RREP_ACKs in the AODVv2 draft seemed like an afterthought. Being somewhat new to the topic, I'm as familiar with RREP_ACKs as I am with AckReqs, with the difference being that I'd have no idea how to implement RREP_ACKs, at least not from the AODVV2 specification:
How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume that, because Section 5.2. demands that AckReqs should be requested by adding an appropriate message TLV, the same applies to RREP_ACKs, but that kind of guesswork could lead to interoperability issues.
Why doesn't the draft remind me that (and how) a RREP "with the 'A' flag set" should be handled? Why doesn't it remind me that (and how) a RREP_ACK should be handled?

Using other sources, i'd probably be able to cobble *something* together, but I'd guess that the probability that another programmer will come up with the same interpretation is not that high.

So, what I was basically saying is just: Having two ways of ensuring bidirectionality is confusing (and maybe standing in the way of interoperability?), and one of the ways is confusing in itself, and I think that needs to be sorted out-- by ditching one of the approaches and being more specific in case RREP_ACKs are here to stay.

Cheers,
Lotte Steenbrink



-- 
Thomas Heide Clausen

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

On 29 mai 2014, at 15:05, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:

Hello Yuichi,

Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI <yuichi.igarashi.hb@hitachi.com>:

Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional links”. But, if you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links are bi-directional?

AODVv2 proposes the inclusion of an AckReq TLV to ensure bidirectional connectivity. My point was that, given the existence of this AckReq mechanism, the additional inclusion of RREP_ACK seems redundant.

Cheers,
Lotte


AODVv2 requires all routes to implement other protocol for verifying bi-directionality of links? I am sure that would cause interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft.  There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

 In Section 13.5., the AODVv2 Draft briefly describes a mechanism called
 RREP_ACK, which seems to serve a similar purpose as the AckReqs
described
 in section 5.2.
 While RFC 3561, which is referenced in section 13.5., explains that a
 RREP-ACK is sent when a packet with the 'A' bit set is received, the
 AODVv2 does not describe how a RREP_ACK is triggered.
 Additionally, the draft does not specify how a RREP_ACK should be
handled.
 If the feature of a RREP_ACK is really needed, a more thorough
explanation
 should be added. Otherwise, removing it could be a step towards de-
 cluttering the draft.


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


--
Hitachi, Ltd., Yokohama Research Laboratory
Yuichi Igarashi
Mail： yuichi.igarashi.hb@hitachi.com
Tel ： +81-(0)50-3135-3457

_______________________________________________
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

--------------090205020903040105050300-- From nobody Sun Jul 20 23:15:13 2014 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 568911B2B6E; Sun, 20 Jul 2014 23:15:07 -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 1R_-mTubrE_v; Sun, 20 Jul 2014 23:15:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 914A71B2D52; Sun, 20 Jul 2014 23:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721061503.26718.32300.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 23:15:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/I1Z0jxCiE0tPe0UkGZ4Z2ap-i2k Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-04.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: Mon, 21 Jul 2014 06:15:07 -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 MANET On-demand (AODVv2) Routing Authors : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-aodvv2-04.txt Pages : 65 Date : 2014-07-20 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-aodvv2-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 20 23:22:50 2014 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 EEFD11B2CAD for ; Sun, 20 Jul 2014 23:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ywXbrkpZnipH for ; Sun, 20 Jul 2014 23:22:46 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB661B2C99 for ; Sun, 20 Jul 2014 23:22:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BiExxDrF8FblAtWFCO5rmfFs/n/jdbkDCtevD/PT2Elf+UCNBj3O9pVdsGv678xq; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.149.207] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X96zl-0005Xs-QQ for manet@ietf.org; Mon, 21 Jul 2014 02:22:45 -0400 Message-ID: <53CCB1B4.3060201@earthlink.net> Date: Sun, 20 Jul 2014 23:22:44 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7d79ca6e947946a63efca2da4e402090d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zzn05Nd65P6oIaCajL3zL8sof_A Subject: [manet] Submission of AODVv2 draft revision 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, 21 Jul 2014 06:22:48 -0000 Hello folks, draft-ietf-manet-aodvv2-04.txt has been have submitted for consideration. The draft does not include proposed revisions for all of the outstanding issues, and I fully expect that another revision will be needed soon, especially after some reasonable text is crafted to resolve the issues surrounding the security and threat models affecting AODVv2. Nevertheless, the inclusion of the new appendix exhibiting some first-draft versions of algorithms for processing AODVv2 messages seemed to merit publication of release ...-04 as soon as possible. I had intended to submit this revision before the IETF Internet Draft deadline. Unfortunately for me (and apparently quite a few others) the deadline on Friday was a big surprise; I had expected the deadline to be on the following Monday. Please excuse this unintended delay. My mistake will, I hope, suggest closer tracking of possible changes in the submission deadline for future IETF meetings. I hope the submission will be considered useful for the discussion this week, in conjunction with recent emails and creation of new issues to summarize some other recent discussion. Regards, Charlie P. From nobody Mon Jul 21 07:39:47 2014 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 41AE41A00F1 for ; Mon, 21 Jul 2014 07:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 GhhKgrxNSLQo for ; Mon, 21 Jul 2014 07:39:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBEC1A0071 for ; Mon, 21 Jul 2014 07:39:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6LEdaiO030253; Mon, 21 Jul 2014 15:39:36 +0100 Received: from 950129200 (dhcp-b3fb.meeting.ietf.org [31.133.179.251]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6LEdYxm030218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 15:39:36 +0100 From: "Adrian Farrel" To: "'Charlie Perkins'" , "'Mobile Ad Hoc Networks mailing list'" References: <53CCB1B4.3060201@earthlink.net> In-Reply-To: <53CCB1B4.3060201@earthlink.net> Date: Mon, 21 Jul 2014 15:39:39 +0100 Message-ID: <076e01cfa4f1$9ae05360$d0a0fa20$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJm+HRF/dgYuLYtUHZk4vej/MKxdJp78elg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20832.000 X-TM-AS-Result: No--15.505-10.0-31-10 X-imss-scan-details: No--15.505-10.0-31-10 X-TMASE-MatchedRID: irl7E//xM96WW08gTNFdoFC9UDhZx5wgnQmRYcv5/Fkk78SxLKShoG2/ ar5TFzuCoiJSjMEHzGvC5qeIz1BfLQFjHc0ldSMGiUStp5x0Elzyha4uErRN/bu9iqQJLR0vh8Y tn75ClDNElaZ44wdr5N07UhXJ7cnLu5h9co4nGENLXb/m/Ps15i2VyoCAxE//fa90YmMUpz1K0Y CCYqpa5d+E7XxD87Uid91HBZ7FfSs0cCaQNKI57Zkjw6+I2QxRt4e1xCL/f2Y9Qy3P8gYn2CYEX G79Tsiv31GU/N5W5BA4lm+QIOVnmEP43Cz5TrG2s/V1Y6QtQtR2u8UyCKVtajnU1V+NaXs9j/xL IaDSshGKXhy9oEl66lPWus3yxQNWt+odoSua73aRk6XtYogiarQ/aqQZTRfKVnRXm1iHN1bEQdG 7H66TyH4gKq42LRYkA1mEC032ErOU6dhRhecDsXlSs7zwIjLEv10YfmhkALR+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Oyw5w2HL9cvgwun-hrtXaPPByzA Subject: Re: [manet] Submission of AODVv2 draft revision 04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: afarrel@juniper.net List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:39:44 -0000 Charlie, Can you just confirm that the version you just posted is identical (i.e. 100% the same) to the version you previously posted at http://www.psg.com/~charliep/ietf90/draft-ietf-manet-aodvv2-pre04.txt A > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charlie Perkins > Sent: 21 July 2014 07:23 > To: Mobile Ad Hoc Networks mailing list > Subject: [manet] Submission of AODVv2 draft revision 04 > > Hello folks, > > draft-ietf-manet-aodvv2-04.txt has been have submitted > for consideration. > > The draft does not include proposed revisions for all of the > outstanding issues, and I fully expect that another revision will > be needed soon, especially after some reasonable text is crafted > to resolve the issues surrounding the security and threat models > affecting AODVv2. Nevertheless, the inclusion of the new > appendix exhibiting some first-draft versions of algorithms for > processing AODVv2 messages seemed to merit publication of > release ...-04 as soon as possible. > > I had intended to submit this revision before the IETF > Internet Draft deadline. Unfortunately for me (and apparently > quite a few others) the deadline on Friday was a big surprise; > I had expected the deadline to be on the following Monday. > Please excuse this unintended delay. My mistake will, I hope, > suggest closer tracking of possible changes in the submission > deadline for future IETF meetings. > > I hope the submission will be considered useful for the > discussion this week, in conjunction with recent emails and > creation of new issues to summarize some other recent > discussion. > > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Jul 21 08:51:34 2014 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 87E971A006D; Mon, 21 Jul 2014 08:51:29 -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 ACTWuyUx36Bi; Mon, 21 Jul 2014 08:51:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7891A02A5; Mon, 21 Jul 2014 08:51:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721155119.24924.72026.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 08:51:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/XRRXLz4tjXtXCBNOfNWb1DLcBsU Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-04.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: Mon, 21 Jul 2014 15:51:29 -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 : Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-olsrv2-multitopology-04.txt Pages : 20 Date : 2014-07-21 Abstract: This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multitopology-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 08:56:25 2014 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 7F8961A0270 for ; Mon, 21 Jul 2014 08:56:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dmDXQO1sAxWI for ; Mon, 21 Jul 2014 08:56:20 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB59D1A008D for ; Mon, 21 Jul 2014 08:56:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 8551DD5549F for ; Mon, 21 Jul 2014 08:56:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 3D2B8D5549E for ; Mon, 21 Jul 2014 08:56:20 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <8054CD07-36C9-4B5E-AF4F-A8DACDF27855@thomasclausen.org> Date: Mon, 21 Jul 2014 11:56:20 -0400 References: <20140721155119.24924.72026.idtracker@ietfa.amsl.com> In-Reply-To: <20140721155119.24924.72026.idtracker@ietfa.amsl.com> To: manet IETF X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wh8219pWhjWXmzr5valEsXAeJTs Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multitopology-04.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: Mon, 21 Jul 2014 15:56:23 -0000 All, This document is identical to the -03, except that there was an issue with a= reference (a hard-coded [OLSRv2] in the source XML) which idnit revealed.=20= In order to be able to proudly claim "idnits raises no issues", we spun this= -04. Once the tools pages catch up, rfcdiff should indicate that other than [OLSR= v2] to [RFC7181] in a single place, only the date and the version# has chang= ed. In other words, if you read -03, no reason to rush to read -04. For the authors, Thomas Sent from my iPad > On 21 Jul 2014, at 11:51, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. >=20 > Title : Multi-Topology Extension for the Optimized Link S= tate Routing Protocol version 2 (OLSRv2) > Authors : Christopher Dearlove > Thomas Heide Clausen > Filename : draft-ietf-manet-olsrv2-multitopology-04.txt > Pages : 20 > Date : 2014-07-21 >=20 > Abstract: > This specification describes an extension to the Optimized Link State > Routing Protocol version 2 (OLSRv2) to support multiple routing > topologies, while retaining interoperability with OLSRv2 routers that > do not implement this extension. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multitopology-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multitopology-0= 4 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Jul 21 10:07:16 2014 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 17F361A000D; Mon, 21 Jul 2014 10:07:12 -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 goehTmTaycEf; Mon, 21 Jul 2014 10:07:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F4C1A003B; Mon, 21 Jul 2014 10:07:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721170704.29670.74135.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 10:07:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BSthPE-n8JEFjkBNEZD297fcM4w Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-optimization-00.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: Mon, 21 Jul 2014 17:07:12 -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 : An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-optimization-00.txt Pages : 12 Date : 2014-07-21 Abstract: The link quality mechanism of the MANET Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold, while still retaining the corresponding link information as acquired from HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently. NHDP also collects information about symmetric 2-hop neighbors. However it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" as described above, then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment. This specification updates NHDP, and the Optimized Link State Routing Protocol version 2 (OLSRv2) to permit retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 10:10:23 2014 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 76D791A01AA for ; Mon, 21 Jul 2014 10:10:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VXvlDHl3AOLj for ; Mon, 21 Jul 2014 10:10:19 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BC91A003B for ; Mon, 21 Jul 2014 10:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 1B443D55528 for ; Mon, 21 Jul 2014 10:10:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 607DBD554B3 for ; Mon, 21 Jul 2014 10:10:15 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <75E3C106-5732-439D-886E-598E065A99D6@thomasclausen.org> Date: Mon, 21 Jul 2014 13:10:12 -0400 References: <20140721170704.29670.74135.idtracker@ietfa.amsl.com> In-Reply-To: <20140721170704.29670.74135.idtracker@ietfa.amsl.com> To: manet IETF X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/DlWWrtnZ54JbkJg49nCFtsmU0OA Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-optimization-00.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: Mon, 21 Jul 2014 17:10:21 -0000 All, Given that draft-dearlove-manet-nhdp-optimization-01 was adopted as WG docum= ent, and with the submission embargo over, we hereby post the very same text= as draft-ietf-manet-nhdp-optimization-00 If you've already read draft-dearlove-manet-nhdp-optimization-01, then don't= panic -- other than the file-name change, this is *exactly* the same text. Best, Thomas Sent from my iPad > On 21 Jul 2014, at 13:07, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. >=20 > Title : An Optimization for the MANET Neighborhood Discov= ery Protocol (NHDP) > Authors : Christopher Dearlove > Thomas Heide Clausen > Filename : draft-ietf-manet-nhdp-optimization-00.txt > Pages : 12 > Date : 2014-07-21 >=20 > Abstract: > The link quality mechanism of the MANET Neighborhood Discovery > Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the > measured link quality from that 1-hop neighbor is below an acceptable > threshold, while still retaining the corresponding link information > as acquired from HELLO message exchange. This allows immediate > reinstatement of the 1-hop neighbor if the link quality later > improves sufficiently. >=20 > NHDP also collects information about symmetric 2-hop neighbors. > However it specifies that if a link from a symmetric 1-hop neighbor > ceases being symmetric, including while "ignored" as described above, > then corresponding symmetric 2-hop neighbors are removed. This may > lead to symmetric 2-hop neighborhood information being permanently > removed (until further HELLO messages are received) if the link > quality of a symmetric 1-hop neighbor drops below the acceptable > threshold, even if only for a moment. >=20 > This specification updates NHDP, and the Optimized Link State Routing > Protocol version 2 (OLSRv2) to permit retaining, but ignoring, > symmetric 2-hop information when the link quality from the > corresponding 1-hop neighbor drops below the acceptable threshold. > This allows immediate reinstatement of the symmetric 2-hop neighbor > if the link quality later improves sufficiently, thus making the > symmetric 2-hop neighborhood more "robust". >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Jul 21 10:34:05 2014 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 AD2661A0176 for ; Mon, 21 Jul 2014 10:34:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 GhVoEvQ1KUq5 for ; Mon, 21 Jul 2014 10:34:00 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F45C1A0250 for ; Mon, 21 Jul 2014 10:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 69300D554B8; Mon, 21 Jul 2014 10:33:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id E7C51D4068A; Mon, 21 Jul 2014 10:33:58 -0700 (PDT) From: Thomas Heide Clausen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2014 19:33:56 +0200 Message-Id: To: manet Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1962.2\)) X-Mailer: Apple Mail (2.1962.2) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Cin_itLgfYmEIaHzJxoMjgYJPHc Cc: manet-chairs@tools.ietf.org, manet-ads Subject: [manet] Status of SMF MIB? 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, 21 Jul 2014 17:34:01 -0000 Hello all, The SMF MIB seems to be stalled. If I interpret the tracker correctly, = the document has been in =E2=80=9CRevised I-D Needed=E2=80=9D state for = 116 days or so.=20 Could the document shepherd let the WG know what the status and hold-up = of this document is, please? Thomas= From nobody Mon Jul 21 11:08:29 2014 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 839651A001D for ; Mon, 21 Jul 2014 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 is9eIjA8dJ9z for ; Mon, 21 Jul 2014 11:08:25 -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 A042B1A002D for ; Mon, 21 Jul 2014 11:08:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GWaMCtZNGNluzihT3jw5rXx9dtt2+8AYqm2P6Wy0B8gGF4aUGot6cdXT2jN8Px+4; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.162.75] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X9I0e-0001EZ-PB; Mon, 21 Jul 2014 14:08:24 -0400 Message-ID: <53CD5716.6030802@earthlink.net> Date: Mon, 21 Jul 2014 11:08:22 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: afarrel@juniper.net References: <53CCB1B4.3060201@earthlink.net> <076e01cfa4f1$9ae05360$d0a0fa20$@juniper.net> In-Reply-To: <076e01cfa4f1$9ae05360$d0a0fa20$@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7f3789531c0d88cc44f20c375be849e40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.162.75 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-6dWzGYaan125CTkMudguDZEJsA Cc: 'Mobile Ad Hoc Networks mailing list' Subject: Re: [manet] Submission of AODVv2 draft revision 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, 21 Jul 2014 18:08:27 -0000 Hello Adrian and all, On 7/21/2014 7:39 AM, Adrian Farrel wrote: > Charlie, > > Can you just confirm that the version you just posted is identical (i.e. 100% > the same) to the version you previously posted at > http://www.psg.com/~charliep/ietf90/draft-ietf-manet-aodvv2-pre04.txt No, I made the following revisions: - fixed remaining instances of "retransmit" to instead use "regenerate" - included information in the algorithms about when to insert AckReq TLV. I submitted the document this morning quite early; when performing rfcdiff just now I noticed a cut-and-paste error in section 13.5 that should have been deleted. It looks pretty much out of place, and so it should be easy to ignore. If bothersome, I can resubmit the document to delete that now, or I can just wait until after the [manet] meeting tomorrow. I expect that the discussion tomorrow will suggest other editorial revisions. Regards, Charlie P. >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charlie Perkins >> Sent: 21 July 2014 07:23 >> To: Mobile Ad Hoc Networks mailing list >> Subject: [manet] Submission of AODVv2 draft revision 04 >> >> Hello folks, >> >> draft-ietf-manet-aodvv2-04.txt has been have submitted >> for consideration. >> >> The draft does not include proposed revisions for all of the >> outstanding issues, and I fully expect that another revision will >> be needed soon, especially after some reasonable text is crafted >> to resolve the issues surrounding the security and threat models >> affecting AODVv2. Nevertheless, the inclusion of the new >> appendix exhibiting some first-draft versions of algorithms for >> processing AODVv2 messages seemed to merit publication of >> release ...-04 as soon as possible. >> >> I had intended to submit this revision before the IETF >> Internet Draft deadline. Unfortunately for me (and apparently >> quite a few others) the deadline on Friday was a big surprise; >> I had expected the deadline to be on the following Monday. >> Please excuse this unintended delay. My mistake will, I hope, >> suggest closer tracking of possible changes in the submission >> deadline for future IETF meetings. >> >> I hope the submission will be considered useful for the >> discussion this week, in conjunction with recent emails and >> creation of new issues to summarize some other recent >> discussion. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From nobody Mon Jul 21 13:14:21 2014 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 F32181A01BA for ; Mon, 21 Jul 2014 13:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rfq-Zf8p9is7 for ; Mon, 21 Jul 2014 13:14:12 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040141A008D for ; Mon, 21 Jul 2014 13:14:12 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1X9JyM-000wdg-4f>; Mon, 21 Jul 2014 22:14:10 +0200 Received: from f050200101.adsl.alicedsl.de ([78.50.200.101] helo=[192.168.1.37]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1X9JyM-003dmO-1e>; Mon, 21 Jul 2014 22:14:10 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: <53CC9234.4010502@earthlink.net> Date: Mon, 21 Jul 2014 22:14:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069.dc1798c89def0b64c3317643b3bd6ef2@trac.tools.ietf.org> <53CC9234.4010502@earthlink.net> To: Charlie Perkins , manet@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 78.50.200.101 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SkV9nRkOkTuZ0ZlRB_hs5zW7na0 Subject: Re: [manet] #42 (aodvv2): What happens if Active routes exceed RERR packet size? 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, 21 Jul 2014 20:14:16 -0000 Hello Charlie, On 21 Jul 2014, at 06:08, Charlie Perkins = wrote: >=20 > Hello Lotte, >=20 > I can indeed imagine it happening, but I am not sure what the > proper resolution should be. While it is true that many routes > *might* be active in a large network, I suspect that the problem > would only arise in a few nodes that are situated as the main > point of connectivity between two subgraphs. >=20 > Anyway, the problem needs a solution. It seems that the active > routes SHOULD be reported as broken, and that the order of > reporting SHOULD be in order of time of use. I don't think the > ordering should be mandated, because some implementations > might not want to do the extra code, and it wouldn't affect > interoperability. Performance might be adversely affected in > the rare cases where there are many active routes in service. >=20 > A node would report the overflow active routes by creating > another RERR message and putting in as many active routes > as possible. >=20 That sounds reasonable to me. > If this is acceptable, I think it will be quite straightforward > to revise the draft accordingly. Maybe the text should go into > a new subsection. I'm not entirely sure that's necessary. I'd imagine something along the = lines of this: For each such Active Route, Route.Dest is added to the set of=20 Unreachable Nodes. If the size of the set of Unreachable Nodes=20 exceeds the packet size of the RERR, additional RERR packets=20 are created until all Active broken routes have been reported.=20 The order of reporting SHOULD be in order of time of use.=20 After the Active Routes using the broken link have all been included=20 as UnreachableNodes, Idle routes MAY also be included, ... etc etc Cheers, Lotte >=20 > Comments? >=20 > Regards, > Charlie P. >=20 >=20 > On 7/16/2014 10:11 AM, manet issue tracker wrote: >> #42: What happens if Active routes exceed RERR packet size? >>=20 >> Section 8.3.2. states that >>=20 >>=20 >> {{{ >> After the Active Routes using >> the broken link have all been included as UnreachableNodes, = Idle >> routes MAY also be included, if allowed by the setting of >> ENABLE_IDLE_UNREACHABLE, as long as the packet size of the = RERR >> does >> not exceed the MTU (interface "Maximum Transfer Unit") of = the >> physical medium. >> }}} >>=20 >>=20 >> However, it is not specified what happens if the listing of all = ''Active'' >> routes already exceeds the packet size. In a large-scale network = using >> IEEE 802.15.4., this is not unlikely to happen, and I think it = should be >> defined how to handle this situation. >>=20 From nobody Mon Jul 21 13:42:55 2014 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 71FB41A0426 for ; Mon, 21 Jul 2014 13:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 NnNP7DTUuSdT for ; Mon, 21 Jul 2014 13:42:50 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591271A00CA for ; Mon, 21 Jul 2014 13:42:49 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1X9KQ3-00132W-SD>; Mon, 21 Jul 2014 22:42:47 +0200 Received: from f050200101.adsl.alicedsl.de ([78.50.200.101] helo=[192.168.1.37]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1X9KQ3-003g0s-Mn>; Mon, 21 Jul 2014 22:42:47 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_64112CF9-3E64-4026-B697-D56D47FA57D7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: <53CCA8B1.5050705@earthlink.net> Date: Mon, 21 Jul 2014 22:42:45 +0200 Message-Id: <7A5BC27E-B1F4-46E9-87F7-B7124D3E7462@fu-berlin.de> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <05CD0538-85C5-4986-A49A-D74965634262@thomasclausen.org> <768F7407-94BE-41F1-ABA6-0FC0131F8B5D@fu-berlin.de> <53CCA8B1.5050705@earthlink.net> To: Charlie Perkins , manet@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 78.50.200.101 X-ZEDAT-Hint: A Archived-At: http://mailarchive.ietf.org/arch/msg/manet/47mErpAqDQhRFq4lPZmmeiLLuFo Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK 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, 21 Jul 2014 20:42:52 -0000 --Apple-Mail=_64112CF9-3E64-4026-B697-D56D47FA57D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Charlie, On 21 Jul 2014, at 07:44, Charlie Perkins = wrote: >=20 > Hello Lotte and all, >=20 > To review and summarize: >=20 > The AckReq TLV is to be included with the RREP, in cases where the > the node sending the RREP must ascertain that the intended receiver > of the RREP will actually receive it. >=20 > When a node receives an RREP that includes the AckReq TLV, then that > node must send back a response. The discussion has been about > whether or not to mandate that the RREP_Ack is to be sent as that > response. >=20 > AckReq and RREP_Ack not technically required. The nodes can verify > bidirectionality in other ways. Some layer 2 protocols provide > bidirectionality. Even for cases where a layer-3 solution is desired, > additional AODVv2 protocol is not required. Ping is a time-tested > and well understood mechanism for verifying connectivity. As far as I can recall, the argument was that this stands in the way of = interoperability, which is why having a lowest common denominator makes = sense. Also, it takes the burden of picking the right mechanism away = from those who don't know exactly what they're doing (or leaves them a = bit more time to think about it). As somebody who had to learn the hard = way that using RFC 6775 is maybe not the best idea, I'd support the = cause for *one* mandatory minimal solution. Cheers, Lotte >=20 > Henning has suggested including and perhaps even mandating > RREP_Ack to be used in preference to existing protocol mechanisms. >=20 > For me, this is a minor issue. It has been stated many times that > AODVv2 should be a "lean" protocol, and that sentiment had led me > to favor exclusion of RREP_Ack from the protocol. I was later > persuaded to include it as an optional feature. I can be persuaded > either way -- leaner versus more self-contained. I do not really = care. > I feel that the "self-contained" argument is weak, because no > protocol running on top of IP is self contained (by definition). > But whether or not the argument is weak, if AODVv2 is considered > to need this feature, I am happy to retain the specification for it, > as well as supporting text for when it should be used. >=20 > Another alternative would be to *mandate* the use of ping for > this purpose. To me it seems unwise to mandate ping when the > link is known to be bidirectional (by way of any other mechanism, > layer 2 or layer 3). This is perhaps especially true because, when > any mechanism (including Ping) would be mandated, is exactly > the time when congestion on the wireless link should be avoided, > and mandating unnecessary control traffic is often considered to > be improper protocol design. >=20 > But, to reiterate, the mandate can be included without serious > problem other than additional code and some small percentage > of increased congestion. >=20 > In some previous messages, there was confusion between the > AckReq TLV and the RREP_Ack response to that TLV. I hope this > long-ish message will erase this small bit of earlier confusion. >=20 >=20 >=20 > On 5/29/2014 8:15 AM, Lotte Steenbrink wrote: >> Hello, >>=20 >> Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen = : >>=20 >>> It would be interesting to understand why AckReq was included in the = first place - given that that seems redundant with the well-known = rrep_ack mechanism, and given that (it seems to me) that there are = potential huge downsides to AckReq.=20 >>=20 >> Of course. I forgot to check whether my E-Mail client messed up the = order of my mails again before I sent my reply, that's why my reply was = a bit redundant. Sorry about that. >>=20 >> The reason I opted for a removal of RREP_ACKs instead of AckReqs was = that, to me, the description of RREP_ACKs in the AODVv2 draft seemed = like an afterthought. Being somewhat new to the topic, I'm as familiar = with RREP_ACKs as I am with AckReqs, with the difference being that I'd = have no idea how to implement RREP_ACKs, at least not from the AODVV2 = specification: >> How do I set the 'A' flag in RFC5444 RREPs correctly? One could = assume that, because Section 5.2. demands that AckReqs should be = requested by adding an appropriate message TLV, the same applies to = RREP_ACKs, but that kind of guesswork could lead to interoperability = issues. >> Why doesn't the draft remind me that (and how) a RREP "with the 'A' = flag set" should be handled? Why doesn't it remind me that (and how) a = RREP_ACK should be handled? >>=20 >> Using other sources, i'd probably be able to cobble *something* = together, but I'd guess that the probability that another programmer = will come up with the same interpretation is not that high. >>=20 >> So, what I was basically saying is just: Having two ways of ensuring = bidirectionality is confusing (and maybe standing in the way of = interoperability?), and one of the ways is confusing in itself, and I = think that needs to be sorted out-- by ditching one of the approaches = and being more specific in case RREP_ACKs are here to stay. >>=20 >> Cheers, >> Lotte Steenbrink >>=20 >>=20 >>>=20 >>> --=20 >>> Thomas Heide Clausen >>> http://www.thomasclausen.org >>>=20 >>> "Today's scientists have substituted mathematics for=20 >>> experiments, and they wander off through equation=20 >>> after equation, and eventually build a structure=20 >>> which has no relation to reality." >>> - Nikola Tesla,=20 >>> Modern Mechanics and Inventions, July, 1934 >>>=20 >>> On 29 mai 2014, at 15:05, Lotte Steenbrink = wrote: >>>=20 >>>> Hello Yuichi, >>>>=20 >>>> Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI = : >>>>=20 >>>>> Hi Charlie, >>>>>=20 >>>>> It says in sec.4 that "AODVv2 only supports bidirectional = links=E2=80=9D. But, if you remove RREP_ACK from the spec, how does = AODVv2 itself ensure all links are bi-directional? >>>>=20 >>>> AODVv2 proposes the inclusion of an AckReq TLV to ensure = bidirectional connectivity. My point was that, given the existence of = this AckReq mechanism, the additional inclusion of RREP_ACK seems = redundant. >>>>=20 >>>> Cheers, >>>> Lotte >>>>=20 >>>> [1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2 >>>>=20 >>>>> AODVv2 requires all routes to implement other protocol for = verifying bi-directionality of links? I am sure that would cause = interoperability problems. >>>>> Also, this is related to tickets #26 and #27, I think. >>>>>=20 >>>>> Regards, >>>>> Yuichi >>>>> (2014/05/29 2:34), Charlie Perkins wrote: >>>>>>=20 >>>>>> Hello Lotte, >>>>>>=20 >>>>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>>>> some discussion a while back about compatibility, but I have not >>>>>> seen anyone defending the RREP_ACK in this discussion and it was >>>>>> not present in the previous DYMO drafts. >>>>>>=20 >>>>>> If anyone would prefer to keep RREP_ACK, then I will try to = fashion >>>>>> some more detailed specification for handling it, which will be >>>>>> basically the way it was handled by AODV. >>>>>>=20 >>>>>> Regards, >>>>>> Charlie P. >>>>>>=20 >>>>>>=20 >>>>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>>>> #41: AckReq vs RREP_ACK >>>>>>>=20 >>>>>>> In Section 13.5., the AODVv2 Draft briefly describes a = mechanism called >>>>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>>>> described >>>>>>> in section 5.2. >>>>>>> While RFC 3561, which is referenced in section 13.5., explains = that a >>>>>>> RREP-ACK is sent when a packet with the 'A' bit set is = received, the >>>>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>>>> Additionally, the draft does not specify how a RREP_ACK should = be >>>>>>> handled. >>>>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>>>> explanation >>>>>>> should be added. Otherwise, removing it could be a step towards = de- >>>>>>> cluttering the draft. >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Hitachi, Ltd., Yokohama Research Laboratory >>>>> Yuichi Igarashi >>>>> Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com >>>>> Tel =EF=BC=9A +81-(0)50-3135-3457 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_64112CF9-3E64-4026-B697-D56D47FA57D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Charlie,

On 21 Jul 2014, at 07:44, Charlie Perkins = <charles.perkins@earthlink.ne= t> wrote:

=20 =20

Hello Lotte and all,

To review and summarize:

The AckReq TLV is to be included with the RREP, in cases where = the
the node sending the RREP must ascertain that the intended = receiver
of the RREP will actually receive it.

When a node receives an RREP that includes the AckReq TLV, then = that
node must send back a response.  The discussion has been = about
whether or not to mandate that the RREP_Ack is to be sent as = that
response.

AckReq and RREP_Ack not technically required.  The nodes can = verify
bidirectionality in other ways.  Some layer 2 protocols = provide
bidirectionality.  Even for cases where a layer-3 solution is desired,
additional AODVv2 protocol is not required.  Ping is a = time-tested
and well understood mechanism for verifying = connectivity.

As far as I can = recall, the argument was that this stands in the way of = interoperability, which is why having a lowest common denominator makes = sense. Also, it takes the burden of picking the right mechanism away = from those who don't know exactly what they're doing (or leaves them a = bit more time to think about it). As somebody who had to learn the hard = way that using RFC 6775 is maybe not the best idea, I'd support the = cause for *one* mandatory minimal = solution.

Cheers,
Lotte


Henning has suggested including and perhaps even mandating
RREP_Ack to be used in preference to existing protocol = mechanisms.

For me, this is a minor issue.  It has been stated many times = that
AODVv2 should be a "lean" protocol, and that sentiment had led = me
to favor exclusion of RREP_Ack from the protocol.   I was = later
persuaded to include it as an optional feature.  I can be = persuaded
either way -- leaner versus more self-contained.  I do not = really care.
I feel that the "self-contained" argument is weak, because no
protocol running on top of IP is self contained (by definition).
But whether or not the argument is weak, if AODVv2 is considered
to need this feature, I am happy to retain the specification for = it,
as well as supporting text for when it should be used.

Another alternative would be to *mandate* the use of ping for
this purpose.  To me it seems unwise to mandate ping when = the
link is known to be bidirectional (by way of any other = mechanism,
layer 2 or layer 3).  This is perhaps especially true because, = when
any mechanism (including Ping) would be mandated, is exactly
the time when congestion on the wireless link should be avoided,
and mandating unnecessary control traffic is often considered to
be improper protocol design.

But, to reiterate, the mandate can be included without serious
problem other than additional code and some small percentage
of increased congestion.

In some previous messages, there was confusion between the
AckReq TLV and the RREP_Ack response to that TLV.  I hope = this
long-ish message will erase this small bit of earlier confusion.



On 5/29/2014 8:15 AM, Lotte = Steenbrink wrote:
Hello,

Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen <ietf@thomasclausen.org>:
It would be interesting to understand why AckReq was included in the first place - given that that seems redundant with the well-known rrep_ack mechanism, and given that (it seems to me) that there are potential huge downsides to AckReq. 

Of course. I forgot to check whether my E-Mail client messed up the order of my mails again before I sent my reply, that's why my reply was a bit redundant. Sorry about = that.

The reason I opted for a removal of RREP_ACKs instead of AckReqs was that, to me, the description of RREP_ACKs in the AODVv2 draft seemed like an afterthought. Being somewhat new to the topic, I'm as familiar with RREP_ACKs as I am with AckReqs, with the difference being that I'd have no idea how to implement RREP_ACKs, at least not from the AODVV2 specification:
How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume that, because Section 5.2. demands that AckReqs should be requested by adding an appropriate message TLV, the same applies to RREP_ACKs, but that kind of guesswork could lead to interoperability issues.
Why doesn't the draft remind me that (and how) a RREP "with the 'A' flag set" should be handled? Why doesn't it remind me that (and how) a RREP_ACK should be handled?

Using other sources, i'd probably be able to cobble *something* together, but I'd guess that the probability that another programmer will come up with the same interpretation is not that high.

So, what I was basically saying is just: Having two ways of ensuring bidirectionality is confusing (and maybe standing in the way of interoperability?), and one of the ways is confusing in itself, and I think that needs to be sorted out-- by ditching one of the approaches and being more specific in case RREP_ACKs are here to stay.

Cheers,
Lotte Steenbrink



-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off = through equation 
  after equation, and eventually =  build a structure 
  which has no relation to = reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, = July, 1934

On 29 mai 2014, at 15:05, Lotte Steenbrink <lotte.steenbrink@fu-berlin.d= e> wrote:

Hello Yuichi,

Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI <yuichi.igarashi.hb@hitachi.= com>:

Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D. But, if you remove = RREP_ACK from the spec, how does AODVv2 itself ensure all links are bi-directional?

AODVv2 proposes the inclusion of an AckReq TLV to ensure bidirectional connectivity. My point was that, given the existence of this AckReq mechanism, the additional inclusion of RREP_ACK seems redundant.

Cheers,
Lotte


AODVv2 requires all routes to implement other protocol for verifying bi-directionality of links? I am sure that would cause interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft.  There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs = RREP_ACK

 In Section 13.5., the AODVv2 Draft = briefly describes a mechanism called
 RREP_ACK, which seems to serve a similar purpose as the AckReqs
described
 in section 5.2.
 While RFC 3561, which is referenced in section 13.5., explains that a
 RREP-ACK is sent when a packet with the = 'A' bit set is received, the
 AODVv2 does not describe how a RREP_ACK = is triggered.
 Additionally, the draft does not specify = how a RREP_ACK should be
handled.
 If the feature of a RREP_ACK is really needed, a more thorough
explanation
 should be added. Otherwise, removing it = could be a step towards de-
 cluttering the draft.


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


--
Hitachi, Ltd., Yokohama Research Laboratory
Yuichi Igarashi
Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.= com
Tel =EF=BC=9A +81-(0)50-3135-3457

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



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


= --Apple-Mail=_64112CF9-3E64-4026-B697-D56D47FA57D7-- From nobody Mon Jul 21 13:44:15 2014 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 9CDF41A0453 for ; Mon, 21 Jul 2014 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 moRt81YcHDmZ for ; Mon, 21 Jul 2014 13:44:04 -0700 (PDT) Received: from ucol19pa09.eemsg.mail.mil (ucol19pa09.eemsg.mail.mil [214.24.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id C96171A0450 for ; Mon, 21 Jul 2014 13:44:03 -0700 (PDT) Received: from edge-cols02.mail.mil ([131.64.104.100]) by ucol19pa09.eemsg.mail.mil with ESMTP; 21 Jul 2014 20:44:03 +0000 Received: from UCOLHPMG.easf.csd.disa.mil (131.64.104.35) by edge-cols02.mail.mil (131.64.104.100) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 21 Jul 2014 20:42:39 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.86]) by ucolhpmg.easf.csd.disa.mil ([131.64.104.35]) with mapi id 14.03.0174.001; Mon, 21 Jul 2014 20:42:39 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Thomas Heide Clausen , manet Thread-Topic: [manet] Status of SMF MIB? (UNCLASSIFIED) Thread-Index: AQHPpSRPNHweD1ttbkq0KVM2wdC8WQ== Date: Mon, 21 Jul 2014 20:42:39 +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: [131.64.22.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rZKuaXIftET03smjMJORAOAtHfk Cc: "manet-chairs@tools.ietf.org" , manet-ads Subject: Re: [manet] Status of SMF MIB? (UNCLASSIFIED) 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, 21 Jul 2014 20:44:07 -0000 Q2xhc3NpZmljYXRpb246IFVOQ0xBU1NJRklFRA0KQ2F2ZWF0czogTk9ORQ0KDQpUaG9tYXMsDQoN CllvdSBhcmUgY29ycmVjdCwgaXQgaGFzIHN0YWxsZWQuICBJJ2xsIGNvcnJlY3QgdGhpcy4NCg0K VG8gbXkga25vd2xlZGdlIGFsbCBvZiB0aGUgaXNzdWVzIHJhaXNlZCBieSB0aGUgdmFyaW91cyBy ZXZpZXdlcnMgd2VyZSBhZGRyZXNzZWQgdG8gdGhlaXIgc2F0aXNmYWN0aW9uIGluIG91ciBlbWFp bCBleGNoYW5nZXMgYmFjayBpbiBBcHJpbC4gIEhvd2V2ZXIsIEkgbmVlZCB0byBpbmNvcnBvcmF0 ZSB0aGUgcmV2aXNpb25zIGludG8gYSBmaW5hbCBkcmFmdCBhbmQgcmUtaXNzdWUgKGFsb25nIHdp dGggbm90ZXMgb2YgZXhwbGFuYXRpb24gdG8gZWFjaCBvZiB0aGUgcmV2aWV3ZXIpLiAgDQoNCkkg d2lsbCB3b3JrIHVwIHRoZSByZXZpc2lvbiB0aGlzIHdlZWsgYW5kIHBvc3QgdGhlIG5ldyB2ZXJz aW9uIHByaW9yIHRvIHRoZSBiZWdpbm5pbmcgb2YgbmV4dCB3ZWVrLiAgSG9wZWZ1bGx5IHRoZW4s IEkgY2FuIG1vdmUgdGhpcyBkcmFmdCBmb3J3YXJkIHRvIGl0cyBjb25jbHVzaW9uLg0KDQpUaGFu a3MgZm9yIHlvdXIgKHRoZSB3b3JraW5nIGdyb3VwJ3MsIGNoYWlycycgYW5kIEFkcycpIHBhdGll bmNlIHJlZ2FyZGluZyB0aGlzIG1hdHRlci4NCg0KQm9iDQoNClVTIEFybXkgQ0VSREVDDQpRVUVT VCBQcm9ncmFtLCBTJlRDRA0KQVBHLCBNRA0KDQooYykgNDQzLjkxMC40NDIwDQoobykgNDQzLjM5 NS44NzQ0DQpyb2JlcnQuZy5jb2xlQHVzLmFybXkubWlsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBUaG9tYXMgSGVpZGUNCj4gQ2xhdXNlbg0KPiBTZW50OiBNb25kYXksIEp1 bHkgMjEsIDIwMTQgMTozNCBQTQ0KPiBUbzogbWFuZXQNCj4gQ2M6IG1hbmV0LWNoYWlyc0B0b29s cy5pZXRmLm9yZzsgbWFuZXQtYWRzDQo+IFN1YmplY3Q6IFttYW5ldF0gU3RhdHVzIG9mIFNNRiBN SUI/DQo+IA0KPiBIZWxsbyBhbGwsDQo+IA0KPiBUaGUgU01GIE1JQiBzZWVtcyB0byBiZSBzdGFs bGVkLiBJZiBJIGludGVycHJldCB0aGUgdHJhY2tlciBjb3JyZWN0bHksIHRoZQ0KPiBkb2N1bWVu dCBoYXMgYmVlbiBpbiDigJxSZXZpc2VkIEktRCBOZWVkZWTigJ0gc3RhdGUgZm9yIDExNiBkYXlz IG9yIHNvLg0KPiANCj4gQ291bGQgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGxldCB0aGUgV0cga25v dyB3aGF0IHRoZSBzdGF0dXMgYW5kIGhvbGQtdXAgb2YNCj4gdGhpcyBkb2N1bWVudCBpcywgcGxl YXNlPw0KPiANCj4gVGhvbWFzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCkNsYXNzaWZpY2F0 aW9uOiBVTkNMQVNTSUZJRUQNCkNhdmVhdHM6IE5PTkUNCg0KDQo= From nobody Mon Jul 21 14:29:39 2014 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 0DCAC1A0653 for ; Mon, 21 Jul 2014 14:29:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 loavB0hB7tcc for ; Mon, 21 Jul 2014 14:29:36 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11851A0647 for ; Mon, 21 Jul 2014 14:29:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 6FA63121C50; Mon, 21 Jul 2014 14:29:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 0EF09121C4D; Mon, 21 Jul 2014 14:29:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Mon, 21 Jul 2014 17:29:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C617074-6B19-41AA-9C3E-AB60EF6E89AF@thomasclausen.org> References: To: "Cole, Robert G CIV USARMY CERDEC (US)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8kAwWAb1KdEQngpr2mL2XcYrhJE Cc: "manet-chairs@tools.ietf.org" , manet-ads , manet Subject: Re: [manet] Status of SMF MIB? (UNCLASSIFIED) 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, 21 Jul 2014 21:29:38 -0000 Dear Bob, Awesome, thank you. I thought that I would follow up with the WG and try to get clarity on this p= oint, in case there was something more profound afoot keeping it from advanc= ing. Looking forward to see the update. Best, Thomas Sent from my iPad > On 21 Jul 2014, at 16:42, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Thomas, >=20 > You are correct, it has stalled. I'll correct this. >=20 > To my knowledge all of the issues raised by the various reviewers were add= ressed to their satisfaction in our email exchanges back in April. However,= I need to incorporate the revisions into a final draft and re-issue (along w= ith notes of explanation to each of the reviewer). =20 >=20 > I will work up the revision this week and post the new version prior to th= e beginning of next week. Hopefully then, I can move this draft forward to i= ts conclusion. >=20 > Thanks for your (the working group's, chairs' and Ads') patience regarding= this matter. >=20 > Bob >=20 > US Army CERDEC > QUEST Program, S&TCD > APG, MD >=20 > (c) 443.910.4420 > (o) 443.395.8744 > robert.g.cole@us.army.mil >=20 >=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide >> Clausen >> Sent: Monday, July 21, 2014 1:34 PM >> To: manet >> Cc: manet-chairs@tools.ietf.org; manet-ads >> Subject: [manet] Status of SMF MIB? >>=20 >> Hello all, >>=20 >> The SMF MIB seems to be stalled. If I interpret the tracker correctly, th= e >> document has been in =E2=80=9CRevised I-D Needed=E2=80=9D state for 116 d= ays or so. >>=20 >> Could the document shepherd let the WG know what the status and hold-up o= f >> this document is, please? >>=20 >> Thomas >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 >=20 From nobody Mon Jul 21 14:46:38 2014 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 84CBC1A0169 for ; Mon, 21 Jul 2014 14:46:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ojbK0Lwl2mxf for ; Mon, 21 Jul 2014 14:46:35 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A1B1A00C5 for ; Mon, 21 Jul 2014 14:46:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 8354B121C4C; Mon, 21 Jul 2014 14:46:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 17701121C4B; Mon, 21 Jul 2014 14:46:35 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <805F526F-2199-4F7D-A24B-50FB3DE88075@thomasclausen.org> Date: Mon, 21 Jul 2014 17:46:35 -0400 To: manet , "" , manet-ads X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Idq1ZB--RuetY33e-QR3Fr4xkKI Subject: [manet] Another question on MIBs -- Report-mib, this time. 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, 21 Jul 2014 21:46:36 -0000 Dear WG, WG-Chairs, I'm working on an I-D. That I-D would like to cite REPORT-MIB.=20 Alas, REPORT-MIB was last updated on the 5th of November, 2012. I believe that the fate of REPORT-MIB has been discussed numerous times over= the past year or so, but I am actually not sure that a resolution has been r= eached (or, if it has, what that resolution is): =09 o Abandoned, we're not going to do this o We're going to revive it, and the schedule looks like _____= Inquiring mind wanting to know - mostly to know if I can reasonably cite thi= s document, or if I should avoid the citation since it might become a blocki= ng issue, or a downref. Best, Thomas Sent from my iPad= From nobody Mon Jul 21 23:37:39 2014 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 CF0B51A059F for ; Mon, 21 Jul 2014 23:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, IXHASH_X1=1.5, 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 DyxzzsrrZXmq for ; Mon, 21 Jul 2014 23:37:36 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C561A0552 for ; Mon, 21 Jul 2014 23:37:36 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so7434196wgg.4 for ; Mon, 21 Jul 2014 23:37:35 -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=a/t+EPTmNsQv5PDq3MaesYFNmifZ8pqlXKt3QqdJBFc=; b=LHPqa0G/tNHKelXixOPoIoD6+HVVc7YistLCWzUTDsLX5IhtJqmnFL8gCDcZemWI1+ RWWWrUqmBbOBgXpapKT1tGsOwq2wKR0jlH6UDaImyeEtCh64SkW7sg+Trl/iSWYcMgZG QXtB1YqmJJw6JfuVMkWbtKGPT1+UOx2hf2s7o2m9I5oJ0QQgTWwQ9YyVRsIuKt67wT1P SGRuXOfOpIZZ2Kv8rzPWhi8jFbZsrxVCpFOo0xverRsNTwqpkcn4AmMDB7zBKilwWoEn p5S6bMsUJULsbfOirEV6qYeORbQemM3WSbtOGhwT3rRM5iJiRAcUgK36ugJO0uSqvR30 i7vA== MIME-Version: 1.0 X-Received: by 10.180.205.141 with SMTP id lg13mr11655855wic.21.1406011055186; Mon, 21 Jul 2014 23:37:35 -0700 (PDT) Received: by 10.216.44.142 with HTTP; Mon, 21 Jul 2014 23:37:35 -0700 (PDT) Date: Tue, 22 Jul 2014 11:07:35 +0430 Message-ID: From: Ali Imani To: "manet@ietf.org List" Content-Type: multipart/alternative; boundary=001a11c263887ea9b604fec27580 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Fxb1LX_0kV5Gc42V4dCRNuhcMjU Subject: [manet] Remove me 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, 22 Jul 2014 06:37:38 -0000 --001a11c263887ea9b604fec27580 Content-Type: text/plain; charset=UTF-8 --001a11c263887ea9b604fec27580 Content-Type: text/html; charset=UTF-8
--001a11c263887ea9b604fec27580-- From nobody Mon Jul 21 23:39:42 2014 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 3AF4A1A0A96 for ; Mon, 21 Jul 2014 23:39: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 9kT6xERYrHwh for ; Mon, 21 Jul 2014 23:39:40 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10631A0A86 for ; Mon, 21 Jul 2014 23:39:39 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so6134869qaq.11 for ; Mon, 21 Jul 2014 23:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5JTWf5iUTN4M8hiQJYMYnw66YDZynxgkp2NgiTrQvFk=; b=flmEknM7JwNR/Y1u1OPSDfhVP/VR6xoV0sDllzj37TcatZ2HhRu37OJWGU6mRdLX8S YLQETEkbQ8yP3iZNSRNXQn1rsUndsuAtfhSLCWJih+p6KmtA6VumchKPjxlfPqvAUdGB XHRBeujeqfI1iyZs77AYvHk/h/YQPra4KpTKse9MIN45qMV8OmQkB/EohuRmefxLUeCE p6rxZZaIdWQKfaEx4fKtodBVSQ+o0AnsXcn62xGI/UyL7epC8U9veGR8GjRsom9PAAYT iNcK0VQ2nTpfPNTW659auN8Gp6fWrpBmpo+jZospd8lbHpFOyQb87H3v5AIt17tlYjXc XVaQ== X-Received: by 10.140.88.243 with SMTP id t106mr44818392qgd.12.1406011179097; Mon, 21 Jul 2014 23:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Mon, 21 Jul 2014 23:39:19 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 22 Jul 2014 08:39:19 +0200 Message-ID: To: Ali Imani Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2mCgulhmYdtOdW2WgmPxeKGSi70 Cc: "manet@ietf.org List" Subject: Re: [manet] Remove me 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, 22 Jul 2014 06:39:41 -0000 Hi, at the end of each message you receive, you will find a link to the relevant "Mailman" (mail manager) website, where you can remove yourself. Henning Rogge On Tue, Jul 22, 2014 at 8:37 AM, Ali Imani wrote: > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Mon Jul 21 23:50:44 2014 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 5484A1A064C for ; Mon, 21 Jul 2014 23:50:43 -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_FONT_SIZE_LARGE=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 JqdFXnhewNgl for ; Mon, 21 Jul 2014 23:50:41 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0501A059F for ; Mon, 21 Jul 2014 23:50:41 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so5317589wiv.13 for ; Mon, 21 Jul 2014 23:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=C+qq/+3UX+I8Cq03vfx4izroPxRczpCUBes1Ynogt8g=; b=byIgA2mUyHP06UDGjQYN545J2PvHo23A4doK2VNnNFOOJSvhm1eEZlCDn5TfaU2wAn LO+/D//jToImKe3RfMmj8r1jNRn8ZaTgt6Tvr4bCFMxlt9ZI4UpwZy+VABFRO+SkrBeN JtYIeBMXnIl7fYxG09lz+QpJjDuO7YHTGKacZOKmGMcafXl8IznSF16VBecej7Zz19bB 0+SvBNUjIYQobpqnhyT64f0bea2mwXQBh8eZkjPHKB6zv2AH4ix7/whS+90rt4Cr7suL xB+SBVDgtXJPZ2SJB8R3JklCcRB3aoOG8Zm9iZpsZLD5SarxDvfaYoINu1m+7UQFo4h5 a3SA== MIME-Version: 1.0 X-Received: by 10.180.205.141 with SMTP id lg13mr11753437wic.21.1406011839851; Mon, 21 Jul 2014 23:50:39 -0700 (PDT) Received: by 10.216.44.142 with HTTP; Mon, 21 Jul 2014 23:50:39 -0700 (PDT) In-Reply-To: <805F526F-2199-4F7D-A24B-50FB3DE88075@thomasclausen.org> References: <805F526F-2199-4F7D-A24B-50FB3DE88075@thomasclausen.org> Date: Tue, 22 Jul 2014 11:20:39 +0430 Message-ID: From: Ali Imani To: Thomas Clausen , "manet@ietf.org List" Content-Type: multipart/alternative; boundary=001a11c2638843b1ad04fec2a445 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ArxO9V1HgPQRbJI3_hHePLmcjnA Subject: Re: [manet] Another question on MIBs -- Report-mib, this time. 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, 22 Jul 2014 06:50:43 -0000 --001a11c2638843b1ad04fec2a445 Content-Type: text/plain; charset=UTF-8 remove me On Tue, Jul 22, 2014 at 2:16 AM, Thomas Clausen wrote: > Dear WG, WG-Chairs, > > I'm working on an I-D. > > That I-D would like to cite REPORT-MIB. > > Alas, REPORT-MIB was last updated on the 5th of November, 2012. > > I believe that the fate of REPORT-MIB has been discussed numerous times > over the past year or so, but I am actually not sure that a resolution has > been reached (or, if it has, what that resolution is): > > o Abandoned, we're not going to do this > o We're going to revive it, and the schedule looks like _____ > > Inquiring mind wanting to know - mostly to know if I can reasonably cite > this document, or if I should avoid the citation since it might become a > blocking issue, or a downref. > > Best, > > Thomas > > Sent from my iPad > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c2638843b1ad04fec2a445 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
remove me


On Tue, Jul 22, 2014 at 2:16 AM,= Thomas Clausen <thomas@thomasclausen.org> wrote:
Dear WG, WG-Chairs,

I'm working on an I-D.

That I-D would like to cite REPORT-MIB.

Alas, REPORT-MIB was last updated on the 5th of November, 2012.

I believe that the fate of REPORT-MIB has been discussed numerous times ove= r the past year or so, but I am actually not sure that a resolution has bee= n reached (or, if it has, what that resolution is):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0 =C2=A0 =C2=A0 Abandoned, we're not= going to do this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0 =C2=A0 =C2=A0 We're going to reviv= e it, and the schedule looks like _____

Inquiring mind wanting to know - mostly to know if I can reasonably cite th= is document, or if I should avoid the citation since it might become a bloc= king issue, or a downref.

Best,

Thomas

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

--001a11c2638843b1ad04fec2a445-- From nobody Tue Jul 22 04:02:17 2014 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 C785A1A01C3 for ; Tue, 22 Jul 2014 04:02:14 -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 WjKy9ZlRrYVS for ; Tue, 22 Jul 2014 04:02:13 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243F81A016B for ; Tue, 22 Jul 2014 04:02:12 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so7814197wgh.15 for ; Tue, 22 Jul 2014 04:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1JX3Fq+cKvKSkvmTE4cNS0WvGVmJYnq/U8ATa5plTPg=; b=iu2tWEmD4LRe++idCRqM+UDyeQWwdN0nQa+ZsnXqoC4rYCCq2QAdwt6AOXSc5Hpe9x P8QWDM/AluHi3eurcOL24X5jQ4A0oWhWrS2PL4vpx9Ea4eVcPdgQxsdieRfxhbIt6GiK zNqP4bghj9kx7SbQA8fX/FzO6bU8CNijk9X/0ADgZ+nZDrygmUCEg6phbw/THgXlftcm WMtTYWCGbrrERjn4mCT059NVUMFj5NgM2WpSVAaJTOwv7L+e59PUKYlPNbLlzjXMRK2p cHDl90h+hJWNodrIpjbaMJLipHNYo0X16Suz/aGfLx8uo/ulN6X7JGT8A8xwj9GeI71x u0qA== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr13647651wib.20.1406026931552; Tue, 22 Jul 2014 04:02:11 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Tue, 22 Jul 2014 04:02:11 -0700 (PDT) In-Reply-To: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> Date: Tue, 22 Jul 2014 13:02:11 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ec65ccc8f904fec6277b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/j4nejMAZzbUh5oRS2n1uQgidlvc Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) 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, 22 Jul 2014 11:02:14 -0000 --f46d0444ec65ccc8f904fec6277b Content-Type: text/plain; charset=UTF-8 IMHO The problem is that RFC5444 still does not have a multiplexing standard in IETF. The way of multiplexing is still just implemented by OLSRv2 experts but I dont find any standard for multiplexing yet. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not specified for all RFC5444 formats because it is general format but RFC5498 is not general. If I am wrong please point me to an RFC. AB On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker < trac+manet@trac.tools.ietf.org> wrote: > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) > > The document is completely noncompliant with the RFC 5444 multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-manet- > charliep@computer.org | aodvv2@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: aodvv2 | Version: > Severity: Active WG | Keywords: RFC 5498 > Document | > -------------------------+------------------------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d0444ec65ccc8f904fec6277b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO The problem is that RFC5444 still does not have = a multiplexing standard in IETF. The way of multiplexing is still just impl= emented by OLSRv2 experts but I dont find any standard for multiplexing yet= . The RFC5498 is not for multipexing as I understand it. We already discuss= ed once that multiplexing is not specified for all RFC5444 formats because = it is general format but RFC5498 is not general.
=C2=A0
If I am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tra= cker <trac+manet@trac.tools.ietf.org> wrote:
#45: RFC 5498 non-compliance (submitt= ed for Chris Dearlove)

=C2=A0The document is completely noncompliant= with the RFC 5444 multiplexing
=C2=A0mechanism, mandated by RFC 5498 (on the manet port/protocol). It does=
=C2=A0many things that are not within its competence.

--
----= ---------------------+-------------------------------------------------
= =C2=A0Reporter: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0Owner: =C2=A0draft-ietf-manet-
=C2=A0 charliep@computer.org = =C2=A0| =C2=A0aodvv2@tools.ietf.or= g
=C2=A0 =C2=A0 =C2=A0Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 Status: =C2=A0new
=C2=A0Priority: =C2=A0minor =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0Milestone:
Component: =C2=A0aodvv2 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Version:
=C2= =A0Severity: =C2=A0Active WG =C2=A0 =C2=A0| =C2=A0 Keywords: =C2=A0RFC 5498=
=C2=A0 Document =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
-= ------------------------+-------------------------------------------------<= br>
Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45= >
manet <http:/= /tools.ietf.org/manet/>

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

--f46d0444ec65ccc8f904fec6277b-- From nobody Tue Jul 22 05:24:37 2014 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 F0B041A0AD5 for ; Tue, 22 Jul 2014 05:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ES_zq_WwPCdN for ; Tue, 22 Jul 2014 05:24:34 -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 835761A064A for ; Tue, 22 Jul 2014 05:24:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="459769310" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:24:31 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="58615564" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:24:33 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:24:34 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "manet@ietf.org" Thread-Topic: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) Thread-Index: AQHPpJWJ9gYyJ8BybUCpcuu2+pDuDZur3teAgAAnEvA= Date: Tue, 22 Jul 2014 12:24:33 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC7BGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kpN_YwhW0Jc_j8kRph5UB1UQbJo Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) 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, 22 Jul 2014 12:24:36 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC7BGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 UkZDNTQ0NCBkZXNjcmliZXMgYSBtdWx0aXBsZXhpbmcgcHJvY2Vzcy4gSXQgaXMgbm90IHJlcXVp cmVkIHB1cmVseSBpbiBpdHMgb3duIHRlcm1zLiBCdXQgUkZDIDU0OTggbWFrZSBpdCBtYW5kYXRv cnkgZm9yIGFueSBwcm90b2NvbCB1c2luZyB0aGUgcG9ydC9wcm90b2NvbCBhbGxvY2F0ZWQgYnkg dGhhdCBSRkMuIEFuZCB0aGUgV0cgaGFzIGFncmVlZCB0aGF0IGFsbCByb3V0aW5nIHByb3RvY29s cyBkZXZlbG9wZWQgaGF2ZSB0byBiZSBhYmxlIChhdCBsZWFzdCkgdG8gdXNlIHRoYXQgcG9ydC9w cm90b2NvbC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVu Z2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3 b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQg VGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywg Q2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0 IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpC QUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndp Y2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJv cm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVz IE5vOiAxOTk2Njg3DQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEFiZHVzc2FsYW0gQmFyeXVuDQpTZW50OiAyMiBKdWx5IDIwMTQgMTI6 MDINClRvOiBtYW5ldEBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xz LmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSAjNDUgKGFvZHZ2Mik6IFJGQyA1NDk4IG5v bi1jb21wbGlhbmNlIChzdWJtaXR0ZWQgZm9yIENocmlzIERlYXJsb3ZlKQ0KDQoNCioqKiBXQVJO SU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlz YXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0K Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGlu ZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2Vp dmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlv dSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vz czxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMu cGRmPi4NCklNSE8gVGhlIHByb2JsZW0gaXMgdGhhdCBSRkM1NDQ0IHN0aWxsIGRvZXMgbm90IGhh dmUgYSBtdWx0aXBsZXhpbmcgc3RhbmRhcmQgaW4gSUVURi4gVGhlIHdheSBvZiBtdWx0aXBsZXhp bmcgaXMgc3RpbGwganVzdCBpbXBsZW1lbnRlZCBieSBPTFNSdjIgZXhwZXJ0cyBidXQgSSBkb250 IGZpbmQgYW55IHN0YW5kYXJkIGZvciBtdWx0aXBsZXhpbmcgeWV0LiBUaGUgUkZDNTQ5OCBpcyBu b3QgZm9yIG11bHRpcGV4aW5nIGFzIEkgdW5kZXJzdGFuZCBpdC4gV2UgYWxyZWFkeSBkaXNjdXNz ZWQgb25jZSB0aGF0IG11bHRpcGxleGluZyBpcyBub3Qgc3BlY2lmaWVkIGZvciBhbGwgUkZDNTQ0 NCBmb3JtYXRzIGJlY2F1c2UgaXQgaXMgZ2VuZXJhbCBmb3JtYXQgYnV0IFJGQzU0OTggaXMgbm90 IGdlbmVyYWwuDQoNCklmIEkgYW0gd3JvbmcgcGxlYXNlIHBvaW50IG1lIHRvIGFuIFJGQy4NCkFC DQpPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCA1OjQwIEFNLCBtYW5ldCBpc3N1ZSB0cmFja2VyIDx0 cmFjK21hbmV0QHRyYWMudG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnRyYWMrbWFuZXRAdHJhYy50b29s cy5pZXRmLm9yZz4+IHdyb3RlOg0KIzQ1OiBSRkMgNTQ5OCBub24tY29tcGxpYW5jZSAoc3VibWl0 dGVkIGZvciBDaHJpcyBEZWFybG92ZSkNCg0KIFRoZSBkb2N1bWVudCBpcyBjb21wbGV0ZWx5IG5v bmNvbXBsaWFudCB3aXRoIHRoZSBSRkMgNTQ0NCBtdWx0aXBsZXhpbmcNCiBtZWNoYW5pc20sIG1h bmRhdGVkIGJ5IFJGQyA1NDk4IChvbiB0aGUgbWFuZXQgcG9ydC9wcm90b2NvbCkuIEl0IGRvZXMN CiBtYW55IHRoaW5ncyB0aGF0IGFyZSBub3Qgd2l0aGluIGl0cyBjb21wZXRlbmNlLg0KDQotLQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICAgICAgICAgICAgICAgfCAgICAgIE93bmVy OiAgZHJhZnQtaWV0Zi1tYW5ldC0NCiAgY2hhcmxpZXBAY29tcHV0ZXIub3JnPG1haWx0bzpjaGFy bGllcEBjb21wdXRlci5vcmc+ICB8ICBhb2R2djJAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmFvZHZ2 MkB0b29scy5pZXRmLm9yZz4NCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICB8ICAgICBTdGF0dXM6 ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6 ICBhb2R2djIgICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgQWN0aXZlIFdHICAgIHwg ICBLZXl3b3JkczogIFJGQyA1NDk4DQogIERvY3VtZW50ICAgICAgICAgICAgICAgfA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL21h bmV0L3RyYWMvdGlja2V0LzQ1Pg0KbWFuZXQgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9tYW5ldC8+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5l dCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK VGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGlu dGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0 ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBp dCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC7BGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJGQzU0NDQgZGVzY3JpYmVzIGEgbXVsdGlwbGV4aW5nIHBy b2Nlc3MuIEl0IGlzIG5vdCByZXF1aXJlZCBwdXJlbHkgaW4gaXRzIG93biB0ZXJtcy4gQnV0IFJG QyA1NDk4IG1ha2UgaXQgbWFuZGF0b3J5IGZvciBhbnkgcHJvdG9jb2wgdXNpbmcgdGhlIHBvcnQv cHJvdG9jb2wNCiBhbGxvY2F0ZWQgYnkgdGhhdCBSRkMuIEFuZCB0aGUgV0cgaGFzIGFncmVlZCB0 aGF0IGFsbCByb3V0aW5nIHByb3RvY29scyBkZXZlbG9wZWQgaGF2ZSB0byBiZSBhYmxlIChhdCBs ZWFzdCkgdG8gdXNlIHRoYXQgcG9ydC9wcm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VuaW9yIFByaW5jaXBhbCBF bmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMs IE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMg QWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEy NDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYjNDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0i bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208L3NwYW4+PC9hPg0KIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTxicj4NCjxicj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+QkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpS ZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBB ZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJl Z2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4NzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBt YW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KPGI+U2VudDo8L2I+IDIyIEp1bHkgMjAxNCAxMjowMjxi cj4NCjxiPlRvOjwvYj4gbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYt bWFuZXQtYW9kdnYyQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFu ZXRdICM0NSAoYW9kdnYyKTogUkZDIDU0OTggbm9uLWNvbXBsaWFuY2UgKHN1Ym1pdHRlZCBmb3Ig Q2hyaXMgRGVhcmxvdmUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sg MS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp dGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBt ZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBm cm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5r cywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwv aT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxh Z3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2 ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0K aGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNw aWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5 c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5n JTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9z cGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNSE8gVGhlIHByb2JsZW0gaXMgdGhhdCBSRkM1NDQ0IHN0 aWxsIGRvZXMgbm90IGhhdmUgYSBtdWx0aXBsZXhpbmcgc3RhbmRhcmQgaW4gSUVURi4gVGhlIHdh eSBvZiBtdWx0aXBsZXhpbmcgaXMgc3RpbGwganVzdCBpbXBsZW1lbnRlZCBieSBPTFNSdjIgZXhw ZXJ0cyBidXQgSSBkb250IGZpbmQgYW55IHN0YW5kYXJkIGZvciBtdWx0aXBsZXhpbmcgeWV0LiBU aGUgUkZDNTQ5OCBpcyBub3QgZm9yIG11bHRpcGV4aW5nDQogYXMgSSB1bmRlcnN0YW5kIGl0LiBX ZSBhbHJlYWR5IGRpc2N1c3NlZCBvbmNlIHRoYXQgbXVsdGlwbGV4aW5nIGlzIG5vdCBzcGVjaWZp ZWQgZm9yIGFsbCBSRkM1NDQ0IGZvcm1hdHMgYmVjYXVzZSBpdCBpcyBnZW5lcmFsIGZvcm1hdCBi dXQgUkZDNTQ5OCBpcyBub3QgZ2VuZXJhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSBhbSB3cm9uZyBwbGVhc2UgcG9pbnQgbWUgdG8g YW4gUkZDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QUI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0IDU6NDAgQU0sIG1hbmV0IGlzc3VlIHRyYWNrZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzp0cmFjJiM0MzttYW5ldEB0cmFjLnRvb2xzLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHJhYyYjNDM7bWFuZXRAdHJhYy50b29scy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzQ1OiBSRkMgNTQ5OCBu b24tY29tcGxpYW5jZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSk8YnI+DQo8YnI+DQom bmJzcDtUaGUgZG9jdW1lbnQgaXMgY29tcGxldGVseSBub25jb21wbGlhbnQgd2l0aCB0aGUgUkZD IDU0NDQgbXVsdGlwbGV4aW5nPGJyPg0KJm5ic3A7bWVjaGFuaXNtLCBtYW5kYXRlZCBieSBSRkMg NTQ5OCAob24gdGhlIG1hbmV0IHBvcnQvcHJvdG9jb2wpLiBJdCBkb2VzPGJyPg0KJm5ic3A7bWFu eSB0aGluZ3MgdGhhdCBhcmUgbm90IHdpdGhpbiBpdHMgY29tcGV0ZW5jZS48YnI+DQo8YnI+DQot LTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQombmJzcDtSZXBvcnRlcjogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDtPd25lcjogJm5ic3A7ZHJhZnQtaWV0Zi1tYW5ldC08YnI+DQombmJzcDsgPGEgaHJl Zj0ibWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+Y2hhcmxpZXBAY29tcHV0ZXIub3JnPC9h PiAmbmJzcDt8ICZuYnNwOzxhIGhyZWY9Im1haWx0bzphb2R2djJAdG9vbHMuaWV0Zi5vcmciPmFv ZHZ2MkB0b29scy5pZXRmLm9yZzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO1R5cGU6ICZu YnNwO2RlZmVjdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgU3RhdHVzOiAm bmJzcDtuZXc8YnI+DQombmJzcDtQcmlvcml0eTogJm5ic3A7bWlub3IgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCAmbmJzcDtNaWxlc3RvbmU6PGJyPg0KQ29tcG9uZW50OiAmbmJzcDthb2R2 djIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7VmVyc2lvbjo8YnI+DQombmJz cDtTZXZlcml0eTogJm5ic3A7QWN0aXZlIFdHICZuYnNwOyAmbmJzcDt8ICZuYnNwOyBLZXl3b3Jk czogJm5ic3A7UkZDIDU0OTg8YnI+DQombmJzcDsgRG9jdW1lbnQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KPGJyPg0KVGlja2V0IFVSTDogJmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvd2cvbWFuZXQvdHJhYy90aWNrZXQvNDUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL3dnL21hbmV0L3RyYWMvdGlja2V0LzQ1PC9hPiZndDs8YnI+DQptYW5ldCAm bHQ7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL21hbmV0LyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9tYW5ldC88L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8 YnI+ClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRo ZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZy b20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4KWW91IHNob3VsZCBub3Qg Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4KZGlz dHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+CioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PC9wPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC7BGLKXM0002VGREEN_-- From nobody Tue Jul 22 05:26:42 2014 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 C1BE61A0ADE for ; Tue, 22 Jul 2014 05:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 2AT2wzfaFh9l for ; Tue, 22 Jul 2014 05:26:38 -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 7912F1A0ADC for ; Tue, 22 Jul 2014 05:26:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="388464098" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 13:26:36 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="65623573" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 13:26:42 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:26:43 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] draft-ietf-manet-olsrv2-multitopology-02 Thread-Index: AQHPlUvtgnYCP2J2BUy5nE+mbSIHqJuMyluAgAASOhCAGMX/gIAGgxpQ Date: Tue, 22 Jul 2014 12:26:42 +0000 Message-ID: References: <49C9A5BC-6A5C-4509-AFA2-CD75179D3E13@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC91GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/EjzSxQhkWdAXw7QEGhwRKt2idck Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02 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, 22 Jul 2014 12:26:40 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC91GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 QWxsIG9mIHRob3NlIHF1ZXN0aW9ucyBhcmUgYW5zd2VyZWQgaW4gdGhlIGRyYWZ0LCBpbiBwYXJ0 aWN1bGFyIGluIFNlY3Rpb24gNC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmlj YXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3Rl bXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdy ZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0 IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHwgaHR0cDovL3d3dy5iYWVzeXN0 ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBP ZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENl bnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZyb206IEFiZHVzc2FsYW0gQmFyeXVuIFttYWls dG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb21dDQpTZW50OiAxOCBKdWx5IDIwMTQgMTE6MDAN ClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IFN0YW4gUmF0bGlmZiAoc3JhdGxp ZmYpOyBtYW5ldCBJRVRGDQpTdWJqZWN0OiBSZTogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LW9s c3J2Mi1tdWx0aXRvcG9sb2d5LTAyDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ug b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g ZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hl dGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMg b3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBj YW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1 c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQu YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0Rl YWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQoNCk9uIFdlZG5lc2Rh eSwgSnVseSAyLCAyMDE0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToNCkkgZG8g bm90IHJlY2FsbCBhbnkgcHJldmlvdXNseSBhc2tlZCBhbmQgdW5hbnN3ZXJlZCBxdWVzdGlvbnMg ZnJvbSB5b3UuDQoNCiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQv Y3VycmVudC9tc2cxNTg1MC5odG1sDQoNClRoZSBxdWVzdGlvbnMgd2VyZSBmb3IgdGhlIGRyYWZ0 IGJlZm9yZSBhZG9wdGlvbiwgYnV0IGlmIGFuc3dlcmVkIHdpbGwgaGVscCB0aGUgZXhwZXJpbWVu dCBvZiB0aGlzIGFkb3B0ZWQgcHJvdG9jb2wuIEkgYW0gc29ycnkgZm9yIG5vdCBjb21wbGV0ZSBy ZXZpZXcgYnV0IHdpbGwgc3VibWl0IHNob3J0bHkgYmVmb3JlIG1lZXRpbmcuDQoNCkFCDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0 byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5 b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQg b3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC91GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsbCBvZiB0aG9zZSBxdWVzdGlvbnMgYXJlIGFuc3dlcmVk IGluIHRoZSBkcmFmdCwgaW4gcGFydGljdWxhciBpbiBTZWN0aW9uIDQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdG9waGVyIERlYXJsb3ZlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4NCkNvbW11 bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJB RSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmll bGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDog JiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4NCiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208YnI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1p dGVkPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFy bmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwg VUs8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gQWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBKdWx5IDIwMTQgMTE6MDA8YnI+DQo8Yj5Ubzo8 L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBTdGFuIFJhdGxp ZmYgKHNyYXRsaWZmKTsgbWFuZXQgSUVURjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXRvcG9sb2d5LTAyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBw dCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAq Kio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl IGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5 b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw bHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJk aW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBv dXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50 cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv Y3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklm IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVm PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMu cGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiBXZWRuZXNk YXksIEp1bHkgMiwgMjAxNCwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3QgcmVjYWxsIGFueSBwcmV2aW91c2x5 IGFza2VkIGFuZCB1bmFuc3dlcmVkIHF1ZXN0aW9ucyBmcm9tIHlvdS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTU4NTAuaHRtbCI+ aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTU4 NTAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIHF1ZXN0aW9ucyB3ZXJlIGZvciB0aGUgZHJhZnQgYmVmb3JlIGFkb3B0aW9u LCBidXQgaWYgYW5zd2VyZWQgd2lsbCBoZWxwIHRoZSBleHBlcmltZW50Jm5ic3A7b2YgdGhpcyBh ZG9wdGVkIHByb3RvY29sLiBJIGFtIHNvcnJ5IGZvciBub3QgY29tcGxldGUgcmV2aWV3IGJ1dCB3 aWxsIHN1Ym1pdCBzaG9ydGx5IGJlZm9yZSBtZWV0aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BQjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJy PgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg dGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkg cHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEC91GLKXM0002VGREEN_-- From nobody Tue Jul 22 05:27:23 2014 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 46CDE1A0AE2 for ; Tue, 22 Jul 2014 05:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 oiH2tCGZC_u0 for ; Tue, 22 Jul 2014 05:27:18 -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 1F5A31A0AE9 for ; Tue, 22 Jul 2014 05:27:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="459770796" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:27:16 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="58616085" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:27:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:27:24 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Three drafts to progress Thread-Index: Ac+g4AzL/nr5eDepTmK3VGcbYl9zyAB4VDQAALm2uUA= Date: Tue, 22 Jul 2014 12:27:23 +0000 Message-ID: References: <2269A8ED-73CC-4334-A819-7D79521DE08B@cisco.com> In-Reply-To: <2269A8ED-73CC-4334-A819-7D79521DE08B@cisco.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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEECA3GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/f9eQGJZUd_WxjIMse-AIeAQ0xUY Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] Three drafts to progress 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, 22 Jul 2014 12:27:21 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEECA3GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (First I've been back in office since this.) Thanks Stan. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 18 July 2014 15:49 To: Dearlove, Christopher (UK) Cc: manet-chairs@tools.ietf.org; manet@ietf.org; manet-ads@tools.ietf.org Subject: Re: [manet] Three drafts to progress *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Chris/All, draft-dearlove-manet-ibs-00 and draft-dearlove-manet-nhdp-optimization-01 a= re accepted as working group drafts. As Chris notes, draft-ietf-manet-olsrv2-multitopology-03 has cleared WGLC. = We'll work to get a document shepherd assigned and push for publication. Regards, Stan On Jul 16, 2014, at 6:27 AM, "Dearlove, Christopher (UK)" > wrote: Joe, Stan, All The call to adopt draft-dearlove-manet-ibs-00.txt as a WG document was made= on 30th June for comment within 2 weeks, which has now passed. The WGLC for draft-ietf-manet-olsrv2-multitopology-02 (updated to draft-iet= f-manet-olsrv2-multitopology-03 on 4th July based on comments made) was mad= e on 1st July, for comments by 14th July, which has now passed. The call to adopt draft-dearlove-manet-nhdp-optimization-01 was made on 2nd= July, with no period stated (which I overlooked) but has had a period of 2= weeks since then. I've seen various positive comments, especially on the first two, and no ne= gative ones. I'd like therefore to ask the chairs to take the appropriate a= ctions (some of which then come back to the authors). Christopher -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEECA3GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(First I’ve been ba= ck in office since this.)

 <= /p>

Thanks Stan.

 <= /p>

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

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

 <= /p>

From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 18 July 2014 15:49
To: Dearlove, Christopher (UK)
Cc: manet-chairs@tools.ietf.org; manet@ietf.org; manet-ads@tools.iet= f.org
Subject: Re: [manet] Three drafts to progress

 

 

*** WARNING ***=

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

Chris/All, 

 

draft-dearlove-manet-ibs-00 and draft-dearlove-manet= -nhdp-optimization-01 are accepted as working group drafts. 

 

As Chris notes, draft-ietf-manet-olsrv2-multitopolog= y-03 has cleared WGLC. We'll work to get a document shepherd assigned and p= ush for publication. 

 

Regards,

Stan

 

On Jul 16, 2014, at 6:27 AM, "Dearlove, Christo= pher (UK)" <chris.= dearlove@baesystems.com> wrote:



Joe, Stan, All

 

The call to adopt draft-dearlove-manet-= ibs-00.txt as a WG document was made on 30th June for comment within 2 week= s, which has now passed.

 

The WGLC for draft-ietf-manet-olsrv2-mu= ltitopology-02 (updated to draft-ietf-manet-olsrv2-multitopology-03 on 4th = July based on comments made) was made on 1st July, for comments by 14th July, which has now passed.

 

The call to adopt draft-dearlove-manet-= nhdp-optimization-01 was made on 2nd July, with no period stated (which I o= verlooked) but has had a period of 2 weeks since then.

 

I’ve seen various positive commen= ts, especially on the first two, and no negative ones. I’d like there= fore to ask the chairs to take the appropriate actions (some of which then come back to the authors).

 

Christopher

 

--

Christopher Dearlove

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

= chris.dearlove@baesystems.com | http://www.bae= systems.com

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

 

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

_____________________________________= __________
manet mailing list
manet@ietf.o= rg
https://www.ietf.org/mailman/listinfo/manet=

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEECA3GLKXM0002VGREEN_-- From nobody Tue Jul 22 05:30:19 2014 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 0F41A1A0AEA for ; Tue, 22 Jul 2014 05:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 2qPo1HjU-XhG for ; Tue, 22 Jul 2014 05:30:16 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B6A1A0AE1 for ; Tue, 22 Jul 2014 05:30:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="459772009" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:30:14 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="58616514" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:30:21 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:30:22 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #43 (aodvv2): Reliance on bidirectional paths (submitted for Chris Dearlove) Thread-Index: AQHPpJUYvDt+kr6EP0abOo+1LWSvQ5up2hmAgAItuQA= Date: Tue, 22 Jul 2014 12:30:21 +0000 Message-ID: References: <061.7e05e09a5a981863ce7bf1d07b303583@trac.tools.ietf.org> <53CC9339.50103@computer.org> In-Reply-To: <53CC9339.50103@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Fejj3IyTKOb0k5NhZnXaqliJi5M Subject: Re: [manet] #43 (aodvv2): Reliance on bidirectional paths (submitted for Chris Dearlove) 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, 22 Jul 2014 12:30:18 -0000 VGhlIGtleSB0aGluZyBpcyB0aGF0IHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgbmVl ZCB0byBpbnRlcm9wZXJhdGUgYW5kIG5vdCB1c2UgdW5pZGlyZWN0aW9uYWwgbGlua3MuIEF0IHRo ZSBtb21lbnQgdGhhdCB3b3VsZG4ndCBoYXBwZW4uDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxv dmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91 cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5 DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmll bGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQg MTI0NSAyNDIxOTTCoHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9w ZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBC b3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywg R1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hhcmxlcyBFLiBQZXJraW5zIFtt YWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnXSANClNlbnQ6IDIxIEp1bHkgMjAxNCAwNToxMw0K VG86IG1hbmV0QGlldGYub3JnOyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgZHJhZnQtaWV0 Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdICM0MyAo YW9kdnYyKTogUmVsaWFuY2Ugb24gYmlkaXJlY3Rpb25hbCBwYXRocyAoc3VibWl0dGVkIGZvciBD aHJpcyBEZWFybG92ZSkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0 aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNr IG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhl ICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1 Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSGVsbG8g Q2hyaXMsDQoNClBlcmhhcHMgaXQgd291bGQgYmUgYmV0dGVyIHRvIGlkZW50aWZ5IHRoZSBwcm9w ZXIgcHJvdG9jb2wgbWV0aG9kIGFzIHBhcnQgb2YgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50 LiAgSWYgbm8gb3RoZXIgbWVhbnMgYXJlIGF2YWlsYWJsZSwgdGhlbg0KQU9EVnYyIG5vZGVzIGNv dWxkIGJlIHJlcXVpcmVkIHRvIHVzZSB0aGUgYmxhY2tsaXN0IG1lY2hhbmlzbSwgd2hpY2ggaXMg aW50ZW5kZWQgdG8gcHJvdmlkZSBiaWRpcmVjdGlvbmFsaXR5Lg0KDQpJdCBzZWVtcyB1bndpc2Ug dG8gcmVxdWlyZSBhZGRpdGlvbmFsIHByb3RvY29sIG1lY2hhbmlzbXMgZm9yIGNhc2VzIGluIHdo aWNoIGxheWVyIDIgYWxyZWFkeSBndWFyYW50ZWVzIGJpZGlyZWN0aW9uYWwgbGlua3MuICBUaGlz IGNvdWxkIGFsc28gYmUgaW5jbHVkZWQgYXMgYSBzdGF0ZW1lbnQgd2l0aGluIHRoZSBhcHBsaWNh YmlsaXR5IHNlY3Rpb24uDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KT24gNy8yMC8yMDE0 IDg6MzcgUE0sIG1hbmV0IGlzc3VlIHRyYWNrZXIgd3JvdGU6DQo+ICM0MzogUmVsaWFuY2Ugb24g YmlkaXJlY3Rpb25hbCBwYXRocyAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSkNCj4NCj4g ICBUaGUgcHJvdG9jb2wgcmVsaWVzIG9uIGxpbmtzIGJlaW5nIGJpZGlyZWN0aW9uYWwuIEl0IG11 c3QgdGhlcmVmb3JlDQo+ICAgcHJvdmlkZSBhIG1lYW5zIHRvIGVuc3VlIHRoYXQuIEl0J3Mgbm90 IGdvb2QgZW5vdWdoIHRvIGxpc3Qgc2V2ZXJhbA0KPiAgIHBvc3NpYmlsaXRpZXMgLSB0aGF0IHdp bGwgbm90IG9mZmVyIGludGVyb3BlcmFiaWxpdHkuIEl0IGlzIGZpbmUgb2YgY291cnNlDQo+ICAg dG8gb2ZmZXIgYWxsb3dpbmcgYWRkaXRpb25hbCByZWFzb25zIHRvIGV4Y2x1ZGUgbGlua3MsIGJ1 dCB0aGVyZSBuZWVkcyB0bw0KPiAgIGJlIGEgYmFzaWMgbm9uLW9wdGlvbmFsIG1lY2hhbmlzbSBm b3Igc29tZXRoaW5nIHRoYXQgdGhlIHByb3RvY29sIHdpbGwgbm90DQo+ICAgd29yayB3aXRob3V0 Lg0KPg0KDQotLQ0KUmVnYXJkcywNCkNoYXJsaWUgUC4NCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJl Y2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5v dGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Tue Jul 22 05:31:54 2014 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 91D321A0208 for ; Tue, 22 Jul 2014 05:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 7cLbiYA28NUr for ; Tue, 22 Jul 2014 05:31:50 -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 0DD661A0AEC for ; Tue, 22 Jul 2014 05:31:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="459772942" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:31:44 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="58616734" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:31:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:31:52 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #44 (aodvv2): Hop count (submitted for Chris Dearlove) Thread-Index: AQHPpJqnrKSqJw0CA0uM666HHJ2CDZusCDdQ Date: Tue, 22 Jul 2014 12:31:51 +0000 Message-ID: References: <061.da9873dd6d5b2c594251eb39ecba54b5@trac.tools.ietf.org> <53CC9423.1010502@computer.org> In-Reply-To: <53CC9423.1010502@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wdQpKyrKSwNmGr1yzVH7DqRb6Dc Subject: Re: [manet] #44 (aodvv2): Hop count (submitted for Chris Dearlove) 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, 22 Jul 2014 12:31:51 -0000 WW91IG5lZWQgdG8gY2hhbmdlIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBoYW5kbGUgYSBuZXcgbWV0 cmljIHR5cGUsIEknbSBhZnJhaWQgSSBkb24ndCBoYXZlIHRoZSB0aW1lIHRoaXMgbWludXRlIHRv IGNoZWNrIHRoZSBmdW5jdGlvbiBuYW1lIHRoYXQgbmVlZHMgaW1wbGVtZW50aW5nIC0gYW5kIGlz IG9ubHkgc3BlY2lmaWVkIGZvciBob3AgY291bnQuIEEgbmV3IG1ldHJpYyBuZWVkcyBhIG5ldyBz cGVjaWZpY2F0aW9uIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiB0aGF0IGZ1bmN0aW9uLg0KDQotLSAN CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1h dGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2Ug QW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50 cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00y IDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0K Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t DQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTog V2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBG YXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYg V2FsZXMgTm86IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Q2hhcmxlcyBFLiBQZXJraW5zIFttYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnXSANClNlbnQ6 IDIxIEp1bHkgMjAxNCAwNToxNw0KVG86IG1hbmV0QGlldGYub3JnOyBEZWFybG92ZSwgQ2hyaXN0 b3BoZXIgKFVLKTsgZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdICM0NCAoYW9kdnYyKTogSG9wIGNvdW50IChzdWJtaXR0ZWQgZm9yIENo cmlzIERlYXJsb3ZlKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3Vy IG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRo ZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sg b24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUg J1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVj dGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIZWxsbyBD aHJpcywNCg0KSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgeW91IG1ha2UgdGhlIGNsYWltIHRoYXQg QU9EVnYyIGNhbm5vdCBoYW5kbGUgZnV0dXJlIG1ldHJpYyBjaGFuZ2VzLiAgSWYgbm9kZXMgd2lz aCB0byB1c2UgYWx0ZXJuYXRlIG1ldHJpY3MsIHRoZSBjdXJyZW50IGRyYWZ0IHNwZWNpZmllcyBt ZWNoYW5pc21zIHRvIGluc3VyZSB0aGF0IHJvdXRlcyB3aWxsIGJlIHNlbGVjdGVkIGJhc2VkIG9u IHRoZSBjb3N0cyBhc3NvY2lhdGVkIHRvIHRob3NlIHJvdXRlcyBhcyBjb21wdXRlZCBieSB0aGUg YWx0ZXJuYXRlIG1ldHJpYy4gIElmIHRoaXMgaXMgbm90IHRydWUsIGNvdWxkIHlvdSBiZSBtb3Jl IHNwZWNpZmljIGFib3V0IGhvdyB0aGUgaW50ZW5kZWQgbWVjaGFuaXNtcyBmYWlsIHRvIGRvIHNv Pw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDcvMjAvMjAxNCA4OjM4IFBNLCBtYW5l dCBpc3N1ZSB0cmFja2VyIHdyb3RlOg0KPiAjNDQ6IEhvcCBjb3VudCAoc3VibWl0dGVkIGZvciBD aHJpcyBEZWFybG92ZSkNCj4NCj4gICBEZXNwaXRlIHNheWluZyB0aGF0IGhvcCBjb3VudCBpcyBp bmFkZXF1YXRlLCBpdCdzIHRoZSBvbmx5IG1ldHJpYw0KPiAgIHN1cHBvcnRlZC4gQW5kIHVubGlr ZSBPTFNSdjIsIHdoaWNoIGlzIGRlc2lnbmVkIHNvIHRoYXQgdGhlIHByb3RvY29sDQo+ICAgY2Fu IGhhbmRsZSBhbnkgZnV0dXJlIG1ldHJpYyB3aXRob3V0IGNoYW5nZSwgdGhhdCdzIG5vdCB0cnVl IGhlcmUuDQo+ICAgVGhhdCdzIGEgZGVmaW5pdGUgcHJvdG9jb2wgd2Vha25lc3MuDQo+DQoNCi0t DQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj aXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBu b3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv bi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioK From nobody Tue Jul 22 05:34:36 2014 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 ED3E11A0ADF for ; Tue, 22 Jul 2014 05:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 LGOSCdp75CLh for ; Tue, 22 Jul 2014 05:34:33 -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 CFD501A0ADC for ; Tue, 22 Jul 2014 05:34:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="459773972" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:34:30 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="58617217" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:34:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:34:23 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) Thread-Index: AQHPpJWJ9gYyJ8BybUCpcuu2+pDuDZup37OAgAIo/8A= Date: Tue, 22 Jul 2014 12:34:22 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <53CC97ED.4050308@computer.org> In-Reply-To: <53CC97ED.4050308@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SllLZtNoWQXEl9R3R9OZU5Rt6o8 Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) 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, 22 Jul 2014 12:34:36 -0000 VGhlIHF1b3RlZCB0ZXh0IGlzIGlycmVsZXZhbnQgdG8gdGhpcyBwb2ludC4NCg0KQXMgaGFzIGJl ZW4gc2FpZCBtYW55IHRpbWVzLCBwYWNrZXRzIGJlbG9uZyB0byB0aGUgbXVsdGlwbGV4ZXIsIG1l c3NhZ2VzIHRvIHRoZSBwcm90b2NvbC4gVGhlcmUgYXJlIG1hbnkgcGllY2VzIG9mIHRleHQgc3Bl Y2lmeWluZyB0aGluZ3MgYWJvdXQgcGFja2V0cyB0aGF0IGFyZSBvdXQgb2YgdGhlIGNvbXBldGVu Y2Ugb2YgdGhlIHByb3RvY29sLiBJJ20gYWZyYWlkIEkgc3RvcHBlZCBtYXJraW5nIHRoZW0gb24g bXkgY29weS4NCg0KKEZvciBleGFjdGx5IGhvdyB0aGUgcHJvdG9jb2wgY2FuIGludGVyYWN0IHdp dGggcGFja2V0cywgc2VlIDU0NDQuKQ0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11 bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5 c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQs IEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQy MTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25z KSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBG YXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllV LCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hhcmxlcyBFLiBQZXJraW5zIFttYWlsdG86 Y2hhcmxpZXBAY29tcHV0ZXIub3JnXSANClNlbnQ6IDIxIEp1bHkgMjAxNCAwNTozMw0KVG86IG1h bmV0QGlldGYub3JnOyBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZzsgRGVh cmxvdmUsIENocmlzdG9waGVyIChVSykNClN1YmplY3Q6IFJlOiBbbWFuZXRdICM0NSAoYW9kdnYy KTogUkZDIDU0OTggbm9uLWNvbXBsaWFuY2UgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUp DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0K Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3Bp Y2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBv cnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkhlbGxvIENocmlzLA0KDQpUaGUg ZG9jdW1lbnQgc3RhdGVzOg0KDQo+ICAgIEluIGl0cyBkZWZhdWx0IG1vZGUgb2Ygb3BlcmF0aW9u LCBBT0RWdjIgc2VuZHMgbWVzc2FnZXMgdXNpbmcgdGhlDQo+ICAgIHBhcmFtZXRlcnMgZm9yIHBv cnQgbnVtYmVyIGFuZCBJUCBwcm90b2NvbCBzcGVjaWZpZWQgaW4gW1JGQzU0OThdIHRvDQo+ICAg IGNhcnJ5IHByb3RvY29sIHBhY2tldHMuICBCeSBkZWZhdWx0LCBBT0RWdjIgbWVzc2FnZXMgYXJl IHNlbnQgd2l0aA0KPiAgICB0aGUgSVAgZGVzdGluYXRpb24gYWRkcmVzcyBzZXQgdG8gdGhlIGxp bmstbG9jYWwgbXVsdGljYXN0IGFkZHJlc3MNCj4gICAgTEwtTUFORVQtUm91dGVycyBbUkZDNTQ5 OF0gdW5sZXNzIG90aGVyd2lzZSBzcGVjaWZpZWQuIFRoZXJlZm9yZSwNCj4gICAgYWxsIEFPRFZ2 MiByb3V0ZXJzIE1VU1Qgc3Vic2NyaWJlIHRvIExMLU1BTkVULVJvdXRlcnMgW1JGQzU0OThdIHRv DQo+ICAgIHJlY2VpdmluZyBBT0RWdjIgbWVzc2FnZXMuDQoNClNvLCBJIHN1c3BlY3QgdGhlIHBy b2JsZW0gbGllcyBlbHNld2hlcmUuICBDb3VsZCB5b3UgcG9pbnQgdG8gdGhlIG5vbmNvbXBsaWFu dCBwYXJ0IG9mIHRoZSBBT0RWdjIgc3BlY2lmaWNhdGlvbiwgYW5kIHRoZSBwcm90b2NvbCBtYW5k YXRlIGZvciB3aGljaCB0aGUgQU9EVnYyIHNwZWNpZmljYXRpb24gaXMgbm9uY29tcGxpYW50Pw0K DQoNCk9uIDcvMjAvMjAxNCA4OjQwIFBNLCBtYW5ldCBpc3N1ZSB0cmFja2VyIHdyb3RlOg0KPiAj NDU6IFJGQyA1NDk4IG5vbi1jb21wbGlhbmNlIChzdWJtaXR0ZWQgZm9yIENocmlzIERlYXJsb3Zl KQ0KPg0KPiAgIFRoZSBkb2N1bWVudCBpcyBjb21wbGV0ZWx5IG5vbmNvbXBsaWFudCB3aXRoIHRo ZSBSRkMgNTQ0NCBtdWx0aXBsZXhpbmcNCj4gICBtZWNoYW5pc20sIG1hbmRhdGVkIGJ5IFJGQyA1 NDk4IChvbiB0aGUgbWFuZXQgcG9ydC9wcm90b2NvbCkuIEl0IGRvZXMNCj4gICBtYW55IHRoaW5n cyB0aGF0IGFyZSBub3Qgd2l0aGluIGl0cyBjb21wZXRlbmNlLg0KPg0KDQotLQ0KUmVnYXJkcywN CkNoYXJsaWUgUC4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVh c2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ug c2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3Nl IG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqCg== From nobody Tue Jul 22 05:37:20 2014 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 721671A0ADF for ; Tue, 22 Jul 2014 05:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 SR_9W_9doURh for ; Tue, 22 Jul 2014 05:37: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 169961A0AFC for ; Tue, 22 Jul 2014 05:37:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="459775313" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:37:09 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="58617949" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:37:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:37:17 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) Thread-Index: AQHPpJXUi8mNGGufc0WgpNK9XyBUG5up4ZyAgAInynA= Date: Tue, 22 Jul 2014 12:37:16 +0000 Message-ID: References: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> <53CC9987.6060104@computer.org> In-Reply-To: <53CC9987.6060104@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kbYmr1dB-LAOSmQdrQthQhbTY90 Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) 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, 22 Jul 2014 12:37:19 -0000 SnVzdCBmb3IgYSBzdGFydCB5b3UgYWxzbyBuZWVkIHRvIGtub3cgdGhhdCBJUCByb3V0ZXMgYXJl IHJlcXVlc3RlZCwgdGhhdCBwYWNrZXRzIGFyZSBmbG93aW5nLCBhbmQgdG8gaGF2ZSB0aGUgYWJp bGl0eSB0byBxdWV1ZSBwYWNrZXRzLiBJJ20gcHJldHR5IHN1cmUgbm90IGFsbCBvZiB0aG9zZSBh cmUgbWFuZGF0ZWQgYnkgSVAuIFRoZSByb3V0aW5nIHByb3RvY29sIGFsc28gbmVlZHMgdG8gc2Vl IElDTVAgbWVzc2FnZXMgLSBpcyB0aGF0IG5vcm1hbD8NCg0KQXMgSSBzYWlkLCBpdCdzIGEgbWF0 dGVyIG9mIHdoYXQgdGhlIHdob2xlIGFyY2hpdGVjdHVyZSBsb29rcyBsaWtlLg0KDQotLSANCkNo cmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlv biBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5h bHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUN Cldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhI TiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoN CkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fy d2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJu Ym9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMgTm86IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hh cmxlcyBFLiBQZXJraW5zIFttYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnXSANClNlbnQ6IDIx IEp1bHkgMjAxNCAwNTo0MA0KVG86IG1hbmV0QGlldGYub3JnOyBkcmFmdC1pZXRmLW1hbmV0LWFv ZHZ2MkB0b29scy5pZXRmLm9yZzsgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNClN1YmplY3Q6 IFJlOiBbbWFuZXRdICM0NiAoYW9kdnYyKTogV2hhdCBpcyBuZWVkZWQgZnJvbSBJUCBhbmQgSUNN UCAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs IHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhl ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig cmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQg bWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1l c3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSGVsbG8gQ2hyaXMsDQoNCkkgYW0gcHJldHR5IHN1cmUgdGhhdCB0aGUgb25s eSB0aGluZ3MgbmVlZGVkIGZyb20gSVAgYW5kIElDTVAgYXJlIGZlYXR1cmVzIHRoYXQgYXJlIGFs cmVhZHkgbWFuZGF0ZWQgYnkgSVAgKGluY2x1ZGluZyBJQ01QKS4gIElmIHRoZXJlIHdlcmUgZGFu Z2VyIHRoYXQgQU9EVnYyIG1pZ2h0IHJlcXVpcmUgb3B0aW9uYWwgZmVhdHVyZXMgb2YgSVAgb3Ig b3B0aW9uYWwgZmVhdHVyZXMgb2YgSUNNUCwgSSBjb3VsZCB1bmRlcnN0YW5kIHlvdXIgY29uY2Vy bi4gIEFzIGl0IGlzLCBJIGRvIG5vdCB1bmRlcnN0YW5kIGV4YWN0bHkgd2hhdCBpcyBuZWVkZWQg dG8gZW5oYW5jZSBpbXBsZW1lbnRhYmlsaXR5IG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQpUaGUg b25seSB0aGluZyBleHBlY3RlZCBmcm9tIElDTVAgaXMgZGVsaXZlcnkgb2YgRGVzdGluYXRpb24g VW5yZWFjaGFibGUgKFR5cGUgMyBDb2RlIDEpLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpbXBs ZW1lbnRhdGlvbnMgYXJlIHVubGlrZWx5IHRvIHByb3ZpZGU/DQoNCkkgYW0gY29uZnVzZWQgYWJv dXQgd2hhdCAob3RoZXIgdGhhbiBJQ01QKSBBT0RWdjIgIm5lZWRzIiBmcm9tIElQIHRoYXQgY291 bGQgY2F1c2UgYSBwcm9ibGVtLiAgVHJ1ZSwgd2UgZG8gZXhwZWN0IElQIHRvIGZpbmQgdGhlIHBy b3BlciBvdXRnb2luZyBpbnRlcmZhY2UsIGFuZCB0byBwZXJmb3JtIGxvbmdlc3QtcHJlZml4LWZp cnN0IG1hdGNoaW5nLCBhbmQgc28gb24uLi4NCg0KRG8geW91IGhhdmUgYW4gZXhhbXBsZSBvZiBz b21lIG90aGVyIHByb3RvY29sIHNwZWNpZmljYXRpb24gdGhhdCBsaXN0cyB0aGVzZSBraW5kcyBv ZiBkZXBlbmRlbmNpZXM/DQoNCg0KT24gNy8yMC8yMDE0IDg6NDIgUE0sIG1hbmV0IGlzc3VlIHRy YWNrZXIgd3JvdGU6DQo+ICM0NjogV2hhdCBpcyBuZWVkZWQgZnJvbSBJUCBhbmQgSUNNUCAoc3Vi bWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSkNCj4NCj4gICBUaGUgcHJvdG9jb2wgbmVlZHMgbWFu eSB0aGluZ3MgZnJvbSBJUCwgc3VjaCBhcyBmYWlsZWQgcm91dGluZw0KPiAgIG5vdGlmaWNhdGlv biwgYW5kIGludGVyYWN0cyB3aXRoIGl0IGluIHdheXMgc3VjaCBhcyBxdWV1aW5nIHBhY2tldHMu DQo+ICAgSXQgYWxzbyBpbnRlcmFjdHMgKHNlbmRzIGFuZCByZWNlaXZlcykgd2l0aCBJQ01QLCBh bmQgSSdtIG5vdCBzdXJlDQo+ICAgd2hhdCBlbHNlLiBUaGlzIG5lZWRzIHRvIGJlIHB1dCB0b2dl dGhlciwgc28gdGhlIHJlYWRlciBjYW4gc2VlIHdoYXQNCj4gICBpcyBuZWVkZWQgdG8gYmUgYWJs ZSB0byBpbXBsZW1lbnQgdGhpcy4NCj4NCg0KLS0NClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBp dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0 cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Tue Jul 22 05:38:30 2014 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 D40031A0AF3 for ; Tue, 22 Jul 2014 05:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ftV0e9d-nLb0 for ; Tue, 22 Jul 2014 05:38:28 -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 277F21A0AFC for ; Tue, 22 Jul 2014 05:38:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="388468900" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 13:38:24 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="65626014" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 13:38:30 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:38:31 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) Thread-Index: AQHPpJYUeiDPaaz1Z0eQvrYiMlVQoZup4hsAgAIoGEA= Date: Tue, 22 Jul 2014 12:38:30 +0000 Message-ID: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> In-Reply-To: <53CC99F2.5050103@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Ew6Jojo-gFr6Q_dHJILF2P1vOUE Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 12:38:29 -0000 SXQgbWlnaHQgbWFrZSBtb3JlIHNlbnNlIHRvIGRpc2N1c3MgYSBwcm9wb3NhbCBmb3IgaW5jbHVz aW9uIGluIGEgV0cgZHJhZnQgd2l0aCB0aGUgV0cgZmlyc3QuDQoNCi0tIA0KQ2hyaXN0b3BoZXIg RGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5j ZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBh YmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5u aW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVs OiArNDQgMTI0NSAyNDIxOTTCoHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3Rl bXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNl LCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBI YW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5 NjY4Nw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaGFybGVzIEUuIFBl cmtpbnMgW21haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmddIA0KU2VudDogMjEgSnVseSAyMDE0 IDA1OjQxDQpUbzogbWFuZXRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xz LmlldGYub3JnOyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KU3ViamVjdDogUmU6IFttYW5l dF0gIzQ3IChhb2R2djIpOiBTZWN1cml0eSBhcHByb2FjaCB1bmFjY2VwdGFibGUgKHN1Ym1pdHRl ZCBmb3IgQ2hyaXMgRGVhcmxvdmUpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcg ISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0 c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9y IGZyb20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9s bG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9y IGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CkhlbGxvIENocmlzLA0KDQpJIGhhdmUgdGhvdWdodCBhYm91dCB0aGlzIGZvciBhIGxvbmcgdGlt ZS4gIEZpbmFsbHksIGFmdGVyIHNvbWUgZ29vZCBkaXNjdXNzaW9uIGhlcmUgYXQgdGhlIElFVEYs IEkgaGF2ZSBpZGVudGlmaWVkIGEgd2F5IGZvcndhcmQuICBJIHdpbGwgcG9zdCBpdCB0byB0aGUg bGlzdCBhZnRlciBnZXR0aW5nIHNvbWUgcHJvcGVyIHNlY3VyaXR5IHJldmlldyBmb3IgaXQuDQoN Ck9uIDcvMjAvMjAxNCA4OjQzIFBNLCBtYW5ldCBpc3N1ZSB0cmFja2VyIHdyb3RlOg0KPiAjNDc6 IFNlY3VyaXR5IGFwcHJvYWNoIHVuYWNjZXB0YWJsZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFy bG92ZSkNCj4NCj4gICBUaGUgc2VjdXJpdHkgYXBwcm9hY2ggaXMgdW5hY2NlcHRhYmxlLiBUaGUg c2VjdXJpdHkNCj4gICBkaXJlY3RvcmF0ZSBhbmQgQURzIHJlZnVzZWQgdG8gYWNjZXB0IHRoaXMg ZnJvbSBPTFNSdjIuIFRoZXkgd2lsbA0KPiAgIHJlZnVzZSB0byBhY2NlcHQgdGhpcyBmcm9tIHRo aXMgcHJvdG9jb2wuIEluY2lkZW50YWxseSBub3RlIHRoYXQNCj4gICByZWZlcmVuY2VzIHRvIFJG QyA2NjIxIHNob3VsZCBiZSB0byBSRkMgNjYyMiwgZXhjZXB0IG5vdyB0byBSRkMgNzE4Mi4NCj4N Cg0KLS0NClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGll bnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg dGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw b3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKgo= From nobody Tue Jul 22 05:39:42 2014 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 99A751A0B09 for ; Tue, 22 Jul 2014 05:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 63Bl_ABQZ6Du for ; Tue, 22 Jul 2014 05:39:40 -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 CD3921A0B05 for ; Tue, 22 Jul 2014 05:39:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="459776333" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 13:39:32 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="58618285" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 13:39:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 13:39:30 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) Thread-Index: AQHPpJZRpGdaQIoNtkqxT42LJQkBP5up4z0AgAInWBA= Date: Tue, 22 Jul 2014 12:39:29 +0000 Message-ID: References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> In-Reply-To: <53CC9AE6.7090800@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JVOcGVsQ2KWMiDm4vood57RKhck Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 12:39:41 -0000 SW4gYXQgbGVhc3Qgb25lIHBsYWNlIGluIHRoZSBkcmFmdCAoc29ycnksIEkgZG9uJ3QgaGF2ZSB0 aGUgdGltZSB0byBmaW5kIGl0IGFnYWluIG5vdykgaXQgZXhwbGljaXRseSBzYXlzIG9uZSBhZGRy ZXNzIHBlciBpbnRlcmZhY2UuDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNh dGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVt cyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3Jl YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTTC oHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSB8 IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExp bWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5i b3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVL DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaGFybGVzIEUuIFBlcmtpbnMgW21haWx0bzpjaGFy bGllcEBjb21wdXRlci5vcmddIA0KU2VudDogMjEgSnVseSAyMDE0IDA1OjQ1DQpUbzogbWFuZXRA aWV0Zi5vcmc7IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBkcmFmdC1pZXRmLW1hbmV0LWFv ZHZ2MkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gIzQ4IChhb2R2djIpOiBT aW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlIHBlciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3IgQ2hy aXMgRGVhcmxvdmUpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhl IGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAn UmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0 aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkhlbGxvIENo cmlzLA0KDQpBT0RWdjIgZG9lcyBub3QgaW1wb3NlIHRoaXMgcmVzdHJpY3Rpb24uICBJdCBoYXMs IGZvciBhIGxvbmcgdGltZSwgZW5hYmxlZCBtdWx0aXBsZSByb3V0ZXIgYWRkcmVzc2VzIHBlciBp bnRlcmZhY2UuICBJIHdpbGwgbG9vayBhZ2FpbiwgYnV0IGFzIG9mIG5vdyBJIGRvIG5vdCBzZWUg d2hlcmUgYW55IHN1Y2ggcmVzdHJpY3Rpb24gaGFzIGJlZW4gaW1wb3NlZC4gIElmIHlvdSBoYXZl IGlkZW50aWZpZWQgd2hlcmUgdGhpcyByZXN0cmljdGlvbiBpcyBpbXBsaWVkIG9yIHN0YXRlZCBk aXJlY3RseSwgcGxlYXNlIGxldCBtZSBrbm93IGFzIHNvb24gYXMgcG9zc2libGUuDQoNClVubnVt YmVyZWQgaW50ZXJmYWNlcyBoYXZlIG5ldmVyIGJlZW4gc3VnZ2VzdGVkIGFzIGFwcHJvcHJpYXRl IGZvciBpbmNsdXNpb24gb2YgdGhlIGZlYXR1cmUgc2V0IGZvciBhbnkgcmVhY3RpdmUgcHJvdG9j b2wgdGhhdCB3YXMgdW5kZXIgY29uc2lkZXJhdGlvbiB3aXRoaW4gW21hbmV0XSwgYWxsIHRoZSB3 YXkgc2luY2UgdGhlIHZlcnkgaW5pdGlhdGlvbiBvZiB0aGUgd29ya2luZyBncm91cC4gIEF0IGxl YXN0IG5vdCB3aXRoaW4gbXkgbWVtb3J5Lg0KDQpPbiA3LzIwLzIwMTQgODo0NiBQTSwgbWFuZXQg aXNzdWUgdHJhY2tlciB3cm90ZToNCj4gIzQ4OiBTaW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNl IHBlciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgDQo+IERlYXJsb3ZlKQ0KPg0KPiAgIFRo ZSBtb2RlbCBpcyBvZiByb3V0ZXJzIHdpdGggYSBzaW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNl LiBJbiBPTFNSdjINCj4gICB0aGlzIHdhc24ndCBjb25zaWRlcmVkIGFjY2VwdGFibGUuIFRoZSBh dXRob3JzIGRlZmluZWQgbXVsdGlwbGUgYWRkcmVzc2VzDQo+ICAgcGVyIGludGVyZmFjZSwgdGhl IFdHIHJlcXVpcmVkIHN1cHBvcnRpbmcgdW5udW1iZXJlZCBpbnRlcmZhY2VzIHdoaWNoDQo+ICAg c2hhcmVkIGFkZHJlc3Nlcy4NCj4NCg0KLS0NClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBv ciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Tue Jul 22 05:42:48 2014 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 7605A1A0AFD for ; Tue, 22 Jul 2014 05:42:46 -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 w1sOw3T34CTJ for ; Tue, 22 Jul 2014 05:42:45 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97931A0B04 for ; Tue, 22 Jul 2014 05:42:44 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so7009542qga.1 for ; Tue, 22 Jul 2014 05:42:44 -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=11F9uwO5qhothIIjx68eYkVNLR4FUDPeD6+BBEQVGFA=; b=X/5548p41wgDPyxafhsLOjvoQ7QP1YawV/euWWSP2OQYRmmhUrllHViJa+/XTzgnxR l2IgoSQm8s6u9UWijatjl4hOfi84+uw/MvZKdKreg5l5cKl5Z9qFQobDKaOpahvX+Q52 txkVi2K7/RtaAheaHNEKJydg/0y0L43UsEopfGfTOgTy5u+tsxuyM2SXLy09NUnh3P+h ga8dH5xtfkMFJyFvtCatZLFregVghLgFmvglj3B/l7JL84GhLJX1qoVu5xqXXHoYQfhI 9jUEfqAl24wsRYAdufkCem5c5q7usj6rwpj6iNTDdTTdIFjPmxSVFx3ejm9NA7vjrhtH Ofhw== X-Received: by 10.224.96.137 with SMTP id h9mr55073916qan.96.1406032964015; Tue, 22 Jul 2014 05:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 05:42:23 -0700 (PDT) In-Reply-To: References: <061.da9873dd6d5b2c594251eb39ecba54b5@trac.tools.ietf.org> <53CC9423.1010502@computer.org> From: Henning Rogge Date: Tue, 22 Jul 2014 14:42:23 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CswqXeafytRPXX4hCRRXV8Bd8ik Cc: "manet@ietf.org" Subject: Re: [manet] #44 (aodvv2): Hop count (submitted for Chris Dearlove) 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, 22 Jul 2014 12:42:46 -0000 On Tue, Jul 22, 2014 at 2:31 PM, Dearlove, Christopher (UK) wrote: > You need to change the implementation to handle a new metric type, I'm af= raid I don't have the time this minute to check the function name that need= s implementing - and is only specified for hop count. A new metric needs a = new specification and implementation of that function. I think you also need to work out a custom encoding/decoding for the TLV value because there is no definition of a generic transport format for the metric. Henning Rogge From nobody Tue Jul 22 06:01:13 2014 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 1ED841ABC75 for ; Tue, 22 Jul 2014 06:01:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 MQJ7AKBrI2L0 for ; Tue, 22 Jul 2014 06:01:07 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7798E1AC0D2 for ; Tue, 22 Jul 2014 06:00:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 508E2247325; Tue, 22 Jul 2014 06:00:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E9021240820; Tue, 22 Jul 2014 06:00:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 15:00:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CAB23BD-12D8-4619-B243-EC211DB4AD70@thomasclausen.org> References: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> <53CC9987.6060104@computer.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CBeMZURhUhZYfGi8vp7o9gi_PDU Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) 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, 22 Jul 2014 13:01:11 -0000 > On 22 Jul 2014, at 14:37 , Dearlove, Christopher (UK) = wrote: >=20 > Just for a start you also need to know that IP routes are requested, = that packets are flowing, and to have the ability to queue packets. I'm = pretty sure not all of those are mandated by IP. The routing protocol = also needs to see ICMP messages - is that normal? >=20 > As I said, it's a matter of what the whole architecture looks like. >=20 Just to pile on to what Chris says here. There is this whole thing of an =E2=80=9Cactive route=E2=80=9D being one = that is actually used for forwarding data traffic, and that the IP stack = needs to somehow record and report this to the protocol. That=E2=80=99s actually a pretty invasive operation, and I am not = certain that all platforms allow for that, and I know that there=E2=80=99r= e platforms where you really don=E2=80=99t want to do that. Such things scope pretty narrowly the applicability of the protocol, and = it therefore must be called out in the applicability statement = (currently this constraint is buried pretty deep in section 5 and 6). There=E2=80=99re =E2=80=94 as Chris indicate =E2=80=94 a lot of things = of this nature, where this protocol interacts in =E2=80=9Cnon-traditional=E2= =80=9D ways with the IP stack, and these need to be called out very = explicitly.=20 This both to allow identifying the platforms on which this protocol can = be made operate (and those where it cannot), and to correctly identify = the complexity of implementing this protocol on a given platform. > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@computer.org]=20 > Sent: 21 July 2014 05:40 > To: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; Dearlove, = Christopher (UK) > Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP = (submitted for Chris Dearlove) >=20 > ----------------------! 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. > -------------------------------------------------------- >=20 > Hello Chris, >=20 > I am pretty sure that the only things needed from IP and ICMP are = features that are already mandated by IP (including ICMP). If there = were danger that AODVv2 might require optional features of IP or = optional features of ICMP, I could understand your concern. As it is, I = do not understand exactly what is needed to enhance implementability of = the specification. >=20 > The only thing expected from ICMP is delivery of Destination = Unreachable (Type 3 Code 1). Is this something that implementations are = unlikely to provide? >=20 > I am confused about what (other than ICMP) AODVv2 "needs" from IP that = could cause a problem. True, we do expect IP to find the proper = outgoing interface, and to perform longest-prefix-first matching, and so = on... >=20 > Do you have an example of some other protocol specification that lists = these kinds of dependencies? >=20 >=20 > On 7/20/2014 8:42 PM, manet issue tracker wrote: >> #46: What is needed from IP and ICMP (submitted for Chris Dearlove) >>=20 >> The protocol needs many things from IP, such as failed routing >> notification, and interacts with it in ways such as queuing packets. >> It also interacts (sends and receives) with ICMP, and I'm not sure >> what else. This needs to be put together, so the reader can see what >> is needed to be able to implement this. >>=20 >=20 > -- > Regards, > Charlie P. >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 06:09:51 2014 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 941171B27A2 for ; Tue, 22 Jul 2014 06:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ARvpRqr8P1yl for ; Tue, 22 Jul 2014 06:09:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978A21B2793 for ; Tue, 22 Jul 2014 06:08:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7BB532408CA; Tue, 22 Jul 2014 06:08:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 511FF240820; Tue, 22 Jul 2014 06:08:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5596533-B738-426E-8072-E3FF55BB5F24" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 15:08:28 +0200 Message-Id: <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0Tsio1NcJ-g3Mo8DwnSGukdTT_o Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , manet-ads , "manet@ietf.org" Subject: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) 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, 22 Jul 2014 13:09:48 -0000 --Apple-Mail=_C5596533-B738-426E-8072-E3FF55BB5F24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am still, with reference to this document, dismayed to see that there = remain abundant references to positional information in address blocks = in RFC5444 messages.=20 As has been pointed out numerous times, this is inappropriate, = positional information cannot be assumed assured and preserved by = generic 5444 message generation and parsing code. The first instance of = this offense is in Table 1 ... This has been requested fixed for years now. When will it be fixed? > On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) = wrote: >=20 > RFC5444 describes a multiplexing process. It is not required purely in = its own terms. But RFC 5498 make it mandatory for any protocol using the = port/protocol allocated by that RFC. And the WG has agreed that all = routing protocols developed have to be able (at least) to use that = port/protocol. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam = Baryun > Sent: 22 July 2014 12:02 > To: manet@ietf.org > Cc: draft-ietf-manet-aodvv2@tools.ietf.org > Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted = for Chris Dearlove) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > IMHO The problem is that RFC5444 still does not have a multiplexing = standard in IETF. The way of multiplexing is still just implemented by = OLSRv2 experts but I dont find any standard for multiplexing yet. The = RFC5498 is not for multipexing as I understand it. We already discussed = once that multiplexing is not specified for all RFC5444 formats because = it is general format but RFC5498 is not general. > =20 > If I am wrong please point me to an RFC. > AB > On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker = wrote: > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) >=20 > The document is completely noncompliant with the RFC 5444 = multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. >=20 > -- > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-manet- > charliep@computer.org | aodvv2@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: aodvv2 | Version: > Severity: Active WG | Keywords: RFC 5498 > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_C5596533-B738-426E-8072-E3FF55BB5F24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am = still, with reference to this document, dismayed to see that there = remain abundant references to positional information in address blocks = in RFC5444 messages. 

As has been pointed out = numerous times, this is inappropriate, positional information cannot be = assumed assured and preserved by generic 5444 message generation and = parsing code. The first instance of this offense is in Table 1 = ...

This has been requested fixed for years now. When = will it be fixed?


On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) = <Chris.Dearlove@baesystems.co= m> wrote:

RFC5444 describes a multiplexing process. It is not = required purely in its own terms. But RFC 5498 make it mandatory for any = protocol using the port/protocol allocated by that RFC. And the WG has = agreed that all routing protocols developed have to be able (at least) = to use that port/protocol.
 
--
Christopher Dearlove
Senior Principal = Engineer, Information Assurance Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam = Baryun
Sent: 22 July 2014 = 12:02
To: manet@ietf.org
Cc: draft-ietf-manet-aodvv2@tools.ietf.org
Subject:<= span class=3D"Apple-converted-space"> Re: [manet] #45 = (aodvv2): RFC 5498 non-compliance (submitted for Chris = Dearlove)
 
 
*** = WARNING ***

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

IMHO The problem is that RFC5444 still does not have a = multiplexing standard in IETF. The way of multiplexing is still just = implemented by OLSRv2 experts but I dont find any standard for = multiplexing yet. The RFC5498 is not for multipexing as I understand it. = We already discussed once that multiplexing is not specified for all = RFC5444 formats because it is general format but RFC5498 is not = general.
 
If I = am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <trac+manet@trac.tools.ietf.org> = wrote:
#45: RFC 5498 = non-compliance (submitted for Chris Dearlove)

 The document = is completely noncompliant with the RFC 5444 = multiplexing
 mechanism, mandated by RFC 5498 (on the manet = port/protocol). It does
 many things that are not within its = competence.

--
-------------------------+-----------------------= --------------------------
 Reporter:       =         |      Owner: =  draft-ietf-manet-
  charliep@computer.org  |  aodvv2@tools.ietf.org
    =  Type:  defect       |     Status: =  new
 Priority:  minor        | =  Milestone:
Component:  aodvv2       | =    Version:
 Severity:  Active WG    | =   Keywords:  RFC 5498
  Document       =         = |
-------------------------+-------------------------------------------= ------

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45>
mane= t <http://tools.ietf.org/manet/>

__________________= _____________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
 

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

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

= --Apple-Mail=_C5596533-B738-426E-8072-E3FF55BB5F24-- From nobody Tue Jul 22 06:19:05 2014 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 85CD41B278E for ; Tue, 22 Jul 2014 06:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uPR9XpOqLCgn for ; Tue, 22 Jul 2014 06:18:54 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E1D1A0AFD for ; Tue, 22 Jul 2014 06:18:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 969B124099D; Tue, 22 Jul 2014 06:18:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CA2A1240961; Tue, 22 Jul 2014 06:18:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_219D4A61-2314-4F4E-AFF5-FA82900EAE24" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 15:18:39 +0200 Message-Id: References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OYyzw64LfuJ162bgK8ucsCSEOrM Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 13:18:58 -0000 --Apple-Mail=_219D4A61-2314-4F4E-AFF5-FA82900EAE24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jul 2014, at 14:39 , Dearlove, Christopher (UK) = wrote: >=20 > In at least one place in the draft (sorry, I don't have the time to = find it again now) it explicitly says one address per interface. >=20 Not sure if this is the place that Chris is thinking of, but in my = review I encountered things such as: Blacklist.Node The IP address of the node that did not verify bidirectional connectivity. Which looks like it is assumed that a =E2=80=9Cnode=E2=80=9D (I assume = that this means =E2=80=9Crouter=E2=80=9D and will be fixed in a coming = version, as has been requested multiple times) has a single IP address = (that=E2=80=99s what the use of the definite article implies, is it = not?) Also: AODVv2 supports routers with multiple interfaces, as long as each interface has its own (unicast routeable) IP address =E2=80=9Caddress=E2=80=9D - singular, not plural. There were other instances of such, these were just the first I saw when = glancing over my review. > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@computer.org]=20 > Sent: 21 July 2014 05:45 > To: manet@ietf.org; Dearlove, Christopher (UK); = draft-ietf-manet-aodvv2@tools.ietf.org > Subject: Re: [manet] #48 (aodvv2): Single address per interface per = router (submitted for Chris Dearlove) >=20 > ----------------------! 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. > -------------------------------------------------------- >=20 > Hello Chris, >=20 > AODVv2 does not impose this restriction. It has, for a long time, = enabled multiple router addresses per interface. I will look again, but = as of now I do not see where any such restriction has been imposed. If = you have identified where this restriction is implied or stated = directly, please let me know as soon as possible. >=20 > Unnumbered interfaces have never been suggested as appropriate for = inclusion of the feature set for any reactive protocol that was under = consideration within [manet], all the way since the very initiation of = the working group. At least not within my memory. >=20 > On 7/20/2014 8:46 PM, manet issue tracker wrote: >> #48: Single address per interface per router (submitted for Chris=20 >> Dearlove) >>=20 >> The model is of routers with a single address per interface. In = OLSRv2 >> this wasn't considered acceptable. The authors defined multiple = addresses >> per interface, the WG required supporting unnumbered interfaces = which >> shared addresses. >>=20 >=20 > -- > Regards, > Charlie P. >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_219D4A61-2314-4F4E-AFF5-FA82900EAE24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Jul = 2014, at 14:39 , Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.co= m> wrote:

In at = least one place in the draft (sorry, I don't have the time to find it = again now) it explicitly says one address per = interface.


Not sure if this is = the place that Chris is thinking of, but in my review I encountered = things such as:

 Blacklist.Node
      The IP address of the node that did not verify bidirectional
      connectivity.

Which looks like it is = assumed that a =E2=80=9Cnode=E2=80=9D (I assume that this means = =E2=80=9Crouter=E2=80=9D and will be fixed in a coming version, as has = been requested multiple times) has a single IP address (that=E2=80=99s = what the use of the definite article implies, is it = not?)

Also:

 AODVv2 supports routers =
with
   multiple interfaces, as long as each interface has its own (unicast
   routeable) IP address

=E2=80=9Caddress=E2= =80=9D - singular, not plural.

There were other = instances of such, these were just the first I saw when glancing over my = review.


--
Christopher Dearlove
Senior Principal = Engineer, Information Assurance Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.co= m | http://www.baesystems.com

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


-----Original Message-----
From: Charles E. = Perkins [mailto:charliep@computer.org] =
Sent: 21 July 2014 05:45
To: manet@ietf.org; Dearlove, Christopher = (UK); draft-ietf-manet-ao= dvv2@tools.ietf.org
Subject: Re: [manet] #48 (aodvv2): Single = address per interface per router (submitted for Chris = Dearlove)

----------------------! 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.
--------------------------------------------------------
<= br>Hello Chris,

AODVv2 does not impose this restriction.  It = has, for a long time, enabled multiple router addresses per interface. =  I will look again, but as of now I do not see where any such = restriction has been imposed.  If you have identified where this = restriction is implied or stated directly, please let me know as soon as = possible.

Unnumbered interfaces have never been suggested as = appropriate for inclusion of the feature set for any reactive protocol = that was under consideration within [manet], all the way since the very = initiation of the working group.  At least not within my = memory.

On 7/20/2014 8:46 PM, manet issue tracker = wrote:
#48: Single address per interface = per router (submitted for Chris
Dearlove)

 The model is = of routers with a single address per interface. In OLSRv2
 this = wasn't considered acceptable. The authors defined multiple addresses
=  per interface, the WG required supporting unnumbered interfaces = which
 shared = addresses.


--
Regards,
Charlie = P.

****************************************************************= ****
This email and any attachments are confidential to the = intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor disclose = or
distribute its contents to any other = person.
***************************************************************= *****
_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_219D4A61-2314-4F4E-AFF5-FA82900EAE24-- From nobody Tue Jul 22 06:22:43 2014 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 805CE1B27BF for ; Tue, 22 Jul 2014 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 3KfYTuZfL-YR for ; Tue, 22 Jul 2014 06:22:33 -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 0E4E41B27B5 for ; Tue, 22 Jul 2014 06:22:15 -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 1X9a1F-000676-Ij for manet@ietf.org; Tue, 22 Jul 2014 15:22:13 +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 1X9a1F-0002ak-Eh for manet@ietf.org; Tue, 22 Jul 2014 15:22:13 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Jul 2014 15:22:13 +0200 Message-ID: <53CE657E.70908@fkie.fraunhofer.de> Date: Tue, 22 Jul 2014 15:22:06 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090102000700040300080909" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19211/Tue Jul 22 13:11:01 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: da8eb4258d586be99f3c918cac8a614c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YlBZmuge2rLx_qspgvafL_Bqjwc Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 13:22:40 -0000 --------------ms090102000700040300080909 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/22/2014 03:18 PM, Thomas Heide Clausen wrote: >=20 >> On 22 Jul 2014, at 14:39 , Dearlove, Christopher (UK) >> >= >> wrote: >> >> In at least one place in the draft (sorry, I don't have the time to >> find it again now) it explicitly says one address per interface. >> >=20 > Not sure if this is the place that Chris is thinking of, but in my > review I encountered things such as: >=20 > Blacklist.Node > The IP address of the node that did not verify bidirectional > connectivity. >=20 >=20 > Which looks like it is assumed that a =93node=94 (I assume that this me= ans > =93router=94 and will be fixed in a coming version, as has been request= ed > multiple times) has a single IP address (that=92s what the use of the > definite article implies, is it not?) >=20 > Also: >=20 > AODVv2 supports routers with > multiple interfaces, as long as each interface has its own (unicast > routeable) IP address >=20 >=20 > =93address=94 - singular, not plural. >=20 > There were other instances of such, these were just the first I saw whe= n > glancing over my review. Just a thought, does this mean we cannot run AODVv2 with IPv6 linklocal addresses? In the presence of VLAN interfaces these addresses can be the same for multiple interfaces of the same node. 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 --------------ms090102000700040300080909 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 Fw0xNDA3MjIxMzIyMTJaMCMGCSqGSIb3DQEJBDEWBBRRnzgL/bbRsvb4Q+BXXssEEJqjsTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADA+jTDUeq076DwR5+4dRD+bp3xW7992EjHcUEhj6mk2v EQZli4NybI1REryj9v2lSC61O5w8ADtWYHQjiajmnKVXXtCAlSAub55KwD5sKFvoepu/EITV WJwELgXCqW33BNMw5Exz5DhClfuDPOA5mneB7Pdx0ZKCWw3KfRRHSMIHoVyODpC+blZBHUv8 T4sQMdtHFlOvy34Sf2KQo104n7KAM3O0YyXEOTsobxjopSs++KUztgXppIafQyxOgbTGf3O0 4dIORqqzPqt6JtzD45ZhQK03Euxam3NG56iHtjR8PqhYF5JJraA8YzySgNicIyg8jeZ1+bGf laG+U4idvgAAAAAAAA== --------------ms090102000700040300080909-- From nobody Tue Jul 22 06:42:44 2014 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 6161F1B282F for ; Tue, 22 Jul 2014 06:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 l9SgyMrGyQr0 for ; Tue, 22 Jul 2014 06:42:38 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690351B2816 for ; Tue, 22 Jul 2014 06:42:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 455722408CA; Tue, 22 Jul 2014 06:42:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 10712240952; Tue, 22 Jul 2014 06:42:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCCD030C-8B4C-4669-8516-A3AE535E7931" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 15:42:35 +0200 Message-Id: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/XoT8Mu33TnrTC-tZwy_O3ya29es Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 13:42:42 -0000 --Apple-Mail=_FCCD030C-8B4C-4669-8516-A3AE535E7931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 to this. > On 22 Jul 2014, at 14:38 , Dearlove, Christopher (UK) = wrote: >=20 > It might make more sense to discuss a proposal for inclusion in a WG = draft with the WG first. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@computer.org]=20 > Sent: 21 July 2014 05:41 > To: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; Dearlove, = Christopher (UK) > Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable = (submitted for Chris Dearlove) >=20 > ----------------------! 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. > -------------------------------------------------------- >=20 > Hello Chris, >=20 > I have thought about this for a long time. Finally, after some good = discussion here at the IETF, I have identified a way forward. I will = post it to the list after getting some proper security review for it. >=20 > On 7/20/2014 8:43 PM, manet issue tracker wrote: >> #47: Security approach unacceptable (submitted for Chris Dearlove) >>=20 >> The security approach is unacceptable. The security >> directorate and ADs refused to accept this from OLSRv2. They will >> refuse to accept this from this protocol. Incidentally note that >> references to RFC 6621 should be to RFC 6622, except now to RFC = 7182. >>=20 >=20 > -- > Regards, > Charlie P. >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_FCCD030C-8B4C-4669-8516-A3AE535E7931 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 to = this.

On 22 Jul = 2014, at 14:38 , Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.co= m> wrote:

It might make more sense to discuss a proposal for = inclusion in a WG draft with the WG first.

-- 
Christopher Dearlove
Senior Principal Engineer, = Information Assurance Group
Communications, Networks and Image = Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

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


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@computer.org] 
Sent: 21 July 2014 05:41
To: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; Dearlove, Christopher (UK)
Subject: Re: [manet] #47 = (aodvv2): Security approach unacceptable (submitted for Chris = Dearlove)

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

Hello Chris,

I have thought about this for a long time.  Finally, = after some good discussion here at the IETF, I have identified a way = forward.  I will post it to the list after getting some proper = security review for it.

On 7/20/2014 8:43 PM, manet issue tracker wrote:
#47: Security approach = unacceptable (submitted for Chris Dearlove)

 The security = approach is unacceptable. The security
 directorate and ADs = refused to accept this from OLSRv2. They will
 refuse to accept = this from this protocol. Incidentally note that
 references to = RFC 6621 should be to RFC 6622, except now to RFC = 7182.


--
Regards,
Charlie P.

*************************************************************= *******
This email and any attachments are confidential to the = intended
recipient and may also be privileged. If you are not the = intended
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose nor = disclose or
distribute its contents to any other person.
*************************************************************= *******
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail=_FCCD030C-8B4C-4669-8516-A3AE535E7931-- From nobody Tue Jul 22 06:45:36 2014 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 BA5371B2837 for ; Tue, 22 Jul 2014 06:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 e3tk8HSbeeaG for ; Tue, 22 Jul 2014 06:45:29 -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 5451A1B2817 for ; Tue, 22 Jul 2014 06:45:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="388496430" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 14:45:26 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="65640499" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 14:45:33 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 14:45:33 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen Thread-Topic: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) Thread-Index: AQHPpa4iUwAjyYRRgkWwNjYZ9D92cpusF6uA Date: Tue, 22 Jul 2014 13:45:33 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> In-Reply-To: <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDB2GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/onOP-iPdVmoS-2FiMDtX-9sltqg Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , manet-ads , "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) 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, 22 Jul 2014 13:45:32 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDB2GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, I think there has been some improvement here, but could be improv= ed further. This is at the level of comment I didn't attempt to make, I con= centrated on what I considered the most major issues. IIRC, two TLVs are suggested, one to say "this is A", one to say "this is B= ". It's assumed there are two addresses, and the one that's not A is B, and= vice versal. Better is to have a single TLV with a value for A or B. Why? First, it avo= ids wasting a TLV code point. Second, you can flag A and B with a single mu= ltivalue TLV more efficiently than marking A and B. And it's a good idea to= mark A and B, because that way you can add additional addresses in an exte= nsion, without introducing any problems as to which is A or B with a single= TLV. In addition, the practice we introduced in TLV extensions of having a= null value (255 UNSPECIFIED is what we used) can help there as well. One of those things the authors of 5444 etc. would like to do - when they c= an find some extra hours in a week - is to set out this sort of good practi= ce for 5444 that has been found to be valuable. In this case we have the tw= o principles of (a) always attack a TLV to indicate information, as just do= ing so from a non-TLVed address precludes various extensions, and (b) when = attaching information, null values are good - T:LV extensions discusses why= , a lot comes down to that you can't order for more than one or two TLVs at= once. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] Sent: 22 July 2014 14:08 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodv= v2): RFC 5498 non-compliance (submitted for Chris Dearlove)) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. I am still, with reference to this document, dismayed to see that there rem= ain abundant references to positional information in address blocks in RFC5= 444 messages. As has been pointed out numerous times, this is inappropriate, positional i= nformation cannot be assumed assured and preserved by generic 5444 message = generation and parsing code. The first instance of this offense is in Table= 1 ... This has been requested fixed for years now. When will it be fixed? On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) > wrote: RFC5444 describes a multiplexing process. It is not required purely in its = own terms. But RFC 5498 make it mandatory for any protocol using the port/p= rotocol allocated by that RFC. And the WG has agreed that all routing proto= cols developed have to be able (at least) to use that port/protocol. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 22 July 2014 12:02 To: manet@ietf.org Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for C= hris Dearlove) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. IMHO The problem is that RFC5444 still does not have a multiplexing standar= d in IETF. The way of multiplexing is still just implemented by OLSRv2 expe= rts but I dont find any standard for multiplexing yet. The RFC5498 is not f= or multipexing as I understand it. We already discussed once that multiplex= ing is not specified for all RFC5444 formats because it is general format b= ut RFC5498 is not general. If I am wrong please point me to an RFC. AB On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker > wrote: #45: RFC 5498 non-compliance (submitted for Chris Dearlove) The document is completely noncompliant with the RFC 5444 multiplexing mechanism, mandated by RFC 5498 (on the manet port/protocol). It does many things that are not within its competence. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-manet- charliep@computer.org | aodvv2@tools.ietf= .org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG | Keywords: RFC 5498 Document | -------------------------+------------------------------------------------- Ticket URL: manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDB2GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, I think there h= as been some improvement here, but could be improved further. This is at th= e level of comment I didn’t attempt to make, I concentrated on what I considered the most major issues.

 <= /p>

IIRC, two TLVs are sugges= ted, one to say “this is A”, one to say “this is B”= . It’s assumed there are two addresses, and the one that’s not = A is B, and vice versal.

 <= /p>

Better is to have a singl= e TLV with a  value for A or B. Why? First, it avoids wasting a TLV co= de point. Second, you can flag A and B with a single multivalue TLV more efficiently than marking A and B. And it’s a good idea to m= ark A and B, because that way you can add additional addresses in an extens= ion, without introducing any problems as to which is A or B with a single T= LV. In addition, the practice we introduced in TLV extensions of having a null value (255 UNSPECIFIED is what we used)= can help there as well.

 <= /p>

One of those things the a= uthors of 5444 etc. would like to do – when they can find some extra = hours in a week – is to set out this sort of good practice for 5444 that has been found to be valuable. In this case we have the two prin= ciples of (a) always attack a TLV to indicate information, as just doing so= from a non-TLVed address precludes various extensions, and (b) when attach= ing information, null values are good – T:LV extensions discusses why, a lot comes down to that you c= an’t order for more than one or two TLVs at once.

 <= /p>

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

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

 <= /p>

From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org= ]
Sent: 22 July 2014 14:08
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ad= s
Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #4= 5 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

 

 

*** WARNING ***=

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

I am still, with reference to this document, dismaye= d to see that there remain abundant references to positional information in= address blocks in RFC5444 messages. 

 

As has been pointed out numerous times, this is inap= propriate, positional information cannot be assumed assured and preserved b= y generic 5444 message generation and parsing code. The first instance of t= his offense is in Table 1 ...

 

This has been requested fixed for years now. When wi= ll it be fixed?

 

 

On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK= ) <Chris.Dearlove@baesy= stems.com> wrote:

 

RFC5444 describes a multi= plexing process. It is not required purely in its own terms. But RFC 5498 m= ake it mandatory for any protocol using the port/protocol allocated by that RFC. And the WG has agreed that all routing protocols de= veloped have to be able (at least) to use that port/protocol.

 <= /p>

--

Christopher Dearlove

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

= chris.dearlove@baesystems.com | http://www.bae= systems.com

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

 <= /p>

From: manet [ma= ilto:manet-bounces@ietf.org] On Behalf Of <= /span>Abdussalam Baryun
Sent: 22 July 2014= 12:02
To: manet@ietf.org<= br> Cc: dr= aft-ietf-manet-aodvv2@tools.ietf.org
Subject: Re: [mane= t] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

 

 

*** WARNING ***=

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

IMHO The problem is that RFC5444 still does not have= a multiplexing standard in IETF. The way of multiplexing is still just imp= lemented by OLSRv2 experts but I dont find any standard for multiplexing ye= t. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not spe= cified for all RFC5444 formats because it is general format but RFC5498 is = not general.

 

If I am wrong please point me to an RFC.<= /p>

AB

On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker= <trac+manet@trac.tools.ietf.org> wrote:

#45: RFC 5498 non-compliance (submitted for Chris De= arlove)

 The document is completely noncompliant with the RFC 5444 multiplexin= g
 mechanism, mandated by RFC 5498 (on the manet port/protocol). It does=
 many things that are not within its competence.

--
-------------------------+---------------------------------------------= ----
 Reporter:               |   &= nbsp;  Owner:  draft-ietf-manet-
  charliep@computer.org  |  <= a href=3D"mailto:aodvv2@tools.ietf.org">aodvv2= @tools.ietf.org
     Type:  defect       |    = Status:  new
 Priority:  minor        |  Milestone: Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:  RFC 5= 498
  Document               |
-------------------------+---------------------------------------------= ----

Ticket URL: <https://tools.ietf.org/wg/ma= net/trac/ticket/45>
manet <http://tools.ietf.org/manet/>

_______________________________________________
manet mailing list
manet@ietf.o= rg
<= span style=3D"color:purple">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.
********************************************************************

______________________________________= _________
manet mailing list
manet@i= etf.org
https://www.ietf.org/mailman/listinfo/manet=

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDB2GLKXM0002VGREEN_-- From nobody Tue Jul 22 06:46:21 2014 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 581721B2812 for ; Tue, 22 Jul 2014 06:46:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yuS2oYXKmP6k for ; Tue, 22 Jul 2014 06:46:19 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACBA1B2817 for ; Tue, 22 Jul 2014 06:46:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B98552408CA; Tue, 22 Jul 2014 06:46:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3F9C6240952; Tue, 22 Jul 2014 06:46:14 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: <53CE657E.70908@fkie.fraunhofer.de> Date: Tue, 22 Jul 2014 15:46:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> <53CE657E.70908@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/66XYC_AqBy3YsrF_h3huMHCmRAo Cc: manet@ietf.org Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 13:46:20 -0000 > On 22 Jul 2014, at 15:22 , Henning Rogge = wrote: >=20 > On 07/22/2014 03:18 PM, Thomas Heide Clausen wrote: >>=20 >>> On 22 Jul 2014, at 14:39 , Dearlove, Christopher (UK) >>> > >>> wrote: >>>=20 >>> In at least one place in the draft (sorry, I don't have the time to >>> find it again now) it explicitly says one address per interface. >>>=20 >>=20 >> Not sure if this is the place that Chris is thinking of, but in my >> review I encountered things such as: >>=20 >> Blacklist.Node >> The IP address of the node that did not verify bidirectional >> connectivity. >>=20 >>=20 >> Which looks like it is assumed that a =93node=94 (I assume that this = means >> =93router=94 and will be fixed in a coming version, as has been = requested >> multiple times) has a single IP address (that=92s what the use of the >> definite article implies, is it not?) >>=20 >> Also: >>=20 >> AODVv2 supports routers with >> multiple interfaces, as long as each interface has its own (unicast >> routeable) IP address >>=20 >>=20 >> =93address=94 - singular, not plural. >>=20 >> There were other instances of such, these were just the first I saw = when >> glancing over my review. >=20 > Just a thought, >=20 > does this mean we cannot run AODVv2 with IPv6 linklocal addresses? In > the presence of VLAN interfaces these addresses can be the same for > multiple interfaces of the same node. >=20 That would be my reading of it, yes. I should add that this was one of the arguments that was made for = enabling OLSRv2 to use (in the right context, and with constraints = specified in the document) =93duplicated=94 addresses, unnumbered = interfaces, etc. As Chris indicated, the reactive protocol, as currently designed, = appears less capable than OLSRv2 on this point. I think that with this limitation identified, it should be called out as = one of the aspects narrowing the applicability scope of this protocol, = in the applicability statement. Thomas > Henning Rogge >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 06:50:51 2014 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 EEA361B283E for ; Tue, 22 Jul 2014 06:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 Oeg7SWXrNx4a for ; Tue, 22 Jul 2014 06:50:47 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180A11B284B for ; Tue, 22 Jul 2014 06:50:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="459810152" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 14:50:45 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="58631676" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 14:50:53 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 14:50:52 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen Thread-Topic: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) Thread-Index: AQHPpJZRpGdaQIoNtkqxT42LJQkBP5up4z0AgAInWBD///phgIAAGFbA Date: Tue, 22 Jul 2014 13:50:52 +0000 Message-ID: References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDC9GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0alQwPqywP-4xLeKyVz6pVrRPMs Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 13:50:50 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDC9GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNlY29uZCBvZiB0aGVzZSB3YXMgdGhlIHBvaW50IEkgaGFkIGluIG1pbmQuIFRoZSBmaXJz dCBpcyBhbiBhc3NvY2lhdGVkIGlzc3VlLg0KDQpUaGVyZSBhcmUgdmFyaW91cyBjb21wbGV4aXRp ZXMgaW4gT0xTUnYyIHRoYXQgcmVsYXRlIHRvIGFkZHJlc3Npbmcgb2YgaW50ZXJmYWNlcyAobm90 IHNoYXJlZCBiZXR3ZWVuIHJvdXRlcnMsIGJ1dCBwb3NzaWJseSBzaGFyZWQgYmV0d2VlbiBpbnRl cmZhY2VzKSBhbmQgZ2F0ZXdheXMgKGNhbiBvdmVybGFwIGFuZCBzaGFyZSkuIFdlIHRoaW5rIHdl IGdvdCB0aGVtIHJpZ2h0ICh0aG91Z2ggd2l0aG91dCBhIGZvcm1hbCBwcm9vZiwgc28gaXTigJlz IHBvc3NpYmxlIHdlIG1pc3NlZCBzb21ldGhpbmcg4oCTIEkgdGhpbmsgd2UgY2F1Z2h0IG9uZSBy aWdodCBhdCB0aGUgbGFzdCBwb3N0LUlFU0cgcG9pbnQpLiBCdXQgc29tZSB0b29rIHNvbWUgd29y ay4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVy LCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBh bmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5v bG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUg MjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20+IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lz dGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91 c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gs IEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAx OTk2Njg3DQoNCkZyb206IFRob21hcyBIZWlkZSBDbGF1c2VuIFttYWlsdG86dGhvbWFzQHRob21h c2NsYXVzZW4ub3JnXQ0KU2VudDogMjIgSnVseSAyMDE0IDE0OjE5DQpUbzogRGVhcmxvdmUsIENo cmlzdG9waGVyIChVSykNCkNjOiBDaGFybGVzIFBlcmtpbnM7IG1hbmV0QGlldGYub3JnOyBkcmFm dC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0g IzQ4IChhb2R2djIpOiBTaW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlIHBlciByb3V0ZXIgKHN1 Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0 IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWls IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5l dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQpPbiAyMiBK dWwgMjAxNCwgYXQgMTQ6MzkgLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Q2hyaXMuRGVh cmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOkNocmlzLkRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t Pj4gd3JvdGU6DQoNCkluIGF0IGxlYXN0IG9uZSBwbGFjZSBpbiB0aGUgZHJhZnQgKHNvcnJ5LCBJ IGRvbid0IGhhdmUgdGhlIHRpbWUgdG8gZmluZCBpdCBhZ2FpbiBub3cpIGl0IGV4cGxpY2l0bHkg c2F5cyBvbmUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlLg0KDQpOb3Qgc3VyZSBpZiB0aGlzIGlzIHRo ZSBwbGFjZSB0aGF0IENocmlzIGlzIHRoaW5raW5nIG9mLCBidXQgaW4gbXkgcmV2aWV3IEkgZW5j b3VudGVyZWQgdGhpbmdzIHN1Y2ggYXM6DQoNCg0KIEJsYWNrbGlzdC5Ob2RlDQoNCiAgICAgIFRo ZSBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIHRoYXQgZGlkIG5vdCB2ZXJpZnkgYmlkaXJlY3Rpb25h bA0KDQogICAgICBjb25uZWN0aXZpdHkuDQoNCldoaWNoIGxvb2tzIGxpa2UgaXQgaXMgYXNzdW1l ZCB0aGF0IGEg4oCcbm9kZeKAnSAoSSBhc3N1bWUgdGhhdCB0aGlzIG1lYW5zIOKAnHJvdXRlcuKA nSBhbmQgd2lsbCBiZSBmaXhlZCBpbiBhIGNvbWluZyB2ZXJzaW9uLCBhcyBoYXMgYmVlbiByZXF1 ZXN0ZWQgbXVsdGlwbGUgdGltZXMpIGhhcyBhIHNpbmdsZSBJUCBhZGRyZXNzICh0aGF04oCZcyB3 aGF0IHRoZSB1c2Ugb2YgdGhlIGRlZmluaXRlIGFydGljbGUgaW1wbGllcywgaXMgaXQgbm90PykN Cg0KQWxzbzoNCg0KDQogQU9EVnYyIHN1cHBvcnRzIHJvdXRlcnMgd2l0aA0KDQogICBtdWx0aXBs ZSBpbnRlcmZhY2VzLCBhcyBsb25nIGFzIGVhY2ggaW50ZXJmYWNlIGhhcyBpdHMgb3duICh1bmlj YXN0DQoNCiAgIHJvdXRlYWJsZSkgSVAgYWRkcmVzcw0KDQrigJxhZGRyZXNz4oCdIC0gc2luZ3Vs YXIsIG5vdCBwbHVyYWwuDQoNClRoZXJlIHdlcmUgb3RoZXIgaW5zdGFuY2VzIG9mIHN1Y2gsIHRo ZXNlIHdlcmUganVzdCB0aGUgZmlyc3QgSSBzYXcgd2hlbiBnbGFuY2luZyBvdmVyIG15IHJldmll dy4NCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5l ZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtz IGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNo bm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVs bXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0 NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBT eXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBI b3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3Vn aCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86 IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hhcmxlcyBF LiBQZXJraW5zIFttYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnXQ0KU2VudDogMjEgSnVseSAy MDE0IDA1OjQ1DQpUbzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsgRGVh cmxvdmUsIENocmlzdG9waGVyIChVSyk7IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xzLmll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbbWFuZXRdICM0OCAoYW9kdnYyKTogU2luZ2xlIGFkZHJlc3MgcGVyIGludGVy ZmFjZSBwZXIgcm91dGVyIChzdWJtaXR0ZWQgZm9yIENocmlzIERlYXJsb3ZlKQ0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNh cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh dHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWls cycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3Bp Y2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIZWxsbyBDaHJpcywNCg0KQU9EVnYyIGRvZXMgbm90 IGltcG9zZSB0aGlzIHJlc3RyaWN0aW9uLiAgSXQgaGFzLCBmb3IgYSBsb25nIHRpbWUsIGVuYWJs ZWQgbXVsdGlwbGUgcm91dGVyIGFkZHJlc3NlcyBwZXIgaW50ZXJmYWNlLiAgSSB3aWxsIGxvb2sg YWdhaW4sIGJ1dCBhcyBvZiBub3cgSSBkbyBub3Qgc2VlIHdoZXJlIGFueSBzdWNoIHJlc3RyaWN0 aW9uIGhhcyBiZWVuIGltcG9zZWQuICBJZiB5b3UgaGF2ZSBpZGVudGlmaWVkIHdoZXJlIHRoaXMg cmVzdHJpY3Rpb24gaXMgaW1wbGllZCBvciBzdGF0ZWQgZGlyZWN0bHksIHBsZWFzZSBsZXQgbWUg a25vdyBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpVbm51bWJlcmVkIGludGVyZmFjZXMgaGF2ZSBu ZXZlciBiZWVuIHN1Z2dlc3RlZCBhcyBhcHByb3ByaWF0ZSBmb3IgaW5jbHVzaW9uIG9mIHRoZSBm ZWF0dXJlIHNldCBmb3IgYW55IHJlYWN0aXZlIHByb3RvY29sIHRoYXQgd2FzIHVuZGVyIGNvbnNp ZGVyYXRpb24gd2l0aGluIFttYW5ldF0sIGFsbCB0aGUgd2F5IHNpbmNlIHRoZSB2ZXJ5IGluaXRp YXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBBdCBsZWFzdCBub3Qgd2l0aGluIG15IG1lbW9y eS4NCg0KT24gNy8yMC8yMDE0IDg6NDYgUE0sIG1hbmV0IGlzc3VlIHRyYWNrZXIgd3JvdGU6DQoN CiM0ODogU2luZ2xlIGFkZHJlc3MgcGVyIGludGVyZmFjZSBwZXIgcm91dGVyIChzdWJtaXR0ZWQg Zm9yIENocmlzDQpEZWFybG92ZSkNCg0KIFRoZSBtb2RlbCBpcyBvZiByb3V0ZXJzIHdpdGggYSBz aW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlLiBJbiBPTFNSdjINCiB0aGlzIHdhc24ndCBjb25z aWRlcmVkIGFjY2VwdGFibGUuIFRoZSBhdXRob3JzIGRlZmluZWQgbXVsdGlwbGUgYWRkcmVzc2Vz DQogcGVyIGludGVyZmFjZSwgdGhlIFdHIHJlcXVpcmVkIHN1cHBvcnRpbmcgdW5udW1iZXJlZCBp bnRlcmZhY2VzIHdoaWNoDQogc2hhcmVkIGFkZHJlc3Nlcy4NCg0KLS0NClJlZ2FyZHMsDQpDaGFy bGllIFAuDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQgcGxlYXNl IGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBz aG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ug b3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1h bmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDC9GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNlY29uZCBv ZiB0aGVzZSB3YXMgdGhlIHBvaW50IEkgaGFkIGluIG1pbmQuIFRoZSBmaXJzdCBpcyBhbiBhc3Nv Y2lhdGVkIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIHZhcmlvdXMgY29tcGxleGl0aWVzIGlu IE9MU1J2MiB0aGF0IHJlbGF0ZSB0byBhZGRyZXNzaW5nIG9mIGludGVyZmFjZXMgKG5vdCBzaGFy ZWQgYmV0d2VlbiByb3V0ZXJzLCBidXQgcG9zc2libHkgc2hhcmVkIGJldHdlZW4gaW50ZXJmYWNl cykgYW5kIGdhdGV3YXlzDQogKGNhbiBvdmVybGFwIGFuZCBzaGFyZSkuIFdlIHRoaW5rIHdlIGdv dCB0aGVtIHJpZ2h0ICh0aG91Z2ggd2l0aG91dCBhIGZvcm1hbCBwcm9vZiwgc28gaXTigJlzIHBv c3NpYmxlIHdlIG1pc3NlZCBzb21ldGhpbmcg4oCTIEkgdGhpbmsgd2UgY2F1Z2h0IG9uZSByaWdo dCBhdCB0aGUgbGFzdCBwb3N0LUlFU0cgcG9pbnQpLiBCdXQgc29tZSB0b29rIHNvbWUgd29yay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdG9w aGVyIERlYXJsb3ZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3Vy YW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlz aXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJl PGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBD TTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4 OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4NCiB8IGh0dHA6Ly93 d3cuYmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sg SG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91 Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg V2FsZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gVGhvbWFzIEhlaWRlIENsYXVzZW4gW21haWx0bzp0aG9tYXNAdGhvbWFz Y2xhdXNlbi5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjIgSnVseSAyMDE0IDE0OjE5PGJyPg0K PGI+VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gQ2hh cmxlcyBQZXJraW5zOyBtYW5ldEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djJAdG9v bHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gIzQ4IChhb2R2djIp OiBTaW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlIHBlciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3Ig Q2hyaXMgRGVhcmxvdmUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286 cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48 L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxi cj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48 L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+ DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl bWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk JTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlz IHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgSnVsIDIwMTQsIGF0IDE0OjM5ICwgRGVh cmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpDaHJpcy5EZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbSI+Q2hyaXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5JbiBhdCBsZWFzdCBvbmUgcGxhY2UgaW4gdGhlIGRyYWZ0IChzb3Jy eSwgSSBkb24ndCBoYXZlIHRoZSB0aW1lIHRvIGZpbmQgaXQgYWdhaW4gbm93KSBpdCBleHBsaWNp dGx5IHNheXMgb25lIGFkZHJlc3MgcGVyIGludGVyZmFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc3VyZSBpZiB0aGlz IGlzIHRoZSBwbGFjZSB0aGF0IENocmlzIGlzIHRoaW5raW5nIG9mLCBidXQgaW4gbXkgcmV2aWV3 IEkgZW5jb3VudGVyZWQgdGhpbmdzIHN1Y2ggYXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiBCbGFja2xpc3QuTm9kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBJUCBhZGRy ZXNzIG9mIHRoZSBub2RlIHRoYXQgZGlkIG5vdCB2ZXJpZnkgYmlkaXJlY3Rpb25hbDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbm5lY3Rpdml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoaWNoIGxvb2tzIGxpa2UgaXQgaXMgYXNzdW1lZCB0aGF0IGEg4oCc bm9kZeKAnSAoSSBhc3N1bWUgdGhhdCB0aGlzIG1lYW5zIOKAnHJvdXRlcuKAnSBhbmQgd2lsbCBi ZSBmaXhlZCBpbiBhIGNvbWluZyB2ZXJzaW9uLCBhcyBoYXMgYmVlbiByZXF1ZXN0ZWQgbXVsdGlw bGUgdGltZXMpIGhhcyBhIHNpbmdsZSBJUCBhZGRyZXNzICh0aGF04oCZcyB3aGF0IHRoZSB1c2Ug b2YgdGhlIGRlZmluaXRlIGFydGljbGUgaW1wbGllcywgaXMNCiBpdCBub3Q/KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4gQU9EVnYyIHN1cHBvcnRzIHJv dXRlcnMgd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7IG11bHRpcGxlIGludGVyZmFjZXMsIGFzIGxvbmcgYXMgZWFjaCBpbnRlcmZhY2UgaGFzIGl0 cyBvd24gKHVuaWNhc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OyZuYnNwOyByb3V0ZWFibGUpIElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcYWRkcmVzc+KAnSAtIHNpbmd1 bGFyLCBub3QgcGx1cmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVyZSB3ZXJlIG90aGVyIGluc3RhbmNlcyBvZiBzdWNoLCB0aGVzZSB3 ZXJlIGp1c3QgdGhlIGZpcnN0IEkgc2F3IHdoZW4gZ2xhbmNpbmcgb3ZlciBteSByZXZpZXcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSA8YnI+DQpDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5l ZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25zLCBOZXR3 b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFu Y2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQg QmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0 MjE5NCZuYnNwO3wgJm5ic3A7RmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTwvYT4gfA0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbSI+aHR0 cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8YnI+DQpCQUUgU3lzdGVtcyAoT3BlcmF0 aW9ucykgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBC b3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywg R1UxNCA2WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAx OTk2Njg3PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBDaGFybGVzIEUuIFBlcmtpbnMgWzxhIGhyZWY9Im1haWx0bzpjaGFybGllcEBjb21wdXRl ci5vcmciPm1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmc8L2E+XQ0KPGJyPg0KU2VudDogMjEg SnVseSAyMDE0IDA1OjQ1PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+ bWFuZXRAaWV0Zi5vcmc8L2E+OyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsNCjxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0 Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFttYW5l dF0gIzQ4IChhb2R2djIpOiBTaW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlIHBlciByb3V0ZXIg KHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9y aWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4 dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1 bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFj aG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWls cycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3Bp Y2lvdXMgZW1haWwgbWVzc2FnZXMuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpIZWxsbyBDaHJpcyw8YnI+DQo8 YnI+DQpBT0RWdjIgZG9lcyBub3QgaW1wb3NlIHRoaXMgcmVzdHJpY3Rpb24uICZuYnNwO0l0IGhh cywgZm9yIGEgbG9uZyB0aW1lLCBlbmFibGVkIG11bHRpcGxlIHJvdXRlciBhZGRyZXNzZXMgcGVy IGludGVyZmFjZS4gJm5ic3A7SSB3aWxsIGxvb2sgYWdhaW4sIGJ1dCBhcyBvZiBub3cgSSBkbyBu b3Qgc2VlIHdoZXJlIGFueSBzdWNoIHJlc3RyaWN0aW9uIGhhcyBiZWVuIGltcG9zZWQuICZuYnNw O0lmIHlvdSBoYXZlIGlkZW50aWZpZWQgd2hlcmUgdGhpcyByZXN0cmljdGlvbiBpcw0KIGltcGxp ZWQgb3Igc3RhdGVkIGRpcmVjdGx5LCBwbGVhc2UgbGV0IG1lIGtub3cgYXMgc29vbiBhcyBwb3Nz aWJsZS48YnI+DQo8YnI+DQpVbm51bWJlcmVkIGludGVyZmFjZXMgaGF2ZSBuZXZlciBiZWVuIHN1 Z2dlc3RlZCBhcyBhcHByb3ByaWF0ZSBmb3IgaW5jbHVzaW9uIG9mIHRoZSBmZWF0dXJlIHNldCBm b3IgYW55IHJlYWN0aXZlIHByb3RvY29sIHRoYXQgd2FzIHVuZGVyIGNvbnNpZGVyYXRpb24gd2l0 aGluIFttYW5ldF0sIGFsbCB0aGUgd2F5IHNpbmNlIHRoZSB2ZXJ5IGluaXRpYXRpb24gb2YgdGhl IHdvcmtpbmcgZ3JvdXAuICZuYnNwO0F0IGxlYXN0IG5vdCB3aXRoaW4gbXkgbWVtb3J5Ljxicj4N Cjxicj4NCk9uIDcvMjAvMjAxNCA4OjQ2IFBNLCBtYW5ldCBpc3N1ZSB0cmFja2VyIHdyb3RlOjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij4jNDg6IFNpbmdsZSBhZGRyZXNzIHBlciBpbnRlcmZhY2UgcGVy IHJvdXRlciAoc3VibWl0dGVkIGZvciBDaHJpcw0KPGJyPg0KRGVhcmxvdmUpPGJyPg0KPGJyPg0K Jm5ic3A7VGhlIG1vZGVsIGlzIG9mIHJvdXRlcnMgd2l0aCBhIHNpbmdsZSBhZGRyZXNzIHBlciBp bnRlcmZhY2UuIEluIE9MU1J2Mjxicj4NCiZuYnNwO3RoaXMgd2Fzbid0IGNvbnNpZGVyZWQgYWNj ZXB0YWJsZS4gVGhlIGF1dGhvcnMgZGVmaW5lZCBtdWx0aXBsZSBhZGRyZXNzZXM8YnI+DQombmJz cDtwZXIgaW50ZXJmYWNlLCB0aGUgV0cgcmVxdWlyZWQgc3VwcG9ydGluZyB1bm51bWJlcmVkIGlu dGVyZmFjZXMgd2hpY2g8YnI+DQombmJzcDtzaGFyZWQgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS08YnI+DQpSZWdhcmRzLDxicj4NCkNoYXJs aWUgUC48YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJy Pg0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDC9GLKXM0002VGREEN_-- From nobody Tue Jul 22 06:52:02 2014 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 F2F691ABB2E for ; Tue, 22 Jul 2014 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 oiOohrDf7iFu for ; Tue, 22 Jul 2014 06:51:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151A31B27D3 for ; Tue, 22 Jul 2014 06:51:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EA8FB240961; Tue, 22 Jul 2014 06:51:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A5036240952; Tue, 22 Jul 2014 06:51:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5962EE59-23F8-4424-BEF6-D576535AD89E" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 15:51:43 +0200 Message-Id: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/p1UuWO3gptJwSoTQpaYAzzoVync Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" , manet-ads Subject: Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) 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, 22 Jul 2014 13:51:59 -0000 --Apple-Mail=_5962EE59-23F8-4424-BEF6-D576535AD89E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jul 2014, at 15:45 , Dearlove, Christopher (UK) = wrote: >=20 > Actually, I think there has been some improvement here, but could be = improved further. This is at the level of comment I didn=E2=80=99t = attempt to make, I concentrated on what I considered the most major = issues. Improvement, I agree, but still *quite* far from to the point where = it=E2=80=99s correct. > IIRC, two TLVs are suggested, one to say =E2=80=9Cthis is A=E2=80=9D, = one to say =E2=80=9Cthis is B=E2=80=9D. It=E2=80=99s assumed there are = two addresses, and the one that=E2=80=99s not A is B, and vice versal. > =20 > Better is to have a single TLV with a value for A or B. Why? First, = it avoids wasting a TLV code point. Second, you can flag A and B with a = single multivalue TLV more efficiently than marking A and B. And it=E2=80=99= s a good idea to mark A and B, because that way you can add additional = addresses in an extension, without introducing any problems as to which = is A or B with a single TLV. In addition, the practice we introduced in = TLV extensions of having a null value (255 UNSPECIFIED is what we used) = can help there as well. Yes, and while important, the above is a design detail that is = relatively easy to hammer out, when all else is completed. =20 > One of those things the authors of 5444 etc. would like to do =E2=80=93 = when they can find some extra hours in a week =E2=80=93 is to set out = this sort of good practice for 5444 that has been found to be valuable. = In this case we have the two principles of (a) always attack a TLV to = indicate information, as just doing so from a non-TLVed address = precludes various extensions, and (b) when attaching information, null = values are good =E2=80=93 T:LV extensions discusses why, a lot comes = down to that you can=E2=80=99t order for more than one or two TLVs at = once. Yes, and with the caveat that one of the 5444 authors is trying to find = some hours this week for that, so that may be forthcoming soon. (See, Chris, now you made me go public with this, so I=E2=80=99m kinda = on the hook for producing something=E2=80=A6.) Thomas > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 22 July 2014 14:08 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads > Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 = (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > I am still, with reference to this document, dismayed to see that = there remain abundant references to positional information in address = blocks in RFC5444 messages.=20 > =20 > As has been pointed out numerous times, this is inappropriate, = positional information cannot be assumed assured and preserved by = generic 5444 message generation and parsing code. The first instance of = this offense is in Table 1 ... > =20 > This has been requested fixed for years now. When will it be fixed? > =20 > =20 > On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) = wrote: > =20 > RFC5444 describes a multiplexing process. It is not required purely in = its own terms. But RFC 5498 make it mandatory for any protocol using the = port/protocol allocated by that RFC. And the WG has agreed that all = routing protocols developed have to be able (at least) to use that = port/protocol. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam = Baryun > Sent: 22 July 2014 12:02 > To: manet@ietf.org > Cc: draft-ietf-manet-aodvv2@tools.ietf.org > Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted = for Chris Dearlove) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > IMHO The problem is that RFC5444 still does not have a multiplexing = standard in IETF. The way of multiplexing is still just implemented by = OLSRv2 experts but I dont find any standard for multiplexing yet. The = RFC5498 is not for multipexing as I understand it. We already discussed = once that multiplexing is not specified for all RFC5444 formats because = it is general format but RFC5498 is not general. > =20 > If I am wrong please point me to an RFC. > AB > On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker = wrote: > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) >=20 > The document is completely noncompliant with the RFC 5444 = multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. >=20 > -- > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-manet- > charliep@computer.org | aodvv2@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: aodvv2 | Version: > Severity: Active WG | Keywords: RFC 5498 > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > 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 --Apple-Mail=_5962EE59-23F8-4424-BEF6-D576535AD89E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Jul = 2014, at 15:45 , Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

Actually, I think there has been some improvement = here, but could be improved further. This is at the level of comment I = didn=E2=80=99t attempt to make, I concentrated on what I considered the = most major = issues.

Improveme= nt, I agree, but still *quite* far from to the point where it=E2=80=99s = correct.

IIRC, two TLVs are suggested, one to say =E2=80=9Cthis = is A=E2=80=9D, one to say =E2=80=9Cthis is B=E2=80=9D. It=E2=80=99s = assumed there are two addresses, and the one that=E2=80=99s not A is B, = and vice versal.
 
Better is to have a single TLV with a  value for = A or B. Why? First, it avoids wasting a TLV code point. Second, you can = flag A and B with a single multivalue TLV more efficiently than marking = A and B. And it=E2=80=99s a good idea to mark A and B, because that way = you can add additional addresses in an extension, without introducing = any problems as to which is A or B with a single TLV. In addition, the = practice we introduced in TLV extensions of having a null value (255 = UNSPECIFIED is what we used) can help there as = well.

Yes, and while = important, the above is a design detail that is relatively easy to = hammer out, when all else is completed.
 
One of those things the authors of 5444 etc. would = like to do =E2=80=93 when they can find some extra hours in a week =E2=80=93= is to set out this sort of good practice for 5444 that has been found = to be valuable. In this case we have the two principles of (a) always = attack a TLV to indicate information, as just doing so from a non-TLVed = address precludes various extensions, and (b) when attaching = information, null values are good =E2=80=93 T:LV extensions discusses = why, a lot comes down to that you can=E2=80=99t order for more than one = or two TLVs at once.

Yes, and with the caveat = that one of the 5444 authors is trying to find some hours this week for = that, so that may be forthcoming soon.

(See, = Chris, now you made me go public with this, so I=E2=80=99m kinda on the = hook for producing = something=E2=80=A6.)

Thomas

 
--
Christopher = Dearlove
Senior Principal Engineer, Information Assurance = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] 
Sent: 22 July 2014 = 14:08
To: Dearlove, Christopher = (UK)
Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; = manet-ads
Subject: Not just 5498 but also 5444 = compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance = (submitted for Chris Dearlove))
 
 
*** = WARNING ***

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

I am = still, with reference to this document, dismayed to see that there = remain abundant references to positional information in address blocks = in RFC5444 messages. 
 
As = has been pointed out numerous times, this is inappropriate, positional = information cannot be assumed assured and preserved by generic 5444 = message generation and parsing code. The first instance of this offense = is in Table 1 ...
 
This = has been requested fixed for years now. When will it be = fixed?
 
 
On 22 Jul 2014, = at 14:24 , Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> = wrote:
 
RFC5444 describes a multiplexing process. It is not = required purely in its own terms. But RFC 5498 make it mandatory for any = protocol using the port/protocol allocated by that RFC. And the WG has = agreed that all routing protocols developed have to be able (at least) = to use that port/protocol.
 
--
Christopher = Dearlove
Senior Principal Engineer, Information Assurance = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems = (Operations) Limited
Registered Office: Warwick House, PO Box 87, = Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, = UK
Registered in England & Wales No: = 1996687
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam = Baryun
Sent: 22 July 2014 = 12:02
To: manet@ietf.org
Cc: draft-ietf-manet-aodvv2@tools.ietf.org
Subject:<= /b> Re: [manet] #45 = (aodvv2): RFC 5498 non-compliance (submitted for Chris = Dearlove)
 
 
*** WARNING ***

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

=
IMHO The problem is that RFC5444 = still does not have a multiplexing standard in IETF. The way of = multiplexing is still just implemented by OLSRv2 experts but I dont find = any standard for multiplexing yet. The RFC5498 is not for multipexing as = I understand it. We already discussed once that multiplexing is not = specified for all RFC5444 formats because it is general format but = RFC5498 is not general.
 
If I = am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker = <trac+manet@trac.tools.ietf.org> = wrote:
#45: = RFC 5498 non-compliance (submitted for Chris Dearlove)

 The = document is completely noncompliant with the RFC 5444 = multiplexing
 mechanism, mandated by RFC 5498 (on the manet = port/protocol). It does
 many things that are not within its = competence.

--
-------------------------+-----------------------= --------------------------
 Reporter:       =         |      Owner: =  draft-ietf-manet-
  charliep@computer.org  |  aodvv2@tools.ietf.org
     Type: =  defect       |     Status: =  new
 Priority:  minor        | =  Milestone:
Component:  aodvv2       | =    Version:
 Severity:  Active WG    | =   Keywords:  RFC 5498
  Document       =         = |
-------------------------+-------------------------------------------= ------

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45>
= manet <http://tools.ietf.org/manet/>

______________= _________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet=
 

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

_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet=
 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail=_5962EE59-23F8-4424-BEF6-D576535AD89E-- From nobody Tue Jul 22 06:56:33 2014 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 80A731B2858 for ; Tue, 22 Jul 2014 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=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 eNMtFBCjTCA6 for ; Tue, 22 Jul 2014 06:56:22 -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 0A5C71ABB2F for ; Tue, 22 Jul 2014 06:56:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="388500732" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 14:56:19 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="65642878" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 14:56:26 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 14:56:26 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen Thread-Topic: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) Thread-Index: AQHPpbQbhFyS/YWVCkeq01fmYC5UcpusHQOg Date: Tue, 22 Jul 2014 13:56:26 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDF2GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZrzrCNNPgv0C0i2tnq4kN6om_5w Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" , manet-ads Subject: Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) 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, 22 Jul 2014 13:56:25 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDF2GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZeKAmXZlIHNhaWQgc29tZXRoaW5nIGxpa2UgdGhhdCBiZWZvcmUuDQoNCkJ1dCBq dXN0IHRvIG1ha2UgVGhvbWFz4oCZcyB3b3JrbG9hZCBldmVuIGdyZWF0ZXIsIHRoZXJlIGFyZSBt YW55IGRldGFpbHMgb2YgNTQ0NCwgTkhEUCBhbmQgT0xTUlYyIHRoYXQgdGhlIGF1dGhvcnMgd291 bGQgbGlrZSB0byBwcm92aWRlIHJhdGlvbmFsZSBtYXRlcmlhbCBmb3IuIFdl4oCZdmUgZG9uZSBp dCBvbmNlLCBmb3IgbWV0cmljcy4gQnV0IGl0IHJlYWxseSBpcyBzb21ldGhpbmcgdGhhdOKAmXMg aGFyZCB0byBmaW5kIHRpbWUgdG8gZG8sIGJlY2F1c2UgaXTigJlzIGp1c3QgYSBnb29kIGlkZWEs IHJhdGhlciB0aGFuIGJlaW5nIGVzc2VudGlhbC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3Zl DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXAN CkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0K QkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxk IFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEy NDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHwgaHR0cDovL3d3 dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVn aXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVy b3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZyb206IFRob21hcyBIZWlkZSBD bGF1c2VuIFttYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnXQ0KU2VudDogMjIgSnVseSAy MDE0IDE0OjUyDQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBkcmFmdC1pZXRm LW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZzsgbWFuZXQtYWRzOyBtYW5ldEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFttYW5ldF0gTm90IGp1c3QgNTQ5OCBidXQgYWxzbyA1NDQ0IGNvbXBsaWFu Y2UgKHdhczogUmU6ICM0NSAoYW9kdnYyKTogUkZDIDU0OTggbm9uLWNvbXBsaWFuY2UgKHN1Ym1p dHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9t IGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5 b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBp cyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQu ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50 cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCg0KT24gMjIgSnVs IDIwMTQsIGF0IDE1OjQ1ICwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+ IHdyb3RlOg0KDQpBY3R1YWxseSwgSSB0aGluayB0aGVyZSBoYXMgYmVlbiBzb21lIGltcHJvdmVt ZW50IGhlcmUsIGJ1dCBjb3VsZCBiZSBpbXByb3ZlZCBmdXJ0aGVyLiBUaGlzIGlzIGF0IHRoZSBs ZXZlbCBvZiBjb21tZW50IEkgZGlkbuKAmXQgYXR0ZW1wdCB0byBtYWtlLCBJIGNvbmNlbnRyYXRl ZCBvbiB3aGF0IEkgY29uc2lkZXJlZCB0aGUgbW9zdCBtYWpvciBpc3N1ZXMuDQoNCkltcHJvdmVt ZW50LCBJIGFncmVlLCBidXQgc3RpbGwgKnF1aXRlKiBmYXIgZnJvbSB0byB0aGUgcG9pbnQgd2hl cmUgaXTigJlzIGNvcnJlY3QuDQoNCklJUkMsIHR3byBUTFZzIGFyZSBzdWdnZXN0ZWQsIG9uZSB0 byBzYXkg4oCcdGhpcyBpcyBB4oCdLCBvbmUgdG8gc2F5IOKAnHRoaXMgaXMgQuKAnS4gSXTigJlz IGFzc3VtZWQgdGhlcmUgYXJlIHR3byBhZGRyZXNzZXMsIGFuZCB0aGUgb25lIHRoYXTigJlzIG5v dCBBIGlzIEIsIGFuZCB2aWNlIHZlcnNhbC4NCg0KQmV0dGVyIGlzIHRvIGhhdmUgYSBzaW5nbGUg VExWIHdpdGggYSAgdmFsdWUgZm9yIEEgb3IgQi4gV2h5PyBGaXJzdCwgaXQgYXZvaWRzIHdhc3Rp bmcgYSBUTFYgY29kZSBwb2ludC4gU2Vjb25kLCB5b3UgY2FuIGZsYWcgQSBhbmQgQiB3aXRoIGEg c2luZ2xlIG11bHRpdmFsdWUgVExWIG1vcmUgZWZmaWNpZW50bHkgdGhhbiBtYXJraW5nIEEgYW5k IEIuIEFuZCBpdOKAmXMgYSBnb29kIGlkZWEgdG8gbWFyayBBIGFuZCBCLCBiZWNhdXNlIHRoYXQg d2F5IHlvdSBjYW4gYWRkIGFkZGl0aW9uYWwgYWRkcmVzc2VzIGluIGFuIGV4dGVuc2lvbiwgd2l0 aG91dCBpbnRyb2R1Y2luZyBhbnkgcHJvYmxlbXMgYXMgdG8gd2hpY2ggaXMgQSBvciBCIHdpdGgg YSBzaW5nbGUgVExWLiBJbiBhZGRpdGlvbiwgdGhlIHByYWN0aWNlIHdlIGludHJvZHVjZWQgaW4g VExWIGV4dGVuc2lvbnMgb2YgaGF2aW5nIGEgbnVsbCB2YWx1ZSAoMjU1IFVOU1BFQ0lGSUVEIGlz IHdoYXQgd2UgdXNlZCkgY2FuIGhlbHAgdGhlcmUgYXMgd2VsbC4NCg0KWWVzLCBhbmQgd2hpbGUg aW1wb3J0YW50LCB0aGUgYWJvdmUgaXMgYSBkZXNpZ24gZGV0YWlsIHRoYXQgaXMgcmVsYXRpdmVs eSBlYXN5IHRvIGhhbW1lciBvdXQsIHdoZW4gYWxsIGVsc2UgaXMgY29tcGxldGVkLg0KDQoNCk9u ZSBvZiB0aG9zZSB0aGluZ3MgdGhlIGF1dGhvcnMgb2YgNTQ0NCBldGMuIHdvdWxkIGxpa2UgdG8g ZG8g4oCTIHdoZW4gdGhleSBjYW4gZmluZCBzb21lIGV4dHJhIGhvdXJzIGluIGEgd2VlayDigJMg aXMgdG8gc2V0IG91dCB0aGlzIHNvcnQgb2YgZ29vZCBwcmFjdGljZSBmb3IgNTQ0NCB0aGF0IGhh cyBiZWVuIGZvdW5kIHRvIGJlIHZhbHVhYmxlLiBJbiB0aGlzIGNhc2Ugd2UgaGF2ZSB0aGUgdHdv IHByaW5jaXBsZXMgb2YgKGEpIGFsd2F5cyBhdHRhY2sgYSBUTFYgdG8gaW5kaWNhdGUgaW5mb3Jt YXRpb24sIGFzIGp1c3QgZG9pbmcgc28gZnJvbSBhIG5vbi1UTFZlZCBhZGRyZXNzIHByZWNsdWRl cyB2YXJpb3VzIGV4dGVuc2lvbnMsIGFuZCAoYikgd2hlbiBhdHRhY2hpbmcgaW5mb3JtYXRpb24s IG51bGwgdmFsdWVzIGFyZSBnb29kIOKAkyBUOkxWIGV4dGVuc2lvbnMgZGlzY3Vzc2VzIHdoeSwg YSBsb3QgY29tZXMgZG93biB0byB0aGF0IHlvdSBjYW7igJl0IG9yZGVyIGZvciBtb3JlIHRoYW4g b25lIG9yIHR3byBUTFZzIGF0IG9uY2UuDQoNClllcywgYW5kIHdpdGggdGhlIGNhdmVhdCB0aGF0 IG9uZSBvZiB0aGUgNTQ0NCBhdXRob3JzIGlzIHRyeWluZyB0byBmaW5kIHNvbWUgaG91cnMgdGhp cyB3ZWVrIGZvciB0aGF0LCBzbyB0aGF0IG1heSBiZSBmb3J0aGNvbWluZyBzb29uLg0KDQooU2Vl LCBDaHJpcywgbm93IHlvdSBtYWRlIG1lIGdvIHB1YmxpYyB3aXRoIHRoaXMsIHNvIEnigJltIGtp bmRhIG9uIHRoZSBob29rIGZvciBwcm9kdWNpbmcgc29tZXRoaW5n4oCmLikNCg0KVGhvbWFzDQoN Cg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIs IEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFu ZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9s b2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAy NDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tPGh0dHA6Ly93d3cu YmFlc3lzdGVtcy5jb20vPg0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVn aXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVy b3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZyb206IFRob21hcyBIZWlkZSBD bGF1c2VuIFttYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnXQ0KU2VudDogMjIgSnVseSAy MDE0IDE0OjA4DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBtYW5ldEBpZXRm Lm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29s cy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc+ OyBtYW5ldC1hZHMNClN1YmplY3Q6IE5vdCBqdXN0IDU0OTggYnV0IGFsc28gNTQ0NCBjb21wbGlh bmNlICh3YXM6IFJlOiBbbWFuZXRdICM0NSAoYW9kdnYyKTogUkZDIDU0OTggbm9uLWNvbXBsaWFu Y2UgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0K VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIg Y2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55 IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxh Z3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNr IGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRo ZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkkg YW0gc3RpbGwsIHdpdGggcmVmZXJlbmNlIHRvIHRoaXMgZG9jdW1lbnQsIGRpc21heWVkIHRvIHNl ZSB0aGF0IHRoZXJlIHJlbWFpbiBhYnVuZGFudCByZWZlcmVuY2VzIHRvIHBvc2l0aW9uYWwgaW5m b3JtYXRpb24gaW4gYWRkcmVzcyBibG9ja3MgaW4gUkZDNTQ0NCBtZXNzYWdlcy4NCg0KQXMgaGFz IGJlZW4gcG9pbnRlZCBvdXQgbnVtZXJvdXMgdGltZXMsIHRoaXMgaXMgaW5hcHByb3ByaWF0ZSwg cG9zaXRpb25hbCBpbmZvcm1hdGlvbiBjYW5ub3QgYmUgYXNzdW1lZCBhc3N1cmVkIGFuZCBwcmVz ZXJ2ZWQgYnkgZ2VuZXJpYyA1NDQ0IG1lc3NhZ2UgZ2VuZXJhdGlvbiBhbmQgcGFyc2luZyBjb2Rl LiBUaGUgZmlyc3QgaW5zdGFuY2Ugb2YgdGhpcyBvZmZlbnNlIGlzIGluIFRhYmxlIDEgLi4uDQoN ClRoaXMgaGFzIGJlZW4gcmVxdWVzdGVkIGZpeGVkIGZvciB5ZWFycyBub3cuIFdoZW4gd2lsbCBp dCBiZSBmaXhlZD8NCg0KDQpPbiAyMiBKdWwgMjAxNCwgYXQgMTQ6MjQgLCBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKSA8Q2hyaXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOkNocmlz LkRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNClJGQzU0NDQgZGVzY3JpYmVzIGEg bXVsdGlwbGV4aW5nIHByb2Nlc3MuIEl0IGlzIG5vdCByZXF1aXJlZCBwdXJlbHkgaW4gaXRzIG93 biB0ZXJtcy4gQnV0IFJGQyA1NDk4IG1ha2UgaXQgbWFuZGF0b3J5IGZvciBhbnkgcHJvdG9jb2wg dXNpbmcgdGhlIHBvcnQvcHJvdG9jb2wgYWxsb2NhdGVkIGJ5IHRoYXQgUkZDLiBBbmQgdGhlIFdH IGhhcyBhZ3JlZWQgdGhhdCBhbGwgcm91dGluZyBwcm90b2NvbHMgZGV2ZWxvcGVkIGhhdmUgdG8g YmUgYWJsZSAoYXQgbGVhc3QpIHRvIHVzZSB0aGF0IHBvcnQvcHJvdG9jb2wuDQoNCi0tDQpDaHJp c3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24g QXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5 c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpX ZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4s IFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv bS8+DQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmlj ZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJl LCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5k ICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWJkdXNzYWxhbSBCYXJ5dW4NClNlbnQ6IDIyIEp1bHkg MjAxNCAxMjowMg0KVG86IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCkNj OiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21hbmV0XSAjNDUg KGFvZHZ2Mik6IFJGQyA1NDk4IG5vbi1jb21wbGlhbmNlIChzdWJtaXR0ZWQgZm9yIENocmlzIERl YXJsb3ZlKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu ZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9y IGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5i YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk JTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh c2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUy MFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCklNSE8gVGhlIHByb2JsZW0gaXMgdGhhdCBSRkM1 NDQ0IHN0aWxsIGRvZXMgbm90IGhhdmUgYSBtdWx0aXBsZXhpbmcgc3RhbmRhcmQgaW4gSUVURi4g VGhlIHdheSBvZiBtdWx0aXBsZXhpbmcgaXMgc3RpbGwganVzdCBpbXBsZW1lbnRlZCBieSBPTFNS djIgZXhwZXJ0cyBidXQgSSBkb250IGZpbmQgYW55IHN0YW5kYXJkIGZvciBtdWx0aXBsZXhpbmcg eWV0LiBUaGUgUkZDNTQ5OCBpcyBub3QgZm9yIG11bHRpcGV4aW5nIGFzIEkgdW5kZXJzdGFuZCBp dC4gV2UgYWxyZWFkeSBkaXNjdXNzZWQgb25jZSB0aGF0IG11bHRpcGxleGluZyBpcyBub3Qgc3Bl Y2lmaWVkIGZvciBhbGwgUkZDNTQ0NCBmb3JtYXRzIGJlY2F1c2UgaXQgaXMgZ2VuZXJhbCBmb3Jt YXQgYnV0IFJGQzU0OTggaXMgbm90IGdlbmVyYWwuDQoNCklmIEkgYW0gd3JvbmcgcGxlYXNlIHBv aW50IG1lIHRvIGFuIFJGQy4NCkFCDQpPbiBNb24sIEp1bCAyMSwgMjAxNCBhdCA1OjQwIEFNLCBt YW5ldCBpc3N1ZSB0cmFja2VyIDx0cmFjK21hbmV0QHRyYWMudG9vbHMuaWV0Zi5vcmc8bWFpbHRv OnRyYWMrbWFuZXRAdHJhYy50b29scy5pZXRmLm9yZz4+IHdyb3RlOg0KIzQ1OiBSRkMgNTQ5OCBu b24tY29tcGxpYW5jZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSkNCg0KIFRoZSBkb2N1 bWVudCBpcyBjb21wbGV0ZWx5IG5vbmNvbXBsaWFudCB3aXRoIHRoZSBSRkMgNTQ0NCBtdWx0aXBs ZXhpbmcNCiBtZWNoYW5pc20sIG1hbmRhdGVkIGJ5IFJGQyA1NDk4IChvbiB0aGUgbWFuZXQgcG9y dC9wcm90b2NvbCkuIEl0IGRvZXMNCiBtYW55IHRoaW5ncyB0aGF0IGFyZSBub3Qgd2l0aGluIGl0 cyBjb21wZXRlbmNlLg0KDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICAgICAg ICAgICAgICAgfCAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1tYW5ldC0NCiAgY2hhcmxpZXBAY29t cHV0ZXIub3JnPG1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmc+ICB8ICBhb2R2djJAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmFvZHZ2MkB0b29scy5pZXRmLm9yZz4NCiAgICAgVHlwZTogIGRlZmVj dCAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICB8ICBN aWxlc3RvbmU6DQpDb21wb25lbnQ6ICBhb2R2djIgICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVy aXR5OiAgQWN0aXZlIFdHICAgIHwgICBLZXl3b3JkczogIFJGQyA1NDk4DQogIERvY3VtZW50ICAg ICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwczov L3Rvb2xzLmlldGYub3JnL3dnL21hbmV0L3RyYWMvdGlja2V0LzQ1Pg0KbWFuZXQgPGh0dHA6Ly90 b29scy5pZXRmLm9yZy9tYW5ldC8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0 bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFz ZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ug c2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3Nl IG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt YW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlz dA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDF2GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRo aW5rIHdl4oCZdmUgc2FpZCBzb21ldGhpbmcgbGlrZSB0aGF0IGJlZm9yZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1 dCBqdXN0IHRvIG1ha2UgVGhvbWFz4oCZcyB3b3JrbG9hZCBldmVuIGdyZWF0ZXIsIHRoZXJlIGFy ZSBtYW55IGRldGFpbHMgb2YgNTQ0NCwgTkhEUCBhbmQgT0xTUlYyIHRoYXQgdGhlIGF1dGhvcnMg d291bGQgbGlrZSB0byBwcm92aWRlIHJhdGlvbmFsZSBtYXRlcmlhbCBmb3IuDQogV2XigJl2ZSBk b25lIGl0IG9uY2UsIGZvciBtZXRyaWNzLiBCdXQgaXQgcmVhbGx5IGlzIHNvbWV0aGluZyB0aGF0 4oCZcyBoYXJkIHRvIGZpbmQgdGltZSB0byBkbywgYmVjYXVzZSBpdOKAmXMganVzdCBhIGdvb2Qg aWRlYSwgcmF0aGVyIHRoYW4gYmVpbmcgZXNzZW50aWFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VuaW9yIFBy aW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwPGJyPg0KQ29tbXVu aWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5PGJyPg0KQkFF IFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQpXZXN0IEhhbm5pbmdmaWVs ZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJyPg0KVGVsOiAm IzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYjNDM7NDQgMTI0NSAyNDIxMjQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb208L3NwYW4+PC9hPg0KIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTxicj4N Cjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0 ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJu Ym9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBV Szxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4NzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaG9tYXMg SGVpZGUgQ2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZ10NCjxicj4NCjxi PlNlbnQ6PC9iPiAyMiBKdWx5IDIwMTQgMTQ6NTI8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBD aHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0 b29scy5pZXRmLm9yZzsgbWFuZXQtYWRzOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW21hbmV0XSBOb3QganVzdCA1NDk4IGJ1dCBhbHNvIDU0NDQgY29tcGxpYW5jZSAo d2FzOiBSZTogIzQ1IChhb2R2djIpOiBSRkMgNTQ5OCBub24tY29tcGxpYW5jZSAoc3VibWl0dGVk IGZvciBDaHJpcyBEZWFybG92ZSkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWdu OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRl cm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNo b3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwv c3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8 L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3Ug ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+ DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgSnVsIDIwMTQsIGF0IDE1OjQ1 ICwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY3R1YWxseSwgSSB0 aGluayB0aGVyZSBoYXMgYmVlbiBzb21lIGltcHJvdmVtZW50IGhlcmUsIGJ1dCBjb3VsZCBiZSBp bXByb3ZlZCBmdXJ0aGVyLiBUaGlzIGlzIGF0IHRoZSBsZXZlbCBvZiBjb21tZW50IEkgZGlkbuKA mXQgYXR0ZW1wdCB0byBtYWtlLCBJIGNvbmNlbnRyYXRlZA0KIG9uIHdoYXQgSSBjb25zaWRlcmVk IHRoZSBtb3N0IG1ham9yIGlzc3Vlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW1wcm92 ZW1lbnQsIEkgYWdyZWUsIGJ1dCBzdGlsbCAqcXVpdGUqIGZhciBmcm9tIHRvIHRoZSBwb2ludCB3 aGVyZSBpdOKAmXMgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SUlSQywgdHdvIFRMVnMgYXJlIHN1Z2dlc3RlZCwgb25lIHRvIHNheSDigJx0aGlzIGlz IEHigJ0sIG9uZSB0byBzYXkg4oCcdGhpcyBpcyBC4oCdLiBJdOKAmXMgYXNzdW1lZCB0aGVyZSBh cmUgdHdvIGFkZHJlc3NlcywgYW5kIHRoZSBvbmUgdGhhdOKAmXMgbm90IEEgaXMgQiwgYW5kIHZp Y2UNCiB2ZXJzYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXR0 ZXIgaXMgdG8gaGF2ZSBhIHNpbmdsZSBUTFYgd2l0aCBhICZuYnNwO3ZhbHVlIGZvciBBIG9yIEIu IFdoeT8gRmlyc3QsIGl0IGF2b2lkcyB3YXN0aW5nIGEgVExWIGNvZGUgcG9pbnQuIFNlY29uZCwg eW91IGNhbiBmbGFnIEEgYW5kIEIgd2l0aCBhIHNpbmdsZSBtdWx0aXZhbHVlDQogVExWIG1vcmUg ZWZmaWNpZW50bHkgdGhhbiBtYXJraW5nIEEgYW5kIEIuIEFuZCBpdOKAmXMgYSBnb29kIGlkZWEg dG8gbWFyayBBIGFuZCBCLCBiZWNhdXNlIHRoYXQgd2F5IHlvdSBjYW4gYWRkIGFkZGl0aW9uYWwg YWRkcmVzc2VzIGluIGFuIGV4dGVuc2lvbiwgd2l0aG91dCBpbnRyb2R1Y2luZyBhbnkgcHJvYmxl bXMgYXMgdG8gd2hpY2ggaXMgQSBvciBCIHdpdGggYSBzaW5nbGUgVExWLiBJbiBhZGRpdGlvbiwg dGhlIHByYWN0aWNlIHdlIGludHJvZHVjZWQNCiBpbiBUTFYgZXh0ZW5zaW9ucyBvZiBoYXZpbmcg YSBudWxsIHZhbHVlICgyNTUgVU5TUEVDSUZJRUQgaXMgd2hhdCB3ZSB1c2VkKSBjYW4gaGVscCB0 aGVyZSBhcyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBhbmQgd2hpbGUgaW1wb3J0YW50 LCB0aGUgYWJvdmUgaXMgYSBkZXNpZ24gZGV0YWlsIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRv IGhhbW1lciBvdXQsIHdoZW4gYWxsIGVsc2UgaXMgY29tcGxldGVkLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgb2YgdGhvc2UgdGhpbmdzIHRoZSBhdXRo b3JzIG9mIDU0NDQgZXRjLiB3b3VsZCBsaWtlIHRvIGRvIOKAkyB3aGVuIHRoZXkgY2FuIGZpbmQg c29tZSBleHRyYSBob3VycyBpbiBhIHdlZWsg4oCTIGlzIHRvIHNldCBvdXQgdGhpcyBzb3J0IG9m IGdvb2QgcHJhY3RpY2UgZm9yDQogNTQ0NCB0aGF0IGhhcyBiZWVuIGZvdW5kIHRvIGJlIHZhbHVh YmxlLiBJbiB0aGlzIGNhc2Ugd2UgaGF2ZSB0aGUgdHdvIHByaW5jaXBsZXMgb2YgKGEpIGFsd2F5 cyBhdHRhY2sgYSBUTFYgdG8gaW5kaWNhdGUgaW5mb3JtYXRpb24sIGFzIGp1c3QgZG9pbmcgc28g ZnJvbSBhIG5vbi1UTFZlZCBhZGRyZXNzIHByZWNsdWRlcyB2YXJpb3VzIGV4dGVuc2lvbnMsIGFu ZCAoYikgd2hlbiBhdHRhY2hpbmcgaW5mb3JtYXRpb24sIG51bGwgdmFsdWVzIGFyZQ0KIGdvb2Qg 4oCTIFQ6TFYgZXh0ZW5zaW9ucyBkaXNjdXNzZXMgd2h5LCBhIGxvdCBjb21lcyBkb3duIHRvIHRo YXQgeW91IGNhbuKAmXQgb3JkZXIgZm9yIG1vcmUgdGhhbiBvbmUgb3IgdHdvIFRMVnMgYXQgb25j ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WWVzLCBhbmQgd2l0aCB0aGUgY2F2ZWF0IHRoYXQgb25lIG9mIHRoZSA1NDQ0IGF1dGhvcnMgaXMg dHJ5aW5nIHRvIGZpbmQgc29tZSBob3VycyB0aGlzIHdlZWsgZm9yIHRoYXQsIHNvIHRoYXQgbWF5 IGJlIGZvcnRoY29taW5nIHNvb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPihTZWUsIENocmlzLCBub3cgeW91IG1hZGUgbWUgZ28gcHVibGlj IHdpdGggdGhpcywgc28gSeKAmW0ga2luZGEgb24gdGhlIGhvb2sgZm9yIHByb2R1Y2luZyBzb21l dGhpbmfigKYuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaG9tYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdG9waGVy IERlYXJsb3ZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNl bmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4N CkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxi cj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5u aW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4N ClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUg MjQyMTI0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhy ZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+fDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tLyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0K QkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTog V2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBG YXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaG9tYXMNCiBIZWlkZSBDbGF1c2Vu IFs8YSBocmVmPSJtYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5tYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4yMiBKdWx5IDIwMTQgMTQ6MDg8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJy Pg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPm1hbmV0QGlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1hbmV0 LWFvZHZ2MkB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZHJhZnQt aWV0Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjsNCiBtYW5ldC1hZHM8 YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+Tm90IGp1c3QgNTQ5OCBidXQgYWxzbyA1NDQ0IGNvbXBsaWFuY2UgKHdhczog UmU6IFttYW5ldF0gIzQ1IChhb2R2djIpOiBSRkMgNTQ5OCBub24tY29tcGxpYW5jZSAoc3VibWl0 dGVkIGZvciBDaHJpcyBEZWFybG92ZSkpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFk ZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3Vu ZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiog V0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlv bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJv bmc+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDs8L3NwYW4+PC9pPjwvc3Bhbj48ZW0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj50aGF0DQogeW91IGNhbiBsb29r IG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljazwvc3Bhbj48L2VtPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzMzMzk3MiI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk JTIwRmxhZ3MucGRmIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4u PC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48 YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBw bGVhc2UgZm9sbG93PC9zcGFuPjwvZW0+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVu dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv RGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+dGhpcw0KIHByb2Nlc3M8L3NwYW4+PC9hPi48L3NwYW4+PC9lbT48L3NwYW4+ PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGFtIHN0aWxsLCB3aXRoIHJlZmVyZW5jZSB0byB0aGlzIGRvY3VtZW50LCBkaXNt YXllZCB0byBzZWUgdGhhdCB0aGVyZSByZW1haW4gYWJ1bmRhbnQgcmVmZXJlbmNlcyB0byBwb3Np dGlvbmFsIGluZm9ybWF0aW9uIGluIGFkZHJlc3MgYmxvY2tzIGluIFJGQzU0NDQgbWVzc2FnZXMu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBoYXMgYmVlbiBwb2ludGVkIG91dCBudW1lcm91 cyB0aW1lcywgdGhpcyBpcyBpbmFwcHJvcHJpYXRlLCBwb3NpdGlvbmFsIGluZm9ybWF0aW9uIGNh bm5vdCBiZSBhc3N1bWVkIGFzc3VyZWQgYW5kIHByZXNlcnZlZCBieSBnZW5lcmljIDU0NDQgbWVz c2FnZSBnZW5lcmF0aW9uIGFuZCBwYXJzaW5nIGNvZGUuIFRoZSBmaXJzdCBpbnN0YW5jZSBvZiB0 aGlzIG9mZmVuc2UgaXMgaW4gVGFibGUgMSAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFz IGJlZW4gcmVxdWVzdGVkIGZpeGVkIGZvciB5ZWFycyBub3cuIFdoZW4gd2lsbCBpdCBiZSBmaXhl ZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIyIEp1bCAyMDE0LCBh dCAxNDoyNCAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86 Q2hyaXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PkNocmlzLkRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJGQzU0NDQgZGVzY3JpYmVzIGEgbXVsdGlwbGV4aW5nIHByb2Nlc3MuIEl0IGlzIG5vdCByZXF1 aXJlZCBwdXJlbHkgaW4gaXRzIG93biB0ZXJtcy4gQnV0IFJGQyA1NDk4IG1ha2UgaXQgbWFuZGF0 b3J5IGZvciBhbnkgcHJvdG9jb2wgdXNpbmcgdGhlIHBvcnQvcHJvdG9jb2wNCiBhbGxvY2F0ZWQg YnkgdGhhdCBSRkMuIEFuZCB0aGUgV0cgaGFzIGFncmVlZCB0aGF0IGFsbCByb3V0aW5nIHByb3Rv Y29scyBkZXZlbG9wZWQgaGF2ZSB0byBiZSBhYmxlIChhdCBsZWFzdCkgdG8gdXNlIHRoYXQgcG9y dC9wcm90b2NvbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdG9waGVyIERlYXJsb3ZlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNl bmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4N CkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxi cj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5u aW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4N ClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUg MjQyMTI0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+fDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tLyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTwvc3Bhbj48 L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdp c3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJv c3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4Nzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYW5ldA0KIFs8YSBocmVmPSJt YWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5BYmR1c3NhbGFtIEJh cnl1bjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj4yMiBKdWx5IDIwMTQgMTI6MDI8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpt YW5ldEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFuZXRAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbWFuZXQtYW9kdnYy QHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kcmFmdC1pZXRmLW1h bmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbbWFu ZXRdICM0NSAoYW9kdnYyKTogUkZDIDU0OTggbm9uLWNvbXBsaWFuY2UgKHN1Ym1pdHRlZCBmb3Ig Q2hyaXMgRGVhcmxvdmUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRp bmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB Uk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVy IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu eSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZv ciBpbmZvcm1hdGlvbiByZWdhcmRpbmc8L3NwYW4+PC9lbT48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25n PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+dGhhdA0KIHlvdSBjYW4gbG9vayBv dXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2s8L3NwYW4+PC9lbT48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUy MEZsYWdzLnBkZiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bhbj48L2E+Ljwv c3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJy Pg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxl YXNlIGZvbGxvdzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQu YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0Rl YWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnRoaXMNCiBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwv aT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JTUhPIFRoZSBwcm9ibGVtIGlzIHRoYXQgUkZDNTQ0NCBzdGls bCBkb2VzIG5vdCBoYXZlIGEgbXVsdGlwbGV4aW5nIHN0YW5kYXJkIGluIElFVEYuIFRoZSB3YXkg b2YgbXVsdGlwbGV4aW5nIGlzIHN0aWxsIGp1c3QgaW1wbGVtZW50ZWQgYnkgT0xTUnYyIGV4cGVy dHMgYnV0IEkgZG9udCBmaW5kIGFueSBzdGFuZGFyZCBmb3IgbXVsdGlwbGV4aW5nIHlldC4gVGhl IFJGQzU0OTggaXMgbm90IGZvciBtdWx0aXBleGluZw0KIGFzIEkgdW5kZXJzdGFuZCBpdC4gV2Ug YWxyZWFkeSBkaXNjdXNzZWQgb25jZSB0aGF0IG11bHRpcGxleGluZyBpcyBub3Qgc3BlY2lmaWVk IGZvciBhbGwgUkZDNTQ0NCBmb3JtYXRzIGJlY2F1c2UgaXQgaXMgZ2VuZXJhbCBmb3JtYXQgYnV0 IFJGQzU0OTggaXMgbm90IGdlbmVyYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIEkg YW0gd3JvbmcgcGxlYXNlIHBvaW50IG1lIHRvIGFuIFJGQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFCPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgNTo0MCBBTSwgbWFuZXQgaXNzdWUgdHJh Y2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRyYWMmIzQzO21hbmV0QHRyYWMudG9vbHMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50cmFjJiM0Mztt YW5ldEB0cmFjLnRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ IzQ1OiBSRkMgNTQ5OCBub24tY29tcGxpYW5jZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92 ZSk8YnI+DQo8YnI+DQombmJzcDtUaGUgZG9jdW1lbnQgaXMgY29tcGxldGVseSBub25jb21wbGlh bnQgd2l0aCB0aGUgUkZDIDU0NDQgbXVsdGlwbGV4aW5nPGJyPg0KJm5ic3A7bWVjaGFuaXNtLCBt YW5kYXRlZCBieSBSRkMgNTQ5OCAob24gdGhlIG1hbmV0IHBvcnQvcHJvdG9jb2wpLiBJdCBkb2Vz PGJyPg0KJm5ic3A7bWFueSB0aGluZ3MgdGhhdCBhcmUgbm90IHdpdGhpbiBpdHMgY29tcGV0ZW5j ZS48YnI+DQo8YnI+DQotLTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQombmJzcDtS ZXBvcnRlcjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDtPd25lcjogJm5ic3A7ZHJhZnQtaWV0Zi1tYW5ldC08YnI+ DQombmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+Y2hhcmxpZXBAY29tcHV0ZXIub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7fCAmbmJzcDs8YSBocmVmPSJt YWlsdG86YW9kdnYyQHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5h b2R2djJAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 VHlwZTogJm5ic3A7ZGVmZWN0ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyBT dGF0dXM6ICZuYnNwO25ldzxicj4NCiZuYnNwO1ByaW9yaXR5OiAmbmJzcDttaW5vciAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO01pbGVzdG9uZTo8YnI+DQpDb21wb25lbnQ6ICZu YnNwO2FvZHZ2MiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDtWZXJzaW9uOjxi cj4NCiZuYnNwO1NldmVyaXR5OiAmbmJzcDtBY3RpdmUgV0cgJm5ic3A7ICZuYnNwO3wgJm5ic3A7 IEtleXdvcmRzOiAmbmJzcDtSRkMgNTQ5ODxicj4NCiZuYnNwOyBEb2N1bWVudCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaWNrZXQgVVJMOiAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy93Zy9tYW5ldC90cmFjL3RpY2tldC80NSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbWFuZXQv dHJhYy90aWNrZXQvNDU8L3NwYW4+PC9hPiZndDs8YnI+DQptYW5ldCAmbHQ7PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL21hbmV0LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9tYW5ldC88L3NwYW4+PC9hPiZndDs8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFuZXRAaWV0Zi5vcmc8L3NwYW4+PC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBz dHlsZT0ib3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJy Pg0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpt YW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu b3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+bWFuZXRAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFu ZXQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPm1hbmV0QGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEDF2GLKXM0002VGREEN_-- From nobody Tue Jul 22 06:56:57 2014 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 84D271A0B0E; Tue, 22 Jul 2014 06:56:38 -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 vyUPFO1Uqe2U; Tue, 22 Jul 2014 06:56:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3037F1B278B; Tue, 22 Jul 2014 06:56:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722135633.15496.7961.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 06:56:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IQZEbzMpGLH8U4jA3_t05KQexQU Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-ibs-00.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: Tue, 22 Jul 2014 13:56:38 -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 : Identity-Based Signatures for MANET Routing Protocols Author : Christopher Dearlove Filename : draft-ietf-manet-ibs-00.txt Pages : 10 Date : 2014-07-22 Abstract: This document extends [RFC7182], which specifies a framework for, and specific examples of, integrity check values (ICVs) for packets and messages using the generalized packet/message format specified in [RFC5444]. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an identity-based signature, defined according to the ECCSI (Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption) algorithm specified in [RFC6507]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-ibs-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 06:59:27 2014 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 E615B1B278D for ; Tue, 22 Jul 2014 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0Wrwt7QFLgZN for ; Tue, 22 Jul 2014 06:59:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C331B278B for ; Tue, 22 Jul 2014 06:59:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 82CB9240952; Tue, 22 Jul 2014 06:59:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C39232408CA; Tue, 22 Jul 2014 06:59:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_98DF5A35-B131-42CD-BAAB-0B481844D3D2" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 15:59:18 +0200 Message-Id: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1qM4x04ep-XdYUP9AW4wtHbrkeo Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , manet-ads , "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) 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, 22 Jul 2014 13:59:26 -0000 --Apple-Mail=_98DF5A35-B131-42CD-BAAB-0B481844D3D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jul 2014, at 15:56 , Dearlove, Christopher (UK) = wrote: >=20 > I think we=E2=80=99ve said something like that before. > =20 > But just to make Thomas=E2=80=99s workload even greater, Oh, sure, I didn=E2=80=99t plan on sleeping, or having a social life, = anyways ;) Thomas --Apple-Mail=_98DF5A35-B131-42CD-BAAB-0B481844D3D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Jul = 2014, at 15:56 , Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

I think we=E2=80=99ve said something like that = before.
 
But just to make Thomas=E2=80=99s workload even = greater,

Oh, = sure, I didn=E2=80=99t plan on sleeping, or having a social life, = anyways ;)

Thomas

= --Apple-Mail=_98DF5A35-B131-42CD-BAAB-0B481844D3D2-- From nobody Tue Jul 22 07:02:03 2014 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 2C1B31B284A; Tue, 22 Jul 2014 07:01:59 -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 Bdcze-5Ajh4C; Tue, 22 Jul 2014 07:01:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6301B286C; Tue, 22 Jul 2014 07:01:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722140153.17288.64601.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 07:01:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xv50LmLPff-d31GC7v9uXZeX3Kw Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 14:01:59 -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-01.txt Pages : 16 Date : 2014-07-22 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 07:05:37 2014 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 2CFB61B27CF for ; Tue, 22 Jul 2014 07:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 0eWYeYrZrDCt for ; Tue, 22 Jul 2014 07:05:30 -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 309861B284A for ; Tue, 22 Jul 2014 07:05:30 -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 1X9ah6-0005ie-NK for manet@ietf.org; Tue, 22 Jul 2014 16:05:28 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X9ah6-0002xQ-JH for manet@ietf.org; Tue, 22 Jul 2014 16:05:28 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Jul 2014 16:05:28 +0200 Message-ID: <53CE6FA4.9010500@fkie.fraunhofer.de> Date: Tue, 22 Jul 2014 16:05:24 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000008060702070603060302" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19211/Tue Jul 22 13:11:01 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: dad17b0fa7a976ea34f8545b3e71195d Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_KQnRFYmFJ3lgMmQ9ZAuR9KyI1I Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 14:05:34 -0000 --------------ms000008060702070603060302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote: >> One of those things the authors of 5444 etc. would like to do =96 when= >> they can find some extra hours in a week =96 is to set out this sort o= f >> good practice for 5444 that has been found to be valuable. In this >> case we have the two principles of (a) always attack a TLV to indicate= >> information, as just doing so from a non-TLVed address precludes >> various extensions, and (b) when attaching information, null values >> are good =96 T:LV extensions discusses why, a lot comes down to that y= ou >> can=92t order for more than one or two TLVs at once. >=20 > Yes, and with the caveat that one of the 5444 authors is trying to find= > some hours this week for that, so that may be forthcoming soon. >=20 > (See, Chris, now you made me go public with this, so I=92m kinda on the= > hook for producing something=85.) I would also be interested in doing this, mostly because a lot of these assumptions (how to do RFC5444) have been put into the design of my RFC5444 parser/generator API. The generator API supports that multiple parts of the program are multiplexing data into the same message, so there is no reliable way to guarantee the position of addresses and TLVs within the message. Documenting these 'best practices' would be helpful for further protocol designers. 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 --------------ms000008060702070603060302 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 Fw0xNDA3MjIxNDA1MjdaMCMGCSqGSIb3DQEJBDEWBBQoEMozXyKeeX6SpzzQYdgIAveZPzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAihVIkd+9+or6uGSLPRhHbBLyDYLiyD+Um7Smbg73vjkb KnDvjsv6Rv32NFXfx3kXby1hwGQeT0+/uLCZ5JCNZs13HvqmPlzDNFPw8h/GxI8phCs1tdrq ZHHf0zQM6dZCFGK+fbAZ+NRwgTglxlKntCR5BonSE3EZBzsLI1FXTk5C/f2ODO6MnvSLMxk3 ZT7UzZDnx6+CPR7MS+43P3GZMclxzVTKO8TmoMoZrl9EIShqQ4G+H3kA/W7TrvlRpHuTNnRg r7NqYHv5c7ZpEn9hwQm6bM2GnCjwvncpH93F3MvoE4NF9U1CLkVjxNHGLeDcWSwbYVjhsBnn u5GUwE8mCAAAAAAAAA== --------------ms000008060702070603060302-- From nobody Tue Jul 22 07:08:52 2014 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 72BD91B2882 for ; Tue, 22 Jul 2014 07:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 v4oS07aNHmel for ; Tue, 22 Jul 2014 07:08:45 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD221B286F for ; Tue, 22 Jul 2014 07:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CC67B240961; Tue, 22 Jul 2014 07:08:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 54646240952; Tue, 22 Jul 2014 07:08:43 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: <53CE6FA4.9010500@fkie.fraunhofer.de> Date: Tue, 22 Jul 2014 16:08:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tgvA9Jkn3TvYSkqt4MdITnC6xe0 Cc: manet@ietf.org Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 14:08:46 -0000 > On 22 Jul 2014, at 16:05 , Henning Rogge = wrote: >=20 > On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote: >>> One of those things the authors of 5444 etc. would like to do =96 = when >>> they can find some extra hours in a week =96 is to set out this sort = of >>> good practice for 5444 that has been found to be valuable. In this >>> case we have the two principles of (a) always attack a TLV to = indicate >>> information, as just doing so from a non-TLVed address precludes >>> various extensions, and (b) when attaching information, null values >>> are good =96 T:LV extensions discusses why, a lot comes down to that = you >>> can=92t order for more than one or two TLVs at once. >>=20 >> Yes, and with the caveat that one of the 5444 authors is trying to = find >> some hours this week for that, so that may be forthcoming soon. >>=20 >> (See, Chris, now you made me go public with this, so I=92m kinda on = the >> hook for producing something=85.) >=20 > I would also be interested in doing this, mostly because a lot of = these > assumptions (how to do RFC5444) have been put into the design of my > RFC5444 parser/generator API. >=20 > The generator API supports that multiple parts of the program are > multiplexing data into the same message, so there is no reliable way = to > guarantee the position of addresses and TLVs within the message. >=20 > Documenting these 'best practices' would be helpful for further = protocol > designers. >=20 Absolutely, and we (well, at least, I) count on looping you in on this = process. Cheers, Thomas > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 07:08:53 2014 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 825E91B286F for ; Tue, 22 Jul 2014 07:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 r-ols2lDnf0t for ; Tue, 22 Jul 2014 07:08:44 -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 2F13F1B285D for ; Tue, 22 Jul 2014 07:08:44 -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 1X9akF-00076w-0m for manet@ietf.org; Tue, 22 Jul 2014 16:08:43 +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 1X9akE-0002z2-Sz for manet@ietf.org; Tue, 22 Jul 2014 16:08:42 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Jul 2014 16:08:42 +0200 Message-ID: <53CE7069.8070305@fkie.fraunhofer.de> Date: Tue, 22 Jul 2014 16:08:41 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> In-Reply-To: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040305020005040203000006" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19211/Tue Jul 22 13:11:01 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c4d5118c678b4c5efdde27bcb7d1073a Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lHogsxeXELEi5n8E2xtd3YriWHg Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 14:08:46 -0000 --------------ms040305020005040203000006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I uploaded an update to my DAT metric draft to the IETF database. The update is a minor one, moving "one bit" of the metric range from the "link speed" to the "packet loss" part, changing the "minimal link speed" to 1000 (instead of 1024) and adding an appendix that talks about my experience with stabilizing the raw linkspeed of an interface. Unless someone finds another problem with the draft I think we should consider going towards WGLC... Henning Rogge -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.txt Date: Tue, 22 Jul 2014 07:01:54 -0700 From: internet-drafts@ietf.org To: Emmanuel Baccelli , Henning Rogge , Emmanuel Baccelli , Henning Rogge A new version of I-D, draft-ietf-manet-olsrv2-dat-metric-01.txt has been successfully submitted by Henning Rogge and posted to the IETF repository. Name: draft-ietf-manet-olsrv2-dat-metric Revision: 01 Title: Packet Sequence Number based directional airtime metric for OLSRv= 2 Document date: 2014-07-22 Group: manet Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-dat-metric-01= =2Etxt Status: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/ Htmlized: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-dat-metric-01 Abstract: This document specifies an directional airtime link metric for usage in OLSRv2. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040305020005040203000006 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 Fw0xNDA3MjIxNDA4NDFaMCMGCSqGSIb3DQEJBDEWBBTYkHco+O5ijS+obR+4OK2Up7GYHDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAo/YOVoxTfkO1h5L8U5Y6Y/34wS5wsPymTImp0372Ap3C fOLc+4WVnbIdA4SS9c8i2DH9/mIOy0sQMZlmWdF2R1jZ4Lj5ZQtCqVZH+omxk2vKWpu+jlSj Hv14XjE2HAiOdpfwQ8odg7k/TJoMYdLKjZJUJMXaMWsB7Te3/p730tmaO1zHH7KmztpEgAeo qplpBUy8PJV7hGbjEkNjiWQ60WkI9d0U7ngjrJI1ZpLvEUtlX5ur0nFBynFndOIsB35SV3HI F8EtwcKd65OZwq2jfcBamcfxYNA5cn9i2LOjpU0zXfjXFFEPBSQOlQ3wXxvTYeunXHnGz8OA jAZPRjTpUgAAAAAAAA== --------------ms040305020005040203000006-- From nobody Tue Jul 22 07:14:13 2014 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 BA3BE1A0107 for ; Tue, 22 Jul 2014 07:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 y7q-zA1-R065 for ; Tue, 22 Jul 2014 07:14:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96E11B28A1 for ; Tue, 22 Jul 2014 07:14:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AA165247325; Tue, 22 Jul 2014 07:14:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 30F2F2408B9; Tue, 22 Jul 2014 07:14:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: <53CE7069.8070305@fkie.fraunhofer.de> Date: Tue, 22 Jul 2014 16:14:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yQzl3z34G1vD9l3VRfp4sB27w3U Cc: "" , "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 14:14:11 -0000 > On 22 Jul 2014, at 16:08 , Henning Rogge = wrote: >=20 > Hi, >=20 > I uploaded an update to my DAT metric draft to the IETF database. >=20 > The update is a minor one, moving "one bit" of the metric range from = the > "link speed" to the "packet loss" part, changing the "minimal link > speed" to 1000 (instead of 1024) and adding an appendix that talks = about > my experience with stabilizing the raw linkspeed of an interface. >=20 > Unless someone finds another problem with the draft I think we should > consider going towards WGLC=E2=80=A6 That=E2=80=99s just awesome.=20 I read the previous version (-00) and had a few nits (and they were just = nits). Didn=E2=80=99t get time to type them up, but will try to do so = this week, and in passing look at the RFCdiff to -01. FWIW, my review resulted only in nits, of the sort that can easily be = folded in during a WGLC.=20 So I vividly encourage that a WGLC be issued for this document. Thomas > Henning Rogge >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-ietf-manet-olsrv2-dat-metric-01.txt > Date: Tue, 22 Jul 2014 07:01:54 -0700 > From: internet-drafts@ietf.org > To: Emmanuel Baccelli , Henning Rogge > , Emmanuel Baccelli > , Henning Rogge > >=20 >=20 > A new version of I-D, draft-ietf-manet-olsrv2-dat-metric-01.txt > has been successfully submitted by Henning Rogge and posted to the > IETF repository. >=20 > Name: draft-ietf-manet-olsrv2-dat-metric > Revision: 01 > Title: Packet Sequence Number based directional airtime = metric for OLSRv2 > Document date: 2014-07-22 > Group: manet > Pages: 16 > URL: > = http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-dat-metric-01.= txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/ > Htmlized: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-dat-metric-01= >=20 > Abstract: > This document specifies an directional airtime link metric for usage > in OLSRv2. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 07:19:09 2014 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 3FF4E1B28BC for ; Tue, 22 Jul 2014 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Zp2V3tHyaNnc for ; Tue, 22 Jul 2014 07:19:02 -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 439EF1A0AD4 for ; Tue, 22 Jul 2014 07:19:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="459825633" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 15:18:59 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="58637834" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 15:19:07 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 15:19:07 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: You help appreciated on IBS draft Thread-Index: Ac+ltwTlX79aqVYDRGW+yQlCmcFqzQ== Date: Tue, 22 Jul 2014 14:19:06 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE47GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2imdUSrW-3PKy-IEcTW0K47FDfo Subject: [manet] You help appreciated on IBS draft 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, 22 Jul 2014 14:19:06 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE47GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I've just done the draft-dearlove-manet-ibs-00 -> draft-ietf-manet-ibs-00 c= onversion, literally just a change of name, not even a comma changed otherw= ise. Both drafts contain a TBD appendix. Actually I have written that appendix. = I'll include part of it below. Why only part? Because the point is first to= create a real message, then second to create a real signature. If you've e= ver implemented something like RFC 6507, the test vectors are invaluable fo= r checking your code. My unpublished full version has the result of the signature, and intermedia= te values before that. But I think a better test than me publishing and som= eone saying "yes I agree" is for one or more people to produce their signat= ure blind for comparison. Of course in the case of a difference, then we ca= n see who is right. Which is why the "or more" is good. Note that you don't need the fully implement the extension to do that, just= implement (or find an implementation of) ECCSI to do that. Of course should someone point out that the message is incorrect, or unsuit= able in some manner before we get to the signature calculation part, or the= re is some other error, then I'll have to re-run my signature again. That's= the one easy part. Obviously there's an acknowledgement on offer, I'm afraid it's the best inc= entive I have. Christopher Appendix A. Example Appendix C of [RFC6130] contains this example of a HELLO message. (Note that normally, a TIMESTAMP ICV would also be added before the ICV TLV, but for simplicity that step has been omitted here.) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO | MF=3D7 | MAL=3D3 | Message Length =3D 45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit =3D 1 | Hop Count =3D 0 | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message TLV Block Length =3D 8 | VALIDITY_TIME | MTLVF =3D 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Len =3D 1 | Value (Time) | INTERVAL_TIME | MTLVF =3D 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Len =3D 1 | Value (Time) | Num Addrs =3D 5 | ABF =3D 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head Len =3D 3 | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid 0 | Mid 1 | Mid 2 | Mid 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid 4 | Address TLV Block Length =3D 14 | LOCAL_IF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATLVF =3D 80 | Index =3D 0 | Value Len =3D 1 | THIS_IF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LINK_STATUS | ATLV =3D 52 | Strt Indx =3D 1 | Stop Indx =3D 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Len =3D 4 | HEARD | HEARD | SYMMETRIC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOST | +-+-+-+-+-+-+-+-+ In order to provide an example of an ECCSI ICV Message TLV that may be added to this message, the fields shown need to all have numerical values, both by inserting defined numerical values (e.g. 0 for HELLO) and by selecting example values where needed. The latter consists of: o The message sequence number will be zero. o The five addresses will be 192.0.2.1 to 192.0.2.5. o The message validity time will be 6 seconds, and the message interval time will be 2 seconds, each encoded with a constant value C =3D 1/1024 seconds, as described in [RFC5497], as referenced from [RFC6130]. In addition, when calculating an ICV, the hop count and hop limit are both set to zero. This results in the message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|0 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1|0 0 1 1 0 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+ Or in hexadecimal form M :=3D 0x 0073002D 00000000 00080110 01640010 01580580 03C00002 01020304 05000E02 05000100 03340104 04020201 00 The ICV TLV that will be added will have cryptographic function ECCSI-ADDR, and hash function SHA-256. This message has no originator address, but it travels a single hop, and its IP source address can be used. This will be assumed to be 192.0.2.0, with an empty , thus the sender's identity will be, in hexadecimal form: ID :=3D 0x C0000200 Parameters for [RFC6507] will thus be n =3D 256, N =3D 32. The same parameters and master key will be used as in Appendix A of [RFC6507], i.e., the elliptic curve P-256, with parameters: p :=3D 0x FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF B :=3D 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B q :=3D 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551 G :=3D 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 KSAK :=3D 0x 12345; KPAK :=3D 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4 The remaining steps to creating a private key for ID use the same "random" value v as Appendix A of [RFC6507] and are: v :=3D 0x 23456; (Values of PVT and HS omitted here.) The remaining steps to creating a signature for M use the same "random" value j as Appendix A of [RFC6507] and are: j :=3D 0x 34567; J :=3D 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB (Remainder giving values of r, HE, s', s and Signature omitted here.) -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE47GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I’ve just done the draft-dearlove-manet-ibs-00= -> draft-ietf-manet-ibs-00 conversion, literally just a change of name,= not even a comma changed otherwise.

 

Both drafts contain a TBD appendix. Actually I have = written that appendix. I’ll include part of it below. Why only part? = Because the point is first to create a real message, then second to create = a real signature. If you’ve ever implemented something like RFC 6507, the test vectors are invaluable for checking your= code.

 

My unpublished full version has the result of the si= gnature, and intermediate values before that. But I think a better test tha= n me publishing and someone saying “yes I agree” is for one or = more people to produce their signature blind for comparison. Of course in the case of a difference, then we can see who is = right. Which is why the “or more” is good.

 

Note that you don’t need the fully implement t= he extension to do that, just implement (or find an implementation of) ECCS= I to do that.

 

Of course should someone point out that the message = is incorrect, or unsuitable in some manner before we get to the signature c= alculation part, or there is some other error, then I’ll have to re-r= un my signature again. That’s the one easy part.

 

Obviously there’s an acknowledgement on offer,= I’m afraid it’s the best incentive I have.

 

Christopher

 

 

Appendix A.  Example

 

   Appendix C of [RFC6130] contains= this example of a HELLO message.

   (Note that normally, a TIMESTAMP= ICV would also be added before the

   ICV TLV, but for simplicity that= step has been omitted here.)

 

      0  &= nbsp;           &nbs= p;    1         = ;          2   =             &nb= sp;   3

      0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |   &= nbsp; HELLO     | MF=3D7  | MAL=3D3 |  &= nbsp;   Message Length =3D 45      |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     | Hop Limit =3D 1 | = Hop Count =3D 0 |    Message Sequence Number  &nbs= p; |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     | Message TLV Block = Length =3D 8  | VALIDITY_TIME |  MTLVF =3D 16   |<= /o:p>

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     | Value Len =3D 1 | = Value (Time)  | INTERVAL_TIME |  MTLVF =3D 16   |<= /o:p>

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     | Value Len =3D 1 | = Value (Time)  | Num Addrs =3D 5 |   ABF =3D 128   = |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     | Head Len =3D 3&nbs= p; |            = ;         Head   &nb= sp;            =       |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |   &= nbsp; Mid 0     |     Mid 1 &n= bsp;   |     Mid 2     |&= nbsp;    Mid 3     |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |   &= nbsp; Mid 4     | Address TLV Block Length =3D 14 |&nbs= p;  LOCAL_IF    |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |  ATLVF =3D 80=    |   Index =3D 0   | Value Len =3D 1 | = ;   THIS_IF    |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |  LINK_STATUS&= nbsp; |   ATLV =3D 52   | Strt Indx =3D 1 | Stop Indx = =3D 4 |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     | Value Len =3D 4 |&= nbsp;    HEARD     |   &n= bsp; HEARD     |   SYMMETRIC   |

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |   &= nbsp; LOST      |

     +-+-+-&#= 43;-+-+-+-+-+

 

   In order to provide an example o= f an ECCSI ICV Message TLV that may

   be added to this message, the fi= elds shown need to all have numerical

   values, both by inserting define= d numerical values (e.g. 0 for HELLO)

   and by selecting example values = where needed.  The latter consists

   of:

 

   o  The message sequence num= ber will be zero.

 

   o  The five addresses will = be 192.0.2.1 to 192.0.2.5.

 

   o  The message validity tim= e will be 6 seconds, and the message

      interval time = will be 2 seconds, each encoded with a constant

      value C =3D 1/= 1024 seconds, as described in [RFC5497], as referenced

      from [RFC6130]= .

 

   In addition, when calculating an= ICV, the hop count and hop limit are

   both set to zero.  This res= ults in the message:

 

      0  &= nbsp;           &nbs= p;    1         = ;          2   =             &nb= sp;   3

      0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 0|0 1= 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 0|0 0= 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 0 0 0= 0 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 1 0 0 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 1|0 1= 1 0 0 1 0 0|0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 1|0 1= 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 1 1|1 1= 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 1|0 0= 0 0 0 0 1 0|0 0 0 0 0 0 1 1|0 0 0 0 0 1 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 1 0 1|0 0= 0 0 0 0 0 0 0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 1 0 1 0 0 0 0|0 0= 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 1 1|0 0= 1 1 0 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 1 0 0|0 0= 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|

     +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

     |0 0 0 0 0 0 0 0|

     +-+-+-&#= 43;-+-+-+-+-+

 

   Or in hexadecimal form

 

      M  &= nbsp;      :=3D 0x 0073002D  00000000  0= 0080110  01640010

       &nb= sp;            =   01580580  03C00002  01020304  05000E02

       &nb= sp;            =   05000100  03340104  04020201  00

 

   The ICV TLV that will be added w= ill have cryptographic function

   ECCSI-ADDR, and hash function SH= A-256.  This message has no

   originator address, but it trave= ls a single hop, and its IP source

   address can be used.  This = will be assumed to be 192.0.2.0, with an

   empty <key-id>, thus the s= ender's identity will be, in hexadecimal

   form:

 

      ID  =       :=3D 0x  C0000200

 

   Parameters for [RFC6507] will th= us be n =3D 256, N =3D 32.  The same

   parameters and master key will b= e used as in Appendix A of [RFC6507],

   i.e., the elliptic curve P-256, = with parameters:

 

      p  &= nbsp;      :=3D 0x  FFFFFFFF 00000001 0000000= 0 00000000

       &nb= sp;            =    00000000 FFFFFFFF FFFFFFFF FFFFFFFF

 

      B  &= nbsp;      :=3D 0x  5AC635D8 AA3A93E7 B3EBBD5= 5 769886BC

       &nb= sp;            =    651D06B0 CC53B0F6 3BCE3C3E 27D2604B

 

      q  &= nbsp;      :=3D 0x  FFFFFFFF 00000000 FFFFFFF= F FFFFFFFF

       &nb= sp;            =    BCE6FAAD A7179E84 F3B9CAC2 FC632551

 

      G  &= nbsp;      :=3D 0x  04

       &nb= sp;            =    6B17D1F2 E12C4247 F8BCE6E5 63A440F2

       &nb= sp;            =    77037D81 2DEB33A0 F4A13945 D898C296

       &nb= sp;             = ;  4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16

       &nb= sp;            =    2BCE3357 6B315ECE CBB64068 37BF51F5

 

      KSAK &nbs= p;    :=3D 0x  12345;

 

      KPAK &nbs= p;    :=3D 0x  04

       &nb= sp;            =    50D4670B DE75244F 28D2838A 0D25558A

       &nb= sp;            =    7A72686D 4522D4C8 273FB644 2AEBFA93

       &nb= sp;            =    DBDD3755 1AFD263B 5DFD617F 3960C65A

       &nb= sp;            =    8C298850 FF99F203 66DCE7D4 367217F4

 

   The remaining steps to creating = a private key for ID use the same

   "random" value v as Ap= pendix A of [RFC6507] and are:

 

      v  &= nbsp;      :=3D 0x  23456;<= /p>

 

(Values of PVT and HS omitted here.)

 

   The remaining steps to creating = a signature for M use the same

   "random" value j as Ap= pendix A of [RFC6507] and are:

 

      j  &= nbsp;      :=3D 0x  34567;<= /p>

 

      J  &= nbsp;      :=3D 0x  04

       &nb= sp;            =    269D4C8F DEB66A74 E4EF8C0D 5DCC597D

       &nb= sp;            =    DFE6029C 2AFFC493 6008CD2C C1045D81

       &nb= sp;            =    6DDA6A13 10F4B067 BD5DABDA D741B7CE

       &nb= sp;            =    F36457E1 96B1BFA9 7FD5F8FB B3926ADB

 

(Remainder giving values of r, HE, s’, s and S= ignature omitted here.)

 

-- <= /p>

Christopher Dearlove

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

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

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

 

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

 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE47GLKXM0002VGREEN_-- From nobody Tue Jul 22 07:23:48 2014 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 1D5091B28DD for ; Tue, 22 Jul 2014 07:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ispkOfZ98ZgQ for ; Tue, 22 Jul 2014 07:23:40 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371B51B28DE for ; Tue, 22 Jul 2014 07:23:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1AEDE2407D0; Tue, 22 Jul 2014 07:23:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B9960240223; Tue, 22 Jul 2014 07:23:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5EE509A-0E63-4409-92B7-D17AC05E3CBC" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 16:23:38 +0200 Message-Id: References: To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/S_1x87JVKghZCNiNgoCw14NGvyE Cc: "manet@ietf.org" Subject: Re: [manet] You help appreciated on IBS draft 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, 22 Jul 2014 14:23:43 -0000 --Apple-Mail=_A5EE509A-0E63-4409-92B7-D17AC05E3CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > Obviously there=E2=80=99s an acknowledgement on offer, I=E2=80=99m = afraid it=E2=80=99s the best incentive I have. > =20 > Christopher This is the IETF - we work better on offers of beer or caffeine ;) --Apple-Mail=_A5EE509A-0E63-4409-92B7-D17AC05E3CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Obviously = there=E2=80=99s an acknowledgement on offer, I=E2=80=99m afraid it=E2=80=99= s the best incentive I have.
 
Christopher

This is the IETF - we work better on offers of beer or caffeine = ;)

= --Apple-Mail=_A5EE509A-0E63-4409-92B7-D17AC05E3CBC-- From nobody Tue Jul 22 07:25:27 2014 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 774CE1B28E9 for ; Tue, 22 Jul 2014 07:25:21 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7fBI9vZtD8yc for ; Tue, 22 Jul 2014 07:25:13 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFF01B28FC for ; Tue, 22 Jul 2014 07:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EFE2F240961 for ; Tue, 22 Jul 2014 07:25:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A9C452407D0 for ; Tue, 22 Jul 2014 07:25:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A77648D4-874D-441F-8D00-A0A19925B507 Content-Transfer-Encoding: 7bit From: Thomas Clausen Mime-Version: 1.0 (1.0) Date: Tue, 22 Jul 2014 10:25:07 -0400 Message-Id: <1CD9CC1F-18BD-4592-BFEE-AFA5812785B5@thomasclausen.org> To: manet X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/C4ysfM0Qhb9JaOs2JhMQLrTn2qI Subject: [manet] Security question for draft-ietf-manet-aodvv2-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, 22 Jul 2014 14:25:22 -0000 --Apple-Mail-A77648D4-874D-441F-8D00-A0A19925B507 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Given that we were told that a way forward for security had been identified= , but we were not allowed to know what that way forward was, I'll ask some= specific questions that I hope can be answered. Page numbers refer to the document in --- Page 4 --- Draft text: > When a data packet is received to be forwarded but there is no valid rout= e for the destination,=20 > then the AODVv2 router of the source of the packet is notified via a Rout= e Error (RERR)=20 > message. Comment: This, then, essentially, means that for every non-routable packet, the proto= col must be informed -- as for with routing table "hits" for marking a route= as active, this is uncommon, and somewhat intrusive, as has been discussed e= lsewhere.=20 Question: With that being said, as a router must send a message for each non-delivered= message, this also does sound like a formidable attack vector against a rou= ter: pump it data packets to a set of non-existing address, and watch it exh= aust itself generating RERRs. How is that being guarded against? Draft text: > Each upstream router that receives the RERR marks the route as broken. Comment: So, essentially this implies that it is possible to do a denial-of-service a= ttack, by injecting RERRs and cause other devices to do a RREQ flooding on t= he network -- draining battery, causing channel congestion, etc. Question: How is this protected against? Bigger Question: It is possible to attack a router, and the network *both* by sending control= signals and by sending data packets.=20 One might device an "admission policy" based in ICVs on control signals, tha= t could be used to exclude (as in the above) a rogue RERR. How to protect against attacks-by-data-packets? Requiring ICVs on all data p= ackets seems unfeasible, what's the "way forward" for this? Best, Thomas Sent from my iPad= --Apple-Mail-A77648D4-874D-441F-8D00-A0A19925B507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Given that  we were told that a w= ay forward for security had been identified, but we were not allowed to know= what that way forward was,  I'll  ask some specific questions tha= t I hope can be answered.

Page numbers refer to the= document in <subject>

--- Page 4 ---

=
Draft text:
> When a data packet is rece= ived to  be forwarded but there is no valid route for the destination,=  
> then  the AODVv2 router of the source of the pac= ket is notified via a Route  Error (RERR) 
> message= .

Comment:
This, then, essentially, means that for e= very non-routable packet, the protocol must be informed -- as for with routi= ng table "hits" for marking a route as active, this is uncommon, and somewha= t intrusive, as has been discussed elsewhere. 

Question:
With that being said, as a router must send= a message for each non-delivered message, this also does sound like a formi= dable attack vector against a router: pump it data packets to a set of non-e= xisting address, and watch it exhaust itself generating RERRs.
How= is that being guarded against?

Draft text:
> Each upstr= eam router that receives the RERR  marks the route as broken.

<= b>Comment:
So, essentially this implies that it is possible to do a d= enial-of-service attack, by injecting RERRs and cause other devices to do a R= REQ flooding on the network -- draining battery, causing channel congestion,= etc.

Question:
How is this protected against?
Bigger Question:
It is possible to attack a router, a= nd the network *both* by sending control signals and by sending data packets= . 

One might device an "admission policy" base= d in ICVs on control signals, that could be used to exclude (as in the above= ) a rogue RERR.

How to protect against attacks-by-d= ata-packets? Requiring ICVs on all data packets seems unfeasible, what's the= "way forward" for this?

Best,

=
Thomas

Sent from my iPad
= --Apple-Mail-A77648D4-874D-441F-8D00-A0A19925B507-- From nobody Tue Jul 22 07:25:51 2014 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 518261B2904 for ; Tue, 22 Jul 2014 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 BwFST9I2CTmM for ; Tue, 22 Jul 2014 07:25:35 -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 89C841B28FE for ; Tue, 22 Jul 2014 07:25:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="388515228" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 15:25:30 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="65650147" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 15:25:37 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 15:25:36 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , Henning Rogge Thread-Topic: [manet] Not just 5498 but also 5444 compliance Thread-Index: AQHPpbYXuIaZrHbN8kGd1/etmzcqO5usELGAgAAT1WA= Date: Tue, 22 Jul 2014 14:25:36 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> In-Reply-To: <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> 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: http://mailarchive.ietf.org/arch/msg/manet/-NWRm_lYI4lQrDnzYGfjuXptZUs Cc: "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 14:25:45 -0000 I'm expecting to be contributing as an author here, and your input will be = valuable here. I'm not sure how far this document will get (it's effort limited as has bee= n said). If we get to an abstract representation of 5444 information (we ma= y or may not) then I'm aware of at least two approaches with advantages or = disadvantages. Roughly speaking, one is iterator based, one is map based, w= ith different tradeoffs (and preserving slightly different information). Ho= wever I don't think we should specify an API here. Publication of an API se= parately (ID or software documentation) could well be useful. = -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Claus= en Sent: 22 July 2014 15:09 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] Not just 5498 but also 5444 compliance ----------------------! 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. -------------------------------------------------------- > On 22 Jul 2014, at 16:05 , Henning Rogge wrote: > = > On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote: >>> One of those things the authors of 5444 etc. would like to do - when = >>> they can find some extra hours in a week - is to set out this sort = >>> of good practice for 5444 that has been found to be valuable. In = >>> this case we have the two principles of (a) always attack a TLV to = >>> indicate information, as just doing so from a non-TLVed address = >>> precludes various extensions, and (b) when attaching information, = >>> null values are good - T:LV extensions discusses why, a lot comes = >>> down to that you can't order for more than one or two TLVs at once. >> = >> Yes, and with the caveat that one of the 5444 authors is trying to = >> find some hours this week for that, so that may be forthcoming soon. >> = >> (See, Chris, now you made me go public with this, so I'm kinda on the = >> hook for producing something..) > = > I would also be interested in doing this, mostly because a lot of = > these assumptions (how to do RFC5444) have been put into the design of = > my > RFC5444 parser/generator API. > = > The generator API supports that multiple parts of the program are = > multiplexing data into the same message, so there is no reliable way = > to guarantee the position of addresses and TLVs within the message. > = > Documenting these 'best practices' would be helpful for further = > protocol designers. > = Absolutely, and we (well, at least, I) count on looping you in on this proc= ess. Cheers, Thomas > Henning Rogge > = > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = > Kommunikation, Informationsverarbeitung und Ergonomie FKIE = > Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, = > Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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 Tue Jul 22 07:27:29 2014 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 EB8251B2907 for ; Tue, 22 Jul 2014 07:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 pmFBB0YarDNA for ; Tue, 22 Jul 2014 07:27:24 -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 6F3BA1B2909 for ; Tue, 22 Jul 2014 07:27:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="388515834" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 15:27:22 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="65650446" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 15:27:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 15:27:28 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen Thread-Topic: [manet] You help appreciated on IBS draft Thread-Index: Ac+ltwTlX79aqVYDRGW+yQlCmcFqzf//8kEA///uhPA= Date: Tue, 22 Jul 2014 14:27:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE81GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/w7CGu55fvFDQvVE7jX0HSbVGg2E Cc: "manet@ietf.org" Subject: Re: [manet] You help appreciated on IBS draft 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, 22 Jul 2014 14:27:26 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE81GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SWYgeW91IGNhbiB0ZWxsIG1lIHdoaWNoIElFVEYgcHJvdG9jb2wgSSBjYW4gdXNlIHRvIHRyYW5z ZmVyIHRob3NlLCBJ4oCZbGwgc2VlIGlmIEkgY2FuIGZpbmQgYW4gaW1wbGVtZW50YXRpb24uDQoN Ci0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5m b3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIElt YWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kg Q2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEy NA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMg KE9wZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQ TyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50 cywgR1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4 Nw0KDQpGcm9tOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9tYXNjbGF1 c2VuLm9yZ10NClNlbnQ6IDIyIEp1bHkgMjAxNCAxNToyNA0KVG86IERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFlvdSBo ZWxwIGFwcHJlY2lhdGVkIG9uIElCUyBkcmFmdA0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBt ZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBm cm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1 bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFj aG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhh dCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8 aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv dGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFp bCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFu ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt ZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCg0KT2J2aW91 c2x5IHRoZXJl4oCZcyBhbiBhY2tub3dsZWRnZW1lbnQgb24gb2ZmZXIsIEnigJltIGFmcmFpZCBp dOKAmXMgdGhlIGJlc3QgaW5jZW50aXZlIEkgaGF2ZS4NCg0KQ2hyaXN0b3BoZXINCg0KVGhpcyBp cyB0aGUgSUVURiAtIHdlIHdvcmsgYmV0dGVyIG9uIG9mZmVycyBvZiBiZWVyIG9yIGNhZmZlaW5l IDspDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0 ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBu b3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0 cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE81GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmIHlvdSBjYW4gdGVsbCBtZSB3aGljaCBJRVRGIHByb3RvY29sIEkgY2FuIHVzZSB0byB0 cmFuc2ZlciB0aG9zZSwgSeKAmWxsIHNlZSBpZiBJIGNhbiBmaW5kIGFuIGltcGxlbWVudGF0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0 b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNz dXJhbmNlIEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFs eXNpcyBDYXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50 cmU8YnI+DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IENNMiA4SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBG YXg6ICYjNDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPg0KIHwgaHR0cDov L3d3dy5iYWVzeXN0ZW1zLmNvbTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QkFFIFN5 c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2lj ayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9y b3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1w OyBXYWxlcyBObzogMTk5NjY4NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBUaG9tYXMgSGVpZGUgQ2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9t YXNjbGF1c2VuLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMiBKdWx5IDIwMTQgMTU6MjQ8YnI+ DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBt YW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBZb3UgaGVscCBh cHByZWNpYXRlZCBvbiBJQlMgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAy LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8 bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGlu dGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ug c2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHku PC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5n IDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQg Zm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFu ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt ZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlv dSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm Ij4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PYnZpb3VzbHkgdGhl cmXigJlzIGFuIGFja25vd2xlZGdlbWVudCBvbiBvZmZlciwgSeKAmW0gYWZyYWlkIGl04oCZcyB0 aGUgYmVzdCBpbmNlbnRpdmUgSSBoYXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DaHJpc3RvcGhlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGlzIHRoZSBJRVRGIC0gd2Ugd29yayBiZXR0ZXIgb24gb2ZmZXJzIG9mIGJlZXIg b3IgY2FmZmVpbmUgOyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5k ZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIg c3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQg b3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUg aXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEEE81GLKXM0002VGREEN_-- From nobody Tue Jul 22 07:31:33 2014 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 595DA1B28F4 for ; Tue, 22 Jul 2014 07:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z69bRzF9JZ76 for ; Tue, 22 Jul 2014 07:31:29 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892E51B2939 for ; Tue, 22 Jul 2014 07:31:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 696C2240820; Tue, 22 Jul 2014 07:31:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D1AC9240223; Tue, 22 Jul 2014 07:31:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6E52778F-1A4B-4FB5-8135-D9CF3713C012" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 16:30:56 +0200 Message-Id: <7EA63C18-4A12-46A5-9880-E9D785C84341@thomasclausen.org> References: To: Christopher Dearlove , Adrian Farrel X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/eKaGdDrIdT-KdqkM4nXhZZbD-xA Cc: "manet@ietf.org" Subject: Re: [manet] You help appreciated on IBS draft 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, 22 Jul 2014 14:31:31 -0000 --Apple-Mail=_6E52778F-1A4B-4FB5-8135-D9CF3713C012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jul 2014, at 16:27 , Dearlove, Christopher (UK) = wrote: >=20 > If you can tell me which IETF protocol I can use to transfer those, = I=E2=80=99ll see if I can find an implementation. I dunno, there was a lot of =E2=80=9Ceverything-over-MPLS=E2=80=9D so = I=E2=80=99m sure that there must be a beer-and-caffeine-over-MPLS spec = somewhere in the repositories. Adrian, a pointer? Thomas > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 22 July 2014 15:24 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] You help appreciated on IBS draft > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > =20 > Obviously there=E2=80=99s an acknowledgement on offer, I=E2=80=99m = afraid it=E2=80=99s the best incentive I have. > =20 > Christopher > =20 > This is the IETF - we work better on offers of beer or caffeine ;) > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_6E52778F-1A4B-4FB5-8135-D9CF3713C012 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Jul = 2014, at 16:27 , Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

If you can tell me which IETF protocol I can use to = transfer those, I=E2=80=99ll see if I can find an = implementation.

I = dunno, there was a lot of =E2=80=9Ceverything-over-MPLS=E2=80=9D so = I=E2=80=99m sure that there must be  a beer-and-caffeine-over-MPLS = spec somewhere in the repositories. Adrian, a = pointer?

Thomas

 
--
Christopher = Dearlove
Senior Principal Engineer, Information Assurance = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] 
Sent: 22 July 2014 = 15:24
To: Dearlove, Christopher = (UK)
Cc: manet@ietf.org
Subject: Re: [manet] You help = appreciated on IBS draft
 
 
*** = WARNING ***

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

 
Obviously = there=E2=80=99s an acknowledgement on offer, I=E2=80=99m afraid it=E2=80=99= s the best incentive I have.
 
Christopher
 
This is the IETF - we work better on offers of beer = or caffeine ;)
 

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

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

= --Apple-Mail=_6E52778F-1A4B-4FB5-8135-D9CF3713C012-- From nobody Tue Jul 22 07:40:17 2014 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 649BA1B293D for ; Tue, 22 Jul 2014 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 VHElFpFi2pHG for ; Tue, 22 Jul 2014 07:40:11 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79BE1B289C for ; Tue, 22 Jul 2014 07:40:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id F2E339203F3; Tue, 22 Jul 2014 07:40:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 330909203EC; Tue, 22 Jul 2014 07:40:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 16:40:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8315A8D1-2ED0-47E2-82A5-930832C34D4A@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/keHD7VCBmH9_ojYvRWEabbQb3b4 Cc: "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 14:40:12 -0000 > On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) = wrote: >=20 > I'm expecting to be contributing as an author here, and your input = will be valuable here. And I=92m sitting here with Ulrich, and in part hammering ideas out for = these, and we=92re all in agreement also. =20 Y=92all have been implementing 5444 parser/generators, and so that seems = exactly the experience necessary for these efforts. > I'm not sure how far this document will get (it's effort limited as = has been said). If we get to an abstract representation of 5444 = information (we may or may not) then I'm aware of at least two = approaches with advantages or disadvantages. Roughly speaking, one is = iterator based, one is map based, with different tradeoffs (and = preserving slightly different information). However I don't think we = should specify an API here. Publication of an API separately (ID or = software documentation) could well be useful.=20 Absolutely. Right now, as I said, we=92re just hammering out ideas =97 = any thoughts like these (or others) from folks having built 5444 = parsers/generators appreciated Thomas >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide = Clausen > Sent: 22 July 2014 15:09 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Not just 5498 but also 5444 compliance >=20 > ----------------------! 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. > -------------------------------------------------------- >=20 >> On 22 Jul 2014, at 16:05 , Henning Rogge = wrote: >>=20 >> On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote: >>>> One of those things the authors of 5444 etc. would like to do - = when=20 >>>> they can find some extra hours in a week - is to set out this sort=20= >>>> of good practice for 5444 that has been found to be valuable. In=20 >>>> this case we have the two principles of (a) always attack a TLV to=20= >>>> indicate information, as just doing so from a non-TLVed address=20 >>>> precludes various extensions, and (b) when attaching information,=20= >>>> null values are good - T:LV extensions discusses why, a lot comes=20= >>>> down to that you can't order for more than one or two TLVs at once. >>>=20 >>> Yes, and with the caveat that one of the 5444 authors is trying to=20= >>> find some hours this week for that, so that may be forthcoming soon. >>>=20 >>> (See, Chris, now you made me go public with this, so I'm kinda on = the=20 >>> hook for producing something..) >>=20 >> I would also be interested in doing this, mostly because a lot of=20 >> these assumptions (how to do RFC5444) have been put into the design = of=20 >> my >> RFC5444 parser/generator API. >>=20 >> The generator API supports that multiple parts of the program are=20 >> multiplexing data into the same message, so there is no reliable way=20= >> to guarantee the position of addresses and TLVs within the message. >>=20 >> Documenting these 'best practices' would be helpful for further=20 >> protocol designers. >>=20 >=20 > Absolutely, and we (well, at least, I) count on looping you in on this = process. >=20 > Cheers, >=20 > Thomas >=20 >=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 >> Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg,=20= >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 08:20:40 2014 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 0E4961B2977 for ; Tue, 22 Jul 2014 08:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.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 FHzo0tLzjRIs for ; Tue, 22 Jul 2014 08:20:25 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D5F1B2983 for ; Tue, 22 Jul 2014 08:20:22 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so7096635qgd.13 for ; Tue, 22 Jul 2014 08:20: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=rkh8p1wHjWbemW8N5/Nl4EAzlLQSE0lFRi9HxlVOXHk=; b=GQ3IftjEmIqTCKHLHaL7p7DrunXtfF7oP2rY5XbREjt99brquZDmKwieYXgUG9NKH+ m6POqLMkD3S0uC7yDYRU3yC7eRt7VRXgxinzfXq8scFbJjHIxT6dgG0kozWzLfjQeX3T uOAEqa6CW11gegb1UWau+yi5bnvro5q9S8l1g0gMOooI2vnB0xcAZf8DkJu47ZHTfzqb 1pUp1AjAtvQMhcVRV3cf1KU7JppNmQ+IaADSmF+Qy6OvycxCFV8z5qKTxRHYe0BCI0TJ jKMZILKybhsaq4yNmjVeidQpJzZn0hvEfhWrzGrQmmk7z1+oIkLGtW2dJDvndrSn+0en S9GA== X-Received: by 10.140.80.170 with SMTP id c39mr50950140qgd.79.1406042421527; Tue, 22 Jul 2014 08:20:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 08:20:01 -0700 (PDT) In-Reply-To: References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 22 Jul 2014 17:20:01 +0200 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ge3WiBeIpuH6K5bTfmijsRHBBPE Cc: "" , "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 15:20:28 -0000 On Tue, Jul 22, 2014 at 4:14 PM, Thomas Heide Clausen wrote: >> Unless someone finds another problem with the draft I think we should >> consider going towards WGLC=E2=80=A6 > > That=E2=80=99s just awesome. > > I read the previous version (-00) and had a few nits (and they were just = nits). Didn=E2=80=99t get time to type them up, but will try to do so this = week, and in passing look at the RFCdiff to -01. > > FWIW, my review resulted only in nits, of the sort that can easily be fol= ded in during a WGLC. > > So I vividly encourage that a WGLC be issued for this document. I would also be okay to insert the 'nits' and release a -02 draft in a mont= h... xml2rfc makes it easy to insert changes without worrying about references and pages. Henning Rogge From nobody Tue Jul 22 08:25:50 2014 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 C2AF81B297B for ; Tue, 22 Jul 2014 08:25:48 -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 RnJtK1kZjMi8 for ; Tue, 22 Jul 2014 08:25:47 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A06A1B297A for ; Tue, 22 Jul 2014 08:25:47 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so7310264qgf.31 for ; Tue, 22 Jul 2014 08:25: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:content-transfer-encoding; bh=JYEnO87gXJPP/GRzasnonSdOUpN94PnWVKkpRw8IuFc=; b=YmPH0/Fca24qQ/lgLKv8AsMTD7ROJkgk+LFWbc5P8TPjAr9KfTCEa7lt+88TfBGdrQ juDamXIZrZdg9MsfxQF9Y3CN1p13tlG9uqrX3FiUOGmOA+OP1RDi03OzIyrnEor0WQDD Qe7n1Fgjc1zfA5PaclgcxLl0wjjRvAcPVhoozwX2HObSehTjWOFCp92N39oIt15dr8xT eK4AVI/ejRuIFxdYxDxkfX9f5WhD/4j0wT1HJO5qiT53gHCW2AZKcafvDILXDX15lUmM gfWLDQBqg1ATMunE3dPlwG3i4ceGab+i8wN99M+fN6Ljov2lCvPCiW1vQrdZN4CBV3Wm bbEQ== X-Received: by 10.224.103.134 with SMTP id k6mr12765371qao.24.1406042746188; Tue, 22 Jul 2014 08:25:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 08:25:26 -0700 (PDT) In-Reply-To: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> From: Henning Rogge Date: Tue, 22 Jul 2014 17:25:26 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5w-kdblzakChMhJn8AhDF-XaHDg Cc: "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 15:25:48 -0000 On Tue, Jul 22, 2014 at 4:25 PM, Dearlove, Christopher (UK) wrote: > I'm expecting to be contributing as an author here, and your input will b= e valuable here. > > I'm not sure how far this document will get (it's effort limited as has b= een said). If we get to an abstract representation of 5444 information (we = may or may not) then I'm aware of at least two approaches with advantages o= r disadvantages. fun fact about my parser API... there are TWO ways to get TLVs (and the attached context) with my API. One is similar to a XML SAX parser... you get a callback for each hierarchy that opens/closes and one for each object inside. This is useful for parsing incoming data without knowing the structure. The other one uses a predefined array of TLVs (for either packet, message or address level) your code is interested in . With this method you get all the relevant TLVs at once instead of one by one. > Roughly speaking, one is iterator based, one is map based, with different= tradeoffs (and preserving slightly different information). However I don't= think we should specify an API here. Publication of an API separately (ID = or software documentation) could well be useful. I agree, specifying a fixed API sounds bad... and before I would consider publishing "my" API as an ID I would really need some review of it. Henning Rogge From nobody Tue Jul 22 08:29:13 2014 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 47D021A0046 for ; Tue, 22 Jul 2014 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 GSYo-OqM6kov for ; Tue, 22 Jul 2014 08:29:05 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1011A0041 for ; Tue, 22 Jul 2014 08:29:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2800524099D; Tue, 22 Jul 2014 08:29:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id AF6122408B9; Tue, 22 Jul 2014 08:29:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 17:29:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RMC_aioYaxkiHC1GLz4QWWktzbI Cc: "" , "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 15:29:06 -0000 > On 22 Jul 2014, at 17:20 , Henning Rogge wrote: >=20 > On Tue, Jul 22, 2014 at 4:14 PM, Thomas Heide Clausen > wrote: >>> Unless someone finds another problem with the draft I think we = should >>> consider going towards WGLC=E2=80=A6 >>=20 >> That=E2=80=99s just awesome. >>=20 >> I read the previous version (-00) and had a few nits (and they were = just nits). Didn=E2=80=99t get time to type them up, but will try to do = so this week, and in passing look at the RFCdiff to -01. >>=20 >> FWIW, my review resulted only in nits, of the sort that can easily be = folded in during a WGLC. >>=20 >> So I vividly encourage that a WGLC be issued for this document. >=20 > I would also be okay to insert the 'nits' and release a -02 draft in a = month... >=20 > xml2rfc makes it easy to insert changes without worrying about > references and pages. Sure, but I se absolutely no reason to postpone a WGLC a month for that. = Let=E2=80=99s get it launched=E2=80=A6 Thomas >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 08:31:01 2014 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 EFD221A014E for ; Tue, 22 Jul 2014 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_12=0.6, 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 zP6pgWUCJ2O4 for ; Tue, 22 Jul 2014 08:30:52 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B641A00DD for ; Tue, 22 Jul 2014 08:30:18 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so6159834lbd.14 for ; Tue, 22 Jul 2014 08:30:16 -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=DmIEaZ77ve/xhpfeM8eL91qe/GWgwXMxGkYlxewFHHI=; b=uP1/XzUcnkNpjjxEnvdcUEmWU+kt5uo9kMAsC6jwskB+8WrwMx2G3KN6pTWcYh/v0h /EB0DOQEOX1ErGmMr5THR6wr3SylNb/GIA3h4BFp2koE+OSei2XW27oRSg8LkjnoETIO Kpml717f5aT0oitHH5K9fObvZG5aNY3N2hmpkJhM0CL4LqTWnMSeo76teFSYP+Tbt3bj lJ1fFLua5sSm58sV3LhEqgd3xsrqx+TbJe2MjNjeOsZGUDabYV6Fv3fYmNl2kx3gdttD Py+gl6sHzHKCfo8a2rq/S1X0H+gY1718faLVe2hny2SylTb5NAYaCSXGqHz7zM4ZuoVd yElA== MIME-Version: 1.0 X-Received: by 10.112.55.147 with SMTP id s19mr19294747lbp.78.1406043016658; Tue, 22 Jul 2014 08:30:16 -0700 (PDT) Received: by 10.152.104.236 with HTTP; Tue, 22 Jul 2014 08:30:16 -0700 (PDT) In-Reply-To: <8315A8D1-2ED0-47E2-82A5-930832C34D4A@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> <8315A8D1-2ED0-47E2-82A5-930832C34D4A@thomasclausen.org> Date: Tue, 22 Jul 2014 11:30:16 -0400 Message-ID: From: Justin Dean To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=001a1133eb828c085504fec9e6c5 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6EhkZ5X6GKDRNQD6qagx6lbl8mg Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 15:30:55 -0000 --001a1133eb828c085504fec9e6c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Count me in on the effort as well. We should take note that it isn't just about how best to compact a packetbb message with multiple tlv values of different protocol types (and there are different ways and tradeoffs). It should also be about the design of the format and best practices for designing messages, tlvs, and assigning values. Having a what not to do and why section would also be helpful. Justin On Tue, Jul 22, 2014 at 10:40 AM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > > > On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > > > I'm expecting to be contributing as an author here, and your input will > be valuable here. > > And I=E2=80=99m sitting here with Ulrich, and in part hammering ideas out= for > these, and we=E2=80=99re all in agreement also. > Y=E2=80=99all have been implementing 5444 parser/generators, and so that = seems > exactly the experience necessary for these efforts. > > > I'm not sure how far this document will get (it's effort limited as has > been said). If we get to an abstract representation of 5444 information (= we > may or may not) then I'm aware of at least two approaches with advantages > or disadvantages. Roughly speaking, one is iterator based, one is map > based, with different tradeoffs (and preserving slightly different > information). However I don't think we should specify an API here. > Publication of an API separately (ID or software documentation) could wel= l > be useful. > > Absolutely. Right now, as I said, we=E2=80=99re just hammering out ideas = =E2=80=94 any > thoughts like these (or others) from folks having built 5444 > parsers/generators appreciated > > Thomas > > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide > Clausen > > Sent: 22 July 2014 15:09 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] Not just 5498 but also 5444 compliance > > > > ----------------------! 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. > > -------------------------------------------------------- > > > >> On 22 Jul 2014, at 16:05 , Henning Rogge < > henning.rogge@fkie.fraunhofer.de> wrote: > >> > >> On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote: > >>>> One of those things the authors of 5444 etc. would like to do - when > >>>> they can find some extra hours in a week - is to set out this sort > >>>> of good practice for 5444 that has been found to be valuable. In > >>>> this case we have the two principles of (a) always attack a TLV to > >>>> indicate information, as just doing so from a non-TLVed address > >>>> precludes various extensions, and (b) when attaching information, > >>>> null values are good - T:LV extensions discusses why, a lot comes > >>>> down to that you can't order for more than one or two TLVs at once. > >>> > >>> Yes, and with the caveat that one of the 5444 authors is trying to > >>> find some hours this week for that, so that may be forthcoming soon. > >>> > >>> (See, Chris, now you made me go public with this, so I'm kinda on the > >>> hook for producing something..) > >> > >> I would also be interested in doing this, mostly because a lot of > >> these assumptions (how to do RFC5444) have been put into the design of > >> my > >> RFC5444 parser/generator API. > >> > >> The generator API supports that multiple parts of the program are > >> multiplexing data into the same message, so there is no reliable way > >> to guarantee the position of addresses and TLVs within the message. > >> > >> Documenting these 'best practices' would be helpful for further > >> protocol designers. > >> > > > > Absolutely, and we (well, at least, I) count on looping you in on this > process. > > > > Cheers, > > > > Thomas > > > > > >> Henning Rogge > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg= , > >> Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > _______________________________________________ > > 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 > --001a1133eb828c085504fec9e6c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Count me in on the effort as well. =C2=A0We should take no= te that it isn't just about how best to compact a packetbb message with= multiple tlv values of different protocol types (and there are different w= ays and tradeoffs). =C2=A0It should also be about the design of the format = and best practices for designing messages, tlvs, and assigning values. =C2= =A0Having a what not to do and why section would also be helpful.

Justin


On Tue, Jul 22, 2014 at 10:40 AM, Thomas Heide Clausen <thomas@t= homasclausen.org> wrote:

> On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> = wrote:
>
> I'm expecting to be contributing as an author here, and your input= will be valuable here.

And I=E2=80=99m sitting here with Ulrich, and in part hammering ideas= out for these, and we=E2=80=99re all in agreement also.
Y=E2=80=99all have been implementing 5444 parser/generators, and so that se= ems exactly the experience necessary for these efforts.

> I'm not sure how far this document will get (it's effort limit= ed as has been said). If we get to an abstract representation of 5444 infor= mation (we may or may not) then I'm aware of at least two approaches wi= th advantages or disadvantages. Roughly speaking, one is iterator based, on= e is map based, with different tradeoffs (and preserving slightly different= information). However I don't think we should specify an API here. Pub= lication of an API separately (ID or software documentation) could well be = useful.

Absolutely. Right now, as I said, we=E2=80=99re just hammering out id= eas =E2=80=94 any thoughts like these (or others) from folks having built 5= 444 parsers/generators appreciated

Thomas

>
> --
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =C2=A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet [mailto:manet-bo= unces@ietf.org] On Behalf Of Thomas Heide Clausen
> Sent: 22 July 2014 15:09
> To: Henning Rogge
> Cc: manet@ietf.org
> Subject: Re: [manet] Not just 5498 but also 5444 compliance
>
> ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external partner o= r from the internet.
> Consider carefully whether you should click on any links, open any att= achments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for i= nstructions on reporting suspicious email messages.
> --------------------------------------------------------
>
>> On 22 Jul 2014, at 16:05 , Henning Rogge <henning.rogge@fkie.fraunhofer.de> wro= te:
>>
>> On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote:
>>>> One of those things the authors of 5444 etc. would like to= do - when
>>>> they can find some extra hours in a week - is to set out t= his sort
>>>> of good practice for 5444 that has been found to be valuab= le. In
>>>> this case we have the two principles of (a) always attack = a TLV to
>>>> indicate information, as just doing so from a non-TLVed ad= dress
>>>> precludes various extensions, and (b) when attaching infor= mation,
>>>> null values are good - T:LV extensions discusses why, a lo= t comes
>>>> down to that you can't order for more than one or two = TLVs at once.
>>>
>>> Yes, and with the caveat that one of the 5444 authors is tryin= g to
>>> find some hours this week for that, so that may be forthcoming= soon.
>>>
>>> (See, Chris, now you made me go public with this, so I'm k= inda on the
>>> hook for producing something..)
>>
>> I would also be interested in doing this, mostly because a lot of<= br> >> these assumptions (how to do RFC5444) have been put into the desig= n of
>> my
>> RFC5444 parser/generator API.
>>
>> The generator API supports that multiple parts of the program are<= br> >> multiplexing data into the same message, so there is no reliable w= ay
>> to guarantee the position of addresses and TLVs within the message= .
>>
>> Documenting these 'best practices' would be helpful for fu= rther
>> protocol designers.
>>
>
> Absolutely, and we (well, at least, I) count on looping you in on this= process.
>
> Cheers,
>
> Thomas
>
>
>> Henning Rogge
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wacht= berg,
>> Germany
>> Telefon +49 228 9435-961, =C2=A0 Fax +49 228 9435 685
>> mailto:henning= .rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
> ******************************************************************** > This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

--001a1133eb828c085504fec9e6c5-- From nobody Tue Jul 22 08:34:46 2014 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 972361A00C0 for ; Tue, 22 Jul 2014 08:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 ubTKLo2Ro2MK for ; Tue, 22 Jul 2014 08:34:43 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EB01A00F9 for ; Tue, 22 Jul 2014 08:34:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B8B45240C8C; Tue, 22 Jul 2014 08:34:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9862A240961; Tue, 22 Jul 2014 08:34:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_71BB4DDB-A38C-4748-8D77-DFB2016EC2CA" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1967.5\)) From: Thomas Heide Clausen In-Reply-To: Date: Tue, 22 Jul 2014 17:34:39 +0200 Message-Id: <44ACC15D-C5DC-47FA-A62F-D01D9C7DEF9A@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> <8315A8D1-2ED0-47E2-82A5-930832C34D4A@thomasclausen.org> To: Justin Dean X-Mailer: Apple Mail (2.1967.5) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MQVboPGfdOO0tXOlxOxvHOaPVDI Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 15:34:45 -0000 --Apple-Mail=_71BB4DDB-A38C-4748-8D77-DFB2016EC2CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jul 2014, at 17:30 , Justin Dean wrote: >=20 > Count me in on the effort as well. We should take note that it isn't = just about how best to compact a packetbb message with multiple tlv = values of different protocol types (and there are different ways and = tradeoffs). It should also be about the design of the format and best = practices for designing messages, tlvs, and assigning values. Having a = what not to do and why section would also be helpful. >=20 Actually, it is not at all about how to best compact a 5444-message. = That=E2=80=99s interesting, but for a different I-D (which I hope that = someone will write). This effort is about the design of the format, how to use it in ways = that enable generic parsing and generation machinery, and =E2=80=94 as = you say =E2=80=94 best practices (including for managing the code-point = spaces). I=E2=80=99m actually starting to think that there=E2=80=99re two = documents here, a 5444-rationale, and a 5444-usage =E2=80=94 different, = but probably both very interesting. Thomas > Justin >=20 >=20 > On Tue, Jul 22, 2014 at 10:40 AM, Thomas Heide Clausen = wrote: >=20 > > On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) = wrote: > > > > I'm expecting to be contributing as an author here, and your input = will be valuable here. >=20 > And I=E2=80=99m sitting here with Ulrich, and in part hammering ideas = out for these, and we=E2=80=99re all in agreement also. > Y=E2=80=99all have been implementing 5444 parser/generators, and so = that seems exactly the experience necessary for these efforts. >=20 > > I'm not sure how far this document will get (it's effort limited as = has been said). If we get to an abstract representation of 5444 = information (we may or may not) then I'm aware of at least two = approaches with advantages or disadvantages. Roughly speaking, one is = iterator based, one is map based, with different tradeoffs (and = preserving slightly different information). However I don't think we = should specify an API here. Publication of an API separately (ID or = software documentation) could well be useful. >=20 > Absolutely. Right now, as I said, we=E2=80=99re just hammering out = ideas =E2=80=94 any thoughts like these (or others) from folks having = built 5444 parsers/generators appreciated >=20 > Thomas >=20 > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas = Heide Clausen > > Sent: 22 July 2014 15:09 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] Not just 5498 but also 5444 compliance > > > > ----------------------! 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. > > -------------------------------------------------------- > > > >> On 22 Jul 2014, at 16:05 , Henning Rogge = wrote: > >> > >> On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote: > >>>> One of those things the authors of 5444 etc. would like to do - = when > >>>> they can find some extra hours in a week - is to set out this = sort > >>>> of good practice for 5444 that has been found to be valuable. In > >>>> this case we have the two principles of (a) always attack a TLV = to > >>>> indicate information, as just doing so from a non-TLVed address > >>>> precludes various extensions, and (b) when attaching information, > >>>> null values are good - T:LV extensions discusses why, a lot comes > >>>> down to that you can't order for more than one or two TLVs at = once. > >>> > >>> Yes, and with the caveat that one of the 5444 authors is trying to > >>> find some hours this week for that, so that may be forthcoming = soon. > >>> > >>> (See, Chris, now you made me go public with this, so I'm kinda on = the > >>> hook for producing something..) > >> > >> I would also be interested in doing this, mostly because a lot of > >> these assumptions (how to do RFC5444) have been put into the design = of > >> my > >> RFC5444 parser/generator API. > >> > >> The generator API supports that multiple parts of the program are > >> multiplexing data into the same message, so there is no reliable = way > >> to guarantee the position of addresses and TLVs within the message. > >> > >> Documenting these 'best practices' would be helpful for further > >> protocol designers. > >> > > > > Absolutely, and we (well, at least, I) count on looping you in on = this process. > > > > Cheers, > > > > Thomas > > > > > >> Henning Rogge > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 = Wachtberg, > >> Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_71BB4DDB-A38C-4748-8D77-DFB2016EC2CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 22 Jul = 2014, at 17:30 , Justin Dean <bebemaster@gmail.com> = wrote:

Count me in on the effort as well.  We should take note = that it isn't just about how best to compact a packetbb message with = multiple tlv values of different protocol types (and there are different = ways and tradeoffs).  It should also be about the design of the = format and best practices for designing messages, tlvs, and assigning = values.  Having a what not to do and why section would also be = helpful.


Actually, it is not at all = about how to best compact a 5444-message. That=E2=80=99s interesting, = but for a different I-D (which I hope that someone will = write).

This effort is about the design of the = format, how to use it in ways that enable generic parsing and generation = machinery, and =E2=80=94 as you say =E2=80=94 best practices (including = for managing the code-point spaces).

I=E2=80=99m = actually starting to think that there=E2=80=99re two documents here, a = 5444-rationale, and a 5444-usage =E2=80=94 different, but probably both = very = interesting.

Thomas


=
Justin


On Tue, Jul 22, = 2014 at 10:40 AM, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:

> On 22 Jul 2014, at 16:25 , Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:
>
> I'm expecting to be contributing as an author here, and your input = will be valuable here.

And I=E2=80=99m sitting here with Ulrich, and in part hammering = ideas out for these, and we=E2=80=99re all in agreement also.
Y=E2=80=99all have been implementing 5444 parser/generators, and so that = seems exactly the experience necessary for these efforts.

> I'm not sure how far this document will get (it's effort limited as = has been said). If we get to an abstract representation of 5444 = information (we may or may not) then I'm aware of at least two = approaches with advantages or disadvantages. Roughly speaking, one is = iterator based, one is map based, with different tradeoffs (and = preserving slightly different information). However I don't think we = should specify an API here. Publication of an API separately (ID or = software documentation) could well be useful.

Absolutely. Right now, as I said, we=E2=80=99re just hammering out = ideas =E2=80=94 any thoughts like these (or others) from folks having = built 5444 parsers/generators appreciated

Thomas

>
> --
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 = 242124
> chris.dearlove@baesystems.co= m | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Heide Clausen
> Sent: 22 July 2014 15:09
> To: Henning Rogge
> Cc: manet@ietf.org
> Subject: Re: [manet] Not just 5498 but also 5444 compliance
>
> ----------------------! 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.
> --------------------------------------------------------
>
>> On 22 Jul 2014, at 16:05 , Henning Rogge <henning.rogge@fkie.fraunh= ofer.de> wrote:
>>
>> On 07/22/2014 03:51 PM, Thomas Heide Clausen wrote:
>>>> One of those things the authors of 5444 etc. would like = to do - when
>>>> they can find some extra hours in a week - is to set = out this sort
>>>> of good practice for 5444 that has been found to be = valuable. In
>>>> this case we have the two principles of (a) always = attack a TLV to
>>>> indicate information, as just doing so from a non-TLVed = address
>>>> precludes various extensions, and (b) when attaching = information,
>>>> null values are good - T:LV extensions discusses why, a = lot comes
>>>> down to that you can't order for more than one or two = TLVs at once.
>>>
>>> Yes, and with the caveat that one of the 5444 authors is = trying to
>>> find some hours this week for that, so that may be = forthcoming soon.
>>>
>>> (See, Chris, now you made me go public with this, so I'm = kinda on the
>>> hook for producing something..)
>>
>> I would also be interested in doing this, mostly because a lot = of
>> these assumptions (how to do RFC5444) have been put into the = design of
>> my
>> RFC5444 parser/generator API.
>>
>> The generator API supports that multiple parts of the program = are
>> multiplexing data into the same message, so there is no = reliable way
>> to guarantee the position of addresses and TLVs within the = message.
>>
>> Documenting these 'best practices' would be helpful for = further
>> protocol designers.
>>
>
> Absolutely, and we (well, at least, I) count on looping you in on = this process.
>
> Cheers,
>
> Thomas
>
>
>> Henning Rogge
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut = f=C3=BCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 = Wachtberg,
>> Germany
>> Telefon +49 228 9435-961,   Fax +49 228 = 9435 685
>> mailto:henning.rogge@fkie.fraunh= ofer.de http://www.fkie.fraunhofer.de
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
> = ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the = intended
> recipient please delete it from your system and notify the = sender.
> You should not copy it or use it for any purpose nor disclose = or
> distribute its contents to any other person.
> = ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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


= --Apple-Mail=_71BB4DDB-A38C-4748-8D77-DFB2016EC2CA-- From nobody Tue Jul 22 08:36:34 2014 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 8F8F31A0022 for ; Tue, 22 Jul 2014 08:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 PXzMZEmC33Fc for ; Tue, 22 Jul 2014 08:36:31 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510741A0005 for ; Tue, 22 Jul 2014 08:36:31 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id hr17so6129922lab.2 for ; Tue, 22 Jul 2014 08:36: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=8mVDEUDHBbQHUnqdWipPr2mZTdSQAQmNM9/TML0Gzds=; b=SBpqJKWe9xEnJPjlrTyBl3YU059Be5f0ZVMo8btADSc9TrJILSPW5xsq8wQ9sAaHDV 2mtwG35xOmWzZv1ZEZAj/9PqelZuBqc8v7SvBuix4ohWcecTbnyugIhtX9mRSh8ron8F Ji+nInJfq8r3EMKz91/OG1w4mD4rwLL8XYP3AZQ88+uHxxEGq3yNMuY5OBwXe1sqY87q WInvX54K5g5iAml8jwPbbwoHwjGMqOJe1nbxNrZodZNOMv9iuE+kDRdZVC9lBrjqgxwc Y4JUN8pcZY/9gmOVyvsEiCaIE/89/0LFOhrxJmC6K2/K0XX0ysL6LSJtvvDJcRjD5fsz dMTA== MIME-Version: 1.0 X-Received: by 10.152.30.10 with SMTP id o10mr23741069lah.41.1406043389659; Tue, 22 Jul 2014 08:36:29 -0700 (PDT) Received: by 10.152.104.236 with HTTP; Tue, 22 Jul 2014 08:36:29 -0700 (PDT) In-Reply-To: <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> Date: Tue, 22 Jul 2014 11:36:29 -0400 Message-ID: From: Justin Dean To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=089e0158c7b4c78fb904fec9fc1c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lUiAzKkqaw0-w0eJTrWhqbRWV_M Cc: "" , "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 15:36:33 -0000 --089e0158c7b4c78fb904fec9fc1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Henning I would very much like to make these changes in my code (yes I have an implementation) and provide it for interop testing. It would be nice to catch any glaring mistakes/omissions in the draft that us humans may have missed. Justin On Tue, Jul 22, 2014 at 11:29 AM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > > > On 22 Jul 2014, at 17:20 , Henning Rogge wrote: > > > > On Tue, Jul 22, 2014 at 4:14 PM, Thomas Heide Clausen > > wrote: > >>> Unless someone finds another problem with the draft I think we should > >>> consider going towards WGLC=E2=80=A6 > >> > >> That=E2=80=99s just awesome. > >> > >> I read the previous version (-00) and had a few nits (and they were > just nits). Didn=E2=80=99t get time to type them up, but will try to do s= o this > week, and in passing look at the RFCdiff to -01. > >> > >> FWIW, my review resulted only in nits, of the sort that can easily be > folded in during a WGLC. > >> > >> So I vividly encourage that a WGLC be issued for this document. > > > > I would also be okay to insert the 'nits' and release a -02 draft in a > month... > > > > xml2rfc makes it easy to insert changes without worrying about > > references and pages. > > Sure, but I se absolutely no reason to postpone a WGLC a month for that. > Let=E2=80=99s get it launched=E2=80=A6 > > Thomas > > > > > Henning Rogge > > > > _______________________________________________ > > 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 > --089e0158c7b4c78fb904fec9fc1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Henning I would very much like to make these changes in my= code (yes I have an implementation) and provide it for interop testing. = =C2=A0It would be nice to catch any glaring mistakes/omissions in the draft= that us humans may have missed.

Justin


On Tue, Jul 22, 2014 at 11:29 AM, Thomas Heide Clausen = <thomas@thomasclausen.org> wrote:

> On 22 Jul 2014, at 17:20 , Henning Rogge <hrogge@gmail.com> wrote:
>
> On Tue, Jul 22, 2014 at 4:14 PM, Thomas Heide Clausen
> <thomas@thomasclausen.o= rg> wrote:
>>> Unless someone finds another problem with the draft I think we= should
>>> consider going towards WGLC=E2=80=A6
>>
>> That=E2=80=99s just awesome.
>>
>> I read the previous version (-00) and had a few nits (and they wer= e just nits). Didn=E2=80=99t get time to type them up, but will try to do s= o this week, and in passing look at the RFCdiff to -01.
>>
>> FWIW, my review resulted only in nits, of the sort that can easily= be folded in during a WGLC.
>>
>> So I vividly encourage that a WGLC be issued for this document. >
> I would also be okay to insert the 'nits' and release a -02 dr= aft in a month...
>
> xml2rfc makes it easy to insert changes without worrying about
> references and pages.

Sure, but I se absolutely no reason to postpone a WGLC a month for th= at. Let=E2=80=99s get it launched=E2=80=A6

Thomas

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

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

--089e0158c7b4c78fb904fec9fc1c-- From nobody Tue Jul 22 08:38:05 2014 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 E73091A01F2 for ; Tue, 22 Jul 2014 08:38:03 -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 MfRi4CKD3-yM for ; Tue, 22 Jul 2014 08:38:03 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB9C1A0173 for ; Tue, 22 Jul 2014 08:38:02 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so6696250qad.17 for ; Tue, 22 Jul 2014 08:38: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=mGE1y3jZuYFxNzlCvb5Iq6VmFzx2IXJN0hrxlPcin1M=; b=tXnZyUXVLMrrgF2JBSa6CD9q2+o6Df8ntykl/5pBl0JdO8+wZ68jTchJa4XXcC9JiE bU56IWmOI6nxcgRRXgxu+MGdirEPXYi1k3PeBIiVnAm3lOZ4SWs1+MdCji5jg4zATGeL m73ghjFcEqarjAeGUs3UbSeoTrX/OgJPz+8b4KDdL5PuEbqSDzVmDUeGR0YI+7yaFifw B16WvmyDoFg4m2FnH1WHJivANgto7r1Ge22xfj99vfrC6Jkr8JMm8qpSbOfd05znN3zt 91dHJFb+HLg5R+qvqX5wiR1HioKe2AQHF/Vs9hM4JcWrhbBVnpKvR7qmWBuR9tTylI4p vX6g== X-Received: by 10.140.94.138 with SMTP id g10mr8742373qge.90.1406043482216; Tue, 22 Jul 2014 08:38:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 08:37:42 -0700 (PDT) In-Reply-To: References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> From: Henning Rogge Date: Tue, 22 Jul 2014 17:37:42 +0200 Message-ID: To: Justin Dean Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W6MUF6UotZwIvT_A9MEH2kOHEuM Cc: "" , "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 15:38:04 -0000 On Tue, Jul 22, 2014 at 5:36 PM, Justin Dean wrote: > Henning I would very much like to make these changes in my code (yes I have > an implementation) and provide it for interop testing. It would be nice to > catch any glaring mistakes/omissions in the draft that us humans may have > missed. You implemented this in your NHDP implementation? Yes, we definitely should repeat our interop test! (how is your OLSRv2 implementation coming?) Henning Rogge From nobody Tue Jul 22 08:51:11 2014 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 2F2CC1B29A6 for ; Tue, 22 Jul 2014 08:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 YoC4qXu3eQ_4 for ; Tue, 22 Jul 2014 08:51:05 -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 2E72D1B2975 for ; Tue, 22 Jul 2014 08:51:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="388547507" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 16:51:02 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="65666978" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 16:51:09 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 16:51:10 +0100 From: "Dearlove, Christopher (UK)" To: Justin Dean , Thomas Heide Clausen Thread-Topic: [manet] Not just 5498 but also 5444 compliance Thread-Index: AQHPpbYXuIaZrHbN8kGd1/etmzcqO5usELGAgAAT1WD///TzgIAADgMAgAAVoRA= Date: Tue, 22 Jul 2014 15:51:09 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> <8315A8D1-2ED0-47E2-82A5-930832C34D4A@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF082GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hDMd357jhie2usBtHYnXUVPiprM Cc: "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 15:51:09 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF082GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBwcmluY2lwbGVzIGFyZSB3aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIGZpcnN0LiBU aGVyZSBhcmUgc29tZSBwcmluY2lwbGVzIHRoYXQgZG8gaGF2ZSBhIG5vbi16ZXJvIG92ZXJoZWFk LCBidXQgbWFrZSB2YXJpb3VzIG90aGVyIHRoaW5ncyBwb3NzaWJsZSBhbmQgdGh1cyBhcmUgd2Fu dGVkLg0KDQpGb3IgZWZmaWNpZW5jeSwgdGhpcyBpcyBoYXJkIOKAkyBhbmQgYWxzbyBxdWFsaXR5 IG9mIGltcGxlbWVudGF0aW9uIGhlcmUgY291bGQgYmUgYSBzZWxsaW5nIHBvaW50LiBCdXQgVExW IGV4dGVuc2lvbnMgY29udGFpbnMgc29tZSBmZWF0dXJlcyB0aGF0IHNob3VsZCAoZWZmb3J0IHBl cm1pdHRpbmcpIGJlIGNhbGxlZCBvdXQgYW5kIGV4YW1wbGVkIChpZiB0aGF04oCZcyBhIHdvcmQp Lg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIs IEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFu ZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9s b2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAy NDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3Vz ZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwg SGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5 OTY2ODcNCg0KRnJvbTogSnVzdGluIERlYW4gW21haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbV0N ClNlbnQ6IDIyIEp1bHkgMjAxNCAxNjozMA0KVG86IFRob21hcyBIZWlkZSBDbGF1c2VuDQpDYzog RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTog W21hbmV0XSBOb3QganVzdCA1NDk4IGJ1dCBhbHNvIDU0NDQgY29tcGxpYW5jZQ0KDQoNCioqKiBX QVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0 Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2Fy ZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJl Y2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3 ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklm IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJv Y2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFp bHMucGRmPi4NCkNvdW50IG1lIGluIG9uIHRoZSBlZmZvcnQgYXMgd2VsbC4gIFdlIHNob3VsZCB0 YWtlIG5vdGUgdGhhdCBpdCBpc24ndCBqdXN0IGFib3V0IGhvdyBiZXN0IHRvIGNvbXBhY3QgYSBw YWNrZXRiYiBtZXNzYWdlIHdpdGggbXVsdGlwbGUgdGx2IHZhbHVlcyBvZiBkaWZmZXJlbnQgcHJv dG9jb2wgdHlwZXMgKGFuZCB0aGVyZSBhcmUgZGlmZmVyZW50IHdheXMgYW5kIHRyYWRlb2Zmcyku ICBJdCBzaG91bGQgYWxzbyBiZSBhYm91dCB0aGUgZGVzaWduIG9mIHRoZSBmb3JtYXQgYW5kIGJl c3QgcHJhY3RpY2VzIGZvciBkZXNpZ25pbmcgbWVzc2FnZXMsIHRsdnMsIGFuZCBhc3NpZ25pbmcg dmFsdWVzLiAgSGF2aW5nIGEgd2hhdCBub3QgdG8gZG8gYW5kIHdoeSBzZWN0aW9uIHdvdWxkIGFs c28gYmUgaGVscGZ1bC4NCg0KSnVzdGluDQoNCk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDEwOjQw IEFNLCBUaG9tYXMgSGVpZGUgQ2xhdXNlbiA8dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnPG1haWx0 bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmc+PiB3cm90ZToNCg0KPiBPbiAyMiBKdWwgMjAxNCwg YXQgMTY6MjUgLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6 DQo+DQo+IEknbSBleHBlY3RpbmcgdG8gYmUgY29udHJpYnV0aW5nIGFzIGFuIGF1dGhvciBoZXJl LCBhbmQgeW91ciBpbnB1dCB3aWxsIGJlIHZhbHVhYmxlIGhlcmUuDQpBbmQgSeKAmW0gc2l0dGlu ZyBoZXJlIHdpdGggVWxyaWNoLCBhbmQgaW4gcGFydCBoYW1tZXJpbmcgaWRlYXMgb3V0IGZvciB0 aGVzZSwgYW5kIHdl4oCZcmUgYWxsIGluIGFncmVlbWVudCBhbHNvLg0KWeKAmWFsbCBoYXZlIGJl ZW4gaW1wbGVtZW50aW5nIDU0NDQgcGFyc2VyL2dlbmVyYXRvcnMsIGFuZCBzbyB0aGF0IHNlZW1z IGV4YWN0bHkgdGhlIGV4cGVyaWVuY2UgbmVjZXNzYXJ5IGZvciB0aGVzZSBlZmZvcnRzLg0KDQo+ IEknbSBub3Qgc3VyZSBob3cgZmFyIHRoaXMgZG9jdW1lbnQgd2lsbCBnZXQgKGl0J3MgZWZmb3J0 IGxpbWl0ZWQgYXMgaGFzIGJlZW4gc2FpZCkuIElmIHdlIGdldCB0byBhbiBhYnN0cmFjdCByZXBy ZXNlbnRhdGlvbiBvZiA1NDQ0IGluZm9ybWF0aW9uICh3ZSBtYXkgb3IgbWF5IG5vdCkgdGhlbiBJ J20gYXdhcmUgb2YgYXQgbGVhc3QgdHdvIGFwcHJvYWNoZXMgd2l0aCBhZHZhbnRhZ2VzIG9yIGRp c2FkdmFudGFnZXMuIFJvdWdobHkgc3BlYWtpbmcsIG9uZSBpcyBpdGVyYXRvciBiYXNlZCwgb25l IGlzIG1hcCBiYXNlZCwgd2l0aCBkaWZmZXJlbnQgdHJhZGVvZmZzIChhbmQgcHJlc2VydmluZyBz bGlnaHRseSBkaWZmZXJlbnQgaW5mb3JtYXRpb24pLiBIb3dldmVyIEkgZG9uJ3QgdGhpbmsgd2Ug c2hvdWxkIHNwZWNpZnkgYW4gQVBJIGhlcmUuIFB1YmxpY2F0aW9uIG9mIGFuIEFQSSBzZXBhcmF0 ZWx5IChJRCBvciBzb2Z0d2FyZSBkb2N1bWVudGF0aW9uKSBjb3VsZCB3ZWxsIGJlIHVzZWZ1bC4N CkFic29sdXRlbHkuIFJpZ2h0IG5vdywgYXMgSSBzYWlkLCB3ZeKAmXJlIGp1c3QgaGFtbWVyaW5n IG91dCBpZGVhcyDigJQgYW55IHRob3VnaHRzIGxpa2UgdGhlc2UgKG9yIG90aGVycykgZnJvbSBm b2xrcyBoYXZpbmcgYnVpbHQgNTQ0NCBwYXJzZXJzL2dlbmVyYXRvcnMgYXBwcmVjaWF0ZWQNCg0K VGhvbWFzDQoNCj4NCj4gLS0NCj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4gU2VuaW9yIFByaW5j aXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwDQo+IENvbW11bmljYXRp b25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KPiBCQUUgU3lzdGVt cyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KPiBXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQo+IFRlbDogKzQ0IDEyNDUgMjQy MTk0PHRlbDolMkI0NCUyMDEyNDUlMjAyNDIxOTQ+IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0PHRl bDolMkI0NCUyMDEyNDUlMjAyNDIxMjQ+DQo+IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5 c3RlbXMuY29tDQo+DQo+IEJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQo+IFJlZ2lz dGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9z cGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQo+IFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBUaG9tYXMgSGVp ZGUgQ2xhdXNlbg0KPiBTZW50OiAyMiBKdWx5IDIwMTQgMTU6MDkNCj4gVG86IEhlbm5pbmcgUm9n Z2UNCj4gQ2M6IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCj4gU3ViamVj dDogUmU6IFttYW5ldF0gTm90IGp1c3QgNTQ5OCBidXQgYWxzbyA1NDQ0IGNvbXBsaWFuY2UNCj4N Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+ IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCj4gRm9sbG93IHRoZSAnUmVwb3J0IFN1 c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiBy ZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4+IE9uIDIyIEp1bCAy MDE0LCBhdCAxNjowNSAsIEhlbm5pbmcgUm9nZ2UgPGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhv ZmVyLmRlPG1haWx0bzpoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZT4+IHdyb3RlOg0K Pj4NCj4+IE9uIDA3LzIyLzIwMTQgMDM6NTEgUE0sIFRob21hcyBIZWlkZSBDbGF1c2VuIHdyb3Rl Og0KPj4+PiBPbmUgb2YgdGhvc2UgdGhpbmdzIHRoZSBhdXRob3JzIG9mIDU0NDQgZXRjLiB3b3Vs ZCBsaWtlIHRvIGRvIC0gd2hlbg0KPj4+PiB0aGV5IGNhbiBmaW5kIHNvbWUgZXh0cmEgaG91cnMg aW4gYSB3ZWVrIC0gaXMgdG8gc2V0IG91dCB0aGlzIHNvcnQNCj4+Pj4gb2YgZ29vZCBwcmFjdGlj ZSBmb3IgNTQ0NCB0aGF0IGhhcyBiZWVuIGZvdW5kIHRvIGJlIHZhbHVhYmxlLiBJbg0KPj4+PiB0 aGlzIGNhc2Ugd2UgaGF2ZSB0aGUgdHdvIHByaW5jaXBsZXMgb2YgKGEpIGFsd2F5cyBhdHRhY2sg YSBUTFYgdG8NCj4+Pj4gaW5kaWNhdGUgaW5mb3JtYXRpb24sIGFzIGp1c3QgZG9pbmcgc28gZnJv bSBhIG5vbi1UTFZlZCBhZGRyZXNzDQo+Pj4+IHByZWNsdWRlcyB2YXJpb3VzIGV4dGVuc2lvbnMs IGFuZCAoYikgd2hlbiBhdHRhY2hpbmcgaW5mb3JtYXRpb24sDQo+Pj4+IG51bGwgdmFsdWVzIGFy ZSBnb29kIC0gVDpMViBleHRlbnNpb25zIGRpc2N1c3NlcyB3aHksIGEgbG90IGNvbWVzDQo+Pj4+ IGRvd24gdG8gdGhhdCB5b3UgY2FuJ3Qgb3JkZXIgZm9yIG1vcmUgdGhhbiBvbmUgb3IgdHdvIFRM VnMgYXQgb25jZS4NCj4+Pg0KPj4+IFllcywgYW5kIHdpdGggdGhlIGNhdmVhdCB0aGF0IG9uZSBv ZiB0aGUgNTQ0NCBhdXRob3JzIGlzIHRyeWluZyB0bw0KPj4+IGZpbmQgc29tZSBob3VycyB0aGlz IHdlZWsgZm9yIHRoYXQsIHNvIHRoYXQgbWF5IGJlIGZvcnRoY29taW5nIHNvb24uDQo+Pj4NCj4+ PiAoU2VlLCBDaHJpcywgbm93IHlvdSBtYWRlIG1lIGdvIHB1YmxpYyB3aXRoIHRoaXMsIHNvIEkn bSBraW5kYSBvbiB0aGUNCj4+PiBob29rIGZvciBwcm9kdWNpbmcgc29tZXRoaW5nLi4pDQo+Pg0K Pj4gSSB3b3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgaW4gZG9pbmcgdGhpcywgbW9zdGx5IGJlY2F1 c2UgYSBsb3Qgb2YNCj4+IHRoZXNlIGFzc3VtcHRpb25zIChob3cgdG8gZG8gUkZDNTQ0NCkgaGF2 ZSBiZWVuIHB1dCBpbnRvIHRoZSBkZXNpZ24gb2YNCj4+IG15DQo+PiBSRkM1NDQ0IHBhcnNlci9n ZW5lcmF0b3IgQVBJLg0KPj4NCj4+IFRoZSBnZW5lcmF0b3IgQVBJIHN1cHBvcnRzIHRoYXQgbXVs dGlwbGUgcGFydHMgb2YgdGhlIHByb2dyYW0gYXJlDQo+PiBtdWx0aXBsZXhpbmcgZGF0YSBpbnRv IHRoZSBzYW1lIG1lc3NhZ2UsIHNvIHRoZXJlIGlzIG5vIHJlbGlhYmxlIHdheQ0KPj4gdG8gZ3Vh cmFudGVlIHRoZSBwb3NpdGlvbiBvZiBhZGRyZXNzZXMgYW5kIFRMVnMgd2l0aGluIHRoZSBtZXNz YWdlLg0KPj4NCj4+IERvY3VtZW50aW5nIHRoZXNlICdiZXN0IHByYWN0aWNlcycgd291bGQgYmUg aGVscGZ1bCBmb3IgZnVydGhlcg0KPj4gcHJvdG9jb2wgZGVzaWduZXJzLg0KPj4NCj4NCj4gQWJz b2x1dGVseSwgYW5kIHdlICh3ZWxsLCBhdCBsZWFzdCwgSSkgY291bnQgb24gbG9vcGluZyB5b3Ug aW4gb24gdGhpcyBwcm9jZXNzLg0KPg0KPiBDaGVlcnMsDQo+DQo+IFRob21hcw0KPg0KPg0KPj4g SGVubmluZyBSb2dnZQ0KPj4NCj4+IC0tDQo+PiBEaXBsb20tSW5mb3JtYXRpa2VyIEhlbm5pbmcg Um9nZ2UgLCBGcmF1bmhvZmVyLUluc3RpdHV0IGbDvHINCj4+IEtvbW11bmlrYXRpb24sIEluZm9y bWF0aW9uc3ZlcmFyYmVpdHVuZyB1bmQgRXJnb25vbWllIEZLSUUNCj4+IEtvbW11bmlrYXRpb25z c3lzdGVtZSAoS09NKSBGcmF1bmhvZmVyIFN0cmHDn2UgMjAsIDUzMzQzIFdhY2h0YmVyZywNCj4+ IEdlcm1hbnkNCj4+IFRlbGVmb24gKzQ5IDIyOCA5NDM1LTk2MTx0ZWw6JTJCNDklMjAyMjglMjA5 NDM1LTk2MT4sICAgRmF4ICs0OSAyMjggOTQzNSA2ODU8dGVsOiUyQjQ5JTIwMjI4JTIwOTQzNSUy MDY4NT4NCj4+IG1haWx0bzpoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZTxtYWlsdG86 aGVubmluZy5yb2dnZUBma2llLmZyYXVuaG9mZXIuZGU+IGh0dHA6Ly93d3cuZmtpZS5mcmF1bmhv ZmVyLmRlDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1h bmV0QGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t YW5ldA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+ DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPiByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPiByZWNpcGllbnQgcGxlYXNl IGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCj4gWW91 IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9z ZSBvcg0KPiBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KPiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1h bmV0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h bmV0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt YW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF082GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIHRoaW5rIHByaW5jaXBsZXMgYXJlIHdoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgZmly c3QuIFRoZXJlIGFyZSBzb21lIHByaW5jaXBsZXMgdGhhdCBkbyBoYXZlIGEgbm9uLXplcm8gb3Zl cmhlYWQsIGJ1dCBtYWtlIHZhcmlvdXMgb3RoZXIgdGhpbmdzIHBvc3NpYmxlIGFuZA0KIHRodXMg YXJlIHdhbnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBlZmZpY2llbmN5LCB0aGlzIGlzIGhhcmQg4oCTIGFu ZCBhbHNvIHF1YWxpdHkgb2YgaW1wbGVtZW50YXRpb24gaGVyZSBjb3VsZCBiZSBhIHNlbGxpbmcg cG9pbnQuIEJ1dCBUTFYgZXh0ZW5zaW9ucyBjb250YWlucyBzb21lIGZlYXR1cmVzIHRoYXQgc2hv dWxkIChlZmZvcnQNCiBwZXJtaXR0aW5nKSBiZSBjYWxsZWQgb3V0IGFuZCBleGFtcGxlZCAoaWYg dGhhdOKAmXMgYSB3b3JkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0t DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3Jt YXRpb24gQXNzdXJhbmNlIEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJ bWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5v bG9neSBDZW50cmU8YnI+DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7 fCZuYnNwOyBGYXg6ICYjNDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPg0K IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+QkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmlj ZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJl LCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gRGVhbiBbbWFp bHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIyIEp1bHkgMjAx NCAxNjozMDxicj4NCjxiPlRvOjwvYj4gVGhvbWFzIEhlaWRlIENsYXVzZW48YnI+DQo8Yj5DYzo8 L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW21hbmV0XSBOb3QganVzdCA1NDk4IGJ1dCBhbHNvIDU0NDQgY29tcGxp YW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRp bmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRl cm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIg Y2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55 IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9y IGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwv aT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4g dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sg PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwv c3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJy Pg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxl YXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT dXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwv c3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNvdW50IG1lIGluIG9uIHRoZSBlZmZvcnQgYXMgd2VsbC4gJm5ic3A7V2Ugc2hvdWxkIHRh a2Ugbm90ZSB0aGF0IGl0IGlzbid0IGp1c3QgYWJvdXQgaG93IGJlc3QgdG8gY29tcGFjdCBhIHBh Y2tldGJiIG1lc3NhZ2Ugd2l0aCBtdWx0aXBsZSB0bHYgdmFsdWVzIG9mIGRpZmZlcmVudCBwcm90 b2NvbCB0eXBlcyAoYW5kIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBhbmQgdHJhZGVvZmZzKS4g Jm5ic3A7SXQgc2hvdWxkIGFsc28gYmUNCiBhYm91dCB0aGUgZGVzaWduIG9mIHRoZSBmb3JtYXQg YW5kIGJlc3QgcHJhY3RpY2VzIGZvciBkZXNpZ25pbmcgbWVzc2FnZXMsIHRsdnMsIGFuZCBhc3Np Z25pbmcgdmFsdWVzLiAmbmJzcDtIYXZpbmcgYSB3aGF0IG5vdCB0byBkbyBhbmQgd2h5IHNlY3Rp b24gd291bGQgYWxzbyBiZSBoZWxwZnVsLjxicj4NCjxicj4NCkp1c3RpbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEp1bCAyMiwgMjAxNCBhdCAxMDo0MCBBTSwgVGhvbWFzIEhlaWRlIENsYXVz ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0i X2JsYW5rIj50aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCiZndDsgT24gMjIgSnVsIDIwMTQsIGF0IDE2OjI1ICwgRGVhcmxvdmUsIENo cmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBJJ20gZXhwZWN0aW5nIHRvIGJlIGNvbnRyaWJ1dGluZyBhcyBhbiBh dXRob3IgaGVyZSwgYW5kIHlvdXIgaW5wdXQgd2lsbCBiZSB2YWx1YWJsZSBoZXJlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgSeKAmW0gc2l0dGluZyBo ZXJlIHdpdGggVWxyaWNoLCBhbmQgaW4gcGFydCBoYW1tZXJpbmcgaWRlYXMgb3V0IGZvciB0aGVz ZSwgYW5kIHdl4oCZcmUgYWxsIGluIGFncmVlbWVudCBhbHNvLjxicj4NClnigJlhbGwgaGF2ZSBi ZWVuIGltcGxlbWVudGluZyA1NDQ0IHBhcnNlci9nZW5lcmF0b3JzLCBhbmQgc28gdGhhdCBzZWVt cyBleGFjdGx5IHRoZSBleHBlcmllbmNlIG5lY2Vzc2FyeSBmb3IgdGhlc2UgZWZmb3J0cy48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCiZndDsgSSdtIG5vdCBzdXJlIGhvdyBmYXIgdGhpcyBkb2N1bWVu dCB3aWxsIGdldCAoaXQncyBlZmZvcnQgbGltaXRlZCBhcyBoYXMgYmVlbiBzYWlkKS4gSWYgd2Ug Z2V0IHRvIGFuIGFic3RyYWN0IHJlcHJlc2VudGF0aW9uIG9mIDU0NDQgaW5mb3JtYXRpb24gKHdl IG1heSBvciBtYXkgbm90KSB0aGVuIEknbSBhd2FyZSBvZiBhdCBsZWFzdCB0d28gYXBwcm9hY2hl cyB3aXRoIGFkdmFudGFnZXMgb3IgZGlzYWR2YW50YWdlcy4gUm91Z2hseSBzcGVha2luZywNCiBv bmUgaXMgaXRlcmF0b3IgYmFzZWQsIG9uZSBpcyBtYXAgYmFzZWQsIHdpdGggZGlmZmVyZW50IHRy YWRlb2ZmcyAoYW5kIHByZXNlcnZpbmcgc2xpZ2h0bHkgZGlmZmVyZW50IGluZm9ybWF0aW9uKS4g SG93ZXZlciBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBzcGVjaWZ5IGFuIEFQSSBoZXJlLiBQdWJs aWNhdGlvbiBvZiBhbiBBUEkgc2VwYXJhdGVseSAoSUQgb3Igc29mdHdhcmUgZG9jdW1lbnRhdGlv bikgY291bGQgd2VsbCBiZSB1c2VmdWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFic29sdXRlbHkuIFJpZ2h0IG5vdywgYXMgSSBzYWlkLCB3ZeKAmXJlIGp1 c3QgaGFtbWVyaW5nIG91dCBpZGVhcyDigJQgYW55IHRob3VnaHRzIGxpa2UgdGhlc2UgKG9yIG90 aGVycykgZnJvbSBmb2xrcyBoYXZpbmcgYnVpbHQgNTQ0NCBwYXJzZXJzL2dlbmVyYXRvcnMgYXBw cmVjaWF0ZWQ8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xh c3M9ImhvZW56YiI+VGhvbWFzPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQom Z3Q7IENocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KJmd0OyBTZW5pb3IgUHJpbmNpcGFsIEVuZ2lu ZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXA8YnI+DQomZ3Q7IENvbW11bmljYXRpb25z LCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCiZndDsgQkFFIFN5 c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQomZ3Q7IFdlc3QgSGFubmluZ2Zp ZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUs8YnI+DQomZ3Q7 IFRlbDogPGEgaHJlZj0idGVsOiUyQjQ0JTIwMTI0NSUyMDI0MjE5NCI+JiM0Mzs0NCAxMjQ1IDI0 MjE5NDwvYT4gfCAmbmJzcDtGYXg6IDxhIGhyZWY9InRlbDolMkI0NCUyMDEyNDUlMjAyNDIxMjQi Pg0KJiM0Mzs0NCAxMjQ1IDI0MjEyNDwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208 L2E+IHwNCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEJBRSBT eXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KJmd0OyBSZWdpc3RlcmVkIE9mZmljZTog V2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBG YXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NCiZndDsgUmVnaXN0ZXJlZCBpbiBF bmdsYW5kICZhbXA7IFdhbGVzIE5vOiAxOTk2Njg3PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBtYW5ldCBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIj5tYW5ldC1ib3VuY2Vz QGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFRob21hcyBIZWlkZSBDbGF1c2VuPGJyPg0KJmd0 OyBTZW50OiAyMiBKdWx5IDIwMTQgMTU6MDk8YnI+DQomZ3Q7IFRvOiBIZW5uaW5nIFJvZ2dlPGJy Pg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbbWFuZXRdIE5vdCBqdXN0IDU0OTggYnV0IGFs c28gNTQ0NCBjb21wbGlhbmNlPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdp bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVy bmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPGJyPg0KJmd0OyBDb25zaWRlciBjYXJl ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0 YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KJmd0OyBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91 cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGlu ZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLjxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0 OyZndDsgT24gMjIgSnVsIDIwMTQsIGF0IDE2OjA1ICwgSGVubmluZyBSb2dnZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlIj5oZW5uaW5nLnJvZ2dl QGZraWUuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgT24gMDcvMjIvMjAxNCAwMzo1MSBQTSwgVGhvbWFzIEhlaWRlIENsYXVzZW4gd3JvdGU6 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbmUgb2YgdGhvc2UgdGhpbmdzIHRoZSBhdXRob3JzIG9m IDU0NDQgZXRjLiB3b3VsZCBsaWtlIHRvIGRvIC0gd2hlbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg dGhleSBjYW4gZmluZCBzb21lIGV4dHJhIGhvdXJzIGluIGEgd2VlayAtIGlzIHRvIHNldCBvdXQg dGhpcyBzb3J0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBvZiBnb29kIHByYWN0aWNlIGZvciA1NDQ0 IHRoYXQgaGFzIGJlZW4gZm91bmQgdG8gYmUgdmFsdWFibGUuIEluPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyB0aGlzIGNhc2Ugd2UgaGF2ZSB0aGUgdHdvIHByaW5jaXBsZXMgb2YgKGEpIGFsd2F5cyBh dHRhY2sgYSBUTFYgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGluZGljYXRlIGluZm9ybWF0aW9u LCBhcyBqdXN0IGRvaW5nIHNvIGZyb20gYSBub24tVExWZWQgYWRkcmVzczxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgcHJlY2x1ZGVzIHZhcmlvdXMgZXh0ZW5zaW9ucywgYW5kIChiKSB3aGVuIGF0dGFj aGluZyBpbmZvcm1hdGlvbiw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG51bGwgdmFsdWVzIGFyZSBn b29kIC0gVDpMViBleHRlbnNpb25zIGRpc2N1c3NlcyB3aHksIGEgbG90IGNvbWVzPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBkb3duIHRvIHRoYXQgeW91IGNhbid0IG9yZGVyIGZvciBtb3JlIHRoYW4g b25lIG9yIHR3byBUTFZzIGF0IG9uY2UuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IFllcywgYW5kIHdpdGggdGhlIGNhdmVhdCB0aGF0IG9uZSBvZiB0aGUgNTQ0NCBhdXRob3Jz IGlzIHRyeWluZyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyBmaW5kIHNvbWUgaG91cnMgdGhpcyB3ZWVr IGZvciB0aGF0LCBzbyB0aGF0IG1heSBiZSBmb3J0aGNvbWluZyBzb29uLjxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAoU2VlLCBDaHJpcywgbm93IHlvdSBtYWRlIG1lIGdvIHB1 YmxpYyB3aXRoIHRoaXMsIHNvIEknbSBraW5kYSBvbiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgaG9v ayBmb3IgcHJvZHVjaW5nIHNvbWV0aGluZy4uKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg SSB3b3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgaW4gZG9pbmcgdGhpcywgbW9zdGx5IGJlY2F1c2Ug YSBsb3Qgb2Y8YnI+DQomZ3Q7Jmd0OyB0aGVzZSBhc3N1bXB0aW9ucyAoaG93IHRvIGRvIFJGQzU0 NDQpIGhhdmUgYmVlbiBwdXQgaW50byB0aGUgZGVzaWduIG9mPGJyPg0KJmd0OyZndDsgbXk8YnI+ DQomZ3Q7Jmd0OyBSRkM1NDQ0IHBhcnNlci9nZW5lcmF0b3IgQVBJLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgVGhlIGdlbmVyYXRvciBBUEkgc3VwcG9ydHMgdGhhdCBtdWx0aXBsZSBwYXJ0 cyBvZiB0aGUgcHJvZ3JhbSBhcmU8YnI+DQomZ3Q7Jmd0OyBtdWx0aXBsZXhpbmcgZGF0YSBpbnRv IHRoZSBzYW1lIG1lc3NhZ2UsIHNvIHRoZXJlIGlzIG5vIHJlbGlhYmxlIHdheTxicj4NCiZndDsm Z3Q7IHRvIGd1YXJhbnRlZSB0aGUgcG9zaXRpb24gb2YgYWRkcmVzc2VzIGFuZCBUTFZzIHdpdGhp biB0aGUgbWVzc2FnZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IERvY3VtZW50aW5nIHRo ZXNlICdiZXN0IHByYWN0aWNlcycgd291bGQgYmUgaGVscGZ1bCBmb3IgZnVydGhlcjxicj4NCiZn dDsmZ3Q7IHByb3RvY29sIGRlc2lnbmVycy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IEFic29sdXRlbHksIGFuZCB3ZSAod2VsbCwgYXQgbGVhc3QsIEkpIGNvdW50IG9uIGxvb3Bp bmcgeW91IGluIG9uIHRoaXMgcHJvY2Vzcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaGVlcnMsPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhvbWFzPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0 OyBIZW5uaW5nIFJvZ2dlPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLTxicj4NCiZndDsm Z3Q7IERpcGxvbS1JbmZvcm1hdGlrZXIgSGVubmluZyBSb2dnZSAsIEZyYXVuaG9mZXItSW5zdGl0 dXQgZsO8cjxicj4NCiZndDsmZ3Q7IEtvbW11bmlrYXRpb24sIEluZm9ybWF0aW9uc3ZlcmFyYmVp dHVuZyB1bmQgRXJnb25vbWllIEZLSUU8YnI+DQomZ3Q7Jmd0OyBLb21tdW5pa2F0aW9uc3N5c3Rl bWUgKEtPTSkgRnJhdW5ob2ZlciBTdHJhw59lIDIwLCA1MzM0MyBXYWNodGJlcmcsPGJyPg0KJmd0 OyZndDsgR2VybWFueTxicj4NCiZndDsmZ3Q7IFRlbGVmb24gPGEgaHJlZj0idGVsOiUyQjQ5JTIw MjI4JTIwOTQzNS05NjEiPiYjNDM7NDkgMjI4IDk0MzUtOTYxPC9hPiwgJm5ic3A7IEZheCA8YSBo cmVmPSJ0ZWw6JTJCNDklMjAyMjglMjA5NDM1JTIwNjg1Ij4NCiYjNDM7NDkgMjI4IDk0MzUgNjg1 PC9hPjxicj4NCiZndDsmZ3Q7IG1haWx0bzo8YSBocmVmPSJtYWlsdG86aGVubmluZy5yb2dnZUBm a2llLmZyYXVuaG9mZXIuZGUiPmhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlPC9hPg0K PGEgaHJlZj0iaHR0cDovL3d3dy5ma2llLmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LmZraWUuZnJhdW5ob2Zlci5kZTwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyZndDsgbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv Om1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJy Pg0KJmd0Ozxicj4NCiZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCiZndDsg cmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQ8YnI+DQomZ3Q7IHJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBz eXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCiZndDsgWW91IHNob3VsZCBub3QgY29w eSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCiZndDsg ZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQomZ3Q7ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZn dDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF082GLKXM0002VGREEN_-- From nobody Tue Jul 22 08:55:28 2014 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 245C31A00B8 for ; Tue, 22 Jul 2014 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 xEgmxUzCQi46 for ; Tue, 22 Jul 2014 08:55:24 -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 AAFD41B2959 for ; Tue, 22 Jul 2014 08:55:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="459865510" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 16:55:22 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="58654640" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 16:55:03 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 16:55:02 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , Justin Dean Thread-Topic: [manet] Not just 5498 but also 5444 compliance Thread-Index: AQHPpbYXuIaZrHbN8kGd1/etmzcqO5usELGAgAAT1WD///TzgIAADgMAgAABOoCAABVvcA== Date: Tue, 22 Jul 2014 15:55:00 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> <8315A8D1-2ED0-47E2-82A5-930832C34D4A@thomasclausen.org> <44ACC15D-C5DC-47FA-A62F-D01D9C7DEF9A@thomasclausen.org> In-Reply-To: <44ACC15D-C5DC-47FA-A62F-D01D9C7DEF9A@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF097GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rS9rKFnLDjiBtdwOGP8uDyvaPcs Cc: "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 15:55:27 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF097GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGVyZeKAmXMgc29tZSBvdmVybGFwLiBGb3IgZXhhbXBsZSB0aGUgcHJpbmNpcGxl IHRoYXQgaWYgeW91IGNyZWF0ZSBhbiBhZGRyZXNzIGJsb2NrIFRMViB3aG9zZSB2YWx1ZXMgZW51 bWVyYXRlIG1lYW5pbmdzIHRoYXQgYW4gdW5zcGVjaWZpZWQgdmFsdWUgaXMgYSBnb29kIHRoaW5n IHRvIGhhdmUgKFJGQyA3MTg4KSBpcyBmb3IgZWZmaWNpZW5jeSByZWFzb25zLiBFeHBsYWluaW5n IHdoeSBnZXRzIHlvdSBhIGJpdCBpbnRvIDU0NDQgY29tcGFjdGlvbi4NCg0KLS0NCkNocmlzdG9w aGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1 cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMg Q2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3Qg SGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsN ClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+ IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykg TGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFy bmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwg VUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZyb206IFRo b21hcyBIZWlkZSBDbGF1c2VuIFttYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnXQ0KU2Vu dDogMjIgSnVseSAyMDE0IDE2OjM1DQpUbzogSnVzdGluIERlYW4NCkNjOiBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKTsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIE5vdCBq dXN0IDU0OTggYnV0IGFsc28gNTQ0NCBjb21wbGlhbmNlDQoNCg0KKioqIFdBUk5JTkcgKioqDQpU aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0 aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBj YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg YXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFn cyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sg aGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhl IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQpP biAyMiBKdWwgMjAxNCwgYXQgMTc6MzAgLCBKdXN0aW4gRGVhbiA8YmViZW1hc3RlckBnbWFpbC5j b208bWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tPj4gd3JvdGU6DQoNCkNvdW50IG1lIGluIG9u IHRoZSBlZmZvcnQgYXMgd2VsbC4gIFdlIHNob3VsZCB0YWtlIG5vdGUgdGhhdCBpdCBpc24ndCBq dXN0IGFib3V0IGhvdyBiZXN0IHRvIGNvbXBhY3QgYSBwYWNrZXRiYiBtZXNzYWdlIHdpdGggbXVs dGlwbGUgdGx2IHZhbHVlcyBvZiBkaWZmZXJlbnQgcHJvdG9jb2wgdHlwZXMgKGFuZCB0aGVyZSBh cmUgZGlmZmVyZW50IHdheXMgYW5kIHRyYWRlb2ZmcykuICBJdCBzaG91bGQgYWxzbyBiZSBhYm91 dCB0aGUgZGVzaWduIG9mIHRoZSBmb3JtYXQgYW5kIGJlc3QgcHJhY3RpY2VzIGZvciBkZXNpZ25p bmcgbWVzc2FnZXMsIHRsdnMsIGFuZCBhc3NpZ25pbmcgdmFsdWVzLiAgSGF2aW5nIGEgd2hhdCBu b3QgdG8gZG8gYW5kIHdoeSBzZWN0aW9uIHdvdWxkIGFsc28gYmUgaGVscGZ1bC4NCg0KQWN0dWFs bHksIGl0IGlzIG5vdCBhdCBhbGwgYWJvdXQgaG93IHRvIGJlc3QgY29tcGFjdCBhIDU0NDQtbWVz c2FnZS4gVGhhdOKAmXMgaW50ZXJlc3RpbmcsIGJ1dCBmb3IgYSBkaWZmZXJlbnQgSS1EICh3aGlj aCBJIGhvcGUgdGhhdCBzb21lb25lIHdpbGwgd3JpdGUpLg0KDQpUaGlzIGVmZm9ydCBpcyBhYm91 dCB0aGUgZGVzaWduIG9mIHRoZSBmb3JtYXQsIGhvdyB0byB1c2UgaXQgaW4gd2F5cyB0aGF0IGVu YWJsZSBnZW5lcmljIHBhcnNpbmcgYW5kIGdlbmVyYXRpb24gbWFjaGluZXJ5LCBhbmQg4oCUIGFz IHlvdSBzYXkg4oCUIGJlc3QgcHJhY3RpY2VzIChpbmNsdWRpbmcgZm9yIG1hbmFnaW5nIHRoZSBj b2RlLXBvaW50IHNwYWNlcykuDQoNCknigJltIGFjdHVhbGx5IHN0YXJ0aW5nIHRvIHRoaW5rIHRo YXQgdGhlcmXigJlyZSB0d28gZG9jdW1lbnRzIGhlcmUsIGEgNTQ0NC1yYXRpb25hbGUsIGFuZCBh IDU0NDQtdXNhZ2Ug4oCUIGRpZmZlcmVudCwgYnV0IHByb2JhYmx5IGJvdGggdmVyeSBpbnRlcmVz dGluZy4NCg0KVGhvbWFzDQoNCg0KDQpKdXN0aW4NCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQg MTA6NDAgQU0sIFRob21hcyBIZWlkZSBDbGF1c2VuIDx0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmc8 bWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZz4+IHdyb3RlOg0KDQo+IE9uIDIyIEp1bCAy MDE0LCBhdCAxNjoyNSAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3 cm90ZToNCj4NCj4gSSdtIGV4cGVjdGluZyB0byBiZSBjb250cmlidXRpbmcgYXMgYW4gYXV0aG9y IGhlcmUsIGFuZCB5b3VyIGlucHV0IHdpbGwgYmUgdmFsdWFibGUgaGVyZS4NCkFuZCBJ4oCZbSBz aXR0aW5nIGhlcmUgd2l0aCBVbHJpY2gsIGFuZCBpbiBwYXJ0IGhhbW1lcmluZyBpZGVhcyBvdXQg Zm9yIHRoZXNlLCBhbmQgd2XigJlyZSBhbGwgaW4gYWdyZWVtZW50IGFsc28uDQpZ4oCZYWxsIGhh dmUgYmVlbiBpbXBsZW1lbnRpbmcgNTQ0NCBwYXJzZXIvZ2VuZXJhdG9ycywgYW5kIHNvIHRoYXQg c2VlbXMgZXhhY3RseSB0aGUgZXhwZXJpZW5jZSBuZWNlc3NhcnkgZm9yIHRoZXNlIGVmZm9ydHMu DQoNCj4gSSdtIG5vdCBzdXJlIGhvdyBmYXIgdGhpcyBkb2N1bWVudCB3aWxsIGdldCAoaXQncyBl ZmZvcnQgbGltaXRlZCBhcyBoYXMgYmVlbiBzYWlkKS4gSWYgd2UgZ2V0IHRvIGFuIGFic3RyYWN0 IHJlcHJlc2VudGF0aW9uIG9mIDU0NDQgaW5mb3JtYXRpb24gKHdlIG1heSBvciBtYXkgbm90KSB0 aGVuIEknbSBhd2FyZSBvZiBhdCBsZWFzdCB0d28gYXBwcm9hY2hlcyB3aXRoIGFkdmFudGFnZXMg b3IgZGlzYWR2YW50YWdlcy4gUm91Z2hseSBzcGVha2luZywgb25lIGlzIGl0ZXJhdG9yIGJhc2Vk LCBvbmUgaXMgbWFwIGJhc2VkLCB3aXRoIGRpZmZlcmVudCB0cmFkZW9mZnMgKGFuZCBwcmVzZXJ2 aW5nIHNsaWdodGx5IGRpZmZlcmVudCBpbmZvcm1hdGlvbikuIEhvd2V2ZXIgSSBkb24ndCB0aGlu ayB3ZSBzaG91bGQgc3BlY2lmeSBhbiBBUEkgaGVyZS4gUHVibGljYXRpb24gb2YgYW4gQVBJIHNl cGFyYXRlbHkgKElEIG9yIHNvZnR3YXJlIGRvY3VtZW50YXRpb24pIGNvdWxkIHdlbGwgYmUgdXNl ZnVsLg0KQWJzb2x1dGVseS4gUmlnaHQgbm93LCBhcyBJIHNhaWQsIHdl4oCZcmUganVzdCBoYW1t ZXJpbmcgb3V0IGlkZWFzIOKAlCBhbnkgdGhvdWdodHMgbGlrZSB0aGVzZSAob3Igb3RoZXJzKSBm cm9tIGZvbGtzIGhhdmluZyBidWlsdCA1NDQ0IHBhcnNlcnMvZ2VuZXJhdG9ycyBhcHByZWNpYXRl ZA0KDQpUaG9tYXMNCg0KPg0KPiAtLQ0KPiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KPiBTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCj4gQ29tbXVu aWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQo+IEJBRSBT eXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQo+IFdlc3QgSGFubmluZ2ZpZWxkIFJv YWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNCj4gVGVsOiArNDQgMTI0 NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwMTI0NSUyMDI0MjE5ND4gfCAgRmF4OiArNDQgMTI0NSAyNDIx MjQ8dGVsOiUyQjQ0JTIwMTI0NSUyMDI0MjEyND4NCj4gY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0dHA6Ly93d3cu YmFlc3lzdGVtcy5jb208aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS8+DQo+DQo+IEJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQo+IFJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhv dXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdo LCBIYW50cywgR1UxNCA2WVUsIFVLDQo+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5v OiAxOTk2Njg3DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1h bmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBUaG9tYXMgSGVpZGUgQ2xhdXNlbg0KPiBTZW50OiAyMiBK dWx5IDIwMTQgMTU6MDkNCj4gVG86IEhlbm5pbmcgUm9nZ2UNCj4gQ2M6IG1hbmV0QGlldGYub3Jn PG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFttYW5ldF0gTm90IGp1c3Qg NTQ5OCBidXQgYWxzbyA1NDQ0IGNvbXBsaWFuY2UNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs IHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0 aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBv ciByZXBseS4NCj4gRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9u IElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFp bCBtZXNzYWdlcy4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4NCj4+IE9uIDIyIEp1bCAyMDE0LCBhdCAxNjowNSAsIEhlbm5pbmcg Um9nZ2UgPGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5uaW5nLnJv Z2dlQGZraWUuZnJhdW5ob2Zlci5kZT4+IHdyb3RlOg0KPj4NCj4+IE9uIDA3LzIyLzIwMTQgMDM6 NTEgUE0sIFRob21hcyBIZWlkZSBDbGF1c2VuIHdyb3RlOg0KPj4+PiBPbmUgb2YgdGhvc2UgdGhp bmdzIHRoZSBhdXRob3JzIG9mIDU0NDQgZXRjLiB3b3VsZCBsaWtlIHRvIGRvIC0gd2hlbg0KPj4+ PiB0aGV5IGNhbiBmaW5kIHNvbWUgZXh0cmEgaG91cnMgaW4gYSB3ZWVrIC0gaXMgdG8gc2V0IG91 dCB0aGlzIHNvcnQNCj4+Pj4gb2YgZ29vZCBwcmFjdGljZSBmb3IgNTQ0NCB0aGF0IGhhcyBiZWVu IGZvdW5kIHRvIGJlIHZhbHVhYmxlLiBJbg0KPj4+PiB0aGlzIGNhc2Ugd2UgaGF2ZSB0aGUgdHdv IHByaW5jaXBsZXMgb2YgKGEpIGFsd2F5cyBhdHRhY2sgYSBUTFYgdG8NCj4+Pj4gaW5kaWNhdGUg aW5mb3JtYXRpb24sIGFzIGp1c3QgZG9pbmcgc28gZnJvbSBhIG5vbi1UTFZlZCBhZGRyZXNzDQo+ Pj4+IHByZWNsdWRlcyB2YXJpb3VzIGV4dGVuc2lvbnMsIGFuZCAoYikgd2hlbiBhdHRhY2hpbmcg aW5mb3JtYXRpb24sDQo+Pj4+IG51bGwgdmFsdWVzIGFyZSBnb29kIC0gVDpMViBleHRlbnNpb25z IGRpc2N1c3NlcyB3aHksIGEgbG90IGNvbWVzDQo+Pj4+IGRvd24gdG8gdGhhdCB5b3UgY2FuJ3Qg b3JkZXIgZm9yIG1vcmUgdGhhbiBvbmUgb3IgdHdvIFRMVnMgYXQgb25jZS4NCj4+Pg0KPj4+IFll cywgYW5kIHdpdGggdGhlIGNhdmVhdCB0aGF0IG9uZSBvZiB0aGUgNTQ0NCBhdXRob3JzIGlzIHRy eWluZyB0bw0KPj4+IGZpbmQgc29tZSBob3VycyB0aGlzIHdlZWsgZm9yIHRoYXQsIHNvIHRoYXQg bWF5IGJlIGZvcnRoY29taW5nIHNvb24uDQo+Pj4NCj4+PiAoU2VlLCBDaHJpcywgbm93IHlvdSBt YWRlIG1lIGdvIHB1YmxpYyB3aXRoIHRoaXMsIHNvIEknbSBraW5kYSBvbiB0aGUNCj4+PiBob29r IGZvciBwcm9kdWNpbmcgc29tZXRoaW5nLi4pDQo+Pg0KPj4gSSB3b3VsZCBhbHNvIGJlIGludGVy ZXN0ZWQgaW4gZG9pbmcgdGhpcywgbW9zdGx5IGJlY2F1c2UgYSBsb3Qgb2YNCj4+IHRoZXNlIGFz c3VtcHRpb25zIChob3cgdG8gZG8gUkZDNTQ0NCkgaGF2ZSBiZWVuIHB1dCBpbnRvIHRoZSBkZXNp Z24gb2YNCj4+IG15DQo+PiBSRkM1NDQ0IHBhcnNlci9nZW5lcmF0b3IgQVBJLg0KPj4NCj4+IFRo ZSBnZW5lcmF0b3IgQVBJIHN1cHBvcnRzIHRoYXQgbXVsdGlwbGUgcGFydHMgb2YgdGhlIHByb2dy YW0gYXJlDQo+PiBtdWx0aXBsZXhpbmcgZGF0YSBpbnRvIHRoZSBzYW1lIG1lc3NhZ2UsIHNvIHRo ZXJlIGlzIG5vIHJlbGlhYmxlIHdheQ0KPj4gdG8gZ3VhcmFudGVlIHRoZSBwb3NpdGlvbiBvZiBh ZGRyZXNzZXMgYW5kIFRMVnMgd2l0aGluIHRoZSBtZXNzYWdlLg0KPj4NCj4+IERvY3VtZW50aW5n IHRoZXNlICdiZXN0IHByYWN0aWNlcycgd291bGQgYmUgaGVscGZ1bCBmb3IgZnVydGhlcg0KPj4g cHJvdG9jb2wgZGVzaWduZXJzLg0KPj4NCj4NCj4gQWJzb2x1dGVseSwgYW5kIHdlICh3ZWxsLCBh dCBsZWFzdCwgSSkgY291bnQgb24gbG9vcGluZyB5b3UgaW4gb24gdGhpcyBwcm9jZXNzLg0KPg0K PiBDaGVlcnMsDQo+DQo+IFRob21hcw0KPg0KPg0KPj4gSGVubmluZyBSb2dnZQ0KPj4NCj4+IC0t DQo+PiBEaXBsb20tSW5mb3JtYXRpa2VyIEhlbm5pbmcgUm9nZ2UgLCBGcmF1bmhvZmVyLUluc3Rp dHV0IGbDvHINCj4+IEtvbW11bmlrYXRpb24sIEluZm9ybWF0aW9uc3ZlcmFyYmVpdHVuZyB1bmQg RXJnb25vbWllIEZLSUUNCj4+IEtvbW11bmlrYXRpb25zc3lzdGVtZSAoS09NKSBGcmF1bmhvZmVy IFN0cmHDn2UgMjAsIDUzMzQzIFdhY2h0YmVyZywNCj4+IEdlcm1hbnkNCj4+IFRlbGVmb24gKzQ5 IDIyOCA5NDM1LTk2MTx0ZWw6JTJCNDklMjAyMjglMjA5NDM1LTk2MT4sICAgRmF4ICs0OSAyMjgg OTQzNSA2ODU8dGVsOiUyQjQ5JTIwMjI4JTIwOTQzNSUyMDY4NT4NCj4+IG1haWx0bzpoZW5uaW5n LnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGU+IGh0dHA6Ly93d3cuZmtpZS5mcmF1bmhvZmVyLmRlPGh0dHA6Ly93d3cuZmtpZS5m cmF1bmhvZmVyLmRlLz4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+PiBtYW5ldEBpZXRmLm9yZzxt YWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86 bWFuZXRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQNCj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+IHJlY2lwaWVu dCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVy Lg0KPiBZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9y IGRpc2Nsb3NlIG9yDQo+IGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24uDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZzxt YWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoN Cg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF097GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZXJl4oCZcyBzb21lIG92ZXJsYXAuIEZvciBleGFtcGxl IHRoZSBwcmluY2lwbGUgdGhhdCBpZiB5b3UgY3JlYXRlIGFuIGFkZHJlc3MgYmxvY2sgVExWIHdo b3NlIHZhbHVlcyBlbnVtZXJhdGUgbWVhbmluZ3MgdGhhdCBhbiB1bnNwZWNpZmllZCB2YWx1ZSBp cw0KIGEgZ29vZCB0aGluZyB0byBoYXZlIChSRkMgNzE4OCkgaXMgZm9yIGVmZmljaWVuY3kgcmVh c29ucy4gRXhwbGFpbmluZyB3aHkgZ2V0cyB5b3UgYSBiaXQgaW50byA1NDQ0IGNvbXBhY3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS0NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rv cGhlciBEZWFybG92ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5TZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1 cmFuY2UgR3JvdXA8YnI+DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5 c2lzIENhcGFiaWxpdHk8YnI+DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRy ZTxicj4NCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg Q00yIDhITiwgVUs8YnI+DQpUZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7IEZh eDogJiM0Mzs0NCAxMjQ1IDI0MjEyNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpu b25lIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+DQogfCBodHRwOi8v d3d3LmJhZXN5c3RlbXMuY29tPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CQUUgU3lz dGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNr IEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3Jv dWdoLCBIYW50cywgR1UxNCA2WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7 IFdhbGVzIE5vOiAxOTk2Njg3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFRob21hcyBIZWlkZSBDbGF1c2VuIFttYWlsdG86dGhvbWFzQHRob21h c2NsYXVzZW4ub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIyIEp1bHkgMjAxNCAxNjozNTxicj4N CjxiPlRvOjwvYj4gSnVzdGluIERlYW48YnI+DQo8Yj5DYzo8L2I+IERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBOb3QganVzdCA1NDk4IGJ1dCBhbHNvIDU0NDQgY29tcGxpYW5jZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIu MHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNr Z3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi PioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwg cGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVm dWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRh Y2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZv cm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9z dHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQg eW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhy ZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5 L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+ PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBm b2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3 b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGlj aW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+ PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIy IEp1bCAyMDE0LCBhdCAxNzozMCAsIEp1c3RpbiBEZWFuICZsdDs8YSBocmVmPSJtYWlsdG86YmVi ZW1hc3RlckBnbWFpbC5jb20iPmJlYmVtYXN0ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkNvdW50IG1lIGluIG9uIHRoZSBlZmZvcnQgYXMgd2VsbC4gJm5ic3A7 V2Ugc2hvdWxkIHRha2Ugbm90ZSB0aGF0IGl0IGlzbid0IGp1c3QgYWJvdXQgaG93IGJlc3QgdG8g Y29tcGFjdCBhIHBhY2tldGJiIG1lc3NhZ2Ugd2l0aCBtdWx0aXBsZSB0bHYgdmFsdWVzIG9mIGRp ZmZlcmVudCBwcm90b2NvbCB0eXBlcyAoYW5kIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBhbmQN CiB0cmFkZW9mZnMpLiAmbmJzcDtJdCBzaG91bGQgYWxzbyBiZSBhYm91dCB0aGUgZGVzaWduIG9m IHRoZSBmb3JtYXQgYW5kIGJlc3QgcHJhY3RpY2VzIGZvciBkZXNpZ25pbmcgbWVzc2FnZXMsIHRs dnMsIGFuZCBhc3NpZ25pbmcgdmFsdWVzLiAmbmJzcDtIYXZpbmcgYSB3aGF0IG5vdCB0byBkbyBh bmQgd2h5IHNlY3Rpb24gd291bGQgYWxzbyBiZSBoZWxwZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFs bHksIGl0IGlzIG5vdCBhdCBhbGwgYWJvdXQgaG93IHRvIGJlc3QgY29tcGFjdCBhIDU0NDQtbWVz c2FnZS4gVGhhdOKAmXMgaW50ZXJlc3RpbmcsIGJ1dCBmb3IgYSBkaWZmZXJlbnQgSS1EICh3aGlj aCBJIGhvcGUgdGhhdCBzb21lb25lIHdpbGwgd3JpdGUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVmZm9ydCBpcyBhYm91dCB0aGUg ZGVzaWduIG9mIHRoZSBmb3JtYXQsIGhvdyB0byB1c2UgaXQgaW4gd2F5cyB0aGF0IGVuYWJsZSBn ZW5lcmljIHBhcnNpbmcgYW5kIGdlbmVyYXRpb24gbWFjaGluZXJ5LCBhbmQg4oCUIGFzIHlvdSBz YXkg4oCUIGJlc3QgcHJhY3RpY2VzIChpbmNsdWRpbmcgZm9yIG1hbmFnaW5nIHRoZSBjb2RlLXBv aW50IHNwYWNlcykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPknigJltIGFjdHVhbGx5IHN0YXJ0aW5nIHRvIHRoaW5rIHRoYXQgdGhlcmXigJly ZSB0d28gZG9jdW1lbnRzIGhlcmUsIGEgNTQ0NC1yYXRpb25hbGUsIGFuZCBhIDU0NDQtdXNhZ2Ug 4oCUIGRpZmZlcmVudCwgYnV0IHByb2JhYmx5IGJvdGggdmVyeSBpbnRlcmVzdGluZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5KdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgMTA6NDAg QU0sIFRob21hcyBIZWlkZSBDbGF1c2VuICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzQHRob21h c2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQomZ3Q7IE9uIDIyIEp1bCAyMDE0LCBh dCAxNjoyNSAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSSdtIGV4cGVjdGluZyB0byBi ZSBjb250cmlidXRpbmcgYXMgYW4gYXV0aG9yIGhlcmUsIGFuZCB5b3VyIGlucHV0IHdpbGwgYmUg dmFsdWFibGUgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QW5kIEnigJltIHNpdHRpbmcgaGVyZSB3aXRoIFVscmljaCwgYW5kIGluIHBhcnQgaGFtbWVy aW5nIGlkZWFzIG91dCBmb3IgdGhlc2UsIGFuZCB3ZeKAmXJlIGFsbCBpbiBhZ3JlZW1lbnQgYWxz by48YnI+DQpZ4oCZYWxsIGhhdmUgYmVlbiBpbXBsZW1lbnRpbmcgNTQ0NCBwYXJzZXIvZ2VuZXJh dG9ycywgYW5kIHNvIHRoYXQgc2VlbXMgZXhhY3RseSB0aGUgZXhwZXJpZW5jZSBuZWNlc3Nhcnkg Zm9yIHRoZXNlIGVmZm9ydHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQomZ3Q7IEknbSBub3Qgc3Vy ZSBob3cgZmFyIHRoaXMgZG9jdW1lbnQgd2lsbCBnZXQgKGl0J3MgZWZmb3J0IGxpbWl0ZWQgYXMg aGFzIGJlZW4gc2FpZCkuIElmIHdlIGdldCB0byBhbiBhYnN0cmFjdCByZXByZXNlbnRhdGlvbiBv ZiA1NDQ0IGluZm9ybWF0aW9uICh3ZSBtYXkgb3IgbWF5IG5vdCkgdGhlbiBJJ20gYXdhcmUgb2Yg YXQgbGVhc3QgdHdvIGFwcHJvYWNoZXMgd2l0aCBhZHZhbnRhZ2VzIG9yIGRpc2FkdmFudGFnZXMu IFJvdWdobHkgc3BlYWtpbmcsDQogb25lIGlzIGl0ZXJhdG9yIGJhc2VkLCBvbmUgaXMgbWFwIGJh c2VkLCB3aXRoIGRpZmZlcmVudCB0cmFkZW9mZnMgKGFuZCBwcmVzZXJ2aW5nIHNsaWdodGx5IGRp ZmZlcmVudCBpbmZvcm1hdGlvbikuIEhvd2V2ZXIgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgc3Bl Y2lmeSBhbiBBUEkgaGVyZS4gUHVibGljYXRpb24gb2YgYW4gQVBJIHNlcGFyYXRlbHkgKElEIG9y IHNvZnR3YXJlIGRvY3VtZW50YXRpb24pIGNvdWxkIHdlbGwgYmUgdXNlZnVsLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYnNvbHV0ZWx5LiBSaWdodCBub3cs IGFzIEkgc2FpZCwgd2XigJlyZSBqdXN0IGhhbW1lcmluZyBvdXQgaWRlYXMg4oCUIGFueSB0aG91 Z2h0cyBsaWtlIHRoZXNlIChvciBvdGhlcnMpIGZyb20gZm9sa3MgaGF2aW5nIGJ1aWx0IDU0NDQg cGFyc2Vycy9nZW5lcmF0b3JzIGFwcHJlY2lhdGVkPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPlRob21hczwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZn dDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCiZndDsg U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwPGJy Pg0KJmd0OyBDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFi aWxpdHk8YnI+DQomZ3Q7IEJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJy Pg0KJmd0OyBXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IENNMiA4SE4sIFVLPGJyPg0KJmd0OyBUZWw6IDxhIGhyZWY9InRlbDolMkI0NCUyMDEyNDUlMjAy NDIxOTQiPiYjNDM7NDQgMTI0NSAyNDIxOTQ8L2E+IHwgJm5ic3A7RmF4OiA8YSBocmVmPSJ0ZWw6 JTJCNDQlMjAxMjQ1JTIwMjQyMTI0Ij4NCiYjNDM7NDQgMTI0NSAyNDIxMjQ8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiB8DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208L2E+PGJy Pg0KJmd0Ozxicj4NCiZndDsgQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQom Z3Q7IFJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3Jv dWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLPGJy Pg0KJmd0OyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7IEZyb206IG1hbmV0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNA aWV0Zi5vcmciPm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVGhvbWFz IEhlaWRlIENsYXVzZW48YnI+DQomZ3Q7IFNlbnQ6IDIyIEp1bHkgMjAxNCAxNTowOTxicj4NCiZn dDsgVG86IEhlbm5pbmcgUm9nZ2U8YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFttYW5l dF0gTm90IGp1c3QgNTQ5OCBidXQgYWxzbyA1NDQ0IGNvbXBsaWFuY2U8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48 YnI+DQomZ3Q7IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQomZ3Q7IEZvbGxv dyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBp bnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuPGJyPg0K Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiAyMiBKdWwgMjAxNCwgYXQgMTY6MDUgLCBI ZW5uaW5nIFJvZ2dlICZsdDs8YSBocmVmPSJtYWlsdG86aGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUiPmhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiAwNy8yMi8yMDE0IDAzOjUxIFBNLCBUaG9t YXMgSGVpZGUgQ2xhdXNlbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uZSBvZiB0aG9z ZSB0aGluZ3MgdGhlIGF1dGhvcnMgb2YgNTQ0NCBldGMuIHdvdWxkIGxpa2UgdG8gZG8gLSB3aGVu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0aGV5IGNhbiBmaW5kIHNvbWUgZXh0cmEgaG91cnMgaW4g YSB3ZWVrIC0gaXMgdG8gc2V0IG91dCB0aGlzIHNvcnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG9m IGdvb2QgcHJhY3RpY2UgZm9yIDU0NDQgdGhhdCBoYXMgYmVlbiBmb3VuZCB0byBiZSB2YWx1YWJs ZS4gSW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgY2FzZSB3ZSBoYXZlIHRoZSB0d28gcHJp bmNpcGxlcyBvZiAoYSkgYWx3YXlzIGF0dGFjayBhIFRMViB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgaW5kaWNhdGUgaW5mb3JtYXRpb24sIGFzIGp1c3QgZG9pbmcgc28gZnJvbSBhIG5vbi1UTFZl ZCBhZGRyZXNzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBwcmVjbHVkZXMgdmFyaW91cyBleHRlbnNp b25zLCBhbmQgKGIpIHdoZW4gYXR0YWNoaW5nIGluZm9ybWF0aW9uLDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgbnVsbCB2YWx1ZXMgYXJlIGdvb2QgLSBUOkxWIGV4dGVuc2lvbnMgZGlzY3Vzc2VzIHdo eSwgYSBsb3QgY29tZXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRvd24gdG8gdGhhdCB5b3UgY2Fu J3Qgb3JkZXIgZm9yIG1vcmUgdGhhbiBvbmUgb3IgdHdvIFRMVnMgYXQgb25jZS48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgWWVzLCBhbmQgd2l0aCB0aGUgY2F2ZWF0IHRoYXQg b25lIG9mIHRoZSA1NDQ0IGF1dGhvcnMgaXMgdHJ5aW5nIHRvPGJyPg0KJmd0OyZndDsmZ3Q7IGZp bmQgc29tZSBob3VycyB0aGlzIHdlZWsgZm9yIHRoYXQsIHNvIHRoYXQgbWF5IGJlIGZvcnRoY29t aW5nIHNvb24uPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IChTZWUsIENocmlz LCBub3cgeW91IG1hZGUgbWUgZ28gcHVibGljIHdpdGggdGhpcywgc28gSSdtIGtpbmRhIG9uIHRo ZTxicj4NCiZndDsmZ3Q7Jmd0OyBob29rIGZvciBwcm9kdWNpbmcgc29tZXRoaW5nLi4pPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxkIGFsc28gYmUgaW50ZXJlc3RlZCBpbiBkb2lu ZyB0aGlzLCBtb3N0bHkgYmVjYXVzZSBhIGxvdCBvZjxicj4NCiZndDsmZ3Q7IHRoZXNlIGFzc3Vt cHRpb25zIChob3cgdG8gZG8gUkZDNTQ0NCkgaGF2ZSBiZWVuIHB1dCBpbnRvIHRoZSBkZXNpZ24g b2Y8YnI+DQomZ3Q7Jmd0OyBteTxicj4NCiZndDsmZ3Q7IFJGQzU0NDQgcGFyc2VyL2dlbmVyYXRv ciBBUEkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZ2VuZXJhdG9yIEFQSSBzdXBw b3J0cyB0aGF0IG11bHRpcGxlIHBhcnRzIG9mIHRoZSBwcm9ncmFtIGFyZTxicj4NCiZndDsmZ3Q7 IG11bHRpcGxleGluZyBkYXRhIGludG8gdGhlIHNhbWUgbWVzc2FnZSwgc28gdGhlcmUgaXMgbm8g cmVsaWFibGUgd2F5PGJyPg0KJmd0OyZndDsgdG8gZ3VhcmFudGVlIHRoZSBwb3NpdGlvbiBvZiBh ZGRyZXNzZXMgYW5kIFRMVnMgd2l0aGluIHRoZSBtZXNzYWdlLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgRG9jdW1lbnRpbmcgdGhlc2UgJ2Jlc3QgcHJhY3RpY2VzJyB3b3VsZCBiZSBoZWxw ZnVsIGZvciBmdXJ0aGVyPGJyPg0KJmd0OyZndDsgcHJvdG9jb2wgZGVzaWduZXJzLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQWJzb2x1dGVseSwgYW5kIHdlICh3ZWxsLCBhdCBs ZWFzdCwgSSkgY291bnQgb24gbG9vcGluZyB5b3UgaW4gb24gdGhpcyBwcm9jZXNzLjxicj4NCiZn dDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaG9tYXM8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEhlbm5pbmcgUm9nZ2U8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsgRGlwbG9tLUluZm9ybWF0aWtlciBIZW5uaW5nIFJv Z2dlICwgRnJhdW5ob2Zlci1JbnN0aXR1dCBmw7xyPGJyPg0KJmd0OyZndDsgS29tbXVuaWthdGlv biwgSW5mb3JtYXRpb25zdmVyYXJiZWl0dW5nIHVuZCBFcmdvbm9taWUgRktJRTxicj4NCiZndDsm Z3Q7IEtvbW11bmlrYXRpb25zc3lzdGVtZSAoS09NKSBGcmF1bmhvZmVyIFN0cmHDn2UgMjAsIDUz MzQzIFdhY2h0YmVyZyw8YnI+DQomZ3Q7Jmd0OyBHZXJtYW55PGJyPg0KJmd0OyZndDsgVGVsZWZv biA8YSBocmVmPSJ0ZWw6JTJCNDklMjAyMjglMjA5NDM1LTk2MSI+JiM0Mzs0OSAyMjggOTQzNS05 NjE8L2E+LCAmbmJzcDsgRmF4IDxhIGhyZWY9InRlbDolMkI0OSUyMDIyOCUyMDk0MzUlMjA2ODUi Pg0KJiM0Mzs0OSAyMjggOTQzNSA2ODU8L2E+PGJyPg0KJmd0OyZndDsgbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZSI+aGVubmluZy5yb2dnZUBm a2llLmZyYXVuaG9mZXIuZGU8L2E+DQo8YSBocmVmPSJodHRwOi8vd3d3LmZraWUuZnJhdW5ob2Zl ci5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmZraWUuZnJhdW5ob2Zlci5kZTwvYT48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbWFuZXQgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYu b3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+ DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZDxicj4NCiZndDsgcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQomZ3Q7IHJlY2lwaWVudCBwbGVh c2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4N CiZndDsgWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5v ciBkaXNjbG9zZSBvcjxicj4NCiZndDsgZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbi48YnI+DQomZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KJmd0Ozxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1h bmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3Jn Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF097GLKXM0002VGREEN_-- From nobody Tue Jul 22 09:09:33 2014 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 BB16D1B28A9 for ; Tue, 22 Jul 2014 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 EzHH8p9Anzo6 for ; Tue, 22 Jul 2014 09:09:22 -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 153961B28C7 for ; Tue, 22 Jul 2014 09:09:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HVQxu2dutRN0otESFS6scbqmufuemQApAFlXhfypa6sUlJKH54BgmZZMyHi1DD6p; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.149.207] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X9ccg-0006pU-Tv; Tue, 22 Jul 2014 12:09:03 -0400 Message-ID: <53CE8C9C.8090303@earthlink.net> Date: Tue, 22 Jul 2014 09:09:00 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060109030509030302010800" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac73f810f8819ee628a4fc0fe41ee64c9e8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/o5ae5UZy8wmq0dBOWhA80opI-mA Cc: manet-ads , manet@ietf.org Subject: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 16:09:27 -0000 This is a multi-part message in MIME format. --------------060109030509030302010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Chris, While RFC 5444 is mandated for [manet], and thus AODVv2 must be in compliance, it is my experience that RFC 5444 was not at all designed for reactive protocols. If there is going to be a new RFC 5444, it should also include some consideration about how to fix this problem. To restrict other protocols on the basis of something clever about a supposedly "better" packet format's parser is putting the cart before the horse. In the meantime, it would exacerbate an already unfortunate situation to place additional RFC 5444 mandates without consideration of the needs of non-proactive protocols. RFC 5444 seems to be all about how to condense the representation of otherwise interchangeable IP addresses. It has been made more difficult to include attach information to specific IP addresses because that makes them non-interchangeable in the AddrBlks. This point of view becomes more or less irrelevant (even counterproductive) when there are only one or two addresses in the AddrBlks. Given the number of comments made regarding issues with AODVv2, I don't think I can be much help with the process of reconsidering RFC 5444 right now, but in the future I would be very happy to do so. Also, please note that this *should* *not* be construed to mean that I do not intend AODVv2 to be conformant to RFC 5444. However, if all of a sudden there were recognition within the working group that RFC 5444 does place very significant (and, I think, undesirable) design constraints on protocol design, I would be very happy to go back to the way things were before. Right now I do not have time to take up that cause. // Regards, Charlie P. On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote: > > Actually, I think there has been some improvement here, but could be > improved further. This is at the level of comment I didn't attempt to > make, I concentrated on what I considered the most major issues. > > IIRC, two TLVs are suggested, one to say "this is A", one to say "this > is B". It's assumed there are two addresses, and the one that's not A > is B, and vice versal. > > Better is to have a single TLV with a value for A or B. Why? First, > it avoids wasting a TLV code point. Second, you can flag A and B with > a single multivalue TLV more efficiently than marking A and B. And > it's a good idea to mark A and B, because that way you can add > additional addresses in an extension, without introducing any problems > as to which is A or B with a single TLV. In addition, the practice we > introduced in TLV extensions of having a null value (255 UNSPECIFIED > is what we used) can help there as well. > > One of those things the authors of 5444 etc. would like to do -- when > they can find some extra hours in a week -- is to set out this sort of > good practice for 5444 that has been found to be valuable. In this > case we have the two principles of (a) always attack a TLV to indicate > information, as just doing so from a non-TLVed address precludes > various extensions, and (b) when attaching information, null values > are good -- T:LV extensions discusses why, a lot comes down to that > you can't order for more than one or two TLVs at once. > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > *From:*Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > *Sent:* 22 July 2014 14:08 > *To:* Dearlove, Christopher (UK) > *Cc:* manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads > *Subject:* Not just 5498 but also 5444 compliance (was: Re: [manet] > #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) > > **** WARNING **** > > /This message originates from outside our organisation, either from an > external partner or the internet.// > /Consider carefully whether you should click on any links, open any > attachments or reply./ > /For information regarding //*/Red Flags/*/that you can look out for > in emails you receive, click here > .// > /If you feel the email is suspicious, please follow this process > .// > > I am still, with reference to this document, dismayed to see that > there remain abundant references to positional information in address > blocks in RFC5444 messages. > > As has been pointed out numerous times, this is inappropriate, > positional information cannot be assumed assured and preserved by > generic 5444 message generation and parsing code. The first instance > of this offense is in Table 1 ... > > This has been requested fixed for years now. When will it be fixed? > > On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) > > wrote: > > RFC5444 describes a multiplexing process. It is not required > purely in its own terms. But RFC 5498 make it mandatory for any > protocol using the port/protocol allocated by that RFC. And the WG > has agreed that all routing protocols developed have to be able > (at least) to use that port/protocol. > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com > |http://www.baesystems.com > > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > *From:*manet [mailto:manet-bounces@ietf.org]*On Behalf > Of*Abdussalam Baryun > *Sent:*22 July 2014 12:02 > *To:*manet@ietf.org > *Cc:*draft-ietf-manet-aodvv2@tools.ietf.org > > *Subject:*Re: [manet] #45 (aodvv2): RFC 5498 non-compliance > (submitted for Chris Dearlove) > > **** WARNING **** > > /This message originates from outside our organisation, either > from an external partner or the internet.// > /Consider carefully whether you should click on any links, open > any attachments or reply./ > /For information regarding//*/Red Flags/*///that you can look out > for in emails you receive, click////here > .// > /If you feel the email is suspicious, please follow//this process > .// > > IMHO The problem is that RFC5444 still does not have a > multiplexing standard in IETF. The way of multiplexing is still > just implemented by OLSRv2 experts but I dont find any standard > for multiplexing yet. The RFC5498 is not for multipexing as I > understand it. We already discussed once that multiplexing is not > specified for all RFC5444 formats because it is general format but > RFC5498 is not general. > > If I am wrong please point me to an RFC. > > AB > > On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker > > wrote: > > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) > > The document is completely noncompliant with the RFC 5444 > multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-manet- > charliep@computer.org | > aodvv2@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: aodvv2 | Version: > Severity: Active WG | Keywords: RFC 5498 > Document | > -------------------------+------------------------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --------------060109030509030302010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Chris,

While RFC 5444 is mandated for [manet], and thus AODVv2 must be
in compliance, it is my experience that RFC 5444 was not at all designed
for reactive protocols.  If there is going to be a new RFC 5444, it should
also include some consideration about how to fix this problem.

To restrict other protocols on the basis of something clever about
a supposedly "better" packet format's parser is putting the cart before
the horse.

In the meantime, it would exacerbate an already unfortunate situation
to place additional RFC 5444 mandates without consideration of the
needs of non-proactive protocols.  RFC 5444 seems to be all about how
to condense the representation of otherwise interchangeable IP
addresses. It has been made more difficult to include attach information
to specific IP addresses because that makes them non-interchangeable
in the AddrBlks.  This point of view becomes more or less irrelevant
(even counterproductive) when there are only one or two addresses in
the AddrBlks.

Given the number of comments made regarding issues with AODVv2,
I don't think I can be much help with the process of reconsidering
RFC 5444 right now, but in the future I would be very happy to do so.

Also, please note that this *should* *not* be construed to mean that I
do not intend AODVv2 to be conformant to RFC 5444.  However, if all of
a sudden there were recognition within the working group that RFC 5444
does place very significant (and, I think, undesirable) design constraints
on protocol design, I would be very happy to go back to the way things
were before.  Right now I do not have time to take up that cause.

Regards,
Charlie P.



On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote:

Actually, I think there has been some improvement here, but could be improved further. This is at the level of comment I didn’t attempt to make, I concentrated on what I considered the most major issues.

 

IIRC, two TLVs are suggested, one to say “this is A”, one to say “this is B”. It’s assumed there are two addresses, and the one that’s not A is B, and vice versal.

 

Better is to have a single TLV with a  value for A or B. Why? First, it avoids wasting a TLV code point. Second, you can flag A and B with a single multivalue TLV more efficiently than marking A and B. And it’s a good idea to mark A and B, because that way you can add additional addresses in an extension, without introducing any problems as to which is A or B with a single TLV. In addition, the practice we introduced in TLV extensions of having a null value (255 UNSPECIFIED is what we used) can help there as well.

 

One of those things the authors of 5444 etc. would like to do – when they can find some extra hours in a week – is to set out this sort of good practice for 5444 that has been found to be valuable. In this case we have the two principles of (a) always attack a TLV to indicate information, as just doing so from a non-TLVed address precludes various extensions, and (b) when attaching information, null values are good – T:LV extensions discusses why, a lot comes down to that you can’t order for more than one or two TLVs at once.

 

--

Christopher Dearlove

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

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

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

 

From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 22 July 2014 14:08
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads
Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

 

 

*** WARNING ***

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

I am still, with reference to this document, dismayed to see that there remain abundant references to positional information in address blocks in RFC5444 messages. 

 

As has been pointed out numerous times, this is inappropriate, positional information cannot be assumed assured and preserved by generic 5444 message generation and parsing code. The first instance of this offense is in Table 1 ...

 

This has been requested fixed for years now. When will it be fixed?

 

 

On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

 

RFC5444 describes a multiplexing process. It is not required purely in its own terms. But RFC 5498 make it mandatory for any protocol using the port/protocol allocated by that RFC. And the WG has agreed that all routing protocols developed have to be able (at least) to use that port/protocol.

 

--

Christopher Dearlove

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

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

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

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 12:02
To: manet@ietf.org
Cc: draft-ietf-manet-aodvv2@tools.ietf.org
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

 

 

*** WARNING ***

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

IMHO The problem is that RFC5444 still does not have a multiplexing standard in IETF. The way of multiplexing is still just implemented by OLSRv2 experts but I dont find any standard for multiplexing yet. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not specified for all RFC5444 formats because it is general format but RFC5498 is not general.

 

If I am wrong please point me to an RFC.

AB

On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <trac+manet@trac.tools.ietf.org> wrote:

#45: RFC 5498 non-compliance (submitted for Chris Dearlove)

 The document is completely noncompliant with the RFC 5444 multiplexing
 mechanism, mandated by RFC 5498 (on the manet port/protocol). It does
 many things that are not within its competence.

--
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  charliep@computer.org  |  aodvv2@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:  RFC 5498
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45>
manet <http://tools.ietf.org/manet/>

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

 

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

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

 


--------------060109030509030302010800-- From nobody Tue Jul 22 09:14:21 2014 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 1E30D1B2989 for ; Tue, 22 Jul 2014 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 oG0z7MzVwL-P for ; Tue, 22 Jul 2014 09:14:18 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id DA45F1A0016 for ; Tue, 22 Jul 2014 09:14:17 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X9chi-0005cs-0h; Tue, 22 Jul 2014 12:14:14 -0400 Message-ID: <53CE8DD3.20708@computer.org> Date: Tue, 22 Jul 2014 09:14:11 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000803050702090203000008" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac74b44fd6461262fc2396118e0178864da350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pHUrKrWIIuIsZJ87Km3HWZs-8ek Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 16:14:20 -0000 This is a multi-part message in MIME format. --------------000803050702090203000008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Chris, OLSRv2 is much more demanding regarding the determination of which IP addresses belong to which routers. Basically, AODVv2 does not care. DSR did not care either. In fact, I am not aware of any reactive protocol for which this was ever an issue. What matters is the establishment of a routing path from source to destination. I will fix the wording about handling blacklisted addresses as suggested. If you have other instances, please do not hesitate to point them out. Regards, Charlie P. On 7/22/2014 6:50 AM, Dearlove, Christopher (UK) wrote: > > The second of these was the point I had in mind. The first is an > associated issue. > > There are various complexities in OLSRv2 that relate to addressing of > interfaces (not shared between routers, but possibly shared between > interfaces) and gateways (can overlap and share). We think we got them > right (though without a formal proof, so it’s possible we missed > something – I think we caught one right at the last post-IESG point). > But some took some work. > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > *From:*Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > *Sent:* 22 July 2014 14:19 > *To:* Dearlove, Christopher (UK) > *Cc:* Charles Perkins; manet@ietf.org; > draft-ietf-manet-aodvv2@tools.ietf.org > *Subject:* Re: [manet] #48 (aodvv2): Single address per interface per > router (submitted for Chris Dearlove) > > **** WARNING **** > > /This message originates from outside our organisation, either from an > external partner or the internet.// > /Consider carefully whether you should click on any links, open any > attachments or reply./ > /For information regarding //*/Red Flags/*/that you can look out for > in emails you receive, click here > .// > /If you feel the email is suspicious, please follow this process > .// > > On 22 Jul 2014, at 14:39 , Dearlove, Christopher (UK) > > wrote: > > In at least one place in the draft (sorry, I don't have the time > to find it again now) it explicitly says one address per interface. > > Not sure if this is the place that Chris is thinking of, but in my > review I encountered things such as: > > Blacklist.Node > The IP address of the node that did not verify bidirectional > connectivity. > > Which looks like it is assumed that a “node†(I assume that this means > “router†and will be fixed in a coming version, as has been requested > multiple times) has a single IP address (that’s what the use of the > definite article implies, is it not?) > > Also: > > AODVv2 supports routers with > multiple interfaces, as long as each interface has its own (unicast > routeable) IP address > > “address†- singular, not plural. > > There were other instances of such, these were just the first I saw > when glancing over my review. > > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com > | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@computer.org] > Sent: 21 July 2014 05:45 > To: manet@ietf.org ; Dearlove, Christopher > (UK); draft-ietf-manet-aodvv2@tools.ietf.org > > Subject: Re: [manet] #48 (aodvv2): Single address per interface > per router (submitted for Chris Dearlove) > > ----------------------! 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. > -------------------------------------------------------- > > Hello Chris, > > AODVv2 does not impose this restriction. It has, for a long time, > enabled multiple router addresses per interface. I will look > again, but as of now I do not see where any such restriction has > been imposed. If you have identified where this restriction is > implied or stated directly, please let me know as soon as possible. > > Unnumbered interfaces have never been suggested as appropriate for > inclusion of the feature set for any reactive protocol that was > under consideration within [manet], all the way since the very > initiation of the working group. At least not within my memory. > > On 7/20/2014 8:46 PM, manet issue tracker wrote: > > #48: Single address per interface per router (submitted for Chris > Dearlove) > > The model is of routers with a single address per interface. In > OLSRv2 > this wasn't considered acceptable. The authors defined multiple > addresses > per interface, the WG required supporting unnumbered interfaces which > shared addresses. > > > -- > Regards, > Charlie P. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. --------------000803050702090203000008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello Chris,

OLSRv2 is much more demanding regarding the determination of which
IP addresses belong to which routers.  Basically, AODVv2 does not care.
DSR did not care either.  In fact, I am not aware of any reactive protocol
for which this was ever an issue.  What matters is the establishment of
a routing path from source to destination.

I will fix the wording about handling blacklisted addresses as suggested.
If you have other instances, please do not hesitate to point them out.

Regards,
Charlie P.


On 7/22/2014 6:50 AM, Dearlove, Christopher (UK) wrote:

The second of these was the point I had in mind. The first is an associated issue.

 

There are various complexities in OLSRv2 that relate to addressing of interfaces (not shared between routers, but possibly shared between interfaces) and gateways (can overlap and share). We think we got them right (though without a formal proof, so it’s possible we missed something – I think we caught one right at the last post-IESG point). But some took some work.

 

--

Christopher Dearlove

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

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

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

 

From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 22 July 2014 14:19
To: Dearlove, Christopher (UK)
Cc: Charles Perkins; manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org
Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove)

 

 

*** WARNING ***

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

 

On 22 Jul 2014, at 14:39 , Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

 

In at least one place in the draft (sorry, I don't have the time to find it again now) it explicitly says one address per interface.

 

Not sure if this is the place that Chris is thinking of, but in my review I encountered things such as:

 

 Blacklist.Node
      The IP address of the node that did not verify bidirectional
      connectivity.

 

Which looks like it is assumed that a “node†(I assume that this means “router†and will be fixed in a coming version, as has been requested multiple times) has a single IP address (that’s what the use of the definite article implies, is it not?)

 

Also:

 

 AODVv2 supports routers with
   multiple interfaces, as long as each interface has its own (unicast
   routeable) IP address

 

“address†- singular, not plural.

 

There were other instances of such, these were just the first I saw when glancing over my review.

 

 

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

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


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@computer.org]
Sent: 21 July 2014 05:45
To: manet@ietf.org; Dearlove, Christopher (UK); draft-ietf-manet-aodvv2@tools.ietf.org
Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove)

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

Hello Chris,

AODVv2 does not impose this restriction.  It has, for a long time, enabled multiple router addresses per interface.  I will look again, but as of now I do not see where any such restriction has been imposed.  If you have identified where this restriction is implied or stated directly, please let me know as soon as possible.

Unnumbered interfaces have never been suggested as appropriate for inclusion of the feature set for any reactive protocol that was under consideration within [manet], all the way since the very initiation of the working group.  At least not within my memory.

On 7/20/2014 8:46 PM, manet issue tracker wrote:

#48: Single address per interface per router (submitted for Chris
Dearlove)

 The model is of routers with a single address per interface. In OLSRv2
 this wasn't considered acceptable. The authors defined multiple addresses
 per interface, the WG required supporting unnumbered interfaces which
 shared addresses.


--
Regards,
Charlie P.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 


-- 
Regards,
Charlie P.
--------------000803050702090203000008-- From nobody Tue Jul 22 09:21:05 2014 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 A110B1A01F2 for ; Tue, 22 Jul 2014 09:21: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 cTjklyp5RXbv for ; Tue, 22 Jul 2014 09:21:01 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12CC1A0196 for ; Tue, 22 Jul 2014 09:21:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id D9CD5920EFF for ; Tue, 22 Jul 2014 09:21:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 2FA14920EED for ; Tue, 22 Jul 2014 09:21:00 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <677582AE-0FEA-46BC-A056-2CBD6824347D@thomasclausen.org> Date: Tue, 22 Jul 2014 12:20:58 -0400 To: manet X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/d7tAKetDHb2q2-Iqr8PNn9bBQgU Subject: [manet] Question to ADOVv2 applicability statement 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, 22 Jul 2014 16:21:03 -0000 The draft states: > The AODVv2 routing protocol is designed for stub (i.e., non-transit) or d= isconnected (i.e., > from the Internet) mobile ad hoc networks (MANETs). Does this mean that this protocol does not support "attached network", as ar= e known from OLSRv2 (and OLSR, even)?=20 If the answer is "yes, it does support attached networks" then the statement= quoted above is incorrect.=20 If the answer is "no, it does not support attached network" then the stateme= nt quoted is correct -- but, it's a limitation of the protocol that I am not= enthusiastic about Sent from my iPad= From nobody Tue Jul 22 09:26:13 2014 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 D0F561B29CA for ; Tue, 22 Jul 2014 09:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 4q3dJUJE2nIH for ; Tue, 22 Jul 2014 09:26:05 -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 059DA1A01F2 for ; Tue, 22 Jul 2014 09:26:05 -0700 (PDT) Received: from [31.133.149.207] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X9ctA-0002Ni-4N; Tue, 22 Jul 2014 12:26:04 -0400 Message-ID: <53CE909A.3050206@computer.org> Date: Tue, 22 Jul 2014 09:26:02 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" , manet@ietf.org References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac763c0537266e2c62d6fcdf84fc1718247350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.149.207 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8FAAwEQD5rDWjsQKWMPYdhbH6L0 Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 16:26:08 -0000 Hello Chris, First, I must have a proposal. When I have that, I will certainly discuss with the working group before inclusion in the draft. Right now, I just have a good idea for a proposal -- in other words, a way forward. I have sent it to my co-authors. It needs more text. If you would like to help flesh out the text, please let me know. I'll be happy to work with you on it as well to make it a better-thought-out proposal. I've noticed that sometimes people on this list can be very, very critical, and this motivates the desire to do a better job before presenting ideas to the list. Other working groups are different. On 7/22/2014 5:38 AM, Dearlove, Christopher (UK) wrote: > It might make more sense to discuss a proposal for inclusion in a WG draft with the WG first. > -- Regards, Charlie P. From nobody Tue Jul 22 09:28:06 2014 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 CFA261B29D1 for ; Tue, 22 Jul 2014 09:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 m_Eb7v2Yi2Ks for ; Tue, 22 Jul 2014 09:27:54 -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 CBAF41A011E for ; Tue, 22 Jul 2014 09:27:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="388558006" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 17:27:52 +0100 X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208";a="65672374" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 17:27:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 17:27:59 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins Thread-Topic: Please, no more RFC 5444 mandates right now... Thread-Index: AQHPpcdUAroX/7TmIUaK2Kd68hScM5usQzkg Date: Tue, 22 Jul 2014 16:27:58 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE8C9C.8090303@earthlink.net> In-Reply-To: <53CE8C9C.8090303@earthlink.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wqIdaz6_wICDDK3dRttkR593-LQ Cc: manet-ads , "manet@ietf.org" Subject: Re: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 16:27:59 -0000 This is a WG document, not just your private document, and I'm pointing out= how it can be better. And not at a significant efficiency cost. But you wi= ll note this wasn't on my list of major issues, this was on the list I have= n't got to. I only mentioned it as relevant to someone else's point. As for your last point, that's implying a totally unacceptable option. It has been agreed by the WG, and defined in Proposed Standards, that - MANET WG routing protocols shall be able to use the manet port/protocol. - RFC 5498 mandates that anything using that port/protocol shall use not ju= st RFC 5444, but the RFC 5444 multiplexer. - The separation out of the RFC 5444 format as not just for OLSRv2 (includi= ng the also then not split out NHDP) was also a WG imposed requirement. On that last point, given that RFC 5498 was (inexplicably to me) accepted b= efore RFC 5444, the IESG insisted that RFC 5444 contain a specification of = the multiplexing mechanism that RFC 5498 had imposed on it. And RFC 5498 wa= s authored by your then DYMO co-author. He obviously didn't feel it couldn'= t cope with reactive protocols. As for there being too many issues with AODVv2, yes, there are too many iss= ues with AODVv2. That's the problem. The solution is not to ignore them, bu= t to fix them (the WG having taken the decision not to restart from a docum= ent with fewer issues). As for the only two addresses, you're imposing a restriction on any future = extension that might want to report an address for another reason. I don't = think that is a good idea. --=20 Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Charlie Perkins [mailto:charles.perkins@earthlink.net]=20 Sent: 22 July 2014 17:09 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; manet-ads Subject: Please, no more RFC 5444 mandates right now... *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Hello Chris, While RFC 5444 is mandated for [manet], and thus AODVv2 must be in compliance, it is my experience that RFC 5444 was not at all designed for reactive protocols.=A0 If there is going to be a new RFC 5444, it shoul= d also include some consideration about how to fix this problem. To restrict other protocols on the basis of something clever about a supposedly "better" packet format's parser is putting the cart before the horse. In the meantime, it would exacerbate an already unfortunate situation to place additional RFC 5444 mandates without consideration of the needs of non-proactive protocols.=A0 RFC 5444 seems to be all about how to condense the representation of otherwise interchangeable IP addresses. It has been made more difficult to include attach information to specific IP addresses because that makes them non-interchangeable in the AddrBlks.=A0 This point of view becomes more or less irrelevant (even counterproductive) when there are only one or two addresses in the AddrBlks. Given the number of comments made regarding issues with AODVv2, I don't think I can be much help with the process of reconsidering RFC 5444 right now, but in the future I would be very happy to do so. Also, please note that this *should* *not* be construed to mean that I do not intend AODVv2 to be conformant to RFC 5444.=A0 However, if all of a sudden there were recognition within the working group that RFC 5444 does place very significant (and, I think, undesirable) design constraints on protocol design, I would be very happy to go back to the way things were before.=A0 Right now I do not have time to take up that cause. Regards, Charlie P. On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote: Actually, I think there has been some improvement here, but could be improv= ed further. This is at the level of comment I didn't attempt to make, I con= centrated on what I considered the most major issues. =A0 IIRC, two TLVs are suggested, one to say "this is A", one to say "this is B= ". It's assumed there are two addresses, and the one that's not A is B, and= vice versal. =A0 Better is to have a single TLV with a =A0value for A or B. Why? First, it a= voids wasting a TLV code point. Second, you can flag A and B with a single = multivalue TLV more efficiently than marking A and B. And it's a good idea = to mark A and B, because that way you can add additional addresses in an ex= tension, without introducing any problems as to which is A or B with a sing= le TLV. In addition, the practice we introduced in TLV extensions of having= a null value (255 UNSPECIFIED is what we used) can help there as well. =A0 One of those things the authors of 5444 etc. would like to do - when they c= an find some extra hours in a week - is to set out this sort of good practi= ce for 5444 that has been found to be valuable. In this case we have the tw= o principles of (a) always attack a TLV to indicate information, as just do= ing so from a non-TLVed address precludes various extensions, and (b) when = attaching information, null values are good - T:LV extensions discusses why= , a lot comes down to that you can't order for more than one or two TLVs at= once. =A0 --=20 Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 =A0 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 Sent: 22 July 2014 14:08 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodv= v2): RFC 5498 non-compliance (submitted for Chris Dearlove)) =A0 =A0 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. I am still, with reference to this document, dismayed to see that there rem= ain abundant references to positional information in address blocks in RFC5= 444 messages.=A0 =A0 As has been pointed out numerous times, this is inappropriate, positional i= nformation cannot be assumed assured and preserved by generic 5444 message = generation and parsing code. The first instance of this offense is in Table= 1 ... =A0 This has been requested fixed for years now. When will it be fixed? =A0 =A0 On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) wrote: =A0 RFC5444 describes a multiplexing process. It is not required purely in its = own terms. But RFC 5498 make it mandatory for any protocol using the port/p= rotocol allocated by that RFC. And the WG has agreed that all routing proto= cols developed have to be able (at least) to use that port/protocol. =A0 -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124 chris.dearlove@baesystems.com=A0|=A0http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 =A0 From:=A0manet [mailto:manet-bounces@ietf.org]=A0On Behalf Of=A0Abdussalam B= aryun Sent:=A022 July 2014 12:02 To:=A0manet@ietf.org Cc:=A0draft-ietf-manet-aodvv2@tools.ietf.org Subject:=A0Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for= Chris Dearlove) =A0 =A0 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding=A0Red Flags=A0that you can look out for in emails= you receive, click=A0here. If you feel the email is suspicious, please follow=A0this process. IMHO The problem is that RFC5444 still does not have a multiplexing standar= d in IETF. The way of multiplexing is still just implemented by OLSRv2 expe= rts but I dont find any standard for multiplexing yet. The RFC5498 is not f= or multipexing as I understand it. We already discussed once that multiplex= ing is not specified for all RFC5444 formats because it is general format b= ut RFC5498 is not general. =A0 If I am wrong please point me to an RFC. AB On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker wrote: #45: RFC 5498 non-compliance (submitted for Chris Dearlove) =A0The document is completely noncompliant with the RFC 5444 multiplexing =A0mechanism, mandated by RFC 5498 (on the manet port/protocol). It does =A0many things that are not within its competence. -- -------------------------+------------------------------------------------- =A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= manet- =A0=A0charliep@computer.org=A0=A0| =A0aodvv2@tools.ietf.org =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new =A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0Milestone: Component: =A0aodvv2 =A0 =A0 =A0 | =A0 =A0Version: =A0Severity: =A0Active WG =A0 =A0| =A0 Keywords: =A0RFC 5498 =A0 Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 | -------------------------+------------------------------------------------- Ticket URL: manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet =A0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet =A0 From nobody Tue Jul 22 09:32:10 2014 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 5932A1A01C6 for ; Tue, 22 Jul 2014 09:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793, T_FILL_THIS_FORM_SHORT=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 DdKrnMPDcw61 for ; Tue, 22 Jul 2014 09:32:05 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143981A00DC for ; Tue, 22 Jul 2014 09:32:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,710,1400022000"; d="scan'208,217";a="459877458" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 17:32:03 +0100 X-IronPort-AV: E=Sophos; i="5.01,710,1400022000"; d="scan'208,217"; a="58658591" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 17:32:10 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 17:32:10 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" Thread-Topic: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) Thread-Index: AQHPpJZRpGdaQIoNtkqxT42LJQkBP5up4z0AgAInWBD///phgIAAGFbAgAAYtYCAABTUcA== Date: Tue, 22 Jul 2014 16:32:10 +0000 Message-ID: References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> <53CC9AE6.7090800@computer.org> <53CE8DD3.20708@computer.org> In-Reply-To: <53CE8DD3.20708@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF129GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JnfPD47Bclam_GCvv7hZrkJZZLU Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) 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, 22 Jul 2014 16:32:08 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF129GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcgaXMgbW9yZSDigJxkZW1hbmRp bmfigJ0uIE1vcmUgbGltaXRpbmcsIHllcy4gSeKAmW0gbm90IHN1cmUgd2hhdCBwb2ludCB5b3Ug YXJlIG1ha2luZyB3aXRoIOKAnGRvZXMgbm90IGNhcmXigJ0uDQoNCkFzIGZvciBwb2ludGluZyBv dXQgb3RoZXIgaW5zdGFuY2VzLCBubywgSSBkb27igJl0IGhhdmUgdGhlIHRpbWUuIEhhdmluZyBw b2ludGVkIG91dCBhbiBhcmVhIG9mIGlzc3VlIGl0IHNob3VsZCBiZSB0aGUgYXV0aG9yL2VkaXRv cuKAmXMgcmVzcG9uc2liaWxpdHkgdG8gY2hlY2sgZm9yIGNvbnNpc3RlbmN5LiBPciBhdCBsZWFz dCB0aGF04oCZcyBteSBhdHRpdHVkZSBhcyBhbiBhdXRob3IuDQoNCi0tDQpDaHJpc3RvcGhlciBE ZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNl IEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFi aWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5p bmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6 ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0 ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3Jv dWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQpGcm9tOiBDaGFybGVz IEUuIFBlcmtpbnMgW21haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmddDQpTZW50OiAyMiBKdWx5 IDIwMTQgMTc6MTQNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1hbmV0QGll dGYub3JnOyBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDog UmU6IFttYW5ldF0gIzQ4IChhb2R2djIpOiBTaW5nbGUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlIHBl ciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpDQoNCg0KKioqIFdBUk5JTkcg KioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25z aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJl ZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwg Y2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZl ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0 dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+ Lg0KDQpIZWxsbyBDaHJpcywNCg0KT0xTUnYyIGlzIG11Y2ggbW9yZSBkZW1hbmRpbmcgcmVnYXJk aW5nIHRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoaWNoDQpJUCBhZGRyZXNzZXMgYmVsb25nIHRvIHdo aWNoIHJvdXRlcnMuICBCYXNpY2FsbHksIEFPRFZ2MiBkb2VzIG5vdCBjYXJlLg0KRFNSIGRpZCBu b3QgY2FyZSBlaXRoZXIuICBJbiBmYWN0LCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgcmVhY3RpdmUg cHJvdG9jb2wNCmZvciB3aGljaCB0aGlzIHdhcyBldmVyIGFuIGlzc3VlLiAgV2hhdCBtYXR0ZXJz IGlzIHRoZSBlc3RhYmxpc2htZW50IG9mDQphIHJvdXRpbmcgcGF0aCBmcm9tIHNvdXJjZSB0byBk ZXN0aW5hdGlvbi4NCg0KSSB3aWxsIGZpeCB0aGUgd29yZGluZyBhYm91dCBoYW5kbGluZyBibGFj a2xpc3RlZCBhZGRyZXNzZXMgYXMgc3VnZ2VzdGVkLg0KSWYgeW91IGhhdmUgb3RoZXIgaW5zdGFu Y2VzLCBwbGVhc2UgZG8gbm90IGhlc2l0YXRlIHRvIHBvaW50IHRoZW0gb3V0Lg0KDQpSZWdhcmRz LA0KQ2hhcmxpZSBQLg0KDQpPbiA3LzIyLzIwMTQgNjo1MCBBTSwgRGVhcmxvdmUsIENocmlzdG9w aGVyIChVSykgd3JvdGU6DQpUaGUgc2Vjb25kIG9mIHRoZXNlIHdhcyB0aGUgcG9pbnQgSSBoYWQg aW4gbWluZC4gVGhlIGZpcnN0IGlzIGFuIGFzc29jaWF0ZWQgaXNzdWUuDQoNClRoZXJlIGFyZSB2 YXJpb3VzIGNvbXBsZXhpdGllcyBpbiBPTFNSdjIgdGhhdCByZWxhdGUgdG8gYWRkcmVzc2luZyBv ZiBpbnRlcmZhY2VzIChub3Qgc2hhcmVkIGJldHdlZW4gcm91dGVycywgYnV0IHBvc3NpYmx5IHNo YXJlZCBiZXR3ZWVuIGludGVyZmFjZXMpIGFuZCBnYXRld2F5cyAoY2FuIG92ZXJsYXAgYW5kIHNo YXJlKS4gV2UgdGhpbmsgd2UgZ290IHRoZW0gcmlnaHQgKHRob3VnaCB3aXRob3V0IGEgZm9ybWFs IHByb29mLCBzbyBpdOKAmXMgcG9zc2libGUgd2UgbWlzc2VkIHNvbWV0aGluZyDigJMgSSB0aGlu ayB3ZSBjYXVnaHQgb25lIHJpZ2h0IGF0IHRoZSBsYXN0IHBvc3QtSUVTRyBwb2ludCkuIEJ1dCBz b21lIHRvb2sgc29tZSB3b3JrLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNh dGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVt cyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3Jl YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQg fCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1h aWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9m ZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2Vu dHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogVGhvbWFzIEhlaWRlIENsYXVzZW4gW21h aWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAyMiBKdWx5IDIwMTQgMTQ6MTkN ClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IENoYXJsZXMgUGVya2luczsgbWFu ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsgZHJhZnQtaWV0Zi1tYW5ldC1hb2R2 djJAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xzLmll dGYub3JnPg0KU3ViamVjdDogUmU6IFttYW5ldF0gIzQ4IChhb2R2djIpOiBTaW5nbGUgYWRkcmVz cyBwZXIgaW50ZXJmYWNlIHBlciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUp DQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0 aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNr IG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVt YWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFn cy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xs b3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3 b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGlj aW91cyUyMEVtYWlscy5wZGY+Lg0KDQpPbiAyMiBKdWwgMjAxNCwgYXQgMTQ6MzkgLCBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Q2hyaXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv OkNocmlzLkRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNCkluIGF0IGxlYXN0IG9u ZSBwbGFjZSBpbiB0aGUgZHJhZnQgKHNvcnJ5LCBJIGRvbid0IGhhdmUgdGhlIHRpbWUgdG8gZmlu ZCBpdCBhZ2FpbiBub3cpIGl0IGV4cGxpY2l0bHkgc2F5cyBvbmUgYWRkcmVzcyBwZXIgaW50ZXJm YWNlLg0KDQpOb3Qgc3VyZSBpZiB0aGlzIGlzIHRoZSBwbGFjZSB0aGF0IENocmlzIGlzIHRoaW5r aW5nIG9mLCBidXQgaW4gbXkgcmV2aWV3IEkgZW5jb3VudGVyZWQgdGhpbmdzIHN1Y2ggYXM6DQoN Cg0KIEJsYWNrbGlzdC5Ob2RlDQoNCiAgICAgIFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIHRo YXQgZGlkIG5vdCB2ZXJpZnkgYmlkaXJlY3Rpb25hbA0KDQogICAgICBjb25uZWN0aXZpdHkuDQoN CldoaWNoIGxvb2tzIGxpa2UgaXQgaXMgYXNzdW1lZCB0aGF0IGEg4oCcbm9kZeKAnSAoSSBhc3N1 bWUgdGhhdCB0aGlzIG1lYW5zIOKAnHJvdXRlcuKAnSBhbmQgd2lsbCBiZSBmaXhlZCBpbiBhIGNv bWluZyB2ZXJzaW9uLCBhcyBoYXMgYmVlbiByZXF1ZXN0ZWQgbXVsdGlwbGUgdGltZXMpIGhhcyBh IHNpbmdsZSBJUCBhZGRyZXNzICh0aGF04oCZcyB3aGF0IHRoZSB1c2Ugb2YgdGhlIGRlZmluaXRl IGFydGljbGUgaW1wbGllcywgaXMgaXQgbm90PykNCg0KQWxzbzoNCg0KDQogQU9EVnYyIHN1cHBv cnRzIHJvdXRlcnMgd2l0aA0KDQogICBtdWx0aXBsZSBpbnRlcmZhY2VzLCBhcyBsb25nIGFzIGVh Y2ggaW50ZXJmYWNlIGhhcyBpdHMgb3duICh1bmljYXN0DQoNCiAgIHJvdXRlYWJsZSkgSVAgYWRk cmVzcw0KDQrigJxhZGRyZXNz4oCdIC0gc2luZ3VsYXIsIG5vdCBwbHVyYWwuDQoNClRoZXJlIHdl cmUgb3RoZXIgaW5zdGFuY2VzIG9mIHN1Y2gsIHRoZXNlIHdlcmUganVzdCB0aGUgZmlyc3QgSSBz YXcgd2hlbiBnbGFuY2luZyBvdmVyIG15IHJldmlldy4NCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVh cmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBH cm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmls aXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5n ZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiAr NDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVk DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3Vn aCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVn aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hhcmxlcyBFLiBQZXJraW5zIFttYWlsdG86Y2hhcmxpZXBA Y29tcHV0ZXIub3JnXQ0KU2VudDogMjEgSnVseSAyMDE0IDA1OjQ1DQpUbzogbWFuZXRAaWV0Zi5v cmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IGRy YWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1h bmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbWFuZXRdICM0OCAoYW9k dnYyKTogU2luZ2xlIGFkZHJlc3MgcGVyIGludGVyZmFjZSBwZXIgcm91dGVyIChzdWJtaXR0ZWQg Zm9yIENocmlzIERlYXJsb3ZlKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBm cm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQg Y2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxv dyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBp bnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpI ZWxsbyBDaHJpcywNCg0KQU9EVnYyIGRvZXMgbm90IGltcG9zZSB0aGlzIHJlc3RyaWN0aW9uLiAg SXQgaGFzLCBmb3IgYSBsb25nIHRpbWUsIGVuYWJsZWQgbXVsdGlwbGUgcm91dGVyIGFkZHJlc3Nl cyBwZXIgaW50ZXJmYWNlLiAgSSB3aWxsIGxvb2sgYWdhaW4sIGJ1dCBhcyBvZiBub3cgSSBkbyBu b3Qgc2VlIHdoZXJlIGFueSBzdWNoIHJlc3RyaWN0aW9uIGhhcyBiZWVuIGltcG9zZWQuICBJZiB5 b3UgaGF2ZSBpZGVudGlmaWVkIHdoZXJlIHRoaXMgcmVzdHJpY3Rpb24gaXMgaW1wbGllZCBvciBz dGF0ZWQgZGlyZWN0bHksIHBsZWFzZSBsZXQgbWUga25vdyBhcyBzb29uIGFzIHBvc3NpYmxlLg0K DQpVbm51bWJlcmVkIGludGVyZmFjZXMgaGF2ZSBuZXZlciBiZWVuIHN1Z2dlc3RlZCBhcyBhcHBy b3ByaWF0ZSBmb3IgaW5jbHVzaW9uIG9mIHRoZSBmZWF0dXJlIHNldCBmb3IgYW55IHJlYWN0aXZl IHByb3RvY29sIHRoYXQgd2FzIHVuZGVyIGNvbnNpZGVyYXRpb24gd2l0aGluIFttYW5ldF0sIGFs bCB0aGUgd2F5IHNpbmNlIHRoZSB2ZXJ5IGluaXRpYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAu ICBBdCBsZWFzdCBub3Qgd2l0aGluIG15IG1lbW9yeS4NCg0KT24gNy8yMC8yMDE0IDg6NDYgUE0s IG1hbmV0IGlzc3VlIHRyYWNrZXIgd3JvdGU6DQoNCg0KIzQ4OiBTaW5nbGUgYWRkcmVzcyBwZXIg aW50ZXJmYWNlIHBlciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMNCkRlYXJsb3ZlKQ0KDQog VGhlIG1vZGVsIGlzIG9mIHJvdXRlcnMgd2l0aCBhIHNpbmdsZSBhZGRyZXNzIHBlciBpbnRlcmZh Y2UuIEluIE9MU1J2Mg0KIHRoaXMgd2Fzbid0IGNvbnNpZGVyZWQgYWNjZXB0YWJsZS4gVGhlIGF1 dGhvcnMgZGVmaW5lZCBtdWx0aXBsZSBhZGRyZXNzZXMNCiBwZXIgaW50ZXJmYWNlLCB0aGUgV0cg cmVxdWlyZWQgc3VwcG9ydGluZyB1bm51bWJlcmVkIGludGVyZmFjZXMgd2hpY2gNCiBzaGFyZWQg YWRkcmVzc2VzLg0KDQotLQ0KUmVnYXJkcywNCkNoYXJsaWUgUC4NCg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRl bmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0 ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBp ZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KDQoNCi0tDQoNClJlZ2FyZHMsDQoNCkNoYXJsaWUgUC4N Cg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF129GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBub3Qgc3VyZSB3aGF0 IHlvdSBhcmUgc3VnZ2VzdGluZyBpcyBtb3JlIOKAnGRlbWFuZGluZ+KAnS4gTW9yZSBsaW1pdGlu ZywgeWVzLiBJ4oCZbSBub3Qgc3VyZSB3aGF0IHBvaW50IHlvdSBhcmUgbWFraW5nIHdpdGgg4oCc ZG9lcyBub3QgY2FyZeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGZvciBwb2ludGluZyBvdXQgb3RoZXIgaW5z dGFuY2VzLCBubywgSSBkb27igJl0IGhhdmUgdGhlIHRpbWUuIEhhdmluZyBwb2ludGVkIG91dCBh biBhcmVhIG9mIGlzc3VlIGl0IHNob3VsZCBiZSB0aGUgYXV0aG9yL2VkaXRvcuKAmXMgcmVzcG9u c2liaWxpdHkgdG8gY2hlY2sNCiBmb3IgY29uc2lzdGVuY3kuIE9yIGF0IGxlYXN0IHRoYXTigJlz IG15IGF0dGl0dWRlIGFzIGFuIGF1dGhvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdG9waGVyIERlYXJsb3ZlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlbmlvciBQcmluY2lwYWwg RW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25z LCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1z IEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAx MjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9 Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPC9zcGFuPjwvYT4NCiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0K UmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2gg QWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+IENoYXJsZXMgRS4gUGVya2lucyBbbWFpbHRvOmNoYXJsaWVwQGNv bXB1dGVyLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMiBKdWx5IDIwMTQgMTc6MTQ8YnI+DQo8 Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBtYW5l dEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gIzQ4IChhb2R2djIpOiBTaW5nbGUgYWRkcmVzcyBw ZXIgaW50ZXJmYWNlIHBlciByb3V0ZXIgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEu MHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2Jh Y2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3 MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5h dGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5h bCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2Fy ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0 dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGlu Zm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48 L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhh dCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEg aHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bh bj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0K PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNl IGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3 ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNw aWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bh bj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpIZWxsbyBDaHJpcyw8YnI+DQo8YnI+DQpPTFNS djIgaXMgbXVjaCBtb3JlIGRlbWFuZGluZyByZWdhcmRpbmcgdGhlIGRldGVybWluYXRpb24gb2Yg d2hpY2g8YnI+DQpJUCBhZGRyZXNzZXMgYmVsb25nIHRvIHdoaWNoIHJvdXRlcnMuJm5ic3A7IEJh c2ljYWxseSwgQU9EVnYyIGRvZXMgbm90IGNhcmUuPGJyPg0KRFNSIGRpZCBub3QgY2FyZSBlaXRo ZXIuJm5ic3A7IEluIGZhY3QsIEkgYW0gbm90IGF3YXJlIG9mIGFueSByZWFjdGl2ZSBwcm90b2Nv bDxicj4NCmZvciB3aGljaCB0aGlzIHdhcyBldmVyIGFuIGlzc3VlLiZuYnNwOyBXaGF0IG1hdHRl cnMgaXMgdGhlIGVzdGFibGlzaG1lbnQgb2Y8YnI+DQphIHJvdXRpbmcgcGF0aCBmcm9tIHNvdXJj ZSB0byBkZXN0aW5hdGlvbi48YnI+DQo8YnI+DQpJIHdpbGwgZml4IHRoZSB3b3JkaW5nIGFib3V0 IGhhbmRsaW5nIGJsYWNrbGlzdGVkIGFkZHJlc3NlcyBhcyBzdWdnZXN0ZWQuPGJyPg0KSWYgeW91 IGhhdmUgb3RoZXIgaW5zdGFuY2VzLCBwbGVhc2UgZG8gbm90IGhlc2l0YXRlIHRvIHBvaW50IHRo ZW0gb3V0Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcvMjIvMjAxNCA2 OjUwIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNlY29uZCBvZiB0aGVzZSB3YXMgdGhlIHBvaW50IEkgaGFk IGluIG1pbmQuIFRoZSBmaXJzdCBpcyBhbiBhc3NvY2lhdGVkIGlzc3VlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl cmUgYXJlIHZhcmlvdXMgY29tcGxleGl0aWVzIGluIE9MU1J2MiB0aGF0IHJlbGF0ZSB0byBhZGRy ZXNzaW5nIG9mIGludGVyZmFjZXMgKG5vdCBzaGFyZWQgYmV0d2VlbiByb3V0ZXJzLCBidXQgcG9z c2libHkgc2hhcmVkIGJldHdlZW4gaW50ZXJmYWNlcykgYW5kIGdhdGV3YXlzDQogKGNhbiBvdmVy bGFwIGFuZCBzaGFyZSkuIFdlIHRoaW5rIHdlIGdvdCB0aGVtIHJpZ2h0ICh0aG91Z2ggd2l0aG91 dCBhIGZvcm1hbCBwcm9vZiwgc28gaXTigJlzIHBvc3NpYmxlIHdlIG1pc3NlZCBzb21ldGhpbmcg 4oCTIEkgdGhpbmsgd2UgY2F1Z2h0IG9uZSByaWdodCBhdCB0aGUgbGFzdCBwb3N0LUlFU0cgcG9p bnQpLiBCdXQgc29tZSB0b29rIHNvbWUgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdG9waGVyIERlYXJsb3ZlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlbmlvciBQcmluY2lw YWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRp b25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0 ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9h ZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0 NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhy ZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPC9zcGFuPjwvYT4NCiB8IDxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20i Pmh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgKE9w ZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwg UE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFu dHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBO bzogMTk5NjY4Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBUaG9tYXMgSGVpZGUgQ2xhdXNlbiBbPGEgaHJlZj0ibWFpbHRvOnRob21hc0B0aG9t YXNjbGF1c2VuLm9yZyI+bWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZzwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gMjIgSnVseSAyMDE0IDE0OjE5PGJyPg0KPGI+VG86PC9iPiBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gQ2hhcmxlcyBQZXJraW5zOyA8YSBo cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWll dGYtbWFuZXQtYW9kdnYyQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW21hbmV0XSAjNDggKGFvZHZ2Mik6IFNpbmdsZSBhZGRyZXNzIHBlciBpbnRlcmZhY2UgcGVy IHJvdXRlciAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBw dCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAq Kio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl IGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5 b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw bHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJk aW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBv dXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50 cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv Y3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklm IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVm PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMu cGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBKdWwg MjAxNCwgYXQgMTQ6MzkgLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOkNocmlzLkRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5DaHJpcy5EZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkluIGF0IGxlYXN0IG9uZSBwbGFj ZSBpbiB0aGUgZHJhZnQgKHNvcnJ5LCBJIGRvbid0IGhhdmUgdGhlIHRpbWUgdG8gZmluZCBpdCBh Z2FpbiBub3cpIGl0IGV4cGxpY2l0bHkgc2F5cyBvbmUgYWRkcmVzcyBwZXIgaW50ZXJmYWNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk5vdCBzdXJlIGlmIHRoaXMgaXMgdGhlIHBsYWNlIHRoYXQgQ2hyaXMgaXMgdGhpbmtpbmcg b2YsIGJ1dCBpbiBteSByZXZpZXcgSSBlbmNvdW50ZXJlZCB0aGluZ3Mgc3VjaCBhczo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+IEJsYWNrbGlzdC5Ob2RlPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVGhlIElQIGFkZHJlc3Mgb2YgdGhlIG5vZGUgdGhhdCBkaWQgbm90IHZlcmlmeSBi aWRpcmVjdGlvbmFsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ubmVjdGl2aXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggbG9va3MgbGlrZSBpdCBp cyBhc3N1bWVkIHRoYXQgYSDigJxub2Rl4oCdIChJIGFzc3VtZSB0aGF0IHRoaXMgbWVhbnMg4oCc cm91dGVy4oCdIGFuZCB3aWxsIGJlIGZpeGVkIGluIGEgY29taW5nIHZlcnNpb24sIGFzIGhhcyBi ZWVuIHJlcXVlc3RlZCBtdWx0aXBsZSB0aW1lcykgaGFzIGEgc2luZ2xlIElQIGFkZHJlc3MgKHRo YXTigJlzIHdoYXQgdGhlIHVzZSBvZiB0aGUgZGVmaW5pdGUgYXJ0aWNsZSBpbXBsaWVzLCBpcw0K IGl0IG5vdD8pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsc286PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PiBBT0RWdjIgc3VwcG9ydHMgcm91dGVycyB3aXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgbXVsdGlwbGUgaW50ZXJmYWNlcywgYXMgbG9uZyBhcyBl YWNoIGludGVyZmFjZSBoYXMgaXRzIG93biAodW5pY2FzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IHJvdXRlYWJsZSkgSVAgYWRkcmVzczwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7i gJxhZGRyZXNz4oCdIC0gc2luZ3VsYXIsIG5vdCBwbHVyYWwuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIHdlcmUgb3RoZXIgaW5zdGFu Y2VzIG9mIHN1Y2gsIHRoZXNlIHdlcmUganVzdCB0aGUgZmlyc3QgSSBzYXcgd2hlbiBnbGFuY2lu ZyBvdmVyIG15IHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2Vu aW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwPGJyPg0K Q29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5PGJy Pg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQpXZXN0IEhhbm5p bmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJyPg0K VGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCAmbmJzcDtGYXg6ICYjNDM7NDQgMTI0NSAy NDIxMjQ8YnI+DQo8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20i PmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiB8DQo8YSBocmVmPSJodHRwOi8vd3d3 LmJhZXN5c3RlbXMuY29tIj5odHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxicj4N CkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6 IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwg RmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xh bmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IENoYXJsZXMgRS4gUGVya2lucyBbPGEgaHJlZj0ibWFp bHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+bWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZzwv YT5dDQo8YnI+DQpTZW50OiAyMSBKdWx5IDIwMTQgMDU6NDU8YnI+DQpUbzogPGEgaHJlZj0ibWFp bHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT47IERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspOw0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRvb2xz LmlldGYub3JnIj5kcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZzwvYT48YnI+ DQpTdWJqZWN0OiBSZTogW21hbmV0XSAjNDggKGFvZHZ2Mik6IFNpbmdsZSBhZGRyZXNzIHBlciBp bnRlcmZhY2UgcGVyIHJvdXRlciAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSk8YnI+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48 YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9sbG93IHRoZSAnUmVw b3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9u cyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4N CkhlbGxvIENocmlzLDxicj4NCjxicj4NCkFPRFZ2MiBkb2VzIG5vdCBpbXBvc2UgdGhpcyByZXN0 cmljdGlvbi4gJm5ic3A7SXQgaGFzLCBmb3IgYSBsb25nIHRpbWUsIGVuYWJsZWQgbXVsdGlwbGUg cm91dGVyIGFkZHJlc3NlcyBwZXIgaW50ZXJmYWNlLiAmbmJzcDtJIHdpbGwgbG9vayBhZ2Fpbiwg YnV0IGFzIG9mIG5vdyBJIGRvIG5vdCBzZWUgd2hlcmUgYW55IHN1Y2ggcmVzdHJpY3Rpb24gaGFz IGJlZW4gaW1wb3NlZC4gJm5ic3A7SWYgeW91IGhhdmUgaWRlbnRpZmllZCB3aGVyZSB0aGlzIHJl c3RyaWN0aW9uIGlzDQogaW1wbGllZCBvciBzdGF0ZWQgZGlyZWN0bHksIHBsZWFzZSBsZXQgbWUg a25vdyBhcyBzb29uIGFzIHBvc3NpYmxlLjxicj4NCjxicj4NClVubnVtYmVyZWQgaW50ZXJmYWNl cyBoYXZlIG5ldmVyIGJlZW4gc3VnZ2VzdGVkIGFzIGFwcHJvcHJpYXRlIGZvciBpbmNsdXNpb24g b2YgdGhlIGZlYXR1cmUgc2V0IGZvciBhbnkgcmVhY3RpdmUgcHJvdG9jb2wgdGhhdCB3YXMgdW5k ZXIgY29uc2lkZXJhdGlvbiB3aXRoaW4gW21hbmV0XSwgYWxsIHRoZSB3YXkgc2luY2UgdGhlIHZl cnkgaW5pdGlhdGlvbiBvZiB0aGUgd29ya2luZyBncm91cC4gJm5ic3A7QXQgbGVhc3Qgbm90IHdp dGhpbiBteSBtZW1vcnkuPGJyPg0KPGJyPg0KT24gNy8yMC8yMDE0IDg6NDYgUE0sIG1hbmV0IGlz c3VlIHRyYWNrZXIgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiM0ODogU2luZ2xl IGFkZHJlc3MgcGVyIGludGVyZmFjZSBwZXIgcm91dGVyIChzdWJtaXR0ZWQgZm9yIENocmlzDQo8 YnI+DQpEZWFybG92ZSk8YnI+DQo8YnI+DQombmJzcDtUaGUgbW9kZWwgaXMgb2Ygcm91dGVycyB3 aXRoIGEgc2luZ2xlIGFkZHJlc3MgcGVyIGludGVyZmFjZS4gSW4gT0xTUnYyPGJyPg0KJm5ic3A7 dGhpcyB3YXNuJ3QgY29uc2lkZXJlZCBhY2NlcHRhYmxlLiBUaGUgYXV0aG9ycyBkZWZpbmVkIG11 bHRpcGxlIGFkZHJlc3Nlczxicj4NCiZuYnNwO3BlciBpbnRlcmZhY2UsIHRoZSBXRyByZXF1aXJl ZCBzdXBwb3J0aW5nIHVubnVtYmVyZWQgaW50ZXJmYWNlcyB3aGljaDxicj4NCiZuYnNwO3NoYXJl ZCBhZGRyZXNzZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQot LTxicj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJy Pg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl IGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBm cm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5v dCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0K ZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu b3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48L286cD48L3By ZT4NCjxwcmU+Q2hhcmxpZSBQLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF129GLKXM0002VGREEN_-- From nobody Tue Jul 22 09:32:24 2014 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 EF9D71B29DC for ; Tue, 22 Jul 2014 09:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 O-97Ei5ph-jp for ; Tue, 22 Jul 2014 09:32:11 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462251B29D1 for ; Tue, 22 Jul 2014 09:32:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 7D0689210F3; Tue, 22 Jul 2014 09:32:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 272589210F1; Tue, 22 Jul 2014 09:32:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-05995AE7-B08C-4963-8A0B-A18464A9AB87 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: <53CE8C9C.8090303@earthlink.net> Date: Tue, 22 Jul 2014 12:32:07 -0400 Content-Transfer-Encoding: 7bit Message-Id: <68867DFE-7658-40F8-88C7-B71C6CAE4843@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE8C9C.8090303@earthlink.net> To: Charlie Perkins Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Kv_P2pGucEoyesMYryxxHqtDXeA Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , manet-ads Subject: Re: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 16:32:14 -0000 --Apple-Mail-05995AE7-B08C-4963-8A0B-A18464A9AB87 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 22 Jul 2014, at 12:09, Charlie Perkins w= rote: >=20 >=20 > Hello Chris, >=20 > While RFC 5444 is mandated for [manet], and thus AODVv2 must be > in compliance, it is my experience that RFC 5444 was not at all designed > for reactive protocols.=20 The above is a glaringly incorrect statement. When RFC5444 was designed, it was with substantial input from Ian Chakeres a= nd Charlie E. Perkins, so as to ensure that it was suitable also for their r= eactive protocol designs.=20 Furthermore, I actually have co-designed a fairly successful (as in: deploye= d very widely) reactive protocol, using RFC5444 -- and that, without the sli= ghtest of problems. > If there is going to be a new RFC 5444, it should > also include some consideration about how to fix this problem. There is no problem with RFC5444. There may be a problem with how you are using RFC5444, or how you are unders= tanding RFC5444. That problem-of-using and problem-of-understanding is what these documents a= re intended to address, > To restrict other protocols on the basis of something clever about > a supposedly "better" packet format's parser is putting the cart before > the horse. In which way?=20 > In the meantime, it would exacerbate an already unfortunate situation > to place additional RFC 5444 mandates without consideration of the > needs of non-proactive protocols. RFC 5444 seems to be all about how > to condense the representation of otherwise interchangeable IP > addresses. It has been made more difficult to include attach information > to specific IP addresses because that makes them non-interchangeable > in the AddrBlks.=20 This is a good example of how you are misunderstanding RFC5444. Attributes a= ssociated with addresses is indeed possible, and greatly facilitated in RFC5= 444, by that association being by way of TLVs. It is even easier to come up with a new protocol since if you already have a= n RFC5444 packet generator/parser, then you can reuse it unmodified. That greatly simplifies making protocol extensions, or making new protocols.= It would be a radically unfortunate situation to *not* support modularity an= d generic components. > This point of view becomes more or less irrelevant > (even counterproductive) when there are only one or two addresses in > the AddrBlks. No, not really. > Given the number of comments made regarding issues with AODVv2, > I don't think I can be much help with the process of reconsidering > RFC 5444 right now, but in the future I would be very happy to do so. There are no plans for reconsidering RFC5444. > Also, please note that this *should* *not* be construed to mean that I > do not intend AODVv2 to be conformant to RFC 5444. However, if all of > a sudden there were recognition within the working group that RFC 5444 > does place very significant (and, I think, undesirable) design constraints= > on protocol design, I would be very happy to go back to the way things > were before.=20 I think that you are profoundly misunderstanding things here. The "constraints" that you talk about serve - successfully - to ensure modul= arity, extensibility, flexibility and reuse -- between multiple different pr= otocols. As indicated, I have co-designed reactive protocols using RFC5444, and not o= nly was it possible, it was simple and efficient. And, by re-using the 5444-parser from my OLSRv2 implementation without modif= ications, it allowed extremely snappy development of prototype -- and later r= unning -- code, Thomas > Right now I do not have time to take up that cause. >=20 > Regards, > Charlie P. >=20 >=20 >=20 >> On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote: >> Actually, I think there has been some improvement here, but could be impr= oved further. This is at the level of comment I didn=E2=80=99t attempt to ma= ke, I concentrated on what I considered the most major issues. >> =20 >> IIRC, two TLVs are suggested, one to say =E2=80=9Cthis is A=E2=80=9D, one= to say =E2=80=9Cthis is B=E2=80=9D. It=E2=80=99s assumed there are two addr= esses, and the one that=E2=80=99s not A is B, and vice versal. >> =20 >> Better is to have a single TLV with a value for A or B. Why? First, it a= voids wasting a TLV code point. Second, you can flag A and B with a single m= ultivalue TLV more efficiently than marking A and B. And it=E2=80=99s a good= idea to mark A and B, because that way you can add additional addresses in a= n extension, without introducing any problems as to which is A or B with a s= ingle TLV. In addition, the practice we introduced in TLV extensions of havi= ng a null value (255 UNSPECIFIED is what we used) can help there as well. >> =20 >> One of those things the authors of 5444 etc. would like to do =E2=80=93 w= hen they can find some extra hours in a week =E2=80=93 is to set out this so= rt of good practice for 5444 that has been found to be valuable. In this cas= e we have the two principles of (a) always attack a TLV to indicate informat= ion, as just doing so from a non-TLVed address precludes various extensions,= and (b) when attaching information, null values are good =E2=80=93 T:LV ext= ensions discusses why, a lot comes down to that you can=E2=80=99t order for m= ore than one or two TLVs at once. >> =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Information Assurance Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 >> Sent: 22 July 2014 14:08 >> To: Dearlove, Christopher (UK) >> Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads >> Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (ao= dvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) >> =20 >> =20 >> *** WARNING *** >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Consider carefully whether you should click on any links, open any attach= ments or reply. >> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >> I am still, with reference to this document, dismayed to see that there r= emain abundant references to positional information in address blocks in RFC= 5444 messages.=20 >> =20 >> As has been pointed out numerous times, this is inappropriate, positional= information cannot be assumed assured and preserved by generic 5444 message= generation and parsing code. The first instance of this offense is in Table= 1 ... >> =20 >> This has been requested fixed for years now. When will it be fixed? >> =20 >> =20 >> On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) wrote: >> =20 >> RFC5444 describes a multiplexing process. It is not required purely in it= s own terms. But RFC 5498 make it mandatory for any protocol using the port/= protocol allocated by that RFC. And the WG has agreed that all routing proto= cols developed have to be able (at least) to use that port/protocol. >> =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Information Assurance Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryu= n >> Sent: 22 July 2014 12:02 >> To: manet@ietf.org >> Cc: draft-ietf-manet-aodvv2@tools.ietf.org >> Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for= Chris Dearlove) >> =20 >> =20 >> *** WARNING *** >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Consider carefully whether you should click on any links, open any attach= ments or reply. >> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >> IMHO The problem is that RFC5444 still does not have a multiplexing stand= ard in IETF. The way of multiplexing is still just implemented by OLSRv2 exp= erts but I dont find any standard for multiplexing yet. The RFC5498 is not f= or multipexing as I understand it. We already discussed once that multiplexi= ng is not specified for all RFC5444 formats because it is general format but= RFC5498 is not general. >> =20 >> If I am wrong please point me to an RFC. >> AB >> On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker wrote: >> #45: RFC 5498 non-compliance (submitted for Chris Dearlove) >>=20 >> The document is completely noncompliant with the RFC 5444 multiplexing >> mechanism, mandated by RFC 5498 (on the manet port/protocol). It does >> many things that are not within its competence. >>=20 >> -- >> -------------------------+-----------------------------------------------= -- >> Reporter: | Owner: draft-ietf-manet- >> charliep@computer.org | aodvv2@tools.ietf.org >> Type: defect | Status: new >> Priority: minor | Milestone: >> Component: aodvv2 | Version: >> Severity: Active WG | Keywords: RFC 5498 >> Document | >> -------------------------+-----------------------------------------------= -- >>=20 >> Ticket URL: >> manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> =20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> 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 --Apple-Mail-05995AE7-B08C-4963-8A0B-A18464A9AB87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 22 Jul 2014, at 12:0= 9, Charlie Perkins <char= les.perkins@earthlink.net> wrote:

=20 =20 =20
Hello Chris,

While RFC 5444 is mandated for [manet], and thus AODVv2 must be
in compliance, it is my experience that RFC 5444 was not at all designed
for reactive protocols. 

The abov= e is a glaringly incorrect statement.

When RFC5444 was de= signed, it was with substantial input from Ian Chakeres and Charlie E. Perki= ns, so as to ensure that it was suitable also for their reactive protocol de= signs. 

Furthermore, I actually have co-design= ed a fairly successful (as in: deployed very widely) reactive protocol, usin= g RFC5444 -- and that, without the slightest of problems.

If there is going to be a new RFC 5444, it should
also include some consideration about how to fix this problem.
=

There is no problem with RFC5444.

=
There may be a problem with how you are using RFC5444, or how you= are understanding RFC5444.

That problem-of-using a= nd problem-of-understanding is what these documents are intended to address,=

=20 To restrict other protocols on the basis of something clever about
a supposedly "better" packet format's parser is putting the cart before
the horse.

In which way? 

=20 In the meantime, it would exacerbate an already unfortunate situation
to place additional RFC 5444 mandates without consideration of the
needs of non-proactive protocols.  RFC 5444 seems to be all about how
to condense the representation of otherwise interchangeable IP
addresses. It has been made more difficult to include attach information
to specific IP addresses because that makes them non-interchangeable
= in the AddrBlks. 

This is a g= ood example of how you are misunderstanding RFC5444. Attributes associated w= ith addresses is indeed possible, and greatly facilitated in RFC5444, by tha= t association being by way of TLVs.

It is even easi= er to come up with a new protocol since if you already have an RFC5444 packe= t generator/parser, then you can reuse it unmodified.

That greatly simplifies making protocol extensions, or making new protoco= ls.

It would be a radically unfortunate situation t= o *not* support modularity and generic components.

This point of view becomes more or less irrelevant
(even counterproductive) when there are only one or two addresses in
= the AddrBlks.

No, not really.
=

Given the number of comments made regarding issues with AODVv2,
I don't think I can be much help with the process of reconsidering
RFC 5444 right now, but in the future I would be very happy to do so.

There are no plans for reconsid= ering RFC5444.

=20 Also, please note that this *should* *not* be construed to mean that I
do not intend AODVv2 to be conformant to RFC 5444.  However, if all= of
a sudden there were recognition within the working group that RFC 5444
does place very significant (and, I think, undesirable) design constraints
on protocol design, I would be very happy to go back to the way things
were before. 

I think that you are= profoundly misunderstanding things here.

The "cons= traints" that you talk about serve - successfully - to ensure modularity, ex= tensibility, flexibility and reuse -- between multiple different protocols.<= /div>

As indicated, I have co-designed reactive protocols= using RFC5444, and not only was it possible, it was simple and efficient.

And, by re-using the 5444-parser from my OLSRv2 impl= ementation without modifications, it allowed extremely snappy development of= prototype -- and later running -- code,

Thomas

Right now I do not hav= e time to take up that cause.

Regards,
Charlie P.



On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote:

Actually, I think there has been some improvement here, but could be improved further. This is at the level of comment I didn=E2=80=99= t attempt to make, I concentrated on what I considered the most major issues.

 

IIRC, two TLVs are suggested, one to say =E2=80=9Cthis is A=E2=80=9D, o= ne to say =E2=80=9Cthis is B=E2=80=9D. It=E2=80=99s assumed there are two a= ddresses, and the one that=E2=80=99s not A is B, and vice versal.

 

Better is to have a single TLV with a  value for A or B. Why? First, it avoids wasting a TLV code point. Second, you can flag A and B with a single multivalue TLV more efficiently than marking A and B. And it=E2=80=99s a good idea to mark A and= B, because that way you can add additional addresses in an extension, without introducing any problems as to which is A or B with a single TLV. In addition, the practice we introduced in TLV extensions of having a null value (255 UNSPECIFIED is what we used) can help there as well.<= /span>

 

One of those things the authors of 5444 etc. would like to do =E2=80= =93 when they can find some extra hours in a week =E2=80=93 is to se= t out this sort of good practice for 5444 that has been found to be valuable. In this case we have the two principles of (a) always attack a TLV to indicate information, as just doing so from a non-TLVed address precludes various extensions, and (b) when attaching information, null values are good =E2=80=93 T:LV extensions discusses why, a lot comes do= wn to that you can=E2=80=99t order for more than one or two TLVs at= once.

 

--

Christopher Dearlove

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

chris.dearlove@ba= esystems.com | http://www.baesystems.com

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

 

From:= Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 22 July 2014 14:08
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org;= manet-ads
Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

 

 

*** WARNING ***

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

I am still, with reference to this document, dismayed to see that there remain abundant references to positional information in address blocks in RFC5444 messages. 

 

As has been pointed out numerous times, this is inappropriate, positional information cannot be assumed assured and preserved by generic 5444 message generation and parsing code. The first instance of this offense is in Table 1 ...

 

This has been requested fixed for years now. When will it be fixed?

 

 

On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) <Chris.Dearlove@baesystems= .com> wrote:

 

RFC54= 44 describes a multiplexing process. It is not required purely in its own terms. But RFC 5498 make it mandatory for any protocol using the port/protocol allocated by that RFC. And the WG has agreed that all routing protocols developed have to be able (at least) to use that port/protocol.

 = ;

--

Chris= topher Dearlove

Senio= r Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 24= 2124

chris.dearlove@baesystems.com | http://www.baesystems.co= m

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

 = ;

From:= &= nbsp;manet [mail= to:manet-bounces@ietf.org]&= nbsp;On Behalf Of&= nbsp;Abdussalam Baryun
Sent:=  22 July 2014 12:02
To:&n= bsp;manet@ietf.org
Cc:&n= bsp;draft-ietf-manet-aodvv2@tools= .ietf.org
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

 

 

*** WARNING ***

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

IMHO The problem is that RFC5444 still does not have a multiplexing standard in IETF. The way of multiplexing is still just implemented by OLSRv2 experts but I dont find any standard for multiplexing yet. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not specified for all RFC5444 formats because it is general format but RFC5498 is not general.

 

If I am wrong please point me to an RFC.

AB

On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <trac+manet@trac.tools.ietf.org>= wrote:

#45: RFC 5498 non-compliance (submitted for Chris Dearlove)

 The document is completely noncompliant with the RFC 5444 multiplexing
 mechanism, mandated by RFC 5498 (on the manet port/protocol). It does
 many things that are not within its competence.

--
-------------------------+-------------------------------------------------<= br>  Reporter:         &nbs= p;     |      Owner:  draft-ietf-manet-
 &nbs= p;<= span style=3D"color:purple">charliep@computer.org  |  aodvv2@t= ools.ietf.org
     Type:  defect   &n= bsp;   |     Status:  new
 Priority:  minor      =  |  Milestone:
Component:  aodvv2       | &= nbsp;  Version:
 Severity:  Active WG    | &= nbsp; Keywords:  RFC 5498
  Document         &nbs= p;     |
-------------------------+-------------------------------------------------<= br>
Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45<= /a>>
manet <h= ttp://tools.ietf.org/manet/>

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

 

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

____________________= ___________________________
manet mailing list
manet@ietf.org<= br> https://www.ietf= .org/mailman/listinfo/manet

 


=20
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-05995AE7-B08C-4963-8A0B-A18464A9AB87-- From nobody Tue Jul 22 09:39:25 2014 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 E61F01A02F7 for ; Tue, 22 Jul 2014 09:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 fUO6DyyonD_k for ; Tue, 22 Jul 2014 09:39:23 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FA11A02EB for ; Tue, 22 Jul 2014 09:39:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208";a="459879339" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 17:39:21 +0100 X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208";a="58659047" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 17:39:28 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 17:39:29 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" Thread-Topic: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) Thread-Index: AQHPpJYUeiDPaaz1Z0eQvrYiMlVQoZup4hsAgAIoGECAAC8eAIAAEo3Q Date: Tue, 22 Jul 2014 16:39:28 +0000 Message-ID: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> In-Reply-To: <53CE909A.3050206@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rRiyT2XFHHOYSP0x661SsD-uXNY Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 16:39:25 -0000 SSB3b3VsZCBzdWdnZXN0IG91dGxpbmluZyB0aGUgYmFzaWMgY29uY2VwdCBvbiBsaXN0LiBEb2Vz bid0IG5lZWQgYSBkZXRhaWxlZCB3cml0ZXVwIHRvIHN0YXJ0IHdpdGguIEluIGZhY3QgZG9pbmcg c28gbWlnaHQgbWluaW1pc2UgdGhlIG51bWJlciBvZiB3cml0ZXVwcyBhbmQgcmUtd3JpdGV1cHMu DQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIs IEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFu ZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9s b2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTTCoHwgIEZheDogKzQ0IDEyNDUg MjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lz dGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQg T2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBD ZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVu Z2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBDaGFybGVzIEUuIFBlcmtpbnMgW21haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmdd IA0KU2VudDogMjIgSnVseSAyMDE0IDE3OjI2DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChV Syk7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSAjNDcgKGFvZHZ2Mik6IFNl Y3VyaXR5IGFwcHJvYWNoIHVuYWNjZXB0YWJsZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92 ZSkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRp b24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQu DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5r cywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3Vz cGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJl cG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSGVsbG8gQ2hyaXMsDQoNCkZp cnN0LCBJIG11c3QgaGF2ZSBhIHByb3Bvc2FsLiAgV2hlbiBJIGhhdmUgdGhhdCwgSSB3aWxsIGNl cnRhaW5seSBkaXNjdXNzIHdpdGggdGhlIHdvcmtpbmcgZ3JvdXAgYmVmb3JlIGluY2x1c2lvbiBp biB0aGUgZHJhZnQuICBSaWdodCBub3csIEkganVzdCBoYXZlIGEgZ29vZCBpZGVhIGZvciBhIHBy b3Bvc2FsIC0tIGluIG90aGVyIHdvcmRzLCBhIHdheSBmb3J3YXJkLiAgSSBoYXZlIHNlbnQgaXQg dG8gbXkgY28tYXV0aG9ycy4gIEl0IG5lZWRzIG1vcmUgdGV4dC4NCg0KSWYgeW91IHdvdWxkIGxp a2UgdG8gaGVscCBmbGVzaCBvdXQgdGhlIHRleHQsIHBsZWFzZSBsZXQgbWUga25vdy4gSSdsbCBi ZSBoYXBweSB0byB3b3JrIHdpdGggeW91IG9uIGl0IGFzIHdlbGwgdG8gbWFrZSBpdCBhIGJldHRl ci10aG91Z2h0LW91dCBwcm9wb3NhbC4gIEkndmUgbm90aWNlZCB0aGF0IHNvbWV0aW1lcyBwZW9w bGUgb24gdGhpcyBsaXN0IGNhbiBiZSB2ZXJ5LCB2ZXJ5IGNyaXRpY2FsLCBhbmQgdGhpcyBtb3Rp dmF0ZXMgdGhlIGRlc2lyZSB0byBkbyBhIGJldHRlciBqb2IgYmVmb3JlIHByZXNlbnRpbmcgaWRl YXMgdG8gdGhlIGxpc3QuDQoNCk90aGVyIHdvcmtpbmcgZ3JvdXBzIGFyZSBkaWZmZXJlbnQuDQoN Ck9uIDcvMjIvMjAxNCA1OjM4IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToN Cj4gSXQgbWlnaHQgbWFrZSBtb3JlIHNlbnNlIHRvIGRpc2N1c3MgYSBwcm9wb3NhbCBmb3IgaW5j bHVzaW9uIGluIGEgV0cgZHJhZnQgd2l0aCB0aGUgV0cgZmlyc3QuDQo+DQoNCi0tDQpSZWdhcmRz LA0KQ2hhcmxpZSBQLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBs ZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllv dSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xv c2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioK From nobody Tue Jul 22 09:43:43 2014 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 D0C121A02E2 for ; Tue, 22 Jul 2014 09:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 jLxeZMD-fdXK for ; Tue, 22 Jul 2014 09:43:40 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A201A01C6 for ; Tue, 22 Jul 2014 09:43:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id E68A1921347; Tue, 22 Jul 2014 09:43:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 69DF592135D; Tue, 22 Jul 2014 09:43:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 12:43:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE8C9C.8090303@earthlink.net> To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/s31VjKUV3ZQAfTuBLJntfaqptUs Cc: Charlie Perkins , "manet@ietf.org" , manet-ads Subject: Re: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 16:43:41 -0000 Couple of comments... > On 22 Jul 2014, at 12:27, "Dearlove, Christopher (UK)" wrote: >=20 > This is a WG document, not just your private document, and I'm pointing ou= t how it can be better. And not at a significant efficiency cost. But you wi= ll note this wasn't on my list of major issues, this was on the list I haven= 't got to. I only mentioned it as relevant to someone else's point. It's just worth recalling that reviews to the reactive protocol have been po= sted on the mailing list since the Maastricht IETF, and that these largely h= ave gone unanswered and unaddressed by the authors -- even to this day. > As for your last point, that's implying a totally unacceptable option. Agreed. > It has been agreed by the WG, and defined in Proposed Standards, that > - MANET WG routing protocols shall be able to use the manet port/protocol.= > - RFC 5498 mandates that anything using that port/protocol shall use not j= ust RFC 5444, but the RFC 5444 multiplexer. > - The separation out of the RFC 5444 format as not just for OLSRv2 (includ= ing the also then not split out NHDP) was also a WG imposed requirement. Yes. > On that last point, given that RFC 5498 was (inexplicably to me) accepted b= efore RFC 5444, the IESG insisted that RFC 5444 contain a specification of t= he multiplexing mechanism that RFC 5498 had imposed on it. And RFC 5498 was a= uthored by your then DYMO co-author. He obviously didn't feel it couldn't co= pe with reactive protocols. To this point, one of the ideas of these new documents that we're working on= is also to clarify that slight oddity which the "reverse order" of 5498 and= 5444 caused -- but not to obsolete or update 5444 or 5498. > As for there being too many issues with AODVv2, yes, there are too many is= sues with AODVv2. That's the problem. The solution is not to ignore them, bu= t to fix them (the WG having taken the decision not to restart from a docume= nt with fewer issues). A frustrating bit here is, though, that even though issues have been pointed= out "many draft revisions ago", they still appear in the current version. Another frustrating bit here is, that the current revision introduces sizabl= e new text, which introduces a good deal of new issues, while not resolving a= ny of those having been raised previously. Thomas > As for the only two addresses, you're imposing a restriction on any future= extension that might want to report an address for another reason. I don't t= hink that is a good idea. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > From: Charlie Perkins [mailto:charles.perkins@earthlink.net]=20 > Sent: 22 July 2014 17:09 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; manet-ads > Subject: Please, no more RFC 5444 mandates right now... >=20 >=20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Hello Chris, >=20 > While RFC 5444 is mandated for [manet], and thus AODVv2 must be > in compliance, it is my experience that RFC 5444 was not at all designed > for reactive protocols. If there is going to be a new RFC 5444, it should= > also include some consideration about how to fix this problem. >=20 > To restrict other protocols on the basis of something clever about > a supposedly "better" packet format's parser is putting the cart before > the horse. >=20 > In the meantime, it would exacerbate an already unfortunate situation > to place additional RFC 5444 mandates without consideration of the > needs of non-proactive protocols. RFC 5444 seems to be all about how > to condense the representation of otherwise interchangeable IP > addresses. It has been made more difficult to include attach information > to specific IP addresses because that makes them non-interchangeable > in the AddrBlks. This point of view becomes more or less irrelevant > (even counterproductive) when there are only one or two addresses in > the AddrBlks. >=20 > Given the number of comments made regarding issues with AODVv2, > I don't think I can be much help with the process of reconsidering > RFC 5444 right now, but in the future I would be very happy to do so. >=20 > Also, please note that this *should* *not* be construed to mean that I > do not intend AODVv2 to be conformant to RFC 5444. However, if all of > a sudden there were recognition within the working group that RFC 5444 > does place very significant (and, I think, undesirable) design constraints= > on protocol design, I would be very happy to go back to the way things > were before. Right now I do not have time to take up that cause. >=20 > Regards, > Charlie P. >=20 >=20 > On 7/22/2014 6:45 AM, Dearlove, Christopher (UK) wrote: > Actually, I think there has been some improvement here, but could be impro= ved further. This is at the level of comment I didn't attempt to make, I con= centrated on what I considered the most major issues. > =20 > IIRC, two TLVs are suggested, one to say "this is A", one to say "this is B= ". It's assumed there are two addresses, and the one that's not A is B, and v= ice versal. > =20 > Better is to have a single TLV with a value for A or B. Why? First, it av= oids wasting a TLV code point. Second, you can flag A and B with a single mu= ltivalue TLV more efficiently than marking A and B. And it's a good idea to m= ark A and B, because that way you can add additional addresses in an extensi= on, without introducing any problems as to which is A or B with a single TLV= . In addition, the practice we introduced in TLV extensions of having a null= value (255 UNSPECIFIED is what we used) can help there as well. > =20 > One of those things the authors of 5444 etc. would like to do - when they c= an find some extra hours in a week - is to set out this sort of good practic= e for 5444 that has been found to be valuable. In this case we have the two p= rinciples of (a) always attack a TLV to indicate information, as just doing s= o from a non-TLVed address precludes various extensions, and (b) when attach= ing information, null values are good - T:LV extensions discusses why, a lot= comes down to that you can't order for more than one or two TLVs at once. > =20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 22 July 2014 14:08 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org; manet-ads > Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aod= vv2): RFC 5498 non-compliance (submitted for Chris Dearlove)) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. > I am still, with reference to this document, dismayed to see that there re= main abundant references to positional information in address blocks in RFC5= 444 messages.=20 > =20 > As has been pointed out numerous times, this is inappropriate, positional i= nformation cannot be assumed assured and preserved by generic 5444 message g= eneration and parsing code. The first instance of this offense is in Table 1= ... > =20 > This has been requested fixed for years now. When will it be fixed? > =20 > =20 > On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) wrote: > =20 > RFC5444 describes a multiplexing process. It is not required purely in its= own terms. But RFC 5498 make it mandatory for any protocol using the port/p= rotocol allocated by that RFC. And the WG has agreed that all routing protoc= ols developed have to be able (at least) to use that port/protocol. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun= > Sent: 22 July 2014 12:02 > To: manet@ietf.org > Cc: draft-ietf-manet-aodvv2@tools.ietf.org > Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for C= hris Dearlove) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. > IMHO The problem is that RFC5444 still does not have a multiplexing standa= rd in IETF. The way of multiplexing is still just implemented by OLSRv2 expe= rts but I dont find any standard for multiplexing yet. The RFC5498 is not fo= r multipexing as I understand it. We already discussed once that multiplexin= g is not specified for all RFC5444 formats because it is general format but R= FC5498 is not general. > =20 > If I am wrong please point me to an RFC. > AB > On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker wrote: > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) >=20 > The document is completely noncompliant with the RFC 5444 multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. >=20 > -- > -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-manet- > charliep@computer.org | aodvv2@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: aodvv2 | Version: > Severity: Active WG | Keywords: RFC 5498 > Document | > -------------------------+------------------------------------------------= - >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > 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 From nobody Tue Jul 22 09:44:46 2014 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 796CC1A02E2 for ; Tue, 22 Jul 2014 09:44:44 -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 6kEGyd2ePXLq for ; Tue, 22 Jul 2014 09:44:42 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147EB1B29F9 for ; Tue, 22 Jul 2014 09:44:41 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so6385745wiv.7 for ; Tue, 22 Jul 2014 09:44:40 -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=1Lu7Dh1xlOuAft0baHVcr3IxVwZ56jPEDSkxgCSMD/8=; b=lnAdT0pNOezfw+CX+ebcLaMi1rhEq0NZpNKY1sM7hG7kZOjWgYl9ifo7zN+JQ9QYul /he3k8OPAA7NqkhgcaPaR4h2YA2OaHFo4ND+NYoWa1PL8Mv4V3rH+EBRVPhV7YvJiSew lB92CF91BjsZ/xGRXqPhjb80N7k29wGH0Xra99qXgktUsYlbZrsz2OAInclTe/8yqIcr Zh/ydHPaHV2zfqyKohekUXDfdwz5x+dObLL0UQueBEScb6Ro0FNaMbU5BXg24wanHbzB ODl0cvJexmqFovjdQvBtQBFIYIWHepts55XhKKg8LEq+NL0doMMrDEkXC/n7j/AVFKWw O5hQ== MIME-Version: 1.0 X-Received: by 10.180.109.168 with SMTP id ht8mr16143747wib.68.1406047480706; Tue, 22 Jul 2014 09:44:40 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Tue, 22 Jul 2014 09:44:40 -0700 (PDT) In-Reply-To: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> Date: Tue, 22 Jul 2014 18:44:40 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=e89a8f3bab1b9fff0d04fecaf052 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cecd0L6MeFN2Kx3gTJZ5ZSEkxv0 Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) 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, 22 Jul 2014 16:44:44 -0000 --e89a8f3bab1b9fff0d04fecaf052 Content-Type: text/plain; charset=UTF-8 So I understand from your message that there is no mandate of multiplexing method or specific format method. 5498 defines port/protocol for such format. Usually messages, formats, packets, and multiplex, are not more important than the AODVv2 protocol function, so usually we set function then the messaging and then multiplexing. IMHO it was not right that this WG spend lot of effort and years to do RFC5444 before completing its two basic standards (reactive and proactive), but it is ok if we make priority to the standards function. AB On Tuesday, July 22, 2014, Dearlove, Christopher (UK) wrote: > RFC5444 describes a multiplexing process. It is not required purely in > its own terms. But RFC 5498 make it mandatory for any protocol using the > port/protocol allocated by that RFC. And the WG has agreed that all routing > protocols developed have to be able (at least) to use that port/protocol. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com > | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > *From:* manet [mailto:manet-bounces@ietf.org > ] *On Behalf Of *Abdussalam > Baryun > *Sent:* 22 July 2014 12:02 > *To:* manet@ietf.org > *Cc:* draft-ietf-manet-aodvv2@tools.ietf.org > > *Subject:* Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted > for Chris Dearlove) > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > IMHO The problem is that RFC5444 still does not have a multiplexing > standard in IETF. The way of multiplexing is still just implemented by > OLSRv2 experts but I dont find any standard for multiplexing yet. The > RFC5498 is not for multipexing as I understand it. We already discussed > once that multiplexing is not specified for all RFC5444 formats because it > is general format but RFC5498 is not general. > > > > If I am wrong please point me to an RFC. > > AB > > On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker < > trac+manet@trac.tools.ietf.org > > wrote: > > #45: RFC 5498 non-compliance (submitted for Chris Dearlove) > > The document is completely noncompliant with the RFC 5444 multiplexing > mechanism, mandated by RFC 5498 (on the manet port/protocol). It does > many things that are not within its competence. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-manet- > charliep@computer.org > | > aodvv2@tools.ietf.org > > Type: defect | Status: new > Priority: minor | Milestone: > Component: aodvv2 | Version: > Severity: Active WG | Keywords: RFC 5498 > Document | > -------------------------+------------------------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > --e89a8f3bab1b9fff0d04fecaf052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So I understand from your message that there is no mandate of multiplexing = method or specific format method. 5498 defines port/protocol for such forma= t.=C2=A0

Usually messages, formats, packets, and multipl= ex,=C2=A0are not more important than the AODVv2=C2=A0protocol function, so = usually we=C2=A0set function then the messaging and then=C2=A0multiplexing.= IMHO it=C2=A0was not right that this WG spend lot of effort and years=C2= =A0to do RFC5444 before completing its two basic standards (reactive and pr= oactive), but it is ok if we make priority to the=C2=A0standards=C2=A0funct= ion.=C2=A0

AB

On Tuesday, July 22, 2014, Dearlove, Chr= istopher (UK) wrote:

RFC5444 describes a multi= plexing process. It is not required purely in its own terms. But RFC 5498 m= ake it mandatory for any protocol using the port/protocol allocated by that RFC. And the WG has agreed that all routing protocols de= veloped have to be able (at least) to use that port/protocol.=

=C2=A0

--

Christopher Dearlove

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

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

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

=C2=A0

From: manet [mailto:manet-bounces= @ietf.org] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 12:02
To: manet@ietf.org
Cc: draft-ietf-manet-aodvv= 2@tools.ietf.org
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitte= d for Chris Dearlove)

=C2=A0

=C2=A0

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

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

IMHO The problem is that RFC5444 still does not have= a multiplexing standard in IETF. The way of multiplexing is still just imp= lemented by OLSRv2 experts but I dont find any standard for multiplexing ye= t. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not spe= cified for all RFC5444 formats because it is general format but RFC5498 is = not general.

=C2=A0

If I am wrong please point me to an RFC.

AB

On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker= <trac+manet@trac.tools.ietf.org= > wrote:

#45: RFC 5498 non-compliance (submitted for Chris De= arlove)

=C2=A0The document is completely noncompliant with the RFC 5444 multiplexin= g
=C2=A0mechanism, mandated by RFC 5498 (on the manet port/protocol). It does=
=C2=A0many things that are not within its competence.

--
-------------------------+-------------------------------------------------=
=C2=A0Reporter: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0Owner: =C2=A0draft-ietf-manet-
=C2=A0 charliep@computer.org =C2=A0| =C2=A0aodvv2@tools.ietf.org
=C2=A0 =C2=A0 =C2=A0Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= Status: =C2=A0new
=C2=A0Priority: =C2=A0minor =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0Milestone: Component: =C2=A0aodvv2 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Version:
=C2=A0Severity: =C2=A0Active WG =C2=A0 =C2=A0| =C2=A0 Keywords: =C2=A0RFC 5= 498
=C2=A0 Document =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45> manet <http:/= /tools.ietf.org/manet/>

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

=C2=A0

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

--e89a8f3bab1b9fff0d04fecaf052-- From nobody Tue Jul 22 09:45:20 2014 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 3A9881B29EF for ; Tue, 22 Jul 2014 09:45:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4y0qeL_k4S97 for ; Tue, 22 Jul 2014 09:45:18 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549D31B29ED for ; Tue, 22 Jul 2014 09:45:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id F3B53D407FC; Tue, 22 Jul 2014 09:45:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 985DAD400E2; Tue, 22 Jul 2014 09:45:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 12:45:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE8C9C.8090303@earthlink.net> To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/dU3Ala4IJ90kRDAkoyNB_3CCjqU Cc: Charlie Perkins , "manet@ietf.org" , manet-ads Subject: Re: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 16:45:19 -0000 And, one very specific comment... > On 22 Jul 2014, at 12:27, "Dearlove, Christopher (UK)" wrote: >=20 > As for the only two addresses, you're imposing a restriction on any future= extension that might want to report an address for another reason. I don't t= hink that is a good idea. Also, I haste to point out, there are good uses for -- in a reactive protoco= l with multiple addresses on multiple interfaces -- being able to include mo= re than two addresses in the various messages. This, even, before starting to think about extensions -- where, obviously, t= his is very true as Chris state. Thomas= From nobody Tue Jul 22 09:46:34 2014 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 219CA1B2A0E for ; Tue, 22 Jul 2014 09:46:33 -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 XypH0XVefREZ for ; Tue, 22 Jul 2014 09:46:32 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8FA1B29EF for ; Tue, 22 Jul 2014 09:46:31 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so6262621lbi.10 for ; Tue, 22 Jul 2014 09:46:30 -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=ZmWmg4QRuoZDcBgs9QnWJd0hZCh/F0iBoVRhcZDn8rw=; b=yd7SKV3OuZROwKhcVHHd1aUPvH+CEf0DnPvVzWHXdTuHbwkwFOFNBORnfLwO+XA0K3 +asVd/V4g4SPLCd2YM0BU7rn2reAMwuZqMtPwdjQ5tICkno5Hw63JybHSeEZQ3ylMuJx Qr5SWPIK6e+z5CjLAH9VklootShmVzhkK/rUncyBOVoolCtF1hlwed+7ZHeVYYuZ/F3i 6RmsfTYT077OkxE1opmZS3mO/aH10YjvxWyoGeJLI+XYdpnY2HTYVyMBGd3bluMKHZhs v3siX4AIpl2MdpmLfspFl/eJFhVtP3nICGAAjVJqjl7TIUKf8whJLbUKuBVpetMc4u5W jaiw== MIME-Version: 1.0 X-Received: by 10.152.36.225 with SMTP id t1mr37311507laj.65.1406047589956; Tue, 22 Jul 2014 09:46:29 -0700 (PDT) Received: by 10.152.104.236 with HTTP; Tue, 22 Jul 2014 09:46:29 -0700 (PDT) In-Reply-To: References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> Date: Tue, 22 Jul 2014 12:46:29 -0400 Message-ID: From: Justin Dean To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0158b5d423066d04fecaf71e Archived-At: http://mailarchive.ietf.org/arch/msg/manet/U2zANfzhiAw2TpLSnAoEsdVnXHk Cc: "" , "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 16:46:33 -0000 --089e0158b5d423066d04fecaf71e Content-Type: text/plain; charset=UTF-8 No it's implemented in my not yet publicly released OLSRv2 code. (which is at the point I would be comfortable passing it along to you) Our OLSRv2 implementation state: Written, compiling, running, adding routes and only crashing on occasion...So about 25-25% finished ;p Justin On Tue, Jul 22, 2014 at 11:37 AM, Henning Rogge wrote: > On Tue, Jul 22, 2014 at 5:36 PM, Justin Dean wrote: > > Henning I would very much like to make these changes in my code (yes I > have > > an implementation) and provide it for interop testing. It would be nice > to > > catch any glaring mistakes/omissions in the draft that us humans may have > > missed. > > You implemented this in your NHDP implementation? Yes, we definitely > should repeat our interop test! > > (how is your OLSRv2 implementation coming?) > > Henning Rogge > --089e0158b5d423066d04fecaf71e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No it's implemented in my not yet publicly released OL= SRv2 code. =C2=A0(which is at the point I would be comfortable passing it a= long to you)

Our OLSRv2 implementation state: Written, compiling, ru= nning, adding routes and only crashing on occasion...So about 25-25% finish= ed ;p
=C2=A0
Justin


On Tue, Jul 22, 2014 at 11:37 AM, Henning Rogge = <hrogge@gmail.com<= /a>> wrote:
On Tue, Jul 22, 2014 at 5:36= PM, Justin Dean <bebemaster@gma= il.com> wrote:
> Henning I would very much like to make these changes in my code (yes I= have
> an implementation) and provide it for interop testing. =C2=A0It would = be nice to
> catch any glaring mistakes/omissions in the draft that us humans may h= ave
> missed.

You implemented this in your NHDP implementation? Yes, we definitely<= br> should repeat our interop test!

(how is your OLSRv2 implementation coming?)

Henning Rogge

--089e0158b5d423066d04fecaf71e-- From nobody Tue Jul 22 09:47:58 2014 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 8A3CC1A0104 for ; Tue, 22 Jul 2014 09:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OVHtx00sV3Bw for ; Tue, 22 Jul 2014 09:47:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DB41A00F4 for ; Tue, 22 Jul 2014 09:47:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7B2E3247326; Tue, 22 Jul 2014 09:47:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 512FA2407D0; Tue, 22 Jul 2014 09:47:56 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B95E40DD-1E16-4486-9A2F-61FFB3C39671 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 12:47:55 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2F7C0DDB-4171-4D63-B259-DF3B09B59B2C@thomasclausen.org> References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> To: Justin Dean Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PX4K41WjISNd0VcErfG7pou-rsY Cc: "" , "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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: Tue, 22 Jul 2014 16:47:57 -0000 --Apple-Mail-B95E40DD-1E16-4486-9A2F-61FFB3C39671 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 22 Jul 2014, at 12:46, Justin Dean wrote: >=20 > No it's implemented in my not yet publicly released OLSRv2 code. (which i= s at the point I would be comfortable passing it along to you) >=20 > Our OLSRv2 implementation state: Written, compiling, running, adding route= s and only crashing on occasion... I'm sure, Justin, that with a little effort you can get it to the point wher= e it will be crashing all the time ;) > So about 25-25% finished ;p > =20 > Justin >=20 >=20 >> On Tue, Jul 22, 2014 at 11:37 AM, Henning Rogge wrote:= >> On Tue, Jul 22, 2014 at 5:36 PM, Justin Dean wrote= : >> > Henning I would very much like to make these changes in my code (yes I h= ave >> > an implementation) and provide it for interop testing. It would be nic= e to >> > catch any glaring mistakes/omissions in the draft that us humans may ha= ve >> > missed. >>=20 >> You implemented this in your NHDP implementation? Yes, we definitely >> should repeat our interop test! >>=20 >> (how is your OLSRv2 implementation coming?) >>=20 >> Henning Rogge >=20 --Apple-Mail-B95E40DD-1E16-4486-9A2F-61FFB3C39671 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 22 Jul 2014, at 12:46, Justin Dean <bebemaster@gmail.com> wrote:

No it's implemented in my not yet publicly released OLSRv2 code.  (which is at the point I would be comfortable passing it along to you)

Our OLSRv2 implementation state: Written, compiling, running, adding routes and only crashing on occasion...

I'm sure, Justin, that with a little effort you can get it to the point where it will be crashing all the time ;)

So about 25-25% finished ;p
 
Justin


On Tue, Jul 22, 2014 at 11:37 AM, Henning Rogge <hrogge@gmail.com> wrote:
On Tue, Jul 22, 2014 at 5:36 PM, Justin Dean <bebemaster@gmail.com> wrote:
> Henning I would very much like to make these changes in my code (yes I have
> an implementation) and provide it for interop testing.  It would be nice to
> catch any glaring mistakes/omissions in the draft that us humans may have
> missed.

You implemented this in your NHDP implementation? Yes, we definitely
should repeat our interop test!

(how is your OLSRv2 implementation coming?)

Henning Rogge

--Apple-Mail-B95E40DD-1E16-4486-9A2F-61FFB3C39671-- From nobody Tue Jul 22 09:48:46 2014 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 5DBDC1A0104 for ; Tue, 22 Jul 2014 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 lqRXlMUX6qGU for ; Tue, 22 Jul 2014 09:48:43 -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 B417C1B29F6 for ; Tue, 22 Jul 2014 09:48:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208";a="388562182" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 17:48:41 +0100 X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208";a="65674271" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 17:48:48 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 17:48:48 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , manet Thread-Topic: [manet] Question to ADOVv2 applicability statement Thread-Index: AQHPpcj3iYU1qXldr0uGj9fp5MaAN5usS+6A Date: Tue, 22 Jul 2014 16:48:48 +0000 Message-ID: References: <677582AE-0FEA-46BC-A056-2CBD6824347D@thomasclausen.org> In-Reply-To: <677582AE-0FEA-46BC-A056-2CBD6824347D@thomasclausen.org> 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: http://mailarchive.ietf.org/arch/msg/manet/xR69ikqfLHjGnc0u2V7lgOVo5Z8 Subject: Re: [manet] Question to ADOVv2 applicability statement 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, 22 Jul 2014 16:48:44 -0000 I'm going to disagree here to some extent. First, if we allow one (and only one) attached network then we can consider= the MANET as a stub. (Obviously no attached networks is disconnected.) So what about more than one attached network? Just to get it out of the way, from insider the MANET, there is a definite = issue as to whether those attached networks can be the same, different but = overlapping, or must be disjoint. But that's not the issue here. If we can have two (or more) attached networks, we could make the MANET a t= ransit network. Which is a case some people want. But you could still make = it behave only as if a stub from multiple places (I'd have to check my term= inology to check if that's also classified as a stub). So I think the two issues (stub only, number of attached networks) are rela= ted (because there's an impossible combination) but stub does not automatic= ally exclude multiple attached networks. I'm not sure what AODVv2 is offering here. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen Sent: 22 July 2014 17:21 To: manet Subject: [manet] Question to ADOVv2 applicability statement ----------------------! 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. -------------------------------------------------------- The draft states: > The AODVv2 routing protocol is designed for stub (i.e., non-transit) or= disconnected (i.e., > from the Internet) mobile ad hoc networks (MANETs). Does this mean that this protocol does not support "attached network", as a= re known from OLSRv2 (and OLSR, even)? = If the answer is "yes, it does support attached networks" then the statemen= t quoted above is incorrect. = If the answer is "no, it does not support attached network" then the statem= ent quoted is correct -- but, it's a limitation of the protocol that I am n= ot enthusiastic about Sent from my iPad _______________________________________________ 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 Tue Jul 22 09:49:44 2014 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 BE4821B2A21 for ; Tue, 22 Jul 2014 09:49:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 58LDAuHZm1Du for ; Tue, 22 Jul 2014 09:49:41 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6D91B2A1B for ; Tue, 22 Jul 2014 09:49:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 597A82408CA; Tue, 22 Jul 2014 09:49:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 32B59240820; Tue, 22 Jul 2014 09:49:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 12:49:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7A4D33C4-2176-4AC9-B978-296B92D95D1B@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SNYvZ7hxh1ajb8YnIuxPBIdWaZg Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 22 Jul 2014 16:49:42 -0000 > On 22 Jul 2014, at 11:25, Henning Rogge wrote: >=20 > On Tue, Jul 22, 2014 at 4:25 PM, Dearlove, Christopher (UK) > wrote: >> I'm expecting to be contributing as an author here, and your input will b= e valuable here. >>=20 >> I'm not sure how far this document will get (it's effort limited as has b= een said). If we get to an abstract representation of 5444 information (we m= ay or may not) then I'm aware of at least two approaches with advantages or d= isadvantages. >=20 > fun fact about my parser API... there are TWO ways to get TLVs (and > the attached context) with my API. >=20 > One is similar to a XML SAX parser... you get a callback for each > hierarchy that opens/closes and one for each object inside. This is > useful for parsing incoming data without knowing the structure. > The other one uses a predefined array of TLVs (for either packet, > message or address level) your code is interested in . With this > method you get all the relevant TLVs at once instead of one by one. >=20 >> Roughly speaking, one is iterator based, one is map based, with different= tradeoffs (and preserving slightly different information). However I don't t= hink we should specify an API here. Publication of an API separately (ID or s= oftware documentation) could well be useful. >=20 > I agree, specifying a fixed API sounds bad... and before I would > consider publishing "my" API as an ID I would really need some review > of it. >=20 With that being said....at some point, it would be fun to get you to come to= an IETF, and present not a protocol, but exactly your parser/generator. Run= ning code, and all that... Thomas > Henning Rogge From nobody Tue Jul 22 09:51:17 2014 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 CF84D1B2A23 for ; Tue, 22 Jul 2014 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 oBx2lYN_Um0j for ; Tue, 22 Jul 2014 09:51:13 -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 E62441B2A17 for ; Tue, 22 Jul 2014 09:51:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208,217";a="388562569" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 17:51:11 +0100 X-IronPort-AV: E=Sophos; i="5.01,711,1400022000"; d="scan'208,217"; a="65674452" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 17:51:18 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 17:51:18 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) Thread-Index: AQHPpJWJ9gYyJ8BybUCpcuu2+pDuDZur3teAgAAnEvCAADieAIAAEl5g Date: Tue, 22 Jul 2014 16:51:18 +0000 Message-ID: References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF1A6GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/TMvhpTlk_ijASSf7oSZ1krANoVo Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) 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, 22 Jul 2014 16:51:15 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF1A6GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGhhdmUgbWFuYWdlZCB0byByZWFkIHRoZSBleGFjdCBvcHBvc2l0ZSBvZiB3aGF0IEkgd3Jv dGUuIEkgc3VnZ2VzdCByZWFkaW5nIHRoZSBSRkNzLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxv dmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91 cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5 DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmll bGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQg MTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8v d3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpS ZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBB ZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0 ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogbWFuZXQgW21haWx0 bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWJkdXNzYWxhbSBCYXJ5dW4N ClNlbnQ6IDIyIEp1bHkgMjAxNCAxNzo0NQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp DQpDYzogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0QGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSAjNDUgKGFvZHZ2Mik6IFJGQyA1NDk4IG5vbi1jb21w bGlhbmNlIChzdWJtaXR0ZWQgZm9yIENocmlzIERlYXJsb3ZlKQ0KDQoNCioqKiBXQVJOSU5HICoq Kg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQg RmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNs aWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVs IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRw Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4N ClNvIEkgdW5kZXJzdGFuZCBmcm9tIHlvdXIgbWVzc2FnZSB0aGF0IHRoZXJlIGlzIG5vIG1hbmRh dGUgb2YgbXVsdGlwbGV4aW5nIG1ldGhvZCBvciBzcGVjaWZpYyBmb3JtYXQgbWV0aG9kLiA1NDk4 IGRlZmluZXMgcG9ydC9wcm90b2NvbCBmb3Igc3VjaCBmb3JtYXQuDQoNClVzdWFsbHkgbWVzc2Fn ZXMsIGZvcm1hdHMsIHBhY2tldHMsIGFuZCBtdWx0aXBsZXgsIGFyZSBub3QgbW9yZSBpbXBvcnRh bnQgdGhhbiB0aGUgQU9EVnYyIHByb3RvY29sIGZ1bmN0aW9uLCBzbyB1c3VhbGx5IHdlIHNldCBm dW5jdGlvbiB0aGVuIHRoZSBtZXNzYWdpbmcgYW5kIHRoZW4gbXVsdGlwbGV4aW5nLiBJTUhPIGl0 IHdhcyBub3QgcmlnaHQgdGhhdCB0aGlzIFdHIHNwZW5kIGxvdCBvZiBlZmZvcnQgYW5kIHllYXJz IHRvIGRvIFJGQzU0NDQgYmVmb3JlIGNvbXBsZXRpbmcgaXRzIHR3byBiYXNpYyBzdGFuZGFyZHMg KHJlYWN0aXZlIGFuZCBwcm9hY3RpdmUpLCBidXQgaXQgaXMgb2sgaWYgd2UgbWFrZSBwcmlvcml0 eSB0byB0aGUgc3RhbmRhcmRzIGZ1bmN0aW9uLg0KDQpBQg0KDQpPbiBUdWVzZGF5LCBKdWx5IDIy LCAyMDE0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToNClJGQzU0NDQgZGVzY3Jp YmVzIGEgbXVsdGlwbGV4aW5nIHByb2Nlc3MuIEl0IGlzIG5vdCByZXF1aXJlZCBwdXJlbHkgaW4g aXRzIG93biB0ZXJtcy4gQnV0IFJGQyA1NDk4IG1ha2UgaXQgbWFuZGF0b3J5IGZvciBhbnkgcHJv dG9jb2wgdXNpbmcgdGhlIHBvcnQvcHJvdG9jb2wgYWxsb2NhdGVkIGJ5IHRoYXQgUkZDLiBBbmQg dGhlIFdHIGhhcyBhZ3JlZWQgdGhhdCBhbGwgcm91dGluZyBwcm90b2NvbHMgZGV2ZWxvcGVkIGhh dmUgdG8gYmUgYWJsZSAoYXQgbGVhc3QpIHRvIHVzZSB0aGF0IHBvcnQvcHJvdG9jb2wuDQoNCi0t DQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3Jt YXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdl IEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2Vu dHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENN MiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0K Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwn LCdjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbScpOz4gfCBodHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9m ZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2Vu dHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbWFuZXQtYm91bmNlc0Bp ZXRmLm9yZycpOz5dIE9uIEJlaGFsZiBPZiBBYmR1c3NhbGFtIEJhcnl1bg0KU2VudDogMjIgSnVs eSAyMDE0IDEyOjAyDQpUbzogbWFuZXRAaWV0Zi5vcmc8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2 bWwnLCdtYW5ldEBpZXRmLm9yZycpOz4NCkNjOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29s cy5pZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2RyYWZ0LWlldGYtbWFuZXQt YW9kdnYyQHRvb2xzLmlldGYub3JnJyk7Pg0KU3ViamVjdDogUmU6IFttYW5ldF0gIzQ1IChhb2R2 djIpOiBSRkMgNTQ5OCBub24tY29tcGxpYW5jZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92 ZSkNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0 c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9y IHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZv cm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4g ZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lz dGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZs YWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZv bGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3 ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNw aWNpb3VzJTIwRW1haWxzLnBkZj4uDQpJTUhPIFRoZSBwcm9ibGVtIGlzIHRoYXQgUkZDNTQ0NCBz dGlsbCBkb2VzIG5vdCBoYXZlIGEgbXVsdGlwbGV4aW5nIHN0YW5kYXJkIGluIElFVEYuIFRoZSB3 YXkgb2YgbXVsdGlwbGV4aW5nIGlzIHN0aWxsIGp1c3QgaW1wbGVtZW50ZWQgYnkgT0xTUnYyIGV4 cGVydHMgYnV0IEkgZG9udCBmaW5kIGFueSBzdGFuZGFyZCBmb3IgbXVsdGlwbGV4aW5nIHlldC4g VGhlIFJGQzU0OTggaXMgbm90IGZvciBtdWx0aXBleGluZyBhcyBJIHVuZGVyc3RhbmQgaXQuIFdl IGFscmVhZHkgZGlzY3Vzc2VkIG9uY2UgdGhhdCBtdWx0aXBsZXhpbmcgaXMgbm90IHNwZWNpZmll ZCBmb3IgYWxsIFJGQzU0NDQgZm9ybWF0cyBiZWNhdXNlIGl0IGlzIGdlbmVyYWwgZm9ybWF0IGJ1 dCBSRkM1NDk4IGlzIG5vdCBnZW5lcmFsLg0KDQpJZiBJIGFtIHdyb25nIHBsZWFzZSBwb2ludCBt ZSB0byBhbiBSRkMuDQpBQg0KT24gTW9uLCBKdWwgMjEsIDIwMTQgYXQgNTo0MCBBTSwgbWFuZXQg aXNzdWUgdHJhY2tlciA8dHJhYyttYW5ldEB0cmFjLnRvb2xzLmlldGYub3JnPGphdmFzY3JpcHQ6 X2UoJTdCJTdELCdjdm1sJywndHJhYyUyQm1hbmV0QHRyYWMudG9vbHMuaWV0Zi5vcmcnKTs+PiB3 cm90ZToNCiM0NTogUkZDIDU0OTggbm9uLWNvbXBsaWFuY2UgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMg RGVhcmxvdmUpDQoNCiBUaGUgZG9jdW1lbnQgaXMgY29tcGxldGVseSBub25jb21wbGlhbnQgd2l0 aCB0aGUgUkZDIDU0NDQgbXVsdGlwbGV4aW5nDQogbWVjaGFuaXNtLCBtYW5kYXRlZCBieSBSRkMg NTQ5OCAob24gdGhlIG1hbmV0IHBvcnQvcHJvdG9jb2wpLiBJdCBkb2VzDQogbWFueSB0aGluZ3Mg dGhhdCBhcmUgbm90IHdpdGhpbiBpdHMgY29tcGV0ZW5jZS4NCg0KLS0NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYt bWFuZXQtDQogIGNoYXJsaWVwQGNvbXB1dGVyLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3Zt bCcsJ2NoYXJsaWVwQGNvbXB1dGVyLm9yZycpOz4gIHwgIGFvZHZ2MkB0b29scy5pZXRmLm9yZzxq YXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2FvZHZ2MkB0b29scy5pZXRmLm9yZycpOz4NCiAg ICAgVHlwZTogIGRlZmVjdCAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1p bm9yICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBhb2R2djIgICAgICAgfCAgICBW ZXJzaW9uOg0KIFNldmVyaXR5OiAgQWN0aXZlIFdHICAgIHwgICBLZXl3b3JkczogIFJGQyA1NDk4 DQogIERvY3VtZW50ICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tl dCBVUkw6IDxodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL21hbmV0L3RyYWMvdGlja2V0LzQ1Pg0K bWFuZXQgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9tYW5ldC8+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0 QGlldGYub3JnPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbWFuZXRAaWV0Zi5vcmcnKTs+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20g eW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBp dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBp dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF1A6GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBoYXZlIG1hbmFnZWQgdG8gcmVhZCB0 aGUgZXhhY3Qgb3Bwb3NpdGUgb2Ygd2hhdCBJIHdyb3RlLiBJIHN1Z2dlc3QgcmVhZGluZyB0aGUg UkZDcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0b3Bo ZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJh bmNlIEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNp cyBDYXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8 YnI+DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENN MiA4SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6 ICYjNDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPg0KIHwgaHR0cDovL3d3 dy5iYWVzeXN0ZW1zLmNvbTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QkFFIFN5c3Rl bXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBI b3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3Vn aCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX YWxlcyBObzogMTk5NjY4NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KPGI+ U2VudDo8L2I+IDIyIEp1bHkgMjAxNCAxNzo0NTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENo cmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyQHRv b2xzLmlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21h bmV0XSAjNDUgKGFvZHZ2Mik6IFJGQyA1NDk4IG5vbi1jb21wbGlhbmNlIChzdWJtaXR0ZWQgZm9y IENocmlzIERlYXJsb3ZlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNr IDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo aXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMg bWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIg ZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48 L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZs YWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2Vp dmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4N CmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3Vz cGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVz eXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGlu ZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwv c3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz OTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U28gSSB1bmRlcnN0YW5kIGZyb20geW91ciBtZXNzYWdlIHRoYXQgdGhlcmUgaXMg bm8gbWFuZGF0ZSBvZiBtdWx0aXBsZXhpbmcgbWV0aG9kIG9yIHNwZWNpZmljIGZvcm1hdCBtZXRo b2QuIDU0OTggZGVmaW5lcyBwb3J0L3Byb3RvY29sIGZvciBzdWNoIGZvcm1hdC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVzdWFsbHkgbWVzc2Fn ZXMsIGZvcm1hdHMsIHBhY2tldHMsIGFuZCBtdWx0aXBsZXgsJm5ic3A7YXJlIG5vdCBtb3JlIGlt cG9ydGFudCB0aGFuIHRoZSBBT0RWdjImbmJzcDtwcm90b2NvbCBmdW5jdGlvbiwgc28gdXN1YWxs eSB3ZSZuYnNwO3NldCBmdW5jdGlvbiB0aGVuIHRoZSBtZXNzYWdpbmcgYW5kIHRoZW4mbmJzcDtt dWx0aXBsZXhpbmcuIElNSE8gaXQmbmJzcDt3YXMgbm90IHJpZ2h0IHRoYXQgdGhpcyBXRyBzcGVu ZCBsb3Qgb2YgZWZmb3J0IGFuZA0KIHllYXJzJm5ic3A7dG8gZG8gUkZDNTQ0NCBiZWZvcmUgY29t cGxldGluZyBpdHMgdHdvIGJhc2ljIHN0YW5kYXJkcyAocmVhY3RpdmUgYW5kIHByb2FjdGl2ZSks IGJ1dCBpdCBpcyBvayBpZiB3ZSBtYWtlIHByaW9yaXR5IHRvIHRoZSZuYnNwO3N0YW5kYXJkcyZu YnNwO2Z1bmN0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFCPGJyPg0KPGJyPg0KT24gVHVlc2RheSwgSnVseSAyMiwgMjAxNCwg RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJGQzU0NDQgZGVzY3JpYmVzIGEgbXVsdGlwbGV4aW5nIHByb2Nlc3Mu IEl0IGlzIG5vdCByZXF1aXJlZCBwdXJlbHkgaW4gaXRzIG93biB0ZXJtcy4gQnV0IFJGQyA1NDk4 DQogbWFrZSBpdCBtYW5kYXRvcnkgZm9yIGFueSBwcm90b2NvbCB1c2luZyB0aGUgcG9ydC9wcm90 b2NvbCBhbGxvY2F0ZWQgYnkgdGhhdCBSRkMuIEFuZCB0aGUgV0cgaGFzIGFncmVlZCB0aGF0IGFs bCByb3V0aW5nIHByb3RvY29scyBkZXZlbG9wZWQgaGF2ZSB0byBiZSBhYmxlIChhdCBsZWFzdCkg dG8gdXNlIHRoYXQgcG9ydC9wcm90b2NvbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLQ0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBB c3N1cmFuY2UgR3JvdXA8YnI+DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFu YWx5c2lzIENhcGFiaWxpdHk8YnI+DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENl bnRyZTxicj4NCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y ZCwgQ00yIDhITiwgVUs8YnI+DQpUZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7 IEZheDogJiM0Mzs0NCAxMjQ1IDI0MjEyNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnY2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb20nKTsiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3Nw YW4+PC9hPg0KIHwgPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3Rl bXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBI b3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3Vn aCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX YWxlcyBObzogMTk5NjY4Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQNCiBbbWFpbHRvOjxhIGhyZWY9 ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbWFuZXQtYm91bmNlc0BpZXRmLm9yZycpOyIg dGFyZ2V0PSJfYmxhbmsiPm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5BYmR1c3NhbGFtIEJhcnl1bjxicj4NCjxiPlNlbnQ6PC9iPiAyMiBKdWx5IDIwMTQg MTI6MDI8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1s JywnbWFuZXRAaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj4NCm1hbmV0QGlldGYub3JnPC9h Pjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdk cmFmdC1pZXRmLW1hbmV0LWFvZHZ2MkB0b29scy5pZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsi Pg0KZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djJAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbbWFuZXRdICM0NSAoYW9kdnYyKTogUkZDIDU0OTggbm9uLWNvbXBsaWFu Y2UgKHN1Ym1pdHRlZCBmb3IgQ2hyaXMgRGVhcmxvdmUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu ZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkg d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVu dHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRp b24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25n PjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBj YW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8 L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3 MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91 cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdp dGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9j ZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JTUhPIFRoZSBwcm9i bGVtIGlzIHRoYXQgUkZDNTQ0NCBzdGlsbCBkb2VzIG5vdCBoYXZlIGEgbXVsdGlwbGV4aW5nIHN0 YW5kYXJkIGluIElFVEYuIFRoZSB3YXkgb2YgbXVsdGlwbGV4aW5nIGlzIHN0aWxsIGp1c3QgaW1w bGVtZW50ZWQgYnkgT0xTUnYyIGV4cGVydHMgYnV0IEkgZG9udCBmaW5kIGFueSBzdGFuZGFyZA0K IGZvciBtdWx0aXBsZXhpbmcgeWV0LiBUaGUgUkZDNTQ5OCBpcyBub3QgZm9yIG11bHRpcGV4aW5n IGFzIEkgdW5kZXJzdGFuZCBpdC4gV2UgYWxyZWFkeSBkaXNjdXNzZWQgb25jZSB0aGF0IG11bHRp cGxleGluZyBpcyBub3Qgc3BlY2lmaWVkIGZvciBhbGwgUkZDNTQ0NCBmb3JtYXRzIGJlY2F1c2Ug aXQgaXMgZ2VuZXJhbCBmb3JtYXQgYnV0IFJGQzU0OTggaXMgbm90IGdlbmVyYWwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiBJIGFt IHdyb25nIHBsZWFzZSBwb2ludCBtZSB0byBhbiBSRkMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFCPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0IDU6 NDAgQU0sIG1hbmV0IGlzc3VlIHRyYWNrZXIgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdC JTdELCdjdm1sJywndHJhYyUyQm1hbmV0QHRyYWMudG9vbHMuaWV0Zi5vcmcnKTsiIHRhcmdldD0i X2JsYW5rIj50cmFjJiM0MzttYW5ldEB0cmFjLnRvb2xzLmlldGYub3JnPC9hPiZndDsNCiB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+IzQ1OiBSRkMgNTQ5OCBu b24tY29tcGxpYW5jZSAoc3VibWl0dGVkIGZvciBDaHJpcyBEZWFybG92ZSk8YnI+DQo8YnI+DQom bmJzcDtUaGUgZG9jdW1lbnQgaXMgY29tcGxldGVseSBub25jb21wbGlhbnQgd2l0aCB0aGUgUkZD IDU0NDQgbXVsdGlwbGV4aW5nPGJyPg0KJm5ic3A7bWVjaGFuaXNtLCBtYW5kYXRlZCBieSBSRkMg NTQ5OCAob24gdGhlIG1hbmV0IHBvcnQvcHJvdG9jb2wpLiBJdCBkb2VzPGJyPg0KJm5ic3A7bWFu eSB0aGluZ3MgdGhhdCBhcmUgbm90IHdpdGhpbiBpdHMgY29tcGV0ZW5jZS48YnI+DQo8YnI+DQot LTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQombmJzcDtSZXBvcnRlcjogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDtPd25lcjogJm5ic3A7ZHJhZnQtaWV0Zi1tYW5ldC08YnI+DQombmJzcDsgPGEgaHJl Zj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdjaGFybGllcEBjb21wdXRlci5vcmcnKTsi IHRhcmdldD0iX2JsYW5rIj4NCmNoYXJsaWVwQGNvbXB1dGVyLm9yZzwvYT4gJm5ic3A7fCAmbmJz cDs8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2FvZHZ2MkB0b29scy5pZXRm Lm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPmFvZHZ2MkB0b29scy5pZXRmLm9yZzwvYT48YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwO1R5cGU6ICZuYnNwO2RlZmVjdCAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgU3RhdHVzOiAmbmJzcDtuZXc8YnI+DQombmJzcDtQcmlvcml0eTog Jm5ic3A7bWlub3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDtNaWxlc3RvbmU6 PGJyPg0KQ29tcG9uZW50OiAmbmJzcDthb2R2djIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7VmVyc2lvbjo8YnI+DQombmJzcDtTZXZlcml0eTogJm5ic3A7QWN0aXZlIFdHICZu YnNwOyAmbmJzcDt8ICZuYnNwOyBLZXl3b3JkczogJm5ic3A7UkZDIDU0OTg8YnI+DQombmJzcDsg RG9jdW1lbnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHw8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVGlja2V0IFVSTDogJmx0 OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbWFuZXQvdHJhYy90aWNrZXQvNDUi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL3dnL21hbmV0L3RyYWMvdGlj a2V0LzQ1PC9hPiZndDs8YnI+DQptYW5ldCAmbHQ7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL21hbmV0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9tYW5ldC88 L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0iamF2YXNjcmlw dDpfZSglN0IlN0QsJ2N2bWwnLCdtYW5ldEBpZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPm1h bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw PioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxl YXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+ DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRp c2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv bi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF1A6GLKXM0002VGREEN_-- From nobody Tue Jul 22 09:51:52 2014 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 B983C1A0331 for ; Tue, 22 Jul 2014 09:51: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 UjShQkKwr3cQ for ; Tue, 22 Jul 2014 09:51:49 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DF41A0158 for ; Tue, 22 Jul 2014 09:51:41 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so7363604qge.11 for ; Tue, 22 Jul 2014 09:51:40 -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=EsPUymmmTI0VH8hC8RTz+Dz4kfmFMy1Z5fin22NiKBs=; b=nxzQBtYf1aTKqgwabQDcNIhyszZWaDL11lx5OObZq1eNAAwOeaoA0XKjHci+RBO5uK JVSBYZARmpJ+Qn/gid7zy0ms8QLCsLgQ6VeOtE655FBgRXGCIjOSIZzb1qWT1spA9prn /fCXwzpHU/Jyziqh97Za+iMVrLNVr94EEC21ib0hBwcKWYM4UQXtvqK4eN9nnyEGbDrN BGeUrVIKeUzUWvYkYwobTu5oTWoFUI5XAKoD6RYefkDJuYHEp0GdykizTq5H8A9yZZ8a lJgaeUtLDdDa3+0DkGzBoF6WRBHxgWixMVyAXFS01SQuYs34drl+vy3IKFUw0Xa/Wo/m lTnw== X-Received: by 10.140.95.101 with SMTP id h92mr52414847qge.35.1406047900918; Tue, 22 Jul 2014 09:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 09:51:20 -0700 (PDT) In-Reply-To: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> From: Henning Rogge Date: Tue, 22 Jul 2014 18:51:20 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IAhG6ran46-UeGril2-oT-6mKpk Cc: "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 16:51:50 -0000 On Tue, Jul 22, 2014 at 6:39 PM, Dearlove, Christopher (UK) wrote: > I would suggest outlining the basic concept on list. Doesn't need a detailed writeup to start with. In fact doing so might minimise the number of writeups and re-writeups. We might copy the basic security concept of OLSRv2... shared group key should work for AODVv2 too, because its just a replacement for layer-2 security for most MANETs. Henning Rogge From nobody Tue Jul 22 09:56:55 2014 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 447821B29B5 for ; Tue, 22 Jul 2014 09:56:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 EQZGkucqE56P for ; Tue, 22 Jul 2014 09:56:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C171A0300 for ; Tue, 22 Jul 2014 09:56:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47C282408B9; Tue, 22 Jul 2014 09:56:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 20EE8240820; Tue, 22 Jul 2014 09:56:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 12:56:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <79B7A230-0CFE-450B-9122-E34F144218DB@thomasclausen.org> References: <677582AE-0FEA-46BC-A056-2CBD6824347D@thomasclausen.org> To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tIm-bJSWGHBkJ6bKd7Vdjq5WooE Cc: manet Subject: Re: [manet] Question to ADOVv2 applicability statement 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, 22 Jul 2014 16:56:52 -0000 I think that you, actually, are not disagreeing with me here, Chris.=20 I am not sure I understand what AODVv2 offers, either, in the context of "mo= re than one attached network" - but, you do put it more eloquently than I. > On 22 Jul 2014, at 12:48, "Dearlove, Christopher (UK)" wrote: >=20 > I'm going to disagree here to some extent. >=20 > First, if we allow one (and only one) attached network then we can conside= r the MANET as a stub. (Obviously no attached networks is disconnected.) >=20 > So what about more than one attached network? >=20 > Just to get it out of the way, from insider the MANET, there is a definite= issue as to whether those attached networks can be the same, different but o= verlapping, or must be disjoint. But that's not the issue here. >=20 > If we can have two (or more) attached networks, we could make the MANET a t= ransit network. Which is a case some people want. But you could still make i= t behave only as if a stub from multiple places (I'd have to check my termin= ology to check if that's also classified as a stub). >=20 > So I think the two issues (stub only, number of attached networks) are rel= ated (because there's an impossible combination) but stub does not automatic= ally exclude multiple attached networks. >=20 > I'm not sure what AODVv2 is offering here. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen > Sent: 22 July 2014 17:21 > To: manet > Subject: [manet] Question to ADOVv2 applicability statement >=20 > ----------------------! WARNING ! ---------------------- This message orig= inates 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 attachm= ents or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. > -------------------------------------------------------- >=20 > The draft states: >=20 >> The AODVv2 routing protocol is designed for stub (i.e., non-transit) or= disconnected (i.e., >> from the Internet) mobile ad hoc networks (MANETs). >=20 > Does this mean that this protocol does not support "attached network", as a= re known from OLSRv2 (and OLSR, even)?=20 >=20 > If the answer is "yes, it does support attached networks" then the stateme= nt quoted above is incorrect.=20 >=20 > If the answer is "no, it does not support attached network" then the state= ment quoted is correct -- but, it's a limitation of the protocol that I am n= ot enthusiastic about >=20 > Sent from my iPad > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From nobody Tue Jul 22 09:57:28 2014 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 350291B29E9 for ; Tue, 22 Jul 2014 09:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 I1_b73PCN9yG for ; Tue, 22 Jul 2014 09:57:23 -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 6728C1B29EE for ; Tue, 22 Jul 2014 09:57:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208";a="388563495" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2014 17:57:21 +0100 X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208";a="65674928" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 22 Jul 2014 17:57:28 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 17:57:28 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) Thread-Index: AQHPpJYUeiDPaaz1Z0eQvrYiMlVQoZup4hsAgAIoGECAAC8eAIAAEo3Q///0hQCAABEMQA== Date: Tue, 22 Jul 2014 16:57:27 +0000 Message-ID: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UcU0rlG8ZURt5M8LiDL6rQpopOk Cc: "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 16:57:25 -0000 VGhvbWFzIGhhcyBlYXJsaWVyIHBvaW50ZWQgb3V0IGFuIGlzc3VlICh3aGljaCBJIGhhZG4ndCB0 aG91Z2h0IG9mKSB0aGF0IGlmIEFPRFZ2MiByZWFjdHMgdG8gSVAgcGFja2V0cywgd2hhdCBhYm91 dCB0aGVtPyBUaGF0J3MgbmV3IGNvbXBhcmVkIHRvIE9MU1J2MiBhbmQgUkZDcyA3MTgyLzcxODMu DQoNCkJ1dCB5ZXMsIFJGQyA3MTgyIGNhbiBkZWZpbml0ZWx5IGJlIGEgc3RhcnRpbmcgcG9pbnQu IEl0IHdpbGwgd29yayBhcHBsaWVkIHRvIDU0NDQgcGFja2V0cy4gRm9yIGl0IHRvIHdvcmsgYXBw bGllZCB0byBBT0RWdjIgbWVzc2FnZXMgdGhleSBuZWVkIHRvIGJlIGltbXV0YWJsZS4gSSdtIG5v dCBzdXJlIGlmIHRoZXkgY3VycmVudGx5IGFyZSBvciBhcmUgbm90Lg0KDQooV2l0aCBhIHNoYXJl ZCBzZWNyZXQga2V5LCB0aGVyZSdzIGxpdHRsZSBpZiBhbnkgd2luIGluIHByb3RlY3RpbmcgbWVz c2FnZXMgcmF0aGVyIHRoYW4gcGFja2V0cy4gV2l0aCBvdGhlciBhcHByb2FjaGVzLCBzdWNoIGFz IGluIHRoZSBJQlMgZHJhZnQsIHByb3RlY3RpbmcgbWVzc2FnZXMgY2FuIGJlIGEgZGVmaW5pdGUg d2luLikNCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdp bmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29y a3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRl Y2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NMKgfCAgRmF4OiArNDQg MTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIHwgaHR0cDovL3d3dy5i YWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0 ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3Nw YWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwuY29tXSANClNl bnQ6IDIyIEp1bHkgMjAxNCAxNzo1MQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpD YzogQ2hhcmxlcyBFLiBQZXJraW5zOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5l dF0gIzQ3IChhb2R2djIpOiBTZWN1cml0eSBhcHByb2FjaCB1bmFjY2VwdGFibGUgKHN1Ym1pdHRl ZCBmb3IgQ2hyaXMgRGVhcmxvdmUpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcg ISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0 c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9y IGZyb20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9s bG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9y IGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Ck9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDY6MzkgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo VUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gd3JvdGU6DQo+IEkgd291bGQgc3Vn Z2VzdCBvdXRsaW5pbmcgdGhlIGJhc2ljIGNvbmNlcHQgb24gbGlzdC4gRG9lc24ndCBuZWVkIGEg ZGV0YWlsZWQgd3JpdGV1cCB0byBzdGFydCB3aXRoLiBJbiBmYWN0IGRvaW5nIHNvIG1pZ2h0IG1p bmltaXNlIHRoZSBudW1iZXIgb2Ygd3JpdGV1cHMgYW5kIHJlLXdyaXRldXBzLg0KDQpXZSBtaWdo dCBjb3B5IHRoZSBiYXNpYyBzZWN1cml0eSBjb25jZXB0IG9mIE9MU1J2Mi4uLiBzaGFyZWQgZ3Jv dXAga2V5IHNob3VsZCB3b3JrIGZvciBBT0RWdjIgdG9vLCBiZWNhdXNlIGl0cyBqdXN0IGEgcmVw bGFjZW1lbnQgZm9yIGxheWVyLTIgc2VjdXJpdHkgZm9yIG1vc3QgTUFORVRzLg0KDQpIZW5uaW5n IFJvZ2dlDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxl dGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQg bm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlz dHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK From nobody Tue Jul 22 10:00:05 2014 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 D21B21B29E2 for ; Tue, 22 Jul 2014 10:00:02 -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 QdIEWI9VDTHh for ; Tue, 22 Jul 2014 10:00:00 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0881A0161 for ; Tue, 22 Jul 2014 10:00:00 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so15920387vcb.27 for ; Tue, 22 Jul 2014 09:59:59 -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=Crhp7WO7N6AxLv1ZgkEvU0ALCUXxpZgMHP2dPndDnjs=; b=QEICgXlLW33b9jnGQQVwHq5uoVcx9Y9uqbeE5WAAxf36+i/9c8641nxsxpoIFW+jDY YE0ROpmBMmc3KUliOc6ERfJlE+QskWLVukFAVFQJfVjfHb5z2tijbj1IixEAqrR2DVaE 0f0cH9oGrz1MvPOHL0ni9gghxa/+ZTrZk7R9M= 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=Crhp7WO7N6AxLv1ZgkEvU0ALCUXxpZgMHP2dPndDnjs=; b=V4ydZRuuey7DN/CefwIIjUIAKRSIGfm7sT8VWZas0xu+5IPyUqIiaiT6Q3KFwyNTvA PEVEuHpV1ru0NNkyi8xok9yWMviMDwvGgtt+WFEJgHCzKsJkMsNAfD/hM5ZUteJUUHo1 UZJg1RUBlB/t69zFRQpba5HBIOPnEfPGcZh13AcEzAttcqAhwK6l+7sOc/fndOXle9Vl G2bPBLMCgu/3g7PeL2b0XDbAqwKe0HToszL4qxkAErzLBDTD7GP3XtqKJ7qk2mMBAmIb 50HoRt3v0G9YIRKRYD4F/rtjTaiRByUQHFqy0vygaDwTnRGsK7V5Qlrp5eAee03TGp3G AAdg== X-Gm-Message-State: ALoCoQmCNRUDL0QBNkXKvYTSYi8O5Cvt4Iy0oIBYwz+hdxzylOSf6dyWmCkTiBEnZZ0QaaXh1IwS MIME-Version: 1.0 X-Received: by 10.52.37.81 with SMTP id w17mr12531494vdj.95.1406048399518; Tue, 22 Jul 2014 09:59:59 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Tue, 22 Jul 2014 09:59:59 -0700 (PDT) In-Reply-To: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> Date: Tue, 22 Jul 2014 12:59:59 -0400 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lXCJk0LfQJrg8k8eqdc_osNcNi8 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:00:03 -0000 On Tue, Jul 22, 2014 at 12:51 PM, Henning Rogge wrote: > On Tue, Jul 22, 2014 at 6:39 PM, Dearlove, Christopher (UK) > wrote: >> I would suggest outlining the basic concept on list. Doesn't need a detailed writeup to start with. In fact doing so might minimise the number of writeups and re-writeups. > > We might copy the basic security concept of OLSRv2... shared group key > should work for AODVv2 too, because its just a replacement for layer-2 > security for most MANETs. I think it will not be as easy as that (although I am in favor of reusing the security related RFCs we have recently published). In link-state routing protocols, that works pretty well to just stick an ICV to messages flooded through the network. In reactive protocols, paths are established by forwarding RREQs/RREP that change underway (in particular the metrics that change at every hop). So this may be more difficult. There are also the issues mentioned previously in the discussion of how RERRs are triggered and that they may tear down routes. I believe to remember that Charlie mentioned somewhere that his intent is to re-add intermediate RREPs (although I personally don't agree with that if this is really the case). This will make it very difficult, since routers may reply "on behalf" of others. Regards Ulrich From nobody Tue Jul 22 10:01:58 2014 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 6800E1B29BC for ; Tue, 22 Jul 2014 10:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 veYZToBM0IPC for ; Tue, 22 Jul 2014 10:01:52 -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 8A34B1A02D4 for ; Tue, 22 Jul 2014 10:01:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,711,1400022000"; d="scan'208,217";a="459883816" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Jul 2014 18:01:50 +0100 X-IronPort-AV: E=Sophos; i="5.01,711,1400022000"; d="scan'208,217"; a="58660456" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Jul 2014 18:01:57 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.213]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 18:01:57 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: Odds against joining MANET Thread-Index: Ac+lznViER73sMgmSIWgyTnwpn6rFw== Date: Tue, 22 Jul 2014 17:01:56 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF202GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/A3Y6gnfq3atOI9DFIs5OofkGFQ0 Subject: [manet] Odds against joining MANET 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, 22 Jul 2014 17:01:55 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF202GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Not impossible, but as subject line says, odds against joining you electron= ically. Have a good meeting. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF202GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Not impossible, but as subject line says, odds again= st joining you electronically.

 

Have a good meeting.

 

-- <= /p>

Christopher Dearlove

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

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

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

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40CEF202GLKXM0002VGREEN_-- From nobody Tue Jul 22 10:02:18 2014 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 EE26D1B2A3B for ; Tue, 22 Jul 2014 10:02:17 -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 srg3EF69MVdK for ; Tue, 22 Jul 2014 10:02:16 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878DD1A02CF for ; Tue, 22 Jul 2014 10:02:16 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so6859682qaq.15 for ; Tue, 22 Jul 2014 10:02: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=G5ZIwP5AFQLlFA2cbOkAlGzN68faq0o4NHsC2i62GTw=; b=BddojbiSlZ4ljetkJqjDr0aEVZmpfEeegpHTO4p1mgAHFscEOigtqvro5jwHcge14S zUQ0dH7Ymki4DdRp+W6XUUx5eYvX+MVRx+d+tHDOOVg3ufqMkuGkMinlkiExDINyCJyv iCbVewxq7e6fqW2TwVPvmQVmSzGqwOoFRn8bjR+9HAAcMM/tFIVP8gXd+Si6opizlTfN 2yY3rhA69CgvQSAqDTNNijhh8v030hiLK40OkI7u1bU6RpGELbK9Mwu8wBHJgbBmN+JS cM2CaNPKSPHe69sY6IJs1DnIW7y50nJwrC7n57uM76X15d9hCar5bU7AIQfKt/+6t/kM AGKA== X-Received: by 10.140.95.101 with SMTP id h92mr52510115qge.35.1406048535765; Tue, 22 Jul 2014 10:02:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 10:01:55 -0700 (PDT) In-Reply-To: References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> From: Henning Rogge Date: Tue, 22 Jul 2014 19:01:55 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qv3b_NvYMV2q4G_KcS4Aa4ttWD0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:02:18 -0000 On Tue, Jul 22, 2014 at 6:57 PM, Dearlove, Christopher (UK) wrote: > Thomas has earlier pointed out an issue (which I hadn't thought of) that if AODVv2 reacts to IP packets, what about them? That's new compared to OLSRv2 and RFCs 7182/7183. > > But yes, RFC 7182 can definitely be a starting point. It will work applied to 5444 packets. For it to work applied to AODVv2 messages they need to be immutable. I'm not sure if they currently are or are not. Packets are always immutable, because they only exist for a single hop... but you are right, this would be "hop-by-hop" security. But its a starting point. > (With a shared secret key, there's little if any win in protecting messages rather than packets. With other approaches, such as in the IBS draft, protecting messages can be a definite win.) Exactly. On Tue, Jul 22, 2014 at 6:59 PM, Ulrich Herberg wrote: > I think it will not be as easy as that (although I am in favor of > reusing the security related RFCs we have recently published). I was thinking about reusing the concept, not the RFC itself. Use it as a blueprint. > In > link-state routing protocols, that works pretty well to just stick an > ICV to messages flooded through the network. In reactive protocols, > paths are established by forwarding RREQs/RREP that change underway > (in particular the metrics that change at every hop). So this may be > more difficult. There are also the issues mentioned previously in the > discussion of how RERRs are triggered and that they may tear down > routes. > > I believe to remember that Charlie mentioned somewhere that his intent > is to re-add intermediate RREPs (although I personally don't agree > with that if this is really the case). This will make it very > difficult, since routers may reply "on behalf" of others. With a shared group-key every node could impersonate every other node anyways. Henning Rogge From nobody Tue Jul 22 10:10:31 2014 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 36A631B2A7F for ; Tue, 22 Jul 2014 10:10:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KI9eaA7H_Kjv for ; Tue, 22 Jul 2014 10:10:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42BC1B2A81 for ; Tue, 22 Jul 2014 10:10:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B5954240961; Tue, 22 Jul 2014 10:10:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8EB852407D0; Tue, 22 Jul 2014 10:10:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 13:10:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <804AEECE-421E-4D1B-BBEB-DA084D4833E5@thomasclausen.org> References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> To: Ulrich Herberg Archived-At: http://mailarchive.ietf.org/arch/msg/manet/I8qNFK1KI4SmDXyBH-ofi5T1n1M Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:10:30 -0000 > On 22 Jul 2014, at 12:59, Ulrich Herberg wrote: >=20 >> On Tue, Jul 22, 2014 at 12:51 PM, Henning Rogge wrote:= >> On Tue, Jul 22, 2014 at 6:39 PM, Dearlove, Christopher (UK) >> wrote: >>> I would suggest outlining the basic concept on list. Doesn't need a deta= iled writeup to start with. In fact doing so might minimise the number of wr= iteups and re-writeups. >>=20 >> We might copy the basic security concept of OLSRv2... shared group key >> should work for AODVv2 too, because its just a replacement for layer-2 >> security for most MANETs. >=20 > I think it will not be as easy as that (although I am in favor of > reusing the security related RFCs we have recently published). In > link-state routing protocols, that works pretty well to just stick an > ICV to messages flooded through the network. In reactive protocols, > paths are established by forwarding RREQs/RREP that change underway > (in particular the metrics that change at every hop). So this may be > more difficult. There are also the issues mentioned previously in the > discussion of how RERRs are triggered and that they may tear down > routes. > I believe to remember that Charlie mentioned somewhere that his intent > is to re-add intermediate RREPs (although I personally don't agree > with that if this is really the case). This will make it very > difficult, since routers may reply "on behalf" of others. >=20 I seem to recall back in the days when I looked at this, that when academic w= ork was published on securing reactive protocols, the first step was systema= tically "disable intermediate / gratuitous RREPs". Thomas > Regards > Ulrich >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 10:14:13 2014 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 EFC681B2A7F for ; Tue, 22 Jul 2014 10:14:10 -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 Jbw6Om6VOC3i for ; Tue, 22 Jul 2014 10:14:09 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398CB1B2AA3 for ; Tue, 22 Jul 2014 10:14:06 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so9418752wes.35 for ; Tue, 22 Jul 2014 10:14:02 -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=PDlxU7XVtOwB/4qCl5bgqxZumG1XMTxW866Sm/CUoUs=; b=0koyh7qzvQW9uMbIJPuYbdkSDUnI99e7593k5kf3wT2oXCI1rl2XEWzaKmCJ3IoxqB vWmI59ueaBx1vb+fkHFviWDRY/qE9cXliZZsxgArqjkTxnthiMySel5OhORL9ZvSas2l JE08bDQ2YO/+RbL4KO4yyrFWGm6OXFmu5wf4bnU/X1e5aJUnhHwTNl+SfQmm/X/PYLS4 PThQDaMgcq9c7FCOsJmndXsDLacfdH+wHSaV8BiYaWe/bHiSFfGFWMseq9NfSG9lM1On XkVmLpLfx0jNPKgaIDd3NRtSvthgAao8Ld5bRA5gh3Qxuzz/hs8V5UF+ikwwMdHRtWcw tJLg== X-Received: by 10.194.122.73 with SMTP id lq9mr26142749wjb.133.1406049242582; Tue, 22 Jul 2014 10:14:02 -0700 (PDT) Received: from [10.5.25.254] (dab-crx1-h-2-10.dab.02.net. [82.132.227.167]) by mx.google.com with ESMTPSA id ey16sm55863464wid.14.2014.07.22.10.14.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 10:14:00 -0700 (PDT) References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Christopher Dearlove Date: Tue, 22 Jul 2014 18:13:54 +0100 To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8dkPNHafRr6YSuG1wP09kvZ9IRg Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:14:11 -0000 Why reinvent the wheel again? If the RFC 7182 concept works, let's use RFC 7= 182. If not, let's understand why not. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 22 Jul 2014, at 18:01, Henning Rogge wrote: >=20 > On Tue, Jul 22, 2014 at 6:57 PM, Dearlove, Christopher (UK) > wrote: >> Thomas has earlier pointed out an issue (which I hadn't thought of) that i= f AODVv2 reacts to IP packets, what about them? That's new compared to OLSRv= 2 and RFCs 7182/7183. >>=20 >> But yes, RFC 7182 can definitely be a starting point. It will work applie= d to 5444 packets. For it to work applied to AODVv2 messages they need to be= immutable. I'm not sure if they currently are or are not. >=20 > Packets are always immutable, because they only exist for a single > hop... but you are right, this would be "hop-by-hop" security. But its > a starting point. >=20 >> (With a shared secret key, there's little if any win in protecting messag= es rather than packets. With other approaches, such as in the IBS draft, pro= tecting messages can be a definite win.) >=20 > Exactly. >=20 >> On Tue, Jul 22, 2014 at 6:59 PM, Ulrich Herberg wro= te: >> I think it will not be as easy as that (although I am in favor of >> reusing the security related RFCs we have recently published). >=20 > I was thinking about reusing the concept, not the RFC itself. Use it > as a blueprint. >=20 >> In >> link-state routing protocols, that works pretty well to just stick an >> ICV to messages flooded through the network. In reactive protocols, >> paths are established by forwarding RREQs/RREP that change underway >> (in particular the metrics that change at every hop). So this may be >> more difficult. There are also the issues mentioned previously in the >> discussion of how RERRs are triggered and that they may tear down >> routes. >>=20 >> I believe to remember that Charlie mentioned somewhere that his intent >> is to re-add intermediate RREPs (although I personally don't agree >> with that if this is really the case). This will make it very >> difficult, since routers may reply "on behalf" of others. >=20 > With a shared group-key every node could impersonate every other node anyw= ays. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jul 22 10:19:08 2014 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 ACDD31B2AC1 for ; Tue, 22 Jul 2014 10:19:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 CZc9t0BzpxNK for ; Tue, 22 Jul 2014 10:18:58 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE52F1B2AA6 for ; Tue, 22 Jul 2014 10:18:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BF057247326; Tue, 22 Jul 2014 10:18:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 97BB124099D; Tue, 22 Jul 2014 10:18:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 13:18:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <20078252-BB73-4012-A5A1-FE926610ACF1@thomasclausen.org> References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YMTERBv80rgmMq0fLG3d8Io80Zw Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:19:00 -0000 > On 22 Jul 2014, at 13:01, Henning Rogge wrote: >=20 > On Tue, Jul 22, 2014 at 6:57 PM, Dearlove, Christopher (UK) > wrote: >> Thomas has earlier pointed out an issue (which I hadn't thought of) that i= f AODVv2 reacts to IP packets, what about them? That's new compared to OLSRv= 2 and RFCs 7182/7183. >>=20 >> But yes, RFC 7182 can definitely be a starting point. It will work applie= d to 5444 packets. For it to work applied to AODVv2 messages they need to be= immutable. I'm not sure if they currently are or are not. >=20 > Packets are always immutable, because they only exist for a single > hop... but you are right, this would be "hop-by-hop" security. But its > a starting point. >=20 >> (With a shared secret key, there's little if any win in protecting messag= es rather than packets. With other approaches, such as in the IBS draft, pro= tecting messages can be a definite win.) >=20 > Exactly. >=20 >> On Tue, Jul 22, 2014 at 6:59 PM, Ulrich Herberg wro= te: >> I think it will not be as easy as that (although I am in favor of >> reusing the security related RFCs we have recently published). >=20 > I was thinking about reusing the concept, not the RFC itself. Use it > as a blueprint. >=20 Well, RFC7182 just defines ICV and TIMESTAMP TLVs for inclusion in RFC5444 m= essages, packets, and does IANA allocations for code-points, etc. That, cert= ainly, should be reusable and be reused. RFC7183 may, or may not, be applicable as a blueprint. Although, I reiterate= , that it does not protect against the various attacks possible in a reactiv= e protocol by way of an attacker generating data traffic (i.e., "non control= packets"). >> In >> link-state routing protocols, that works pretty well to just stick an >> ICV to messages flooded through the network. In reactive protocols, >> paths are established by forwarding RREQs/RREP that change underway >> (in particular the metrics that change at every hop). So this may be >> more difficult. There are also the issues mentioned previously in the >> discussion of how RERRs are triggered and that they may tear down >> routes. >>=20 >> I believe to remember that Charlie mentioned somewhere that his intent >> is to re-add intermediate RREPs (although I personally don't agree >> with that if this is really the case). This will make it very >> difficult, since routers may reply "on behalf" of others. >=20 > With a shared group-key every node could impersonate every other node anyw= ays. >=20 Doesn't all this, then, become a matter of "secure only when running over a s= ecured L2"?=20 It might be acceptable in some contexts, but I am not sure that I would sugg= est this as the solution this WG (or, the IETF) should push. I'm not sure th= at it will actually pass muster in the various later-stage reviews of the SE= C-DIR And IESG. Thomas ps: I know that you're not suggesting that this is good security, Henning.= From nobody Tue Jul 22 10:19:18 2014 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 C3B161B2AC5 for ; Tue, 22 Jul 2014 10:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 vikEuCzmEgqt for ; Tue, 22 Jul 2014 10:19:08 -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 B7C2C1B2AA6 for ; Tue, 22 Jul 2014 10:19:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Grxr0TLwR2yfB/pP/0L7uA4X58DJszbO3NWmjdLIAN5JL1ObULYFOXqwg5idQ64X; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.162.90] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X9diK-00065b-SP; Tue, 22 Jul 2014 13:18:56 -0400 Message-ID: <53CE9CFF.2060103@earthlink.net> Date: Tue, 22 Jul 2014 10:18:55 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE8C9C.8090303@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7adb32667332713ad00152d73ebeccc65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.162.90 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-ILIeBS7mNGBE2AFK-ezwLxFHcE Cc: manet@ietf.org, manet-ads Subject: Re: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 17:19:11 -0000 Hello Chris, On 7/22/2014 9:27 AM, Dearlove, Christopher (UK) wrote: > > It has been agreed by the WG, and defined in Proposed Standards, that > - MANET WG routing protocols shall be able to use the manet port/protocol. > - RFC 5498 mandates that anything using that port/protocol shall use not just RFC 5444, but the RFC 5444 multiplexer. As I have agreed many times, you have correctly characterized the world in which [manet] participants find themselves. > > On that last point, given that RFC 5498 was (inexplicably to me) accepted before RFC 5444, the IESG insisted that RFC 5444 contain a specification of the multiplexing mechanism that RFC 5498 had imposed on it. And RFC 5498 was authored by your then DYMO co-author. He obviously didn't feel it couldn't cope with reactive protocols. Well, his RFC 5444 co-existence design was quite thoroughly disparaged by RFC 5444 proponents. It seems that he didn't really understood all the implications of his participation in that. > > As for there being too many issues with AODVv2, yes, there are too many issues with AODVv2. That's the problem. The solution is not to ignore them, but to fix them (the WG having taken the decision not to restart from a document with fewer issues). This is twisting my words. I have a lot of issues to address. You may say that even one single issue is "too many". You certainly should not make any implication that I have been ignoring them. > > As for the only two addresses, you're imposing a restriction on any future extension that might want to report an address for another reason. I don't think that is a good idea. Hmm... well let me see. We need the IP address of a router *wanting* a route to a destination, and we need the IP address of that destination. That's what is needed for route discovery. Do you see the need for more addresses here? As a contrasting example, RERR can have many IP addresses, and they are to some degree interchangeable. The RFC 5444 model is suitable for that. > This is a WG document, not just your private document, Chris: this is not constructive, and in no way do I consider this document as my private document. Regards, Charlie P. From nobody Tue Jul 22 10:22:22 2014 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 4449E1B2A07 for ; Tue, 22 Jul 2014 10:22:21 -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 6QOtDokGbTYE for ; Tue, 22 Jul 2014 10:22:20 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066101A0180 for ; Tue, 22 Jul 2014 10:22:19 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so7290967qgd.23 for ; Tue, 22 Jul 2014 10:22: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:from:date:message-id:subject:to :cc:content-type; bh=YQDBISQk5futHVb6H8ST5iAzr8H8kXVv/9IO3SmWeqk=; b=YzLhLAmzu/crsfqH4kKu8Z9XRi3UVwPqaMX+3R7JBBb9AsGq0lpKbqO4G1DgsTUNVK wxiQw+cX77/rwtfGCGJgKWwWNKmpKan9/cVu4pdvBIveL9ecu3x4iT0SQPDmetZ6PLBm 5T8qAGM5Q/VWUSn6HgU2bnPv8Bd5thAZggPNCkc+UyO3vKAt1I6zxQSdT63r6UZJhGOh n56hmrhtKlY318N8F8snUtpTrDFIFLXOhLRHasJ3aDQIEeJRgamLUa9HpxlVCciyrfL9 w7d9udEvJkQy0lG1/Y4v5+Yy8SOTh+EuDPYqUxv9vw/7kSZmEG6VzE3S5ueneEASKuT6 3jhg== X-Received: by 10.140.88.243 with SMTP id t106mr50623863qgd.12.1406049739086; Tue, 22 Jul 2014 10:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Tue, 22 Jul 2014 10:21:59 -0700 (PDT) In-Reply-To: <20078252-BB73-4012-A5A1-FE926610ACF1@thomasclausen.org> References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> <20078252-BB73-4012-A5A1-FE926610ACF1@thomasclausen.org> From: Henning Rogge Date: Tue, 22 Jul 2014 19:21:59 +0200 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/znIZ9oVUuMJr21kJgme02TarO6E Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:22:21 -0000 On Tue, Jul 22, 2014 at 7:18 PM, Thomas Clausen wrote: > Well, RFC7182 just defines ICV and TIMESTAMP TLVs for inclusion in RFC5444 messages, packets, and does IANA allocations for code-points, etc. That, certainly, should be reusable and be reused. > > RFC7183 may, or may not, be applicable as a blueprint. Although, I reiterate, that it does not protect against the various attacks possible in a reactive protocol by way of an attacker generating data traffic (i.e., "non control packets"). Spoofed ICMP messages to make a router drop a route? > Doesn't all this, then, become a matter of "secure only when running over a secured L2"? If you have a secure L2, you just need an ACL and you have similar security than a HMAC based on a shared key... Henning Rogge From nobody Tue Jul 22 10:26:57 2014 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 008FC1B2A70 for ; Tue, 22 Jul 2014 10:26:55 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Eij-2t8YTJgw for ; Tue, 22 Jul 2014 10:26:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AE21A02B9 for ; Tue, 22 Jul 2014 10:26:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1B333240C8C; Tue, 22 Jul 2014 10:26:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.237] (dhcp-b6ed.meeting.ietf.org [31.133.182.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D3465240952; Tue, 22 Jul 2014 10:26:27 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-FD80D50A-5825-498D-9DC6-1402C86C8FEA Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Tue, 22 Jul 2014 13:26:25 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2DF0740C-52D9-4D22-A819-0B8EF734E798@thomasclausen.org> References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> <53CC99F2.5050103@computer.org> <53CE909A.3050206@computer.org> <20078252-BB73-4012-A5A1-FE926610ACF1@thomasclausen.org> To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CTgszwFhfcsYQ4oGReDql4T0hvM Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) 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, 22 Jul 2014 17:26:55 -0000 --Apple-Mail-FD80D50A-5825-498D-9DC6-1402C86C8FEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 22 Jul 2014, at 13:21, Henning Rogge wrote: >=20 > On Tue, Jul 22, 2014 at 7:18 PM, Thomas Clausen > wrote: >> Well, RFC7182 just defines ICV and TIMESTAMP TLVs for inclusion in RFC544= 4 messages, packets, and does IANA allocations for code-points, etc. That, c= ertainly, should be reusable and be reused. >>=20 >> RFC7183 may, or may not, be applicable as a blueprint. Although, I reiter= ate, that it does not protect against the various attacks possible in a reac= tive protocol by way of an attacker generating data traffic (i.e., "non cont= rol packets"). >=20 > Spoofed ICMP messages to make a router drop a route? >=20 That, or various approaches of (for example)=20 "Send data packets to (non-existing) destinations within the networ= k to=20 a router, watch it exhaust itself (and, create contention in the c= hannel around it) by sending RERRs." >> Doesn't all this, then, become a matter of "secure only when running over= a secured L2"? >=20 > If you have a secure L2, you just need an ACL and you have similar > security than a HMAC based on a shared key... >=20 Yes. If that's the security model for this protocol, then that probably should be= documented, and it should be stated in the applicability statement to not a= ttempts its use elsewhere? Thomas > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-FD80D50A-5825-498D-9DC6-1402C86C8FEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 22 Jul 2014, at 13:2= 1, Henning Rogge <hrogge@gmail.com> wrote:

On Tue, Jul 2= 2, 2014 at 7:18 PM, Thomas Clausen
<thomas@thomasclausen.org> wrote:
Well, RFC7182 just defines ICV and TIMESTAMP TL= Vs for inclusion in RFC5444 messages, packets, and does IANA allocations for= code-points, etc. That, certainly, should be reusable and be reused.=

RFC7183 may, or may not, be applicable as a blu= eprint. Although, I reiterate, that it does not protect against the various a= ttacks possible in a reactive protocol by way of an attacker generating data= traffic (i.e., "non control packets").
=
Spoofed ICMP messages to make a router drop a route?


That, or various approa= ches of (for example) 

"Send data packets to (non-e= xisting) destinations within the network to 
  = a router, watch it exhaust itself (and, create contention in the channel aro= und it)
  by sending RERRs."

Doesn't all this, then, b= ecome a matter of "secure only when running over a secured L2"?

If you have a secure L2, you just need an A= CL and you have similar
security than a HMAC based on a shar= ed key...


Yes.<= /div>

If that's the security model for this protocol, the= n that probably should be documented, and it should be stated in the applica= bility statement to not attempts its use elsewhere?

Thomas

Henning Rogge

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-FD80D50A-5825-498D-9DC6-1402C86C8FEA-- From nobody Tue Jul 22 10:36:58 2014 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 A05DC1B2B2C for ; Tue, 22 Jul 2014 10:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 CFVw2-JToGyY for ; Tue, 22 Jul 2014 10:36:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 5E1D71B2B0F for ; Tue, 22 Jul 2014 10:36:23 -0700 (PDT) Received: from localhost ([::1]:49682 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9dzC-0003vv-KC; Tue, 22 Jul 2014 10:36:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 17:36:22 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/21#comment:1 Message-ID: <076.10b38fb02dec737a0215a65f4dce10b2@trac.tools.ietf.org> References: <061.815c8cc5567c8816898ef0373d66e50b@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <061.815c8cc5567c8816898ef0373d66e50b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GnCGklM7XxeBPvILpjkQuLvKG7I Cc: manet@ietf.org Subject: Re: [manet] #21 (aodvv2): Document hard to read X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:36:52 -0000 #21: Document hard to read Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 10:37:26 2014 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 EEE1A1A02F0 for ; Tue, 22 Jul 2014 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 m3oeSGEJw3lG for ; Tue, 22 Jul 2014 10:37:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 60FCC1B2B03 for ; Tue, 22 Jul 2014 10:37:00 -0700 (PDT) Received: from localhost ([::1]:49711 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9dzo-00042I-8n; Tue, 22 Jul 2014 10:37:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 17:37:00 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/24#comment:1 Message-ID: <076.ec2f0de65af428ae89e7297ef7817f90@trac.tools.ietf.org> References: <061.0f44444abc85a02d639ffe2f7780652e@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <061.0f44444abc85a02d639ffe2f7780652e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CaMfU4nw94aVDWwbUT3zDrsKlW8 Cc: manet@ietf.org Subject: Re: [manet] #24 (aodvv2): Ordering of processing instructions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:37:25 -0000 #24: Ordering of processing instructions Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 10:38:27 2014 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 0FC921B2AFC for ; Tue, 22 Jul 2014 10:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 F0W68FtO9RAy for ; Tue, 22 Jul 2014 10:38:20 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6B71A005F for ; Tue, 22 Jul 2014 10:38:12 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so873253wiv.9 for ; Tue, 22 Jul 2014 10:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=ITPQpjQbIunTgFVAjXJS9uIAdcgoKt540W+NY+jx4mU=; b=wCKL8OZQDbQFxiLqnUjUGnxzEn7en6lq7VFa661yx4wzLA9PpPe62XcK0LMEfAtH1f tuOnHLQEo0pZQsgcDlWs+KMVD6k6bcHzYw28D5GpHNT8tE+Um8yALHJ/IlthSUx/0XuF J5dx+xLAax0DMOxqdEPxlN8qzn7LeY1X3iosNqN033HNILm6qJEuXcrAmzAspVSxRP2V lkH/laIvmPVcPlzoLldnRPZCmf4qrkt8NksWLskt6uxdaZtSydrkMKX3ihnfKnr7rYwl bMF3XZX9cmqiYNGfrfPvq06JJPnrKbS5GvkGCUQS0VDMGX0PCU1K6IAGguuXttODwphJ BOtw== MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr17056369wib.32.1406050691062; Tue, 22 Jul 2014 10:38:11 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Tue, 22 Jul 2014 10:38:11 -0700 (PDT) In-Reply-To: <20140722173202.11282.8433.idtracker@ietfa.amsl.com> References: <20140722173202.11282.8433.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 19:38:11 +0200 X-Google-Sender-Auth: sQFhJiVXMZ8DnhZQMXgiwQV0ZO0 Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=001a11c37e56fa241b04fecbaf21 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kh8HzLXREvVM2WYHmOOuQW36MJ8 Subject: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-01.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: Tue, 22 Jul 2014 17:38:22 -0000 --001a11c37e56fa241b04fecbaf21 Content-Type: text/plain; charset=UTF-8 Hi, We just submitted a new revision of the olsrv2-multipath. The major modification is a new subsection, stating the motivation of being experimental, and the experiments to be conducted. regards Jiazi Yi ---------- Forwarded message ---------- From: Date: Tue, Jul 22, 2014 at 7:32 PM Subject: New Version Notification for draft-yi-manet-olsrv2-multipath-01.txt To: Jiazi Yi , Benoit Parrein < benoit.parrein@polytech.univ-nantes.fr>, Benoit Parrein < Benoit.Parrein@polytech.univ-nantes.fr> A new version of I-D, draft-yi-manet-olsrv2-multipath-01.txt has been successfully submitted by Jiazi Yi and posted to the IETF repository. Name: draft-yi-manet-olsrv2-multipath Revision: 01 Title: Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Document date: 2014-07-22 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-01.txt Status: https://datatracker.ietf.org/doc/draft-yi-manet-olsrv2-multipath/ Htmlized: http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-yi-manet-olsrv2-multipath-01 Abstract: This document specifies a multi-path extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11c37e56fa241b04fecbaf21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We just submitted a new revis= ion of the olsrv2-multipath.=C2=A0
The major modification is a ne= w subsection, stating the motivation of being experimental, and the experim= ents to be conducted.=C2=A0

regards

Jiazi Yi

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Jul 22, 2014 at 7:32 PM
Subject: New Version Notification for= draft-yi-manet-olsrv2-multipath-01.txt
To: Jiazi Yi <jiazi@jiaziyi.com>, Benoit Parrein <benoit.parrein@polytech.= univ-nantes.fr>, Benoit Parrein <Benoit.Parrein@polytech.univ-nantes.fr>


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

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-yi-manet-olsrv2-multipath Revision: =C2=A0 =C2=A0 =C2=A0 01
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Multi-path Extension for the Optim= ized Link State Routing Protocol version 2 (OLSRv2)
Document date: =C2=A02014-07-22
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-01.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracke= r.ietf.org/doc/draft-yi-manet-olsrv2-multipath/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/= draft-yi-manet-olsrv2-multipath-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-yi-manet-olsrv2-multipath-01

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




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

The IETF Secretariat


--001a11c37e56fa241b04fecbaf21-- From nobody Tue Jul 22 10:59:12 2014 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 6BF171A0143 for ; Tue, 22 Jul 2014 10:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 EuIzYGDT5AbU for ; Tue, 22 Jul 2014 10:59:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 422681A0063 for ; Tue, 22 Jul 2014 10:59:09 -0700 (PDT) Received: from localhost ([::1]:50745 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eLE-0000MI-QI; Tue, 22 Jul 2014 10:59:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 17:59:08 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/25#comment:1 Message-ID: <076.7f09352462a6e3001459e56588a960dc@trac.tools.ietf.org> References: <061.79acdb18cee1af055ed1783b3a78c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <061.79acdb18cee1af055ed1783b3a78c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vzuEnpFdEY61aktJsgcz9BWxWbA Cc: manet@ietf.org Subject: Re: [manet] #25 (aodvv2): Meaning of "suppose" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:59:10 -0000 #25: Meaning of "suppose" Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 10:59:46 2014 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 798D21B2814 for ; Tue, 22 Jul 2014 10:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 n6EvLKg4W2d0 for ; Tue, 22 Jul 2014 10:59:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 70B631B2806 for ; Tue, 22 Jul 2014 10:59:42 -0700 (PDT) Received: from localhost ([::1]:50775 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eLm-0000Q9-B8; Tue, 22 Jul 2014 10:59:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 17:59:42 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/26#comment:1 Message-ID: <076.a1ad7dde9361ebc0c0ccb63bb6ce4be1@trac.tools.ietf.org> References: <061.60ec2a0a082d0fa7c5e51c3b223be012@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <061.60ec2a0a082d0fa7c5e51c3b223be012@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uLMfOpDAzTvBHDbNcrN0Y7y4nEQ Cc: manet@ietf.org Subject: Re: [manet] #26 (aodvv2): Specification of optional features X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:59:43 -0000 #26: Specification of optional features Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:00:16 2014 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 D54991B2963 for ; Tue, 22 Jul 2014 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6TH3qdcYoOhg for ; Tue, 22 Jul 2014 11:00:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 97AC51B2804 for ; Tue, 22 Jul 2014 11:00:13 -0700 (PDT) Received: from localhost ([::1]:50808 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eMH-0000bm-Gd; Tue, 22 Jul 2014 11:00:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:00:13 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/27#comment:1 Message-ID: <076.983a28f290849c25f18e1f87c69d6de3@trac.tools.ietf.org> References: <061.cc69d0d59c5db291a9ef255a1650fad8@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <061.cc69d0d59c5db291a9ef255a1650fad8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nVtgn965yQ08vuJOWZcS2fKbdos Cc: manet@ietf.org Subject: Re: [manet] #27 (aodvv2): Processing AckReq X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:00:15 -0000 #27: Processing AckReq Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:00:40 2014 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 DFF581B2963 for ; Tue, 22 Jul 2014 11:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 zfhIkylt9Iuf for ; Tue, 22 Jul 2014 11:00:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 CF1E11A000B for ; Tue, 22 Jul 2014 11:00:37 -0700 (PDT) Received: from localhost ([::1]:50838 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eMf-0000lE-Mc; Tue, 22 Jul 2014 11:00:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:00:37 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/28#comment:1 Message-ID: <076.1c23293a5258e7424225b60fc09a8b22@trac.tools.ietf.org> References: <061.41eddfaea8f2746f1b4be31a039eeeae@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <061.41eddfaea8f2746f1b4be31a039eeeae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/iyD14Yde7RuODAYE5I-Lzf9na3U Cc: manet@ietf.org Subject: Re: [manet] #28 (aodvv2): Routers with multiple interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:00:39 -0000 #28: Routers with multiple interfaces Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:01:45 2014 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 EA7071B2963 for ; Tue, 22 Jul 2014 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Kaszzm1poGhz for ; Tue, 22 Jul 2014 11:01:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 0503D1A01DD for ; Tue, 22 Jul 2014 11:01:43 -0700 (PDT) Received: from localhost ([::1]:50878 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eNi-0000tx-TX; Tue, 22 Jul 2014 11:01:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:01:42 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/31#comment:1 Message-ID: <076.b0350046909fc942fee3a2bd62dfba6f@trac.tools.ietf.org> References: <061.449749bb6c383a0185489dc3ab916269@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <061.449749bb6c383a0185489dc3ab916269@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Y_oRZr4RLso097ICAsvdRqth2VU Cc: manet@ietf.org Subject: Re: [manet] #31 (aodvv2): Suitability for implementation on commodity OS X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:01:44 -0000 #31: Suitability for implementation on commodity OS Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:02:09 2014 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 883CC1A033D for ; Tue, 22 Jul 2014 11:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 69j7lXuv9G44 for ; Tue, 22 Jul 2014 11:02:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 937581A0320 for ; Tue, 22 Jul 2014 11:02:07 -0700 (PDT) Received: from localhost ([::1]:50898 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eO7-000126-G3; Tue, 22 Jul 2014 11:02:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:02:07 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/33#comment:1 Message-ID: <076.094bad2dbdb71826bb9af95150d07684@trac.tools.ietf.org> References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RqLWJuhMGe4ZOyFOwHGDxiYegk4 Cc: manet@ietf.org Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:02:08 -0000 #33: RFC 5444 processing constraint Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:02:46 2014 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 BA4B31B2AA2 for ; Tue, 22 Jul 2014 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 dIOZRiTNSb6z for ; Tue, 22 Jul 2014 11:02:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B89BF1B2963 for ; Tue, 22 Jul 2014 11:02:43 -0700 (PDT) Received: from localhost ([::1]:50932 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eOh-0001GF-LB; Tue, 22 Jul 2014 11:02:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:02:43 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/34#comment:1 Message-ID: <076.1a312ed9e4d293c5bdf9930aff6cd396@trac.tools.ietf.org> References: <061.1b44a2845a63141c8adc66505db6419a@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <061.1b44a2845a63141c8adc66505db6419a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uj4quuvFOzLlMh2JPQXU2n7E2ok Cc: manet@ietf.org Subject: Re: [manet] #34 (aodvv2): Section 13 must be removed X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:02:44 -0000 #34: Section 13 must be removed Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:03:14 2014 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 E00971B2AB1 for ; Tue, 22 Jul 2014 11:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 gmC_0JbViZn6 for ; Tue, 22 Jul 2014 11:03:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 E72911B2A7C for ; Tue, 22 Jul 2014 11:03:11 -0700 (PDT) Received: from localhost ([::1]:50955 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eP9-0001Ka-Re; Tue, 22 Jul 2014 11:03:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:03:11 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/36#comment:1 Message-ID: <076.6268fa294503aa2da76bc02326a31105@trac.tools.ietf.org> References: <061.6da7af79180921ae87942b999eedff0a@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <061.6da7af79180921ae87942b999eedff0a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7SvTrePuvyxyo3RgeiFy9rPAaxI Cc: manet@ietf.org Subject: Re: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:03:13 -0000 #36: Security Considerations: Reactive protocol concept Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:03:36 2014 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 08B221B2AC6 for ; Tue, 22 Jul 2014 11:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6kvdFqkK6299 for ; Tue, 22 Jul 2014 11:03:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 0EAF51B2AC2 for ; Tue, 22 Jul 2014 11:03:35 -0700 (PDT) Received: from localhost ([::1]:50976 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9ePW-0001N5-V5; Tue, 22 Jul 2014 11:03:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:03:34 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/37#comment:1 Message-ID: <076.e3cf8069e6b150b1ecb233bf4d8cc6d4@trac.tools.ietf.org> References: <061.64b65c7cac3396e106617a28e3dcf1ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <061.64b65c7cac3396e106617a28e3dcf1ac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yG88Gvj_sqnDBTJi_JyCKv6FMoE Cc: manet@ietf.org Subject: Re: [manet] #37 (aodvv2): Security Considerations: what needs to be implemented? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:03:36 -0000 #37: Security Considerations: what needs to be implemented? Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:04:03 2014 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 F16D41B2A7C for ; Tue, 22 Jul 2014 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 hhyksM7iF8q2 for ; Tue, 22 Jul 2014 11:03:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B55051B2B1A for ; Tue, 22 Jul 2014 11:03:59 -0700 (PDT) Received: from localhost ([::1]:50998 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9ePv-0001Rz-L4; Tue, 22 Jul 2014 11:03:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:03:59 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/38#comment:1 Message-ID: <076.81e1dccd2660263c98b5e8ad28654744@trac.tools.ietf.org> References: <061.950aa9ed68fd9d1761939b51501ac508@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <061.950aa9ed68fd9d1761939b51501ac508@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qh3HUHSipkaraShRzCc6GbzJsB4 Cc: manet@ietf.org Subject: Re: [manet] #38 (aodvv2): difficulty to do security, in case messages are mutable X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:04:01 -0000 #38: difficulty to do security, in case messages are mutable Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:04:40 2014 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 73B601B2B0E for ; Tue, 22 Jul 2014 11:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 P2jDaVDcek8v for ; Tue, 22 Jul 2014 11:04:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 68ABE1B2AC6 for ; Tue, 22 Jul 2014 11:04:37 -0700 (PDT) Received: from localhost ([::1]:51018 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eQX-0001VK-3E; Tue, 22 Jul 2014 11:04:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:04:37 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/47#comment:1 Message-ID: <076.b0fedb50382c7d9c301366900ebd88e5@trac.tools.ietf.org> References: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <061.869e900273dc713c1c1a5e63fb4e138c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/okn4HPALS4obAhn4O0B20PEsbY4 Cc: manet@ietf.org Subject: Re: [manet] #47 (aodvv2): Security approach unacceptable (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:04:38 -0000 #47: Security approach unacceptable (submitted for Chris Dearlove) Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: security | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:05:21 2014 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 4C91B1B2AC6 for ; Tue, 22 Jul 2014 11:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 uXdjPBmTQI5z for ; Tue, 22 Jul 2014 11:05:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C35411B2B24 for ; Tue, 22 Jul 2014 11:05:18 -0700 (PDT) Received: from localhost ([::1]:51060 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eRC-0001kc-Ms; Tue, 22 Jul 2014 11:05:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:05:18 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/22#comment:1 Message-ID: <076.94bd6f20c1494d377dfcca4e77b6d4e4@trac.tools.ietf.org> References: <061.04d6856ca1d9c40a9ad288f003eeb91f@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <061.04d6856ca1d9c40a9ad288f003eeb91f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/f3XHDkZrfacRpLB5yuFu5Z8Hsbw Cc: manet@ietf.org Subject: Re: [manet] #22 (aodvv2): Multiple terms for same concept X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:05:20 -0000 #22: Multiple terms for same concept Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:05:56 2014 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 AEDFD1B2B33 for ; Tue, 22 Jul 2014 11:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 1q9E-eydRhRb for ; Tue, 22 Jul 2014 11:05:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B5CBA1B2B3E for ; Tue, 22 Jul 2014 11:05:41 -0700 (PDT) Received: from localhost ([::1]:51087 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eRZ-0001rj-L7; Tue, 22 Jul 2014 11:05:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:05:41 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/23#comment:1 Message-ID: <076.b95d0c247912d40b82caafc7a4de7069@trac.tools.ietf.org> References: <061.e1f82be4db481380244914bbd13719fc@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.e1f82be4db481380244914bbd13719fc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/n3JIrVwUBcXGML3muicboZLf5Hw Cc: manet@ietf.org Subject: Re: [manet] #23 (aodvv2): Format of processing algorithms X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:05:51 -0000 #23: Format of processing algorithms Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:06:04 2014 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 0540A1B2B3B for ; Tue, 22 Jul 2014 11:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 0BHUCJdvLzHR for ; Tue, 22 Jul 2014 11:06:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 5A6151B2B35 for ; Tue, 22 Jul 2014 11:06:01 -0700 (PDT) Received: from localhost ([::1]:51107 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eRt-0001tz-8y; Tue, 22 Jul 2014 11:06:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:06:01 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/29#comment:1 Message-ID: <076.7dd70d138c5eb41ca90e2fde946bf77e@trac.tools.ietf.org> References: <061.235f8637e3c7cb9456d361d8404ef4c1@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <061.235f8637e3c7cb9456d361d8404ef4c1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/r_tnZ2KPLgJNhsTmnDhtfQRelXU Cc: manet@ietf.org Subject: Re: [manet] #29 (aodvv2): Choice of IP address X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:06:03 -0000 #29: Choice of IP address Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:06:28 2014 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 1C6981B2B40 for ; Tue, 22 Jul 2014 11:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 7lSJAlMdGH20 for ; Tue, 22 Jul 2014 11:06:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 D27C71B2B3F for ; Tue, 22 Jul 2014 11:06:21 -0700 (PDT) Received: from localhost ([::1]:51120 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eSD-0001ve-Ou; Tue, 22 Jul 2014 11:06:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:06:21 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/30#comment:1 Message-ID: <076.4d6376d79d8ce2a1716e6ac8a65725fb@trac.tools.ietf.org> References: <061.9544556e01d71f4a3bc37047a820e1cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <061.9544556e01d71f4a3bc37047a820e1cd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/d6vhSdrj65oswB6CNDr8xO55cOA Cc: manet@ietf.org Subject: Re: [manet] #30 (aodvv2): Use of word "node" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:06:26 -0000 #30: Use of word "node" Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:06:49 2014 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 28E621B2B38 for ; Tue, 22 Jul 2014 11:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 h_lKTWZeIK-Z for ; Tue, 22 Jul 2014 11:06:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 0D8E31A0193 for ; Tue, 22 Jul 2014 11:06:47 -0700 (PDT) Received: from localhost ([::1]:51136 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eSc-0002D5-VE; Tue, 22 Jul 2014 11:06:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:06:46 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/32#comment:1 Message-ID: <076.35440c159efe155761c47ba961ef790a@trac.tools.ietf.org> References: <061.6938ca142d915a879b2e5bc46f790232@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <061.6938ca142d915a879b2e5bc46f790232@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/viUhosE5aSOOmF2LNATYtGkKgQk Cc: manet@ietf.org Subject: Re: [manet] #32 (aodvv2): Multicast transmission X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:06:48 -0000 #32: Multicast transmission Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:07:41 2014 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 4B87E1B2B41 for ; Tue, 22 Jul 2014 11:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 S6HWG5A8muJF for ; Tue, 22 Jul 2014 11:07:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 28B401B2B26 for ; Tue, 22 Jul 2014 11:07:38 -0700 (PDT) Received: from localhost ([::1]:51179 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eTS-0002Lz-2C; Tue, 22 Jul 2014 11:07:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:07:38 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/35#comment:1 Message-ID: <076.ffef4e38dd486431f4930db2280456e8@trac.tools.ietf.org> References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CUv2k8zJweeTyTvlG97i3QUQpH4 Cc: manet@ietf.org Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:07:39 -0000 #35: A constant is constant Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:07:58 2014 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 739A21A0061 for ; Tue, 22 Jul 2014 11:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 OYB5PGtmIjiC for ; Tue, 22 Jul 2014 11:07:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 8B5521B2B42 for ; Tue, 22 Jul 2014 11:07:56 -0700 (PDT) Received: from localhost ([::1]:51199 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eTk-0002dL-Dh; Tue, 22 Jul 2014 11:07:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:07:56 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/39#comment:1 Message-ID: <084.0fb2badb05085046b27767ffb25dfa0c@trac.tools.ietf.org> References: <069.68e0b0b941aac1c81466bb9638f9ccca@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <069.68e0b0b941aac1c81466bb9638f9ccca@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QWdFnKE-bAsO8ermaTrfjJeng-U Cc: manet@ietf.org Subject: Re: [manet] #39 (aodvv2): Route.Broken flag redundant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:07:57 -0000 #39: Route.Broken flag redundant Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -------------------------------------------+------------------------------- Reporter: lotte.steenbrink@fu-berlin.de | Owner: Type: defect | charliep@computer.org Priority: minor | Status: new Component: aodvv2 | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------------+------------------------------- Ticket URL: manet From nobody Tue Jul 22 11:08:49 2014 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 064BC1B2B42 for ; Tue, 22 Jul 2014 11:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 hj0FDdrJy-s1 for ; Tue, 22 Jul 2014 11:08:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B9F701B2B26 for ; Tue, 22 Jul 2014 11:08:45 -0700 (PDT) Received: from localhost ([::1]:51262 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eUX-0005aD-Jg; Tue, 22 Jul 2014 11:08:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:08:45 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/40#comment:1 Message-ID: <084.130e2b13e44c7fad6e808caa81533967@trac.tools.ietf.org> References: <069.95a79708777877153a07b9961d7e9c16@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <069.95a79708777877153a07b9961d7e9c16@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6P_RGoljChj1wGXoKzxaZe19c9g Cc: manet@ietf.org Subject: Re: [manet] #40 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:08:47 -0000 #40: AckReq vs RREP_ACK Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -------------------------------------------+------------------------------- Reporter: lotte.steenbrink@fu-berlin.de | Owner: Type: defect | charliep@computer.org Priority: minor | Status: new Component: aodvv2 | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------------+------------------------------- Ticket URL: manet From nobody Tue Jul 22 11:09:12 2014 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 DDC9B1B2B4F for ; Tue, 22 Jul 2014 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 hPOOumXGKQvv for ; Tue, 22 Jul 2014 11:09:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 DD1E91B2B4E for ; Tue, 22 Jul 2014 11:09:08 -0700 (PDT) Received: from localhost ([::1]:51301 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eUu-0007T3-NZ; Tue, 22 Jul 2014 11:09:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:09:08 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/41#comment:1 Message-ID: <084.e9aad4238cda48dda648ecac818e7cd7@trac.tools.ietf.org> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3NCheo-mP_btmVqreZzBQuYXILQ Cc: manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:09:10 -0000 #41: AckReq vs RREP_ACK Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -------------------------------------------+------------------------------- Reporter: lotte.steenbrink@fu-berlin.de | Owner: Type: defect | charliep@computer.org Priority: minor | Status: new Component: aodvv2 | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------------+------------------------------- Ticket URL: manet From nobody Tue Jul 22 11:09:41 2014 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 EA1351B2B55 for ; Tue, 22 Jul 2014 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Nvg69DQP1zeo for ; Tue, 22 Jul 2014 11:09:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 43B1B1B2B42 for ; Tue, 22 Jul 2014 11:09:34 -0700 (PDT) Received: from localhost ([::1]:51333 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eVJ-0003kV-Nv; Tue, 22 Jul 2014 11:09:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:09:33 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/42#comment:1 Message-ID: <084.49bdc439a30c90125cfcd8eea9a7f1f7@trac.tools.ietf.org> References: <069.dc1798c89def0b64c3317643b3bd6ef2@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <069.dc1798c89def0b64c3317643b3bd6ef2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UBzGAxJ592NUW6OMKtZeJeUepcs Cc: manet@ietf.org Subject: Re: [manet] #42 (aodvv2): What happens if Active routes exceed RERR packet size? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:09:37 -0000 #42: What happens if Active routes exceed RERR packet size? Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -------------------------------------------+------------------------------- Reporter: lotte.steenbrink@fu-berlin.de | Owner: Type: defect | charliep@computer.org Priority: minor | Status: new Component: aodvv2 | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------------+------------------------------- Ticket URL: manet From nobody Tue Jul 22 11:10:01 2014 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 575131B2B55 for ; Tue, 22 Jul 2014 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 2Z3EQRIfYYcq for ; Tue, 22 Jul 2014 11:09:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 5DC891B2B54 for ; Tue, 22 Jul 2014 11:09:58 -0700 (PDT) Received: from localhost ([::1]:51359 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eVi-00048u-8W; Tue, 22 Jul 2014 11:09:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:09:58 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/45#comment:1 Message-ID: <076.259329eee39c9d33b2a8cccd58f5d317@trac.tools.ietf.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1rbWP3wvcFWkQA8MJZ76NywD5oQ Cc: manet@ietf.org Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:09:59 -0000 #45: RFC 5498 non-compliance (submitted for Chris Dearlove) Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: RFC 5498 | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:10:27 2014 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 7EEEB1B2B61 for ; Tue, 22 Jul 2014 11:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 OKXc3W7T8ID6 for ; Tue, 22 Jul 2014 11:10:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 BD5621B2B63 for ; Tue, 22 Jul 2014 11:10:19 -0700 (PDT) Received: from localhost ([::1]:51398 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9eW3-0004OH-Ln; Tue, 22 Jul 2014 11:10:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 22 Jul 2014 18:10:19 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/46#comment:1 Message-ID: <076.25d9097ea645d89bab28516ad275e48e@trac.tools.ietf.org> References: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zr9eg_D7OWWkDgffJz7IK76AaQk Cc: manet@ietf.org Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:10:25 -0000 #46: What is needed from IP and ICMP (submitted for Chris Dearlove) Changes (by charliep@computer.org): * owner: draft-ietf-manet-aodvv2@tools.ietf.org => charliep@computer.org -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: IP/ICMP interaction | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Jul 22 11:16:31 2014 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 CB1431B2B74 for ; Tue, 22 Jul 2014 11:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 JqrMEeFVPyzF for ; Tue, 22 Jul 2014 11:16:24 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 640771B2B85 for ; Tue, 22 Jul 2014 11:16:23 -0700 (PDT) Received: from [31.133.162.90] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1X9ebu-00069H-Vz for manet@ietf.org; Tue, 22 Jul 2014 14:16:23 -0400 Message-ID: <53CEAA72.1030404@computer.org> Date: Tue, 22 Jul 2014 11:16:18 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7fdb066a442ede5a20d6e5d5f14ff9cdc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.162.90 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Kl2oZx-VilF_Ascr15LEy4hrKqw Subject: [manet] Please excuse the barrage of messages from the manet issue tracker 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, 22 Jul 2014 18:16:25 -0000 Hello folks, I reassigned the issues that had been assigned to draft-ietf-manet-aodvv2@tools.ietf.org to be assigned to myself (charliep@computer.org). I think this only has to be done once, and for future issues this reassignment can be avoided. Next, I will be evaluating the current status of the issues, and updating the issue tracker with relevant discussion from the mailing list. This is likely to take a long time, unfortunately, but I think it is the best way forward in order to avoid going around in circles. If someone knows how to do these operations without sending out so many messages to the mailing list please let me know. -- Regards, Charlie P. From nobody Tue Jul 22 11:43:33 2014 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 765861B2AC9 for ; Tue, 22 Jul 2014 11:43:32 -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 lRjJ_Q2gjWOv for ; Tue, 22 Jul 2014 11:43:31 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238901B2B0C for ; Tue, 22 Jul 2014 11:43:30 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id u10so51188lbd.21 for ; Tue, 22 Jul 2014 11:43:29 -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=e4O0H3nasKUEy5utesKr+A57YgWjED6wqXY/AAc/Yzg=; b=MSS1y0jmu0ThJGdX79lrq/C84OG1T3LEAu9Z0wh1xPrJdawkdfbLMnzpooO8fefUpn 8MjqdmyvgQ6woAjUoA5xV8Funnm6ccxcfXYLzSALjj77enI2TIBVzTbGPEzOx5MVUv35 F0Glkbcz1QYISM856o6cvw0B1sGAePHqqAl2SR1VTPX5pb8wBcmXoh5ls1aGzKAg8Ion GghV/aqFppPOxvfCEtBJoBM+I+yCsc7FDkskcYeM98fUytGKeKH91uH6Uq2k4vAiD0kx Ow6Oxz96V3Jle9qHwMbC0njMTvFJ6w6ZM+gaFRIYI4ZeereoWgagmw65fKDLftqMDH4Q RpRQ== MIME-Version: 1.0 X-Received: by 10.112.24.167 with SMTP id v7mr35335669lbf.19.1406054609504; Tue, 22 Jul 2014 11:43:29 -0700 (PDT) Received: by 10.152.104.236 with HTTP; Tue, 22 Jul 2014 11:43:29 -0700 (PDT) Date: Tue, 22 Jul 2014 14:43:29 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" , Ulrich Herberg Content-Type: multipart/alternative; boundary=001a1134997a88d03b04fecc9974 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bTkba0RC2jFMyvaiPk8QPhC80Ak Subject: [manet] OLSRv2-Routed MANET Management 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, 22 Jul 2014 18:43:32 -0000 --001a1134997a88d03b04fecc9974 Content-Type: text/plain; charset=UTF-8 While only C is required to be the same and many settings can change autonomously without breaking the protocol that isn't the same thing as the protocol working well in those scenarios. The key thing is that management doesn't need to happen across ALL routers at the same time which makes management quite a bit easier. Is the v4 and v6 thing true? Henning mentioned that his implementation uses both v4 and v6 in the same packet but with different messages. To say that OLSRv2 can't do this without running multiple instances isn't 100% true. --001a1134997a88d03b04fecc9974 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While only C is required to be the same and many sett= ings can change autonomously without breaking the protocol that isn't t= he same thing as the protocol working well in those=C2=A0
scenari= os. The key thing is that management doesn't need to happen across ALL = routers at the same time which makes management quite a bit easier.

Is the v4 and v6 thing true? =C2=A0Henning mentioned th= at his implementation uses both v4 and=C2=A0
v6 in the same packe= t but with different messages. =C2=A0To say that OLSRv2 can't do this= =C2=A0
without running multiple instances isn't 100% true.
--001a1134997a88d03b04fecc9974-- From nobody Tue Jul 22 11:53:10 2014 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 200351A033A for ; Tue, 22 Jul 2014 11:53:08 -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 xa-uVgpSNO2C for ; Tue, 22 Jul 2014 11:53:07 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A552A1A02F5 for ; Tue, 22 Jul 2014 11:53:06 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so72255wes.21 for ; Tue, 22 Jul 2014 11:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ftuIPzXCOyZh8gL2FL3miuBmY/W3iwcM/wNVsKpQlz4=; b=UeFzn7FdIIVzzWKLk5vnGZJ7Fm6Pgkgd4FyosdojpZ/OvITuP0ZvJEF4f41ywwSIdC uVKLgJwB6xT5OBbmxpZ0VcsEQdRiQEcbipyjcGlvv3shtLI9TLf6xGnL/TF8eYL1kGDh Kv6Yuq9lv756EW4XEQW4ZbBb+3OK77ibBXBN7YmFYAEHbKocf/2di3iKukKmDFXytGSG NmXLyJ2Zze4A7X4NSWzXYDEBrK3fHnXpXw+Stb0xDjd/Ls564TnSKybyo9cLtnSjSVgA wT4HSXynqrpOzHO1rBsfuPhzNt9Awh7faR2M9gkUaw2dFvEMGC5TgvzzF/W4FcFPwbSI 0wLQ== X-Received: by 10.180.10.138 with SMTP id i10mr17136367wib.81.1406055185176; Tue, 22 Jul 2014 11:53:05 -0700 (PDT) Received: from [192.168.254.4] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id hc4sm2926733wjc.9.2014.07.22.11.53.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 11:53:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: <53CE9CFF.2060103@earthlink.net> Date: Tue, 22 Jul 2014 19:52:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44ACCF12-CD9E-44EA-926D-112CED42C44D@gmail.com> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE8C9C.8090303@earthlink.net> <53CE9CFF.2060103@earthlink.net> To: Charlie Perkins X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W0owHP4fw2XplOh4lnL-kn42IYw Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, manet-ads Subject: Re: [manet] Please, no more RFC 5444 mandates right now... 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, 22 Jul 2014 18:53:08 -0000 On 22 Jul 2014, at 18:18, Charlie Perkins wrote: > Hello Chris, >=20 > On 7/22/2014 9:27 AM, Dearlove, Christopher (UK) wrote: >>=20 >> It has been agreed by the WG, and defined in Proposed Standards, that >> - MANET WG routing protocols shall be able to use the manet = port/protocol. >> - RFC 5498 mandates that anything using that port/protocol shall use = not just RFC 5444, but the RFC 5444 multiplexer. >=20 > As I have agreed many times, you have correctly characterized the = world > in which [manet] participants find themselves. Chose to be in, not "find themselves". And which AODVv2 does not match. >> On that last point, given that RFC 5498 was (inexplicably to me) = accepted before RFC 5444, the IESG insisted that RFC 5444 contain a = specification of the multiplexing mechanism that RFC 5498 had imposed on = it. And RFC 5498 was authored by your then DYMO co-author. He obviously = didn't feel it couldn't cope with reactive protocols. >=20 > Well, his RFC 5444 co-existence design was quite thoroughly > disparaged by RFC 5444 proponents. It seems that he didn't > really understood all the implications of his participation in that. I don't recall things the way you do. >> As for there being too many issues with AODVv2, yes, there are too = many issues with AODVv2. That's the problem. The solution is not to = ignore them, but to fix them (the WG having taken the decision not to = restart from a document with fewer issues). >=20 > This is twisting my words. I have a lot of issues to address. You = may > say that even one single issue is "too many". You certainly should = not > make any implication that I have been ignoring them. See the subject line of this email. >> As for the only two addresses, you're imposing a restriction on any = future extension that might want to report an address for another = reason. I don't think that is a good idea. >=20 > Hmm... well let me see. We need the IP address of a router *wanting* = a route > to a destination, and we need the IP address of that destination. = That's what is > needed for route discovery. Do you see the need for more addresses = here? Planning any intermediate replies? Completely ruled out any route = accumulation? No possibiity of including blacklisting information? = Thought of every possibility someone else might? > As a contrasting example, RERR can have many IP addresses, and they = are > to some degree interchangeable. The RFC 5444 model is suitable for = that. >=20 >> This is a WG document, not just your private document, >=20 > Chris: this is not constructive, and in no way do I consider this > document as my private document. I'd like too see more from your co-authors, it is appearing as a one = person process. From nobody Tue Jul 22 13:35:25 2014 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 77A0F1A03F8 for ; Tue, 22 Jul 2014 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 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, SUBJ_AS_SEEN=1.461] 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 AGUn0Qf66fGO for ; Tue, 22 Jul 2014 13:35:23 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326FF1A03F4 for ; Tue, 22 Jul 2014 13:35:20 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id z11so165102lbi.31 for ; Tue, 22 Jul 2014 13:35:18 -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=DBSeFZJVZowaNEb8CKAn6iCjk70O1i7eDqet+tj+W2w=; b=viKr95EqBec/+5n/tfYoqBkvOrtZ1Jypfj1mECuQ7Tv34fz77lYX6Z2AOlLt7ir1nI EhSaNmFd89FhPdYJwkjseTIc+J9DN4AVYgtokKqsLW8U2skzetUztKPAcdJzpl19YKoX nvn1X493fLJAtPoPDB5PkQ2JZTAgjguYTnXONMu32NGFoiFXEr4eHvCI2hMUFYh637EH EQAMVdQ06u2QgqDmXDjC3qdpprZIVEhpfqGZQvkB3L+hEwBgw3m12e+9onmANDqYxTWX x1CmXTVMsB2YPqCtt9FB+738wBjef0f6fsqABjMysd5iJTHp02l89DhWnv9o08dgxc/R RtgQ== MIME-Version: 1.0 X-Received: by 10.112.198.34 with SMTP id iz2mr14102402lbc.96.1406061318544; Tue, 22 Jul 2014 13:35:18 -0700 (PDT) Received: by 10.152.104.236 with HTTP; Tue, 22 Jul 2014 13:35:18 -0700 (PDT) Date: Tue, 22 Jul 2014 16:35:18 -0400 Message-ID: From: Justin Dean To: Ulrich Herberg , Joseph Macker , Joe P Macker , "Stan Ratliff (sratliff)" , "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a11c33d706ca48404fece2990 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QVpitC2rkLDYEQog0155dG5ofa8 Subject: [manet] MANET action items (as seen by Justin Dean) 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, 22 Jul 2014 20:35:24 -0000 --001a11c33d706ca48404fece2990 Content-Type: text/plain; charset=UTF-8 Notes on action items coming out of the MANET working group meeting. (this list is not exhaustive of the topics covered in the meeting) 1) A suggestion was made to ask Stan if dlep editing help would be helpful. If yes who should that person(s) be? 2) What to do with the report MIB; Kill, finish, revise? 3) Request for WG adoption of SMF sec threat document was made. No one in the room had read the draft, but there was positive room reaction to adopting a document with this subject and no negative reaction as measured by hum. Please read the draft and comment. 4) Request for WG adoption of OLSRv2 sec threat document was made. No one in the room had read the draft, but there was positive room reaction to adopting a document with this subject and no negative reaction as measured by hum. Please read the draft and comment. 5) Ulrich volunteered to shepherd multi-topology draft. 6) Request for WG adoption of OLSRv2 multi-path for experimental status was made. No one in the room had read the draft, there was mixed but positive reaction as measured by hum. Please read the draft and comment. 7) Request for WG adoption of ODMRP was made. Discussion within the room touched upon the charter and was generally positive to multicast work but again charter. No hum was held. Justin Dean --001a11c33d706ca48404fece2990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Notes on action items coming out of the MANET working grou= p meeting. (this list is not exhaustive of the topics covered in the meetin= g)

1) A suggestion was made to ask Stan if dlep editing help wo= uld be helpful. If yes who should that person(s) be?

2) What to do with the report MIB; Kill, finish, revise?

3) Requ= est for WG adoption of SMF sec threat document was made. =C2=A0No one in th= e room had read the draft, but there was positive room reaction to adopting= a document with this subject and no negative reaction as measured by hum. = =C2=A0Please read the draft and comment.

4) Request for WG adoption of OLSRv2 sec threat document was made. =C2= =A0No one in the room had read the draft, but there was positive room react= ion to adopting a document with this subject and no negative reaction as me= asured by hum. Please read the draft and comment.

5) Ulrich volunteered to shepherd multi-topology draft.

6) Reque= st for WG adoption of OLSRv2 multi-path for experimental status was made. = =C2=A0No one in the room had read the draft, there was mixed but positive r= eaction as measured by hum. =C2=A0Please read the draft and comment.

7) Request for WG adoption of ODMRP was made. =C2=A0Discussion within t= he room touched upon the charter and was generally positive to multicast wo= rk but again charter. No hum was held.

Justin Dean
--001a11c33d706ca48404fece2990-- From nobody Tue Jul 22 16:35:16 2014 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 F05501A02FC for ; Tue, 22 Jul 2014 16:35:14 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 HKySZBgs7RaV for ; Tue, 22 Jul 2014 16:35:13 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2413A1A02A3 for ; Tue, 22 Jul 2014 16:35:13 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos; i="5.01,713,1400040000"; d="scan'208,217"; a="11311903" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 22 Jul 2014 19:35:02 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Tue, 22 Jul 2014 19:35:02 -0400 From: "Snyder, Brian" To: "manet@ietf.org" Thread-Topic: BFD Proxy Idea Thread-Index: Ac+mBFQ9JJUS9xvFSKGU/LtcZEhAWA== Date: Tue, 22 Jul 2014 23:35:01 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> 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_84585478AABBBF4B9DF597FC0F84AF7343042853VAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Lfp1xeC1p9PIwt0Q3PTJ4MCRQTg Subject: [manet] BFD Proxy Idea 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, 22 Jul 2014 23:35:15 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF7343042853VAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Everyone, As I presented , I think the main problems I had in adopting DLEP were: * Multicast support * VLAN support * Scalability >From a radio point of view, I would like to get these issues addressed (or = at least discussed) so they can work their way into the DLEP definition. Ideally, I could use DLEP, as it does have some advantages over BFD, to sol= ve the problem I described. Further, I think it would be interesting if we considered defining an abili= ty to use BFD to connect to a DLEP instance in order to manage the link up/= down setting. This could be useful if one was using DLEP over virtual inte= rfaces. Finally, as I didn't quite get to finish my presentation due to time const= raints, I also wanted to mention that I would be here all week and would be= happy to have further conversation on my presentation if anyone was intere= sted. Please feel free to email me and we can pick a coffee spot to contin= ue talking. Thanks, Brian --_000_84585478AABBBF4B9DF597FC0F84AF7343042853VAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Everyone,

 

As I presented , I think the main probl= ems I had in adopting DLEP were:

·        Multicast support

·        VLAN support<= /p>

·        Scalability

 

From a radio point of view, I would lik= e to get these issues addressed (or at least discussed) so they can work th= eir way into the DLEP definition. 

 

Ideally, I could use DLEP, as it does h= ave some advantages over BFD, to solve the problem I described.<= /span>

 

Further, I think it would be interestin= g if we considered defining an ability to use BFD to connect to a DLEP inst= ance in order to manage the link up/down setting.  This could be useful if one was using DLEP over virtual interfaces.<= /span>

 

Finally, as I didn’t  quite = get to finish my presentation due to time constraints, I also wanted to men= tion that I would be here all week and would be happy to have further conversation on my presentation if anyone was interested.  Please fee= l free to email me and we can pick a coffee spot to continue talking.<= /o:p>

 

Thanks,

Brian

--_000_84585478AABBBF4B9DF597FC0F84AF7343042853VAUSMBX03idirec_-- From nobody Tue Jul 22 16:43:09 2014 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 C3C5C1A0A8E for ; Tue, 22 Jul 2014 16:43:07 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 e97LbUscGCAo for ; Tue, 22 Jul 2014 16:43:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4932F1A0A8D for ; Tue, 22 Jul 2014 16:43:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2766D2408B9; Tue, 22 Jul 2014 16:43:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A3F3E240223; Tue, 22 Jul 2014 16:43:05 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B2E92CC8-2514-4D58-90CC-9DF0A3486E9E Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> Date: Tue, 22 Jul 2014 19:43:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> To: "Snyder, Brian" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/stFe_WK4OlZtIYeq1kHJeqpdzhM Cc: "manet@ietf.org" Subject: Re: [manet] BFD Proxy Idea 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, 22 Jul 2014 23:43:07 -0000 --Apple-Mail-B2E92CC8-2514-4D58-90CC-9DF0A3486E9E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Brian, > On 22 Jul 2014, at 19:35, "Snyder, Brian" wrote: >=20 > Everyone, > =20 > As I presented , I think the main problems I had in adopting DLEP were: > =C2=B7 Multicast support > =C2=B7 VLAN support > =C2=B7 Scalability > =20 > =46rom a radio point of view, I would like to get these issues addressed (= or at least discussed) so they can work their way into the DLEP definition.=20= > =20 > Ideally, I could use DLEP, as it does have some advantages over BFD, to so= lve the problem I described. > =20 I think that it would be a significant help if you could point out "how" -- f= or dummies like me, who do not understand satcom very well ;) > Further, I think it would be interesting if we considered defining an abil= ity to use BFD to connect to a DLEP instance in order to manage the link up/= down setting. This could be useful if one was using DLEP over virtual inter= faces. OK, this makes sense to me. =20 > Finally, as I didn=E2=80=99t quite get to finish my presentation due to t= ime constraints, I also wanted to mention that I would be here all week and w= ould be happy to have further conversation on my presentation if anyone was i= nterested. Please feel free to email me and we can pick a coffee spot to co= ntinue talking. To mix up (at least, two) metaphors, I have no dogs in this race -- but I th= roughly enjoyed both your presentation and reading your I-D, which was parti= cularly well written and easy to digest. Cheers, Thomas > =20 > Thanks, > Brian > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-B2E92CC8-2514-4D58-90CC-9DF0A3486E9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Brian,

On 22 Ju= l 2014, at 19:35, "Snyder, Brian" <bsnyder@idirect.net> wrote:

<= div> =

Everyone,

 

As I presented , I think the main problem= s I had in adopting DLEP were:

=C2=B7        Multicast support<= /span>

=C2=B7        VLAN support

=C2=B7        Scalability=

 

=46rom a radio point of view, I would lik= e to get these issues addressed (or at least discussed) so they can work the= ir way into the DLEP definition. 

 

Ideally, I could use DLEP, as it does hav= e some advantages over BFD, to solve the problem I described.

 

<= /div>

I think that it would be a significan= t help if you could point out "how" -- for dummies like me, who do not under= stand satcom very well ;)

=

Further, I think it would be interesting i= f we considered defining an ability to use BFD to connect to a DLEP instance= in order to manage the link up/down setting.  This could be useful if one was using DLEP over virtual interfaces.


OK, this makes sense to me.
 

Finally, as I didn=E2=80=99t  quite g= et to finish my presentation due to time constraints, I also wanted to menti= on that I would be here all week and would be happy to have further conversation on my presentation if anyone was interested.  Please feel= free to email me and we can pick a coffee spot to continue talking.


To mix up (at least, two) metaphors, I have no dogs in t= his race -- but I throughly enjoyed both your presentation and reading your I= -D, which was particularly well written and easy to digest.

Cheers,

Thomas

 

Thanks,

Brian

__________________________= _____________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/li= stinfo/manet
= --Apple-Mail-B2E92CC8-2514-4D58-90CC-9DF0A3486E9E-- From nobody Tue Jul 22 16:54:21 2014 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 A27F91A0A98 for ; Tue, 22 Jul 2014 16:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 JyBqJkB41sgU for ; Tue, 22 Jul 2014 16:54:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33C61A0944 for ; Tue, 22 Jul 2014 16:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13121; q=dns/txt; s=iport; t=1406073258; x=1407282858; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LylJDN8bjY+HNS2lYGzDi7MVw0t69pJPBtNTQlK6EG4=; b=N8KbUWn75NncCOO5/SHa67LXRoBgTS7yPPKuvN5gukAM//y9dZ58CqIa lsWnC97VinkkQYBTDpoEkyuII1jlVQeLK8YloST3Gn0NrsNyThJTbmPBF wgkQzwqap6gGfau21Aee4NUfNvgI8TDKcZOxjNvkkhfoKIDzkWOvHnh/j s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FAGT5zlOtJA2J/2dsb2JhbABZgkdHUlcExyIBCYdFAYELFnaEBAEBBAEBAWsLEAIBCD8HJwsUEQEBBA4FiEINwCMTBI5pEQFMBAeDLoEYBZcJhB6UM4NGbIEMOQ X-IronPort-AV: E=Sophos; i="5.01,713,1400025600"; d="scan'208,217"; a="63167170" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2014 23:54:10 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6MNsA2A015120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 23:54:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 18:54:09 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] BFD Proxy Idea Thread-Index: Ac+mBFQ9JJUS9xvFSKGU/LtcZEhAWAALc6YA Date: Tue, 22 Jul 2014 23:54:09 +0000 Message-ID: References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.219] Content-Type: multipart/alternative; boundary="_000_C7ADCA323D8D471C9E0B76F524AD0EECciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ob_PyUWrARLdumyVCxKf5oyhnhA Cc: "manet@ietf.org" Subject: Re: [manet] BFD Proxy Idea 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, 22 Jul 2014 23:54:19 -0000 --_000_C7ADCA323D8D471C9E0B76F524AD0EECciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian, On Jul 22, 2014, at 7:35 PM, "Snyder, Brian" > wrote: Everyone, As I presented , I think the main problems I had in adopting DLEP were: =95 Multicast support =95 VLAN support =95 Scalability I wasn't able to remotely attend today's meeting. For that, my apologies. I= 'll take a look at your slides, and let's communicate as to what your adopt= ion issues are. >From a radio point of view, I would like to get these issues addressed (or = at least discussed) so they can work their way into the DLEP definition. I'd be happy to discuss DLEP issues. That's one of the things this forum is= for=85 ;-) Ideally, I could use DLEP, as it does have some advantages over BFD, to sol= ve the problem I described. Further, I think it would be interesting if we considered defining an abili= ty to use BFD to connect to a DLEP instance in order to manage the link up/= down setting. This could be useful if one was using DLEP over virtual inte= rfaces. Not sure I understand what you mean here. BFD and DLEP both manage the link= up/down setting, but do so via different approaches. BFD relies on continu= ously sending packets over the link; DLEP relies on "smart modems" to tell = the router about link status. How do you envision connecting the two? Finally, as I didn=92t quite get to finish my presentation due to time con= straints, I also wanted to mention that I would be here all week and would = be happy to have further conversation on my presentation if anyone was inte= rested. Please feel free to email me and we can pick a coffee spot to cont= inue talking. I'm not in Toronto, and therefore can't pick a coffee spot, but as I said, = I'm interested in talking about DLEP. Regards, Stan Thanks, Brian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_C7ADCA323D8D471C9E0B76F524AD0EECciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Brian, 

On Jul 22, 2014, at 7:35 PM, "Snyder, Brian" <bsnyder@idirect.net>
 wrote:

Everyone,
 <= /span>
As I pr= esented , I think the main problems I had in adopting DLEP were:=
=B7  =       <= /span>Multicast support
=B7  =       <= /span>VLAN support
=B7  =       <= /span>Scalability

I wasn't able to remotely attend today's meeting. For that, my apologi= es. I'll take a look at your slides, and let's communicate as to what your = adoption issues are. 

 <= /span>
From a = radio point of view, I would like to get these issues addressed (or at leas= t discussed) so they can work their way into the DLEP definition. 

I'd be happy to discuss DLEP issues. That's one of the things this for= um is for=85 ;-)

 <= /span>
Ideally= , I could use DLEP, as it does have some advantages over BFD, to solve the = problem I described.
 <= /span>
Further= , I think it would be interesting if we considered defining an ability to u= se BFD to connect to a DLEP instance in order to manage the link up/down se= tting.  This could be useful if one was using DLEP over virtual interfaces.

Not sure I understand what you mean here. BFD and DLEP both manage the= link up/down setting, but do so via different approaches. BFD relies on co= ntinuously sending packets over the link; DLEP relies on "smart modems= " to tell the router about link status. How do you envision connecting the two? 

 <= /span>
Finally= , as I didn=92t  quite get to finish my presentation due to time const= raints, I also wanted to mention that I would be here all week and would be= happy to have further conversation on my presentation if anyone was interested.  Please feel free to email me = and we can pick a coffee spot to continue talking.

I'm not in Toronto, and therefore can't pick a coffee spot, but as I s= aid, I'm interested in talking about DLEP. 

Regards,
Stan



 <= /span>
Thanks,=
Brian
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/ma= net

--_000_C7ADCA323D8D471C9E0B76F524AD0EECciscocom_-- From nobody Tue Jul 22 20:21:29 2014 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 41AA31A030D for ; Tue, 22 Jul 2014 20:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 osI5lYxRQO3c for ; Tue, 22 Jul 2014 20:21:25 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id E0E521A0304 for ; Tue, 22 Jul 2014 20:21:24 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,714,1400040000"; d="scan'208";a="11316043" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 22 Jul 2014 23:21:23 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Tue, 22 Jul 2014 23:21:23 -0400 From: "Snyder, Brian" To: Thomas Clausen Thread-Topic: [manet] BFD Proxy Idea Thread-Index: Ac+mBFQ9JJUS9xvFSKGU/LtcZEhAWAAI+EMAAAJkvTA= Date: Wed, 23 Jul 2014 03:21:22 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yMPFCcQMFqrmeSIzw9he93YVpMo Cc: "manet@ietf.org" Subject: Re: [manet] BFD Proxy Idea 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, 23 Jul 2014 03:21:27 -0000 Stan, Thomas, & All, First let me try and explain my use case a bit better, as it's probably not= the typical network designers had in mind... I have been very involved with designing and prototyping a layer 2 sat base= d product offering. As we transition away from "typical" L3 network archit= ecture our next logical step has been for some time to get into RAR/DLEP/ET= C to better optimize L3 routing convergence over the satellite for our cust= omers. The main idea being to allow them to tune down their L3 "HELLOS" an= d try and drive a more event driven model to conserver very expensive satel= lite bandwidth (while keeping decent convergence times). We know there wou= ld be a ton of demand for this if we can solve this particular radio link -= router optimization (faster convergence of Layer 3 CE devices behind the m= odems and hub), which is exactly what DLEP is for.. but my network architec= ture is hub and spoke, not mesh. The scalability of the spokes is simple -= they just need 1 DLEP and ROUTING peer - the hub. However, the hub radio = will terminate (and represent via DLEP to upstream router) potentially thou= sands of spokes. =20 DLEP seems like a perfect match from everything I've read. but in many ways= it seems more complicated than is necessary for my use case.=A0 =A0=A0For = instance, it would be ideal for me to simply be able to set interfaces logi= cally down, yet NOT have to have a routing protocol specifically tied in (l= ike BFD).=A0 That way I don't have to force any particular network architec= ture on my customers.... afterall, the main reason we are going L2 is to be= transparent. That ideal loses some steam if I then have to force very narr= ow routing options on them when in L3 mode they have more choices. I don't= want the congestion/route control features necessarily (for now that is ov= erkill to me), but I would love to be able to easily set peers or links "do= wn" to immediately converge routing tables as a Modem falls out (or reenter= s) the network.=A0 Thus avoiding all L3 timers.=A0 Essentially I'd like to = pull a virtual Ethernet plug.=20 The added functionality is great, and potentially useful down the road, but= the downside then is that it requires OSPF or EIGRP.=A0 Preferably, I woul= dn't care if a customer wanted BGP or RIP, etc. if I could logically set th= e interface down via Radio control messages then all my timing/convergence = problems would be solved.=A0 Is there a simpler way of doing this within th= e confines of DLEP?=A0 As stated above, the hub side has additional complex= ity as it will aggregate for potentially thousands of modems.=A0=A0 So I fully admit, that I am not sure I'm understanding it all correctly, an= d I've only played with Cisco's implementation so I very well may (probably= likely) have my lines blurred between the standard that DLEP defines and e= xactly what is practically implemented and available to use .. This is like= ly throwing my understanding of the standard off.. but when I looked at it = a few months ago (before I ended up going down the BFD route) I was concern= ed that I would need thousands of virtual interfaces at the upstream router= and I knew that wouldn't scale. This sheer # of virtual of interfaces wo= uld also cascade into multicast issues (My hub link is a broadcast medium a= nd I can't have packets replicated). Also, AFAIK, supporting VLAN with thi= s model is not an option. Perhaps one could setup multiple neighbors to ea= ch router via DLEP using multiple interfaces per VLAN per modem - but that = would just make the scaling even worse - by an order of magnitude (we expec= t 10 to 12 vlans per modem). Alternatively, and ideally, we could support = the notion of VLAN trunking into the DLEP interface but I don't think that'= s currently supported, (again though, that could just be a limitation of th= e VMI design in cisco's implementation). BFD it turns out removes a lot of these concerns - but it's significantly c= hattier - which is why I came up with the proxy idea, since as Rick eloquen= tly stated - I have some radio magic I can rely on for link state - I think= because it works on interfaces and doesn't require all the VMI stuff, it j= ust seems to scale better. BUT (big but) it's very chatty in its own right= and I can't have any link state information shared, which would be ideal..= . =20 Primarily, I feel I have a MANET problem/use case - and that if we think ab= out it (or I get more educated:) it should be solved within MANET technolog= ies..... I surprised myself at the end of this research to land on BFD... = I think because I'm proxying it, I've essentially created a DLEP-light for = router - radio link state notifications. =20 I hope that explains some of my concerns and design issues with what I curr= ently have to work with. I'm sure I've made some bad assumptions - so plea= se have at me :) Side note: My observations are what I had in hand to work with, not necessa= rily what the draft says. I'm guessing this is poor form for IETF conversat= ions, so apologies if I've crossed a line... I'm new here ;) Perhaps newer= DLEP drafts address some of these issues, and I just have to stick with BF= D until there are practical implementation I could try and integrate with..= ... It's my understanding the sourceforge reference implementation is base= d on draft-0 which is quite out-of-date already. Thanks for reading this far, Brian From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 Sent: Tuesday, July 22, 2014 7:43 PM To: Snyder, Brian Cc: manet@ietf.org Subject: Re: [manet] BFD Proxy Idea Dear Brian, On 22 Jul 2014, at 19:35, "Snyder, Brian" wrote: Everyone, =A0 As I presented , I think the main problems I had in adopting DLEP were: . Multicast support . VLAN support . Scalability =A0 >From a radio point of view, I would like to get these issues addressed (or = at least discussed) so they can work their way into the DLEP definition.=A0= =20 =A0 Ideally, I could use DLEP, as it does have some advantages over BFD, to sol= ve the problem I described. =A0 I think that it would be a significant help if you could point out "how" --= for dummies like me, who do not understand satcom very well ;) Further, I think it would be interesting if we considered defining an abili= ty to use BFD to connect to a DLEP instance in order to manage the link up/= down setting.=A0 This could be useful if one was using DLEP over virtual in= terfaces. OK, this makes sense to me. =A0 Finally, as I didn't =A0quite get to finish my presentation due to time con= straints, I also wanted to mention that I would be here all week and would = be happy to have further conversation on my presentation if anyone was inte= rested.=A0 Please feel free to email me and we can pick a coffee spot to co= ntinue talking. To mix up (at least, two) metaphors, I have no dogs in this race -- but I t= hroughly enjoyed both your presentation and reading your I-D, which was par= ticularly well written and easy to digest. Cheers, Thomas =A0 Thanks, Brian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 02:56:47 2014 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 53CDF1A0366 for ; Wed, 23 Jul 2014 02:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 BDo3Goizk3cQ for ; Wed, 23 Jul 2014 02:56:43 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8121A035F for ; Wed, 23 Jul 2014 02:56:43 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so7470049wiv.11 for ; Wed, 23 Jul 2014 02:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=WlsXIpwedqtAGwOdJz3gZUiU0oK2nBN6akwN8uHg25Q=; b=buXPPxtG+3R4YWnvIVuuw8FIpTqYmTIItoB4xeax3bV23OfKil7hlUIcCg4ft0KUso zWVP0oJhAuGxTgoHyctWcTCtAFiVX3CUh8CZ53btw4fq6gNzhUUhDCSenx1cgzU6pnOj BQDxYPaGyrgt3kXYe4zsiI8yDja6nwOo5NA9Ur2TssNdPILP+7uUtClx7qMEH0bP/QGr WeyFkBW1kqIjXtOE7VGkk1OwPXseP1nTQMuwQJSq1jNvuscne1QltVX76aVu4NpwCwyW zHQW4UHInRiMJkP1uaECFsQUA0/9KVBLLbtg3OGDa7jigpWrDO45kiL1I9clACdej972 Zxww== MIME-Version: 1.0 X-Received: by 10.180.19.200 with SMTP id h8mr23707743wie.32.1406109399435; Wed, 23 Jul 2014 02:56:39 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Wed, 23 Jul 2014 02:56:39 -0700 (PDT) Date: Wed, 23 Jul 2014 11:56:39 +0200 X-Google-Sender-Auth: gqrVtE4n9Hl8cmqU8TbIVmyV7y4 Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=bcaec53d5eb744d2d804fed95bb5 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BkbKXpRBmmsYIdu0caj14s2RZvU Subject: [manet] About olsrv2-multipath, following the discussion on IETF90 meeting 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, 23 Jul 2014 09:56:45 -0000 --bcaec53d5eb744d2d804fed95bb5 Content-Type: text/plain; charset=UTF-8 Hi, Thanks very much for the discussion on olsrv2-multipath during the meeting. I would like to add a few words regarding the comments during the discussions. o Why do multipath routing in MANET, rather than other WGs? The olsrv2-multipath is an extension of OLSRv2. Based on our experience, multipath is more interesting if the topology is dynamic, or link breakage is frequent. In fact, the simulation results (in which the link is assumed relatively stable) show that the performance is very close between the two in static scenarios. The performance gain is much more interesting in dynamic networks. o Source routing? The olsrv2-multipath uses IP source routing (loose source routing for IPv4, RFC6553 for IPv6), so that it can be interoperable with OLSRv2 and its other extensions (such as new metrics, multi-topology, etc.). Theres nothing inherently preventing other mechanism for 'forcing traffic along certain paths' -- for example, one could imagine setting up a label-switched path for each path in a multi-path flow, if such was desired. It might be a good idea for the next version of the I-D to indicate this, although we do not have any operational experiences with this. It might be an interesting expansion to the document, and to the experiment it is to enable, to try to understand which other ways of 'forcing traffic along certain paths' are valid. Adrian, thank you for triggering those thoughts. o Multipath for re-active protocols? I know that there have been several proposals that published as academic papers. But I have to point out that the way doing multi-path for re-active protocols is very different for pro-active protocols. For pro-active protocol, we have already a topology map of the network, so it's much simpler to calculate desired paths. In re-active protocol, to obtain enough information to get multiple paths, more route discovery messages are required, which might cause unpredictable behaviours. I remember in the IETF Maastricht, there was a presentation about multipath-dymo using multiple interfaces. That was totally a different way compared to this olsrv2-multipath draft, and has special layer 2 requirements (such as multiple interfaces). The draft is aimed to be a light-weight extension of OLSRv2 -- and it is, regarding its size: 16 pages in total -- and if you cut the references, implementation status, copy right, etc, you have less than 10 pages to read :) Please review the document, the authors are very eager to incorporate your comments. As I heard it (granted, I attended remotely) there was a single hum 'against' adopting the document. The authors are actually quite excited about that, since divergent opinions is a source for inspiration: what's the reason for the 'hum against'? Anything in the document that can be done better, or which in your opinion and experience would 'break the internet' or be sub-optimal? If you could elaborate, then that would allow improvements, which would be immensely helpful. Of course, if you want to 'anonymize' by way of relaying through the chairs or the ADs, that's quite alright -- our objective is to build the best possible OLSRv2 extension possible, so through whichever form your opinion is relayed, it's valuable to us, and we want to express our appreciation." The work behind this draft was developed more than a decade ago, and has existed and been improved for years, with very interesting outcome. Thanks to the multiple open-source implementations in different platforms, the protocol has been tested by different researchers, engineers all over the world. We believe it's time to have it clearly specified, and published as an experimental RFC. We've been holding back pushing for this, since we felt that OLSRv2 -- with its support for IPV6, and for security, and for extensibility -- should be finalized before pushing for extensions like this. regards Jiazi --bcaec53d5eb744d2d804fed95bb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks very much for the= discussion on olsrv2-multipath during the meeting. I would like to add a f= ew words regarding the comments during the discussions.

o Why do multipath routing in MANET, rather than other WGs?
=
The olsrv2-multipath is an extension of OLSRv2. Based on our= experience, multipath is more interesting if the topology is dynamic, or l= ink breakage is frequent. In fact, the simulation results (in which the lin= k is assumed relatively stable) show that the performance is very close bet= ween the two in static scenarios. The performance gain is much more interes= ting in dynamic networks.

o Source routing?

The olsrv2-m= ultipath uses IP source routing (loose source routing for IPv4, RFC6553 for= IPv6), so that it can be interoperable with OLSRv2 and its other extension= s (such as new metrics, multi-topology, etc.).
Theres nothing inherently preventing other mechanism for 'forcing = traffic along certain paths' -- for example, one could imagine setting = up a label-switched path for each path in a multi-path flow, if such was de= sired. It might be a good idea for the next version of the I-D to indicate = this, although we do not have any operational experiences with this. It mig= ht be an interesting expansion to the document, and to the experiment it is= to enable, to try to understand which other ways of 'forcing traffic a= long certain paths' are valid. Adrian, thank you for =C2=A0triggering t= hose thoughts.=C2=A0

o Multipath for re-active protocols?

I know that there have been several proposals that published as acad= emic papers. But I have to point out that the way doing multi-path for re-a= ctive protocols is very different for pro-active protocols.
For pro-active protocol, we have already a topology map of the network= , so it's much simpler to calculate desired paths. In re-active protoco= l, to obtain enough information to get multiple paths, more route discovery= messages are required, which might cause unpredictable behaviours.
I remember in the IETF Maastricht, there was a presentation about mult= ipath-dymo using multiple interfaces. That was totally a different way comp= ared to this olsrv2-multipath draft, and has special layer 2 requirements (= such as multiple interfaces).=C2=A0


The draft is aimed to be a light-weight = extension of OLSRv2 -- and it is, regarding its size: 16 pages in total -- = and if you cut the references, implementation status, copy right, etc, you = have less than 10 pages to read :)

Please review the document, the authors are very eager = to incorporate your comments. As I heard it (granted, I attended remotely) = there was a single hum 'against' adopting the document. The authors= are actually quite excited about that, since divergent opinions is a sourc= e for inspiration: =C2=A0what's the reason for the 'hum against'= ;? Anything in the document that can be done better, or which in your opini= on and experience would 'break the internet' or be sub-optimal? If = you could elaborate, then that would allow improvements, which would be imm= ensely helpful.

Of course, if you want to 'anonymize' by way of= relaying through the chairs or the ADs, that's quite alright -- our ob= jective is to build the best possible OLSRv2 extension possible, so through= whichever form your opinion is relayed, it's valuable to us, and we wa= nt to express our appreciation."

The work behind this draft was developed more than a de= cade ago, and has existed and been improved for years, with very interestin= g outcome. Thanks to the multiple open-source implementations in different = platforms, the protocol has been tested by different researchers, engineers= all over the world. We believe it's time to have it clearly specified,= and published as an experimental RFC.

We've been holding back pushing for this, since we = felt that OLSRv2 -- with its support for IPV6, and for security, and for ex= tensibility -- should be finalized before pushing for extensions like this.=

regards

Jiazi

--bcaec53d5eb744d2d804fed95bb5-- From nobody Wed Jul 23 03:00:35 2014 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 D16541A038B; Wed, 23 Jul 2014 03:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.395 X-Spam-Level: X-Spam-Status: No, score=-13.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 Pt2d7vMUcy7F; Wed, 23 Jul 2014 03:00:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECBB1A035F; Wed, 23 Jul 2014 03:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2220; q=dns/txt; s=iport; t=1406109628; x=1407319228; h=date:from:to:cc:subject:message-id:mime-version; bh=S78y0w3pSOfOxG3e9wAuTYRlfcXRiO3tpuM2YXtWv9I=; b=fEHc+zBnTvDxOeWcALpdvbmFbomXSblAjE7SkyUGqhSM4IklFJDLHSZF BCCEtE3KSXFjkeTF/3ZTe5TxA1x6t4un0tSlmj9AIc9TwdXRee/41RhlZ pJS+cnqymprP/UhYeTJZUn7Vdbw9B1DhzItVcNeu5BA00YxXzUyMU9iHB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0eAL6Gz1OtJV2U/2dsb2JhbABZgw7QTA9/FnaERD88NAV3iCe/GhePSx2EMAWKZpA/AZQ0g2Yd X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="scan'208";a="342184556" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jul 2014 10:00:27 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6NA0Pvl016698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 10:00:26 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NA0Kj4015171; Wed, 23 Jul 2014 03:00:25 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NA0Jq5015169; Wed, 23 Jul 2014 03:00:19 -0700 Date: Wed, 23 Jul 2014 03:00:19 -0700 From: Toerless Eckert To: manet@ietf.org Message-ID: <20140723100019.GK24330@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/viQUmbIihUi_xlJg8HKufqLGPjw Cc: pim@ietf.org Subject: [manet] manet: IP multicast comments 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, 23 Jul 2014 10:00:32 -0000 Having not followed Manet for a couple of years, and sat in yesterdays meeting, where there was a question about multicast, some questions and comments: (1) It sounded to me as if every MANET solution support IP multicast flooding, but thats pretty much it ? What for example would be the solution for flooding when you use eg: OSPF with Manet extensions ? SMF ? (2) There seemed to be some interest in working on BTF (Metter Than Flooding) IP multicast protocols (a), but also (b) some concerns about work overload that this might result in for manet. (2a) Is there any write down of use cases in Manet that require such BTF IP multicast services with manet ? If yes, please provide pointers, if not, i'd suggest that is the first thing to write down. I got the understanding that eg: the evolution from SA (situation awareness == very low bitrate) as the prime use case to also voice/video group communication is such a typical use case for BTF multicast, but without it being written down and prioritized, it is IMHO premature to proceed on protocol work. And there is a lot more than just prioritization of work to get from the use cases details. For example, since 2000, we do have in the IETF two IP multicast service models. The traditional group-join one, we now call ASM (Any Source Multicast), and SSM, where the application has to know the source IP address, and includes it in IGMP membership reports. SSM simplifies BTF solutions drastical. It also increases security (not attacks by unwanted sources). So the use case analysis needs to vet whether SSM is an appropriate service or not for the use case. (2b) The routing ADs seem to be running around trying to do load-balancing of work across WGs, so it might be feasible to proceed with eg: protocol work for manet compatible IP multicast in the IP Multicast WG (currently called PIM). From what i could glean from Alias statements yesterday in PIM WG, they where primarily thinking of bringing MPLS multicast over to the Multicast WG, but i think one may want to consider Manet multicast as well. Nevertheless, see (2a), use-cases should IMHO be really owned by Manet-WG itself. Cheers Toerless From nobody Wed Jul 23 03:33:47 2014 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 B49711A03CF for ; Wed, 23 Jul 2014 03:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.395 X-Spam-Level: X-Spam-Status: No, score=-8.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 U5ljeSw62eic for ; Wed, 23 Jul 2014 03:33:44 -0700 (PDT) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B7B1A03A4 for ; Wed, 23 Jul 2014 03:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3057; q=dns/txt; s=iport; t=1406111624; x=1407321224; h=date:from:to:cc:subject:message-id:mime-version; bh=8b3cKSetbeYsUiXpd1bmsyqjlaxcVT/VkOTfeMD946U=; b=CvZeaTS/fECFvnlaKPNbjE3ratP/Q+fWiUWORIGg1jpkeasCd+IKO4ZM 7xNtxYremGAvAoOxwmGGYNJ+mA+8eU3RJWX/LZhElrqR8GnxeH1wKfxag YmrH2v5ocMnnAfpNSN6KUdilSJqsZR0sODMoZ+Jum5OpsAdv6QDrZG/af A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEcALaOz1NIo8UY/2dsb2JhbABZ010PgRV2hEQ/PDQFd4gnvzAXjnoBAU8dhDAFimaQPwGUNINmHYE7 X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="scan'208";a="8600764" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 23 Jul 2014 10:33:41 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NAXcrF026729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 10:33:40 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NAXb0W016285; Wed, 23 Jul 2014 03:33:37 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NAXbV8016284; Wed, 23 Jul 2014 03:33:37 -0700 Date: Wed, 23 Jul 2014 03:33:37 -0700 From: Toerless Eckert To: manet@ietf.org Message-ID: <20140723103336.GL24330@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qxIO_5MfDBtzzKT38ytPAKP86R4 Cc: pim@cisco.com Subject: [manet] manet: draft-gerla-manet-odmrp-03 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, 23 Jul 2014 10:33:45 -0000 Some comments on subject draft, and maybe take this mail also as helpfull to decide if/how PIM WG could help with Manet groups multicast interest: (A) Nice simple looking IP multicast protocol. This is how simple i remember the first versions of PIM to be, 20 years ago, before proliferation, success and generations of implementers eyeballs beat all necessary bug-fixes, oversight amendments and optimizations into the current PIM RFCs. Now having said this: The current PIM RFC 4601 is like C++ vs. Java: Remove 80% from it and you have PIM-SSM, which is relevant here. (B) Fundamentally, ODMRP is what PIM-SSM + draft-ietf-pim-source-discovery-bsr (SD-Draft) with IMHO three main differences: 1) ODMRP does rely on some pre-existing flooding mechanism (eg: SMF) for messages indicating what (S,G) are actively sending traffic. (called "join request" in ODMRP, called SG mapping in SD-draft). 2) PIM-SSM (like all other variants of PIM) maintains an OIF-list (Outgoing Interface list) to which received multicast packets are replicated, and it eliminates loops/duplicate packets via RPF-check. ODMRP proposes to transmit the packet to all interfaces, (even though it could build an OIF list from received "join reply"), and it uses duplicate packet detection instead of RPF check. 3) ODMRP uses "join reply" acknowledgements sent from the up to the downstream router to detect unidirectional adjacencies, and proposes to then use an ad-on draft (gerla-manet-odmrp-asym) to make that work. I think that these differences hardly justify inventing a new protocol and going through all the trouble of (A). Instead i would strongly suggest to consider adopting the solution worked on in PIM and modify it accordingly: - If existing MANET networks have working flooding solutions, they should of course be useable by the solution. SD-Draft was brought into IETF for networks that do not have any (like pretty much all non-MANET networks i know of). - RPF-check vs duplicate-elimination and OIF-list vs all-interface-forwarding might be justified differences based on whether the interfaces is MANET or not. Aka: This doesn't have to be a network wide protocol behavior, but could be IIF/OIF-link properties of PIM - therefore also allowing very easily a mixed network with MANET and non-MANET parts. Instead of having to figure out how to interconnect PIM with a MANET specific protocol (interconnecting multicast protocols is always a pain). And of course, i think there should be more review if these two choices are actually the best for MANET. I understand some reasons why they are good, but i also have some more concerns there. I think this shouldn't be too tough to work out. - Unidirectional link support seems like an extension anyhow, we had done some work in products for non-MANET networks, i don't quite remember what made it through the IETF and what stayed in proprietary features, so i'll comment on this later. Cheers Toerless From nobody Wed Jul 23 03:34:25 2014 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 B596C1A03E0; Wed, 23 Jul 2014 03:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.395 X-Spam-Level: X-Spam-Status: No, score=-13.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 cMNQ4IeFl0MJ; Wed, 23 Jul 2014 03:34:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E701A03DF; Wed, 23 Jul 2014 03:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3241; q=dns/txt; s=iport; t=1406111657; x=1407321257; h=date:from:to:cc:subject:message-id:mime-version; bh=vzqpCXTmNKCej3YWej1g+b6LkvFfmAkYK6bReRyXfZI=; b=TbxCHJcVZFT+Xuw7KREspBvPrP5Drqjd1ewMXmBrIl1C0PS8T0NQ7q6C vn/ylV9OF5pwPxJnFAWFTRl6RhjaxCohu7U/G4wQA+GOuRsiGqFt5N0Wj fC8+8IUhK4XjImfWdZ8pQCgkVGV9VZ4P3MLTDgS6FU+zKzsKbOVN98MlE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsseAC2Pz1OtJA2N/2dsb2JhbABZgw6BKc8mD38WdoREPy0PNAU1JxuIJ78wF456AQFPhE0FimaQPwGUNINmHS+BDA X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="scan'208";a="341991753" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jul 2014 10:34:16 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6NAYFcr016805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 10:34:16 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NAYFij016321; Wed, 23 Jul 2014 03:34:15 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NAYEEJ016320; Wed, 23 Jul 2014 03:34:14 -0700 Date: Wed, 23 Jul 2014 03:34:14 -0700 From: Toerless Eckert To: manet@ietf.org Message-ID: <20140723103414.GM24330@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/a8oZ3m66NfvGrpPAdgO0Xa2U7b4 Cc: pim@ietf.org Subject: [manet] manet: draft-gerla-manet-odmrp-03 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, 23 Jul 2014 10:34:21 -0000 Sorry, resending with correct recipients. Some comments on subject draft, and maybe take this mail also as helpfull to decide if/how PIM WG could help with Manet groups multicast interest: (A) Nice simple looking IP multicast protocol. This is how simple i remember the first versions of PIM to be, 20 years ago, before proliferation, success and generations of implementers eyeballs beat all necessary bug-fixes, oversight amendments and optimizations into the current PIM RFCs. Now having said this: The current PIM RFC 4601 is like C++ vs. Java: Remove 80% from it and you have PIM-SSM, which is relevant here. (B) Fundamentally, ODMRP is what PIM-SSM + draft-ietf-pim-source-discovery-bsr (SD-Draft) with IMHO three main differences: 1) ODMRP does rely on some pre-existing flooding mechanism (eg: SMF) for messages indicating what (S,G) are actively sending traffic. (called "join request" in ODMRP, called SG mapping in SD-draft). 2) PIM-SSM (like all other variants of PIM) maintains an OIF-list (Outgoing Interface list) to which received multicast packets are replicated, and it eliminates loops/duplicate packets via RPF-check. ODMRP proposes to transmit the packet to all interfaces, (even though it could build an OIF list from received "join reply"), and it uses duplicate packet detection instead of RPF check. 3) ODMRP uses "join reply" acknowledgements sent from the up to the downstream router to detect unidirectional adjacencies, and proposes to then use an ad-on draft (gerla-manet-odmrp-asym) to make that work. I think that these differences hardly justify inventing a new protocol and going through all the trouble of (A). Instead i would strongly suggest to consider adopting the solution worked on in PIM and modify it accordingly: - If existing MANET networks have working flooding solutions, they should of course be useable by the solution. SD-Draft was brought into IETF for networks that do not have any (like pretty much all non-MANET networks i know of). - RPF-check vs duplicate-elimination and OIF-list vs all-interface-forwarding might be justified differences based on whether the interfaces is MANET or not. Aka: This doesn't have to be a network wide protocol behavior, but could be IIF/OIF-link properties of PIM - therefore also allowing very easily a mixed network with MANET and non-MANET parts. Instead of having to figure out how to interconnect PIM with a MANET specific protocol (interconnecting multicast protocols is always a pain). And of course, i think there should be more review if these two choices are actually the best for MANET. I understand some reasons why they are good, but i also have some more concerns there. I think this shouldn't be too tough to work out. - Unidirectional link support seems like an extension anyhow, we had done some work in products for non-MANET networks, i don't quite remember what made it through the IETF and what stayed in proprietary features, so i'll comment on this later. Cheers Toerless -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From nobody Wed Jul 23 03:37:21 2014 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 E1AC91A0303; Wed, 23 Jul 2014 03:37:14 -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 eeieI38qotaP; Wed, 23 Jul 2014 03:37:11 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A328C1A0030; Wed, 23 Jul 2014 03:37:11 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so981638qaq.25 for ; Wed, 23 Jul 2014 03:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RBobF0C4o9Sb/5IQIP6X+UXdvRSbgPKrnWxr+RM2Kg8=; b=aEluA9lbCU27rsfbl8aK8jN5aQOmgUK8LHsn9wi9f3XlaIgr9/R8xMEMRsi9IjMpqO gWrJ4bBExtWJJdyK5hSfFJQUz6EdbA1tv0pE6IF8mS2pJrUFmvoV0zORbw8oNKPhxa5T bSCeo3r9ZQrjP4TcDdP+bcEfGxF2kMW/Hpc4FkR1DyEb5zLJV0k8szLVODoJxNviFqqq tDAuDT4XizUhv5p7DYpd5cTtru7DWQ49BHwfkmHRKOQ7JgmE1oL2f9BrMO1XYS+HjnMl dJ0p9TjTrAfWOwA78mjxM/pmwwoi/8V+DWgaQ0155Fx3Z2c/+lq+MfzRpcOBdg82S2Wd sn+Q== X-Received: by 10.224.96.137 with SMTP id h9mr574903qan.96.1406111830891; Wed, 23 Jul 2014 03:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 03:36:50 -0700 (PDT) In-Reply-To: <20140723100019.GK24330@cisco.com> References: <20140723100019.GK24330@cisco.com> From: Henning Rogge Date: Wed, 23 Jul 2014 12:36:50 +0200 Message-ID: To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tuP9--tE1uo-658NZpyMuplhy78 Cc: MANET IETF , pim@ietf.org Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 10:37:15 -0000 On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > Having not followed Manet for a couple of years, and sat in yesterdays > meeting, where there was a question about multicast, some questions and > comments: > > (1) It sounded to me as if every MANET solution support IP multicast > flooding, but thats pretty much it ? What for example would > be the solution for flooding when you use eg: OSPF with Manet > extensions ? SMF ? I think one main difference with MANET is that you have a non-transitive network... just because that you can hear someone on interface X does not mean all your neighbors on interface X can hear this station. This means that multicast packets coming in through an interface typically have to be retransmitted through the same interface again. I don't even know if there is any kind of kernel support for this kind of forwarding. Henning Rogge From nobody Wed Jul 23 03:44:43 2014 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 AEDCC1A017E for ; Wed, 23 Jul 2014 03:44: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 fb_7m4XveXiz for ; Wed, 23 Jul 2014 03:44:39 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0701A0179 for ; Wed, 23 Jul 2014 03:44:39 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so1145035qgf.6 for ; Wed, 23 Jul 2014 03:44:38 -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=kfJdV7Gt0xt357AASqYd+HQZcMslwtN/2yicnCDkeSk=; b=CameKZgBQooIqbzzKj7C0pfLxIjdGF3Lx9i7DRnbtAMwvRSB6ejWasEJE0aTYg/wdM D2ut816oaNz46NGtNw1ZXF7Ge3g+ZYiXvIXmQDQ6KVAW7djMgisPvpLgRabcFO3hnSJw FQIA+l7AUb114+lqLWq3Cw0jzJu7ql9z2JCRSm9rfS7TbO7uIsebwOz8TGQKXz1hu51W tDb6rUYVnjl4qrbPk7TQ5Tj9rkg7KTdLSVKUXUvtpIEpix6U+CIJvqT78GT6ymD18hL5 bo+4ZZl5f3tk75jpHp3Xo78/0ayKcfhSt/THAQfrR6CODTutwik3+xx+5N+C3wliANoH cu9A== X-Received: by 10.140.84.168 with SMTP id l37mr580387qgd.104.1406112278662; Wed, 23 Jul 2014 03:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 03:44:18 -0700 (PDT) In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> From: Henning Rogge Date: Wed, 23 Jul 2014 12:44:18 +0200 Message-ID: To: "Snyder, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bCQD0pmSbeC3GnP5d_ducszOets Cc: "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] BFD Proxy Idea 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, 23 Jul 2014 10:44:41 -0000 On Wed, Jul 23, 2014 at 5:21 AM, Snyder, Brian wrote: > Stan, Thomas, & All, > > First let me try and explain my use case a bit better, as it's probably n= ot the typical network designers had in mind... > > I have been very involved with designing and prototyping a layer 2 sat ba= sed product offering. As we transition away from "typical" L3 network arch= itecture our next logical step has been for some time to get into RAR/DLEP/= ETC to better optimize L3 routing convergence over the satellite for our cu= stomers. The main idea being to allow them to tune down their L3 "HELLOS" = and try and drive a more event driven model to conserver very expensive sat= ellite bandwidth (while keeping decent convergence times). In the "DLEP-model" this would be a modification of the routing agent... because DLEP does not produce any traffic over the wireless link, just locally between the radio and the router. > We know there would be a ton of demand for this if we can solve this part= icular radio link - router optimization (faster convergence of Layer 3 CE d= evices behind the modems and hub), which is exactly what DLEP is for.. but = my network architecture is hub and spoke, not mesh. The scalability of the= spokes is simple - they just need 1 DLEP and ROUTING peer - the hub. Howe= ver, the hub radio will terminate (and represent via DLEP to upstream route= r) potentially thousands of spokes. I see no real trouble with this for DLEP... the "spoke" DLEP-radios will just deliver a single detected neighbor (the hub) while the hub will get all of the neighbors... > DLEP seems like a perfect match from everything I've read. but in many wa= ys it seems more complicated than is necessary for my use case. For inst= ance, it would be ideal for me to simply be able to set interfaces logicall= y down, yet NOT have to have a routing protocol specifically tied in (like = BFD). That way I don't have to force any particular network architecture o= n my customers.... afterall, the main reason we are going L2 is to be trans= parent. That ideal loses some steam if I then have to force very narrow rou= ting options on them when in L3 mode they have more choices. I don't want = the congestion/route control features necessarily (for now that is overkill= to me), but I would love to be able to easily set peers or links "down" to= immediately converge routing tables as a Modem falls out (or reenters) the= network. Thus avoiding all L3 timers. Essentially I'd like to pull a vir= tual Ethernet plug. This should be exactly what DLEP is able to do... forward the layer-2 radio event to the router. > The added functionality is great, and potentially useful down the road, b= ut the downside then is that it requires OSPF or EIGRP. Why? > Preferably, I wouldn't care if a customer wanted BGP or RIP, etc. if I co= uld logically set the interface down via Radio control messages then all my= timing/convergence problems would be solved. Is there a simpler way of do= ing this within the confines of DLEP? As stated above, the hub side has ad= ditional complexity as it will aggregate for potentially thousands of modem= s. The problem I see is that you cannot take the local interface on the router down, because you would also loose your DLEP session. Maybe you could setup a virtual interface on the router that just has the user-traffic (without the DLEP session) which you can take up/down controlled by the DLEP instance on the router? > So I fully admit, that I am not sure I'm understanding it all correctly, = and I've only played with Cisco's implementation so I very well may (probab= ly likely) have my lines blurred between the standard that DLEP defines and= exactly what is practically implemented and available to use .. This is li= kely throwing my understanding of the standard off.. but when I looked at i= t a few months ago (before I ended up going down the BFD route) I was conce= rned that I would need thousands of virtual interfaces at the upstream rout= er and I knew that wouldn't scale. I think you would only need one interface per radio interface, not one per neighbor. > This sheer # of virtual of interfaces would also cascade into multicast i= ssues (My hub link is a broadcast medium and I can't have packets replicate= d). DLEP allows the radio to announce a multicast target (both with ethernet and IP address). > Also, AFAIK, supporting VLAN with this model is not an option. Perhaps o= ne could setup multiple neighbors to each router via DLEP using multiple in= terfaces per VLAN per modem - but that would just make the scaling even wor= se - by an order of magnitude (we expect 10 to 12 vlans per modem). Altern= atively, and ideally, we could support the notion of VLAN trunking into the= DLEP interface but I don't think that's currently supported, (again though= , that could just be a limitation of the VMI design in cisco's implementati= on). First time for me that I hear you need a VLAN for each neighbor seen by a DLEP radio. Henning Rogge From nobody Wed Jul 23 03:47:30 2014 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 D1F9D1A00A3 for ; Wed, 23 Jul 2014 03:47:27 -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 SPf-03jXX9lE for ; Wed, 23 Jul 2014 03:47:26 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9075B1A0329 for ; Wed, 23 Jul 2014 03:47:26 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so1020459qaq.39 for ; Wed, 23 Jul 2014 03:47:25 -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=JdBC75GyrwnlRkMj6v9F6q6GvulDjOzKTig3UsiwUqc=; b=a9FMuV/+0N7RYJ9OacXLxUxvtRcelZHiURD7acUmGKTzGJmypkAOT5XNVjDBofYF3c jyGEIsEAn/ysaQUUqEzP/g0bBGW2X5fboubZ1r0QYXFxtHNNwwRKMRNMOO6UIIwZFDW9 fyzZECuLX7SPk3U3CQOImEJ1bqraOGAfNAqkHC0zw2dDubufyuJh9RJ6mlJVG4k6dDCg Pw1XhAezDas4dw81WjkNddKNImBXcdaEzpWTtWFgr/v3ld8f+B0MkyQLqqHgERLQ7v8c TDNJ53vpn4VzSMiVmuCYmSTCg8EDMtd+H3WtITzbu/Dw/3evNVwEwl677uxmMwnz84xI l40g== X-Received: by 10.224.60.137 with SMTP id p9mr749621qah.70.1406112445292; Wed, 23 Jul 2014 03:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 03:47:05 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 23 Jul 2014 12:47:05 +0200 Message-ID: To: Justin Dean Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CpNW3IbJ83o4zL0ZleMl2UCMpPM Cc: "manet@ietf.org" Subject: Re: [manet] OLSRv2-Routed MANET Management 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, 23 Jul 2014 10:47:27 -0000 On Tue, Jul 22, 2014 at 8:43 PM, Justin Dean wrote: > Is the v4 and v6 thing true? Henning mentioned that his implementation uses > both v4 and > v6 in the same packet but with different messages. To say that OLSRv2 can't > do this > without running multiple instances isn't 100% true. Yes, my implementation can transport both IPv4 TCs and IPv6 TCs within the same RFC5444 packet. I am already working on a draft to present this "flooding optimization" mechanism to the WG. Henning Rogge From nobody Wed Jul 23 03:48:52 2014 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 A66781A00A3 for ; Wed, 23 Jul 2014 03:48:49 -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 5y9VyUoXuZNI for ; Wed, 23 Jul 2014 03:48:48 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8441A0329 for ; Wed, 23 Jul 2014 03:48:48 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so1141205qgd.12 for ; Wed, 23 Jul 2014 03:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QOUXQDJmnWGKQvS18G+7CZphVCamt6orfBiixmq/QxY=; b=aFc47Wpcv5ZoGE8nq8MeYf1fPgjngG2qP0w2Zd+vcfCMsCYLetRemNmJMzknqX210g HXgL3lLrIj4htY+QRHe0EEQJWxJMrSOSm4AQ0pHZ2d72R6EWpbpx5KusNotnvD4x7aqR aiYrt0mckeTgB6Uo76u8cw2mqhBC0KJyVAw1b8XeMPlJ0dq+JXYxvLUlwvgU29NmJb+e 3C9Od+KMaT/+gLgms9WsHDB9kkTEcI9QRdh881ytuC2CWRlfwul+c6m1PFNwLcmzw/we E3ryoG4pRNvNb+RX2y6zyIs36mSY/ovphBgkooE/uR+iaxnSoVENGQd2uaElAamdO2Z2 jLHg== X-Received: by 10.140.84.168 with SMTP id l37mr616816qgd.104.1406112527483; Wed, 23 Jul 2014 03:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 03:48:27 -0700 (PDT) In-Reply-To: References: <20140722173202.11282.8433.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Wed, 23 Jul 2014 12:48:27 +0200 Message-ID: To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PpBaJ1aYcXgVx7YUBKQCAWvrJ6Y Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-01.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, 23 Jul 2014 10:48:49 -0000 On Tue, Jul 22, 2014 at 7:38 PM, Jiazi YI wrote: > Hi, > > We just submitted a new revision of the olsrv2-multipath. > The major modification is a new subsection, stating the motivation of being > experimental, and the experiments to be conducted. Just a question I forgot to ask yesterday... how does this multipath apporach deal with the MTU problem? Using source-routing costs a lot of MTU. Henning Rogge From nobody Wed Jul 23 03:50:00 2014 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 0761A1A03CC for ; Wed, 23 Jul 2014 03:49:57 -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 sDRC4X6zhssQ for ; Wed, 23 Jul 2014 03:49:55 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2591A0329 for ; Wed, 23 Jul 2014 03:49:54 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so1126917qgf.35 for ; Wed, 23 Jul 2014 03:49:54 -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=I2PZousdzwRaBD7hhJ42Pt+su8fURG00fYaOv3n4+w4=; b=jQgS5N5jD7f9MB7VhLwpGmFrMmbCih1jOupiP4WRM24YQju64jwFMnibldnJ+DiKp+ Hj55v0WorzD/7XKNS73COVRHFyBrpk6H+Aq6H700PD6CttppcJy0AC/T5PI/1PAVDqJl QLJWQXXx5AWprNu+9WTTI3oZQo+ik2KwgJrYdq62E5BXOV6F6sagmBZo8NLy1nj/f12h 1WBhZ0GkwcwRkr6snMl/1dUXkMQe/lbAgdmjVktfKMhCsgi894fVTeQDV2gwd+uxYjIh bbuEc+Z5oVDXu8Ybw96yi8RIDEy9LWlGSENxOFBKwBmKbzm4f6YCr54GbZUQcicq6YSt +Jbg== X-Received: by 10.224.60.137 with SMTP id p9mr772961qah.70.1406112594180; Wed, 23 Jul 2014 03:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 03:49:34 -0700 (PDT) In-Reply-To: References: <20140722140154.17288.91798.idtracker@ietfa.amsl.com> <53CE7069.8070305@fkie.fraunhofer.de> <65DB9C5A-32D9-423D-BAB2-6DA9B93DC45A@thomasclausen.org> From: Henning Rogge Date: Wed, 23 Jul 2014 12:49:34 +0200 Message-ID: To: Justin Dean Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/DfKucNEWEE9xYsd6vWkK2z8h0y8 Cc: "" , "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] New Version Notification for draft-ietf-manet-olsrv2-dat-metric-01.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, 23 Jul 2014 10:49:57 -0000 On Tue, Jul 22, 2014 at 6:46 PM, Justin Dean wrote: > No it's implemented in my not yet publicly released OLSRv2 code. (which is > at the point I would be comfortable passing it along to you) > > Our OLSRv2 implementation state: Written, compiling, running, adding routes > and only crashing on occasion...So about 25-25% finished ;p Interop tests would be a great way to find new creative crashes. ;) Henning Rogge From nobody Wed Jul 23 04:00:31 2014 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 321691A0422; Wed, 23 Jul 2014 04:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 kSMzmGuVjGSu; Wed, 23 Jul 2014 03:59:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8974E1A0453; Wed, 23 Jul 2014 03:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1202; q=dns/txt; s=iport; t=1406113193; x=1407322793; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NKYVQnKMzKzUJ34R9v1/L+MOqGcoto0pM1j+QRb1iXU=; b=ac+/VH+IuvJBdELfuuZ4v0FQnhWg/x11IjH1b015UZV5ujAEk8Ac+Fg+ ix8e71nmlDF5qracFIlHVEAQGtOuUcMvCszoHfmSIJxr5/nVrhL6mBNf2 CH8XkYA1dxzrdAzqe62ZieMbUly84i4+kxlwp8N2PnKmCLrthgXXtMDC5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJ6Uz1OtJV2T/2dsb2JhbABZgw6BKc8oAYENFnaEBAEBBDo/EAsOCgklDwVJExuIJ781F49LB4MugRgBBIpmkD8BlDSDZh0v X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="scan'208";a="342197062" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jul 2014 10:59:53 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6NAxq5x015004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 10:59:52 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NAxpfZ017190; Wed, 23 Jul 2014 03:59:51 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NAxpni017189; Wed, 23 Jul 2014 03:59:51 -0700 Date: Wed, 23 Jul 2014 03:59:51 -0700 From: Toerless Eckert To: Henning Rogge Message-ID: <20140723105951.GA17023@cisco.com> References: <20140723100019.GK24330@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jWH_cnLaXbNQ1q-_5hBgRLZQRdo Cc: MANET IETF , pim@ietf.org Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 11:00:03 -0000 Thanks, Henning, I understand the partial-mesh properties of manet L2 subnets, when i said flooding i was asking across a Manet L2 domain. Also: what kernel ? On Wed, Jul 23, 2014 at 12:36:50PM +0200, Henning Rogge wrote: > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > > Having not followed Manet for a couple of years, and sat in yesterdays > > meeting, where there was a question about multicast, some questions and > > comments: > > > > (1) It sounded to me as if every MANET solution support IP multicast > > flooding, but thats pretty much it ? What for example would > > be the solution for flooding when you use eg: OSPF with Manet > > extensions ? SMF ? > > I think one main difference with MANET is that you have a > non-transitive network... just because that you can hear someone on > interface X does not mean all your neighbors on interface X can hear > this station. > > This means that multicast packets coming in through an interface > typically have to be retransmitted through the same interface again. > > I don't even know if there is any kind of kernel support for this kind > of forwarding. > > Henning Rogge From nobody Wed Jul 23 04:03:15 2014 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 9DDA61A01DC; Wed, 23 Jul 2014 04:03:12 -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 QcM0wD8tr65l; Wed, 23 Jul 2014 04:03:06 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE801A0123; Wed, 23 Jul 2014 04:03:06 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so1166505qgd.28 for ; Wed, 23 Jul 2014 04:03:05 -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=GZuMtXUYV/uBu1JND8AOv0ANrvU5fQqHjNgrf3fW9OU=; b=ig3usp+T4cjPjmwEHymfbursbBuWEqhtUAVzh0MaBOzHui4Byu20VBid2Z47FLDjTz yZir3LlPJyCcldRXouJqJJTDAh7RjQYUIXDR0UtquIEb9CGzE0x6oLaw8XImiEbikxv1 jEu7Kwo8mHtr4YzUMFXP6ebHEbe02LukrJOqWgi7mVdivuhadTX8EvEl3wGooo1EH757 9aRzHd4M2ZfGqMsBto5K7BmKoSkg3kblO6ykFuRmXBhO13DEGB5usO5albo0zPDMpfz2 43UshswSyiiY4DwRMTSJo76u0AVEoF2FtIPfPsr8rhjlvCbKHl4MPWPI7JmGogFLiB1+ U8SA== X-Received: by 10.224.96.137 with SMTP id h9mr819463qan.96.1406113384236; Wed, 23 Jul 2014 04:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 04:02:44 -0700 (PDT) In-Reply-To: <20140723105951.GA17023@cisco.com> References: <20140723100019.GK24330@cisco.com> <20140723105951.GA17023@cisco.com> From: Henning Rogge Date: Wed, 23 Jul 2014 13:02:44 +0200 Message-ID: To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hh5eZfjkMyaCykHEnTY5cP--IOM Cc: MANET IETF , pim@ietf.org Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 11:03:12 -0000 On Wed, Jul 23, 2014 at 12:59 PM, Toerless Eckert wrote: > Also: what kernel ? let me rephrase this to "Operation system support"... Henning Rogge From nobody Wed Jul 23 04:04:15 2014 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 DC93D1A0422 for ; Wed, 23 Jul 2014 04:04:13 -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 F5w_SrxObLak for ; Wed, 23 Jul 2014 04:04:08 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DF51A02EC for ; Wed, 23 Jul 2014 04:04:07 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so1045410qaj.35 for ; Wed, 23 Jul 2014 04:04:07 -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=tTe1oja8gJo7JyqZX6VyEcnTsI/5IDZ8vRs6Kv0sALY=; b=RV88jUhhdL019Z31veq2e4xqeDb7bMmy4SLhVNSMvdCYidIYLGk2Qzp07FhiLZfyCh gcjzAzBuxuuLMGxY7dw8dxeR2nIH7tLtopreNVkgUJmqvIkonW4IvvMrbF9FkMPdLlTX 4EQpbcRCE03MMbTIH+erxNBKfL3sRAZXHD9XgbH5h4XcpsJoP3dfNF64mUrGHcOloRCo oyzIuWpn6Suj+AuBNgwQTllRkjrlZOmfrlKnN1O1Lhi3iNp3xkEJV/rgflg9rvkrWYsg y2Y0fGeivVDTiSt29LPfV+Yi6IeGQLNCqccZLwFlj4bYJ9R6iaoFbS4e64RmkN6bMKkd YgOA== X-Received: by 10.224.60.137 with SMTP id p9mr908557qah.70.1406113447209; Wed, 23 Jul 2014 04:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 04:03:47 -0700 (PDT) In-Reply-To: <7A4D33C4-2176-4AC9-B978-296B92D95D1B@thomasclausen.org> References: <061.5b91f4f9f74fe26d1eb24cfd1ed89d43@trac.tools.ietf.org> <617F475F-ABEE-4D19-9AF4-BA20A34DEF7F@thomasclausen.org> <53CE6FA4.9010500@fkie.fraunhofer.de> <62B7CFA4-FFFD-431B-8548-752912941B40@thomasclausen.org> <7A4D33C4-2176-4AC9-B978-296B92D95D1B@thomasclausen.org> From: Henning Rogge Date: Wed, 23 Jul 2014 13:03:47 +0200 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/D0q6ppiB32ZbyGaE8dopWd-u-yY Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Not just 5498 but also 5444 compliance 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, 23 Jul 2014 11:04:14 -0000 On Tue, Jul 22, 2014 at 6:49 PM, Thomas Clausen wrote: > With that being said....at some point, it would be fun to get you to come to an IETF, and present not a protocol, but exactly your parser/generator. Running code, and all that... The only thing I am sure about this is that it would not fit into a timeslot of the MANET WG meeting... *G* Henning Rogge From nobody Wed Jul 23 04:13:58 2014 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 6B14A1A02EC; Wed, 23 Jul 2014 04:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 3Adc1kTlOYdZ; Wed, 23 Jul 2014 04:13:54 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAC21A0028; Wed, 23 Jul 2014 04:13:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,716,1400022000"; d="scan'208";a="460119525" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Jul 2014 12:13:52 +0100 X-IronPort-AV: E=Sophos;i="5.01,716,1400022000"; d="scan'208";a="58749758" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 23 Jul 2014 12:13:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 12:14:00 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Toerless Eckert Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz80GmLKmbrSk6wiZoicSy84ZutZocAgAAaRdA= Date: Wed, 23 Jul 2014 11:13:59 +0000 Message-ID: References: <20140723100019.GK24330@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RNFk-VT8Oi0MrINKBZx5hW0Nylo Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 11:13:56 -0000 They can't always be retransmitted through the same interface, you may need= to use other interface(s) to reach the intended destinations. When flooding (as SMF) you would naturally flood through all interfaces. If= building a tree you need to ensure the tree has bidirectional branches. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 23 July 2014 11:37 To: Toerless Eckert Cc: MANET IETF; pim@ietf.org Subject: Re: [manet] manet: IP multicast comments ----------------------! 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. -------------------------------------------------------- On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > Having not followed Manet for a couple of years, and sat in yesterdays = > meeting, where there was a question about multicast, some questions = > and > comments: > > (1) It sounded to me as if every MANET solution support IP multicast = > flooding, but thats pretty much it ? What for example would be the = > solution for flooding when you use eg: OSPF with Manet extensions ? = > SMF ? I think one main difference with MANET is that you have a non-transitive ne= twork... just because that you can hear someone on interface X does not mea= n all your neighbors on interface X can hear this station. This means that multicast packets coming in through an interface typically = have to be retransmitted through the same interface again. I don't even know if there is any kind of kernel support for this kind of f= orwarding. Henning Rogge _______________________________________________ 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 Jul 23 04:34:15 2014 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 ED33A1A038A for ; Wed, 23 Jul 2014 04:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 3uFfDd2LYLwh for ; Wed, 23 Jul 2014 04:34:12 -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 1D5941A063B for ; Wed, 23 Jul 2014 04:34:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,716,1400022000"; d="scan'208";a="460127736" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Jul 2014 12:34:11 +0100 X-IronPort-AV: E=Sophos;i="5.01,716,1400022000"; d="scan'208";a="58753228" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 23 Jul 2014 12:34:18 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 12:34:18 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Justin Dean , "Thomas Heide Clausen (thomas@thomasclausen.org)" Thread-Topic: [manet] OLSRv2-Routed MANET Management Thread-Index: AQHPpdzowUV695COdUWI9Grrn1z07putamWAgAAYgoA= Date: Wed, 23 Jul 2014 11:34:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MXVK5EpbLeVqEcJNl1oNAB6ulQ8 Cc: "manet@ietf.org" Subject: Re: [manet] OLSRv2-Routed MANET Management 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, 23 Jul 2014 11:34:14 -0000 This needs care to extend the right things. Putting mixed address sized messages in a packet relates to the 5444 multip= lexer. This may be no more than an observation that the 5444 multiplexer al= ready permits that. (I don't think it's stressed, but if it weren't allowed= we'd have put the address length field in the packet header, not the messa= ge header). But there is an issue as to how the multiplexer handles a received packet w= ith IPv4 and IPv6 TCs. (If you can handle that, the sending side is easy.) = 5444 says that the multiplexer sends the TC to OLSRv2. It doesn't allow for= the possibility of there being more than one OLSRv2, whether easily separa= ted (by address length) or not. Even an easy separation is not a defined fe= ature. Which gives two possibilities that I see (a) Extend multiplexer to allow use of message address length as well as me= ssage type in deciding the destination of a message. This only handles that= special case, not a more general case of multiple instantiations of a prot= ocol. (b) TCs (any message length) are sent to "OLSRv2", which is allowed interna= l structure of separate instantiations, by address length or otherwise, of = 7181. This needs repeating for each protocol (obviously NHDP). If "or other= wise" is accepted, this can be a more general concept, but it's also rather= fuzzy. Also are the separate instantiations independent or not? Neither is entirely nice. It's one of those things easy to do in code, but = getting the model right in a draft is at least slightly tricky. I think it'= s worth a discussion on the issue, including the broader question of multip= le instantiations. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 23 July 2014 11:47 To: Justin Dean Cc: manet@ietf.org Subject: Re: [manet] OLSRv2-Routed MANET Management ----------------------! 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. -------------------------------------------------------- On Tue, Jul 22, 2014 at 8:43 PM, Justin Dean wrote: > Is the v4 and v6 thing true? Henning mentioned that his = > implementation uses both v4 and > v6 in the same packet but with different messages. To say that OLSRv2 = > can't do this without running multiple instances isn't 100% true. Yes, my implementation can transport both IPv4 TCs and IPv6 TCs within the = same RFC5444 packet. I am already working on a draft to present this "flooding optimization" mec= hanism to the WG. Henning Rogge _______________________________________________ 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 Jul 23 04:34:33 2014 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 F07D81A0944 for ; Wed, 23 Jul 2014 04:34:32 -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 X5UOP9KRZC5I for ; Wed, 23 Jul 2014 04:34:28 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B281A0A40 for ; Wed, 23 Jul 2014 04:34:27 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so7600709wib.10 for ; Wed, 23 Jul 2014 04:34:25 -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=5rkhwcBjCGNF9euoMhmiyxtbk3ZnPKQdisUFCI9Xd1U=; b=EERaPl23EskHIBFvKOWrY7D4EvYEwR6s0ntg7ZSJvvPK4HSBO+sTE7a3+8FgkzkY58 6eMCJhZQo31TO2fzLE/4eNztzIxsIdRGH9cGFvMVLYCdfbAyhAtnMLW7QUAb/0NgATbS q7Zxh2s2RCaFrygy5X0k4jk5/kjywudn0jHKaJPyTnwcS8FHFV3MSvkmegyzTKGDIvqk /PYLVOCXK7gpa3q0I4JUypDowxxZpujtfRB2GPP8unF4VisGi2abvg888iV5ECBkl+SB tEtIx5Y5syHO7FwOUTp2hNq6yJaXA8w8dX2l2CCUpYRUCHZAqVQLS85meGtolTCY0hoa 5eGg== MIME-Version: 1.0 X-Received: by 10.180.74.11 with SMTP id p11mr23744681wiv.68.1406115264319; Wed, 23 Jul 2014 04:34:24 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Wed, 23 Jul 2014 04:34:24 -0700 (PDT) In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> Date: Wed, 23 Jul 2014 13:34:24 +0200 Message-ID: From: Abdussalam Baryun To: "Snyder, Brian" Content-Type: multipart/alternative; boundary=f46d043891c3d7d62904fedab8c0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OVqww2NOyd24pyT8vM89DweDrXk Cc: "manet@ietf.org" Subject: Re: [manet] BFD Proxy Idea 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, 23 Jul 2014 11:34:33 -0000 --f46d043891c3d7d62904fedab8c0 Content-Type: text/plain; charset=UTF-8 Hi Brian. I think your use case may be different than DLEP use case but can use it. Comments below; On Wed, Jul 23, 2014 at 5:21 AM, Snyder, Brian wrote: > Stan, Thomas, & All, > > First let me try and explain my use case a bit better, as it's probably > not the typical network designers had in mind... > > I have been very involved with designing and prototyping a layer 2 sat > based product offering. As we transition away from "typical" L3 network > architecture our next logical step has been for some time to get into > RAR/DLEP/ETC to better optimize L3 routing convergence over the satellite > for our customers. That is good for Sat Nets to use L2 products; and to use DLEP is suitable which was discussed before by authors in previous meeting (I think in IETF 86 or 87). > The main idea being to allow them to tune down their L3 "HELLOS" and try > and drive a more event driven model to conserver very expensive satellite > bandwidth (while keeping decent convergence times). Hellos/signallings can be reduced within the routing discovery or in the NHDP as in Sat Nets usually the links are connected in longer times because of large/LOS coverage. (Did I understand your use case). > We know there would be a ton of demand for this if we can solve this > particular radio link - router optimization (faster convergence of Layer 3 > CE devices behind the modems and hub), which is exactly what DLEP is for.. > but my network architecture is hub and spoke, not mesh. The scalability of > the spokes is simple - they just need 1 DLEP and ROUTING peer - the hub. > However, the hub radio will terminate (and represent via DLEP to upstream > router) potentially thousands of spokes. > The DLEP works fine with this I think but I am not sure with the problem of termination; why terminated at hub. > > DLEP seems like a perfect match from everything I've read. but in many > ways it seems more complicated than is necessary for my use case. For > instance, it would be ideal for me to simply be able to set interfaces > logically down, yet NOT have to have a routing protocol specifically tied > in (like BFD). DLEP is not tied to one routing protocol otherwise it will not be flexible. > That way I don't have to force any particular network architecture on my > customers.... afterall, the main reason we are going L2 is to be > transparent. Yes DLEP is transparent too. > That ideal loses some steam if I then have to force very narrow routing > options on them when in L3 mode they have more choices. I don't want the > congestion/route control features necessarily (for now that is overkill to > me), but I would love to be able to easily set peers or links "down" to > immediately converge routing tables as a Modem falls out (or reenters) the > network. Thus avoiding all L3 timers. Essentially I'd like to pull a > virtual Ethernet plug. > > The added functionality is great, and potentially useful down the road, > but the downside then is that it requires OSPF or EIGRP. Preferably, I > wouldn't care if a customer wanted BGP or RIP, etc. if I could logically > set the interface down via Radio control messages then all my > timing/convergence problems would be solved. Is there a simpler way of > doing this within the confines of DLEP? As stated above, the hub side has > additional complexity as it will aggregate for potentially thousands of > modems. In Sat Net hub does not need thousands modems it already has its multiple access multiplexing should be solved by L2 not by DLEP or any other product. > > > So I fully admit, that I am not sure I'm understanding it all correctly, > and I've only played with Cisco's implementation so I very well may > (probably likely) have my lines blurred between the standard that DLEP > defines and exactly what is practically implemented and available to use .. > This is likely throwing my understanding of the standard off.. but when I > looked at it a few months ago (before I ended up going down the BFD route) > I was concerned that I would need thousands of virtual interfaces at the > upstream router and I knew that wouldn't scale. The routers work for L3 not in L2 so your new product needs to stay in L2 as you first mentioned before. I still think DLEP is suitable for your case may be DLEP authors can advise better than me. > This sheer # of virtual of interfaces would also cascade into multicast > issues (My hub link is a broadcast medium and I can't have packets > replicated). In Sat Net the broadcasting or multicasting using the hub interfaces issues should be solved in the L2 and not in L3. Multicast between routers are done in L3. However; the extension that Rick is doing for DLEP for L3 may help in your alternative solutions and that will mean you change your choice to a L3 product. > Also, AFAIK, supporting VLAN with this model is not an option. Perhaps > one could setup multiple neighbors to each router via DLEP using multiple > interfaces per VLAN per modem - but that would just make the scaling even > worse - by an order of magnitude (we expect 10 to 12 vlans per modem). > Alternatively, and ideally, we could support the notion of VLAN trunking > into the DLEP interface but I don't think that's currently supported, > (again though, that could just be a limitation of the VMI design in cisco's > implementation). > > BFD it turns out removes a lot of these concerns - but it's significantly > chattier - which is why I came up with the proxy idea, since as Rick > eloquently stated - I have some radio magic I can rely on for link state - > I think because it works on interfaces and doesn't require all the VMI > stuff, it just seems to scale better. BUT (big but) it's very chatty in > its own right and I can't have any link state information shared, which > would be ideal... > IMHO the BFD does not work well in your case or for MANET cases. > > Primarily, I feel I have a MANET problem/use case - and that if we think > about it (or I get more educated:) it should be solved within MANET > technologies..... I surprised myself at the end of this research to land > on BFD... I think because I'm proxying it, I've essentially created a > DLEP-light for router - radio link state notifications. > BFD is not for routing but DLEP is for routing. This WG is doing routing use cases but your problem may include other issues. > > I hope that explains some of my concerns and design issues with what I > currently have to work with. I'm sure I've made some bad assumptions - so > please have at me :) > I hope I undertood as well and I thank you for your presentation and ID which I will do my best to read while our WG is adopting many drafts with few reviews/discussions. AB --f46d043891c3d7d62904fedab8c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian. I think your use case=C2=A0may be=C2=A0different= than DLEP use case but can use it. Comments below;

On Wed, Jul 23, 2014 at 5:21 AM, Snyder, Brian <= span dir=3D"ltr"><bsnyder@idirect.net> wrote:
Stan, Thomas, & All,

First= let me try and explain my use case a bit better, as it's probably not = the typical network designers had in mind...

I have been very involved with designing and prototyping a layer 2 sat = based product offering. =C2=A0As we transition away from "typical"= ; L3 network architecture our next logical step has been for some time to g= et into RAR/DLEP/ETC to better optimize L3 routing convergence over the sat= ellite for our customers.
=C2=A0
That is good for Sat Nets to use L2 products; and to use DLEP is suita= ble which was discussed before by=C2=A0authors in previous meeting (I think= in IETF 86 or 87).
=C2=A0
=C2=A0
=C2=A0=C2=A0The main idea being to al= low them to tune down their L3 "HELLOS" and try and drive a more = event driven model to conserver very expensive satellite bandwidth (while k= eeping decent convergence times).=C2=A0
=C2=A0
Hellos/signallings can be reduced within the routing discovery or in t= he NHDP=C2=A0as in Sat Nets usually the links are connected in longer times= because of large/LOS coverage. (Did I understand your use case).
=C2=A0
=C2=A0We know there would be a ton of= demand for this if we can solve this particular radio link - router optimi= zation (faster convergence of Layer 3 CE devices behind the modems and hub)= , which is exactly what DLEP is for.. but my network architecture is hub an= d spoke, not mesh. =C2=A0The scalability of the spokes is simple - they jus= t need 1 DLEP and ROUTING peer - the hub. =C2=A0However, the hub radio will= terminate (and represent via DLEP to upstream router) potentially thousand= s of spokes.
=C2=A0
The DLEP works fine with this I think but I am not sure with the probl= em of termination; why terminated at hub.

DLEP seems like a perfect match f= rom everything I've read. but in many ways it seems more complicated th= an is necessary for my use case.=C2=A0 =C2=A0=C2=A0For instance, it would b= e ideal for me to simply be able to set interfaces logically down, yet NOT = have to have a routing protocol specifically tied in (like BFD).=C2=A0
=C2=A0
DLEP is not tied to one routing protocol otherwise it will not be flex= ible.
=C2=A0
That way I don't have to force an= y particular network architecture on my customers.... afterall, the main re= ason we are going L2 is to be transparent.
=C2=A0
Yes DLEP is transparent too.
=C2=A0
That ideal loses some steam if I then= have to force very narrow routing options on them when in L3 mode they hav= e more choices. =C2=A0I don't want the congestion/route control feature= s necessarily (for now that is overkill to me), but I would love to be able= to easily set peers or links "down" to immediately converge rout= ing tables as a Modem falls out (or reenters) the network.=C2=A0 Thus avoid= ing all L3 timers.=C2=A0 Essentially I'd like to pull a virtual Etherne= t plug.

The added functionality is great, and potentially useful down the road,= but the downside then is that it requires OSPF or EIGRP.=C2=A0 Preferably,= I wouldn't care if a customer wanted BGP or RIP, etc. if I could logic= ally set the interface down via Radio control messages then all my timing/c= onvergence problems would be solved.=C2=A0 Is there a simpler way of doing = this within the confines of DLEP?=C2=A0 As stated above, the hub side has a= dditional complexity as it will aggregate for potentially thousands of mode= ms.=C2=A0
=C2=A0
In Sat Net hub does not need thousands modems it already has its multi= ple access multiplexing should be solved by L2 not by DLEP or any other pro= duct.
=C2=A0
=C2=A0

So I fully admit, that = I am not sure I'm understanding it all correctly, and I've only pla= yed with Cisco's implementation so I very well may (probably likely) ha= ve my lines blurred between the standard that DLEP defines and exactly what= is practically implemented and available to use .. This is likely throwing= my understanding of the standard off.. but when I looked at it a few month= s ago (before I ended up going down the BFD route) I was concerned that I w= ould need thousands of virtual interfaces at the upstream router and I knew= that wouldn't scale.=C2=A0=C2=A0
=C2=A0
The routers work for L3 not in L2 so your new product needs to stay in= L2 as you first mentioned before. I still think DLEP is suitable for your = case may be DLEP authors can advise better than me.
=C2=A0
This sheer # of virtual of interfaces= would also cascade into multicast issues (My hub link is a broadcast mediu= m and I can't have packets replicated).=C2=A0
=C2=A0
In Sat Net the broadcasting or multicasting using the hub interfaces i= ssues=C2=A0should be solved in the L2 and not in L3. Multicast between rout= ers are done in L3. However; the extension that Rick is doing for DLEP for = L3 may help in your alternative solutions and that will mean you change you= r choice to a L3 product.
=C2=A0
=C2=A0Also, AFAIK, supporting VLAN wi= th this model is not an option. =C2=A0Perhaps one could setup multiple neig= hbors to each router via DLEP using multiple interfaces per VLAN per modem = - but that would just make the scaling even worse - by an order of magnitud= e (we expect 10 to 12 vlans per modem). =C2=A0Alternatively, and ideally, w= e could support the notion of VLAN trunking into the DLEP interface but I d= on't think that's currently supported, (again though, that could ju= st be a limitation of the VMI design in cisco's implementation).

BFD it turns out removes a lot of these concerns - but it's signifi= cantly chattier - which is why I came up with the proxy idea, since as Rick= eloquently stated - I have some radio magic I can rely on for link state -= I think because it works on interfaces and doesn't require all the VMI= stuff, it just seems to scale better. =C2=A0BUT (big but) it's very ch= atty in its own right and I can't have any link state information share= d, which would be ideal...
=C2=A0
IMHO the BFD does not work well in your case or for MANET cases.
=C2=A0

Primarily, I feel I have a MANET = problem/use case - and that if we think about it (or I get more educated:) = it should be solved within MANET technologies..... =C2=A0I surprised myself= at the end of this research to land on BFD... I think because I'm prox= ying it, I've essentially created a DLEP-light for router - radio link = state notifications.
=C2=A0
BFD is not for routing but DLEP is for routing. This WG is doing routi= ng use cases but your problem may include other issues.
=C2=A0

I hope that explains some of my c= oncerns and design issues with what I currently have to work with. =C2=A0I&= #39;m sure I've made some bad assumptions - so please have at me :)
=C2=A0
I hope I undertood as well and I thank you for your presentation and I= D which I will do my best to read while our WG is=C2=A0adopting=C2=A0many d= rafts with few reviews/discussions.
=C2=A0
=C2=A0
AB
--f46d043891c3d7d62904fedab8c0-- From nobody Wed Jul 23 04:42:32 2014 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 A76511A064E for ; Wed, 23 Jul 2014 04:42: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 byy9zdKkAd9k for ; Wed, 23 Jul 2014 04:42:24 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FD81A0564 for ; Wed, 23 Jul 2014 04:42:23 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2028179wiv.15 for ; Wed, 23 Jul 2014 04:42: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:date:message-id:subject:from:to :cc:content-type; bh=Y44XDBrAoXDZHt7HTX3pSghpy/K2rp5+vA4semhLKxE=; b=oHnJu2EPJJbt/Y/eIAxnFa83qzGeUJLmPFtqOryprtza+cEQ9KUQT0GQcUs0pkHOVo h7xwsNe4YwS7Ja7N2urKe3Fn114cSsXx7Nerx3SIjhrF5lHFbr9UkmJdlBWN9D0wPm8m Kh1gL86WR//cyE1OhTtbBElgIWTo+PNy5UJZtywqtkGDmAIu0mJfS6XyH/ysBDtoZG43 x9wEdSfd4nycxY4luGTwKIzvpoNrpfn6aDgW+zWDgxxIVAdt9bIRNkYpqc9Y3kvHOaII JtD2yHit2Y4qr/pDvwf3XjOR/vv7oXzTFT7Aq+FLnGySKx497KUGJ9UbXE+0Jdc+NdFJ 7K4A== MIME-Version: 1.0 X-Received: by 10.194.158.164 with SMTP id wv4mr1029093wjb.124.1406115740517; Wed, 23 Jul 2014 04:42:20 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Wed, 23 Jul 2014 04:42:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jul 2014 13:42:20 +0200 Message-ID: From: Abdussalam Baryun To: Justin Dean Content-Type: multipart/alternative; boundary=089e013c62623a08ed04fedad58b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4K5-iYgP9dSrc2PE-08zCC5dRuI Cc: "manet@ietf.org" Subject: Re: [manet] OLSRv2-Routed MANET Management 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, 23 Jul 2014 11:42:28 -0000 --089e013c62623a08ed04fedad58b Content-Type: text/plain; charset=UTF-8 I did ask th authors about the C issue and I still not sure how can one constant only can manage to make the protocol managed. However thanks for your input and discussion. AB On Tue, Jul 22, 2014 at 8:43 PM, Justin Dean wrote: > While only C is required to be the same and many settings can change > autonomously without breaking the protocol that isn't the same thing as the > protocol working well in those > scenarios. The key thing is that management doesn't need to happen across > ALL routers at the same time which makes management quite a bit easier. > > Is the v4 and v6 thing true? Henning mentioned that his implementation > uses both v4 and > v6 in the same packet but with different messages. To say that OLSRv2 > can't do this > without running multiple instances isn't 100% true. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --089e013c62623a08ed04fedad58b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I did ask th authors about the C issue and I still no= t sure how can one constant only can manage to make the protocol managed. H= owever thanks for your input and discussion.
=C2=A0
AB

On Tue, Jul 22, 2014 at 8:43 PM, Justin Dean <bebemaster@gmail.com> wrote:
While only C is required to be the same and many settings can change a= utonomously without breaking the protocol that isn't the same thing as = the protocol working well in those=C2=A0
scenarios. The key thing is that management doesn't need to happen= across ALL routers at the same time which makes management quite a bit eas= ier.

Is the v4 and v6 thing true? =C2=A0Henning mentioned that his implemen= tation uses both v4 and=C2=A0
v6 in the same packet but with different messages. =C2=A0To say that O= LSRv2 can't do this=C2=A0
without running multiple instances isn't 100% true.
_______________________________________________
manet mailing list
<= a href=3D"mailto:manet@ietf.org">manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


--089e013c62623a08ed04fedad58b-- From nobody Wed Jul 23 04:44:22 2014 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 AACC71A0AA4 for ; Wed, 23 Jul 2014 04:44:18 -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 LNWMi-SBVa-d for ; Wed, 23 Jul 2014 04:44:16 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96181A059F for ; Wed, 23 Jul 2014 04:44:16 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so1213114qge.30 for ; Wed, 23 Jul 2014 04:44: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:content-transfer-encoding; bh=cUUxJTy5uNtigF4cJeSvbKjU2pQIohUxiGCCngjpsvk=; b=cLW+g0hG6KGVvzF2Yt7mtf4BEhASMC1pmiDAueIU7SGCO2nveknrD7lquQ56B4kSc/ Xh8OoGcbJX9dUum1kdgytPqsA8ZImQ89DOPKiI3uRTttY+bG+sQbMlxuY1RFlB9VW1yh loxaxVdSdWLTVUBdIG1G4cdAWHGcNMjS5SAmjZ3zAUOQR6uL7N9FfSRupXW8hw5WDPd/ jnqogMdB0BEhUsEz/vnas3A56UnyFgCnkNFjE2fkNapTEKVyIAbdLROWVEXUT4fv6c0X d52CnZK4xf7sp+mbFYZ2I9cZ7M6FcQmvhqkxzlFBJeZ31RxLiwdFP+MhDbTyQ0bDg00A FxVQ== X-Received: by 10.224.138.8 with SMTP id y8mr1367889qat.38.1406115855276; Wed, 23 Jul 2014 04:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 04:43:55 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 23 Jul 2014 13:43:55 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yEAovsOk8eJ1D5glcc4n2dQjwTk Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] OLSRv2-Routed MANET Management 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, 23 Jul 2014 11:44:18 -0000 On Wed, Jul 23, 2014 at 1:34 PM, Dearlove, Christopher (UK) wrote: > This needs care to extend the right things. > > Putting mixed address sized messages in a packet relates to the 5444 mult= iplexer. This may be no more than an observation that the 5444 multiplexer = already permits that. (I don't think it's stressed, but if it weren't allow= ed we'd have put the address length field in the packet header, not the mes= sage header). Sure. > But there is an issue as to how the multiplexer handles a received packet= with IPv4 and IPv6 TCs. (If you can handle that, the sending side is easy.= ) 5444 says that the multiplexer sends the TC to OLSRv2. It doesn't allow f= or the possibility of there being more than one OLSRv2, whether easily sepa= rated (by address length) or not. Even an easy separation is not a defined = feature. > > Which gives two possibilities that I see > (a) Extend multiplexer to allow use of message address length as well as = message type in deciding the destination of a message. This only handles th= at special case, not a more general case of multiple instantiations of a pr= otocol. > (b) TCs (any message length) are sent to "OLSRv2", I implemented option (b). > which is allowed internal structure of separate instantiations, by addres= s length or otherwise, of 7181. This needs repeating for each protocol (obv= iously NHDP). If "or otherwise" is accepted, this can be a more general con= cept, but it's also rather fuzzy. Also are the separate instantiations inde= pendent or not? Keeping the two parts mostly separated might be the easiest way to implement it. I have chosen to put everything within the same data structure. So in dualstack mode I see all routers twice in the database (once IPv4 and once IPv6), with a cross reference because of my dualstack optimization (my implementation knows which IPv4 originator is which IPv6 originator). Henning Rogge From nobody Wed Jul 23 04:54:09 2014 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 6FBF51A009E; Wed, 23 Jul 2014 04:54:07 -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 vX3I_kez2bnM; Wed, 23 Jul 2014 04:54:06 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0DE1A008C; Wed, 23 Jul 2014 04:54:05 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so1047216wgg.7 for ; Wed, 23 Jul 2014 04:54:04 -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=cEAn4nj4ickosFjzqv+1dHf3WsD9uEsslzsfP10Nq8M=; b=FyEp/pFB+np56OjPI036Ei4ef2DOyP4i7lgQUC/EosvtA55Bdtg/TBX9WsQi/JhmKN JWMYFWCOLKhvGdJT5AlYCP74P9140L+VLVwSRM0knveUbFghTTWIq50RCrmTl8CvIxpn 11jklEj4vNysScBRI2Z4EgUzuuFbGzXt8GxZA7qjeuGdOrcD+OqZ/s2j2v3F+Rvl3jlG b7Gxda9BvMinNMyCqJs7JuDonCgDID8Q1SqnDJbcR8QVoN/wisOYgV7FvznWWz6UlvyT y/0A8nlAwltpger5biJQj4xyv9rJjl815q96dxt2pfn1IzVALyC8432zEa7DVLNVmqse +SjQ== MIME-Version: 1.0 X-Received: by 10.180.81.103 with SMTP id z7mr23830325wix.23.1406116444096; Wed, 23 Jul 2014 04:54:04 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Wed, 23 Jul 2014 04:54:03 -0700 (PDT) In-Reply-To: <20140723100019.GK24330@cisco.com> References: <20140723100019.GK24330@cisco.com> Date: Wed, 23 Jul 2014 13:54:03 +0200 Message-ID: From: Abdussalam Baryun To: Toerless Eckert Content-Type: multipart/alternative; boundary=f46d044288cc29cf3604fedaffbe Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rwL2G0RMtaXuza4QBkyTSKrogMM Cc: manet@ietf.org, pim@ietf.org Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 11:54:07 -0000 --f46d044288cc29cf3604fedaffbe Content-Type: text/plain; charset=UTF-8 On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > > (2b) The routing ADs seem to be running around trying to do > load-balancing of work across WGs, so it might be feasible to > proceed with eg: protocol work for manet compatible IP multicast > in the IP Multicast WG (currently called PIM). From what i > could glean from Alias statements yesterday in PIM WG, they > where primarily thinking of bringing MPLS multicast over to the > Multicast WG, but i think one may want to consider Manet > multicast as well. Nevertheless, see (2a), use-cases should > IMHO be really owned by Manet-WG itself. > The multicast routings in MANET is very different than PIM and MPLS. They have very very different use cases. So I support that the WG works on manet multicast protocols after finishing unicast protocols. As we can now start working on a proactive multicast protocol as we finished OLSRv2. Reactive multicast should not be started/adopted until we do our AODVv2. AB --f46d044288cc29cf3604fedaffbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
On Wed, Jul 23, 2014 at 12:00 PM, Toerless Ecker= t <eckert@cisco.com> wrote:

(2b) The routing ADs seem to be r= unning around trying to do
load-balancing of work across WGs, so it migh= t be feasible to
proceed with eg: protocol work for manet compatible IP multicast
in the = IP Multicast WG (currently called PIM). From what i
could glean from Ali= as statements yesterday in PIM WG, they
where primarily thinking of brin= ging MPLS multicast over to the
Multicast WG, but i think one may want to consider Manet
multicast as we= ll. Nevertheless, see (2a), use-cases should
IMHO be really owned by Man= et-WG itself.
The multicast routings=C2=A0in MANET is very different than PIM and MP= LS. They have very very different use cases. So I support that the WG works= on manet multicast protocols after finishing unicast protocols. As we can = now start working on a proactive=C2=A0multicast protocol as we finished OLS= Rv2. Reactive multicast should not be started/adopted until we do our AODVv= 2.
=C2=A0
AB=C2=A0
=C2=A0
--f46d044288cc29cf3604fedaffbe-- From nobody Wed Jul 23 05:00:52 2014 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 58C6B1A0AF7; Wed, 23 Jul 2014 05:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 Vt1qb5Y33L_c; Wed, 23 Jul 2014 05:00:37 -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 1AB131A066C; Wed, 23 Jul 2014 05:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3660; q=dns/txt; s=iport; t=1406116837; x=1407326437; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=dLFGn66ekIXeLSUv09UasRKjqsAJAb43jeaUcPkbtMQ=; b=jsjI6vh71tQsIgkeffVQ0VyRZjMNXk088jjaZzyf1x8Pk5FtMLJx5MBF 3TKsJ9gYTfdRAVVYaU3Kq5l6KLYHl6D7MG4ajvotmv+44iyXh8sc9ePiD BE/Y5y6UaK5baT+Wg6uwFlI/Dk0W1XUEH3etdYAFKj/lLsFxZ/Lh0a1cN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALeiz1OtJA2D/2dsb2JhbABZgw5SV8deCodFAYEOFnaEAwEBAQMBAQEBLwEiGQMIBQcECxEBAwEBAQkeBw8FEx8DBg4TG4gfCA2/NxeOaQoHAQlCBQcGgyiBGAWKZ4NCjQMBlECDaB0vgQMGAxc X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="scan'208";a="342225788" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jul 2014 12:00:35 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6NC0Yuc019315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 12:00:34 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NC0XnF023670; Wed, 23 Jul 2014 05:00:33 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NC0XYv023669; Wed, 23 Jul 2014 05:00:33 -0700 Date: Wed, 23 Jul 2014 05:00:33 -0700 From: Toerless Eckert To: "Dearlove, Christopher (UK)" Message-ID: <20140723120033.GB17023@cisco.com> References: <20140723100019.GK24330@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/t0zEewtgwglzV_Cff91bf6VDhgA Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 12:00:43 -0000 On Wed, Jul 23, 2014 at 11:13:59AM +0000, Dearlove, Christopher (UK) wrote: > They can't always be retransmitted through the same interface, you may need to use other interface(s) to reach the intended destinations. > > When flooding (as SMF) you would naturally flood through all interfaces. Well, "natural" flooding outside of MANET wold not send back to the receiving interface. In Manet this seems to be necessary if the radio does not do that for you. > If building a tree you need to ensure the tree has bidirectional branches. Well, i thought unidirectional link adjacencies are potentially important to support. Likewise asymmetric links. Cheers Toerless > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge > Sent: 23 July 2014 11:37 > To: Toerless Eckert > Cc: MANET IETF; pim@ietf.org > Subject: Re: [manet] manet: IP multicast comments > > ----------------------! 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. > -------------------------------------------------------- > > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > > Having not followed Manet for a couple of years, and sat in yesterdays > > meeting, where there was a question about multicast, some questions > > and > > comments: > > > > (1) It sounded to me as if every MANET solution support IP multicast > > flooding, but thats pretty much it ? What for example would be the > > solution for flooding when you use eg: OSPF with Manet extensions ? > > SMF ? > > I think one main difference with MANET is that you have a non-transitive network... just because that you can hear someone on interface X does not mean all your neighbors on interface X can hear this station. > > This means that multicast packets coming in through an interface typically have to be retransmitted through the same interface again. > > I don't even know if there is any kind of kernel support for this kind of forwarding. > > Henning Rogge > > _______________________________________________ > 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. > ******************************************************************** > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From nobody Wed Jul 23 05:09:49 2014 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 4844E1A052E for ; Wed, 23 Jul 2014 05:09:47 -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 kh-vQgB3TiUD for ; Wed, 23 Jul 2014 05:09:45 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB961ABB2A for ; Wed, 23 Jul 2014 05:09:45 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p10so1078133wes.30 for ; Wed, 23 Jul 2014 05:09:44 -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=6vh8BErVBwHQ7aoh0M5UupQqE4hbK1ecrq2kCR1kYI0=; b=cHK8+o2LOgPugriEQp0o6sAJcDf2JQanRKUqnFQ3LH02RyRFhVMgswbQJBA2yGlc7S B8YFupqVxS2CQKl34sjVVjAMj7mCGiLyOoomar32qFCQkO/kVXHzvkFv9DnLN+OjCO42 zwVdq5BuRSW2P+gSUNTso2OUObp5rqx7QlmLPgNLkgKeKAjOwAmgOatmqYdvPT1B8wIn Me46n//vWJ+omfwRF8U/JeT0xEF3IHfTLxMSqtolBjpMI9mAqX/vviqtwgQMIkrtIHUN uMfHj2jwyYIqumuHnyp3GAdPR/mBNtlWCVf0SHWDKgybOcDU1gZNxa8vOPEcpCTxyAvq Claw== MIME-Version: 1.0 X-Received: by 10.180.86.199 with SMTP id r7mr2706758wiz.20.1406117383951; Wed, 23 Jul 2014 05:09:43 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Wed, 23 Jul 2014 05:09:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jul 2014 14:09:43 +0200 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: multipart/alternative; boundary=f46d044280b22eda3504fedb3744 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yVnGTjf16vOGxzySvc4zOI8oauc Cc: manet Subject: Re: [manet] About olsrv2-multipath, following the discussion on IETF90 meeting 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, 23 Jul 2014 12:09:47 -0000 --f46d044280b22eda3504fedb3744 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 23, 2014 at 11:56 AM, Jiazi YI wrote: > > o Source routing? > > The olsrv2-multipath uses IP source routing (loose source routing for > IPv4, RFC6553 for IPv6), so that it can be interoperable with OLSRv2 and > its other extensions (such as new metrics, multi-topology, etc.). > Theres nothing inherently preventing other mechanism for 'forcing traffic > along certain paths' -- for example, one could imagine setting up a > label-switched path for each path in a multi-path flow, if such was > desired. It might be a good idea for the next version of the I-D to > indicate this, although we do not have any operational experiences with > this. It might be an interesting expansion to the document, and to the > experiment it is to enable, to try to understand which other ways of > 'forcing traffic along certain paths' are valid. Adrian, thank you for > triggering those thoughts. > > I think you need to show more OLSRv2 use cases than show what does OLSR use of multipath or IP also we should not mention many other issues like multitopology (makes it worse). AB --f46d044280b22eda3504fedb3744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 23, 2014 at 11:56 AM, Jiazi YI <ietf= @jiaziyi.com> wrote:
=C2=A0
o Source routing?

The olsrv2-multipath uses IP source routing (loose source routing for = IPv4, RFC6553 for IPv6), so that it can be interoperable with OLSRv2 and it= s other extensions (such as new metrics, multi-topology, etc.).
Theres nothing inherently preventing other mechanism for 'forcing = traffic along certain paths' -- for example, one could imagine setting = up a label-switched path for each path in a multi-path flow, if such was de= sired. It might be a good idea for the next version of the I-D to indicate = this, although we do not have any operational experiences with this. It mig= ht be an interesting expansion to the document, and to the experiment it is= to enable, to try to understand which other ways of 'forcing traffic a= long certain paths' are valid. Adrian, thank you for =C2=A0triggering t= hose thoughts.=C2=A0
=C2=A0
=C2=A0
I think you need to show more=C2=A0OLSRv2 use cases than show what doe= s OLSR use of multipath or IP also we should not=C2=A0mention many other is= sues like multitopology (makes it worse).
=C2=A0
AB
--f46d044280b22eda3504fedb3744-- From nobody Wed Jul 23 05:17:28 2014 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 017FE1A0AC6 for ; Wed, 23 Jul 2014 05:17:27 -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 NcCJaCybqwgq for ; Wed, 23 Jul 2014 05:17:25 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7C21A0AC1 for ; Wed, 23 Jul 2014 05:17:25 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so1237622qgf.35 for ; Wed, 23 Jul 2014 05:17:24 -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=5TkGji7jTSn5zszL6ALwDSH9NL6SBtOhOBQvbVhI6n0=; b=n/HwLz/QuNWr7DY42HKlB4AVG7ZVTDi3lgsWQvtXQj0/omD09JzQVxcBqfuEDei5I4 ZVHa6T/jxbmu/cqM9iCMOYR9hJ4RQEB8rmXz25t/FBeFaphcJFGTzM5ZDgI3BskAJrCw wDnPSVWfn0pEV5m1GAcD+0XlX2f0iVQtE118M+mWfI88cYYfLCaGeGNRo5olheSvwPLH DASoKSgj4hCSffzVF8toHZkUOmgJ1f1nVzuErYa6soiGEOaiYdzHwZK3Xe2ifmleP+Dx 10fuW8LzO5XfjKJssi+DVlYC/AETl1Ym3Gcn8KXPSXyhVxeXeYXKn4uf9Ng2yPtC/Iwa W70Q== X-Received: by 10.224.129.201 with SMTP id p9mr1291512qas.75.1406117844650; Wed, 23 Jul 2014 05:17:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 05:17:04 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 23 Jul 2014 14:17:04 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uEc7aFSS84qaX1CFQCM-Sgc5TJU Cc: manet Subject: Re: [manet] About olsrv2-multipath, following the discussion on IETF90 meeting 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, 23 Jul 2014 12:17:27 -0000 On Wed, Jul 23, 2014 at 2:09 PM, Abdussalam Baryun wrote: > I think you need to show more OLSRv2 use cases than show what does OLSR use > of multipath or IP also we should not mention many other issues like > multitopology (makes it worse). I think you should work on the structure of this sentence, I am not sure what you mean. Henning Rogge From nobody Wed Jul 23 05:19:07 2014 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 D1EBD1B27A6 for ; Wed, 23 Jul 2014 05:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 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, SUBJ_AS_SEEN=1.461] 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 TjcJ8S-vlGAq for ; Wed, 23 Jul 2014 05:18:58 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337D21B27AF for ; Wed, 23 Jul 2014 05:18:58 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so2086045wib.10 for ; Wed, 23 Jul 2014 05:18:54 -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=Fnt4lMX40VlBpdYwD6iOQPwYZbHW4QpktC/XSLSVUM0=; b=B7GpvH3Py8SieuPSHq4eNY7efezkRxLVimYr1X3GIXvjEi1gdmdyZl8tyubiDPGl0k S43F+qf/+cTbWEeXFasHXZ2FoF6GI/PRRI4eAMnPL1jGUAw1S6d0KQliBr/O1KuDGCDX rY7canFHqo8DvvvaTLg3bz/zpJqhUnFjIkH8jBsmLDLDj5YCXayaqHAzOo4SHGCLDdvH Jjo2cdJTlK7AQgGHxsw5y+JWITCbuzFAFndgFiRsikCojhcddnw6E0eu+75fOoDRqBQF XvX0AhKrvzFebnPH/G8qIzdqEnZqB/i2+5p1Djvz87///daaPl9DqUS1MLdJu2MrDnCp Cavg== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr24220151wib.20.1406117934861; Wed, 23 Jul 2014 05:18:54 -0700 (PDT) Received: by 10.180.102.7 with HTTP; Wed, 23 Jul 2014 05:18:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jul 2014 14:18:54 +0200 Message-ID: From: Abdussalam Baryun To: Justin Dean Content-Type: multipart/alternative; boundary=f46d0444ec650513cd04fedb586b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9ZI3RejbF48v-y7W7LWCtybmys0 Cc: "manet@ietf.org" , Joe P Macker , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET action items (as seen by Justin Dean) 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, 23 Jul 2014 12:19:00 -0000 --f46d0444ec650513cd04fedb586b Content-Type: text/plain; charset=UTF-8 On Tue, Jul 22, 2014 at 10:35 PM, Justin Dean wrote: > Notes on action items coming out of the MANET working group meeting. (this > list is not exhaustive of the topics covered in the meeting) > > 1) A suggestion was made to ask Stan if dlep editing help would be > helpful. If yes who should that person(s) be? > > 2) What to do with the report MIB; Kill, finish, revise? > > 3) Request for WG adoption of SMF sec threat document was made. No one in > the room had read the draft, but there was positive room reaction to > adopting a document with this subject and no negative reaction as measured > by hum. Please read the draft and comment. > The WG should read the draft and discuss before adopting or humming and I hope the chairs consider the high volume of drafts to give me more time before their decisions. > > 4) Request for WG adoption of OLSRv2 sec threat document was made. No one > in the room had read the draft, but there was positive room reaction to > adopting a document with this subject and no negative reaction as measured > by hum. Please read the draft and comment. > I usual not only no read but no discussions. Discussions and reviews are more important than just reading with no work. > > 5) Ulrich volunteered to shepherd multi-topology draft. > There was not enough time for me to review this work but still will submit my review > > 6) Request for WG adoption of OLSRv2 multi-path for experimental status > was made. No one in the room had read the draft, there was mixed but > positive reaction as measured by hum. Please read the draft and comment. > I reject until we get time to review and do our priorities on other drafts. > > 7) Request for WG adoption of ODMRP was made. Discussion within the room > touched upon the charter and was generally positive to multicast work but > again charter. No hum was held. > I dont support adopting reactive multicast until we finish the reactive standard AB > > > Justin Dean > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d0444ec650513cd04fedb586b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 22, 2014 at 10:35 PM, Justin Dean <bebemaster@gmail.com> wrote:
Notes on action items coming out of the MANET working grou= p meeting. (this list is not exhaustive of the topics covered in the meetin= g)

1) A suggestion was made to ask Stan if dlep editing help would be hel= pful. If yes who should that person(s) be?

2) What to do with the re= port MIB; Kill, finish, revise?

3) Request for WG adoption of SMF se= c threat document was made. =C2=A0No one in the room had read the draft, bu= t there was positive room reaction to adopting a document with this subject= and no negative reaction as measured by hum. =C2=A0Please read the draft a= nd comment.
=C2=A0
The WG should read the draft and discuss before adopting or humming an= d I hope the chairs consider the high volume of drafts to give me more time= before their decisions.
=C2=A0

4) Request for WG adoption of OLSRv2 sec threat document was made.= =C2=A0No one in the room had read the draft, but there was positive room r= eaction to adopting a document with this subject and no negative reaction a= s measured by hum. Please read the draft and comment.
=C2=A0
I usual not only no read but no discussions. Discussions and reviews a= re more important than just reading with no work.
=C2=A0
=C2=A0

5) Ulrich volunteered to shepherd multi-topology draft.
<= /div>
=C2=A0
There was not enough time for me to review this work but still will su= bmit my review

6) Request for WG adoption of OLSRv2 multi-path for experimental s= tatus was made. =C2=A0No one in the room had read the draft, there was mixe= d but positive reaction as measured by hum. =C2=A0Please read the draft and= comment.
=C2=A0
I reject until we get time to review and do our priorities on other dr= afts.
=C2=A0
=C2=A0

7) Request for WG adoption of ODMRP was made. =C2=A0Discussion wit= hin the room touched upon the charter and was generally positive to multica= st work but again charter. No hum was held.
=C2=A0
I dont support adopting reactive multicast until we finish the reactiv= e standard
=C2=A0
AB


Justin Dean
=

_____________________________________________= __
manet mailing list
manet@ietf.or= g
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d0444ec650513cd04fedb586b-- From nobody Wed Jul 23 05:27:03 2014 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 3B96E1A0AFE; Wed, 23 Jul 2014 05:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 pVXTuSdmyQuU; Wed, 23 Jul 2014 05:27:00 -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 007B41A01D5; Wed, 23 Jul 2014 05:26:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,717,1400022000"; d="scan'208";a="388789007" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2014 13:26:58 +0100 X-IronPort-AV: E=Sophos;i="5.01,717,1400022000"; d="scan'208";a="65785970" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 23 Jul 2014 13:27:06 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 13:27:05 +0100 From: "Dearlove, Christopher (UK)" To: Toerless Eckert Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz80GmLKmbrSk6wiZoicSy84ZutZocAgAAaRdD///0fgIAAFkeQ Date: Wed, 23 Jul 2014 12:27:05 +0000 Message-ID: References: <20140723100019.GK24330@cisco.com> <20140723120033.GB17023@cisco.com> In-Reply-To: <20140723120033.GB17023@cisco.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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0ho2cXN8D_VVXVHPU1hXQN2bUP0 Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 12:27:02 -0000 Radios tend to behave the way physics demands, and we can't stop then doing= inconvenient things. Though if we are clever we can use what they do to ad= vantage. Every MANET protocol in the WG does not supported unidirectional links. Tha= t applies to NHDP, OLSRv2, SMF, AODVv2. Making a protocol work with unidire= ctional links is not straightforward, given that the sender doesn't know if= it's a 1-directional link, or a 0-directional link. Blind flooding is the = obvious exception that can take advantage of unidirectional links. --=20 Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Toerless Eckert [mailto:eckert@cisco.com]=20 Sent: 23 July 2014 13:01 To: Dearlove, Christopher (UK) Cc: Henning Rogge; MANET IETF; pim@ietf.org Subject: Re: [manet] manet: IP multicast comments ----------------------! 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. -------------------------------------------------------- On Wed, Jul 23, 2014 at 11:13:59AM +0000, Dearlove, Christopher (UK) wrote: > They can't always be retransmitted through the same interface, you may ne= ed to use other interface(s) to reach the intended destinations. >=20 > When flooding (as SMF) you would naturally flood through all interfaces. Well, "natural" flooding outside of MANET wold not send back to the receivi= ng interface. In Manet this seems to be necessary if the radio does not do = that for you. > If building a tree you need to ensure the tree has bidirectional branches= . Well, i thought unidirectional link adjacencies are potentially important t= o support. Likewise asymmetric links. Cheers Toerless > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group Communications,=20 > Networks and Image Analysis Capability BAE Systems Advanced Technology=20 > Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| Fax: +44 1245 242124=20 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=20 > Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales=20 > No: 1996687 >=20 >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge > Sent: 23 July 2014 11:37 > To: Toerless Eckert > Cc: MANET IETF; pim@ietf.org > Subject: Re: [manet] manet: IP multicast comments >=20 > ----------------------! WARNING ! ---------------------- This message ori= ginates from outside our organisation, either from an external partner or f= rom the internet. > Consider carefully whether you should click on any links, open any attach= ments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions= on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrot= e: > > Having not followed Manet for a couple of years, and sat in=20 > > yesterdays meeting, where there was a question about multicast, =20 > > some questions and > > comments: > > > > (1) It sounded to me as if every MANET solution support IP multicast=20 > > flooding, but thats pretty much it ? What for example would be the=20 > > solution for flooding when you use eg: OSPF with Manet extensions ? > > SMF ? >=20 > I think one main difference with MANET is that you have a non-transitive = network... just because that you can hear someone on interface X does not m= ean all your neighbors on interface X can hear this station. >=20 > This means that multicast packets coming in through an interface typicall= y have to be retransmitted through the same interface again. >=20 > I don't even know if there is any kind of kernel support for this kind of= forwarding. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or=20 > distribute its contents to any other person. > ******************************************************************** >=20 -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From nobody Wed Jul 23 05:28:33 2014 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 61D961B27D3; Wed, 23 Jul 2014 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.016 X-Spam-Level: X-Spam-Status: No, score=-13.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 pu4OY5B7qlO1; Wed, 23 Jul 2014 05:28:29 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65A31A0B05; Wed, 23 Jul 2014 05:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1643; q=dns/txt; s=iport; t=1406118509; x=1407328109; h=date:from:to:cc:subject:message-id:mime-version: in-reply-to; bh=2g9wT8+k/Zu7l+wpumdXhaphlwfX/rZKuhvjQZI/aaU=; b=lIdp9NxdKDpSB8FawkOdGw5W54N510lj9zv9NkeqXld2WfqwUE0ylLfG Xz641Il8+uB4iVx9lQodM0BHjBj4VPhDnh44ueTWRgkgVFH1NNv40FMAD t+IHNqqmh+nNzeHdxiwuSM2IwWnCU3DIyAxOUo4og+/GnP17nXFjjqzQt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAG2pz1OtJA2H/2dsb2JhbABZgw6BKc8tAYELFnaEAwEBAQMBOj8FFhIGCTQFNRQTiDoIv14XjnoBAU8Hgy6BGAWKZ5BFAZRAg2gdL4EM X-IronPort-AV: E=Sophos;i="5.01,717,1400025600"; d="scan'208";a="63304529" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP; 23 Jul 2014 12:28:28 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6NCSRD3014686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 12:28:28 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NCSRox025652; Wed, 23 Jul 2014 05:28:27 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NCSQdu025651; Wed, 23 Jul 2014 05:28:26 -0700 Date: Wed, 23 Jul 2014 05:28:26 -0700 From: Toerless Eckert To: Abdussalam Baryun Message-ID: <20140723122826.GC17023@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LpSoHvfeN5cODvudOxMjDNi7cfo Cc: manet@ietf.org, pim@ietf.org Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 12:28:30 -0000 On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote: > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > > > > > (2b) The routing ADs seem to be running around trying to do > > load-balancing of work across WGs, so it might be feasible to > > proceed with eg: protocol work for manet compatible IP multicast > > in the IP Multicast WG (currently called PIM). From what i > > could glean from Alias statements yesterday in PIM WG, they > > where primarily thinking of bringing MPLS multicast over to the > > Multicast WG, but i think one may want to consider Manet > > multicast as well. Nevertheless, see (2a), use-cases should > > IMHO be really owned by Manet-WG itself. > > > The multicast routings in MANET is very different than PIM and MPLS. Can you remember if that reasoning was ever brought before PIM WG ? > They have very very different use cases. Adio/Video conferencing ? Sensoric (telemtry) data flooding ? I'd be surprised if the use cases turn out to be justifying difference in architecture. If at all, its the mobility. > So I support that the WG works on manet > multicast protocols after finishing unicast protocols. As we can now start > working on a proactive multicast protocol as we finished OLSRv2. Reactive > multicast should not be started/adopted until we do our AODVv2. Any specific reasons to go first with a proactive protocol ? Btw: It would really be good as i said in anothrer mail to evaluate the applicability of SSM to the use cases because that allows for the most simple proactive tree building. Cheers Toerless From nobody Wed Jul 23 05:35:01 2014 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 9082C1A0B05; Wed, 23 Jul 2014 05:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 nG9ma8DvyjIF; Wed, 23 Jul 2014 05:34:57 -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 1E24A1B2858; Wed, 23 Jul 2014 05:34:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,717,1400022000"; d="scan'208";a="460155514" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Jul 2014 13:34:55 +0100 X-IronPort-AV: E=Sophos;i="5.01,717,1400022000"; d="scan'208";a="58763607" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 23 Jul 2014 13:35:02 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 13:35:03 +0100 From: "Dearlove, Christopher (UK)" To: Toerless Eckert , Abdussalam Baryun Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz80GmLKmbrSk6wiZoicSy84ZutfBqAgAAJnACAABHZQA== Date: Wed, 23 Jul 2014 12:35:02 +0000 Message-ID: References: <20140723122826.GC17023@cisco.com> In-Reply-To: <20140723122826.GC17023@cisco.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: http://mailarchive.ietf.org/arch/msg/manet/ywpCU09Fjc52jpcy7qy2tG2OuP4 Cc: "manet@ietf.org" , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 12:34:59 -0000 It depends on whether one views multicast as something special to be done a= fter unicast, or something different. In the former case, as we have a unic= ast proactive protocol but not a reactive protocol, doing proactive multica= st first makes sense. In the latter case, not necessarily. Though there may= be an argument that the proactive network is ready - and the unicast routi= ng protocol has information to exploit. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: 23 July 2014 13:28 To: Abdussalam Baryun Cc: manet@ietf.org; pim@ietf.org Subject: Re: [manet] manet: IP multicast comments ----------------------! 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. -------------------------------------------------------- On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote: > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrot= e: > = > > > > (2b) The routing ADs seem to be running around trying to do = > > load-balancing of work across WGs, so it might be feasible to = > > proceed with eg: protocol work for manet compatible IP multicast in = > > the IP Multicast WG (currently called PIM). From what i could glean = > > from Alias statements yesterday in PIM WG, they where primarily = > > thinking of bringing MPLS multicast over to the Multicast WG, but i = > > think one may want to consider Manet multicast as well. = > > Nevertheless, see (2a), use-cases should IMHO be really owned by = > > Manet-WG itself. > > > The multicast routings in MANET is very different than PIM and MPLS. Can you remember if that reasoning was ever brought before PIM WG ? > They have very very different use cases. Adio/Video conferencing ? Sensoric (telemtry) data flooding ? I'd be surprised if the use cases turn out to be justifying difference in a= rchitecture. If at all, its the mobility. > So I support that the WG works on manet multicast protocols after = > finishing unicast protocols. As we can now start working on a = > proactive multicast protocol as we finished OLSRv2. Reactive multicast = > should not be started/adopted until we do our AODVv2. Any specific reasons to go first with a proactive protocol ? Btw: It would really be good as i said in anothrer mail to evaluate the app= licability of SSM to the use cases because that allows for the most simple = proactive tree building. Cheers Toerless _______________________________________________ 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 Jul 23 05:38:37 2014 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 8DAB91B278C; Wed, 23 Jul 2014 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 3s9VUg2AanSB; Wed, 23 Jul 2014 05:38:32 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F711B278B; Wed, 23 Jul 2014 05:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4454; q=dns/txt; s=iport; t=1406119112; x=1407328712; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=Y8BkgiCyMvybZYdLxIJmFwSDpazXS5t+ndlyrp7Ksiw=; b=beUMir1hjw1DIbD3jzyk2qs5Mgeun6kNqeyEnEiyOTYjgajpDxLIoECc 9DH/Doz3NDtx0Sx5lHaRFDs+sR5X3mQ6kR31964SQ9H/vfyVCgDCd/ra4 jBumWQZUDjYo+0pKEtwwAKkYNqWwg3IUaEMdUeHI9XFvxFBNhvZvjJuBd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFOrz1OtJA2B/2dsb2JhbABZgw5SV8deCodFAYELFnaEAwEBAQMBAQEBLwEiGQMIDAQLEQEDAQEBCR4HDwUTHwMGDhOIOggNv1QXjmkKBgIBCEIFBwaDKIEYBYpnkEUBlECDaB0vgQM X-IronPort-AV: E=Sophos;i="5.01,717,1400025600"; d="scan'208";a="342014894" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jul 2014 12:38:16 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6NCcFNK022301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 12:38:15 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NCcDET026186; Wed, 23 Jul 2014 05:38:14 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NCcDNF026185; Wed, 23 Jul 2014 05:38:13 -0700 Date: Wed, 23 Jul 2014 05:38:13 -0700 From: Toerless Eckert To: "Dearlove, Christopher (UK)" Message-ID: <20140723123813.GD17023@cisco.com> References: <20140723122826.GC17023@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/WcHg1L46ZTWINLWEqj7PZo7x-xA Cc: "manet@ietf.org" , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 12:38:34 -0000 On Wed, Jul 23, 2014 at 12:35:02PM +0000, Dearlove, Christopher (UK) wrote: > It depends on whether one views multicast as something special to be done after unicast, or something different. In the former case, as we have a unicast proactive protocol but not a reactive protocol, doing proactive multicast first makes sense. In the latter case, not necessarily. Though there may be an argument that the proactive network is ready - and the unicast routing protocol has information to exploit. Thats an engineerings "reuse of code" argument. I was more thinking of use-case requirements. Reactive protocols tend to have problems delivering first packets reliably unless you go through additional hoops. Proactive protocols have problems avoiding unnecessary state and therefore have possible negative scaling impacts to the applications. Toerless > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: 23 July 2014 13:28 > To: Abdussalam Baryun > Cc: manet@ietf.org; pim@ietf.org > Subject: Re: [manet] manet: IP multicast comments > > ----------------------! 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. > -------------------------------------------------------- > > On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote: > > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > > > > > > > > (2b) The routing ADs seem to be running around trying to do > > > load-balancing of work across WGs, so it might be feasible to > > > proceed with eg: protocol work for manet compatible IP multicast in > > > the IP Multicast WG (currently called PIM). From what i could glean > > > from Alias statements yesterday in PIM WG, they where primarily > > > thinking of bringing MPLS multicast over to the Multicast WG, but i > > > think one may want to consider Manet multicast as well. > > > Nevertheless, see (2a), use-cases should IMHO be really owned by > > > Manet-WG itself. > > > > > The multicast routings in MANET is very different than PIM and MPLS. > > Can you remember if that reasoning was ever brought before PIM WG ? > > > They have very very different use cases. > > Adio/Video conferencing ? Sensoric (telemtry) data flooding ? > I'd be surprised if the use cases turn out to be justifying difference in architecture. If at all, its the mobility. > > > So I support that the WG works on manet multicast protocols after > > finishing unicast protocols. As we can now start working on a > > proactive multicast protocol as we finished OLSRv2. Reactive multicast > > should not be started/adopted until we do our AODVv2. > > Any specific reasons to go first with a proactive protocol ? > > Btw: It would really be good as i said in anothrer mail to evaluate the applicability of SSM to the use cases because that allows for the most simple proactive tree building. > > Cheers > Toerless > > _______________________________________________ > 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 Jul 23 05:56:54 2014 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 7DE591B27A5; Wed, 23 Jul 2014 05:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 YXdTfXND6pHH; Wed, 23 Jul 2014 05:56:49 -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 2E4BD1A0ADD; Wed, 23 Jul 2014 05:56:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,717,1400022000"; d="scan'208";a="388800730" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2014 13:56:44 +0100 X-IronPort-AV: E=Sophos;i="5.01,717,1400022000"; d="scan'208";a="65792304" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 23 Jul 2014 13:56:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 13:56:51 +0100 From: "Dearlove, Christopher (UK)" To: Toerless Eckert Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz80GmLKmbrSk6wiZoicSy84ZutfBqAgAAJnACAABHZQP//8OKAgAAUdhA= Date: Wed, 23 Jul 2014 12:56:51 +0000 Message-ID: References: <20140723122826.GC17023@cisco.com> <20140723123813.GD17023@cisco.com> In-Reply-To: <20140723123813.GD17023@cisco.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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3-nqPb2opw-mgjeqcKpAy_BZfDs Cc: "manet@ietf.org" , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 12:56:51 -0000 I think that was more than a reuse of code argument, and if that's all you = think it was, you've missed the point that it's about what networks might a= lready exist. But on your points, if there's already a proactive unicast pr= otocol, you've already committed to much of the state. I also wouldn't call= it unnecessary state, if it were unnecessary it wouldn't be collected. It'= s more a necessary evil to achieve your other objectives. --=20 Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Toerless Eckert [mailto:eckert@cisco.com]=20 Sent: 23 July 2014 13:38 To: Dearlove, Christopher (UK) Cc: Abdussalam Baryun; manet@ietf.org; pim@ietf.org Subject: Re: [manet] manet: IP multicast comments ----------------------! 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. -------------------------------------------------------- On Wed, Jul 23, 2014 at 12:35:02PM +0000, Dearlove, Christopher (UK) wrote: > It depends on whether one views multicast as something special to be done= after unicast, or something different. In the former case, as we have a un= icast proactive protocol but not a reactive protocol, doing proactive multi= cast first makes sense. In the latter case, not necessarily. Though there m= ay be an argument that the proactive network is ready - and the unicast rou= ting protocol has information to exploit. Thats an engineerings "reuse of code" argument. I was more thinking of use-case requirements. Reactive protocols tend to ha= ve problems delivering first packets reliably unless you go through additio= nal hoops. Proactive protocols have problems avoiding unnecessary state and= therefore have possible negative scaling impacts to the applications. Toerless > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group Communications,=20 > Networks and Image Analysis Capability BAE Systems Advanced Technology=20 > Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| Fax: +44 1245 242124=20 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace=20 > Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales=20 > No: 1996687 >=20 >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Toerless=20 > Eckert > Sent: 23 July 2014 13:28 > To: Abdussalam Baryun > Cc: manet@ietf.org; pim@ietf.org > Subject: Re: [manet] manet: IP multicast comments >=20 > ----------------------! WARNING ! ---------------------- This message ori= ginates from outside our organisation, either from an external partner or f= rom the internet. > Consider carefully whether you should click on any links, open any attach= ments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions= on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote: > > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wr= ote: > >=20 > > > > > > (2b) The routing ADs seem to be running around trying to do=20 > > > load-balancing of work across WGs, so it might be feasible to=20 > > > proceed with eg: protocol work for manet compatible IP multicast=20 > > > in the IP Multicast WG (currently called PIM). From what i could=20 > > > glean from Alias statements yesterday in PIM WG, they where=20 > > > primarily thinking of bringing MPLS multicast over to the=20 > > > Multicast WG, but i think one may want to consider Manet multicast as= well. > > > Nevertheless, see (2a), use-cases should IMHO be really owned by=20 > > > Manet-WG itself. > > > > > The multicast routings in MANET is very different than PIM and MPLS. >=20 > Can you remember if that reasoning was ever brought before PIM WG ? >=20 > > They have very very different use cases. >=20 > Adio/Video conferencing ? Sensoric (telemtry) data flooding ? > I'd be surprised if the use cases turn out to be justifying difference in= architecture. If at all, its the mobility. >=20 > > So I support that the WG works on manet multicast protocols after=20 > > finishing unicast protocols. As we can now start working on a=20 > > proactive multicast protocol as we finished OLSRv2. Reactive=20 > > multicast should not be started/adopted until we do our AODVv2. >=20 > Any specific reasons to go first with a proactive protocol ? >=20 > Btw: It would really be good as i said in anothrer mail to evaluate the a= pplicability of SSM to the use cases because that allows for the most simpl= e proactive tree building. >=20 > Cheers > Toerless >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or=20 > distribute its contents to any other person. > ******************************************************************** From nobody Wed Jul 23 06:01:50 2014 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 83EC61B2876; Wed, 23 Jul 2014 06:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 OgOcSuBgBJkH; Wed, 23 Jul 2014 06:01:48 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 5CD881B2849; Wed, 23 Jul 2014 06:01:47 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 23 Jul 2014 14:01:20 +0100 From: Rick Taylor To: Toerless Eckert , "Dearlove, Christopher (UK)" Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz4o8Gmx9Baj0uSrTWxqBdk+putfBqAgAAJnACAAAHYAIAAAOSAgAAV1hI= Date: Wed, 23 Jul 2014 12:56:22 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA64A@tss-server1.home.tropicalstormsoftware.com> References: <20140723122826.GC17023@cisco.com> , <20140723123813.GD17023@cisco.com> In-Reply-To: <20140723123813.GD17023@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/UP_8Fn9Q6B7GjIUvbljsvZG7xms Cc: "manet@ietf.org" , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 13:01:49 -0000 Toerless, et.al.,=0A= =0A= I think you might be talking yourself into writing an informational draft o= n 'MANET considerations for multicast in reference to the existing state of= the art'.=0A= =0A= I think we are all agreeing that PIM has done some very good work that thos= e of us in MANET are not aware of, but, as others have pointed out, the MAN= ET group believe there are specific considerations for multicast in MANETs.= =0A= =0A= I think analysis in this area is very necessary, before we start reinventin= g each other's work. Then it's just up to the AD's whether this happens in= MANET or PIM.=0A= =0A= Regards,=0A= Rick Taylor=0A= ________________________________________=0A= From: manet [manet-bounces@ietf.org] on behalf of Toerless Eckert [eckert@c= isco.com]=0A= Sent: 23 July 2014 13:38=0A= To: Dearlove, Christopher (UK)=0A= Cc: manet@ietf.org; pim@ietf.org=0A= Subject: Re: [manet] manet: IP multicast comments=0A= =0A= On Wed, Jul 23, 2014 at 12:35:02PM +0000, Dearlove, Christopher (UK) wrote:= =0A= > It depends on whether one views multicast as something special to be done= after unicast, or something different. In the former case, as we have a un= icast proactive protocol but not a reactive protocol, doing proactive multi= cast first makes sense. In the latter case, not necessarily. Though there m= ay be an argument that the proactive network is ready - and the unicast rou= ting protocol has information to exploit.=0A= =0A= Thats an engineerings "reuse of code" argument.=0A= =0A= I was more thinking of use-case requirements. Reactive protocols tend to=0A= have problems delivering first packets reliably unless you go through=0A= additional hoops. Proactive protocols have problems avoiding unnecessary=0A= state and therefore have possible negative scaling impacts to the applicati= ons.=0A= =0A= Toerless=0A= =0A= > --=0A= > Christopher Dearlove=0A= > Senior Principal Engineer, Information Assurance Group=0A= > Communications, Networks and Image Analysis Capability=0A= > BAE Systems Advanced Technology Centre=0A= > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK=0A= > Tel: +44 1245 242194 | Fax: +44 1245 242124=0A= > chris.dearlove@baesystems.com | http://www.baesystems.com=0A= >=0A= > BAE Systems (Operations) Limited=0A= > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK=0A= > Registered in England & Wales No: 1996687=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Toerless Eckert= =0A= > Sent: 23 July 2014 13:28=0A= > To: Abdussalam Baryun=0A= > Cc: manet@ietf.org; pim@ietf.org=0A= > Subject: Re: [manet] manet: IP multicast comments=0A= >=0A= > ----------------------! WARNING ! ---------------------- This message ori= ginates from outside our organisation, either from an external partner or f= rom the internet.=0A= > Consider carefully whether you should click on any links, open any attach= ments or reply.=0A= > Follow the 'Report Suspicious Emails' link on IT matters for instructions= on reporting suspicious email messages.=0A= > --------------------------------------------------------=0A= >=0A= > On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote:=0A= > > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wr= ote:=0A= > >=0A= > > >=0A= > > > (2b) The routing ADs seem to be running around trying to do=0A= > > > load-balancing of work across WGs, so it might be feasible to=0A= > > > proceed with eg: protocol work for manet compatible IP multicast in= =0A= > > > the IP Multicast WG (currently called PIM). From what i could glean= =0A= > > > from Alias statements yesterday in PIM WG, they where primarily=0A= > > > thinking of bringing MPLS multicast over to the Multicast WG, but i= =0A= > > > think one may want to consider Manet multicast as well.=0A= > > > Nevertheless, see (2a), use-cases should IMHO be really owned by=0A= > > > Manet-WG itself.=0A= > > >=0A= > > The multicast routings in MANET is very different than PIM and MPLS.=0A= >=0A= > Can you remember if that reasoning was ever brought before PIM WG ?=0A= >=0A= > > They have very very different use cases.=0A= >=0A= > Adio/Video conferencing ? Sensoric (telemtry) data flooding ?=0A= > I'd be surprised if the use cases turn out to be justifying difference in= architecture. If at all, its the mobility.=0A= >=0A= > > So I support that the WG works on manet multicast protocols after=0A= > > finishing unicast protocols. As we can now start working on a=0A= > > proactive multicast protocol as we finished OLSRv2. Reactive multicast= =0A= > > should not be started/adopted until we do our AODVv2.=0A= >=0A= > Any specific reasons to go first with a proactive protocol ?=0A= >=0A= > Btw: It would really be good as i said in anothrer mail to evaluate the a= pplicability of SSM to the use cases because that allows for the most simpl= e proactive tree building.=0A= >=0A= > Cheers=0A= > Toerless=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= > ********************************************************************=0A= > This email and any attachments are confidential to the intended=0A= > recipient and may also be privileged. If you are not the intended=0A= > recipient please delete it from your system and notify the sender.=0A= > You should not copy it or use it for any purpose nor disclose or=0A= > distribute its contents to any other person.=0A= > ********************************************************************=0A= =0A= _______________________________________________=0A= manet mailing list=0A= manet@ietf.org=0A= https://www.ietf.org/mailman/listinfo/manet=0A= From nobody Wed Jul 23 06:11:24 2014 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 D64191B28BE; Wed, 23 Jul 2014 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ljD6YxMPaAAv; Wed, 23 Jul 2014 06:11:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2E01B28AF; Wed, 23 Jul 2014 06:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7288; q=dns/txt; s=iport; t=1406121064; x=1407330664; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=Co+cHA9O4BlbqfM3ggh3O4FdyYF/p3DAe664W/PKWYY=; b=iViR6YQDTobsAzQuAlQrq4nrACl7oUXWT1kXaSABFricUIOTk7RZ6GW1 d/r8irBNu3peQyAVKRkomiLyz+7MulaN+5aOMJGjC/SOpJOOFrdh62QnY FxRVODXJFwT3F04TTrmlWoXUfeHQPikgdEdSBETsOV3tLswbUvomdKis3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAm0z1OtJV2P/2dsb2JhbABZgw5SV8dfCodFAYELFnaEAwEBAQMBAQEBLwEiGQMIBQcECxEBAwEBAQkeBw8FEx8DBg4TiDoIDb9rF45pCgYCAQhCBQcGgyiBGAWKZ5BFAZRAg2gdL4ED X-IronPort-AV: E=Sophos;i="5.01,717,1400025600"; d="scan'208";a="63325439" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 23 Jul 2014 13:10:58 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6NDAvBm013426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 13:10:57 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6NDAuZJ028067; Wed, 23 Jul 2014 06:10:56 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6NDAua7028041; Wed, 23 Jul 2014 06:10:56 -0700 Date: Wed, 23 Jul 2014 06:10:56 -0700 From: Toerless Eckert To: "Dearlove, Christopher (UK)" Message-ID: <20140723131056.GE17023@cisco.com> References: <20140723122826.GC17023@cisco.com> <20140723123813.GD17023@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/okiAXlwQjDQsEYcGm4cI5-Wcdv4 Cc: "manet@ietf.org" , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 13:11:16 -0000 On Wed, Jul 23, 2014 at 12:56:51PM +0000, Dearlove, Christopher (UK) wrote: > I think that was more than a reuse of code argument, and if that's all you think it was, you've missed the point that it's about what networks might already exist. Well, i read: If one views multicast as something special to be done after unicast, and unicast is proactive, then doing proactive multicast first makes sense. You didn't say whether this meant specs or deployment ;-) Be that as it may: In non-manet networks, we always only had proactive unicast, but that didn't stop us to do reactive and proactive multicast protocols, so i am not sure what deploymnet or spec benefits i could have with that reasoning - unless of course the multicast protocol is directly an extension of the unicast protocol. That was the line of thinking up until 1994 when folks figured it doesn't make a lot of sense trying to counterfit multicast into every IGP. > But on your points, if there's already a proactive unicast protocol, you've already committed to much of the state. I also wouldn't call it unnecessary state, if it were unnecessary it wouldn't be collected. It's more a necessary evil to achieve your other objectives. I as just talking about multicast state, not unicast state. Outside of Manet, there are not a lot of folks interested in reactive unicast routing. Cheers toerless > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Toerless Eckert [mailto:eckert@cisco.com] > Sent: 23 July 2014 13:38 > To: Dearlove, Christopher (UK) > Cc: Abdussalam Baryun; manet@ietf.org; pim@ietf.org > Subject: Re: [manet] manet: IP multicast comments > > ----------------------! 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. > -------------------------------------------------------- > > On Wed, Jul 23, 2014 at 12:35:02PM +0000, Dearlove, Christopher (UK) wrote: > > It depends on whether one views multicast as something special to be done after unicast, or something different. In the former case, as we have a unicast proactive protocol but not a reactive protocol, doing proactive multicast first makes sense. In the latter case, not necessarily. Though there may be an argument that the proactive network is ready - and the unicast routing protocol has information to exploit. > > Thats an engineerings "reuse of code" argument. > > I was more thinking of use-case requirements. Reactive protocols tend to have problems delivering first packets reliably unless you go through additional hoops. Proactive protocols have problems avoiding unnecessary state and therefore have possible negative scaling impacts to the applications. > > Toerless > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group Communications, > > Networks and Image Analysis Capability BAE Systems Advanced Technology > > Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > > Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales > > No: 1996687 > > > > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Toerless > > Eckert > > Sent: 23 July 2014 13:28 > > To: Abdussalam Baryun > > Cc: manet@ietf.org; pim@ietf.org > > Subject: Re: [manet] manet: IP multicast comments > > > > ----------------------! 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. > > -------------------------------------------------------- > > > > On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote: > > > On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert wrote: > > > > > > > > > > > (2b) The routing ADs seem to be running around trying to do > > > > load-balancing of work across WGs, so it might be feasible to > > > > proceed with eg: protocol work for manet compatible IP multicast > > > > in the IP Multicast WG (currently called PIM). From what i could > > > > glean from Alias statements yesterday in PIM WG, they where > > > > primarily thinking of bringing MPLS multicast over to the > > > > Multicast WG, but i think one may want to consider Manet multicast as well. > > > > Nevertheless, see (2a), use-cases should IMHO be really owned by > > > > Manet-WG itself. > > > > > > > The multicast routings in MANET is very different than PIM and MPLS. > > > > Can you remember if that reasoning was ever brought before PIM WG ? > > > > > They have very very different use cases. > > > > Adio/Video conferencing ? Sensoric (telemtry) data flooding ? > > I'd be surprised if the use cases turn out to be justifying difference in architecture. If at all, its the mobility. > > > > > So I support that the WG works on manet multicast protocols after > > > finishing unicast protocols. As we can now start working on a > > > proactive multicast protocol as we finished OLSRv2. Reactive > > > multicast should not be started/adopted until we do our AODVv2. > > > > Any specific reasons to go first with a proactive protocol ? > > > > Btw: It would really be good as i said in anothrer mail to evaluate the applicability of SSM to the use cases because that allows for the most simple proactive tree building. > > > > Cheers > > Toerless > > > > _______________________________________________ > > 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 Jul 23 07:39:05 2014 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 999381B2AB1 for ; Wed, 23 Jul 2014 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 qpAp7V44z6GU for ; Wed, 23 Jul 2014 07:38:55 -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 9B2EF1B2A6A for ; Wed, 23 Jul 2014 07:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9826; q=dns/txt; s=iport; t=1406126255; x=1407335855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=q1hkssTExxn6LuyBQjJaaRH6TYPVK+10geX8Ll47WP4=; b=dElMDvAGoamW4sjJD6oxqFtqUleS07qbKcUoaKRYEAvYWD06u4IU/ks1 eztBsSqTDQTKQnPCo60/7VEWJ7FPrEt1/mLpmenRfCrfoR9nhqY47e6Mr uZ/TzuxnUoKRY5RrpO/KcXu/3gHFG9XR2JV7Na+6MC/+1ErC+AGx07yVO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAL3Hz1OtJA2B/2dsb2JhbABZgw5SVwTHWwqHRQGBCxZ2hAMBAQEDAQEBAWsCCQULAgEIEQEDAQEBJwcnCxQDBggBAQQOBYg6CA3AIBMEiX6EaxEBHTMHgy6BGAEElw6EH5RAg0hsgQw5 X-IronPort-AV: E=Sophos;i="5.01,717,1400025600"; d="scan'208";a="63347678" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP; 23 Jul 2014 14:37:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6NEbYN5027170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 14:37:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 09:37:34 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] BFD Proxy Idea Thread-Index: Ac+mBFQ9JJUS9xvFSKGU/LtcZEhAWAALELQAAAefwQAAF52NgA== Date: Wed, 23 Jul 2014 14:37:33 +0000 Message-ID: References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="Windows-1252" Content-ID: <21289AAC7C280848BF6FA6F5AFB69424@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RLE0OCeTbedirTo7yAhd9IVXfk0 Cc: "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] BFD Proxy Idea 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, 23 Jul 2014 14:38:59 -0000 On Jul 22, 2014, at 11:21 PM, "Snyder, Brian" wrote: > Stan, Thomas, & All, >=20 > First let me try and explain my use case a bit better, as it's probably n= ot the typical network designers had in mind... >=20 > I have been very involved with designing and prototyping a layer 2 sat ba= sed product offering. As we transition away from "typical" L3 network arch= itecture our next logical step has been for some time to get into RAR/DLEP/= ETC to better optimize L3 routing convergence over the satellite for our cu= stomers. The main idea being to allow them to tune down their L3 "HELLOS" = and try and drive a more event driven model to conserver very expensive sat= ellite bandwidth (while keeping decent convergence times). We know there w= ould be a ton of demand for this if we can solve this particular radio link= - router optimization (faster convergence of Layer 3 CE devices behind the= modems and hub), which is exactly what DLEP is for.. but my network archit= ecture is hub and spoke, not mesh. The scalability of the spokes is simple= - they just need 1 DLEP and ROUTING peer - the hub. However, the hub radi= o will terminate (and represent via DLEP to upstream router) potentially th= ousands of spokes. =20 I could see implementing this type of architecture this way - At the spoke = modem, DLEP only reports the presence/absence of the hub. At the hub modem,= it would need to report presence/absence of all of the spokes as they come= and go.=20 >=20 > DLEP seems like a perfect match from everything I've read. but in many wa= ys it seems more complicated than is necessary for my use case. For inst= ance, it would be ideal for me to simply be able to set interfaces logicall= y down, yet NOT have to have a routing protocol specifically tied in (like = BFD). That way I don't have to force any particular network architecture o= n my customers.... afterall, the main reason we are going L2 is to be trans= parent. That ideal loses some steam if I then have to force very narrow rou= ting options on them when in L3 mode they have more choices. I don't want = the congestion/route control features necessarily (for now that is overkill= to me), but I would love to be able to easily set peers or links "down" to= immediately converge routing tables as a Modem falls out (or reenters) the= network. Thus avoiding all L3 timers. Essentially I'd like to pull a vir= tual Ethernet plug.=20 >=20 > The added functionality is great, and potentially useful down the road, b= ut the downside then is that it requires OSPF or EIGRP. Preferably, I woul= dn't care if a customer wanted BGP or RIP, etc. if I could logically set th= e interface down via Radio control messages then all my timing/convergence = problems would be solved. Is there a simpler way of doing this within the = confines of DLEP? As stated above, the hub side has additional complexity = as it will aggregate for potentially thousands of modems. =20 I think that's a case where you have crossed from the specification over to= Cisco's implementation. The DLEP spec doesn't mention any routing protocol= . From a DLEP perspective, we took the tack of saying "Let's figure out wha= t data items are important for a router and modem to communicate, and then = let's produce a protocol to fling them across the chasm between router and = modem." The issues of what to do with said data items (and what protocol or= protocols they should be fed into) is left to implementers. As for the cur= rent Cisco implementation, you are correct - BGP and RIP aren't supported. = That's not a DLEP spec issue, however.=20 >=20 > So I fully admit, that I am not sure I'm understanding it all correctly, = and I've only played with Cisco's implementation so I very well may (probab= ly likely) have my lines blurred between the standard that DLEP defines and= exactly what is practically implemented and available to use .. This is li= kely throwing my understanding of the standard off.. but when I looked at i= t a few months ago (before I ended up going down the BFD route) I was conce= rned that I would need thousands of virtual interfaces at the upstream rout= er and I knew that wouldn't scale. This sheer # of virtual of interfaces = would also cascade into multicast issues (My hub link is a broadcast medium= and I can't have packets replicated). Also, AFAIK, supporting VLAN with t= his model is not an option. Perhaps one could setup multiple neighbors to = each router via DLEP using multiple interfaces per VLAN per modem - but tha= t would just make the scaling even worse - by an order of magnitude (we exp= ect 10 to 12 vlans per modem). Alternatively, and ideally, we could suppor= t the notion of VLAN trunking into the DLEP interface but I don't think tha= t's currently supported, (again though, that could just be a limitation of = the VMI design in cisco's implementation). This could be a problem. As you state up front, the hub may have "thousands= of spokes". Again, it's not a DLEP specification issue - but from a DLEP p= erspective, you'll correspondingly have thousands of "Destinations" that ar= e up in that network, *each* with the potential of having a varying amount = of bandwidth. The question would be exactly how the attached router would g= o about dealing with that notion: would it do so using just a single interf= ace? Or multiple virtual interfaces? That falls into a specific implementat= ion's purview. >=20 > BFD it turns out removes a lot of these concerns - but it's significantly= chattier - which is why I came up with the proxy idea, since as Rick eloqu= ently stated - I have some radio magic I can rely on for link state - I thi= nk because it works on interfaces and doesn't require all the VMI stuff, it= just seems to scale better. BUT (big but) it's very chatty in its own rig= ht and I can't have any link state information shared, which would be ideal= =85 =20 Again, the "VMI stuff" you refer to is implementation-specific. I'd be happ= y to continue that part of the discussion with you (the implementation-spec= ific part), but not on this list=85 ;-) >=20 > Primarily, I feel I have a MANET problem/use case - and that if we think = about it (or I get more educated:) it should be solved within MANET technol= ogies..... I surprised myself at the end of this research to land on BFD..= . I think because I'm proxying it, I've essentially created a DLEP-light fo= r router - radio link state notifications. FWIW, I agree that you have a MANET use case. And as a completely, unabashe= dly, totally *BIASED* observer, I think DLEP addresses most (if not all) of= your needs=85 ;-) I think there are potentially some implementation issues= with the code you have. If you'd like to continue that implementation-spec= ific discussion, please let me know off-list. Regards, Stan >=20 > I hope that explains some of my concerns and design issues with what I cu= rrently have to work with. I'm sure I've made some bad assumptions - so pl= ease have at me :) >=20 > Side note: My observations are what I had in hand to work with, not neces= sarily what the draft says. I'm guessing this is poor form for IETF convers= ations, so apologies if I've crossed a line... I'm new here ;) Perhaps new= er DLEP drafts address some of these issues, and I just have to stick with = BFD until there are practical implementation I could try and integrate with= ..... It's my understanding the sourceforge reference implementation is ba= sed on draft-0 which is quite out-of-date already. >=20 > Thanks for reading this far, > Brian >=20 >=20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: Tuesday, July 22, 2014 7:43 PM > To: Snyder, Brian > Cc: manet@ietf.org > Subject: Re: [manet] BFD Proxy Idea >=20 > Dear Brian, > On 22 Jul 2014, at 19:35, "Snyder, Brian" wrote: > Everyone, > =20 > As I presented , I think the main problems I had in adopting DLEP were: > . Multicast support > . VLAN support > . Scalability > =20 >> From a radio point of view, I would like to get these issues addressed (= or at least discussed) so they can work their way into the DLEP definition.= =20 > =20 > Ideally, I could use DLEP, as it does have some advantages over BFD, to s= olve the problem I described. > =20 >=20 > I think that it would be a significant help if you could point out "how" = -- for dummies like me, who do not understand satcom very well ;) >=20 > Further, I think it would be interesting if we considered defining an abi= lity to use BFD to connect to a DLEP instance in order to manage the link u= p/down setting. This could be useful if one was using DLEP over virtual in= terfaces. >=20 > OK, this makes sense to me. > =20 >=20 > Finally, as I didn't quite get to finish my presentation due to time con= straints, I also wanted to mention that I would be here all week and would = be happy to have further conversation on my presentation if anyone was inte= rested. Please feel free to email me and we can pick a coffee spot to cont= inue talking. >=20 > To mix up (at least, two) metaphors, I have no dogs in this race -- but I= throughly enjoyed both your presentation and reading your I-D, which was p= articularly well written and easy to digest. >=20 > Cheers, >=20 > Thomas >=20 > =20 > Thanks, > Brian > _______________________________________________ > 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 Wed Jul 23 07:57:40 2014 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 BABB81B2887; Wed, 23 Jul 2014 07:57:38 -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 m1ODnIkt4EIw; Wed, 23 Jul 2014 07:57:33 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD331B287A; Wed, 23 Jul 2014 07:57:33 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so1495083qgd.26 for ; Wed, 23 Jul 2014 07:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CM7vKt7Cz+XvkDPpI1R465uFy7TXG1/RG8Ou/LWEht0=; b=KK4r5lytG1ZS42lNK2DHHQ74UESrgddDv8QAA8+6qAesjA36m9PlUHFQvQJDaHfT0M oi1TNiXcXbthEFNyrIkI8/k7DCdL8Fb79KAF1YLDT+H4EChCn/arZAIOtbku/4tAByLf gPe5zmIbh1zr8uxFWfa0voDA6SERUMjzb7+wxcxSrHM8LJgoKTiPgnu+fO69jCR3o8TB 2F5M3UAgmE06bdWs1MXhBa6GUYEdpnnU74HiLhInSHq5BEkvAQbtQ/bkVhCAsLiC5ojI N7CfcYHgUDBPPysb6DEXYpAa1rrW9jWc9JRc2T8dMg/5nLV8V6lMp5y5JT+NsebXjUb1 fquA== MIME-Version: 1.0 X-Received: by 10.140.29.138 with SMTP id b10mr2831026qgb.15.1406127451946; Wed, 23 Jul 2014 07:57:31 -0700 (PDT) Received: by 10.140.101.140 with HTTP; Wed, 23 Jul 2014 07:57:31 -0700 (PDT) In-Reply-To: <20140723100019.GK24330@cisco.com> References: <20140723100019.GK24330@cisco.com> Date: Wed, 23 Jul 2014 10:57:31 -0400 Message-ID: From: Joseph Macker To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a113a75a2484b5004fedd8fe8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wNuK9uXv_rQy6h6aQ5Quqy-Gzf4 Cc: "manet@ietf.org" , pim@ietf.org Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 14:57:38 -0000 --001a113a75a2484b5004fedd8fe8 Content-Type: text/plain; charset=UTF-8 Toerless: Thanks for your comments. Sorry rewinding the thread a bit for some historical perspective in case it helps. On Wed, Jul 23, 2014 at 6:00 AM, Toerless Eckert wrote: > Having not followed Manet for a couple of years, and sat in yesterdays > meeting, where there was a question about multicast, some questions and > comments: > > (1) It sounded to me as if every MANET solution support IP multicast > flooding, but thats pretty much it ? What for example would > be the solution for flooding when you use eg: OSPF with Manet > extensions ? SMF ? > Many moons ago the Manet WG rechartered to make more focused engineering progress in the unicast areas and optimized flooding areas. Years ago there used to be a slew of group-specific multicast discussions, work (both reactive and proactive), and proposals including SSM-related ones,etc. In the last several meetings there has been some revisiting of these older ideas with IDs ODMRP and adaptive multicast (adapts between flooding and path-optimization as convergence/reliability allows). Both of the newer IDs build off of progress made in other areas. Related to your other above question there have been successful live experiments with OSPF-Manet variants and SMF. Where SMF shared the optimized control plane info of OSPF-Manet, not saying this it the right thing to use in many deployments but its been demonstrated. Nonetheless, SMF is intended to be a limited application case design. > (2) There seemed to be some interest in working on BTF (Metter Than > Flooding) IP multicast protocols (a), but also (b) some concerns about > work overload that this might result in for manet. > I am perhaps less worried about workload but some have raised concerns about technical engineering maturity. I believe progress has been in some areas here over the years and there is room for this but if pursued it has to be scoped. > (2a) Is there any write down of use cases in Manet that require > such BTF IP multicast services with manet ? If yes, please provide > pointers, if not, i'd suggest that is the first thing to write down. > > I got the understanding that eg: the evolution from SA (situation > awareness == very low bitrate) as the prime use case to also > voice/video group communication is such a typical use case for BTF > multicast, but without it being written down and prioritized, it is > IMHO premature to proceed on protocol work. > > And there is a lot more than just prioritization of work to get > from the use cases details. For example, since 2000, we do have > in the IETF two IP multicast service models. The traditional > group-join one, we now call ASM (Any Source Multicast), and > SSM, where the application has to know the source IP address, > and includes it in IGMP membership reports. SSM simplifies > BTF solutions drastical. It also increases security (not > attacks by unwanted sources). So the use case analysis needs to > vet whether SSM is an appropriate service or not for the use > case. > Definitely good points before the "now old" rechartering these tradeoffs were discussed alot within the manet community.. There was also an "explicit group" multicast proposal as well as SSM discussions. At that time lots of manet people were also working with PIM solutions at least for gatewaying,etc. I think MANET includes a rich set of application needs and multicast is very important. Pub/sub data services, streaming services, control, discovery are potential examples. We do need to discuss the models, but also the convergence/reliability issues tend to dominate the manet /mesh specific tradeoff and design space as well as the potentially the need for support mechanisms (e.g., dup detection). So the specific design challenges are an important part of any design here. > (2b) The routing ADs seem to be running around trying to do > load-balancing of work across WGs, so it might be feasible to > proceed with eg: protocol work for manet compatible IP multicast > in the IP Multicast WG (currently called PIM). From what i > could glean from Alias statements yesterday in PIM WG, they > where primarily thinking of bringing MPLS multicast over to the > Multicast WG, but i think one may want to consider Manet > multicast as well. Nevertheless, see (2a), use-cases should > IMHO be really owned by Manet-WG itself. > Personally I have worked alot with variants of PIM in the past. Especially gatewaying to/from MANET type networks. It would be good to have more cross discussions. > Cheers > Toerless > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a113a75a2484b5004fedd8fe8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Toerless:

Thanks for your co= mments. Sorry rewinding the thread a bit for some historical perspective in= case it helps.

On Wed, Jul 23, 2014 at 6:00 AM, Toerless Eckert <eckert@cisco.com><= /span> wrote:
Having not followed Manet for a couple of years, and sat in yesterdays
meeting, where there was a question about multicast, =C2=A0some questions a= nd
comments:

(1) It sounded to me as if every MANET solution support IP multicast
flooding, but thats pretty much it ? What for example would
be the solution for flooding when you use eg: OSPF with Manet
extensions ? SMF ?

Many moons ago the M= anet WG rechartered to make =C2=A0more focused engineering progress in the = unicast areas and optimized flooding areas. Years ago there used to be a sl= ew of group-specific multicast discussions, work (both reactive and proacti= ve), =C2=A0and proposals including SSM-related ones,etc. In the last severa= l meetings there has been some revisiting of these older ideas with IDs ODM= RP and adaptive multicast (adapts between flooding and path-optimization as= convergence/reliability allows). =C2=A0Both of the newer IDs build off of = progress made in other areas.

Related to your other above question there have been su= ccessful live experiments with OSPF-Manet variants and SMF. =C2=A0Where SMF= shared the optimized control plane info of OSPF-Manet, not saying this it = the right thing to use in many deployments but its been demonstrated. =C2= =A0Nonetheless, SMF is intended to be a limited application case design.


(2) There seemed to be some interest in working on BTF (Metter Than
Flooding) IP multicast protocols (a), but also (b) some concerns about
work overload that this might result in for manet.
I am perhaps less worried about workload but some have raised c= oncerns about technical engineering maturity. =C2=A0I believe progress has = been in some areas here over the years and there is room for this but if pu= rsued it has to be scoped.


(2a) Is there any write down of use cases in Manet that require
such BTF IP multicast services with manet ? If yes, please provide
pointers, if not, i'd suggest that is the first thing to write down.
I got the understanding that eg: the evolution from SA (situation
awareness =3D=3D very low bitrate) as the prime use case to also
voice/video group communication is such a typical use case for BTF
multicast, but without it being written down and prioritized, it is
IMHO premature to proceed on protocol work.

And there is a lot more than just prioritization of work to get
from the use cases details. For example, since 2000, we do have
in the IETF two IP multicast service models. The traditional
group-join one, we now call ASM (Any Source Multicast), and
SSM, where the application has to know the source IP address,
and includes it in IGMP membership reports. SSM simplifies
BTF solutions drastical. It also increases security (not
attacks by unwanted sources). So the use case analysis needs to
vet whether SSM is an appropriate service or not for the use
case.

Definitely good points before the= "now old" rechartering these tradeoffs were discussed alot withi= n the manet community.. =C2=A0There was also an "explicit group" = multicast proposal as well as SSM discussions. =C2=A0At that time lots of m= anet people were also working with PIM solutions at least for gatewaying,et= c.

I think MANET includes a rich set of application needs = and multicast is very important. Pub/sub data services, streaming services,= control, discovery are potential examples.

We do = need to discuss the models, but also the convergence/reliability issues ten= d to dominate the manet /mesh specific tradeoff and design space as well as= the potentially the need for support mechanisms (e.g., dup detection). So = the specific design challenges are an important part of any design here.


(2b) The routing ADs seem to be running around trying to do
load-balancing of work across WGs, so it might be feasible to
proceed with eg: protocol work for manet compatible IP multicast
in the IP Multicast WG (currently called PIM). From what i
could glean from Alias statements yesterday in PIM WG, they
where primarily thinking of bringing MPLS multicast over to the
Multicast WG, but i think one may want to consider Manet
multicast as well. Nevertheless, see (2a), use-cases should
IMHO be really owned by Manet-WG itself.

Personally I have worked alot with variants of PIM in the past. =C2=A0Esp= ecially gatewaying to/from MANET type networks. =C2=A0It would be good to h= ave more cross discussions.



Cheers
=C2=A0 =C2=A0 Toerless

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

--001a113a75a2484b5004fedd8fe8-- From nobody Wed Jul 23 08:05:30 2014 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 04E361B2AE5 for ; Wed, 23 Jul 2014 08:05:29 -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 RnYKZ9tbb2IJ for ; Wed, 23 Jul 2014 08:05:25 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BD61B2AE1 for ; Wed, 23 Jul 2014 08:05:24 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu12so2354658vcb.6 for ; Wed, 23 Jul 2014 08:05:24 -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=fWqISVRAO7bQOVbG3/WlLPYCNrky+AvAJr/8Qeg4HX4=; b=MBaDczjY1xT/Boxd3KbbTrce6wjiNUYpT7ysEyrjr4Z9E9v9x6vlolDd/0+IcPSoR6 QSwA3GnUdftdVDuhViLEWqM5XMOAfID+HxoljZNkVZBx4mV7giZt7HJM77CdrRcQv0Rh +Bko7aQR1tl4sNsxkKQEeGOwYYZbpMZpm33nJp359n62bDOnhUkj9R8FwmU7mV8fKuqS OY6YPDZeLHsWv+xCM3YwnQjSdSzR2oMMhEcP0SdZS3dXUvN/jxshLmeuL8JpySrdJ9Ks fdcgzYzymMga/lCz68yfmacI2eNRsfGEWr0b6s+uLXsV/GXFd+TgtZjVAoAelmjEB6od iTXQ== MIME-Version: 1.0 X-Received: by 10.52.28.231 with SMTP id e7mr2397987vdh.55.1406127921541; Wed, 23 Jul 2014 08:05:21 -0700 (PDT) Received: by 10.58.2.200 with HTTP; Wed, 23 Jul 2014 08:05:21 -0700 (PDT) Date: Wed, 23 Jul 2014 16:05:21 +0100 Message-ID: From: John Dowdell To: "manet@ietf.org" , "DLEP Research Group (manet-dlep-rg@ietf.org)" Content-Type: multipart/alternative; boundary=20cf307c9ee645b93004feddab5f Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FCcWb3f0TSkDZggVQxwouMHuXuM Subject: [manet] DLEP Interop Event 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, 23 Jul 2014 15:05:29 -0000 --20cf307c9ee645b93004feddab5f Content-Type: text/plain; charset=UTF-8 All Lack of time meant I could not announce this yesterday in the meeting. Good progress has been made on the DLEP draft in the last few meetings, and I believe the draft is nearly ready for some testing. To this end, I intended to offer a DLEP Interop meeting some time during Q1 2015, to take place in south-east Wales, UK. Please bring your routers and modems for testing! Venue: Tredegar House, Newport, South Wales, UK Venue website: http://www.nationaltrust.org.uk/tredegar-house/ Host: Airbus Defence and Space Host website: http://airbusdefenceandspace.com/ Further details will be offered nearer the time. Please note that if you plan on transmitting RF to air, an OFCOM temporary test license may be needed if you are outside of the UK license free bands and power limits. Please contact me for further information and assistance, since we have a local OFCOM contact. OFCOM is the UK regulator for communications, http://www.ofcom.org.uk/. Regards John Dowdell --20cf307c9ee645b93004feddab5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All

Lack of time meant I could not announce this yesterd= ay in the meeting.

Good progress has been made on the D= LEP draft in the last few meetings, and I believe the draft is nearly ready= for some testing. To this end, I=C2=A0intended to offer a DLEP Interop mee= ting some time during Q1 2015, to take place in south-east Wales, UK. Pleas= e bring your routers and modems for testing!

Venue: Tredegar House, Newport, South Wales, UK
Host: Airb= us Defence and Space

Further details w= ill be offered nearer the time.

Please note that i= f you plan on transmitting RF to air,=C2=A0an OFCOM temporary=C2=A0test lic= ense may be needed if you are outside of the UK license free bands and powe= r limits. Please contact me for further information and assistance, since w= e have a local OFCOM contact. OFCOM is=C2=A0the UK regulator for communicat= ions,=C2=A0http://www.ofcom.org.uk/.

Regards
John Dowdell
--20cf307c9ee645b93004feddab5f-- From nobody Wed Jul 23 08:26:35 2014 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 170371B2ADD; Wed, 23 Jul 2014 08:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 DXi1HKtdtNsO; Wed, 23 Jul 2014 08:26:17 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id D98281B28D9; Wed, 23 Jul 2014 08:26:16 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,718,1400040000"; d="scan'208";a="2535107" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport2.idirect.net with ESMTP; 23 Jul 2014 11:26:16 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Wed, 23 Jul 2014 11:26:16 -0400 From: "Snyder, Brian" To: Henning Rogge , Toerless Eckert Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz2bAAam/Fjsku64wVDLp7XuJutulkAgAALoHA= Date: Wed, 23 Jul 2014 15:26:15 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> References: <20140723100019.GK24330@cisco.com> 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: http://mailarchive.ietf.org/arch/msg/manet/jYQHFLeR8Zl1q9BaKWkaxfMigcY Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 15:26:24 -0000 > I think one main difference with MANET is that you have a non-transitive = network... just because that you can hear someone on interface X does not m= ean all your neighbors on interface X can hear this station. >This means that multicast packets coming in through an interface typically= have to be retransmitted through the same interface again. I think if satellite is to be considered a use case for MANET then that can= 't be taken as a constant truth. In satellite we aren't necessarily trying= to build MESH networks (in fact that is much less common) but we are still= interested in MANET to help us pass link state and we still have a lot of = mobility (in terms of modems moving between beams / satellites while mobile= ). So from a multicast requirement, we need there to be the notion on the = hub side that all downstream (the broadcast outroute) multicast is only ev= er sent once, regardless of how many actual DLEP peers are established in t= his direction. If end devices use igmp, pim, etc to get upstream devices t= o forward said multicast - great - the radio doesn't have to know or care s= ince it's a broadcast - if anyone wants it at all, everyone else has the op= portunity to see it for free. In trying to unwrap the implementation I am familiar with from the standard= (thanks to many conversations on this list), I believe this may be possibl= e in theory now. I was thinking one could setup one 'virtual' DLEP peer tha= t registers for all multicast and broadcast mac address towards my radio. = That way my radio can then see all multicast to forward it, regardless of a= ctual individual clients being subscribed or not. (or even *in network*). = Is this understanding correct? thanks, brian _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 08:39:05 2014 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 2A0D21B2AEB; Wed, 23 Jul 2014 08:39: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 4oN84BCnkwUp; Wed, 23 Jul 2014 08:39:02 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B361A0058; Wed, 23 Jul 2014 08:39:02 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so1612936qgd.13 for ; Wed, 23 Jul 2014 08:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=q/OGcPhFHtOjAUlcoKlGObMU915Z7bIcgNFFROPC5S8=; b=lX/P6iIXMip8Q86C0cQpjsHs+L5kquIlKBtIuZs3hczcU0csrbLMDPXYcymecOjcB8 IP0ombCNuYvapP2cvKoggXTLGcwrckKmY9yjnNeKQx9tpRCSxENdH+7o356y6tnZrHYV 2m5b7/AWK2De61kkEp/ej60onGOXvq/wYE9WVfC3J3iZmDDe9N26z/j9fG+/hBxrUGJG 4Q16JPzXNom40xLUvxBXyeUBdFK+cQL5v2PyUVHQhbnaRHGI4F5oDzG0s/TeWlDoxL1B 0L4Jm37GRzr/VrZzdQPcFdXTdAGzhknMsKrbndsTylW5zeF2J7HcfvkIbwxzr+7kN6h0 Ue7g== X-Received: by 10.140.84.168 with SMTP id l37mr3229669qgd.104.1406129941360; Wed, 23 Jul 2014 08:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 08:38:41 -0700 (PDT) In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> References: <20140723100019.GK24330@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> From: Henning Rogge Date: Wed, 23 Jul 2014 17:38:41 +0200 Message-ID: To: "Snyder, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2CYbUZwhUkXFlWbxhSPE4dpBgNc Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 15:39:04 -0000 On Wed, Jul 23, 2014 at 5:26 PM, Snyder, Brian wrote: >> I think one main difference with MANET is that you have a non-transitive= network... just because that you can hear someone on interface X does not = mean all your neighbors on interface X can hear this station. >>This means that multicast packets coming in through an interface typicall= y have to be retransmitted through the same interface again. > > I think if satellite is to be considered a use case for MANET then that c= an't be taken as a constant truth. Its a constant truth for MANET protocol design because its a common thing in MANET deployments. Satcom is already a special case (because there is a "special" node, the hub), but even there the Satcom hub might be forced to retransmit every multicast received over the satcom link because otherwise the rest of the clients would not hear multicast from other clients. > In satellite we aren't necessarily trying to build MESH networks (in fac= t that is much less common) but we are still interested in MANET to help us= pass link state and we still have a lot of mobility (in terms of modems mo= ving between beams / satellites while mobile). So from a multicast require= ment, we need there to be the notion on the hub side that all downstream (t= he broadcast outroute) multicast is only ever sent once, regardless of how= many actual DLEP peers are established in this direction. If end devices = use igmp, pim, etc to get upstream devices to forward said multicast - grea= t - the radio doesn't have to know or care since it's a broadcast - if anyo= ne wants it at all, everyone else has the opportunity to see it for free. > In trying to unwrap the implementation I am familiar with from the standa= rd (thanks to many conversations on this list), I believe this may be possi= ble in theory now. I was thinking one could setup one 'virtual' DLEP peer t= hat registers for all multicast and broadcast mac address towards my radio.= That way my radio can then see all multicast to forward it, regardless of= actual individual clients being subscribed or not. (or even *in network*).= Is this understanding correct? I think the idea with multicast and DLEP is that the radio will either statically announce multicast MACs/IPs or eavesdrop on IGMP (ICMPv6) messages and handle them internally. The routing agent then can use them to fill the local arp table. Your local radio might filter multicast traffic not meant for your local router, but I think thats an implementation detail not set in the draft. Henning Rogge From nobody Wed Jul 23 08:39:15 2014 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 2CFDD1B2AF2 for ; Wed, 23 Jul 2014 08:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, RDNS_NONE=0.793, 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 SY4XOyV27Wio for ; Wed, 23 Jul 2014 08:39:10 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 3E7371B2AF9 for ; Wed, 23 Jul 2014 08:39:08 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 23 Jul 2014 16:38:34 +0100 From: Rick Taylor To: "Stan Ratliff (sratliff)" , "Snyder, Brian" Thread-Topic: [manet] BFD Proxy Idea Thread-Index: AQHPpgauJToXjNoXS0+EDpmMrfu8DJus7YkAgAC87ICAAB7lWg== Date: Wed, 23 Jul 2014 15:38:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA6F2@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343042853@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042A0B@VAUS-MBX03.idirect.net>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/mMZGZpUDJtSIJR-QLEvK6a5dl_I Cc: "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] BFD Proxy Idea 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, 23 Jul 2014 15:39:12 -0000 Stan, Brian, et.al.=0A= =0A= I had a long and very productive chat with Brian, and I hope I was able to = help him differentiate between DLEP and Cisco's implementation.=0A= =0A= >From my perspective, his BFD work seems to e his attempt to work around an = issue he has with his selected implementation, and that Brian you should de= finitely take up with Stan!=0A= =0A= I hope I have managed to bring him up to speed on some of the features that= have come into DLEP since draft-00, allowing him to implement DLEP in his = modems, including only the bits he can actually support given his use-case,= but I will let Brian clarify...=0A= =0A= Offline I discussed this problem with John Dowdell, and he raised the old i= ssue with Satcom DAMA, Metrics and Link Characteristic Requests, so I'm rea= lly pleased that there is someone from the Satcom community who can speak f= rom a position of authority on their use-cases.=0A= =0A= In conclusion, I hope I have verbally convinced Brian that DLEP is the righ= t way to go, and that his issues seem to be mostly with a specific implemen= tation rather than the underlying protocol. I'm not sure what Brian feels = is the best way forwards with his draft, perhaps an information draft descr= ibing how BFD could be used as the 'radio magic' behind a DLEP implementati= on in not very MANET MANET (if that makes any sense).=0A= =0A= As I have said before Brian, any non-Cisco questions concerning DLEP, pleas= e fire them onto the list and we will do our best to help!=0A= =0A= Cheers,=0A= =0A= Rick Taylor =0A= ________________________________________=0A= From: manet [manet-bounces@ietf.org] on behalf of Stan Ratliff (sratliff) [= sratliff@cisco.com]=0A= Sent: 23 July 2014 15:37=0A= To: Snyder, Brian=0A= Cc: manet@ietf.org; Thomas Clausen=0A= Subject: Re: [manet] BFD Proxy Idea=0A= =0A= On Jul 22, 2014, at 11:21 PM, "Snyder, Brian" wrote:= =0A= =0A= > Stan, Thomas, & All,=0A= >=0A= > First let me try and explain my use case a bit better, as it's probably n= ot the typical network designers had in mind...=0A= >=0A= > I have been very involved with designing and prototyping a layer 2 sat ba= sed product offering. As we transition away from "typical" L3 network arch= itecture our next logical step has been for some time to get into RAR/DLEP/= ETC to better optimize L3 routing convergence over the satellite for our cu= stomers. The main idea being to allow them to tune down their L3 "HELLOS" = and try and drive a more event driven model to conserver very expensive sat= ellite bandwidth (while keeping decent convergence times). We know there w= ould be a ton of demand for this if we can solve this particular radio link= - router optimization (faster convergence of Layer 3 CE devices behind the= modems and hub), which is exactly what DLEP is for.. but my network archit= ecture is hub and spoke, not mesh. The scalability of the spokes is simple= - they just need 1 DLEP and ROUTING peer - the hub. However, the hub radi= o will terminate (and represent via DLEP to upstream router) potentially th= ousands of spokes.=0A= =0A= I could see implementing this type of architecture this way - At the spoke = modem, DLEP only reports the presence/absence of the hub. At the hub modem,= it would need to report presence/absence of all of the spokes as they come= and go.=0A= =0A= >=0A= > DLEP seems like a perfect match from everything I've read. but in many wa= ys it seems more complicated than is necessary for my use case. For inst= ance, it would be ideal for me to simply be able to set interfaces logicall= y down, yet NOT have to have a routing protocol specifically tied in (like = BFD). That way I don't have to force any particular network architecture o= n my customers.... afterall, the main reason we are going L2 is to be trans= parent. That ideal loses some steam if I then have to force very narrow rou= ting options on them when in L3 mode they have more choices. I don't want = the congestion/route control features necessarily (for now that is overkill= to me), but I would love to be able to easily set peers or links "down" to= immediately converge routing tables as a Modem falls out (or reenters) the= network. Thus avoiding all L3 timers. Essentially I'd like to pull a vir= tual Ethernet plug.=0A= >=0A= > The added functionality is great, and potentially useful down the road, b= ut the downside then is that it requires OSPF or EIGRP. Preferably, I woul= dn't care if a customer wanted BGP or RIP, etc. if I could logically set th= e interface down via Radio control messages then all my timing/convergence = problems would be solved. Is there a simpler way of doing this within the = confines of DLEP? As stated above, the hub side has additional complexity = as it will aggregate for potentially thousands of modems.=0A= =0A= I think that's a case where you have crossed from the specification over to= Cisco's implementation. The DLEP spec doesn't mention any routing protocol= . From a DLEP perspective, we took the tack of saying "Let's figure out wha= t data items are important for a router and modem to communicate, and then = let's produce a protocol to fling them across the chasm between router and = modem." The issues of what to do with said data items (and what protocol or= protocols they should be fed into) is left to implementers. As for the cur= rent Cisco implementation, you are correct - BGP and RIP aren't supported. = That's not a DLEP spec issue, however.=0A= =0A= >=0A= > So I fully admit, that I am not sure I'm understanding it all correctly, = and I've only played with Cisco's implementation so I very well may (probab= ly likely) have my lines blurred between the standard that DLEP defines and= exactly what is practically implemented and available to use .. This is li= kely throwing my understanding of the standard off.. but when I looked at i= t a few months ago (before I ended up going down the BFD route) I was conce= rned that I would need thousands of virtual interfaces at the upstream rout= er and I knew that wouldn't scale. This sheer # of virtual of interfaces = would also cascade into multicast issues (My hub link is a broadcast medium= and I can't have packets replicated). Also, AFAIK, supporting VLAN with t= his model is not an option. Perhaps one could setup multiple neighbors to = each router via DLEP using multiple interfaces per VLAN per modem - but tha= t would just make the scaling even worse - by an order of magnitude (we exp= ect 10 to 12 vlans per modem). Alternatively, and ideally, we could suppor= t the notion of VLAN trunking into the DLEP interface but I don't think tha= t's currently supported, (again though, that could just be a limitation of = the VMI design in cisco's implementation).=0A= =0A= This could be a problem. As you state up front, the hub may have "thousands= of spokes". Again, it's not a DLEP specification issue - but from a DLEP p= erspective, you'll correspondingly have thousands of "Destinations" that ar= e up in that network, *each* with the potential of having a varying amount = of bandwidth. The question would be exactly how the attached router would g= o about dealing with that notion: would it do so using just a single interf= ace? Or multiple virtual interfaces? That falls into a specific implementat= ion's purview.=0A= =0A= >=0A= > BFD it turns out removes a lot of these concerns - but it's significantly= chattier - which is why I came up with the proxy idea, since as Rick eloqu= ently stated - I have some radio magic I can rely on for link state - I thi= nk because it works on interfaces and doesn't require all the VMI stuff, it= just seems to scale better. BUT (big but) it's very chatty in its own rig= ht and I can't have any link state information shared, which would be ideal= =85=0A= =0A= Again, the "VMI stuff" you refer to is implementation-specific. I'd be happ= y to continue that part of the discussion with you (the implementation-spec= ific part), but not on this list=85 ;-)=0A= =0A= >=0A= > Primarily, I feel I have a MANET problem/use case - and that if we think = about it (or I get more educated:) it should be solved within MANET technol= ogies..... I surprised myself at the end of this research to land on BFD..= . I think because I'm proxying it, I've essentially created a DLEP-light fo= r router - radio link state notifications.=0A= =0A= FWIW, I agree that you have a MANET use case. And as a completely, unabashe= dly, totally *BIASED* observer, I think DLEP addresses most (if not all) of= your needs=85 ;-) I think there are potentially some implementation issues= with the code you have. If you'd like to continue that implementation-spec= ific discussion, please let me know off-list.=0A= =0A= Regards,=0A= Stan=0A= =0A= =0A= =0A= >=0A= > I hope that explains some of my concerns and design issues with what I cu= rrently have to work with. I'm sure I've made some bad assumptions - so pl= ease have at me :)=0A= >=0A= > Side note: My observations are what I had in hand to work with, not neces= sarily what the draft says. I'm guessing this is poor form for IETF convers= ations, so apologies if I've crossed a line... I'm new here ;) Perhaps new= er DLEP drafts address some of these issues, and I just have to stick with = BFD until there are practical implementation I could try and integrate with= ..... It's my understanding the sourceforge reference implementation is ba= sed on draft-0 which is quite out-of-date already.=0A= >=0A= > Thanks for reading this far,=0A= > Brian=0A= >=0A= >=0A= > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=0A= > Sent: Tuesday, July 22, 2014 7:43 PM=0A= > To: Snyder, Brian=0A= > Cc: manet@ietf.org=0A= > Subject: Re: [manet] BFD Proxy Idea=0A= >=0A= > Dear Brian,=0A= > On 22 Jul 2014, at 19:35, "Snyder, Brian" wrote:=0A= > Everyone,=0A= >=0A= > As I presented , I think the main problems I had in adopting DLEP were:= =0A= > . Multicast support=0A= > . VLAN support=0A= > . Scalability=0A= >=0A= >> From a radio point of view, I would like to get these issues addressed (= or at least discussed) so they can work their way into the DLEP definition.= =0A= >=0A= > Ideally, I could use DLEP, as it does have some advantages over BFD, to s= olve the problem I described.=0A= >=0A= >=0A= > I think that it would be a significant help if you could point out "how" = -- for dummies like me, who do not understand satcom very well ;)=0A= >=0A= > Further, I think it would be interesting if we considered defining an abi= lity to use BFD to connect to a DLEP instance in order to manage the link u= p/down setting. This could be useful if one was using DLEP over virtual in= terfaces.=0A= >=0A= > OK, this makes sense to me.=0A= >=0A= >=0A= > Finally, as I didn't quite get to finish my presentation due to time con= straints, I also wanted to mention that I would be here all week and would = be happy to have further conversation on my presentation if anyone was inte= rested. Please feel free to email me and we can pick a coffee spot to cont= inue talking.=0A= >=0A= > To mix up (at least, two) metaphors, I have no dogs in this race -- but I= throughly enjoyed both your presentation and reading your I-D, which was p= articularly well written and easy to digest.=0A= >=0A= > Cheers,=0A= >=0A= > Thomas=0A= >=0A= >=0A= > Thanks,=0A= > Brian=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= =0A= _______________________________________________=0A= manet mailing list=0A= manet@ietf.org=0A= https://www.ietf.org/mailman/listinfo/manet=0A= From nobody Wed Jul 23 09:02:02 2014 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 4B8C41B2922 for ; Wed, 23 Jul 2014 09:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.795 X-Spam-Level: ** X-Spam-Status: No, score=2.795 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 YQWOgBGc0Zgq for ; Wed, 23 Jul 2014 09:02:00 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 E7E1A1B28D4 for ; Wed, 23 Jul 2014 09:01: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; Wed, 23 Jul 2014 17:01:36 +0100 From: Rick Taylor To: "manet@ietf.org" Thread-Topic: New DLEP reference implementation? Thread-Index: Ac+mj2DzVr3RxrSsTQyTtNO4sweulQ== Date: Wed, 23 Jul 2014 16:01:35 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/4ymTGcGxhlEVxLDo6mDp76bvSyU Subject: [manet] New DLEP reference implementation? 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, 23 Jul 2014 16:02:01 -0000 As far as I know, the only open-source reference implementation of DLEP is = the code Cisco kindly published on SourceForge some 4 years ago. The imple= mentation was dlep-draft-00 (or perhaps earlier), and is therefore probably= misleading to anyone searching for references.=0A= =0A= Has the time come for us to release a new reference implementation of DLEP-= 05+, and do people think it would be useful?=0A= =0A= Over breakfast, I made a rough mental sketch of how I would do a reference = implementation:=0A= =0A= GPL license - This is not meant to be used, so stick 'difficult' license on= it.=0A= POSIX platform.=0A= Command line only, no GUI required.=0A= Run in either 'modem mode' or 'router mode'=0A= Demonstrate basic session initialization, maintenance and termination, noth= ing fancy.=0A= Write it in C. (It's what embedded guys use, and it's the lowest common den= ominator)=0A= Use libuv (socket multiplexor from node.js)=0A= Log signal events to stdout, along with the associated data-items.=0A= Don't try and do anything fancy or fast, it's 'howto' code.=0A= Stick it on GitHub, because I prefer it to SF.=0A= Document with doxygen, and try to make it easy to read.=0A= =0A= I'm not sure yet how to run in 'modem mode', as it might need some kind of = interactive console.=0A= =0A= Now, I *might* be able to find some cycles to put a skeleton project togeth= er, but I would need some cycles from the rest of you! Does anyone have an= y keen students/engineers in need of a short project?=0A= =0A= Obviously it would have to be done as a 'clean-room' implementation, as I k= now a few of us have DLEP-ish implementations in commercial products, and w= e would have to ensure all the men in suits are happy.=0A= =0A= It also occurs to me, given John's InterOp announcement, that having a refe= rence implementation would be handy.=0A= =0A= Any comments? Good? Bad? Don't care?=0A= =0A= Rick =0A= =0A= From nobody Wed Jul 23 09:14:00 2014 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 219301A0067 for ; Wed, 23 Jul 2014 09:13:59 -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 7mxS4zMsmJUe for ; Wed, 23 Jul 2014 09:13:57 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4621B1A0025 for ; Wed, 23 Jul 2014 09:13:57 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so1633312qgf.20 for ; Wed, 23 Jul 2014 09:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MYetuctAsAU04UiCEF2YYP6fBfTD70gck1ZmmkSqI6I=; b=kQ3biQ2YkPm8gjhOnYw40DS6F8QSaw9MDG6n4EW7X98hQ/iZ+7fC3hn2rYKIpBTKV6 uCrO9PczSaRxfz8SGvsbFyQ3z2LOB5o2E/0r9GmcrjeLgD5uwYVMy+F2B2QFQEIRb3Fc p8qZ8ZGrSrEBlpYk4mb8eNL0ZDJHVeT2NpyC5EwbxYG1ii16qxnDNeq+lpMcw1tzdivZ X0cOt2XJxDFz55Qx8DvsO1Lr8X8ijFBICpZiqLSMR6sq03wuz2wojzWD5uL3T6DX5evo e9386abVTGdcRiBFduYq3EsvYixEw99eFDTKMXc67fxWeCOSfwLhGSAn4vvQ6QZLEXmU 7waA== X-Received: by 10.224.129.201 with SMTP id p9mr3613972qas.75.1406132036479; Wed, 23 Jul 2014 09:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 23 Jul 2014 09:13:36 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Wed, 23 Jul 2014 18:13:36 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5dOgGQKTUh1i2EZBCt0Eaedt7xk Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 16:13:59 -0000 On Wed, Jul 23, 2014 at 6:01 PM, Rick Taylor wrote: > As far as I know, the only open-source reference implementation of DLEP i= s the code Cisco kindly published on SourceForge some 4 years ago. The imp= lementation was dlep-draft-00 (or perhaps earlier), and is therefore probab= ly misleading to anyone searching for references. > > Has the time come for us to release a new reference implementation of DLE= P-05+, and do people think it would be useful? > > Over breakfast, I made a rough mental sketch of how I would do a referenc= e implementation: > > GPL license - This is not meant to be used, so stick 'difficult' license = on it. > POSIX platform. > Command line only, no GUI required. > Run in either 'modem mode' or 'router mode' > Demonstrate basic session initialization, maintenance and termination, no= thing fancy. > Write it in C. (It's what embedded guys use, and it's the lowest common d= enominator) > Use libuv (socket multiplexor from node.js) > Log signal events to stdout, along with the associated data-items. > Don't try and do anything fancy or fast, it's 'howto' code. > Stick it on GitHub, because I prefer it to SF. > Document with doxygen, and try to make it easy to read. This looks pretty similar to my plans when DLEP-06 (which feels close to DLEP-WGLC) comes out... But a reference implementation will always be useful to test against... some errors are hard to find when you always test against your own code. Henning Rogge From nobody Wed Jul 23 09:53:32 2014 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 0A6F51A0022 for ; Wed, 23 Jul 2014 09:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 kR3CwB2NSxh9 for ; Wed, 23 Jul 2014 09:53:29 -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 9C2DE1A0016 for ; Wed, 23 Jul 2014 09:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2059; q=dns/txt; s=iport; t=1406134409; x=1407344009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NNYnSNJ4mhmEPVBfKklZRhbqrf05lTsSA81abR30mJw=; b=OGXZvr1Az59KBOPxbMpRZ6Fb5AeOuhU/lf/f2PtOqnCn8ELcr8W3Spo8 0mDLc49DCssVsiK0FY4pU8ZtWth88E2cyuOLlBPEa3nMjihxmHaXsukvK QDb6zuKkZxL5wvD/hCCvxqS25t0xPp9ImJ3jdcJ23cA7zSBUtKOcok1aw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAIfnz1OtJA2G/2dsb2JhbABZgw5SVwTHWwqHRQGBCxZ2hAMBAQEDAQEBATc0CwULAgEIDgoeECEGCyUBAQQOBYguAwkIDbk9DYcUEwSNHoF6MweDLoEYBZkqggOOIoYeg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="63400172" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 23 Jul 2014 16:53:28 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6NGrSNb030521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 16:53:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 11:53:28 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] New DLEP reference implementation? Thread-Index: Ac+mj2DzVr3RxrSsTQyTtNO4sweulQAK5ZUAAAFkSoA= Date: Wed, 23 Jul 2014 16:53:27 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <0FF47BFD55FA9945BC1DB4BCBAE9C339@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bXthDLF5a5_HQuubrezX2UEMYt8 Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 16:53:31 -0000 On Jul 23, 2014, at 12:13 PM, Henning Rogge wrote: > On Wed, Jul 23, 2014 at 6:01 PM, Rick Taylor > wrote: >> As far as I know, the only open-source reference implementation of DLEP = is the code Cisco kindly published on SourceForge some 4 years ago. The im= plementation was dlep-draft-00 (or perhaps earlier), and is therefore proba= bly misleading to anyone searching for references. >>=20 >> Has the time come for us to release a new reference implementation of DL= EP-05+, and do people think it would be useful? >>=20 >> Over breakfast, I made a rough mental sketch of how I would do a referen= ce implementation: >>=20 >> GPL license - This is not meant to be used, so stick 'difficult' license= on it. I would have an issue with GPL license. The purpose of a reference implemen= tation *is* to be used, either in whole or in part. IMHO, the GPL license i= s too restrictive. That's the reason we went with the MIT license.=20 Regards, Stan >> POSIX platform. >> Command line only, no GUI required. >> Run in either 'modem mode' or 'router mode' >> Demonstrate basic session initialization, maintenance and termination, n= othing fancy. >> Write it in C. (It's what embedded guys use, and it's the lowest common = denominator) >> Use libuv (socket multiplexor from node.js) >> Log signal events to stdout, along with the associated data-items. >> Don't try and do anything fancy or fast, it's 'howto' code. >> Stick it on GitHub, because I prefer it to SF. >> Document with doxygen, and try to make it easy to read. >=20 > This looks pretty similar to my plans when DLEP-06 (which feels close > to DLEP-WGLC) comes out... >=20 > But a reference implementation will always be useful to test > against... some errors are hard to find when you always test against > your own code. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 10:13:07 2014 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 3A8721B2A5C for ; Wed, 23 Jul 2014 10:13:06 -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 I3J0BczBQfHb for ; Wed, 23 Jul 2014 10:13:04 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770141B2A61 for ; Wed, 23 Jul 2014 10:13:04 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so2122942pab.29 for ; Wed, 23 Jul 2014 10:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=CGIt/48GGimC+ghYvrTouyh+4YpuYVgSe3navngz36E=; b=jkMDxwf8reA1rd9PpeC9FgyPMp3pKTctQL7UQjhfOIYq65D7d2l4iqCTzaZH8TVFzD 1u6SZQs9rnL+F6hRCstarrDvgnLwvUR9cFfTGzJ4PQ9OZQdjs7bMBFWorXCJZ1yTy9cm ZCOGho009d5pGAzYwF4nNLAbQtH74a3aLxJXuyJjQmarlOsxVQlR7X404tvCoFZyMUwB mkGc03wZcjh2qAtthyggNeiB4I//rkNZKYuhReCAb7nntfdRdEhc7/sVvHMskrkQHruI h0jDjjjXpSdROfX2YLm9iKRBDGwSITsM5xmPlx90jvcjJzNV6EHpRC8o4OpiN45FONX+ ttFQ== X-Received: by 10.68.197.40 with SMTP id ir8mr3495210pbc.139.1406135584023; Wed, 23 Jul 2014 10:13:04 -0700 (PDT) Received: from [192.168.1.102] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id mj9sm3882396pdb.44.2014.07.23.10.13.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:13:03 -0700 (PDT) Message-ID: <1406135581.3025.160.camel@localhost> From: Rex Buddenberg To: Rick Taylor Date: Wed, 23 Jul 2014 10:13:01 -0700 In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-2.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/iGsWw2mMR0KVdpmGt80FwVGyEBc Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 17:13:06 -0000 On Wed, 2014-07-23 at 16:01 +0000, Rick Taylor wrote: > > I'm not sure yet how to run in 'modem mode', as it might need some > kind of interactive console. Rick, If you're so exploring, look at things from what the group has been calling 'modem' end of things. Some IEEE 802 language shift is in order: Base Station (BS, what Brian is calling hub) and Subscriber Station. Somewhat more precise language than 'modem'. Brian's satcom problem is a case where all SS can see BS but we make no assumptions about any SS being able to see each other. This is why Brian is using 'hub/spoke' terminology. It is that; no mesh. _The_ layer 2 protocol that implements such is IEEE 802.16. You need a bit of literacy vis .16 to do the job (and it may be easier than you think). There are about four dozen MAC messages in 802.16 that are not communicated through to layer 3. They're carefully outlined in the standard (in fact the bulk of the page count). Of these, the most useful (and perhaps only one you need) is the UL-Map message (upload map). The UL-Map message is included in the BS broadcast stream each frame and it maps out the timeslices for that frame -- each SS transmit assignment (and where the maintenance window for new subscribers lies). For orientation (section 6.3, my copy is 2004 standard): "Each SS shall have a 48-bit universal MAC address, as defined in IEEE Std 802 ® -2001. This address uniquely defines the SS from within the set of all possible vendors and equipment types. It is used during the initial ranging process to establish the appropriate connections for an SS. It is also used as part of the authentication process by which the BS and SS each verify the identity of the other. "Connections are identified by a 16-bit CID. At SS initialization, two pairs of management connections (uplink and downlink) shall be established between the SS and the BS and a third pair of management connections may be optionally generated." I'd suggest that you can wiretap the CID information or otherwise squeeze the CID data from the station -- its pretty much readily available. From nobody Wed Jul 23 10:17:40 2014 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 B90CF1B2B78; Wed, 23 Jul 2014 10:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 z0a1nhMvZcY3; Wed, 23 Jul 2014 10:17:24 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3E1A0270; Wed, 23 Jul 2014 10:16:40 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,718,1400040000"; d="scan'208";a="11337673" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 23 Jul 2014 13:16:40 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Wed, 23 Jul 2014 13:16:39 -0400 From: "Snyder, Brian" To: Henning Rogge Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPplz2bAAam/Fjsku64wVDLp7XuJutulkAgAALoHCAAEi2gP//1gfA Date: Wed, 23 Jul 2014 17:16:38 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343042FCC@VAUS-MBX03.idirect.net> References: <20140723100019.GK24330@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> 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: http://mailarchive.ietf.org/arch/msg/manet/ikqSwheidUJk9zazRTsFx0_-yPA Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 17:17:31 -0000 On Wed, Jul 23, 2014 at 5:26 PM, Snyder, Brian wrote: >>> I think one main difference with MANET is that you have a non-transitiv= e network... just because that you can hear someone on interface X does not= mean all your neighbors on interface X can hear this station. >>>This means that multicast packets coming in through an interface typical= ly have to be retransmitted through the same interface again. >> I think if satellite is to be considered a use case for MANET then that = can't be taken as a constant truth. >Its a constant truth for MANET protocol design because its a common thing = in MANET deployments. >Satcom is already a special case (because there is a "special" node, the h= ub), but even there the Satcom hub might be forced to retransmit every mult= icast received over the satcom link because otherwise the rest of the clien= ts would not hear multicast from other clients. Whilst that is true... it is very common in satellite products (at least in= my experience) that the radio will hairpin inroute multicast traffic if it= is so configured to do so. However, inroute multicast is quite rare of a = use case in actuality. Outroute multicast is very common as the broadcast = nature of the medium blends beautifully to this use case. In fact many cus= tomers solely buy sat for multicast overlay. (However, that's not the MANET= use case).=20 What I was very concerned with was routers thinking each peer is its own in= terface and replicating a downstream packet X times. That can't be allowed= to happen - but again, it's likely this is just a function of the equipmen= t I've been exposed too (or my own misunderstandings) and not actually expe= cted by the design. >> In satellite we aren't necessarily trying to build MESH networks (in fa= ct that is much less common) but we are still interested in MANET to help u= s pass link state and we still have a lot of mobility (in terms of modems m= oving between beams / satellites while mobile). So from a multicast requir= ement, we need there to be the notion on the hub side that all downstream (= the broadcast outroute) multicast is only ever sent once, regardless of ho= w many actual DLEP peers are established in this direction. If end devices= use igmp, pim, etc to get upstream devices to forward said multicast - gre= at - the radio doesn't have to know or care since it's a broadcast - if any= one wants it at all, everyone else has the opportunity to see it for free. >> In trying to unwrap the implementation I am familiar with from the stand= ard (thanks to many conversations on this list), I believe this may be poss= ible in theory now. I was thinking one could setup one 'virtual' DLEP peer = that registers for all multicast and broadcast mac address towards my radio= . That way my radio can then see all multicast to forward it, regardless o= f actual individual clients being subscribed or not. (or even *in network*)= . Is this understanding correct? >I think the idea with multicast and DLEP is that the radio will either sta= tically announce multicast MACs/IPs or eavesdrop on IGMP (ICMPv6) messages = and handle them internally. The routing agent then can use them to fill the= local arp table. >Your local radio might filter multicast traffic not meant for your local r= outer, but I think thats an implementation detail not set in the draft. Fair enough. Is there anything against the "rules" if one managed multicast= membership completely outside the notion of DLEP? There is still a physic= al interface (in our case a VLAN trunk port), and I would be happy to have = that interface decide weather or not to forward multicast with no too littl= e concern about modem status.... there is some persistent multicast I want= to send regardless of DLEP's opinion of spokes being in or out of network.= (There is station keeping multicast that must flow even if there are 0 'in= -network' spokes). thanks for the discussion, brian Henning Rogge From nobody Wed Jul 23 10:32:41 2014 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 C58771A00FA for ; Wed, 23 Jul 2014 10:32:39 -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 tWBueDWknYmb for ; Wed, 23 Jul 2014 10:32:38 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCD31B2AD2 for ; Wed, 23 Jul 2014 10:31:37 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so1984411pdb.17 for ; Wed, 23 Jul 2014 10:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:date:in-reply-to:references:content-type :mime-version:content-transfer-encoding; bh=aRXov6GzOgfsEqVS477flZ/vjaad3NZxA1Ud+20Ngxk=; b=R87U3/mwU9Y7TkaT0UdpQrKilh+xUGZwVcuTGqO55kuKDP6Q/WH8lm7L+JPFMsjcoo t0oUa45Nzvll9e1loZerin4KljNZ1l/i02EyJ9riN/Of2TzNtX/f/tueX9Hdy/swfCHx JnP8oGspdw3pOPXLC0wvXQKYen9H1ssjUqL9abBA64ZiNCDKt7/cjA7Yf2QVN/4FN+g5 GKRErSVlzhTx9yJKQl4FAPxHJN/tYzt2MmpVVPdEJYa2QhBTU6HUSpRI8wegS7FzWuhC INLzZ/oGQb3Vf8fBwM8vjzn+u7lANqOz5rppY1EK0tMZW+opJF02+wnX+AJywmg7xKgC scFw== X-Received: by 10.66.169.136 with SMTP id ae8mr3941282pac.14.1406136695147; Wed, 23 Jul 2014 10:31:35 -0700 (PDT) Received: from [192.168.1.102] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id og3sm2980088pbc.48.2014.07.23.10.31.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:31:34 -0700 (PDT) Message-ID: <1406136693.3025.168.camel@localhost> From: Rex Buddenberg To: manet@ietf.org Date: Wed, 23 Jul 2014 10:31:33 -0700 In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042FCC@VAUS-MBX03.idirect.net> References: <20140723100019.GK24330@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042FCC@VAUS-MBX03.idirect.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-2.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hX4whwFioQKsDBs8_kJJFWP93jw Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 17:32:39 -0000 On Wed, 2014-07-23 at 17:16 +0000, Snyder, Brian wrote: > > >Your local radio might filter multicast traffic not meant for your > local router, but I think thats an implementation detail not set in > the draft. > > Fair enough. Is there anything against the "rules" if one managed > multicast membership completely outside the notion of DLEP? There is > still a physical interface (in our case a VLAN trunk port), and I > would be happy to have that interface decide weather or not to forward > multicast with no too little concern about modem status.... there is > some persistent multicast I want to send regardless of DLEP's opinion > of spokes being in or out of network. (There is station keeping > multicast that must flow even if there are 0 'in-network' spokes). Brian, IEEE 802 consistently partitions between control plane and (user) data plane. Data plane traffic is passed through the layer 2 boundary to higher layers. Control plane traffic remains at layer 2 and is not passed up (although it's generally available for management purposes). So at layer 2, traffic destined for the router is user traffic -- data plane. This can get a bit confusing because some of what is clearly data plane traffic at layer 2 becomes control plane traffic (e.g. routing table updates, router hello messages) at layer 3. Your observation about multicast is correct -- in an all-wired (overprovisioned) terrestrial internet, the benefits of multicast aren't obvious. But as soon as you have a radio-WAN in the infrastructure (whether or not it's satcom), the payoffs to multicast become much greater. From nobody Wed Jul 23 10:34:06 2014 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 E60FE1B2A25 for ; Wed, 23 Jul 2014 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 40tRz6SbxWe7 for ; Wed, 23 Jul 2014 10:34:04 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D61A0104 for ; Wed, 23 Jul 2014 10:33:11 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,718,1400040000"; d="scan'208";a="11338209" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 23 Jul 2014 13:33:10 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Wed, 23 Jul 2014 13:33:10 -0400 From: "Snyder, Brian" To: Rex Buddenberg , Rick Taylor Thread-Topic: [manet] New DLEP reference implementation? Thread-Index: Ac+mj2DzVr3RxrSsTQyTtNO4sweulQAK4F6AAAfNgfA= Date: Wed, 23 Jul 2014 17:33:10 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF734304304B@VAUS-MBX03.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> <1406135581.3025.160.camel@localhost> In-Reply-To: <1406135581.3025.160.camel@localhost> 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: http://mailarchive.ietf.org/arch/msg/manet/0DDaybWFEel1Yteu-7O0aQKSfhs Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 17:34:06 -0000 Rex, Are you suggesting that we modify our entire tdma access control? I can't = imagine there would be a benefit to that. The physical layer is not at issu= e in my design - it's strictily the radio-routing link I'm trying to unders= tand/design/optimize for my use case - given I have a much bigger scale pro= blem (thousands of nodes), no mesh, multicast and vlans too worry about. P= erhaps I misunderstand your point, and if so I apologize, but I don't see a= ny advantage to prying open the whole radio control plane. That is very mat= ure for more than a decade now. If this is what you mean, could you please clarify why that would be advant= ageous to consider? Thanks, brian -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rex Buddenberg Sent: Wednesday, July 23, 2014 1:13 PM To: Rick Taylor Cc: manet@ietf.org Subject: Re: [manet] New DLEP reference implementation? On Wed, 2014-07-23 at 16:01 +0000, Rick Taylor wrote: >=20 > I'm not sure yet how to run in 'modem mode', as it might need some=20 > kind of interactive console. Rick, If you're so exploring, look at things from what the group has been calling= 'modem' end of things. Some IEEE 802 language shift is in order: Base Station (BS, what Brian is calling hub) and Subscriber Station. Somewhat more precise language than 'modem'. =20 Brian's satcom problem is a case where all SS can see BS but we make no ass= umptions about any SS being able to see each other. This is why Brian is using 'hub/spoke' terminology. It is that; no mesh. =20 _The_ layer 2 protocol that implements such is IEEE 802.16. You need = a bit of literacy vis .16 to do the job (and it may be easier than you thin= k). There are about four dozen MAC messages in 802.16 that are not communicated= through to layer 3. They're carefully outlined in the standard (in fact t= he bulk of the page count). Of these, the most useful (and perhaps only on= e you need) is the UL-Map message (upload map). The UL-Map message is incl= uded in the BS broadcast stream each frame and it maps out the timeslices f= or that frame -- each SS transmit assignment (and where the maintenance win= dow for new subscribers lies). =20 For orientation (section 6.3, my copy is 2004 standard): "Each SS shall= have a 48-bit universal MAC address, as defined in IEEE Std 802 (r) -2001.= This address uniquely defines the SS from within the set of all possible v= endors and equipment types. It is used during the initial ranging process t= o establish the appropriate connections for an SS. It is also used as part = of the authentication process by which the BS and SS each verify the identi= ty of the other. "Connections are identified by a 16-bit CID. At SS initialization, two pair= s of management connections (uplink and downlink) shall be established betw= een the SS and the BS and a third pair of management connections may be opt= ionally generated." =20 I'd suggest that you can wiretap the CID information or otherwise sque= eze the CID data from the station -- its pretty much readily available. =20 =20 =20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 10:36:24 2014 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 D60FD1B2BCF for ; Wed, 23 Jul 2014 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 TOvT-bDc32Ru for ; Wed, 23 Jul 2014 10:36:19 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 979A01B2BDB for ; Wed, 23 Jul 2014 10:35:39 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,718,1400040000"; d="scan'208";a="11338295" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 23 Jul 2014 13:35:39 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Wed, 23 Jul 2014 13:35:39 -0400 From: "Snyder, Brian" To: Rick Taylor , "manet@ietf.org" Thread-Topic: New DLEP reference implementation? Thread-Index: Ac+mj2DzVr3RxrSsTQyTtNO4sweulQADQu8A Date: Wed, 23 Jul 2014 17:35:38 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343043093@VAUS-MBX03.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.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: http://mailarchive.ietf.org/arch/msg/manet/udXY1Ae2BQsfzEIQ1xSCWijlxFM Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 17:36:22 -0000 Rick, Perhaps I can help with radio parts -- I'll have to work on this anyway to = play nice at the interop.... Brian -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor Sent: Wednesday, July 23, 2014 12:02 PM To: manet@ietf.org Subject: [manet] New DLEP reference implementation? As far as I know, the only open-source reference implementation of DLEP is = the code Cisco kindly published on SourceForge some 4 years ago. The imple= mentation was dlep-draft-00 (or perhaps earlier), and is therefore probably= misleading to anyone searching for references. Has the time come for us to release a new reference implementation of DLEP-= 05+, and do people think it would be useful? Over breakfast, I made a rough mental sketch of how I would do a reference = implementation: GPL license - This is not meant to be used, so stick 'difficult' license on= it. POSIX platform. Command line only, no GUI required. Run in either 'modem mode' or 'router mode' Demonstrate basic session initialization, maintenance and termination, noth= ing fancy. Write it in C. (It's what embedded guys use, and it's the lowest common den= ominator) Use libuv (socket multiplexor from node.js) Log signal events to = stdout, along with the associated data-items. Don't try and do anything fancy or fast, it's 'howto' code. Stick it on GitHub, because I prefer it to SF. Document with doxygen, and try to make it easy to read. I'm not sure yet how to run in 'modem mode', as it might need some kind of = interactive console. Now, I *might* be able to find some cycles to put a skeleton project togeth= er, but I would need some cycles from the rest of you! Does anyone have an= y keen students/engineers in need of a short project? Obviously it would have to be done as a 'clean-room' implementation, as I k= now a few of us have DLEP-ish implementations in commercial products, and w= e would have to ensure all the men in suits are happy. It also occurs to me, given John's InterOp announcement, that having a refe= rence implementation would be handy. Any comments? Good? Bad? Don't care? Rick =20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 10:36:55 2014 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 312171B2A2D for ; Wed, 23 Jul 2014 10:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 VGc4urMdZ25C for ; Wed, 23 Jul 2014 10:36:50 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 324791B29E6 for ; Wed, 23 Jul 2014 10:36:08 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 23 Jul 2014 18:35:34 +0100 From: Rick Taylor To: "Stan Ratliff (sratliff)" , Henning Rogge Thread-Topic: [manet] New DLEP reference implementation? Thread-Index: AQHPppEbZ6w5tgFiQUWavjEkyPZ4tZutz1mAgAAbmPk= Date: Wed, 23 Jul 2014 17:32:13 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA749@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/dRNTujzsBn6rM7MVi3dK5q8yoAo Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 17:36:51 -0000 >>> GPL license - This is not meant to be used, so stick 'difficult' licens= e on it.=0A= =0A= >I would have an issue with GPL license. The purpose of a reference impleme= ntation *is* to be used, either in whole or in part. IMHO, the >GPL license= is too restrictive. That's the reason we went with the MIT license.=0A= =0A= My intention in using the GPL license was to effectively prevent people usi= ng the reference implementation for anything more than interop testing and = examining how one might go about writing a DLEP router or radio.=0A= =0A= If people are willing to put the effort into a more usable implementation, = then BSD/MIT is probably the right way to go, but it depends on what the co= de author's intention for the code is.=0A= =0A= Personally, it makes no difference to me, as long as I'm not stating that t= he code is fit for a purpose...=0A= =0A= Rick = From nobody Wed Jul 23 10:42:01 2014 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 D2BFC1A0300 for ; Wed, 23 Jul 2014 10:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.795 X-Spam-Level: ** X-Spam-Status: No, score=2.795 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 NLOlTormNxlw for ; Wed, 23 Jul 2014 10:41:58 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 427711A00DC for ; Wed, 23 Jul 2014 10:41: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; Wed, 23 Jul 2014 18:41:33 +0100 From: Rick Taylor To: "Snyder, Brian" , Rex Buddenberg Thread-Topic: [manet] New DLEP reference implementation? Thread-Index: AQHPppleaw6hJTgkMESA3tboDiPRgZut2mEAgAARmUY= Date: Wed, 23 Jul 2014 17:41:33 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA75D@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> <1406135581.3025.160.camel@localhost>, <84585478AABBBF4B9DF597FC0F84AF734304304B@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF734304304B@VAUS-MBX03.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/IWQ6NpAMPQqYFQM_zcSTuMiEZLA Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 17:41:59 -0000 Rex,=0A= =0A= I'm with Brian on this one, in DLEP terms what you discuss is definitely 'r= adio magic', and the intention of a reference implementation is to demonstr= ate via code how one might go about implementing DLEP for a router or radio= . The details of the radio is definitely out of scope; I don't want to get= caught up in a TDMA/CDMA/whatever emulator.=0A= =0A= My musings about a console interface to the DLEP code in radio mode is more= along the lines of:=0A= =0A= >New Link Radio 3 to Radio 2=0A= Radio 3 is now linked to radio by link 7.=0A= >Link 7 CDR 2300, Up=0A= Link 7 now up, CDR: 2300Kbps.=0A= DLEP Destination_Up signals sent to: Radio 3, Radio 2.=0A= >Quit=0A= Goodbye... =0A= =0A= Does that clarify?=0A= =0A= Rick= From nobody Wed Jul 23 10:46:38 2014 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 B6B101AC0D2 for ; Wed, 23 Jul 2014 10:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 CK2G74gmkY6T for ; Wed, 23 Jul 2014 10:46:33 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 7F6611A02D4 for ; Wed, 23 Jul 2014 10:46:32 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 23 Jul 2014 18:46:08 +0100 From: Rick Taylor To: "Snyder, Brian" , "manet@ietf.org" Thread-Topic: New DLEP reference implementation? Thread-Index: Ac+mj2DzVr3RxrSsTQyTtNO4sweulQADQu8AAABUXbo= Date: Wed, 23 Jul 2014 17:44:24 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA77F@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF7343043093@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343043093@VAUS-MBX03.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/s75cNlYq2oZ9lOsUALxGXFMiWEA Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 17:46:34 -0000 Thank you Brian, that's a very kind offer.=0A= =0A= I don't however want to get too far into the details of what the 'router' a= nd 'radio' parts of the DLEP ref impl does, so I want to abstract them as m= uch as possible, but all help gratefully received!=0A= =0A= Damn, this idea of mine is gaining traction, I better flesh out my design a= little more... ;)=0A= =0A= Rick=0A= ________________________________________=0A= From: Snyder, Brian [bsnyder@idirect.net]=0A= Sent: 23 July 2014 18:35=0A= To: Rick Taylor; manet@ietf.org=0A= Subject: RE: New DLEP reference implementation?=0A= =0A= Rick,=0A= =0A= Perhaps I can help with radio parts -- I'll have to work on this anyway to = play nice at the interop....=0A= =0A= Brian=0A= =0A= -----Original Message-----=0A= From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor=0A= Sent: Wednesday, July 23, 2014 12:02 PM=0A= To: manet@ietf.org=0A= Subject: [manet] New DLEP reference implementation?=0A= =0A= As far as I know, the only open-source reference implementation of DLEP is = the code Cisco kindly published on SourceForge some 4 years ago. The imple= mentation was dlep-draft-00 (or perhaps earlier), and is therefore probably= misleading to anyone searching for references.=0A= =0A= Has the time come for us to release a new reference implementation of DLEP-= 05+, and do people think it would be useful?=0A= =0A= Over breakfast, I made a rough mental sketch of how I would do a reference = implementation:=0A= =0A= GPL license - This is not meant to be used, so stick 'difficult' license on= it.=0A= POSIX platform.=0A= Command line only, no GUI required.=0A= Run in either 'modem mode' or 'router mode'=0A= Demonstrate basic session initialization, maintenance and termination, noth= ing fancy.=0A= Write it in C. (It's what embedded guys use, and it's the lowest common den= ominator) Use libuv (socket multiplexor from node.js) Log signal events to = stdout, along with the associated data-items.=0A= Don't try and do anything fancy or fast, it's 'howto' code.=0A= Stick it on GitHub, because I prefer it to SF.=0A= Document with doxygen, and try to make it easy to read.=0A= =0A= I'm not sure yet how to run in 'modem mode', as it might need some kind of = interactive console.=0A= =0A= Now, I *might* be able to find some cycles to put a skeleton project togeth= er, but I would need some cycles from the rest of you! Does anyone have an= y keen students/engineers in need of a short project?=0A= =0A= Obviously it would have to be done as a 'clean-room' implementation, as I k= now a few of us have DLEP-ish implementations in commercial products, and w= e would have to ensure all the men in suits are happy.=0A= =0A= It also occurs to me, given John's InterOp announcement, that having a refe= rence implementation would be handy.=0A= =0A= Any comments? Good? Bad? Don't care?=0A= =0A= Rick=0A= =0A= =0A= _______________________________________________=0A= manet mailing list=0A= manet@ietf.org=0A= https://www.ietf.org/mailman/listinfo/manet=0A= From nobody Wed Jul 23 10:49:06 2014 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 18B471B2A16; Wed, 23 Jul 2014 10:48:52 -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 UFMK4vfuBWL5; Wed, 23 Jul 2014 10:48:49 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B89D1A02D4; Wed, 23 Jul 2014 10:48:48 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so1721636igc.12 for ; Wed, 23 Jul 2014 10:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aqBMNbcEUbxmfrnthpP2bOVlfCFgD8CkVKG+5yxqE0s=; b=JeZ3ZHq0Bh0fUNTc58iqc7cevfg/21xOPglNLXbAZCp2Xf3fpd0F6OeJhv3RxaUXvW lxN+ZC/hG9N8CPbrU883BfzTUhRwaB32PrSvrMPXpyzQny62GxjiFgTbYhRW4w3lCkOr j0F7HLGrIaLzw9e0uL0I/p/4fck+/2OedqOwINWTWniYB0jgPJ+ze023W4hKX6OmWpgX UssUVZPvps7JY9LYBkzy5Kzb2tQTAoPxXENHhvvdSoS3KQ8pExmyADWt1EfgW9lpYHDJ rvAlhxmbW6mtDt6fkFeg7157JXGmuKQZcjYXjtKVhK6Fjw0QOGWx1MZflOkwFzZ2G3Mo lMOg== X-Received: by 10.50.87.98 with SMTP id w2mr6175160igz.34.1406137727582; Wed, 23 Jul 2014 10:48:47 -0700 (PDT) Received: from [10.2.2.8] (dynamic-acs-24-144-141-5.zoominternet.net. [24.144.141.5]) by mx.google.com with ESMTPSA id z8sm61487012igl.20.2014.07.23.10.48.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:48:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shawn Jury In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343042FCC@VAUS-MBX03.idirect.net> Date: Wed, 23 Jul 2014 13:48:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140723100019.GK24330@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042FCC@VAUS-MBX03.idirect.net> To: "Snyder, Brian" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YX1hgY52hkfRpMDNSPWmcxgDF9U Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 17:48:52 -0000 Brian, On Jul 23, 2014, at 1:16 PM, Snyder, Brian wrote: >=20 > On Wed, Jul 23, 2014 at 5:26 PM, Snyder, Brian = wrote: >>>> I think one main difference with MANET is that you have a = non-transitive network... just because that you can hear someone on = interface X does not mean all your neighbors on interface X can hear = this station. >>>> This means that multicast packets coming in through an interface = typically have to be retransmitted through the same interface again. >=20 >>> I think if satellite is to be considered a use case for MANET then = that can't be taken as a constant truth. >=20 >> Its a constant truth for MANET protocol design because its a common = thing in MANET deployments. >=20 >> Satcom is already a special case (because there is a "special" node, = the hub), but even there the Satcom hub might be forced to retransmit = every multicast received over the satcom link because otherwise the rest = of the clients would not hear multicast from other clients. >=20 > Whilst that is true... it is very common in satellite products (at = least in my experience) that the radio will hairpin inroute multicast = traffic if it is so configured to do so. However, inroute multicast is = quite rare of a use case in actuality. Outroute multicast is very = common as the broadcast nature of the medium blends beautifully to this = use case. In fact many customers solely buy sat for multicast overlay. = (However, that's not the MANET use case).=20 >=20 > What I was very concerned with was routers thinking each peer is its = own interface and replicating a downstream packet X times. That can't = be allowed to happen - but again, it's likely this is just a function of = the equipment I've been exposed too (or my own misunderstandings) and = not actually expected by the design. >=20 >=20 =46rom the draft point of view, DLEP supports multicast as a destination = so metrics can be applied. This allows other functionality like = rate-limiting/shaping for a multicast group(s), but these are outside = the scope of the DLEP draft. DLEP doesn't replicate multicast packets = (again, outside the scope), it assumes the router will take care of = that. Even with the implementation you played with, that was the case. = As I offered before off-list (and Stan has too), I'd be happy to help = you better understand how the implementation works, but it not something = to discuss on the IETF alias as it is a Cisco specific implementation. This isn't the first time I've heard this mis-interpretation of the DLEP = spec, wrt how we treat DLEP destinations. DLEP destinations are used to = associate metrics about the RF quality. DLEP destinations can be = physical (as in a router on the remote side) or logical (ie multicast = group). There is no point-to-point connection made between these = devices. Even if the router implementation makes use of virtual = interfaces, the underlying radio protocol is assumed (and must be = treated) to be broadcast. I would argue that if you have an = implementation that doesn't treat the RF as broadcast and makes = point-to-point links instead, it is not following the DLEP spec = correctly. This is the only way I could see multicast packets being = replicated by a router. Please help me to understand if there is a = different view on this. >=20 >>> In satellite we aren't necessarily trying to build MESH networks (in = fact that is much less common) but we are still interested in MANET to = help us pass link state and we still have a lot of mobility (in terms of = modems moving between beams / satellites while mobile). So from a = multicast requirement, we need there to be the notion on the hub side = that all downstream (the broadcast outroute) multicast is only ever = sent once, regardless of how many actual DLEP peers are established in = this direction. If end devices use igmp, pim, etc to get upstream = devices to forward said multicast - great - the radio doesn't have to = know or care since it's a broadcast - if anyone wants it at all, = everyone else has the opportunity to see it for free. >=20 >>> In trying to unwrap the implementation I am familiar with from the = standard (thanks to many conversations on this list), I believe this may = be possible in theory now. I was thinking one could setup one 'virtual' = DLEP peer that registers for all multicast and broadcast mac address = towards my radio. That way my radio can then see all multicast to = forward it, regardless of actual individual clients being subscribed or = not. (or even *in network*). Is this understanding correct? >=20 >> I think the idea with multicast and DLEP is that the radio will = either statically announce multicast MACs/IPs or eavesdrop on IGMP = (ICMPv6) messages and handle them internally. The routing agent then can = use them to fill the local arp table. >=20 >> Your local radio might filter multicast traffic not meant for your = local router, but I think thats an implementation detail not set in the = draft. >=20 > Fair enough. Is there anything against the "rules" if one managed = multicast membership completely outside the notion of DLEP? There is = still a physical interface (in our case a VLAN trunk port), and I would = be happy to have that interface decide weather or not to forward = multicast with no too little concern about modem status.... there is = some persistent multicast I want to send regardless of DLEP's opinion of = spokes being in or out of network. (There is station keeping multicast = that must flow even if there are 0 'in-network' spokes). >=20 Nothing states you have to use DLEP to manage multicast. DLEP has the = capability so that you can help reduce the amount of traffic sent (as = mentioned above) for those radios that might have a different mechanism = for sending multicast. The ROUTER controls what multicast groups are = being sent to the radio/modem. If the ROUTER believes that a group has = joined on the interface, it will send the packet out the interface = (purposely left generic as there are many ways the ROUTER could learn = about a group). Shawn =20 > thanks for the discussion, > brian >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 11:01:02 2014 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 AF38A1A083D; Wed, 23 Jul 2014 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ZVe4KxAEuh9M; Wed, 23 Jul 2014 11:00:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27FD1B2A22; Wed, 23 Jul 2014 10:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7630; q=dns/txt; s=iport; t=1406138400; x=1407348000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HB7gJspBkCiOJfC4alCfsEaX0ZoV0t1cdt14OZuj6u0=; b=TRJH0oFH/xMHV1ED0SbXdEdpEcrSu8yqMqN+z12r2xcLjG8sZ6X/Ety+ /q6OAfMR4ZvS71FdCwxX9nflOcgj55C43kHJqB5S7ZX9fG8kIW3PtNHcq qe1Tx8hWhNKo15E0HisoMr3wpDinECjbH4HXUl62HCjh9UuNKvX4cdPcx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAO73z1OtJA2L/2dsb2JhbABPCoMOUlcEx1sKh0UBgQsWdoQDAQEBAwEBAQE3NAIJBQsCAQgYHhAhBgslAgQOBYguAwkIDbkCDYcUEwSJfoMggVEpMweDLoEYBZkqggOOIoYeg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="63408331" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 23 Jul 2014 17:59:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6NHxaGs006735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 17:59:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 12:59:36 -0500 From: "Stan Ratliff (sratliff)" To: Shawn Jury Thread-Topic: [manet] manet: IP multicast comments Thread-Index: AQHPpl0AK+IXaCp+3EmPKrn2532hR5utyx0AgABQ3ICAAAN6gIAAG14AgAAI+YCAAAMFAA== Date: Wed, 23 Jul 2014 17:59:35 +0000 Message-ID: References: <20140723100019.GK24330@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343042E89@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343042FCC@VAUS-MBX03.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <64F4CCD4B12FD9459A3824FB1F845BA1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/taGjXZizZn-vdxagNkslszmFdO4 Cc: MANET IETF , "pim@ietf.org" Subject: Re: [manet] manet: IP multicast comments 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, 23 Jul 2014 18:00:55 -0000 On Jul 23, 2014, at 1:48 PM, Shawn Jury wrote: > Brian, >=20 > On Jul 23, 2014, at 1:16 PM, Snyder, Brian wrote: >=20 >>=20 >> On Wed, Jul 23, 2014 at 5:26 PM, Snyder, Brian wro= te: >>>>> I think one main difference with MANET is that you have a non-transit= ive network... just because that you can hear someone on interface X does n= ot mean all your neighbors on interface X can hear this station. >>>>> This means that multicast packets coming in through an interface typi= cally have to be retransmitted through the same interface again. >>=20 >>>> I think if satellite is to be considered a use case for MANET then tha= t can't be taken as a constant truth. >>=20 >>> Its a constant truth for MANET protocol design because its a common thi= ng in MANET deployments. >>=20 >>> Satcom is already a special case (because there is a "special" node, th= e hub), but even there the Satcom hub might be forced to retransmit every m= ulticast received over the satcom link because otherwise the rest of the cl= ients would not hear multicast from other clients. >>=20 >> Whilst that is true... it is very common in satellite products (at least= in my experience) that the radio will hairpin inroute multicast traffic if= it is so configured to do so. However, inroute multicast is quite rare of= a use case in actuality. Outroute multicast is very common as the broadca= st nature of the medium blends beautifully to this use case. In fact many = customers solely buy sat for multicast overlay. (However, that's not the MA= NET use case).=20 >>=20 >> What I was very concerned with was routers thinking each peer is its own= interface and replicating a downstream packet X times. That can't be allo= wed to happen - but again, it's likely this is just a function of the equip= ment I've been exposed too (or my own misunderstandings) and not actually e= xpected by the design. >>=20 >>=20 >=20 > From the draft point of view, DLEP supports multicast as a destination so= metrics can be applied. This allows other functionality like rate-limitin= g/shaping for a multicast group(s), but these are outside the scope of the = DLEP draft. DLEP doesn't replicate multicast packets (again, outside the s= cope), it assumes the router will take care of that. Even with the impleme= ntation you played with, that was the case. As I offered before off-list (= and Stan has too), I'd be happy to help you better understand how the imple= mentation works, but it not something to discuss on the IETF alias as it is= a Cisco specific implementation. >=20 > This isn't the first time I've heard this mis-interpretation of the DLEP = spec, wrt how we treat DLEP destinations. DLEP destinations are used to as= sociate metrics about the RF quality. DLEP destinations can be physical (a= s in a router on the remote side) or logical (ie multicast group). There i= s no point-to-point connection made between these devices. Even if the rou= ter implementation makes use of virtual interfaces, the underlying radio pr= otocol is assumed (and must be treated) to be broadcast. I would argue tha= t if you have an implementation that doesn't treat the RF as broadcast and = makes point-to-point links instead, it is not following the DLEP spec corre= ctly. This is the only way I could see multicast packets being replicated = by a router. Please help me to understand if there is a different view on = this. Ditto what Shawn said - Multicast packet replication is required if you're = using a technique like RFC 5578 (for example), but that's got *everything* = to do with the PPPoE underpinnings, and *nothing* to do with the link varia= bility. DLEP treats a multicast group as another logical destination in the= network, so that metrics for the logical destination (group) can be report= ed by the modem, and so that (potentially) a router can make a request via = Link Characteristics Request for data rate, or latency. The "Destination Up= " DLEP signal can flow in either direction (e.g. Modem-to-Router, or Router= -to-Modem) so that either DLEP participant can identify the existence of a = new destination (e.g. a new multicast group). There's nothing in the DLEP s= pec referencing multicast replication, because it's not necessary.=20 Regards, Stan >=20 >>=20 >>>> In satellite we aren't necessarily trying to build MESH networks (in f= act that is much less common) but we are still interested in MANET to help = us pass link state and we still have a lot of mobility (in terms of modems = moving between beams / satellites while mobile). So from a multicast requi= rement, we need there to be the notion on the hub side that all downstream = (the broadcast outroute) multicast is only ever sent once, regardless of h= ow many actual DLEP peers are established in this direction. If end device= s use igmp, pim, etc to get upstream devices to forward said multicast - gr= eat - the radio doesn't have to know or care since it's a broadcast - if an= yone wants it at all, everyone else has the opportunity to see it for free. >>=20 >>>> In trying to unwrap the implementation I am familiar with from the sta= ndard (thanks to many conversations on this list), I believe this may be po= ssible in theory now. I was thinking one could setup one 'virtual' DLEP pee= r that registers for all multicast and broadcast mac address towards my rad= io. That way my radio can then see all multicast to forward it, regardless= of actual individual clients being subscribed or not. (or even *in network= *). Is this understanding correct? >>=20 >>> I think the idea with multicast and DLEP is that the radio will either = statically announce multicast MACs/IPs or eavesdrop on IGMP (ICMPv6) messag= es and handle them internally. The routing agent then can use them to fill = the local arp table. >>=20 >>> Your local radio might filter multicast traffic not meant for your loca= l router, but I think thats an implementation detail not set in the draft. >>=20 >> Fair enough. Is there anything against the "rules" if one managed multic= ast membership completely outside the notion of DLEP? There is still a phy= sical interface (in our case a VLAN trunk port), and I would be happy to ha= ve that interface decide weather or not to forward multicast with no too li= ttle concern about modem status.... there is some persistent multicast I w= ant to send regardless of DLEP's opinion of spokes being in or out of netwo= rk. (There is station keeping multicast that must flow even if there are 0 = 'in-network' spokes). >>=20 >=20 > Nothing states you have to use DLEP to manage multicast. DLEP has the ca= pability so that you can help reduce the amount of traffic sent (as mention= ed above) for those radios that might have a different mechanism for sendin= g multicast. The ROUTER controls what multicast groups are being sent to t= he radio/modem. If the ROUTER believes that a group has joined on the inte= rface, it will send the packet out the interface (purposely left generic as= there are many ways the ROUTER could learn about a group). >=20 > Shawn =20 >=20 >> thanks for the discussion, >> brian >>=20 >> Henning Rogge >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 23 11:17:51 2014 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 1F4F51B2C25 for ; Wed, 23 Jul 2014 11:17:47 -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 kw6YIcLEploB for ; Wed, 23 Jul 2014 11:17:44 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E971E1B2C1F for ; Wed, 23 Jul 2014 11:17:43 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so2078904pdj.28 for ; Wed, 23 Jul 2014 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=jcAET2TqRYwy6hruEiL1tM0WAlP9evar4SZzX1bAUBk=; b=mINy5xmpNbT83/OYjBrvvVBt1+4OHDc9Yx5O5hJCDXRmLzcLAYBEEDDGgjV90/QyvC 2aGBEB4Z3LDuzZMqT8OqQQmvJwAhAW1SV9nIPjH3fRP12SJhS3TXvp7AxqrfWhWaxAkH JvGYFHtE3OGidSFdn7LUkrwj+KwQYT4tDdMadVB5HMarE2Um6ZyRbmbAwPHXniwPw0FD EdkcqiCeJu9SGPLSAOmAmyM3iYbdT15Imvp0Gd1DLSIIantHaBwBZbsctDpqO6STRAxB CYTZFXnJse3dtJJGF4XDg+edgqJMxvk9+w0hCgtgWwLGWrkolnP9xMa7xHP9dyZ1sA4T QE+A== X-Received: by 10.70.54.162 with SMTP id k2mr4271553pdp.138.1406139463698; Wed, 23 Jul 2014 11:17:43 -0700 (PDT) Received: from [192.168.1.102] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id fm8sm11311440pab.28.2014.07.23.11.17.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Jul 2014 11:17:42 -0700 (PDT) Message-ID: <1406139461.3025.178.camel@localhost> From: Rex Buddenberg To: Rick Taylor Date: Wed, 23 Jul 2014 11:17:41 -0700 In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DA75D@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> <1406135581.3025.160.camel@localhost> ,<84585478AABBBF4B9DF597FC0F84AF734304304B@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DA75D@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-2.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RBEPssJLFcIvBbIfYJuQygCzkMo Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 18:17:47 -0000 Rick, Brian, Working the interface between layer 2 and layer 3 is always, er, interesting. One of the things I was suggesting was use of IEEE 802's agreed language for layer 2 artifacts (e.g. BS and SS instead of 'modem'). This is a social problem getting a couple of different engineering communities talking accurately. I probably was a little overextending this by delving into the specific MAC parts of 802.16 ... back some of that up. 'Radio magic'. Here we have another case of multiple communities communicating awkwardly (I have the scars*). 802.16 was derived from DOCSIS. The working group essentially used the layer 2 MAC from DOCSIS and bolted on a radio interface instead of cable. So I'd have a hard time saying anything that I'd waved at you earlier 'radio magic'. 'MAC magic' perhaps. *if you want a sample, track down the 101 different uses of the term 'waveform'. Brian, I would be interested in more information about > our entire tdma access control Most satcom programs have been somewhat proprietary about such information. Hopefully shedding light and not so much heat. b On Wed, 2014-07-23 at 17:41 +0000, Rick Taylor wrote: > Rex, > > I'm with Brian on this one, in DLEP terms what you discuss is definitely 'radio magic', and the intention of a reference implementation is to demonstrate via code how one might go about implementing DLEP for a router or radio. The details of the radio is definitely out of scope; I don't want to get caught up in a TDMA/CDMA/whatever emulator. > > My musings about a console interface to the DLEP code in radio mode is more along the lines of: > > >New Link Radio 3 to Radio 2 > Radio 3 is now linked to radio by link 7. > >Link 7 CDR 2300, Up > Link 7 now up, CDR: 2300Kbps. > DLEP Destination_Up signals sent to: Radio 3, Radio 2. > >Quit > Goodbye... > > Does that clarify? > > Rick From nobody Wed Jul 23 11:35:21 2014 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 3482D1B2C02 for ; Wed, 23 Jul 2014 11:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 OLerN80SDA_g for ; Wed, 23 Jul 2014 11:35:17 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id EEE1B1B2BB1 for ; Wed, 23 Jul 2014 11:35:16 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,718,1400040000"; d="scan'208";a="2538558" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 23 Jul 2014 14:35:15 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Wed, 23 Jul 2014 14:35:15 -0400 From: "Snyder, Brian" To: Rex Buddenberg , Rick Taylor Thread-Topic: [manet] New DLEP reference implementation? Thread-Index: Ac+mj2DzVr3RxrSsTQyTtNO4sweulQAK4F6AAAfNgfD//8mMgIAAChmAgAA+f4A= Date: Wed, 23 Jul 2014 18:35:15 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343044594@VAUS-MBX03.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA703@tss-server1.home.tropicalstormsoftware.com> <1406135581.3025.160.camel@localhost> ,<84585478AABBBF4B9DF597FC0F84AF734304304B@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DA75D@tss-server1.home.tropicalstormsoftware.com> <1406139461.3025.178.camel@localhost> In-Reply-To: <1406139461.3025.178.camel@localhost> 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: http://mailarchive.ietf.org/arch/msg/manet/k36zFtAX1ilwmdNjwEd8hlmQkd4 Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 18:35:18 -0000 Rex, I would have check with the suits about sharing anything like that. I'm not= sure what the status is, I'm guessing (even mostly sure) its considered pr= oprietary. Regardless though, it's a different discussion that doesn't hav= e anything to do with DLEP or MANET in particular. Thanks, Brian -----Original Message----- From: Rex Buddenberg [mailto:buddenbergr@gmail.com]=20 Sent: Wednesday, July 23, 2014 2:18 PM To: Rick Taylor Cc: Snyder, Brian; manet@ietf.org Subject: Re: [manet] New DLEP reference implementation? Rick, Brian, Working the interface between layer 2 and layer 3 is always, er, interestin= g. One of the things I was suggesting was use of IEEE 802's agreed languag= e for layer 2 artifacts (e.g. BS and SS instead of 'modem'). This is a soc= ial problem getting a couple of different engineering communities talking a= ccurately. =20 I probably was a little overextending this by delving into the specifi= c MAC parts of 802.16 ... back some of that up. 'Radio magic'. Here we have another case of multiple communities communica= ting awkwardly (I have the scars*). 802.16 was derived from DOCSIS. The w= orking group essentially used the layer 2 MAC from DOCSIS and bolted on a r= adio interface instead of cable. So I'd have a hard time saying anything t= hat I'd waved at you earlier 'radio magic'. 'MAC magic' perhaps. *if you want a sample, track down the 101 different uses of the term 'wavef= orm'. =20 Brian, I would be interested in more information about =20 > our entire tdma access control Most satcom programs have been somewhat proprietary about such information.= =20 Hopefully shedding light and not so much heat. b On Wed, 2014-07-23 at 17:41 +0000, Rick Taylor wrote: > Rex, >=20 > I'm with Brian on this one, in DLEP terms what you discuss is definitely = 'radio magic', and the intention of a reference implementation is to demons= trate via code how one might go about implementing DLEP for a router or rad= io. The details of the radio is definitely out of scope; I don't want to g= et caught up in a TDMA/CDMA/whatever emulator. >=20 > My musings about a console interface to the DLEP code in radio mode is mo= re along the lines of: >=20 > >New Link Radio 3 to Radio 2 > Radio 3 is now linked to radio by link 7. > >Link 7 CDR 2300, Up > Link 7 now up, CDR: 2300Kbps. > DLEP Destination_Up signals sent to: Radio 3, Radio 2. > >Quit > Goodbye...=20 >=20 > Does that clarify? >=20 > Rick From nobody Wed Jul 23 12:25:52 2014 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 9A3AF1B2B50 for ; Wed, 23 Jul 2014 12:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 RjeN7azk_t0K for ; Wed, 23 Jul 2014 12:25:49 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 863811B2AC9 for ; Wed, 23 Jul 2014 12:25:48 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 23 Jul 2014 20:25:02 +0100 From: Rick Taylor To: "Snyder, Brian" , Rex Buddenberg Thread-Topic: [manet] New DLEP reference implementation? Thread-Index: AQHPppleaw6hJTgkMESA3tboDiPRgZut2mEAgAARmUb///rXgIAABOmAgAAerDE= Date: Wed, 23 Jul 2014 19:25:01 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DA849@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801148DA849tssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ohLonlFGsM9t-2vyBXF7GOj74Lc Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 19:25:50 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801148DA849tssserver1hom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rex The main objective of DLEP is to hide the details of the operation and topo= logy of the radio net from attached routers and just provide a simple commo= n signalling protocol for the local link between one radio and its attached= modems. Any reference implementation must follow this abstraction by definitely not= getting into specific modem/waveform modelling. Hope that helps Rick Sent from my HTC ----- Reply message ----- From: "Snyder, Brian" To: "Rex Buddenberg" , "Rick Taylor" Cc: "manet@ietf.org" Subject: [manet] New DLEP reference implementation? Date: Wed, Jul 23, 2014 14:35 Rex, I would have check with the suits about sharing anything like that. I'm not= sure what the status is, I'm guessing (even mostly sure) its considered pr= oprietary. Regardless though, it's a different discussion that doesn't hav= e anything to do with DLEP or MANET in particular. Thanks, Brian -----Original Message----- From: Rex Buddenberg [mailto:buddenbergr@gmail.com] Sent: Wednesday, July 23, 2014 2:18 PM To: Rick Taylor Cc: Snyder, Brian; manet@ietf.org Subject: Re: [manet] New DLEP reference implementation? Rick, Brian, Working the interface between layer 2 and layer 3 is always, er, interestin= g. One of the things I was suggesting was use of IEEE 802's agreed languag= e for layer 2 artifacts (e.g. BS and SS instead of 'modem'). This is a soc= ial problem getting a couple of different engineering communities talking a= ccurately. I probably was a little overextending this by delving into the specifi= c MAC parts of 802.16 ... back some of that up. 'Radio magic'. Here we have another case of multiple communities communica= ting awkwardly (I have the scars*). 802.16 was derived from DOCSIS. The w= orking group essentially used the layer 2 MAC from DOCSIS and bolted on a r= adio interface instead of cable. So I'd have a hard time saying anything t= hat I'd waved at you earlier 'radio magic'. 'MAC magic' perhaps. *if you want a sample, track down the 101 different uses of the term 'wavef= orm'. Brian, I would be interested in more information about > our entire tdma access control Most satcom programs have been somewhat proprietary about such information. Hopefully shedding light and not so much heat. b On Wed, 2014-07-23 at 17:41 +0000, Rick Taylor wrote: > Rex, > > I'm with Brian on this one, in DLEP terms what you discuss is definitely = 'radio magic', and the intention of a reference implementation is to demons= trate via code how one might go about implementing DLEP for a router or rad= io. The details of the radio is definitely out of scope; I don't want to g= et caught up in a TDMA/CDMA/whatever emulator. > > My musings about a console interface to the DLEP code in radio mode is mo= re along the lines of: > > >New Link Radio 3 to Radio 2 > Radio 3 is now linked to radio by link 7. > >Link 7 CDR 2300, Up > Link 7 now up, CDR: 2300Kbps. > DLEP Destination_Up signals sent to: Radio 3, Radio 2. > >Quit > Goodbye... > > Does that clarify? > > Rick --_000_38A5475DE83986499AEACD2CFAFC3F9801148DA849tssserver1hom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
=
Rex

The main objective of DLEP is to hide the= details of the operation and topology of the radio net from attached route= rs and just provide a simple common signalling protocol for the local link = between one radio and its attached modems.

Any ref= erence implementation must follow this abstraction by definitely not gettin= g into specific modem/waveform modelling.

Hope tha= t helps

Rick

Sent from my= HTC

----- Reply message -----
From: &= quot;Snyder, Brian" <bsnyder@idirect.net>
To: "Rex Budde= nberg" <buddenbergr@gmail.com>, "Rick Taylor" <rick= @tropicalstormsoftware.com>
Cc: "manet@ietf.org" <manet@= ietf.org>
Subject: [manet] New DLEP reference implementation?
Date= : Wed, Jul 23, 2014 14:35

R= ex,

I would have check with the suits about sharing anything like that. I'm not= sure what the status is, I'm guessing (even mostly sure) its considered pr= oprietary.  Regardless though, it's a different discussion that doesn'= t have anything to do with DLEP or MANET in particular.

Thanks,
Brian

-----Original Message-----
From: Rex Buddenberg [mailto:budde= nbergr@gmail.com]
Sent: Wednesday, July 23, 2014 2:18 PM
To: Rick Taylor
Cc: Snyder, Brian; manet@ietf.org
Subject: Re: [manet] New DLEP reference implementation?

Rick, Brian,

Working the interface between layer 2 and layer 3 is always, er, interestin= g.  One of the things I was suggesting was use of IEEE 802's agreed la= nguage for layer 2 artifacts (e.g. BS and SS instead of 'modem').  Thi= s is a social problem getting a couple of different engineering communities= talking accurately. 
     I probably was a little overextending this by delv= ing into the specific MAC parts of 802.16 ... back some of that up.

'Radio magic'.  Here we have another case of multiple communities comm= unicating awkwardly (I have the scars*).  802.16 was derived from DOCS= IS.  The working group essentially used the layer 2 MAC from DOCSIS an= d bolted on a radio interface instead of cable.  So I'd have a hard ti= me saying anything that I'd waved at you earlier 'radio magic'.  'MAC = magic' perhaps.


*if you want a sample, track down the 101 different uses of the term 'wavef= orm'. 


Brian, I would be interested in more information about 
> our entire tdma access control
Most satcom programs have been somewhat proprietary about such information.=  

Hopefully shedding light and not so much heat.

b



On Wed, 2014-07-23 at 17:41 +0000, Rick Taylor wrote:
> Rex,
>
> I'm with Brian on this one, in DLEP terms what you discuss is definite= ly 'radio magic', and the intention of a reference implementation is to dem= onstrate via code how one might go about implementing DLEP for a router or = radio.  The details of the radio is definitely out of scope; I don't w= ant to get caught up in a TDMA/CDMA/whatever emulator.
>
> My musings about a console interface to the DLEP code in radio mode is= more along the lines of:
>
> >New Link Radio 3 to Radio 2
> Radio 3 is now linked to radio by link 7.
> >Link 7 CDR 2300, Up
> Link 7 now up, CDR: 2300Kbps.
> DLEP Destination_Up signals sent to: Radio 3, Radio 2.
> >Quit
> Goodbye...
>
> Does that clarify?
>
> Rick


 --_000_38A5475DE83986499AEACD2CFAFC3F9801148DA849tssserver1hom_-- From nobody Wed Jul 23 13:39:54 2014 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 527401B2A34 for ; Wed, 23 Jul 2014 13:39:52 -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 aPJ2EW5X5Q93 for ; Wed, 23 Jul 2014 13:39:51 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16771B2A61 for ; Wed, 23 Jul 2014 13:39:47 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so2284969pdj.1 for ; Wed, 23 Jul 2014 13:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=iknHHsdQHoCW5JO8nZAqUthkUr8N8AnnxpfZglTkYgA=; b=krh6gzIILNIR/SItG+pGhUAbhlxqFY7qJJ2Ld3qvPnQV6z7OXMKTjxgKsslyee99dy xljc17K9dq9xsO+ewx6OmkS9j04TRb3FzvES1BTOcOLQC1q4L5BtqaR6kecJEKetOlN4 wD6dsAxYlpeUCarMAK6pp3Zmo1COvJxhWwZP67SbJG+2D9hkmOKUifYVE4Jpz9h3A3ga lJuyuJ8N/g9UUgCd5gNE3rKu5JRdGjYSjOEf+IBccBAK4KlvIEzBqXovH642RGEbWSwq Rrb8jTGuyowlsofWm808PdI66yzUSQAMlCe8flv7p0MjwRRSjK1oDgRrBO3WqyukMpQP LFuw== X-Received: by 10.66.100.170 with SMTP id ez10mr5253783pab.12.1406147987520; Wed, 23 Jul 2014 13:39:47 -0700 (PDT) Received: from [192.168.1.102] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id d13sm3290033pbu.72.2014.07.23.13.39.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:39:46 -0700 (PDT) Message-ID: <1406147985.3025.184.camel@localhost> From: Rex Buddenberg To: Rick Taylor Date: Wed, 23 Jul 2014 13:39:45 -0700 In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DA849@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DA849@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-2.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-dLlPRbrdDX_7bDXZNjTv3z3X9w Cc: "manet@ietf.org" Subject: Re: [manet] New DLEP reference implementation? 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, 23 Jul 2014 20:39:52 -0000 On Wed, 2014-07-23 at 19:25 +0000, Rick Taylor wrote: > Rex > > > The main objective of DLEP is to hide the details of the operation and > topology of the radio net from attached routers and just provide a > simple common signalling protocol for the local link between one radio > and its attached modems. Violently agreeing, Rick. > > > Any reference implementation must follow this abstraction by > definitely not getting into specific modem/waveform modelling. Also again we agree. Writing a layer 2/layer 3 interface protocol must be difficult -- we've tried many times and for naught. (Not just in MANET -- autconf, pilc; IEEE 802 has also got a false start or two -- 802.23). While the interface needs to be simple, it needs to be crafted from knowledge of the complexities on both sides of the layer boundary -- apparently not an easy paradox. > > > Hope that helps > > > Rick > > > Sent from my HTC > > ----- Reply message ----- > From: "Snyder, Brian" > To: "Rex Buddenberg" , "Rick Taylor" > > Cc: "manet@ietf.org" > Subject: [manet] New DLEP reference implementation? > Date: Wed, Jul 23, 2014 14:35 > > > Rex, > > I would have check with the suits about sharing anything like that. > I'm not sure what the status is, I'm guessing (even mostly sure) its > considered proprietary. Regardless though, it's a different > discussion that doesn't have anything to do with DLEP or MANET in > particular. > > Thanks, > Brian > > -----Original Message----- > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > Sent: Wednesday, July 23, 2014 2:18 PM > To: Rick Taylor > Cc: Snyder, Brian; manet@ietf.org > Subject: Re: [manet] New DLEP reference implementation? > > Rick, Brian, > > Working the interface between layer 2 and layer 3 is always, er, > interesting. One of the things I was suggesting was use of IEEE 802's > agreed language for layer 2 artifacts (e.g. BS and SS instead of > 'modem'). This is a social problem getting a couple of different > engineering communities talking accurately. > I probably was a little overextending this by delving into the > specific MAC parts of 802.16 ... back some of that up. > > 'Radio magic'. Here we have another case of multiple communities > communicating awkwardly (I have the scars*). 802.16 was derived from > DOCSIS. The working group essentially used the layer 2 MAC from > DOCSIS and bolted on a radio interface instead of cable. So I'd have > a hard time saying anything that I'd waved at you earlier 'radio > magic'. 'MAC magic' perhaps. > > > *if you want a sample, track down the 101 different uses of the term > 'waveform'. > > > Brian, I would be interested in more information about > > our entire tdma access control > Most satcom programs have been somewhat proprietary about such > information. > > Hopefully shedding light and not so much heat. > > b > > > > On Wed, 2014-07-23 at 17:41 +0000, Rick Taylor wrote: > > Rex, > > > > I'm with Brian on this one, in DLEP terms what you discuss is > definitely 'radio magic', and the intention of a reference > implementation is to demonstrate via code how one might go about > implementing DLEP for a router or radio. The details of the radio is > definitely out of scope; I don't want to get caught up in a > TDMA/CDMA/whatever emulator. > > > > My musings about a console interface to the DLEP code in radio mode > is more along the lines of: > > > > >New Link Radio 3 to Radio 2 > > Radio 3 is now linked to radio by link 7. > > >Link 7 CDR 2300, Up > > Link 7 now up, CDR: 2300Kbps. > > DLEP Destination_Up signals sent to: Radio 3, Radio 2. > > >Quit > > Goodbye... > > > > Does that clarify? > > > > Rick > > > From nobody Wed Jul 23 14:41:43 2014 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 801AB1B281C for ; Wed, 23 Jul 2014 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 DL8zOg7jQOAd for ; Wed, 23 Jul 2014 14:41:40 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6EE1B280A for ; Wed, 23 Jul 2014 14:41:40 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2934764wiv.15 for ; Wed, 23 Jul 2014 14:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ApoVdef8wyUMuE2Vm3SQ1U6ACYPm77qf0OUaEYUifz8=; b=jWFLZhbeZNhpXrf5a4N7Lk43AVAA8VqG5Hj3M+1HNgjmhqfnSnI0Xx6U1M7NMQ8qWm S1Ia2w7RTVVZEqHCOP34WFF6jnaWUSzO68hGFfasODcVEJ+YtnDamQgTBzcKUcSkx2Ur XCMKOWQLmZgWKGLi6pX+zxbbntzlB8b49qrKlcdbqBZlbLduG4cSNtT/ZoU+tKKAqiFC 3VPHC5sNY7dH6QPzeFWqUt8H4FKmpkjrq7m5whMelibBy2MioNZxt4NB65gOe0AW0G88 AuKFf/EYWZS/1XsOYuU+OGctEvEB4ZhD0g9DPHO3NkJuIP4Ta6vi0KMEZ+RIYCowFK8e KQOw== MIME-Version: 1.0 X-Received: by 10.194.237.135 with SMTP id vc7mr6119656wjc.86.1406151698790; Wed, 23 Jul 2014 14:41:38 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Wed, 23 Jul 2014 14:41:38 -0700 (PDT) In-Reply-To: References: <20140722173202.11282.8433.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 23:41:38 +0200 X-Google-Sender-Auth: RLd--egpej3K7_sft5Gb2oh8PIM Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0149414881bf7404fee33487 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/mMhC5eyo1_jNFhS2ggMxlrLjrWE Cc: manet Subject: Re: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-01.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, 23 Jul 2014 21:41:41 -0000 --089e0149414881bf7404fee33487 Content-Type: text/plain; charset=UTF-8 Hi, There will be a source-routing header, but it won't be costly. We are using loose source routing: if we have 100 hops, there is no need to keep all the 100 addresses in the header, but a few key routers that must go through. For the forwarding between the key routers, OLSRv2 will take care of if by it's own routing table. Experiments show that we are quite safe to get desired disjoint paths using loose source routing. For IPv6, which has relatively long address, RFC6554 provided a compressing mechanism if the routers share a common prefix. regards Jiazi On Wed, Jul 23, 2014 at 12:48 PM, Henning Rogge wrote: > On Tue, Jul 22, 2014 at 7:38 PM, Jiazi YI wrote: > > Hi, > > > > We just submitted a new revision of the olsrv2-multipath. > > The major modification is a new subsection, stating the motivation of > being > > experimental, and the experiments to be conducted. > > Just a question I forgot to ask yesterday... how does this multipath > apporach deal with the MTU problem? Using source-routing costs a lot > of MTU. > > Henning Rogge > --089e0149414881bf7404fee33487 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

There will be a source-routin= g header, but it won't be costly.=C2=A0

We are= using loose source routing: if we have 100 hops, there is no need to keep = all the 100 addresses in the header, but a few key routers that must go thr= ough. For the forwarding between the key routers, OLSRv2 will take care of = if by it's own routing table. Experiments show that we are quite safe t= o get desired disjoint paths using loose source routing.=C2=A0

For IPv6, which has relatively long address, RFC6554 pr= ovided a compressing mechanism if the routers share a common prefix.=C2=A0<= /div>

regards

Jiazi
<= div class=3D"gmail_extra">

On Wed, Jul 23, 2014 at 12:48 PM, Hennin= g Rogge <hrogge@gmail.com> wrote:
On Tue, Jul 22, 2014 at 7:38 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Hi,
>
> We just submitted a new revision of the olsrv2-multipath.
> The major modification is a new subsection, stating the motivation of = being
> experimental, and the experiments to be conducted.

Just a question I forgot to ask yesterday... how does this multipath<= br> apporach deal with the MTU problem? Using source-routing costs a lot
of MTU.

Henning Rogge

--089e0149414881bf7404fee33487-- From nobody Thu Jul 24 00:33:08 2014 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 3F35D1A00EF for ; Thu, 24 Jul 2014 00:33:06 -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 0c5goEymiTBx for ; Thu, 24 Jul 2014 00:33:05 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C933D1A00DD for ; Thu, 24 Jul 2014 00:33:04 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so2786763qgd.5 for ; Thu, 24 Jul 2014 00:33:04 -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=xcUPB+W5fIalK9wcrnCHlX5UepKL+d4PW63uoBygCik=; b=w4HsVCgQdvhFVsJt4ONtIAwdlYJJlO/sKWLAhuyEqQUbXjxsh9KO16pcK32Ma1rnVt eNXSc5SZ/xRu9zgGCz22PsAB1C5CvaKHN6gsKlmkXKyOlp3MPgcXAvaxOUxJoIMBy270 RQCUaFFh/Ay5kMWoZ/s6/q6hYPfjsQXJ3SErHCd0eELMnzCalDeGL0Sk7dcfurF8LxyP vS8chUZHlsOc/w3/NkuvTs272T0Fxf6w1r44MTF+HJHz5nZzLgcqmrWbfzDSlfgQLP93 +M7LKpX1CN+PVmfHRLwUJGUfWGCmxpf6cYcSAAQePw0l0Sp9quhrm9kTvsbQLWervaMv R3Aw== X-Received: by 10.224.103.134 with SMTP id k6mr12296328qao.24.1406187183955; Thu, 24 Jul 2014 00:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Thu, 24 Jul 2014 00:32:43 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 24 Jul 2014 09:32:43 +0200 Message-ID: To: John Dowdell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zxN2twRIduETBODMWQ7d16lgaa4 Cc: "DLEP Research Group \(manet-dlep-rg@ietf.org\)" , "manet@ietf.org" Subject: Re: [manet] DLEP Interop Event 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, 24 Jul 2014 07:33:06 -0000 On Wed, Jul 23, 2014 at 5:05 PM, John Dowdell wrote: > All > > Lack of time meant I could not announce this yesterday in the meeting. > > Good progress has been made on the DLEP draft in the last few meetings, and > I believe the draft is nearly ready for some testing. To this end, I > intended to offer a DLEP Interop meeting some time during Q1 2015, to take > place in south-east Wales, UK. Please bring your routers and modems for > testing! > > Venue: Tredegar House, Newport, South Wales, UK > Venue website: http://www.nationaltrust.org.uk/tredegar-house/ > Host: Airbus Defence and Space > Host website: http://airbusdefenceandspace.com/ > > Further details will be offered nearer the time. > > Please note that if you plan on transmitting RF to air, an OFCOM temporary > test license may be needed if you are outside of the UK license free bands > and power limits. Please contact me for further information and assistance, > since we have a local OFCOM contact. OFCOM is the UK regulator for > communications, http://www.ofcom.org.uk/. I think that is a really nice idea... we will definitely try to attend the interop meeting. Hopefully we will also have enough time to fix a few bugs during the testing. Henning Rogge From nobody Thu Jul 24 01:59:35 2014 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 8BBAC1A00FF; Thu, 24 Jul 2014 01:59:29 -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 9NyCeAV2i_U8; Thu, 24 Jul 2014 01:59:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7471A0101; Thu, 24 Jul 2014 01:59:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724085925.32424.63466.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 01:59:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hk1lR2Ohqwl8_YzIhFiaVJXvAuA Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-ibs-01.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, 24 Jul 2014 08:59:29 -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 : Identity-Based Signatures for MANET Routing Protocols Author : Christopher Dearlove Filename : draft-ietf-manet-ibs-01.txt Pages : 15 Date : 2014-07-24 Abstract: This document extends [RFC7182], which specifies a framework for, and specific examples of, integrity check values (ICVs) for packets and messages using the generalized packet/message format specified in [RFC5444]. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an identity-based signature, defined according to the ECCSI (Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption) algorithm specified in [RFC6507]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-ibs-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-ibs-01 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 Thu Jul 24 02:05:51 2014 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 6EBCF1A0144 for ; Thu, 24 Jul 2014 02:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 zTCz_cMAGmB5 for ; Thu, 24 Jul 2014 02:05:48 -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 29E341A0143 for ; Thu, 24 Jul 2014 02:05:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,722,1400022000"; d="scan'208,217";a="460444973" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Jul 2014 10:05:47 +0100 X-IronPort-AV: E=Sophos; i="5.01,722,1400022000"; d="scan'208,217"; a="58870160" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 24 Jul 2014 10:05:54 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 10:05:54 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: New IBS draft, request for WGLC Thread-Index: Ac+nHb7ZKZluW6PjSp6j+Cirn7lL9A== Date: Thu, 24 Jul 2014 09:05:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078A3GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6CLMjNEIr4N_N1-4Os1u2OeOfS4 Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" Subject: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 09:05:50 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078A3GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable A new version of the IBS draft should be posted by the time I've finished t= yping this. Thanks to Benjamin Smith for verifying the signature - twice, as I had made= a small error in M. (Doing it twice, that actually means each of us knows = the other did it independently.) I believe that completes the draft, as it's a small, specific, extension. I= therefore request that the chairs issue a WGLC for this with an appropriat= e duration for comments etc. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078A3GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

A new version of the IBS draft should be posted by t= he time I’ve finished typing this.

 

Thanks to Benjamin Smith for verifying the signature= – twice, as I had made a small error in M. (Doing it twice, that act= ually means each of us knows the other did it independently.)

 

I believe that completes the draft, as it’s a = small, specific, extension. I therefore request that the chairs issue a WGL= C for this with an appropriate duration for comments etc.

 

-- <= /p>

Christopher Dearlove

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

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

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

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078A3GLKXM0002VGREEN_-- From nobody Thu Jul 24 04:54:03 2014 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 255CD1A01DC for ; Thu, 24 Jul 2014 04:54:02 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FVMb9aQOEqdJ for ; Thu, 24 Jul 2014 04:54:00 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A4E1A0028 for ; Thu, 24 Jul 2014 04:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id A7D23D40509; Thu, 24 Jul 2014 04:53:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [107.18.111.63] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id E632AD54F59; Thu, 24 Jul 2014 04:53:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D8469600-A1BF-4052-ACC7-B1436D1E03A0 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Thu, 24 Jul 2014 07:53:55 -0400 Content-Transfer-Encoding: 7bit Message-Id: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> References: To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ls9adnteUBZWIM-SSH1dzgP3VYs Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 11:54:02 -0000 --Apple-Mail-D8469600-A1BF-4052-ACC7-B1436D1E03A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris, all, I have reviewed this latest version of the document, and I find it a useful a= nd well-shaped mechanism. I've definite plans to implement it, as it a neede= d mechanism in many deployments that I care about. I think that the document is ready to be WGLCed. I have one minor comment: it "updates RFC 7182" - yet, all I can see it does= to 7182 is make assignments from the registries defined therein, is this co= rrect? I.e., it doesn't *modify* the mechanisms specified in 7182? If so, i.e., if what it does is to make allocations from the 7182 registries= , then I wonder if the mechanism is actually "Updates RFC 7182"? Might be worth figuring out before it gets bounced around by the IESG, speci= fically the SEC-ADs? But, by all means, let's have a WGLC started of this document, and prod Adri= an for guidance on this point in parallel. Best, Thomas Sent from my iPad > On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" wrote: >=20 > A new version of the IBS draft should be posted by the time I=E2=80=99ve f= inished typing this. > =20 > Thanks to Benjamin Smith for verifying the signature =E2=80=93 twice, as I= had made a small error in M. (Doing it twice, that actually means each of u= s knows the other did it independently.) > =20 > I believe that completes the draft, as it=E2=80=99s a small, specific, ext= ension. I therefore request that the chairs issue a WGLC for this with an ap= propriate duration for comments etc. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-D8469600-A1BF-4052-ACC7-B1436D1E03A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Chris, all,

I= have reviewed this latest version of the document, and I find it a useful a= nd well-shaped mechanism. I've definite plans to implement it, as it a neede= d mechanism in many deployments that I care about.

= I think that the document is ready to be WGLCed.

I h= ave one minor comment: it "updates RFC 7182" - yet, all I can see it does to= 7182 is make assignments from the registries defined therein, is this corre= ct? I.e., it doesn't *modify* the mechanisms specified in 7182?
If so, i.e., if what it does is to make allocations from the 71= 82 registries, then I wonder if the mechanism is actually "Updates RFC 7182"= ?

Might be worth figuring out before it gets bounce= d around by the IESG, specifically the SEC-ADs?

But= , by all means, let's have a WGLC started of this document, and prod Adrian f= or guidance on this point in parallel.

Best,
<= div>
Thomas


Sent from my iPad

On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com= > wrote:

=

A new version of the IBS draft should be posted by th= e time I=E2=80=99ve finished typing this.

 

Thanks to Benjamin Smith for verifying the signature =E2= =80=93 twice, as I had made a small error in M. (Doing it twice, that actual= ly means each of us knows the other did it independently.)

 

I believe that completes the draft, as it=E2=80=99s a= small, specific, extension. I therefore request that the chairs issue a WGL= C for this with an appropriate duration for comments etc.

 

--

Christopher Dearlove

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

=

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

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

 

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

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-D8469600-A1BF-4052-ACC7-B1436D1E03A0-- From nobody Thu Jul 24 05:30:36 2014 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 D671D1A0243 for ; Thu, 24 Jul 2014 05:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ohglW3_IlpLG for ; Thu, 24 Jul 2014 05:30: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 21C351A02A5 for ; Thu, 24 Jul 2014 05:30:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,724,1400022000"; d="scan'208,217";a="460542952" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Jul 2014 13:30:18 +0100 X-IronPort-AV: E=Sophos; i="5.01,723,1400022000"; d="scan'208,217"; a="58904980" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 24 Jul 2014 13:30:26 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 13:30:26 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen Thread-Topic: [manet] New IBS draft, request for WGLC Thread-Index: Ac+nHb7ZKZluW6PjSp6j+Cirn7lL9AAD9FCAAAKr4BA= Date: Thu, 24 Jul 2014 12:30:26 +0000 Message-ID: References: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> In-Reply-To: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078F5GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xn-UolqWjD596iGqrs9IXJWtdhg Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 12:30:35 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078F5GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHRvIGFkbWl0IHRvIG5vdCB1bmRlcnN0YW5kaW5nIHdoZW4gdXBkYXRpbmcgYW5kIG5v dCB1cGRhdGluZy4gSSBrbm93IHdl4oCZdmUgaGFkIElFU0cgbWVtYmVycyBkaXNhZ3JlZWluZyBv biB0aGF0IHZlcnkgcG9pbnQgKGZvciBvbmUgb2Ygb3VyIGRvY3VtZW50cykgaW4gdGhlIHBhc3Qs IHNvIEkgbWF5IG5vdCBiZSBhbG9uZS4gQXMgZm9yIHdoYXTigJlzIGJlZW4gZG9uZSB3aXRoIHB1 Ymxpc2hlZCBSRkNzLCBJIGNlcnRhaW5seSBzZWUgdGhpbmdzIG1hcmtlZCBhcyB1cGRhdGVzIHRo YXQgYXJlIG5vdCBtdWNoIGRpZmZlcmVudCB0byB0aGlzLiBCdXQgbGlrZWx5IG90aGVycyBub3Qu DQoNCkJ1dCBpbiBzaG9ydCwgSSBkb27igJl0IGtub3csIGFuZCB3aWxsIHRha2UgZ3VpZGFuY2Ug ZnJvbSBhbnlvbmUgd2hvIGRvZXMga25vdy4gQWRyaWFuLCBhbnkgY29tbWVudD8NCg0KLS0NCkNo cmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlv biBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5h bHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUN Cldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhI TiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb20+IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0 aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4 NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0 IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZy b206IFRob21hcyBDbGF1c2VuIFttYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnXQ0KU2Vu dDogMjQgSnVseSAyMDE0IDEyOjU0DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNj OiBtYW5ldEBpZXRmLm9yZzsgbWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtYW5ldC1hZHNA dG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIE5ldyBJQlMgZHJhZnQsIHJlcXVl c3QgZm9yIFdHTEMNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBw YXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBz aG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4N CkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91 dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5l bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz L1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywg cGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdp dGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpDaHJpcywgYWxsLA0KDQpJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGFuZCBJIGZpbmQgaXQg YSB1c2VmdWwgYW5kIHdlbGwtc2hhcGVkIG1lY2hhbmlzbS4gSSd2ZSBkZWZpbml0ZSBwbGFucyB0 byBpbXBsZW1lbnQgaXQsIGFzIGl0IGEgbmVlZGVkIG1lY2hhbmlzbSBpbiBtYW55IGRlcGxveW1l bnRzIHRoYXQgSSBjYXJlIGFib3V0Lg0KDQpJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJl YWR5IHRvIGJlIFdHTENlZC4NCg0KSSBoYXZlIG9uZSBtaW5vciBjb21tZW50OiBpdCAidXBkYXRl cyBSRkMgNzE4MiIgLSB5ZXQsIGFsbCBJIGNhbiBzZWUgaXQgZG9lcyB0byA3MTgyIGlzIG1ha2Ug YXNzaWdubWVudHMgZnJvbSB0aGUgcmVnaXN0cmllcyBkZWZpbmVkIHRoZXJlaW4sIGlzIHRoaXMg Y29ycmVjdD8gSS5lLiwgaXQgZG9lc24ndCAqbW9kaWZ5KiB0aGUgbWVjaGFuaXNtcyBzcGVjaWZp ZWQgaW4gNzE4Mj8NCg0KSWYgc28sIGkuZS4sIGlmIHdoYXQgaXQgZG9lcyBpcyB0byBtYWtlIGFs bG9jYXRpb25zIGZyb20gdGhlIDcxODIgcmVnaXN0cmllcywgdGhlbiBJIHdvbmRlciBpZiB0aGUg bWVjaGFuaXNtIGlzIGFjdHVhbGx5ICJVcGRhdGVzIFJGQyA3MTgyIj8NCg0KTWlnaHQgYmUgd29y dGggZmlndXJpbmcgb3V0IGJlZm9yZSBpdCBnZXRzIGJvdW5jZWQgYXJvdW5kIGJ5IHRoZSBJRVNH LCBzcGVjaWZpY2FsbHkgdGhlIFNFQy1BRHM/DQoNCkJ1dCwgYnkgYWxsIG1lYW5zLCBsZXQncyBo YXZlIGEgV0dMQyBzdGFydGVkIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCBwcm9kIEFkcmlhbiBmb3Ig Z3VpZGFuY2Ugb24gdGhpcyBwb2ludCBpbiBwYXJhbGxlbC4NCg0KQmVzdCwNCg0KVGhvbWFzDQoN Cg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gMjQgSnVsIDIwMTQsIGF0IDA1OjA1LCAiRGVhcmxv dmUsIENocmlzdG9waGVyIChVSykiIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWls dG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCkEgbmV3IHZlcnNpb24g b2YgdGhlIElCUyBkcmFmdCBzaG91bGQgYmUgcG9zdGVkIGJ5IHRoZSB0aW1lIEnigJl2ZSBmaW5p c2hlZCB0eXBpbmcgdGhpcy4NCg0KVGhhbmtzIHRvIEJlbmphbWluIFNtaXRoIGZvciB2ZXJpZnlp bmcgdGhlIHNpZ25hdHVyZSDigJMgdHdpY2UsIGFzIEkgaGFkIG1hZGUgYSBzbWFsbCBlcnJvciBp biBNLiAoRG9pbmcgaXQgdHdpY2UsIHRoYXQgYWN0dWFsbHkgbWVhbnMgZWFjaCBvZiB1cyBrbm93 cyB0aGUgb3RoZXIgZGlkIGl0IGluZGVwZW5kZW50bHkuKQ0KDQpJIGJlbGlldmUgdGhhdCBjb21w bGV0ZXMgdGhlIGRyYWZ0LCBhcyBpdOKAmXMgYSBzbWFsbCwgc3BlY2lmaWMsIGV4dGVuc2lvbi4g SSB0aGVyZWZvcmUgcmVxdWVzdCB0aGF0IHRoZSBjaGFpcnMgaXNzdWUgYSBXR0xDIGZvciB0aGlz IHdpdGggYW4gYXBwcm9wcmlhdGUgZHVyYXRpb24gZm9yIGNvbW1lbnRzIGV0Yy4NCg0KLS0NCkNo cmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlv biBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5h bHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUN Cldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhI TiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb20+IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0 aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4 NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0 IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCg0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0 IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3Qg Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJp YnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGlu ZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078F5GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdC IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBoYXZl IHRvIGFkbWl0IHRvIG5vdCB1bmRlcnN0YW5kaW5nIHdoZW4gdXBkYXRpbmcgYW5kIG5vdCB1cGRh dGluZy4gSSBrbm93IHdl4oCZdmUgaGFkIElFU0cgbWVtYmVycyBkaXNhZ3JlZWluZyBvbiB0aGF0 IHZlcnkgcG9pbnQgKGZvciBvbmUgb2Ygb3VyIGRvY3VtZW50cykgaW4gdGhlIHBhc3QsIHNvIEkg bWF5IG5vdCBiZSBhbG9uZS4gQXMgZm9yIHdoYXTigJlzIGJlZW4NCiBkb25lIHdpdGggcHVibGlz aGVkIFJGQ3MsIEkgY2VydGFpbmx5IHNlZSB0aGluZ3MgbWFya2VkIGFzIHVwZGF0ZXMgdGhhdCBh cmUgbm90IG11Y2ggZGlmZmVyZW50IHRvIHRoaXMuIEJ1dCBsaWtlbHkgb3RoZXJzIG5vdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBpbiBzaG9ydCwgSSBkb27igJl0 IGtub3csIGFuZCB3aWxsIHRha2UgZ3VpZGFuY2UgZnJvbSBhbnlvbmUgd2hvIGRvZXMga25vdy4g QWRyaWFuLCBhbnkgY29tbWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdy b3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBh YmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQpX ZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4s IFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYjNDM7 NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29y YXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiB8IGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVnaXN0 ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3Nw YWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj4gVGhvbWFzDQogQ2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9tYXNj bGF1c2VuLm9yZ10gPGJyPg0KPGI+U2VudDo8L2I+IDI0IEp1bHkgMjAxNCAxMjo1NDxicj4NCjxi PlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0 QGlldGYub3JnOyBtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0LWFkc0B0b29scy5p ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBOZXcgSUJTIGRyYWZ0LCBy ZXF1ZXN0IGZvciBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286 cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48 L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxi cj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48 L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+ DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl bWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk JTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlz IHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzLCBhbGwsPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGxhdGVzdCB2ZXJzaW9u IG9mIHRoZSBkb2N1bWVudCwgYW5kIEkgZmluZCBpdCBhIHVzZWZ1bCBhbmQgd2VsbC1zaGFwZWQg bWVjaGFuaXNtLiBJJ3ZlIGRlZmluaXRlIHBsYW5zIHRvIGltcGxlbWVudCBpdCwgYXMgaXQgYSBu ZWVkZWQgbWVjaGFuaXNtIGluIG1hbnkgZGVwbG95bWVudHMgdGhhdCBJIGNhcmUgYWJvdXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgV0dMQ2VkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgb25lIG1pbm9y IGNvbW1lbnQ6IGl0ICZxdW90O3VwZGF0ZXMgUkZDIDcxODImcXVvdDsgLSB5ZXQsIGFsbCBJIGNh biBzZWUgaXQgZG9lcyB0byA3MTgyIGlzIG1ha2UgYXNzaWdubWVudHMgZnJvbSB0aGUgcmVnaXN0 cmllcyBkZWZpbmVkIHRoZXJlaW4sIGlzIHRoaXMgY29ycmVjdD8gSS5lLiwgaXQgZG9lc24ndCAq bW9kaWZ5KiB0aGUgbWVjaGFuaXNtcyBzcGVjaWZpZWQgaW4gNzE4Mj88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc28sIGkuZS4sIGlmIHdo YXQgaXQgZG9lcyBpcyB0byBtYWtlIGFsbG9jYXRpb25zIGZyb20gdGhlIDcxODIgcmVnaXN0cmll cywgdGhlbiBJIHdvbmRlciBpZiB0aGUgbWVjaGFuaXNtIGlzIGFjdHVhbGx5ICZxdW90O1VwZGF0 ZXMgUkZDIDcxODImcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1pZ2h0IGJlIHdvcnRoIGZpZ3VyaW5nIG91dCBiZWZvcmUgaXQgZ2V0 cyBib3VuY2VkIGFyb3VuZCBieSB0aGUgSUVTRywgc3BlY2lmaWNhbGx5IHRoZSBTRUMtQURzPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQs IGJ5IGFsbCBtZWFucywgbGV0J3MgaGF2ZSBhIFdHTEMgc3RhcnRlZCBvZiB0aGlzIGRvY3VtZW50 LCBhbmQgcHJvZCBBZHJpYW4gZm9yIGd1aWRhbmNlIG9uIHRoaXMgcG9pbnQgaW4gcGFyYWxsZWwu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJl c3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRob21hczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpTZW50IGZyb20gbXkgaVBhZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiAyNCBKdWwgMjAxNCwgYXQgMDU6MDUsICZxdW90O0RlYXJsb3ZlLCBDaHJpc3RvcGhlciAo VUspJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbmV3IHZlcnNp b24gb2YgdGhlIElCUyBkcmFmdCBzaG91bGQgYmUgcG9zdGVkIGJ5IHRoZSB0aW1lIEnigJl2ZSBm aW5pc2hlZCB0eXBpbmcgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIHRvIEJl bmphbWluIFNtaXRoIGZvciB2ZXJpZnlpbmcgdGhlIHNpZ25hdHVyZSDigJMgdHdpY2UsIGFzIEkg aGFkIG1hZGUgYSBzbWFsbCBlcnJvciBpbiBNLiAoRG9pbmcgaXQgdHdpY2UsIHRoYXQgYWN0dWFs bHkgbWVhbnMgZWFjaCBvZiB1cyBrbm93cyB0aGUgb3RoZXIgZGlkIGl0IGluZGVwZW5kZW50bHku KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhhdCBjb21wbGV0ZXMgdGhlIGRy YWZ0LCBhcyBpdOKAmXMgYSBzbWFsbCwgc3BlY2lmaWMsIGV4dGVuc2lvbi4gSSB0aGVyZWZvcmUg cmVxdWVzdCB0aGF0IHRoZSBjaGFpcnMgaXNzdWUgYSBXR0xDIGZvciB0aGlzIHdpdGggYW4gYXBw cm9wcmlhdGUgZHVyYXRpb24gZm9yIGNvbW1lbnRzIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaHJpc3Rv cGhlciBEZWFybG92ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJ bmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXA8YnI+DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3Mg YW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHk8YnI+DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBU ZWNobm9sb2d5IENlbnRyZTxicj4NCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRv dywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUs8YnI+DQpUZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQm bmJzcDt8Jm5ic3A7IEZheDogJiM0Mzs0NCAxMjQ1IDI0MjEyNDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48YSBo cmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTwvc3Bhbj48L2E+IHwNCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20i Pmh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgKE9w ZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwg UE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFu dHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBO bzogMTk5NjY4Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNp cGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZDxicj4NCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5k IG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpkaXN0cmlidXRlIGl0cyBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5l dCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0 QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D078F5GLKXM0002VGREEN_-- From nobody Thu Jul 24 05:36:07 2014 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 9918D1A02D8 for ; Thu, 24 Jul 2014 05:36:02 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5dHa5hp9oUrj for ; Thu, 24 Jul 2014 05:35:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A19C1A0295 for ; Thu, 24 Jul 2014 05:35:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 46F09247472; Thu, 24 Jul 2014 05:35:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [107.18.110.141] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0F8E4240533; Thu, 24 Jul 2014 05:35:58 -0700 (PDT) References: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-328A8D28-5633-4268-87C3-68F333E9D3F6 Content-Transfer-Encoding: 7bit Message-Id: <6CD44A55-2B8B-48E1-8881-A5EACE25DFB5@thomasclausen.org> X-Mailer: iPhone Mail (12A4318c) From: Thomas Heide Clausen Date: Thu, 24 Jul 2014 08:35:52 -0400 To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RdGSoVqSNHo2xz3y5yfWMh1RINw Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 12:36:03 -0000 --Apple-Mail-328A8D28-5633-4268-87C3-68F333E9D3F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 7181 does make allocations from registries created by 5444, but doesn't "Upd= ate rfc5444". That was my yardstick since both of those have flown by the ie= sg.=20 --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 > On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) wrote: >=20 > I have to admit to not understanding when updating and not updating. I kno= w we=E2=80=99ve had IESG members disagreeing on that very point (for one of o= ur documents) in the past, so I may not be alone. As for what=E2=80=99s been= done with published RFCs, I certainly see things marked as updates that are= not much different to this. But likely others not. > =20 > But in short, I don=E2=80=99t know, and will take guidance from anyone who= does know. Adrian, any comment? > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 24 July 2014 12:54 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org > Subject: Re: [manet] New IBS draft, request for WGLC > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Chris, all, > =20 > I have reviewed this latest version of the document, and I find it a usefu= l and well-shaped mechanism. I've definite plans to implement it, as it a ne= eded mechanism in many deployments that I care about. > =20 > I think that the document is ready to be WGLCed. > =20 > I have one minor comment: it "updates RFC 7182" - yet, all I can see it do= es to 7182 is make assignments from the registries defined therein, is this c= orrect? I.e., it doesn't *modify* the mechanisms specified in 7182? > =20 > If so, i.e., if what it does is to make allocations from the 7182 registri= es, then I wonder if the mechanism is actually "Updates RFC 7182"? > =20 > Might be worth figuring out before it gets bounced around by the IESG, spe= cifically the SEC-ADs? > =20 > But, by all means, let's have a WGLC started of this document, and prod Ad= rian for guidance on this point in parallel. > =20 > Best, > =20 > Thomas > =20 >=20 > Sent from my iPad >=20 > On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" wrote: >=20 > A new version of the IBS draft should be posted by the time I=E2=80=99ve f= inished typing this. > =20 > Thanks to Benjamin Smith for verifying the signature =E2=80=93 twice, as I= had made a small error in M. (Doing it twice, that actually means each of u= s knows the other did it independently.) > =20 > I believe that completes the draft, as it=E2=80=99s a small, specific, ext= ension. I therefore request that the chairs issue a WGLC for this with an ap= propriate duration for comments etc. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-328A8D28-5633-4268-87C3-68F333E9D3F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
7181 does make allocations from regist= ries created by 5444, but doesn't "Update rfc5444". That was my yardstick si= nce both of those have flown by the iesg. 

-- 
Thomas Heide Clausen

"Today's scientists= have substituted mathematics for 
  experiments, a= nd they wander off through equation 
  after equati= on, and eventually  build a structure 
  which= has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934
=

On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>= wrote:

I have to admit to not u= nderstanding when updating and not updating. I know we=E2=80=99ve had IESG m= embers disagreeing on that very point (for one of our documents) in the past= , so I may not be alone. As for what=E2=80=99s been done with published RFCs, I certainly see things marked as updates that are= not much different to this. But likely others not.

 

But in short, I don=E2=80= =99t know, and will take guidance from anyone who does know. Adrian, any com= ment?

 

--

Christopher Dearlove

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

=

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

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

 

From: Tho= mas Clausen [mailto:thomas@thomascl= ausen.org]
Sent: 24 July 2014 12:54
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org
Subject: Re: [manet] New IBS draft, request for WGLC

 

 

*** WARNING ***

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

Chris, all,

 

I have reviewed this latest version of the document, a= nd I find it a useful and well-shaped mechanism. I've definite plans to impl= ement it, as it a needed mechanism in many deployments that I care about.

 

I think that the document is ready to be WGLCed.=

 

I have one minor comment: it "updates RFC 7182" - yet= , all I can see it does to 7182 is make assignments from the registries defi= ned therein, is this correct? I.e., it doesn't *modify* the mechanisms speci= fied in 7182?

 

If so, i.e., if what it does is to make allocations f= rom the 7182 registries, then I wonder if the mechanism is actually "Updates= RFC 7182"?

 

Might be worth figuring out before it gets bounced ar= ound by the IESG, specifically the SEC-ADs?

 

But, by all means, let's have a WGLC started of this d= ocument, and prod Adrian for guidance on this point in parallel.<= /p>

 

Best,

 

Thomas

 


Sent from my iPad


On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:=

A new version of the IBS draft should be posted by th= e time I=E2=80=99ve finished typing this.

 

Thanks to Benjamin Smith for verifying the signature =E2= =80=93 twice, as I had made a small error in M. (Doing it twice, that actual= ly means each of us knows the other did it independently.)

 

I believe that completes the draft, as it=E2=80=99s a= small, specific, extension. I therefore request that the chairs issue a WGL= C for this with an appropriate duration for comments etc.

 

--

Christopher Dearlove

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

=

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

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

 

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

___________= ____________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

= --Apple-Mail-328A8D28-5633-4268-87C3-68F333E9D3F6-- From nobody Thu Jul 24 05:44:23 2014 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 820E01A0251 for ; Thu, 24 Jul 2014 05:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=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 X05ESUplibMQ for ; Thu, 24 Jul 2014 05:44:15 -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 41B8B1A024C for ; Thu, 24 Jul 2014 05:44:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,724,1400022000"; d="scan'208,217";a="389120478" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Jul 2014 13:44:12 +0100 X-IronPort-AV: E=Sophos; i="5.01,724,1400022000"; d="scan'208,217"; a="65948650" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 24 Jul 2014 13:44:20 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 13:44:20 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen Thread-Topic: [manet] New IBS draft, request for WGLC Thread-Index: Ac+nHb7ZKZluW6PjSp6j+Cirn7lL9AAD9FCAAAKr4BD///ZZAP//7vHw Date: Thu, 24 Jul 2014 12:44:20 +0000 Message-ID: References: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> <6CD44A55-2B8B-48E1-8881-A5EACE25DFB5@thomasclausen.org> In-Reply-To: <6CD44A55-2B8B-48E1-8881-A5EACE25DFB5@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0792CGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GEqFhIW5rGoVtafBxtBAIUbBLCA Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 12:44:18 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0792CGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgbm90IGEgYmFkIGV4YW1wbGUsIGJ1dCBJIHRoaW5rIHRoaXMgaXMgYSBsaXR0bGUg bW9yZSB0aWdodGx5IGJvdW5kLCBpbiB0d28gb3IgdGhyZWUgd2F5cy4NCg0KRmlyc3QsIDcxODIg c2F5cyB0aGF0IGlmIHlvdSBoYXZlIGEgY3J5cHRvIGFuZCBhIGhhc2ggeW91IGRvIGNyeXB0byho YXNoKGRhdGEpKSB1bmxlc3MgeW91ciBjcnlwdG8gcnVsZXMgc2F5IG90aGVyd2lzZS4gNzE4MiBz YXlzIG90aGVyd2lzZSBmb3IgSE1BQywgdGhpcyBzYXlzIG90aGVyd2lzZSBmb3IgaXRzIHR3byBm dW5jdGlvbnMuDQoNClNlY29uZCwgdGhpcyBjb3VsZCBiZSBzYWlkIHRvIHJlZGVmaW5lIHRoZSBt ZWFuaW5nIG9mIDxrZXktaWQ+IGluIHRoaXMgY2FzZS4NCg0KQSBwb3NzaWJsZSB0aGlyZCBwb2lu dCBpcyBJ4oCZbSBub3Qgc3VyZSBpZiA3MTgyIGltcGxpZXMgdGhhdCB0aGUgd2F5IHRvIGNoZWNr IGFuIElDViBpcyB0byByZWNhbGN1bGF0ZSBhbmQgY29tcGFyZS4gVGhlIGNvbmNlcHQgb2YgdHJ1 bmNhdGlvbiBkZXBlbmRzIG9uIHRoYXQuIEhlcmUgaG93ZXZlciB3ZSBkb27igJl0IHZlcmlmeSBp biB0aGF0IHdheSAoaXTigJlzIGluaGVyZW50bHkgaW1wb3NzaWJsZSkgYnV0IG5lZWRzIGEgc2Vw YXJhdGUgdmVyaWZ5IHByb2Nlc3MsIGFuZCB0cnVuY2F0aW9uIGlzIGRpc2FsbG93ZWQuDQoNCkJl aW5nIGEgbGl0dGxlIG1vcmUgdGlnaHRseSBib3VuZCBwdXRzIGl0IGJhY2sgaW4gbWF5YmUgYW4g dXBkYXRlLCBtYXliZSBub3QgdGVycml0b3J5LiBQZXJzb25hbGx5IEkgdGhpbmsgYXMgYW4gdXBk YXRlIGlzIG1vcmUgdXNlZnVsLCBidXQgY291bGQgZ28gZWl0aGVyIHdheS4NCg0KKElmIHdlIHdy b3RlIGEgZHJhZnQgdG8sIHNheSwgYWRkIFNIQS0zIGFzIGEgaGFzaCBmdW5jdGlvbiBjb2RlIHBv aW50LCB0aGF0IHdvdWxkIGJlIGEgc2ltcGxlIGFsbG9jYXRpb24gYW5kIG5vdCBhbiB1cGRhdGUs IEkgYWdyZWUuKQ0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwg RW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5l dHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNl ZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93 LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiAr NDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoN CkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fy d2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJu Ym9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogVGhvbWFzIEhlaWRlIENsYXVzZW4gW21haWx0bzp0aG9t YXNAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAyNCBKdWx5IDIwMTQgMTM6MzYNClRvOiBEZWFy bG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1hbmV0QGlldGYub3JnOyBtYW5ldC1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IG1hbmV0LWFkc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtt YW5ldF0gTmV3IElCUyBkcmFmdCwgcmVxdWVzdCBmb3IgV0dMQw0KDQoNCioqKiBXQVJOSU5HICoq Kg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQg RmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNs aWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVs IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRw Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4N CjcxODEgZG9lcyBtYWtlIGFsbG9jYXRpb25zIGZyb20gcmVnaXN0cmllcyBjcmVhdGVkIGJ5IDU0 NDQsIGJ1dCBkb2Vzbid0ICJVcGRhdGUgcmZjNTQ0NCIuIFRoYXQgd2FzIG15IHlhcmRzdGljayBz aW5jZSBib3RoIG9mIHRob3NlIGhhdmUgZmxvd24gYnkgdGhlIGllc2cuDQotLQ0KVGhvbWFzIEhl aWRlIENsYXVzZW4NCmh0dHA6Ly93d3cudGhvbWFzY2xhdXNlbi5vcmcNCg0KIlRvZGF5J3Mgc2Np ZW50aXN0cyBoYXZlIHN1YnN0aXR1dGVkIG1hdGhlbWF0aWNzIGZvcg0KICBleHBlcmltZW50cywg YW5kIHRoZXkgd2FuZGVyIG9mZiB0aHJvdWdoIGVxdWF0aW9uDQogIGFmdGVyIGVxdWF0aW9uLCBh bmQgZXZlbnR1YWxseSAgYnVpbGQgYSBzdHJ1Y3R1cmUNCiAgd2hpY2ggaGFzIG5vIHJlbGF0aW9u IHRvIHJlYWxpdHkuIg0KIC0gTmlrb2xhIFRlc2xhLA0KICAgIE1vZGVybiBNZWNoYW5pY3MgYW5k IEludmVudGlvbnMsIEp1bHksIDE5MzQNCg0KT24gMjQganVpbC4gMjAxNCwgYXQgMDg6MzAsIERl YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCkkgaGF2ZSB0byBh ZG1pdCB0byBub3QgdW5kZXJzdGFuZGluZyB3aGVuIHVwZGF0aW5nIGFuZCBub3QgdXBkYXRpbmcu IEkga25vdyB3ZeKAmXZlIGhhZCBJRVNHIG1lbWJlcnMgZGlzYWdyZWVpbmcgb24gdGhhdCB2ZXJ5 IHBvaW50IChmb3Igb25lIG9mIG91ciBkb2N1bWVudHMpIGluIHRoZSBwYXN0LCBzbyBJIG1heSBu b3QgYmUgYWxvbmUuIEFzIGZvciB3aGF04oCZcyBiZWVuIGRvbmUgd2l0aCBwdWJsaXNoZWQgUkZD cywgSSBjZXJ0YWlubHkgc2VlIHRoaW5ncyBtYXJrZWQgYXMgdXBkYXRlcyB0aGF0IGFyZSBub3Qg bXVjaCBkaWZmZXJlbnQgdG8gdGhpcy4gQnV0IGxpa2VseSBvdGhlcnMgbm90Lg0KDQpCdXQgaW4g c2hvcnQsIEkgZG9u4oCZdCBrbm93LCBhbmQgd2lsbCB0YWtlIGd1aWRhbmNlIGZyb20gYW55b25l IHdobyBkb2VzIGtub3cuIEFkcmlhbiwgYW55IGNvbW1lbnQ/DQoNCi0tDQpDaHJpc3RvcGhlciBE ZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNl IEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFi aWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5p bmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6 ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0 ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3Jv dWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQpGcm9tOiBUaG9tYXMg Q2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZ10NClNlbnQ6IDI0IEp1bHkg MjAxNCAxMjo1NA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogbWFuZXRAaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsgbWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBtYW5ldC1hZHNAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0LWFkc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbWFu ZXRdIE5ldyBJQlMgZHJhZnQsIHJlcXVlc3QgZm9yIFdHTEMNCg0KDQoqKiogV0FSTklORyAqKioN ClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVy IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu eSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZs YWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGlj ayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpD aHJpcywgYWxsLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBsYXRlc3QgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQsIGFuZCBJIGZpbmQgaXQgYSB1c2VmdWwgYW5kIHdlbGwtc2hhcGVkIG1lY2hhbmlz bS4gSSd2ZSBkZWZpbml0ZSBwbGFucyB0byBpbXBsZW1lbnQgaXQsIGFzIGl0IGEgbmVlZGVkIG1l Y2hhbmlzbSBpbiBtYW55IGRlcGxveW1lbnRzIHRoYXQgSSBjYXJlIGFib3V0Lg0KDQpJIHRoaW5r IHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIFdHTENlZC4NCg0KSSBoYXZlIG9uZSBt aW5vciBjb21tZW50OiBpdCAidXBkYXRlcyBSRkMgNzE4MiIgLSB5ZXQsIGFsbCBJIGNhbiBzZWUg aXQgZG9lcyB0byA3MTgyIGlzIG1ha2UgYXNzaWdubWVudHMgZnJvbSB0aGUgcmVnaXN0cmllcyBk ZWZpbmVkIHRoZXJlaW4sIGlzIHRoaXMgY29ycmVjdD8gSS5lLiwgaXQgZG9lc24ndCAqbW9kaWZ5 KiB0aGUgbWVjaGFuaXNtcyBzcGVjaWZpZWQgaW4gNzE4Mj8NCg0KSWYgc28sIGkuZS4sIGlmIHdo YXQgaXQgZG9lcyBpcyB0byBtYWtlIGFsbG9jYXRpb25zIGZyb20gdGhlIDcxODIgcmVnaXN0cmll cywgdGhlbiBJIHdvbmRlciBpZiB0aGUgbWVjaGFuaXNtIGlzIGFjdHVhbGx5ICJVcGRhdGVzIFJG QyA3MTgyIj8NCg0KTWlnaHQgYmUgd29ydGggZmlndXJpbmcgb3V0IGJlZm9yZSBpdCBnZXRzIGJv dW5jZWQgYXJvdW5kIGJ5IHRoZSBJRVNHLCBzcGVjaWZpY2FsbHkgdGhlIFNFQy1BRHM/DQoNCkJ1 dCwgYnkgYWxsIG1lYW5zLCBsZXQncyBoYXZlIGEgV0dMQyBzdGFydGVkIG9mIHRoaXMgZG9jdW1l bnQsIGFuZCBwcm9kIEFkcmlhbiBmb3IgZ3VpZGFuY2Ugb24gdGhpcyBwb2ludCBpbiBwYXJhbGxl bC4NCg0KQmVzdCwNCg0KVGhvbWFzDQoNCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gMjQgSnVs IDIwMTQsIGF0IDA1OjA1LCAiRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykiIDxjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+ PiB3cm90ZToNCkEgbmV3IHZlcnNpb24gb2YgdGhlIElCUyBkcmFmdCBzaG91bGQgYmUgcG9zdGVk IGJ5IHRoZSB0aW1lIEnigJl2ZSBmaW5pc2hlZCB0eXBpbmcgdGhpcy4NCg0KVGhhbmtzIHRvIEJl bmphbWluIFNtaXRoIGZvciB2ZXJpZnlpbmcgdGhlIHNpZ25hdHVyZSDigJMgdHdpY2UsIGFzIEkg aGFkIG1hZGUgYSBzbWFsbCBlcnJvciBpbiBNLiAoRG9pbmcgaXQgdHdpY2UsIHRoYXQgYWN0dWFs bHkgbWVhbnMgZWFjaCBvZiB1cyBrbm93cyB0aGUgb3RoZXIgZGlkIGl0IGluZGVwZW5kZW50bHku KQ0KDQpJIGJlbGlldmUgdGhhdCBjb21wbGV0ZXMgdGhlIGRyYWZ0LCBhcyBpdOKAmXMgYSBzbWFs bCwgc3BlY2lmaWMsIGV4dGVuc2lvbi4gSSB0aGVyZWZvcmUgcmVxdWVzdCB0aGF0IHRoZSBjaGFp cnMgaXNzdWUgYSBXR0xDIGZvciB0aGlzIHdpdGggYW4gYXBwcm9wcmlhdGUgZHVyYXRpb24gZm9y IGNvbW1lbnRzIGV0Yy4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNp cGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25z LCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2 YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZh eDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv bQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6 IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwg RmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAm IFdhbGVzIE5vOiAxOTk2Njg3DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJl Y2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUg c2VuZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl IG5vciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbi4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFu ZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0 DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0792CGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+VGhhdOKAmXMgbm90IGEgYmFkIGV4YW1wbGUsIGJ1dCBJIHRoaW5rIHRoaXMgaXMgYSBs aXR0bGUgbW9yZSB0aWdodGx5IGJvdW5kLCBpbiB0d28gb3IgdGhyZWUgd2F5cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZpcnN0LCA3MTgyIHNheXMgdGhhdCBpZiB5b3Ug aGF2ZSBhIGNyeXB0byBhbmQgYSBoYXNoIHlvdSBkbyBjcnlwdG8oaGFzaChkYXRhKSkgdW5sZXNz IHlvdXIgY3J5cHRvIHJ1bGVzIHNheSBvdGhlcndpc2UuIDcxODIgc2F5cyBvdGhlcndpc2UgZm9y IEhNQUMsIHRoaXMgc2F5cyBvdGhlcndpc2UgZm9yIGl0cyB0d28gZnVuY3Rpb25zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U2Vjb25kLCB0aGlzIGNvdWxkIGJlIHNhaWQg dG8gcmVkZWZpbmUgdGhlIG1lYW5pbmcgb2YgJmx0O2tleS1pZCZndDsgaW4gdGhpcyBjYXNlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QSBwb3NzaWJsZSB0aGlyZCBwb2lu dCBpcyBJ4oCZbSBub3Qgc3VyZSBpZiA3MTgyIGltcGxpZXMgdGhhdCB0aGUgd2F5IHRvIGNoZWNr IGFuIElDViBpcyB0byByZWNhbGN1bGF0ZSBhbmQgY29tcGFyZS4gVGhlIGNvbmNlcHQgb2YgdHJ1 bmNhdGlvbiBkZXBlbmRzIG9uIHRoYXQuIEhlcmUgaG93ZXZlciB3ZSBkb27igJl0IHZlcmlmeSBp biB0aGF0IHdheSAoaXTigJlzIGluaGVyZW50bHkNCiBpbXBvc3NpYmxlKSBidXQgbmVlZHMgYSBz ZXBhcmF0ZSB2ZXJpZnkgcHJvY2VzcywgYW5kIHRydW5jYXRpb24gaXMgZGlzYWxsb3dlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJlaW5nIGEgbGl0dGxlIG1vcmUgdGln aHRseSBib3VuZCBwdXRzIGl0IGJhY2sgaW4gbWF5YmUgYW4gdXBkYXRlLCBtYXliZSBub3QgdGVy cml0b3J5LiBQZXJzb25hbGx5IEkgdGhpbmsgYXMgYW4gdXBkYXRlIGlzIG1vcmUgdXNlZnVsLCBi dXQgY291bGQgZ28gZWl0aGVyIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPihJZiB3ZSB3cm90ZSBhIGRyYWZ0IHRvLCBzYXksIGFkZCBTSEEtMyBhcyBhIGhhc2ggZnVu Y3Rpb24gY29kZSBwb2ludCwgdGhhdCB3b3VsZCBiZSBhIHNpbXBsZSBhbGxvY2F0aW9uIGFuZCBu b3QgYW4gdXBkYXRlLCBJIGFncmVlLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNl IEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBD YXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+ DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4 SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYj NDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiB8 IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVn aXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVy b3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLUdCIj4gVGhvbWFzDQogSGVpZGUgQ2xhdXNlbiBbbWFpbHRvOnRob21h c0B0aG9tYXNjbGF1c2VuLm9yZ10gPGJyPg0KPGI+U2VudDo8L2I+IDI0IEp1bHkgMjAxNCAxMzoz Njxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8 L2I+IG1hbmV0QGlldGYub3JnOyBtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0LWFk c0B0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBOZXcgSUJT IGRyYWZ0LCByZXF1ZXN0IGZvciBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQg Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioq PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFs aWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBp bnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91 IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5 Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGlu ZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0 IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJh bmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1 bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5 b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0i aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv dGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBk ZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+NzE4MSBkb2VzIG1ha2UgYWxsb2NhdGlvbnMgZnJvbSByZWdpc3RyaWVzIGNy ZWF0ZWQgYnkgNTQ0NCwgYnV0IGRvZXNuJ3QgJnF1b3Q7VXBkYXRlIHJmYzU0NDQmcXVvdDsuIFRo YXQgd2FzIG15IHlhcmRzdGljayBzaW5jZSBib3RoIG9mIHRob3NlIGhhdmUgZmxvd24gYnkgdGhl IGllc2cuJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob21hcyBIZWlkZSBD bGF1c2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwOi8vd3d3LnRob21hc2NsYXVzZW4ub3JnIj5odHRwOi8vd3d3LnRob21h c2NsYXVzZW4ub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mcXVvdDtUb2RheSdzIHNjaWVudGlzdHMgaGF2ZSBzdWJzdGl0dXRlZCBt YXRoZW1hdGljcyBmb3ImbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwO2V4cGVyaW1lbnRzLCBhbmQgdGhleSB3YW5kZXIg b2ZmIHRocm91Z2ggZXF1YXRpb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwO2FmdGVyIGVxdWF0aW9uLCBhbmQgZXZl bnR1YWxseSAmbmJzcDtidWlsZCBhIHN0cnVjdHVyZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7d2hpY2ggaGFzIG5v IHJlbGF0aW9uIHRvIHJlYWxpdHkuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstIE5pa29sYSBUZXNsYSwmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyAmbmJzcDtNb2Rlcm4gTWVjaGFuaWNzIGFuZCBJbnZlbnRpb25zLCBKdWx5LCAxOTM0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjQganVpbC4gMjAxNCwgYXQgMDg6 MzAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGhhdmUgdG8gYWRtaXQgdG8g bm90IHVuZGVyc3RhbmRpbmcgd2hlbiB1cGRhdGluZyBhbmQgbm90IHVwZGF0aW5nLiBJIGtub3cg d2XigJl2ZSBoYWQgSUVTRyBtZW1iZXJzIGRpc2FncmVlaW5nIG9uIHRoYXQgdmVyeSBwb2ludCAo Zm9yIG9uZSBvZiBvdXIgZG9jdW1lbnRzKSBpbiB0aGUgcGFzdCwgc28gSSBtYXkgbm90IGJlIGFs b25lLiBBcyBmb3Igd2hhdOKAmXMgYmVlbg0KIGRvbmUgd2l0aCBwdWJsaXNoZWQgUkZDcywgSSBj ZXJ0YWlubHkgc2VlIHRoaW5ncyBtYXJrZWQgYXMgdXBkYXRlcyB0aGF0IGFyZSBub3QgbXVjaCBk aWZmZXJlbnQgdG8gdGhpcy4gQnV0IGxpa2VseSBvdGhlcnMgbm90Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QnV0IGluIHNob3J0LCBJIGRvbuKAmXQga25vdywgYW5kIHdp bGwgdGFrZSBndWlkYW5jZSBmcm9tIGFueW9uZSB3aG8gZG9lcyBrbm93LiBBZHJpYW4sIGFueSBj b21tZW50Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tIDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5DaHJpc3RvcGhlciBEZWFybG92ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXA8YnI+DQpDb21t dW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHk8YnI+DQpC QUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZTxicj4NCldlc3QgSGFubmluZ2Zp ZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUs8YnI+DQpUZWw6 ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7IEZheDogJiM0Mzs0NCAxMjQ1IDI0MjEy NDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj5j aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+IHwNCjxhIGhyZWY9Imh0dHA6 Ly93d3cuYmFlc3lzdGVtcy5jb20iPmh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208L2E+PGJyPg0K PGJyPg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9m ZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2Vu dHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4g RW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPiBUaG9tYXMNCiBDbGF1c2VuIFs8YSBocmVmPSJtYWlsdG86dGhvbWFzQHRob21h c2NsYXVzZW4ub3JnIj5tYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiAyNCBKdWx5IDIwMTQgMTI6NTQ8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3Zl LCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0LWNoYWly c0B0b29scy5pZXRmLm9yZyI+DQptYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86bWFuZXQtYWRzQHRvb2xzLmlldGYub3JnIj5tYW5ldC1hZHNAdG9vbHMuaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIE5ldyBJQlMgZHJhZnQs IHJlcXVlc3QgZm9yIFdHTEM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0 Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFu PjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bh bj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGlu IGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50 LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9S ZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVs IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRo aXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXMsIGFsbCw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZl IHJldmlld2VkIHRoaXMgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBhbmQgSSBmaW5k IGl0IGEgdXNlZnVsIGFuZCB3ZWxsLXNoYXBlZCBtZWNoYW5pc20uIEkndmUgZGVmaW5pdGUgcGxh bnMgdG8gaW1wbGVtZW50IGl0LCBhcyBpdCBhIG5lZWRlZCBtZWNoYW5pc20gaW4gbWFueSBkZXBs b3ltZW50cyB0aGF0IEkgY2FyZSBhYm91dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFk eSB0byBiZSBXR0xDZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgaGF2ZSBvbmUgbWlub3IgY29tbWVudDogaXQgJnF1b3Q7dXBkYXRlcyBS RkMgNzE4MiZxdW90OyAtIHlldCwgYWxsIEkgY2FuIHNlZSBpdCBkb2VzIHRvIDcxODIgaXMgbWFr ZSBhc3NpZ25tZW50cyBmcm9tIHRoZSByZWdpc3RyaWVzIGRlZmluZWQgdGhlcmVpbiwgaXMgdGhp cyBjb3JyZWN0PyBJLmUuLCBpdCBkb2Vzbid0ICptb2RpZnkqIHRoZSBtZWNoYW5pc21zIHNwZWNp ZmllZCBpbiA3MTgyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiBzbywgaS5lLiwgaWYgd2hhdCBpdCBkb2VzIGlzIHRvIG1ha2UgYWxsb2Nh dGlvbnMgZnJvbSB0aGUgNzE4MiByZWdpc3RyaWVzLCB0aGVuIEkgd29uZGVyIGlmIHRoZSBtZWNo YW5pc20gaXMgYWN0dWFsbHkgJnF1b3Q7VXBkYXRlcyBSRkMgNzE4MiZxdW90Oz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlnaHQgYmUgd29y dGggZmlndXJpbmcgb3V0IGJlZm9yZSBpdCBnZXRzIGJvdW5jZWQgYXJvdW5kIGJ5IHRoZSBJRVNH LCBzcGVjaWZpY2FsbHkgdGhlIFNFQy1BRHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCwgYnkgYWxsIG1lYW5zLCBsZXQncyBoYXZlIGEg V0dMQyBzdGFydGVkIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCBwcm9kIEFkcmlhbiBmb3IgZ3VpZGFu Y2Ugb24gdGhpcyBwb2ludCBpbiBwYXJhbGxlbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNlbnQgZnJvbSBteSBpUGFk PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDI0IEp1bCAyMDE0LCBhdCAwNTowNSwg JnF1b3Q7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QSBuZXcgdmVyc2lvbiBvZiB0aGUgSUJTIGRyYWZ0IHNob3VsZCBi ZSBwb3N0ZWQgYnkgdGhlIHRpbWUgSeKAmXZlIGZpbmlzaGVkIHR5cGluZyB0aGlzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgdG8gQmVuamFtaW4gU21pdGggZm9yIHZlcmlmeWluZyB0 aGUgc2lnbmF0dXJlIOKAkyB0d2ljZSwgYXMgSSBoYWQgbWFkZSBhIHNtYWxsIGVycm9yIGluIE0u IChEb2luZyBpdCB0d2ljZSwgdGhhdCBhY3R1YWxseSBtZWFucyBlYWNoIG9mIHVzIGtub3dzIHRo ZSBvdGhlciBkaWQgaXQgaW5kZXBlbmRlbnRseS4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YmVsaWV2ZSB0aGF0IGNvbXBsZXRlcyB0aGUgZHJhZnQsIGFzIGl04oCZcyBhIHNtYWxsLCBzcGVj aWZpYywgZXh0ZW5zaW9uLiBJIHRoZXJlZm9yZSByZXF1ZXN0IHRoYXQgdGhlIGNoYWlycyBpc3N1 ZSBhIFdHTEMgZm9yIHRoaXMgd2l0aCBhbiBhcHByb3ByaWF0ZSBkdXJhdGlvbiBmb3IgY29tbWVu dHMgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+LS0gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNocmlzdG9waGVyIERlYXJsb3ZlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxi cj4NCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0 eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBI YW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxi cj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEy NDUgMjQyMTI0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4gfA0KPGEgaHJl Zj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbSI+aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTwv YT48YnI+DQo8YnI+DQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZDxicj4NClJlZ2lz dGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9z cGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLPGJyPg0KUmVnaXN0 ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAxOTk2Njg3PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KWW91 IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9z ZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJy Pg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0792CGLKXM0002VGREEN_-- From nobody Thu Jul 24 07:02:49 2014 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 54B211A02EA for ; Thu, 24 Jul 2014 07:02:47 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 M7T7PJOl0CKz for ; Thu, 24 Jul 2014 07:02:38 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 279B71A0282 for ; Thu, 24 Jul 2014 07:02:38 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,724,1400040000"; d="scan'208,217";a="2561533" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport2.idirect.net with ESMTP; 24 Jul 2014 10:02:37 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Thu, 24 Jul 2014 10:02:37 -0400 From: "Snyder, Brian" To: "manet@ietf.org" Thread-Topic: Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQ== Date: Thu, 24 Jul 2014 14:02:37 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> 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_84585478AABBBF4B9DF597FC0F84AF7343045446VAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_6lTCnVa5OPgyHhZxwS8x8aTUrM Subject: [manet] Request to consider for DLEP 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, 24 Jul 2014 14:02:47 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF7343045446VAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all - had a couple conversations with folks yesterday and did some readi= ng and one thing I'd like to request be added into DLEP is the ability to s= et the equivalent of a default destination. Analogous to a default route a= t L3 layer. IE: In the hub and spoke architecture (mostly all satellite n= etworks - or any non-mesh design) there are networking guarantees that we = can take for granted. Essentially, we know the spoke will only ever have= one direction to pass traffic, so there is no need to manage or teach the = router about connected destinations (mac-addresses). This could be accomp= lished in either 2 ways... one a specific mac address 0xFFFFFFFF could be u= sed to say, you can send me broadcasts - which if interpreted the way I'd l= ike - would tell a router - go ahead and start your multicast IGP discovery= (or if configured your unicast arping) to find any/all L3 routing peers. = The advantage in my opinion to allowing for this: * Simplify router operations in this mode. Because the radio already= knows he is a spoke - there would otherwise be no need to track hub mac ad= dresses because he knows if a destination is not on his local lan - it must= go over the air. * Tracking hub side mac addresses in a modem can become a very large= scale problem. There will be thousands to a hundred thousand of learnt ma= c addresses coming from the hub side (all CE routers behind modems) could g= et learnt. * Without special config the modem can't know which MAC is special t= o be the hub and which isn't, so he'd have to manage it all. * With special config there are complications in OAM. If something c= hanges there is either a lot of configuration to modify and transfer. This = would be an OAM nightmare of potential errors. * It would require "special" work and knowledge for the modems to tr= ack, that break the layers - they are trying to simply be a transparent bri= dge. I don't think this is requesting any special burden on the routers - all I'= m asking is they behave exactly as they would as if a physical cable was ju= st plugged in - but we'll have DLEP virtually controlling the up/down of th= e interface. When set to up it would start to learn/converge like it would= if dlep was uninvolved. My main motivator, in addition to simplicity, is that those of us in the sa= t industry want to simplify or automate all things related to the remote mo= dem, lan, and equipment behind it. This is because years of experience tel= ls us something that can possibly go wrong at one point in time - will - (I= 'm sure we've all learned that lesson) but the difference is if something g= oes wrong on a sat lan - its not normal to have IT people nearby - and to '= fix' it could take a plane flight or a lot of local coordinating. Multiply = that by thousands of modems - and if we can avoid doing something special o= r needing to configure something - we sure would prefer it. NOTE: I understand on the hub side we would need specific destination to de= mux the dlep connections because the hub side will peer will all modem lans= . This is okay to me because complexity at the hub is acceptable - that's = managed by a trained NOC - so if things go wrong, people can deal with it l= ocally.... also much more powerful equipment and in general the complicatio= n is needed there because demuxing must occur. At the modem side, there is = no demuxing in non-mesh networks. I hope I've clearly explained what I'm thinking. ;) Thanks for the consideration, Brian Brian Snyder Snr. Applied Researcher * p: +1 703.648.8228 c: +1 703.220.67= 82 iDirect, 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171 * www.idi= rect.net * Advancing a Connected World --_000_84585478AABBBF4B9DF597FC0F84AF7343045446VAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all – had a couple conversations with folks= yesterday and did some reading and one thing I’d like to request be = added into DLEP is the ability to set the equivalent of a default destinati= on.  Analogous to a default route at L3 layer.   IE: In the hub and spoke architecture (mostly all satellite networks ̵= 1; or any non-mesh design)  there are networking guarantees that we ca= n take for granted.    Essentially, we know the spoke will o= nly ever have one direction to pass traffic, so there is no need to manage or teach the router about connected destinations (mac-addre= sses).   This could be accomplished in either 2 ways… one a= specific mac address 0xFFFFFFFF could be used to say, you can send me broa= dcasts – which if interpreted the way I’d like – would tell a router – go ahead and start your multicast IGP discover= y (or if configured your unicast arping) to find any/all L3 routing peers.&= nbsp; The advantage in my opinion to allowing for this:

 

·        Simplify router operations in this mode. Bec= ause the radio already knows he is a spoke – there would otherwise be= no need to track hub mac addresses because he knows if a destination is no= t on his local lan – it must go over the air.

·        Tracking hub side mac addresses in a modem c= an become a very large scale problem.  There will be thousands to a hu= ndred thousand of learnt mac addresses coming from the hub side (all CE rou= ters behind modems) could get learnt.

·        Without special config the modem can’t= know which MAC is special to be the hub and which isn’t, so he’= ;d have to manage it all.

·        With special config there are complications = in OAM. If something changes there is either a lot of configuration to modi= fy and transfer. This would be an OAM nightmare of potential errors.

·        It would require “special” work = and knowledge for the modems to track, that break the layers – they a= re trying to simply be a transparent bridge.

 

I don’t think this is requesting any special b= urden on the routers – all I’m asking is they behave exactly as= they would as if a physical cable was just plugged in – but we’= ;ll have DLEP virtually controlling the up/down of the interface.  When set to up it would start to learn/converge like it would if dlep was = uninvolved.

 

My main motivator, in addition to simplicity, is tha= t those of us in the sat industry want to simplify or automate all things r= elated to the remote modem, lan, and equipment behind it.  This is bec= ause years of experience tells us something that can possibly go wrong at one point in time – will – (I= 217;m sure we’ve all learned that lesson) but the difference is if so= mething goes wrong on a sat lan – its not normal to have IT people ne= arby – and to ‘fix’ it could take a plane flight or a lot= of local coordinating. Multiply that by thousands of modems – and if we can a= void doing something special or needing to configure something – we s= ure would prefer it.

 

NOTE: I understand on the hub side we would need spe= cific destination to demux the dlep connections because the hub side will p= eer will all modem lans.  This is okay to me because complexity at the= hub is acceptable – that’s managed by a trained NOC – so if things go wrong, people can deal with it local= ly…. also much more powerful equipment and in general the complicatio= n is needed there because demuxing must occur. At the modem side, there is = no demuxing in non-mesh networks.

 

I hope I’ve clearly explained what I’m t= hinking.  ;)

 

 

Thanks for the consideration,

Brian

 

 

Brian Snyder Snr. Applied Researcher  • p: +1 703.648.8228 c: +1 703.220.6782<= o:p>

iDirect, 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171 • www.idirect.net • Adv= ancing a Connected World

 

--_000_84585478AABBBF4B9DF597FC0F84AF7343045446VAUSMBX03idirec_-- From nobody Thu Jul 24 07:19:01 2014 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 862691A033C for ; Thu, 24 Jul 2014 07:18:59 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0n_Hu62KNY6S for ; Thu, 24 Jul 2014 07:18:56 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6891A02EE for ; Thu, 24 Jul 2014 07:18:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id D4A17D40789; Thu, 24 Jul 2014 07:18:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [31.133.161.181] (dhcp-a1b5.meeting.ietf.org [31.133.161.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id A0651D40367; Thu, 24 Jul 2014 07:18:53 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-63F14F6C-D969-48CE-944F-3E0E83EECFDF Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Thu, 24 Jul 2014 10:18:51 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4D5B5557-77C5-4E76-8C26-D98DCB438ACA@thomasclausen.org> References: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> <6CD44A55-2B8B-48E1-8881-A5EACE25DFB5@thomasclausen.org> To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YUnODhuS7bklLKV5673_998XlBY Cc: "manet-chairs@tools.ietf.org" , "manet@ietf.org" , "manet-ads@tools.ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 14:18:59 -0000 --Apple-Mail-63F14F6C-D969-48CE-944F-3E0E83EECFDF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris, > On 24 Jul 2014, at 08:44, "Dearlove, Christopher (UK)" wrote: >=20 > That=E2=80=99s not a bad example, but I think this is a little more tightl= y bound, in two or three ways. > =20 > First, 7182 says that if you have a crypto and a hash you do crypto(hash(d= ata)) unless your crypto rules say otherwise. 7182 says otherwise for HMAC, t= his says otherwise for its two functions. > =20 > Second, this could be said to redefine the meaning of in this cas= e. To me, that actually is *exactly* what 7182 says should happen: "...unless y= our crypto rules say otherwise" is what allows this document to do what it d= oes without "Updates". Although, you *could* make this specific point in this document, like we do i= n 7183 ("As allowed by .... we do ...")? > A possible third point is I=E2=80=99m not sure if 7182 implies that the wa= y to check an ICV is to recalculate and compare. The concept of truncation d= epends on that. Here however we don=E2=80=99t verify in that way (it=E2=80=99= s inherently impossible) but needs a separate verify process, and truncation= is disallowed. > =20 > Being a little more tightly bound puts it back in maybe an update, maybe n= ot territory. Personally I think as an update is more useful, but could go e= ither way. > =20 > (If we wrote a draft to, say, add SHA-3 as a hash function code point, tha= t would be a simple allocation and not an update, I agree.) To me, what you have said in the above - specifically pointed out how this i= s already permitted behavior by 7182 - makes me lean even more to not needi= ng the "Updates" moniker here. To summarize, my opinion is: o Get a WGLC started sooner, rather than later o Toss in the explanation with the "As allowed by ..." refer= ence, since I think that that'd be valuable for those not having commit= ted this RFC series to memory. This can be taken among any other WGLC comments rec= eived, it is=20 just for educational purposes. o Remove "Updates 7182" (Unless Adrian throws a temper-tantrum if we do) o Ship it to the IESG and the RFC Editor. Best, Thomas > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 24 July 2014 13:36 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org > Subject: Re: [manet] New IBS draft, request for WGLC > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > 7181 does make allocations from registries created by 5444, but doesn't "U= pdate rfc5444". That was my yardstick since both of those have flown by the i= esg.=20 >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org > =20 > "Today's scientists have substituted mathematics for=20 > experiments, and they wander off through equation=20 > after equation, and eventually build a structure=20 > which has no relation to reality." > - Nikola Tesla,=20 > Modern Mechanics and Inventions, July, 1934 >=20 > On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) wrote: >=20 > I have to admit to not understanding when updating and not updating. I kno= w we=E2=80=99ve had IESG members disagreeing on that very point (for one of o= ur documents) in the past, so I may not be alone. As for what=E2=80=99s been= done with published RFCs, I certainly see things marked as updates that are= not much different to this. But likely others not. > =20 > But in short, I don=E2=80=99t know, and will take guidance from anyone who= does know. Adrian, any comment? > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 24 July 2014 12:54 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org > Subject: Re: [manet] New IBS draft, request for WGLC > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Chris, all, > =20 > I have reviewed this latest version of the document, and I find it a usefu= l and well-shaped mechanism. I've definite plans to implement it, as it a ne= eded mechanism in many deployments that I care about. > =20 > I think that the document is ready to be WGLCed. > =20 > I have one minor comment: it "updates RFC 7182" - yet, all I can see it do= es to 7182 is make assignments from the registries defined therein, is this c= orrect? I.e., it doesn't *modify* the mechanisms specified in 7182? > =20 > If so, i.e., if what it does is to make allocations from the 7182 registri= es, then I wonder if the mechanism is actually "Updates RFC 7182"? > =20 > Might be worth figuring out before it gets bounced around by the IESG, spe= cifically the SEC-ADs? > =20 > But, by all means, let's have a WGLC started of this document, and prod Ad= rian for guidance on this point in parallel. > =20 > Best, > =20 > Thomas > =20 >=20 > Sent from my iPad >=20 > On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" wrote: >=20 > A new version of the IBS draft should be posted by the time I=E2=80=99ve f= inished typing this. > =20 > Thanks to Benjamin Smith for verifying the signature =E2=80=93 twice, as I= had made a small error in M. (Doing it twice, that actually means each of u= s knows the other did it independently.) > =20 > I believe that completes the draft, as it=E2=80=99s a small, specific, ext= ension. I therefore request that the chairs issue a WGLC for this with an ap= propriate duration for comments etc. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-63F14F6C-D969-48CE-944F-3E0E83EECFDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Chris,

On 24 J= ul 2014, at 08:44, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:

That=E2=80=99s not a ba= d example, but I think this is a little more tightly bound, in two or three w= ays.

 

First, 7182 says that i= f you have a crypto and a hash you do crypto(hash(data)) unless your crypto r= ules say otherwise. 7182 says otherwise for HMAC, this says otherwise for it= s two functions.

 

Second, this could be s= aid to redefine the meaning of <key-id> in this case.

=

To me, that actually is *exactly* what 7182= says should happen: "...unless your crypto rules say otherwise" is what all= ows this document to do what it does without "Updates".

=
Although, you *could* make this specific point in this document, like w= e do in 7183 ("As allowed by .... we do ...")?

A possible third point i= s I=E2=80=99m not sure if 7182 implies that the way to check an ICV is to re= calculate and compare. The concept of truncation depends on that. Here howev= er we don=E2=80=99t verify in that way (it=E2=80=99s inherently impossible) but needs a separate verify process, and truncation is disallow= ed.

 

Being a little more tig= htly bound puts it back in maybe an update, maybe not territory. Personally I= think as an update is more useful, but could go either way.

 

(If we wrote a draft to= , say, add SHA-3 as a hash function code point, that would be a simple alloc= ation and not an update, I agree.)


To me, what you have said in the above - specifically pointed out how thi= s is already permitted behavior by 7182 -  makes me lean even more to n= ot needing the "Updates" moniker here.

To summarize, my o= pinion is:

o Get a WGLC started sooner, rather than later

= o Toss in the explanation with the "As allowed by  ..." reference, si= nce
= I think that that'd be valuable for those not having committed this R= FC series to
memory. This can be taken among any other WGLC comme= nts received, it is 
just for educational purposes.
=

o= Remove "Updates 7182"
(Unless Adrian throws a temper-tantr= um if we do)

o Ship it to the IESG and the RFC Editor.
Best,

Thomas

=

--

Christopher Dearlove

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

=

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

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

 

From: Tho= mas Heide Clausen [mailto:thomas@th= omasclausen.org]
Sent: 24 July 2014 13:36
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org
Subject: Re: [manet] New IBS draft, request for WGLC

 

 

*** WARNING ***

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

7181 does make allocat= ions from registries created by 5444, but doesn't "Update rfc5444". That was= my yardstick since both of those have flown by the iesg. 

-- 

Thomas Heide Clausen

 

"Today's scientists have substituted mathematics for&= nbsp;

  experiments, and they wander off through e= quation 

  after equation, and eventually  buil= d a structure 

  which has no relation to reality."

 - Nikola Tesla, 

    Modern Mechanics and Inventions, J= uly, 1934


On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:=

I have to admit to not u= nderstanding when updating and not updating. I know we=E2=80=99ve had IESG m= embers disagreeing on that very point (for one of our documents) in the past= , so I may not be alone. As for what=E2=80=99s been done with published RFCs, I certainly see things marked as updates that are= not much different to this. But likely others not.

 

But in short, I don=E2=80= =99t know, and will take guidance from anyone who does know. Adrian, any com= ment?

 

--

Christopher Dearlove

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

=

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

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

 

From: Tho= mas Clausen [mailto:thomas@thomascl= ausen.org]
Sent: 24 July 2014 12:54
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org
Subject: Re: [manet] New IBS draft, request for WGLC

 

 

*** WARNING ***

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

Chris, all,

 

I have reviewed this latest version of the document, a= nd I find it a useful and well-shaped mechanism. I've definite plans to impl= ement it, as it a needed mechanism in many deployments that I care about.

 

I think that the document is ready to be WGLCed.=

 

I have one minor comment: it "updates RFC 7182" - yet= , all I can see it does to 7182 is make assignments from the registries defi= ned therein, is this correct? I.e., it doesn't *modify* the mechanisms speci= fied in 7182?

 

If so, i.e., if what it does is to make allocations f= rom the 7182 registries, then I wonder if the mechanism is actually "Updates= RFC 7182"?

 

Might be worth figuring out before it gets bounced ar= ound by the IESG, specifically the SEC-ADs?

 

But, by all means, let's have a WGLC started of this d= ocument, and prod Adrian for guidance on this point in parallel.<= /p>

 

Best,

 

Thomas

 


Sent from my iPad


On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:=

A new version of the IBS draft should be posted by th= e time I=E2=80=99ve finished typing this.

 

Thanks to Benjamin Smith for verifying the signature =E2= =80=93 twice, as I had made a small error in M. (Doing it twice, that actual= ly means each of us knows the other did it independently.)

 

I believe that completes the draft, as it=E2=80=99s a= small, specific, extension. I therefore request that the chairs issue a WGL= C for this with an appropriate duration for comments etc.

 

--

Christopher Dearlove

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

=

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

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

 

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

___________= ____________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-63F14F6C-D969-48CE-944F-3E0E83EECFDF-- From nobody Thu Jul 24 07:22:59 2014 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 5056F1A004E for ; Thu, 24 Jul 2014 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=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 UbdZFgMSRumF for ; Thu, 24 Jul 2014 07:22:50 -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 89E551A0012 for ; Thu, 24 Jul 2014 07:22:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,724,1400022000"; d="scan'208,217";a="389164665" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Jul 2014 15:22:47 +0100 X-IronPort-AV: E=Sophos; i="5.01,724,1400022000"; d="scan'208,217"; a="65971001" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 24 Jul 2014 15:22:32 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.210]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 15:22:31 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen Thread-Topic: [manet] New IBS draft, request for WGLC Thread-Index: Ac+nHb7ZKZluW6PjSp6j+Cirn7lL9AAD9FCAAAKr4BD///ZZAP//7vHwgAAt1YD//+6Z0A== Date: Thu, 24 Jul 2014 14:22:31 +0000 Message-ID: References: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> <6CD44A55-2B8B-48E1-8881-A5EACE25DFB5@thomasclausen.org> <4D5B5557-77C5-4E76-8C26-D98DCB438ACA@thomasclausen.org> In-Reply-To: <4D5B5557-77C5-4E76-8C26-D98DCB438ACA@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0796BGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kS0YMXbVuLeO6GxKXE-4h0Cdmf0 Cc: "manet-chairs@tools.ietf.org" , "manet@ietf.org" , "manet-ads@tools.ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 14:22:57 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0796BGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLCBsZXTigJlzIHN0YXJ0IHRoZSBXR0xDIGFzIHNvb24gYXMgcG9zc2libGUuIFRoZW4g KGFuZCBJIHJlYWxpc2UgdGhpcyB3ZWVrIG1heSBub3QgYmUgdGhlIGJlc3QgdGltZSkgbGV04oCZ cyBnZXQgQWRyaWFuIHRvIGFuc3dlciB0aGUgdXBkYXRlcyBvciBub3IgcXVlc3Rpb24uDQoNCi0t DQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3Jt YXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdl IEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2Vu dHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENN MiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0K Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9w ZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBC b3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywg R1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0K DQpGcm9tOiBUaG9tYXMgQ2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZ10N ClNlbnQ6IDI0IEp1bHkgMjAxNCAxNToxOQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp DQpDYzogbWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtYW5ldC1hZHNAdG9vbHMuaWV0Zi5v cmc7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBOZXcgSUJTIGRyYWZ0LCBy ZXF1ZXN0IGZvciBXR0xDDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2lu YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJu YWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5 b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw bHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9v ayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFu ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt ZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lv dXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lz dGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmcl MjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KQ2hyaXMsDQoNCk9uIDI0IEp1bCAy MDE0LCBhdCAwODo0NCwgIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIiA8Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4g d3JvdGU6DQpUaGF04oCZcyBub3QgYSBiYWQgZXhhbXBsZSwgYnV0IEkgdGhpbmsgdGhpcyBpcyBh IGxpdHRsZSBtb3JlIHRpZ2h0bHkgYm91bmQsIGluIHR3byBvciB0aHJlZSB3YXlzLg0KDQpGaXJz dCwgNzE4MiBzYXlzIHRoYXQgaWYgeW91IGhhdmUgYSBjcnlwdG8gYW5kIGEgaGFzaCB5b3UgZG8g Y3J5cHRvKGhhc2goZGF0YSkpIHVubGVzcyB5b3VyIGNyeXB0byBydWxlcyBzYXkgb3RoZXJ3aXNl LiA3MTgyIHNheXMgb3RoZXJ3aXNlIGZvciBITUFDLCB0aGlzIHNheXMgb3RoZXJ3aXNlIGZvciBp dHMgdHdvIGZ1bmN0aW9ucy4NCg0KU2Vjb25kLCB0aGlzIGNvdWxkIGJlIHNhaWQgdG8gcmVkZWZp bmUgdGhlIG1lYW5pbmcgb2YgPGtleS1pZD4gaW4gdGhpcyBjYXNlLg0KDQpUbyBtZSwgdGhhdCBh Y3R1YWxseSBpcyAqZXhhY3RseSogd2hhdCA3MTgyIHNheXMgc2hvdWxkIGhhcHBlbjogIi4uLnVu bGVzcyB5b3VyIGNyeXB0byBydWxlcyBzYXkgb3RoZXJ3aXNlIiBpcyB3aGF0IGFsbG93cyB0aGlz IGRvY3VtZW50IHRvIGRvIHdoYXQgaXQgZG9lcyB3aXRob3V0ICJVcGRhdGVzIi4NCg0KQWx0aG91 Z2gsIHlvdSAqY291bGQqIG1ha2UgdGhpcyBzcGVjaWZpYyBwb2ludCBpbiB0aGlzIGRvY3VtZW50 LCBsaWtlIHdlIGRvIGluIDcxODMgKCJBcyBhbGxvd2VkIGJ5IC4uLi4gd2UgZG8gLi4uIik/DQoN CkEgcG9zc2libGUgdGhpcmQgcG9pbnQgaXMgSeKAmW0gbm90IHN1cmUgaWYgNzE4MiBpbXBsaWVz IHRoYXQgdGhlIHdheSB0byBjaGVjayBhbiBJQ1YgaXMgdG8gcmVjYWxjdWxhdGUgYW5kIGNvbXBh cmUuIFRoZSBjb25jZXB0IG9mIHRydW5jYXRpb24gZGVwZW5kcyBvbiB0aGF0LiBIZXJlIGhvd2V2 ZXIgd2UgZG9u4oCZdCB2ZXJpZnkgaW4gdGhhdCB3YXkgKGl04oCZcyBpbmhlcmVudGx5IGltcG9z c2libGUpIGJ1dCBuZWVkcyBhIHNlcGFyYXRlIHZlcmlmeSBwcm9jZXNzLCBhbmQgdHJ1bmNhdGlv biBpcyBkaXNhbGxvd2VkLg0KDQpCZWluZyBhIGxpdHRsZSBtb3JlIHRpZ2h0bHkgYm91bmQgcHV0 cyBpdCBiYWNrIGluIG1heWJlIGFuIHVwZGF0ZSwgbWF5YmUgbm90IHRlcnJpdG9yeS4gUGVyc29u YWxseSBJIHRoaW5rIGFzIGFuIHVwZGF0ZSBpcyBtb3JlIHVzZWZ1bCwgYnV0IGNvdWxkIGdvIGVp dGhlciB3YXkuDQoNCihJZiB3ZSB3cm90ZSBhIGRyYWZ0IHRvLCBzYXksIGFkZCBTSEEtMyBhcyBh IGhhc2ggZnVuY3Rpb24gY29kZSBwb2ludCwgdGhhdCB3b3VsZCBiZSBhIHNpbXBsZSBhbGxvY2F0 aW9uIGFuZCBub3QgYW4gdXBkYXRlLCBJIGFncmVlLikNCg0KVG8gbWUsIHdoYXQgeW91IGhhdmUg c2FpZCBpbiB0aGUgYWJvdmUgLSBzcGVjaWZpY2FsbHkgcG9pbnRlZCBvdXQgaG93IHRoaXMgaXMg YWxyZWFkeSBwZXJtaXR0ZWQgYmVoYXZpb3IgYnkgNzE4MiAtICBtYWtlcyBtZSBsZWFuIGV2ZW4g bW9yZSB0byBub3QgbmVlZGluZyB0aGUgIlVwZGF0ZXMiIG1vbmlrZXIgaGVyZS4NCg0KVG8gc3Vt bWFyaXplLCBteSBvcGluaW9uIGlzOg0KDQogICAgICAgICAgICBvICAgICAgICAgIEdldCBhIFdH TEMgc3RhcnRlZCBzb29uZXIsIHJhdGhlciB0aGFuIGxhdGVyDQoNCiAgICAgICAgICAgIG8gICAg ICAgICAgVG9zcyBpbiB0aGUgZXhwbGFuYXRpb24gd2l0aCB0aGUgIkFzIGFsbG93ZWQgYnkgIC4u LiIgcmVmZXJlbmNlLCBzaW5jZQ0KICAgICAgICAgICAgICAgICAgICAgICAgSSB0aGluayB0aGF0 IHRoYXQnZCBiZSB2YWx1YWJsZSBmb3IgdGhvc2Ugbm90IGhhdmluZyBjb21taXR0ZWQgdGhpcyBS RkMgc2VyaWVzIHRvDQogICAgICAgICAgICAgICAgICAgICAgICBtZW1vcnkuIFRoaXMgY2FuIGJl IHRha2VuIGFtb25nIGFueSBvdGhlciBXR0xDIGNvbW1lbnRzIHJlY2VpdmVkLCBpdCBpcw0KICAg ICAgICAgICAgICAgICAgICAgICAganVzdCBmb3IgZWR1Y2F0aW9uYWwgcHVycG9zZXMuDQoNCiAg ICAgICAgICAgIG8gICAgICAgICAgUmVtb3ZlICJVcGRhdGVzIDcxODIiDQogICAgICAgICAgICAg ICAgICAgICAgICAoVW5sZXNzIEFkcmlhbiB0aHJvd3MgYSB0ZW1wZXItdGFudHJ1bSBpZiB3ZSBk bykNCg0KICAgICAgICAgICAgbyAgICAgICAgICBTaGlwIGl0IHRvIHRoZSBJRVNHIGFuZCB0aGUg UkZDIEVkaXRvci4NCg0KQmVzdCwNCg0KVGhvbWFzDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92 ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3Vw DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkN CkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVs ZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAx MjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0dHA6Ly93 d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJl Z2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFl cm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQpGcm9tOiBUaG9tYXMgSGVpZGUg Q2xhdXNlbiBbbWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZ10NClNlbnQ6IDI0IEp1bHkg MjAxNCAxMzozNg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogbWFuZXRAaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsgbWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBtYW5ldC1hZHNAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0LWFkc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbWFu ZXRdIE5ldyBJQlMgZHJhZnQsIHJlcXVlc3QgZm9yIFdHTEMNCg0KDQoqKiogV0FSTklORyAqKioN ClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVy IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu eSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZs YWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGlj ayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQo3 MTgxIGRvZXMgbWFrZSBhbGxvY2F0aW9ucyBmcm9tIHJlZ2lzdHJpZXMgY3JlYXRlZCBieSA1NDQ0 LCBidXQgZG9lc24ndCAiVXBkYXRlIHJmYzU0NDQiLiBUaGF0IHdhcyBteSB5YXJkc3RpY2sgc2lu Y2UgYm90aCBvZiB0aG9zZSBoYXZlIGZsb3duIGJ5IHRoZSBpZXNnLg0KLS0NClRob21hcyBIZWlk ZSBDbGF1c2VuDQpodHRwOi8vd3d3LnRob21hc2NsYXVzZW4ub3JnDQoNCiJUb2RheSdzIHNjaWVu dGlzdHMgaGF2ZSBzdWJzdGl0dXRlZCBtYXRoZW1hdGljcyBmb3INCiAgZXhwZXJpbWVudHMsIGFu ZCB0aGV5IHdhbmRlciBvZmYgdGhyb3VnaCBlcXVhdGlvbg0KICBhZnRlciBlcXVhdGlvbiwgYW5k IGV2ZW50dWFsbHkgIGJ1aWxkIGEgc3RydWN0dXJlDQogIHdoaWNoIGhhcyBubyByZWxhdGlvbiB0 byByZWFsaXR5LiINCiAtIE5pa29sYSBUZXNsYSwNCiAgICBNb2Rlcm4gTWVjaGFuaWNzIGFuZCBJ bnZlbnRpb25zLCBKdWx5LCAxOTM0DQoNCk9uIDI0IGp1aWwuIDIwMTQsIGF0IDA4OjMwLCBEZWFy bG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFp bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpJIGhhdmUgdG8gYWRt aXQgdG8gbm90IHVuZGVyc3RhbmRpbmcgd2hlbiB1cGRhdGluZyBhbmQgbm90IHVwZGF0aW5nLiBJ IGtub3cgd2XigJl2ZSBoYWQgSUVTRyBtZW1iZXJzIGRpc2FncmVlaW5nIG9uIHRoYXQgdmVyeSBw b2ludCAoZm9yIG9uZSBvZiBvdXIgZG9jdW1lbnRzKSBpbiB0aGUgcGFzdCwgc28gSSBtYXkgbm90 IGJlIGFsb25lLiBBcyBmb3Igd2hhdOKAmXMgYmVlbiBkb25lIHdpdGggcHVibGlzaGVkIFJGQ3Ms IEkgY2VydGFpbmx5IHNlZSB0aGluZ3MgbWFya2VkIGFzIHVwZGF0ZXMgdGhhdCBhcmUgbm90IG11 Y2ggZGlmZmVyZW50IHRvIHRoaXMuIEJ1dCBsaWtlbHkgb3RoZXJzIG5vdC4NCg0KQnV0IGluIHNo b3J0LCBJIGRvbuKAmXQga25vdywgYW5kIHdpbGwgdGFrZSBndWlkYW5jZSBmcm9tIGFueW9uZSB3 aG8gZG9lcyBrbm93LiBBZHJpYW4sIGFueSBjb21tZW50Pw0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVh cmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBH cm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmls aXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5n ZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiAr NDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVk DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3Vn aCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVn aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogVGhvbWFzIENs YXVzZW4gW21haWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAyNCBKdWx5IDIw MTQgMTI6NTQNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1hbmV0QGlldGYu b3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz47IG1hbmV0LWNoYWlyc0B0b29scy5pZXRmLm9yZzxt YWlsdG86bWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgbWFuZXQtYWRzQHRvb2xzLmlldGYu b3JnPG1haWx0bzptYW5ldC1hZHNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21hbmV0 XSBOZXcgSUJTIGRyYWZ0LCByZXF1ZXN0IGZvciBXR0xDDQoNCg0KKioqIFdBUk5JTkcgKioqDQpU aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0 aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBj YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg YXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFn cyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sg aGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhl IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KQ2hy aXMsIGFsbCwNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRv Y3VtZW50LCBhbmQgSSBmaW5kIGl0IGEgdXNlZnVsIGFuZCB3ZWxsLXNoYXBlZCBtZWNoYW5pc20u IEkndmUgZGVmaW5pdGUgcGxhbnMgdG8gaW1wbGVtZW50IGl0LCBhcyBpdCBhIG5lZWRlZCBtZWNo YW5pc20gaW4gbWFueSBkZXBsb3ltZW50cyB0aGF0IEkgY2FyZSBhYm91dC4NCg0KSSB0aGluayB0 aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBXR0xDZWQuDQoNCkkgaGF2ZSBvbmUgbWlu b3IgY29tbWVudDogaXQgInVwZGF0ZXMgUkZDIDcxODIiIC0geWV0LCBhbGwgSSBjYW4gc2VlIGl0 IGRvZXMgdG8gNzE4MiBpcyBtYWtlIGFzc2lnbm1lbnRzIGZyb20gdGhlIHJlZ2lzdHJpZXMgZGVm aW5lZCB0aGVyZWluLCBpcyB0aGlzIGNvcnJlY3Q/IEkuZS4sIGl0IGRvZXNuJ3QgKm1vZGlmeSog dGhlIG1lY2hhbmlzbXMgc3BlY2lmaWVkIGluIDcxODI/DQoNCklmIHNvLCBpLmUuLCBpZiB3aGF0 IGl0IGRvZXMgaXMgdG8gbWFrZSBhbGxvY2F0aW9ucyBmcm9tIHRoZSA3MTgyIHJlZ2lzdHJpZXMs IHRoZW4gSSB3b25kZXIgaWYgdGhlIG1lY2hhbmlzbSBpcyBhY3R1YWxseSAiVXBkYXRlcyBSRkMg NzE4MiI/DQoNCk1pZ2h0IGJlIHdvcnRoIGZpZ3VyaW5nIG91dCBiZWZvcmUgaXQgZ2V0cyBib3Vu Y2VkIGFyb3VuZCBieSB0aGUgSUVTRywgc3BlY2lmaWNhbGx5IHRoZSBTRUMtQURzPw0KDQpCdXQs IGJ5IGFsbCBtZWFucywgbGV0J3MgaGF2ZSBhIFdHTEMgc3RhcnRlZCBvZiB0aGlzIGRvY3VtZW50 LCBhbmQgcHJvZCBBZHJpYW4gZm9yIGd1aWRhbmNlIG9uIHRoaXMgcG9pbnQgaW4gcGFyYWxsZWwu DQoNCkJlc3QsDQoNClRob21hcw0KDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIDI0IEp1bCAy MDE0LCBhdCAwNTowNSwgIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIiA8Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4g d3JvdGU6DQpBIG5ldyB2ZXJzaW9uIG9mIHRoZSBJQlMgZHJhZnQgc2hvdWxkIGJlIHBvc3RlZCBi eSB0aGUgdGltZSBJ4oCZdmUgZmluaXNoZWQgdHlwaW5nIHRoaXMuDQoNClRoYW5rcyB0byBCZW5q YW1pbiBTbWl0aCBmb3IgdmVyaWZ5aW5nIHRoZSBzaWduYXR1cmUg4oCTIHR3aWNlLCBhcyBJIGhh ZCBtYWRlIGEgc21hbGwgZXJyb3IgaW4gTS4gKERvaW5nIGl0IHR3aWNlLCB0aGF0IGFjdHVhbGx5 IG1lYW5zIGVhY2ggb2YgdXMga25vd3MgdGhlIG90aGVyIGRpZCBpdCBpbmRlcGVuZGVudGx5LikN Cg0KSSBiZWxpZXZlIHRoYXQgY29tcGxldGVzIHRoZSBkcmFmdCwgYXMgaXTigJlzIGEgc21hbGws IHNwZWNpZmljLCBleHRlbnNpb24uIEkgdGhlcmVmb3JlIHJlcXVlc3QgdGhhdCB0aGUgY2hhaXJz IGlzc3VlIGEgV0dMQyBmb3IgdGhpcyB3aXRoIGFuIGFwcHJvcHJpYXRlIGR1cmF0aW9uIGZvciBj b21tZW50cyBldGMuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBh bCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywg TmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFu Y2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRk b3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6 ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20N Cg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBX YXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZh cm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBX YWxlcyBObzogMTk5NjY4Nw0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNp cGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNl bmRlci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBu b3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1h aWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0796BGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10 YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdC IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QWdyZWVk LCBsZXTigJlzIHN0YXJ0IHRoZSBXR0xDIGFzIHNvb24gYXMgcG9zc2libGUuIFRoZW4gKGFuZCBJ IHJlYWxpc2UgdGhpcyB3ZWVrIG1heSBub3QgYmUgdGhlIGJlc3QgdGltZSkgbGV04oCZcyBnZXQg QWRyaWFuIHRvIGFuc3dlciB0aGUgdXBkYXRlcyBvciBub3IgcXVlc3Rpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS0gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNocmlz dG9waGVyIERlYXJsb3ZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIs IEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25zLCBOZXR3b3Jr cyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2Vk IFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5 NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPC9zcGFuPjwvYT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tPGJyPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CQUUgU3lzdGVtcyAoT3BlcmF0 aW9ucykgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBC b3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywg R1UxNCA2WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAx OTk2Njg3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+IFRob21hcw0KIENsYXVz ZW4gW21haWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmddIDxicj4NCjxiPlNlbnQ6PC9iPiAy NCBKdWx5IDIwMTQgMTU6MTk8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo VUspPGJyPg0KPGI+Q2M6PC9iPiBtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0LWFk c0B0b29scy5pZXRmLm9yZzsgbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFttYW5ldF0gTmV3IElCUyBkcmFmdCwgcmVxdWVzdCBmb3IgV0dMQzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIu MHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNr Z3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi PioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwg cGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVm dWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRh Y2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZv cm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9z dHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQg eW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhy ZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5 L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+ PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBm b2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3 b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGlj aW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+ PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D aHJpcyw8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5PbiAyNCBKdWwgMjAxNCwgYXQgMDg6NDQsICZxdW90O0RlYXJsb3ZlLCBD aHJpc3RvcGhlciAoVUspJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYXTigJlzIG5vdCBhIGJhZCBleGFtcGxlLCBidXQgSSB0 aGluayB0aGlzIGlzIGEgbGl0dGxlIG1vcmUgdGlnaHRseSBib3VuZCwgaW4gdHdvIG9yIHRocmVl IHdheXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5GaXJzdCwgNzE4MiBz YXlzIHRoYXQgaWYgeW91IGhhdmUgYSBjcnlwdG8gYW5kIGEgaGFzaCB5b3UgZG8gY3J5cHRvKGhh c2goZGF0YSkpIHVubGVzcyB5b3VyIGNyeXB0byBydWxlcyBzYXkgb3RoZXJ3aXNlLiA3MTgyIHNh eXMgb3RoZXJ3aXNlIGZvciBITUFDLCB0aGlzIHNheXMgb3RoZXJ3aXNlIGZvciBpdHMgdHdvIGZ1 bmN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlY29uZCwgdGhp cyBjb3VsZCBiZSBzYWlkIHRvIHJlZGVmaW5lIHRoZSBtZWFuaW5nIG9mICZsdDtrZXktaWQmZ3Q7 IGluIHRoaXMgY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlRvIG1lLCB0aGF0IGFjdHVhbGx5 IGlzICpleGFjdGx5KiB3aGF0IDcxODIgc2F5cyBzaG91bGQgaGFwcGVuOiAmcXVvdDsuLi51bmxl c3MgeW91ciBjcnlwdG8gcnVsZXMgc2F5IG90aGVyd2lzZSZxdW90OyBpcyB3aGF0IGFsbG93cyB0 aGlzIGRvY3VtZW50IHRvDQogZG8gd2hhdCBpdCBkb2VzIHdpdGhvdXQgJnF1b3Q7VXBkYXRlcyZx dW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+QWx0aG91Z2gsIHlvdSAqY291bGQqIG1ha2UgdGhpcyBzcGVj aWZpYyBwb2ludCBpbiB0aGlzIGRvY3VtZW50LCBsaWtlIHdlIGRvIGluIDcxODMgKCZxdW90O0Fz IGFsbG93ZWQgYnkgLi4uLiB3ZSBkbyAuLi4mcXVvdDspPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5BIHBvc3NpYmxlIHRoaXJkIHBvaW50IGlzIEnigJltIG5vdCBzdXJlIGlm IDcxODIgaW1wbGllcyB0aGF0IHRoZSB3YXkgdG8gY2hlY2sgYW4gSUNWIGlzIHRvIHJlY2FsY3Vs YXRlIGFuZCBjb21wYXJlLiBUaGUgY29uY2VwdCBvZiB0cnVuY2F0aW9uIGRlcGVuZHMgb24gdGhh dC4gSGVyZSBob3dldmVyIHdlIGRvbuKAmXQgdmVyaWZ5IGluIHRoYXQgd2F5IChpdOKAmXMgaW5o ZXJlbnRseQ0KIGltcG9zc2libGUpIGJ1dCBuZWVkcyBhIHNlcGFyYXRlIHZlcmlmeSBwcm9jZXNz LCBhbmQgdHJ1bmNhdGlvbiBpcyBkaXNhbGxvd2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+QmVpbmcgYSBsaXR0bGUgbW9yZSB0aWdodGx5IGJvdW5kIHB1dHMgaXQgYmFj ayBpbiBtYXliZSBhbiB1cGRhdGUsIG1heWJlIG5vdCB0ZXJyaXRvcnkuIFBlcnNvbmFsbHkgSSB0 aGluayBhcyBhbiB1cGRhdGUgaXMgbW9yZSB1c2VmdWwsIGJ1dCBjb3VsZCBnbyBlaXRoZXIgd2F5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+KElmIHdlIHdyb3RlIGEgZHJh ZnQgdG8sIHNheSwgYWRkIFNIQS0zIGFzIGEgaGFzaCBmdW5jdGlvbiBjb2RlIHBvaW50LCB0aGF0 IHdvdWxkIGJlIGEgc2ltcGxlIGFsbG9jYXRpb24gYW5kIG5vdCBhbiB1cGRhdGUsIEkgYWdyZWUu KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj5UbyBtZSwgd2hhdCB5b3UgaGF2ZSBzYWlkIGluIHRoZSBhYm92ZSAt IHNwZWNpZmljYWxseSBwb2ludGVkIG91dCBob3cgdGhpcyBpcyBhbHJlYWR5IHBlcm1pdHRlZCBi ZWhhdmlvciBieSA3MTgyIC0gJm5ic3A7bWFrZXMgbWUgbGVhbiBldmVuIG1vcmUNCiB0byBub3Qg bmVlZGluZyB0aGUgJnF1b3Q7VXBkYXRlcyZxdW90OyBtb25pa2VyIGhlcmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5UbyBz dW1tYXJpemUsIG15IG9waW5pb24gaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+bzxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+R2V0IGEgV0dMQyBzdGFydGVkIHNvb25lciwgcmF0aGVyIHRoYW4g bGF0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLUdCIj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5U b3NzIGluIHRoZSBleHBsYW5hdGlvbiB3aXRoIHRoZSAmcXVvdDtBcyBhbGxvd2VkIGJ5ICZuYnNw Oy4uLiZxdW90OyByZWZlcmVuY2UsIHNpbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkkgdGhpbmsgdGhh dCB0aGF0J2QgYmUgdmFsdWFibGUgZm9yIHRob3NlIG5vdCBoYXZpbmcgY29tbWl0dGVkIHRoaXMg UkZDIHNlcmllcyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5tZW1vcnkuIFRoaXMgY2FuIGJlIHRha2Vu IGFtb25nIGFueSBvdGhlciBXR0xDIGNvbW1lbnRzIHJlY2VpdmVkLCBpdCBpcyZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLUdCIj5qdXN0IGZvciBlZHVjYXRpb25hbCBwdXJwb3Nlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5SZW1vdmUgJnF1b3Q7VXBkYXRl cyA3MTgyJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPihVbmxlc3MgQWRyaWFuIHRocm93cyBhIHRl bXBlci10YW50cnVtIGlmIHdlIGRvKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPm88c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPlNoaXAgaXQgdG8gdGhlIElFU0cgYW5kIHRoZSBSRkMgRWRpdG9yLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLUdCIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5UaG9tYXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS0gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkNocmlzdG9waGVyIERlYXJsb3ZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlbmlvciBQcmluY2lwYWwg RW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25z LCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1z IEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAx MjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4gfA0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVz eXN0ZW1zLmNvbSI+aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8YnI+DQpCQUUg U3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3 aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5i b3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZh bXA7IFdhbGVzIE5vOiAxOTk2Njg3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+ IFRob21hcw0KIEhlaWRlIENsYXVzZW4gWzxhIGhyZWY9Im1haWx0bzp0aG9tYXNAdGhvbWFzY2xh dXNlbi5vcmciPm1haWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmc8L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IDI0IEp1bHkgMjAxNCAxMzozNjxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENo cmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRm Lm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bWFuZXQtY2hhaXJzQHRv b2xzLmlldGYub3JnIj4NCm1hbmV0LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzptYW5ldC1hZHNAdG9vbHMuaWV0Zi5vcmciPm1hbmV0LWFkc0B0b29scy5pZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTmV3IElCUyBkcmFmdCwgcmVx dWVzdCBmb3IgV0dMQzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7 YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNh dGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9z cGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+ DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9l bT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0K PC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1h aWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUy MEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhl IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRy YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j dW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBw cm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjcxODEgZG9lcyBtYWtlIGFsbG9jYXRpb25zIGZyb20gcmVnaXN0cmllcyBjcmVh dGVkIGJ5IDU0NDQsIGJ1dCBkb2Vzbid0ICZxdW90O1VwZGF0ZSByZmM1NDQ0JnF1b3Q7LiBUaGF0 IHdhcyBteSB5YXJkc3RpY2sgc2luY2UgYm90aCBvZiB0aG9zZSBoYXZlIGZsb3duIGJ5IHRoZSBp ZXNnLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaG9tYXMgSGVpZGUgQ2xhdXNlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy50aG9tYXNjbGF1c2VuLm9yZyI+ aHR0cDovL3d3dy50aG9tYXNjbGF1c2VuLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7VG9kYXkncyBzY2llbnRpc3RzIGhh dmUgc3Vic3RpdHV0ZWQgbWF0aGVtYXRpY3MgZm9yJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDtleHBlcmltZW50cywg YW5kIHRoZXkgd2FuZGVyIG9mZiB0aHJvdWdoIGVxdWF0aW9uJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDthZnRlciBl cXVhdGlvbiwgYW5kIGV2ZW50dWFsbHkgJm5ic3A7YnVpbGQgYSBzdHJ1Y3R1cmUmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwO3doaWNoIGhhcyBubyByZWxhdGlvbiB0byByZWFsaXR5LiZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBOaWtvbGEgVGVz bGEsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7TW9kZXJuIE1lY2hhbmljcyBhbmQgSW52ZW50aW9ucywg SnVseSwgMTkzNDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDI0IGp1 aWwuIDIwMTQsIGF0IDA4OjMwLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBo YXZlIHRvIGFkbWl0IHRvIG5vdCB1bmRlcnN0YW5kaW5nIHdoZW4gdXBkYXRpbmcgYW5kIG5vdCB1 cGRhdGluZy4gSSBrbm93IHdl4oCZdmUgaGFkIElFU0cgbWVtYmVycyBkaXNhZ3JlZWluZyBvbiB0 aGF0IHZlcnkgcG9pbnQgKGZvciBvbmUgb2Ygb3VyIGRvY3VtZW50cykgaW4gdGhlIHBhc3QsIHNv IEkgbWF5IG5vdCBiZSBhbG9uZS4gQXMgZm9yIHdoYXTigJlzIGJlZW4NCiBkb25lIHdpdGggcHVi bGlzaGVkIFJGQ3MsIEkgY2VydGFpbmx5IHNlZSB0aGluZ3MgbWFya2VkIGFzIHVwZGF0ZXMgdGhh dCBhcmUgbm90IG11Y2ggZGlmZmVyZW50IHRvIHRoaXMuIEJ1dCBsaWtlbHkgb3RoZXJzIG5vdC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBpbiBzaG9ydCwgSSBkb27i gJl0IGtub3csIGFuZCB3aWxsIHRha2UgZ3VpZGFuY2UgZnJvbSBhbnlvbmUgd2hvIGRvZXMga25v dy4gQWRyaWFuLCBhbnkgY29tbWVudD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4tLSA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNl IEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBD YXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+ DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4 SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYj NDM7NDQgMTI0NSAyNDIxMjQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiB8 DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tIj5odHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tPC9hPjxicj4NCjxicj4NCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJy Pg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91 Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+ DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4gVGhvbWFzDQogQ2xhdXNlbiBbPGEgaHJlZj0ibWFp bHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZyI+bWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2Vu Lm9yZzwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjQgSnVseSAyMDE0IDEyOjU0PGJyPg0KPGI+ VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h aWx0bzptYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPg0KbWFuZXQtY2hhaXJzQHRvb2xzLmll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0LWFkc0B0b29scy5pZXRmLm9yZyI+bWFu ZXQtYWRzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBOZXcgSUJTIGRyYWZ0LCByZXF1ZXN0IGZvciBXR0xDPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4w cHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB Uk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20g b3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVy IG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdo ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz IG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9u IHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48 ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2Fu IGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0K PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIw RW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNocmlzLCBhbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkb2N1 bWVudCwgYW5kIEkgZmluZCBpdCBhIHVzZWZ1bCBhbmQgd2VsbC1zaGFwZWQgbWVjaGFuaXNtLiBJ J3ZlIGRlZmluaXRlIHBsYW5zIHRvIGltcGxlbWVudCBpdCwgYXMgaXQgYSBuZWVkZWQgbWVjaGFu aXNtIGluIG1hbnkgZGVwbG95bWVudHMgdGhhdCBJIGNhcmUgYWJvdXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCB0aGUg ZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgV0dMQ2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgb25lIG1pbm9yIGNvbW1lbnQ6IGl0 ICZxdW90O3VwZGF0ZXMgUkZDIDcxODImcXVvdDsgLSB5ZXQsIGFsbCBJIGNhbiBzZWUgaXQgZG9l cyB0byA3MTgyIGlzIG1ha2UgYXNzaWdubWVudHMgZnJvbSB0aGUgcmVnaXN0cmllcyBkZWZpbmVk IHRoZXJlaW4sIGlzIHRoaXMgY29ycmVjdD8gSS5lLiwgaXQgZG9lc24ndCAqbW9kaWZ5KiB0aGUg bWVjaGFuaXNtcyBzcGVjaWZpZWQgaW4gNzE4Mj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc28sIGkuZS4sIGlmIHdoYXQgaXQgZG9lcyBp cyB0byBtYWtlIGFsbG9jYXRpb25zIGZyb20gdGhlIDcxODIgcmVnaXN0cmllcywgdGhlbiBJIHdv bmRlciBpZiB0aGUgbWVjaGFuaXNtIGlzIGFjdHVhbGx5ICZxdW90O1VwZGF0ZXMgUkZDIDcxODIm cXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1pZ2h0IGJlIHdvcnRoIGZpZ3VyaW5nIG91dCBiZWZvcmUgaXQgZ2V0cyBib3VuY2VkIGFy b3VuZCBieSB0aGUgSUVTRywgc3BlY2lmaWNhbGx5IHRoZSBTRUMtQURzPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQsIGJ5IGFsbCBtZWFu cywgbGV0J3MgaGF2ZSBhIFdHTEMgc3RhcnRlZCBvZiB0aGlzIGRvY3VtZW50LCBhbmQgcHJvZCBB ZHJpYW4gZm9yIGd1aWRhbmNlIG9uIHRoaXMgcG9pbnQgaW4gcGFyYWxsZWwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob21hczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpT ZW50IGZyb20gbXkgaVBhZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyNCBKdWwg MjAxNCwgYXQgMDU6MDUsICZxdW90O0RlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbmV3IHZlcnNpb24gb2YgdGhlIElC UyBkcmFmdCBzaG91bGQgYmUgcG9zdGVkIGJ5IHRoZSB0aW1lIEnigJl2ZSBmaW5pc2hlZCB0eXBp bmcgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIHRvIEJlbmphbWluIFNtaXRo IGZvciB2ZXJpZnlpbmcgdGhlIHNpZ25hdHVyZSDigJMgdHdpY2UsIGFzIEkgaGFkIG1hZGUgYSBz bWFsbCBlcnJvciBpbiBNLiAoRG9pbmcgaXQgdHdpY2UsIHRoYXQgYWN0dWFsbHkgbWVhbnMgZWFj aCBvZiB1cyBrbm93cyB0aGUgb3RoZXIgZGlkIGl0IGluZGVwZW5kZW50bHkuKTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhhdCBjb21wbGV0ZXMgdGhlIGRyYWZ0LCBhcyBpdOKA mXMgYSBzbWFsbCwgc3BlY2lmaWMsIGV4dGVuc2lvbi4gSSB0aGVyZWZvcmUgcmVxdWVzdCB0aGF0 IHRoZSBjaGFpcnMgaXNzdWUgYSBXR0xDIGZvciB0aGlzIHdpdGggYW4gYXBwcm9wcmlhdGUgZHVy YXRpb24gZm9yIGNvbW1lbnRzIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPi0tIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaHJpc3RvcGhlciBEZWFybG92 ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5TZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBB c3N1cmFuY2UgR3JvdXA8YnI+DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFu YWx5c2lzIENhcGFiaWxpdHk8YnI+DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENl bnRyZTxicj4NCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y ZCwgQ00yIDhITiwgVUs8YnI+DQpUZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7 IEZheDogJiM0Mzs0NCAxMjQ1IDI0MjEyNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48YSBocmVmPSJtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE O3RleHQtZGVjb3JhdGlvbjpub25lIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bh bj48L2E+IHwNCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20iPmh0dHA6Ly93d3cu YmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExp bWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBG YXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllV LCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4Nzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJl Y2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUg c2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+ bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D0796BGLKXM0002VGREEN_-- From nobody Thu Jul 24 07:33:29 2014 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 6E7371A024E for ; Thu, 24 Jul 2014 07:33:26 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TCvH1Kxzxd4T for ; Thu, 24 Jul 2014 07:33:19 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F3D1A004A for ; Thu, 24 Jul 2014 07:33:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 5C0F41C90864; Thu, 24 Jul 2014 07:33:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [31.133.161.181] (dhcp-a1b5.meeting.ietf.org [31.133.161.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id AB0031C9085D; Thu, 24 Jul 2014 07:33:18 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1CF21BA2-8066-4EA5-9BB7-9D71EF741BCD Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Thu, 24 Jul 2014 10:33:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <10ED3708-98FE-48E2-826C-A677415F1F1A@thomasclausen.org> <6CD44A55-2B8B-48E1-8881-A5EACE25DFB5@thomasclausen.org> <4D5B5557-77C5-4E76-8C26-D98DCB438ACA@thomasclausen.org> To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KYbI00mpuGD5v6MDnNJ2QHPa0K0 Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] New IBS draft, request for WGLC 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, 24 Jul 2014 14:33:26 -0000 --Apple-Mail-1CF21BA2-8066-4EA5-9BB7-9D71EF741BCD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 24 Jul 2014, at 10:22, "Dearlove, Christopher (UK)" wrote: >=20 > Agreed, let=E2=80=99s start the WGLC as soon as possible. Then (and I real= ise this week may not be the best time) let=E2=80=99s get Adrian to answer t= he updates or nor question. > =20 Yes, I hear that he's vacationing somewhere in Canada this week, with 1500 o= f his best buddies ;) Thomas > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 24 July 2014 15:19 > To: Dearlove, Christopher (UK) > Cc: manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org; manet@ietf.org > Subject: Re: [manet] New IBS draft, request for WGLC > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Chris, > =20 > On 24 Jul 2014, at 08:44, "Dearlove, Christopher (UK)" wrote: >=20 > That=E2=80=99s not a bad example, but I think this is a little more tightl= y bound, in two or three ways. > =20 > First, 7182 says that if you have a crypto and a hash you do crypto(hash(d= ata)) unless your crypto rules say otherwise. 7182 says otherwise for HMAC, t= his says otherwise for its two functions. > =20 > Second, this could be said to redefine the meaning of in this cas= e. > =20 > To me, that actually is *exactly* what 7182 says should happen: "...unless= your crypto rules say otherwise" is what allows this document to do what it= does without "Updates". > =20 > Although, you *could* make this specific point in this document, like we d= o in 7183 ("As allowed by .... we do ...")? > =20 > A possible third point is I=E2=80=99m not sure if 7182 implies that the wa= y to check an ICV is to recalculate and compare. The concept of truncation d= epends on that. Here however we don=E2=80=99t verify in that way (it=E2=80=99= s inherently impossible) but needs a separate verify process, and truncation= is disallowed. > =20 > Being a little more tightly bound puts it back in maybe an update, maybe n= ot territory. Personally I think as an update is more useful, but could go e= ither way. > =20 > (If we wrote a draft to, say, add SHA-3 as a hash function code point, tha= t would be a simple allocation and not an update, I agree.) > =20 > To me, what you have said in the above - specifically pointed out how this= is already permitted behavior by 7182 - makes me lean even more to not nee= ding the "Updates" moniker here. > =20 > To summarize, my opinion is: > =20 > o Get a WGLC started sooner, rather than later > =20 > o Toss in the explanation with the "As allowed by ..= ." reference, since > I think that that'd be valuable for those not havi= ng committed this RFC series to > memory. This can be taken among any other WGLC com= ments received, it is=20 > just for educational purposes. > =20 > o Remove "Updates 7182" > (Unless Adrian throws a temper-tantrum if we do) > =20 > o Ship it to the IESG and the RFC Editor. > =20 > Best, > =20 > Thomas > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 24 July 2014 13:36 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org > Subject: Re: [manet] New IBS draft, request for WGLC > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > 7181 does make allocations from registries created by 5444, but doesn't "U= pdate rfc5444". That was my yardstick since both of those have flown by the i= esg.=20 >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org > =20 > "Today's scientists have substituted mathematics for=20 > experiments, and they wander off through equation=20 > after equation, and eventually build a structure=20 > which has no relation to reality." > - Nikola Tesla,=20 > Modern Mechanics and Inventions, July, 1934 >=20 > On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) wrote: >=20 > I have to admit to not understanding when updating and not updating. I kno= w we=E2=80=99ve had IESG members disagreeing on that very point (for one of o= ur documents) in the past, so I may not be alone. As for what=E2=80=99s been= done with published RFCs, I certainly see things marked as updates that are= not much different to this. But likely others not. > =20 > But in short, I don=E2=80=99t know, and will take guidance from anyone who= does know. Adrian, any comment? > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 24 July 2014 12:54 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org > Subject: Re: [manet] New IBS draft, request for WGLC > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Chris, all, > =20 > I have reviewed this latest version of the document, and I find it a usefu= l and well-shaped mechanism. I've definite plans to implement it, as it a ne= eded mechanism in many deployments that I care about. > =20 > I think that the document is ready to be WGLCed. > =20 > I have one minor comment: it "updates RFC 7182" - yet, all I can see it do= es to 7182 is make assignments from the registries defined therein, is this c= orrect? I.e., it doesn't *modify* the mechanisms specified in 7182? > =20 > If so, i.e., if what it does is to make allocations from the 7182 registri= es, then I wonder if the mechanism is actually "Updates RFC 7182"? > =20 > Might be worth figuring out before it gets bounced around by the IESG, spe= cifically the SEC-ADs? > =20 > But, by all means, let's have a WGLC started of this document, and prod Ad= rian for guidance on this point in parallel. > =20 > Best, > =20 > Thomas > =20 >=20 > Sent from my iPad >=20 > On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" wrote: >=20 > A new version of the IBS draft should be posted by the time I=E2=80=99ve f= inished typing this. > =20 > Thanks to Benjamin Smith for verifying the signature =E2=80=93 twice, as I= had made a small error in M. (Doing it twice, that actually means each of u= s knows the other did it independently.) > =20 > I believe that completes the draft, as it=E2=80=99s a small, specific, ext= ension. I therefore request that the chairs issue a WGLC for this with an ap= propriate duration for comments etc. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > 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 --Apple-Mail-1CF21BA2-8066-4EA5-9BB7-9D71EF741BCD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 24 Jul 2014, at 10:2= 2, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:

Agreed, let=E2=80=99s s= tart the WGLC as soon as possible. Then (and I realise this week may not be t= he best time) let=E2=80=99s get Adrian to answer the updates or nor question= .

 


Yes, I hear that he's vacationi= ng somewhere in Canada this week, with 1500 of his best buddies ;)

<= /div>
Thomas

--

Christopher Dearlove

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

=

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

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

 

From: Tho= mas Clausen [mailto:thomas@thomascl= ausen.org]
Sent: 24 July 2014 15:19
To: Dearlove, Christopher (UK)
Cc: manet-chairs@tools= .ietf.org; manet-ads@tools.i= etf.org; manet@ietf.org
Subject: Re: [manet] New IBS draft, request for WGLC

 

 

*** WARNING ***

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

Chris,

 

On 24 Jul 2014, at 08:= 44, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:

That=E2=80=99s not a ba= d example, but I think this is a little more tightly bound, in two or three w= ays.

 

First, 7182 says that i= f you have a crypto and a hash you do crypto(hash(data)) unless your crypto r= ules say otherwise. 7182 says otherwise for HMAC, this says otherwise for it= s two functions.

 

Second, this could be s= aid to redefine the meaning of <key-id> in this case.

 =

To me, that= actually is *exactly* what 7182 says should happen: "...unless your crypto r= ules say otherwise" is what allows this document to do what it does without "Updates".

 =

Although, y= ou *could* make this specific point in this document, like we do in 7183 ("A= s allowed by .... we do ...")?

 =

A possible third point i= s I=E2=80=99m not sure if 7182 implies that the way to check an ICV is to re= calculate and compare. The concept of truncation depends on that. Here howev= er we don=E2=80=99t verify in that way (it=E2=80=99s inherently impossible) but needs a separate verify process, and truncation is disallow= ed.

 

Being a little more tig= htly bound puts it back in maybe an update, maybe not territory. Personally I= think as an update is more useful, but could go either way.

 

(If we wrote a draft to= , say, add SHA-3 as a hash function code point, that would be a simple alloc= ation and not an update, I agree.)

 =

To me, what= you have said in the above - specifically pointed out how this is already p= ermitted behavior by 7182 -  makes me lean even more to not needing the "Updates" moniker here.

 =

To summariz= e, my opinion is:

 =

         &n= bsp;  o          Get a WGLC started sooner, rather than later

 =

         &n= bsp;  o          Toss in the explanation with the "As allowed by  ..." reference,= since

         &n= bsp;            =   I think that that'd b= e valuable for those not having committed this RFC series to

         &n= bsp;            =   memory. This can be t= aken among any other WGLC comments received, it is 

         &n= bsp;            =   just for educational= purposes.

 =

         &n= bsp;  o          Remove "Updates 7182"

         &n= bsp;            =   (Unless Adrian throw= s a temper-tantrum if we do)

 =

         &n= bsp;  o          Ship it to the IESG and the RFC Editor.

 =

Best,<= /o:p>

 =

Thomas=

 =

--

Christopher Dearlove

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

=

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

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

 

From: Tho= mas Heide Clausen [mailto:thomas@th= omasclausen.org]
Sent: 24 July 2014 13:36
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org
Subject: Re: [manet] New IBS draft, request for WGLC

 

 

*** WARNING ***

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

7181 does make allocat= ions from registries created by 5444, but doesn't "Update rfc5444". That was= my yardstick since both of those have flown by the iesg. 

-- 

Thomas Heide Clausen

 

"Today's scientists have substituted mathematics for&= nbsp;

  experiments, and they wander off through e= quation 

  after equation, and eventually  buil= d a structure 

  which has no relation to reality."

 - Nikola Tesla, 

    Modern Mechanics and Inventions, J= uly, 1934


On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:=

I have to admit to not u= nderstanding when updating and not updating. I know we=E2=80=99ve had IESG m= embers disagreeing on that very point (for one of our documents) in the past= , so I may not be alone. As for what=E2=80=99s been done with published RFCs, I certainly see things marked as updates that are= not much different to this. But likely others not.

 

But in short, I don=E2=80= =99t know, and will take guidance from anyone who does know. Adrian, any com= ment?

 

--

Christopher Dearlove

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

=

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

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

 

From: Tho= mas Clausen [mailto:thomas@thomascl= ausen.org]
Sent: 24 July 2014 12:54
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; manet-chairs@tools.ietf.org; manet-ads@tools.ietf.org
Subject: Re: [manet] New IBS draft, request for WGLC

 

 

*** WARNING ***

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

Chris, all,

 

I have reviewed this latest version of the document, a= nd I find it a useful and well-shaped mechanism. I've definite plans to impl= ement it, as it a needed mechanism in many deployments that I care about.

 

I think that the document is ready to be WGLCed.=

 

I have one minor comment: it "updates RFC 7182" - yet= , all I can see it does to 7182 is make assignments from the registries defi= ned therein, is this correct? I.e., it doesn't *modify* the mechanisms speci= fied in 7182?

 

If so, i.e., if what it does is to make allocations f= rom the 7182 registries, then I wonder if the mechanism is actually "Updates= RFC 7182"?

 

Might be worth figuring out before it gets bounced ar= ound by the IESG, specifically the SEC-ADs?

 

But, by all means, let's have a WGLC started of this d= ocument, and prod Adrian for guidance on this point in parallel.<= /p>

 

Best,

 

Thomas

 


Sent from my iPad


On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> wrote:=

A new version of the IBS draft should be posted by th= e time I=E2=80=99ve finished typing this.

 

Thanks to Benjamin Smith for verifying the signature =E2= =80=93 twice, as I had made a small error in M. (Doing it twice, that actual= ly means each of us knows the other did it independently.)

 

I believe that completes the draft, as it=E2=80=99s a= small, specific, extension. I therefore request that the chairs issue a WGL= C for this with an appropriate duration for comments etc.

 

--

Christopher Dearlove

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

=

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

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

 

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

___________= ____________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

___________= ____________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-1CF21BA2-8066-4EA5-9BB7-9D71EF741BCD-- From nobody Thu Jul 24 08:47:24 2014 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 C12481A03AD for ; Thu, 24 Jul 2014 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 B4dqpTFo7N11 for ; Thu, 24 Jul 2014 08:47:21 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 CC4C31A0350 for ; Thu, 24 Jul 2014 08:47:20 -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; Thu, 24 Jul 2014 16:46:33 +0100 From: Rick Taylor To: "Snyder, Brian" , "manet@ietf.org" Thread-Topic: Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/n Date: Thu, 24 Jul 2014 15:46:32 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801148DAD0Etssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hiXk3T5m_PR6kHvpfAF9fUbOBNY Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 15:47:22 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801148DAD0Etssserver1hom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As one of the people involved in the extensive discussions with Brian over = this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF solution, I= thought I ought to justify myself. Yes, it's a cludge. In an ideal world, the spoke modem in a hub and spoke = topology would announce it's link-state using the MAC address of the hub as= the destination identifier in the relevant signals. But, as Brian points = out, there are examples of existing technologies where a-priori configurati= on of the hub MAC, or retrofitting the passing of the hub MAC in the link-l= ayer signal is infeasible. In these cases, there needs to be a way for the= spoke modem to announce the link-state of the one and only link it has in = a generic way. Given the lack of knowledge of the hub MAC, any attached ro= uter will need to ARP/ND for it anyway, using the FF:FF:FF:FF:FF:FF address= , so there is some consistency there. Even if the all-FFs MAC is being used as a destination, there is nothing pr= eventing the same modem announcing other MAC destinations, with alternate l= ink state at a another time, so it doesn't break the existing DLEP model, i= n the same way that layer-3 has the default route concept (but obviously wi= th MAC's there is no concept of longest prefix, etc...) I think there needs to be some verbiage somewhere that states something alo= ng the lines of "If a modem will only ever have one link, e.g. a spoke in a= hub and spoke topology, and the MAC address of the destination router cann= ot be determined by the lower layer signalling, then the FF:FF:FF:FF:FF:FF = MAC address MAY be used, but this is NOT RECOMMENDED" (i.e. Do it properly = unless you *really* can't). @Brian: I think you might be arguing yourself into writing an informational= draft entitles "DLEP use-cases for Satcom". Also, as I think about it, this model might work for the 3G access point us= e-case. There is a link to a single destination, but, as with Satcom, the = MAC address of the destination router may not be available. Although, on f= urther consideration (I'm definitely thinking on my feet here) I think the = xG/LTE use-case is better addressed by my layer-3 extensions, as access-poi= nts don't operate as layer-2 bridges, and there may not even be a DLEP rout= er at the destination. Anyway, all food for thought and discussion... Rick --_000_38A5475DE83986499AEACD2CFAFC3F9801148DAD0Etssserver1hom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As one of the people involved in the extensive discussions with Brian over = this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF solution, I= thought I ought to justify myself.

Yes, it's a cludge.  In an ideal world, the spoke modem in a hub and s= poke topology would announce it's link-state using the MAC address of the h= ub as the destination identifier in the relevant signals.  But, as Bri= an points out, there are examples of existing technologies where a-priori configuration of the hub MAC, or retrofitting = the passing of the hub MAC in the link-layer signal is infeasible.  In= these cases, there needs to be a way for the spoke modem to announce the l= ink-state of the one and only link it has in a generic way.  Given the lack of knowledge of the hub MAC, an= y attached router will need to ARP/ND for it anyway, using the FF:FF:FF:FF:= FF:FF address, so there is some consistency there.

Even if the all-FFs MAC is being used as a destination, there is nothing pr= eventing the same modem announcing other MAC destinations, with alternate l= ink state at a another time, so it doesn't break the existing DLEP model, i= n the same way that layer-3 has the default route concept (but obviously with MAC's there is no concept of= longest prefix, etc...)

I think there needs to be some verbiage somewhere that states something alo= ng the lines of "If a modem will only ever have one link, e.g. a spoke= in a hub and spoke topology, and the MAC address of the destination router= cannot be determined by the lower layer signalling, then the FF:FF:FF:FF:FF:FF MAC address MAY be used, but this i= s NOT RECOMMENDED" (i.e. Do it properly unless you *really* can't).
@Brian: I think you might be arguing yourself into writing an informational= draft entitles "DLEP use-cases for Satcom".

Also, as I think about it, this model might work for the 3G access point us= e-case.  There is a link to a single destination, but, as with Satcom,= the MAC address of the destination router may not be available.  Alth= ough, on further consideration (I'm definitely thinking on my feet here) I think the xG/LTE use-case is better addressed = by my layer-3 extensions, as access-points don't operate as layer-2 bridges= , and there may not even be a DLEP router at the destination.

Anyway, all food for thought and discussion...

Rick


--_000_38A5475DE83986499AEACD2CFAFC3F9801148DAD0Etssserver1hom_-- From nobody Thu Jul 24 08:57:26 2014 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 A44DF1A0205 for ; Thu, 24 Jul 2014 08:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_35=0.6, 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 RSBrhFhbNueS for ; Thu, 24 Jul 2014 08:57:24 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923A61A00C0 for ; Thu, 24 Jul 2014 08:57:24 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so3527069qgd.12 for ; Thu, 24 Jul 2014 08:57:23 -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=InDGkWCQxHFj0fXfIHxCAbTSgjkyzDMzFsPi3n2OxVE=; b=MQ3ap6vr99GH1PhrUaoSAnqhkDLpPyOxOX2wTxN3Ousz10twbtPPSW6mUH9w280efb VRPQZwbRhbXT7a64/ftC0wC8JGTwawQRaAryefL41OHMjMUPW7XR5XwUKnSULywbD3+a +ubt9H/HSt/g6zwMmA5En0Jqg2EirEaoi8y9tjdsCwbBAMLNdegC9VPqkmexo9jH1E9r XIb2a6SqH7tQ6VgUa+Varoxky0J2oA31Gu28focRWu/7PdypQ00DtAnn4bYdE/GRqaTo c8qUDYv2Qr07oaoMiDv68ZTFLe8ES8u034XcTqU7bWMnHjCFATLsFI38MLhNgdujKVY3 yYoQ== X-Received: by 10.140.95.101 with SMTP id h92mr15983571qge.35.1406217443832; Thu, 24 Jul 2014 08:57:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Thu, 24 Jul 2014 08:57:03 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Thu, 24 Jul 2014 17:57:03 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PV3jzewlZQDZ9a9jqlc5OyGBBbs Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 15:57:25 -0000 On Thu, Jul 24, 2014 at 5:46 PM, Rick Taylor wrote: > As one of the people involved in the extensive discussions with Brian over > this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF solution, I > thought I ought to justify myself. Hmm... > Yes, it's a cludge. In an ideal world, the spoke modem in a hub and spoke > topology would announce it's link-state using the MAC address of the hub as > the destination identifier in the relevant signals. But, as Brian points > out, there are examples of existing technologies where a-priori > configuration of the hub MAC, or retrofitting the passing of the hub MAC in > the link-layer signal is infeasible. So there is no regular multicast traffic from the hub (which would be reasonable cheap because there is only a single hub)? Can the spokes hear the traffic from the Hub to other spokes? This would deliver the MAC address of the Hub too... > In these cases, there needs to be a > way for the spoke modem to announce the link-state of the one and only link > it has in a generic way. Given the lack of knowledge of the hub MAC, any > attached router will need to ARP/ND for it anyway, using the > FF:FF:FF:FF:FF:FF address, so there is some consistency there. So the idea is start only with a broadcast target and then later announce the unicast target as soon as we know it? We will get it as soon as we receive the first data packet anyways. I am not even sure we need to modify DLEP in any ways to support this hub&spoke topology. Even at the hub, DLEP should be fine to announce the coming and going of spoke modems as detected by the linklayer... this might be a scenario where Stans 'stateful' solution is really better than my older 'stateless' approach. Because we don't need to signal anything for a spoke that stays in the network... we just signal once "its there". Henning Rogge From nobody Thu Jul 24 09:44:46 2014 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 EF7EC1A041D for ; Thu, 24 Jul 2014 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 nRp6fCSirpo0 for ; Thu, 24 Jul 2014 09:44:42 -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 B67C21A041C for ; Thu, 24 Jul 2014 09:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7775; q=dns/txt; s=iport; t=1406220282; x=1407429882; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zjzV4oUGzAZwTnjJmqSy+LD+YdeCF/AfIc1GnRuUmIM=; b=KU+h4lZdR4bU4d+Ajk7+8XUkSP0gFKT9Yb2mbUDhB1QafhvZ1nPk1kM6 4nvuMNnP+ltr3H6OTisgDCAHWWpAd4XOBHWobjiSeNehm6KaMA1NkAFfL Ypz3pvW8Y26ALI5EyaWapFaLBd8MACsU5Y0a5eEuUqJOYi6XglWgmcryz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACw30VOtJA2D/2dsb2JhbABYgw5SVwTJLAEJh0UBgQ0Wd4QEAQEEAQEBawsQAgEIPwcnCxQRAQEEDgUbiCcNv3YTBI9HBAeDLoEYBYovkQeURYNIbIFF X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208,217";a="342542961" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jul 2014 16:44:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6OGifDx026934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 16:44:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 11:44:41 -0500 From: "Stan Ratliff (sratliff)" To: Rick Taylor Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAA1S/gA= Date: Thu, 24 Jul 2014 16:44:40 +0000 Message-ID: <572424F1-4F0E-433D-AACA-C79DF0FF24FC@cisco.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: multipart/alternative; boundary="_000_572424F14F0E433DAACAC79DF0FF24FCciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/g9BQF5j6W91Yib8j2iSmCnu8lyI Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 16:44:45 -0000 --_000_572424F14F0E433DAACAC79DF0FF24FCciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rick/Brian, I'm having a tough time understanding this. It appears to be a way to kludg= e DLEP support for an environment where it's not needed (that being the spo= ke router). Maybe I need a call, or some additional information to understand what the = goal is here. Regards, Stan On Jul 24, 2014, at 11:46 AM, Rick Taylor > wrote: As one of the people involved in the extensive discussions with Brian over = this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF solution, I= thought I ought to justify myself. Yes, it's a cludge. In an ideal world, the spoke modem in a hub and spoke = topology would announce it's link-state using the MAC address of the hub as= the destination identifier in the relevant signals. But, as Brian points = out, there are examples of existing technologies where a-priori configurati= on of the hub MAC, or retrofitting the passing of the hub MAC in the link-l= ayer signal is infeasible. In these cases, there needs to be a way for the= spoke modem to announce the link-state of the one and only link it has in = a generic way. Given the lack of knowledge of the hub MAC, any attached ro= uter will need to ARP/ND for it anyway, using the FF:FF:FF:FF:FF:FF address= , so there is some consistency there. Even if the all-FFs MAC is being used as a destination, there is nothing pr= eventing the same modem announcing other MAC destinations, with alternate l= ink state at a another time, so it doesn't break the existing DLEP model, i= n the same way that layer-3 has the default route concept (but obviously wi= th MAC's there is no concept of longest prefix, etc...) I think there needs to be some verbiage somewhere that states something alo= ng the lines of "If a modem will only ever have one link, e.g. a spoke in a= hub and spoke topology, and the MAC address of the destination router cann= ot be determined by the lower layer signalling, then the FF:FF:FF:FF:FF:FF = MAC address MAY be used, but this is NOT RECOMMENDED" (i.e. Do it properly = unless you *really* can't). @Brian: I think you might be arguing yourself into writing an informational= draft entitles "DLEP use-cases for Satcom". Also, as I think about it, this model might work for the 3G access point us= e-case. There is a link to a single destination, but, as with Satcom, the = MAC address of the destination router may not be available. Although, on f= urther consideration (I'm definitely thinking on my feet here) I think the = xG/LTE use-case is better addressed by my layer-3 extensions, as access-poi= nts don't operate as layer-2 bridges, and there may not even be a DLEP rout= er at the destination. Anyway, all food for thought and discussion... Rick _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_572424F14F0E433DAACAC79DF0FF24FCciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <52A082BF2AE73943BFA4C3FD8B84C990@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Rick/Brian, 

I'm having a tough time understanding this. It appears to be a way to = kludge DLEP support for an environment where it's not needed (that being th= e spoke router). 

Maybe I need a call, or some additional information to understand what= the goal is here. 

Regards,
Stan



On Jul 24, 2014, at 11:46 AM, Rick Taylor <rick@tropicalstormsoftware.com> wrote:
As one of the people involved in the extensive discussions with Brian over = this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF solution, I= thought I ought to justify myself.

Yes, it's a cludge.  In an ideal world, the spoke modem in a hub and s= poke topology would announce it's link-state using the MAC address of the h= ub as the destination identifier in the relevant signals.  But, as Bri= an points out, there are examples of existing technologies where a-priori configuration of the hub MAC, or retrofitting = the passing of the hub MAC in the link-layer signal is infeasible.  In= these cases, there needs to be a way for the spoke modem to announce the l= ink-state of the one and only link it has in a generic way.  Given the lack of knowledge of the hub MAC, an= y attached router will need to ARP/ND for it anyway, using the FF:FF:FF:FF:= FF:FF address, so there is some consistency there.

Even if the all-FFs MAC is being used as a destination, there is nothing pr= eventing the same modem announcing other MAC destinations, with alternate l= ink state at a another time, so it doesn't break the existing DLEP model, i= n the same way that layer-3 has the default route concept (but obviously with MAC's there is no concept of= longest prefix, etc...)

I think there needs to be some verbiage somewhere that states something alo= ng the lines of "If a modem will only ever have one link, e.g. a spoke= in a hub and spoke topology, and the MAC address of the destination router= cannot be determined by the lower layer signalling, then the FF:FF:FF:FF:FF:FF MAC address MAY be used, but this i= s NOT RECOMMENDED" (i.e. Do it properly unless you *really* can't).
@Brian: I think you might be arguing yourself into writing an informational= draft entitles "DLEP use-cases for Satcom".

Also, as I think about it, this model might work for the 3G access point us= e-case.  There is a link to a single destination, but, as with Satcom,= the MAC address of the destination router may not be available.  Alth= ough, on further consideration (I'm definitely thinking on my feet here) I think the xG/LTE use-case is better addressed = by my layer-3 extensions, as access-points don't operate as layer-2 bridges= , and there may not even be a DLEP router at the destination. 

Anyway, all food for thought and discussion...

Rick


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

--_000_572424F14F0E433DAACAC79DF0FF24FCciscocom_-- From nobody Thu Jul 24 09:49:53 2014 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 875C01A04B0 for ; Thu, 24 Jul 2014 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 gU_C7KhZJ0Jl for ; Thu, 24 Jul 2014 09:49:44 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id ED41C1A0547 for ; Thu, 24 Jul 2014 09:49:40 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,725,1400040000"; d="scan'208";a="2566306" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 24 Jul 2014 12:49:39 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Thu, 24 Jul 2014 12:49:39 -0400 From: "Snyder, Brian" To: Henning Rogge , Rick Taylor Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAmQ04AABvhPAA== Date: Thu, 24 Jul 2014 16:49:38 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> 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: http://mailarchive.ietf.org/arch/msg/manet/HTwXXcDDFGEcKQICgxXD-J4i9pQ Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 16:49:45 -0000 The other idea that was proposed was to define a new TLV at session init/di= scovery to tell a router - the same idea... This is a link up message -> no= w go converge. Rick thought using the FFFFFFFF thing would 'merge' the ide= as a little better.... My concern with that is that it could affect other d= ecisions being made based on that, like multicast wildcard or something. I= deally, imho, we could have a special tlv to state :=20 1) Send all multicast this way 2) Send all unicast this way 3) Send all broadcast this way 4) 1,2,3 can be combined All of the above being optional -- of course one could set MAC / IP destina= tions if it's desired to any specific host. And these options should be com= binable... for instance if you set all multicast this way, it would use default link metrics (or wh= atever is set) and if you want to specify a more specific rate control on a= particular destination you could do that too. However, in SATRAN, no one really relies on the router to do any qos becaus= e it doesn't know anything that's going on over the shared (and oversubscr= ibed) radio link, so its much more common to let the modem handle that... (= there is nothing wrong with trying to do it via router qos - but it will no= t work as well). >Can the spokes hear the traffic from the Hub to other spokes? This would d= eliver the MAC address of the Hub too... The outroute is broadcast, so if for instance an ARP goes downstream over t= he air, then every modem will see it (within the appropriate SVN definition= (VLAN, qinq) namespaces) . Now if a arp comes on the inroute then said SV= N's configuration will define if other modems will see it (IE: Will the hub= hairpin it?). I can speak for my implementation here but we have the abil= ity to per SVN define if it should behave in VPWS or VPLS mode. > Because we don't need to signal anything for a spoke that stays in the ne= twork... we just signal once "its there". Perhaps I misunderstood then --- I thought the way its defined if a destina= tion wasn't set - it wouldn't transmit any data to it.... What I'm going fo= r is more I guess bfd like (I feel the bfd proxy paper I presented is very = well described as a kind of a DLEP lite -> interface up/down with no link m= etrics) but once set down, it just kills the routing adjency (clearing the = FIB) and triggers L3 peer rediscovery to begin again. I liked that a lot b= ecause its 0 config and makes the L2 equipment completely transparent. If = I don't have to tell the downstream router anything about what destinations= he can reach when I enter the network... (yet still let L3 routing begin c= onvergence in either direction).... then perhaps there are no changes neede= d. That wasn't my impression from various discussions had.... am I wrong? Thanks all, Brian -----Original Message----- From: Henning Rogge [mailto:hrogge@gmail.com]=20 Sent: Thursday, July 24, 2014 11:57 AM To: Rick Taylor Cc: Snyder, Brian; manet@ietf.org Subject: Re: [manet] Request to consider for DLEP On Thu, Jul 24, 2014 at 5:46 PM, Rick Taylor wrote: > As one of the people involved in the extensive discussions with Brian=20 > over this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF=20 > solution, I thought I ought to justify myself. Hmm... > Yes, it's a cludge. In an ideal world, the spoke modem in a hub and=20 > spoke topology would announce it's link-state using the MAC address of=20 > the hub as the destination identifier in the relevant signals. But,=20 > as Brian points out, there are examples of existing technologies where=20 > a-priori configuration of the hub MAC, or retrofitting the passing of=20 > the hub MAC in the link-layer signal is infeasible. So there is no regular multicast traffic from the hub (which would be reaso= nable cheap because there is only a single hub)? Can the spokes hear the traffic from the Hub to other spokes? This would de= liver the MAC address of the Hub too... > In these cases, there needs to be a > way for the spoke modem to announce the link-state of the one and only=20 > link it has in a generic way. Given the lack of knowledge of the hub=20 > MAC, any attached router will need to ARP/ND for it anyway, using the=20 > FF:FF:FF:FF:FF:FF address, so there is some consistency there. So the idea is start only with a broadcast target and then later announce t= he unicast target as soon as we know it? We will get it as soon as we recei= ve the first data packet anyways. I am not even sure we need to modify DLEP in any ways to support this hub&s= poke topology. Even at the hub, DLEP should be fine to announce the coming = and going of spoke modems as detected by the linklayer... this might be a scenario where Stans 'stateful' solution is really better t= han my older 'stateless' approach. Because we don't need to signal anything= for a spoke that stays in the network... we just signal once "its there". Henning Rogge From nobody Thu Jul 24 09:59:41 2014 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 836141A0A98 for ; Thu, 24 Jul 2014 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 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_35=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 66C9PclEYntH for ; Thu, 24 Jul 2014 09:59:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B0C1A0A88 for ; Thu, 24 Jul 2014 09:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5792; q=dns/txt; s=iport; t=1406221166; x=1407430766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0h6aKrk9boNNulx/n57nvwrkITDtxeCNQBPgDLgxJLg=; b=j+ffzuygRQLXDU7a80XWkdfR9ibLFriXCYD18uCEfFRMDG7YV8fqZVfC eoO35aaq8IySJ7m4SVzabzqjnLvDOwibOO5u05OA3tcmg0MARdmImTgpF wTL2D7mOHMs3zdOSEp2pykahgPdAuHx9DD6D+9MSZdQCTskxL6TFZTALa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACU70VOtJA2B/2dsb2JhbABYgw5SVwTJLAqHRQGBDRZ3hAMBAQEDAQEBASRHCwUHBAIBCBEEAQEBJwchBgsUCQgBAQQOBRuIEwMJCA24UQ2HHhMEjR6BejMHBoMogRgBBJkzggOOJYYgg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208";a="342661532" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jul 2014 16:59:11 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6OGxAar029381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 16:59:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 11:59:10 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAupRIAAAdYiAAAAVRWA Date: Thu, 24 Jul 2014 16:59:09 +0000 Message-ID: References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jd2D_Q0LQUzgWv_vXCabLO6Mgt0 Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 16:59:38 -0000 On Jul 24, 2014, at 12:49 PM, "Snyder, Brian" wrote: > The other idea that was proposed was to define a new TLV at session init/= discovery to tell a router - the same idea... This is a link up message -> = now go converge. =20 How is this different from running the spoke router without DLEP, as it is = today? The interface comes up, and convergence starts=85=20 I guess another piece of the puzzle I'm missing is - "When (or under what c= ircumstances) would this 'all destinations' modem ever issue a DLEP 'Destin= ation Down' message?"=20 Regards, Stan > Rick thought using the FFFFFFFF thing would 'merge' the ideas a little be= tter.... My concern with that is that it could affect other decisions being= made based on that, like multicast wildcard or something. Ideally, imho, = we could have a special tlv to state :=20 > 1) Send all multicast this way > 2) Send all unicast this way > 3) Send all broadcast this way > 4) 1,2,3 can be combined >=20 > All of the above being optional -- of course one could set MAC / IP desti= nations if it's desired to any specific host. And these options should be c= ombinable... for instance > if you set all multicast this way, it would use default link metrics (or = whatever is set) and if you want to specify a more specific rate control on= a particular destination you could do that too. >=20 > However, in SATRAN, no one really relies on the router to do any qos beca= use it doesn't know anything that's going on over the shared (and oversubs= cribed) radio link, so its much more common to let the modem handle that...= (there is nothing wrong with trying to do it via router qos - but it will = not work as well). >=20 >> Can the spokes hear the traffic from the Hub to other spokes? This would= deliver the MAC address of the Hub too... > The outroute is broadcast, so if for instance an ARP goes downstream over= the air, then every modem will see it (within the appropriate SVN definiti= on (VLAN, qinq) namespaces) . Now if a arp comes on the inroute then said = SVN's configuration will define if other modems will see it (IE: Will the h= ub hairpin it?). I can speak for my implementation here but we have the ab= ility to per SVN define if it should behave in VPWS or VPLS mode. >=20 >> Because we don't need to signal anything for a spoke that stays in the n= etwork... we just signal once "its there". >=20 > Perhaps I misunderstood then --- I thought the way its defined if a desti= nation wasn't set - it wouldn't transmit any data to it.... What I'm going = for is more I guess bfd like (I feel the bfd proxy paper I presented is ver= y well described as a kind of a DLEP lite -> interface up/down with no link= metrics) but once set down, it just kills the routing adjency (clearing th= e FIB) and triggers L3 peer rediscovery to begin again. I liked that a lot= because its 0 config and makes the L2 equipment completely transparent. I= f I don't have to tell the downstream router anything about what destinatio= ns he can reach when I enter the network... (yet still let L3 routing begin= convergence in either direction).... then perhaps there are no changes nee= ded. That wasn't my impression from various discussions had.... am I wrong= ? >=20 > Thanks all, > Brian >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com]=20 > Sent: Thursday, July 24, 2014 11:57 AM > To: Rick Taylor > Cc: Snyder, Brian; manet@ietf.org > Subject: Re: [manet] Request to consider for DLEP >=20 > On Thu, Jul 24, 2014 at 5:46 PM, Rick Taylor wrote: >> As one of the people involved in the extensive discussions with Brian=20 >> over this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF=20 >> solution, I thought I ought to justify myself. >=20 > Hmm... >=20 >> Yes, it's a cludge. In an ideal world, the spoke modem in a hub and=20 >> spoke topology would announce it's link-state using the MAC address of=20 >> the hub as the destination identifier in the relevant signals. But,=20 >> as Brian points out, there are examples of existing technologies where=20 >> a-priori configuration of the hub MAC, or retrofitting the passing of=20 >> the hub MAC in the link-layer signal is infeasible. >=20 > So there is no regular multicast traffic from the hub (which would be rea= sonable cheap because there is only a single hub)? >=20 > Can the spokes hear the traffic from the Hub to other spokes? This would = deliver the MAC address of the Hub too... >=20 >> In these cases, there needs to be a >> way for the spoke modem to announce the link-state of the one and only=20 >> link it has in a generic way. Given the lack of knowledge of the hub=20 >> MAC, any attached router will need to ARP/ND for it anyway, using the=20 >> FF:FF:FF:FF:FF:FF address, so there is some consistency there. >=20 > So the idea is start only with a broadcast target and then later announce= the unicast target as soon as we know it? We will get it as soon as we rec= eive the first data packet anyways. >=20 > I am not even sure we need to modify DLEP in any ways to support this hub= &spoke topology. Even at the hub, DLEP should be fine to announce the comin= g and going of spoke modems as detected by the linklayer... > this might be a scenario where Stans 'stateful' solution is really better= than my older 'stateless' approach. Because we don't need to signal anythi= ng for a spoke that stays in the network... we just signal once "its there"= . >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jul 24 10:14:14 2014 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 36CE81A064A for ; Thu, 24 Jul 2014 10:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 JYQu0HsyPwnm for ; Thu, 24 Jul 2014 10:14:09 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6266B1A0AAC for ; Thu, 24 Jul 2014 10:13:52 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,725,1400040000"; d="scan'208";a="2566837" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport2.idirect.net with ESMTP; 24 Jul 2014 13:13:51 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Thu, 24 Jul 2014 13:13:51 -0400 From: "Snyder, Brian" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAmQ04AABvhPAP//2ZeAgAA/4CA= Date: Thu, 24 Jul 2014 17:13:51 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343045964@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> 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: http://mailarchive.ietf.org/arch/msg/manet/yizlBAJbEv7JV7dmuaxLGXJKsVw Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 17:14:11 -0000 The reason why DLEP is still desired is because it will allow one to config= ure the L3 timers to be much much higher. I can rely on DLEP to tell me ra= dio link up/down (even though Ethernet side is always connected). Hence I = can tune the L3 stuff to be a lot calmer and save a ton hello/ack packets A= FTER convergence, since if the modem leaves network I can get a DLEP down m= essage to drive the router to withdraw the established L3 peer and converge= L3 in an event driven manner. In satellite we must protect the RF bandwid= th because its very over subscribed and very expensive. The main driver fo= r me looking into these technologies is too protect the bandwidth -> hence = I am relying on dlep to pass radio interface events to drive convergence. Brian -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: Thursday, July 24, 2014 12:59 PM To: Snyder, Brian Cc: Henning Rogge; Rick Taylor; manet@ietf.org Subject: Re: [manet] Request to consider for DLEP On Jul 24, 2014, at 12:49 PM, "Snyder, Brian" wrote: > The other idea that was proposed was to define a new TLV at session init/= discovery to tell a router - the same idea... This is a link up message -> = now go converge. =20 How is this different from running the spoke router without DLEP, as it is = today? The interface comes up, and convergence starts...=20 I guess another piece of the puzzle I'm missing is - "When (or under what c= ircumstances) would this 'all destinations' modem ever issue a DLEP 'Destin= ation Down' message?"=20 Regards, Stan > Rick thought using the FFFFFFFF thing would 'merge' the ideas a little be= tter.... My concern with that is that it could affect other decisions being= made based on that, like multicast wildcard or something. Ideally, imho, = we could have a special tlv to state :=20 > 1) Send all multicast this way > 2) Send all unicast this way > 3) Send all broadcast this way > 4) 1,2,3 can be combined >=20 > All of the above being optional -- of course one could set MAC / IP=20 > destinations if it's desired to any specific host. And these options shou= ld be combinable... for instance if you set all multicast this way, it woul= d use default link metrics (or whatever is set) and if you want to specify = a more specific rate control on a particular destination you could do that = too. >=20 > However, in SATRAN, no one really relies on the router to do any qos beca= use it doesn't know anything that's going on over the shared (and oversubs= cribed) radio link, so its much more common to let the modem handle that...= (there is nothing wrong with trying to do it via router qos - but it will = not work as well). >=20 >> Can the spokes hear the traffic from the Hub to other spokes? This would= deliver the MAC address of the Hub too... > The outroute is broadcast, so if for instance an ARP goes downstream over= the air, then every modem will see it (within the appropriate SVN definiti= on (VLAN, qinq) namespaces) . Now if a arp comes on the inroute then said = SVN's configuration will define if other modems will see it (IE: Will the h= ub hairpin it?). I can speak for my implementation here but we have the ab= ility to per SVN define if it should behave in VPWS or VPLS mode. >=20 >> Because we don't need to signal anything for a spoke that stays in the n= etwork... we just signal once "its there". >=20 > Perhaps I misunderstood then --- I thought the way its defined if a desti= nation wasn't set - it wouldn't transmit any data to it.... What I'm going = for is more I guess bfd like (I feel the bfd proxy paper I presented is ver= y well described as a kind of a DLEP lite -> interface up/down with no link= metrics) but once set down, it just kills the routing adjency (clearing th= e FIB) and triggers L3 peer rediscovery to begin again. I liked that a lot= because its 0 config and makes the L2 equipment completely transparent. I= f I don't have to tell the downstream router anything about what destinatio= ns he can reach when I enter the network... (yet still let L3 routing begin= convergence in either direction).... then perhaps there are no changes nee= ded. That wasn't my impression from various discussions had.... am I wrong= ? >=20 > Thanks all, > Brian >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com] > Sent: Thursday, July 24, 2014 11:57 AM > To: Rick Taylor > Cc: Snyder, Brian; manet@ietf.org > Subject: Re: [manet] Request to consider for DLEP >=20 > On Thu, Jul 24, 2014 at 5:46 PM, Rick Taylor wrote: >> As one of the people involved in the extensive discussions with Brian=20 >> over this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF=20 >> solution, I thought I ought to justify myself. >=20 > Hmm... >=20 >> Yes, it's a cludge. In an ideal world, the spoke modem in a hub and=20 >> spoke topology would announce it's link-state using the MAC address=20 >> of the hub as the destination identifier in the relevant signals. =20 >> But, as Brian points out, there are examples of existing technologies=20 >> where a-priori configuration of the hub MAC, or retrofitting the=20 >> passing of the hub MAC in the link-layer signal is infeasible. >=20 > So there is no regular multicast traffic from the hub (which would be rea= sonable cheap because there is only a single hub)? >=20 > Can the spokes hear the traffic from the Hub to other spokes? This would = deliver the MAC address of the Hub too... >=20 >> In these cases, there needs to be a >> way for the spoke modem to announce the link-state of the one and=20 >> only link it has in a generic way. Given the lack of knowledge of=20 >> the hub MAC, any attached router will need to ARP/ND for it anyway,=20 >> using the FF:FF:FF:FF:FF:FF address, so there is some consistency there. >=20 > So the idea is start only with a broadcast target and then later announce= the unicast target as soon as we know it? We will get it as soon as we rec= eive the first data packet anyways. >=20 > I am not even sure we need to modify DLEP in any ways to support this hub= &spoke topology. Even at the hub, DLEP should be fine to announce the comin= g and going of spoke modems as detected by the linklayer... > this might be a scenario where Stans 'stateful' solution is really better= than my older 'stateless' approach. Because we don't need to signal anythi= ng for a spoke that stays in the network... we just signal once "its there"= . >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jul 24 10:16:47 2014 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 7E62F1A0084 for ; Thu, 24 Jul 2014 10:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 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_35=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 AWP_1SB3k2_E for ; Thu, 24 Jul 2014 10:16:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE471A064A for ; Thu, 24 Jul 2014 10:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6474; q=dns/txt; s=iport; t=1406222196; x=1407431796; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AdAjGFxnn2i1on03t3p7ReG7/OfOtSk7x+kA0k4KuIU=; b=UpTt5YceVvvJ5ZztrdKtshhiEpci3VDgMnOo+y7U9uBwBhMRhDY7vDl6 PUqILDT0GoJG+O5vq0P+c9xCko9OqNSGMKTmIgOQtSIcPT0NGr35hU5GB 2i7ffTkv+S9OJEWgcnVhkPV7fQdCDsyPJgbBcOAsEVodhgSXHuVGSfU9A Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALo+0VOtJA2I/2dsb2JhbABYgw5SVwTJLAqHRQGBDRZ3hAMBAQEDAQEBASRHCwwEAgEIEQQBAQEnByEGCxQJCAEBBA4FG4gTAwkIDbg5DYceEwSNHoF6MwcGgyiBGAEEmTOCA44lhiCDSGyBRQ X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208";a="339486377" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jul 2014 17:16:35 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6OHGZnA026376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 17:16:35 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 12:16:35 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAupRIAAAdYiAAAAVRWAAACbuAA= Date: Thu, 24 Jul 2014 17:16:34 +0000 Message-ID: <40306191-8D4A-4DCC-B618-17012D317502@cisco.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.42.25] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8426B98702F5E340AE1C9A018E4AE88D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tworG3zyLbfmU7UY78o1yYDZPH8 Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 17:16:42 -0000 Oh, one more observation inline :=20 On Jul 24, 2014, at 12:59 PM, Stan Ratliff (sratliff) = wrote: >=20 > On Jul 24, 2014, at 12:49 PM, "Snyder, Brian" wrote= : >=20 >> The other idea that was proposed was to define a new TLV at session init= /discovery to tell a router - the same idea... This is a link up message ->= now go converge. =20 >=20 > How is this different from running the spoke router without DLEP, as it i= s today? The interface comes up, and convergence starts=85=20 >=20 > I guess another piece of the puzzle I'm missing is - "When (or under what= circumstances) would this 'all destinations' modem ever issue a DLEP 'Dest= ination Down' message?"=20 >=20 > Regards, > Stan >=20 >> Rick thought using the FFFFFFFF thing would 'merge' the ideas a little b= etter.... My concern with that is that it could affect other decisions bein= g made based on that, like multicast wildcard or something. Ideally, imho,= we could have a special tlv to state :=20 >> 1) Send all multicast this way >> 2) Send all unicast this way >> 3) Send all broadcast this way >> 4) 1,2,3 can be combined >>=20 >> All of the above being optional -- of course one could set MAC / IP dest= inations if it's desired to any specific host. And these options should be = combinable... for instance >> if you set all multicast this way, it would use default link metrics (or= whatever is set) and if you want to specify a more specific rate control o= n a particular destination you could do that too. >>=20 >> However, in SATRAN, no one really relies on the router to do any qos bec= ause it doesn't know anything that's going on over the shared (and oversub= scribed) radio link, so its much more common to let the modem handle that..= . (there is nothing wrong with trying to do it via router qos - but it will= not work as well). This is EXACTLY one of the things that DLEP is intended to address. Current= ly, the router DOESN'T know what is going on over the radio link. Hence, we= created a protocol for the radio to TELL the router what's going on, so al= l of the QoS tools can be utilized.=20 Regards, Stan >>=20 >>> Can the spokes hear the traffic from the Hub to other spokes? This woul= d deliver the MAC address of the Hub too... >> The outroute is broadcast, so if for instance an ARP goes downstream ove= r the air, then every modem will see it (within the appropriate SVN definit= ion (VLAN, qinq) namespaces) . Now if a arp comes on the inroute then said= SVN's configuration will define if other modems will see it (IE: Will the = hub hairpin it?). I can speak for my implementation here but we have the a= bility to per SVN define if it should behave in VPWS or VPLS mode. >>=20 >>> Because we don't need to signal anything for a spoke that stays in the = network... we just signal once "its there". >>=20 >> Perhaps I misunderstood then --- I thought the way its defined if a dest= ination wasn't set - it wouldn't transmit any data to it.... What I'm going= for is more I guess bfd like (I feel the bfd proxy paper I presented is ve= ry well described as a kind of a DLEP lite -> interface up/down with no lin= k metrics) but once set down, it just kills the routing adjency (clearing t= he FIB) and triggers L3 peer rediscovery to begin again. I liked that a lo= t because its 0 config and makes the L2 equipment completely transparent. = If I don't have to tell the downstream router anything about what destinati= ons he can reach when I enter the network... (yet still let L3 routing begi= n convergence in either direction).... then perhaps there are no changes ne= eded. That wasn't my impression from various discussions had.... am I wron= g? >>=20 >> Thanks all, >> Brian >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@gmail.com]=20 >> Sent: Thursday, July 24, 2014 11:57 AM >> To: Rick Taylor >> Cc: Snyder, Brian; manet@ietf.org >> Subject: Re: [manet] Request to consider for DLEP >>=20 >> On Thu, Jul 24, 2014 at 5:46 PM, Rick Taylor wrote: >>> As one of the people involved in the extensive discussions with Brian=20 >>> over this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF=20 >>> solution, I thought I ought to justify myself. >>=20 >> Hmm... >>=20 >>> Yes, it's a cludge. In an ideal world, the spoke modem in a hub and=20 >>> spoke topology would announce it's link-state using the MAC address of= =20 >>> the hub as the destination identifier in the relevant signals. But,=20 >>> as Brian points out, there are examples of existing technologies where= =20 >>> a-priori configuration of the hub MAC, or retrofitting the passing of=20 >>> the hub MAC in the link-layer signal is infeasible. >>=20 >> So there is no regular multicast traffic from the hub (which would be re= asonable cheap because there is only a single hub)? >>=20 >> Can the spokes hear the traffic from the Hub to other spokes? This would= deliver the MAC address of the Hub too... >>=20 >>> In these cases, there needs to be a >>> way for the spoke modem to announce the link-state of the one and only= =20 >>> link it has in a generic way. Given the lack of knowledge of the hub=20 >>> MAC, any attached router will need to ARP/ND for it anyway, using the=20 >>> FF:FF:FF:FF:FF:FF address, so there is some consistency there. >>=20 >> So the idea is start only with a broadcast target and then later announc= e the unicast target as soon as we know it? We will get it as soon as we re= ceive the first data packet anyways. >>=20 >> I am not even sure we need to modify DLEP in any ways to support this hu= b&spoke topology. Even at the hub, DLEP should be fine to announce the comi= ng and going of spoke modems as detected by the linklayer... >> this might be a scenario where Stans 'stateful' solution is really bette= r than my older 'stateless' approach. Because we don't need to signal anyth= ing for a spoke that stays in the network... we just signal once "its there= ". >>=20 >> Henning Rogge >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jul 24 10:34:23 2014 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 4BB151A0AA7 for ; Thu, 24 Jul 2014 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 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_35=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 EhDWmROcdXa9 for ; Thu, 24 Jul 2014 10:34:17 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A961A0653 for ; Thu, 24 Jul 2014 10:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7909; q=dns/txt; s=iport; t=1406223256; x=1407432856; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3DMY67b7zmiqnY6oPBhN4+u4QayFWuarrVN0Q77Utrs=; b=MQwC4sMEuEtSUJmArpAtLKgoS4OUQXkYDIPJ8cg7Ebj0eLj8PoE9YO2z BAmOV65ck2gTffdfehwkjUkYMCBhudrfYsnnCZ38JKvi71zrXmQxKkNHR ugJxogXaBAUOI5vLQ+q3qd9cF2lvP9jfEQwPZcdCosU4BIR/cEAwbaoJG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAOBC0VOtJV2T/2dsb2JhbABOCoMOUlcEySwKh0UBgQ0Wd4QDAQEBAwEBAQEkEzQLBQcEAgEIEQQBAQEeCQchBgsUCQgCBA4FG4gTAwkIDbgeDYceEwSNHoFLBgsBHTMHBoMogRgFmTOCA44lhiCDSGyBDDk X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208";a="63691144" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 24 Jul 2014 17:34:15 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6OHYF9o016299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 17:34:15 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 12:34:14 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAupRIAAAdYiAAAAVRWAAACDboAAALYYgA== Date: Thu, 24 Jul 2014 17:34:13 +0000 Message-ID: <2D3F794E-BA3E-4A6C-A590-0A35A232F7A0@cisco.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343045964@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343045964@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.42.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AB9F6960DE4074EA43EE7077B093244@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1LI2Yv2nchyYqkF9kbX-yonrUgA Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 17:34:21 -0000 On Jul 24, 2014, at 1:13 PM, "Snyder, Brian" wrote: > The reason why DLEP is still desired is because it will allow one to conf= igure the L3 timers to be much much higher. I can rely on DLEP to tell me = radio link up/down (even though Ethernet side is always connected). Hence = I can tune the L3 stuff to be a lot calmer and save a ton hello/ack packets= AFTER convergence, since if the modem leaves network I can get a DLEP down= message to drive the router to withdraw the established L3 peer and conver= ge L3 in an event driven manner. In satellite we must protect the RF bandw= idth because its very over subscribed and very expensive. The main driver = for me looking into these technologies is too protect the bandwidth -> henc= e I am relying on dlep to pass radio interface events to drive convergence. >=20 But I think the same problem exists on "Destination Down" as with "Destinat= ion Up". Specifically, you said in an earlier email that identifying the hu= b router, by MAC address, is difficult to do for providing the "Destination= Up". If that's the case, isn't it just as tough to identify the hub router= when it goes down? I don't understand the use case for when the hub router= and/or modem drops - how do you know to issue Destination Down to the spok= es? Another thing to note - DLEP presentation of "Destination Up" does NOT nece= ssarily guarantee a routing adjacency to said destination. It means "someth= ing connected via the RF". If the router's implementation is to issue a HEL= LO, and that HELLO is not answered by anyone other than the hub router, the= n it all works as you want it to (I think). Regards, Stan =20 > Brian >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: Thursday, July 24, 2014 12:59 PM > To: Snyder, Brian > Cc: Henning Rogge; Rick Taylor; manet@ietf.org > Subject: Re: [manet] Request to consider for DLEP >=20 >=20 > On Jul 24, 2014, at 12:49 PM, "Snyder, Brian" wrote= : >=20 >> The other idea that was proposed was to define a new TLV at session init= /discovery to tell a router - the same idea... This is a link up message ->= now go converge. =20 >=20 > How is this different from running the spoke router without DLEP, as it i= s today? The interface comes up, and convergence starts...=20 >=20 > I guess another piece of the puzzle I'm missing is - "When (or under what= circumstances) would this 'all destinations' modem ever issue a DLEP 'Dest= ination Down' message?"=20 >=20 > Regards, > Stan >=20 >> Rick thought using the FFFFFFFF thing would 'merge' the ideas a little b= etter.... My concern with that is that it could affect other decisions bein= g made based on that, like multicast wildcard or something. Ideally, imho,= we could have a special tlv to state :=20 >> 1) Send all multicast this way >> 2) Send all unicast this way >> 3) Send all broadcast this way >> 4) 1,2,3 can be combined >>=20 >> All of the above being optional -- of course one could set MAC / IP=20 >> destinations if it's desired to any specific host. And these options sho= uld be combinable... for instance if you set all multicast this way, it wou= ld use default link metrics (or whatever is set) and if you want to specify= a more specific rate control on a particular destination you could do that= too. >>=20 >> However, in SATRAN, no one really relies on the router to do any qos bec= ause it doesn't know anything that's going on over the shared (and oversub= scribed) radio link, so its much more common to let the modem handle that..= . (there is nothing wrong with trying to do it via router qos - but it will= not work as well). >>=20 >>> Can the spokes hear the traffic from the Hub to other spokes? This woul= d deliver the MAC address of the Hub too... >> The outroute is broadcast, so if for instance an ARP goes downstream ove= r the air, then every modem will see it (within the appropriate SVN definit= ion (VLAN, qinq) namespaces) . Now if a arp comes on the inroute then said= SVN's configuration will define if other modems will see it (IE: Will the = hub hairpin it?). I can speak for my implementation here but we have the a= bility to per SVN define if it should behave in VPWS or VPLS mode. >>=20 >>> Because we don't need to signal anything for a spoke that stays in the = network... we just signal once "its there". >>=20 >> Perhaps I misunderstood then --- I thought the way its defined if a dest= ination wasn't set - it wouldn't transmit any data to it.... What I'm going= for is more I guess bfd like (I feel the bfd proxy paper I presented is ve= ry well described as a kind of a DLEP lite -> interface up/down with no lin= k metrics) but once set down, it just kills the routing adjency (clearing t= he FIB) and triggers L3 peer rediscovery to begin again. I liked that a lo= t because its 0 config and makes the L2 equipment completely transparent. = If I don't have to tell the downstream router anything about what destinati= ons he can reach when I enter the network... (yet still let L3 routing begi= n convergence in either direction).... then perhaps there are no changes ne= eded. That wasn't my impression from various discussions had.... am I wron= g? >>=20 >> Thanks all, >> Brian >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@gmail.com] >> Sent: Thursday, July 24, 2014 11:57 AM >> To: Rick Taylor >> Cc: Snyder, Brian; manet@ietf.org >> Subject: Re: [manet] Request to consider for DLEP >>=20 >> On Thu, Jul 24, 2014 at 5:46 PM, Rick Taylor wrote: >>> As one of the people involved in the extensive discussions with Brian=20 >>> over this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF=20 >>> solution, I thought I ought to justify myself. >>=20 >> Hmm... >>=20 >>> Yes, it's a cludge. In an ideal world, the spoke modem in a hub and=20 >>> spoke topology would announce it's link-state using the MAC address=20 >>> of the hub as the destination identifier in the relevant signals. =20 >>> But, as Brian points out, there are examples of existing technologies=20 >>> where a-priori configuration of the hub MAC, or retrofitting the=20 >>> passing of the hub MAC in the link-layer signal is infeasible. >>=20 >> So there is no regular multicast traffic from the hub (which would be re= asonable cheap because there is only a single hub)? >>=20 >> Can the spokes hear the traffic from the Hub to other spokes? This would= deliver the MAC address of the Hub too... >>=20 >>> In these cases, there needs to be a >>> way for the spoke modem to announce the link-state of the one and=20 >>> only link it has in a generic way. Given the lack of knowledge of=20 >>> the hub MAC, any attached router will need to ARP/ND for it anyway,=20 >>> using the FF:FF:FF:FF:FF:FF address, so there is some consistency there= . >>=20 >> So the idea is start only with a broadcast target and then later announc= e the unicast target as soon as we know it? We will get it as soon as we re= ceive the first data packet anyways. >>=20 >> I am not even sure we need to modify DLEP in any ways to support this hu= b&spoke topology. Even at the hub, DLEP should be fine to announce the comi= ng and going of spoke modems as detected by the linklayer... >> this might be a scenario where Stans 'stateful' solution is really bette= r than my older 'stateless' approach. Because we don't need to signal anyth= ing for a spoke that stays in the network... we just signal once "its there= ". >>=20 >> Henning Rogge >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From nobody Thu Jul 24 10:39:40 2014 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 6D1B21ACD01 for ; Thu, 24 Jul 2014 10:39:37 -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 wvBjABz2-Elx for ; Thu, 24 Jul 2014 10:39:34 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424941A8BB5 for ; Thu, 24 Jul 2014 10:39:34 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so3207253qaq.39 for ; Thu, 24 Jul 2014 10:39: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/fynnegUSk2R1b8O3cLIio/RvFRdiBJ3SnLErzInhak=; b=vTQfdcsffnJbGI+yg6egXUBc3A8DM/MPSStZP3EtGVK2KkX0sIOK7UrEcAliZnEi8U QRvAQLPKW+NuWMc6gWLJjhJ0kWiOr8eJYj1ZzgZjcPqz2fq66USGwphj98lBNATcKlMe Fja62KMkvEt0vDIMFAl+TbCtzHdNxm7pMWyjz7GvfQuMakI1jRfstFfZTVGFvs1bfpBC ipYfDM+qt1ryCEIbEryQH9Xry9NxW9o/Fh5SE9r0Mc4/WPtdgnJTT85U5XQZBTegRMk7 Pw/VfgfxtqH7rJacLIhqLzhI/SbXt+XqnKJFB66zNEHI+cwH+mzQ3dU0QQyzrjDrAsfL 5o3Q== X-Received: by 10.224.96.137 with SMTP id h9mr17867589qan.96.1406223573329; Thu, 24 Jul 2014 10:39:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Thu, 24 Jul 2014 10:39:13 -0700 (PDT) In-Reply-To: <2D3F794E-BA3E-4A6C-A590-0A35A232F7A0@cisco.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343045964@VAUS-MBX03.idirect.net> <2D3F794E-BA3E-4A6C-A590-0A35A232F7A0@cisco.com> From: Henning Rogge Date: Thu, 24 Jul 2014 19:39:13 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LboySgcQDD8NRuYJpX0XTiASGGg Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 17:39:37 -0000 On Thu, Jul 24, 2014 at 7:34 PM, Stan Ratliff (sratliff) wrote: >> The reason why DLEP is still desired is because it will allow one to con= figure the L3 timers to be much much higher. I can rely on DLEP to tell me= radio link up/down (even though Ethernet side is always connected). Hence= I can tune the L3 stuff to be a lot calmer and save a ton hello/ack packet= s AFTER convergence, since if the modem leaves network I can get a DLEP dow= n message to drive the router to withdraw the established L3 peer and conve= rge L3 in an event driven manner. In satellite we must protect the RF band= width because its very over subscribed and very expensive. The main driver= for me looking into these technologies is too protect the bandwidth -> hen= ce I am relying on dlep to pass radio interface events to drive convergence= . >> > > But I think the same problem exists on "Destination Down" as with "Destin= ation Up". Specifically, you said in an earlier email that identifying the = hub router, by MAC address, is difficult to do for providing the "Destinati= on Up". If that's the case, isn't it just as tough to identify the hub rout= er when it goes down? I don't understand the use case for when the hub rout= er and/or modem drops - how do you know to issue Destination Down to the sp= okes? > > Another thing to note - DLEP presentation of "Destination Up" does NOT ne= cessarily guarantee a routing adjacency to said destination. It means "some= thing connected via the RF". If the router's implementation is to issue a H= ELLO, and that HELLO is not answered by anyone other than the hub router, t= hen it all works as you want it to (I think). I wonder if it would be feasible in this "hub and spoke" topology for the hub to send a regular HELLO packet over the satellite link. This would allow the spokes to detect the hubs presence and its MAC address. Unless the satcom terminal itself "knows" if its connected or not. Henning Rogge From nobody Thu Jul 24 10:41:33 2014 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 4C1701A0A88 for ; Thu, 24 Jul 2014 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 q2MB8YoRCOJL for ; Thu, 24 Jul 2014 10:41:26 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id C62BD1A0ABC for ; Thu, 24 Jul 2014 10:41:22 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,725,1400040000"; d="scan'208";a="2567441" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 24 Jul 2014 13:41:22 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Thu, 24 Jul 2014 13:41:22 -0400 From: "Snyder, Brian" To: Henning Rogge , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAmQ04AABvhPAP//2ZeAgAA/4CD//8nsgIAAAWaAgABCzPA= Date: Thu, 24 Jul 2014 17:41:20 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF73430459D2@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF734304588B@VAUS-MBX03.idirect.net> <84585478AABBBF4B9DF597FC0F84AF7343045964@VAUS-MBX03.idirect.net> <2D3F794E-BA3E-4A6C-A590-0A35A232F7A0@cisco.com> 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: http://mailarchive.ietf.org/arch/msg/manet/m-n_ceNebVjJVWsEu40iELxS0aA Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 17:41:30 -0000 Yes the SATCOM terminal knows it's state in the network. That's what I am = using to determine if DLEP should send up/down... that's the exact link sta= te I am reporting on. Sorry for not explaining that before - I thought it = was clear. Funny how when the worlds collide what we all take for granted = is different ;) Thanks,brian -----Original Message----- From: Henning Rogge [mailto:hrogge@gmail.com]=20 Sent: Thursday, July 24, 2014 1:39 PM To: Stan Ratliff (sratliff) Cc: Snyder, Brian; Rick Taylor; manet@ietf.org Subject: Re: [manet] Request to consider for DLEP On Thu, Jul 24, 2014 at 7:34 PM, Stan Ratliff (sratliff) wrote: >> The reason why DLEP is still desired is because it will allow one to con= figure the L3 timers to be much much higher. I can rely on DLEP to tell me= radio link up/down (even though Ethernet side is always connected). Hence= I can tune the L3 stuff to be a lot calmer and save a ton hello/ack packet= s AFTER convergence, since if the modem leaves network I can get a DLEP dow= n message to drive the router to withdraw the established L3 peer and conve= rge L3 in an event driven manner. In satellite we must protect the RF band= width because its very over subscribed and very expensive. The main driver= for me looking into these technologies is too protect the bandwidth -> hen= ce I am relying on dlep to pass radio interface events to drive convergence= . >> > > But I think the same problem exists on "Destination Down" as with "Destin= ation Up". Specifically, you said in an earlier email that identifying the = hub router, by MAC address, is difficult to do for providing the "Destinati= on Up". If that's the case, isn't it just as tough to identify the hub rout= er when it goes down? I don't understand the use case for when the hub rout= er and/or modem drops - how do you know to issue Destination Down to the sp= okes? > > Another thing to note - DLEP presentation of "Destination Up" does NOT ne= cessarily guarantee a routing adjacency to said destination. It means "some= thing connected via the RF". If the router's implementation is to issue a H= ELLO, and that HELLO is not answered by anyone other than the hub router, t= hen it all works as you want it to (I think). I wonder if it would be feasible in this "hub and spoke" topology for the h= ub to send a regular HELLO packet over the satellite link. This would allow= the spokes to detect the hubs presence and its MAC address. Unless the satcom terminal itself "knows" if its connected or not. Henning Rogge From nobody Thu Jul 24 13:32:07 2014 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 9613E1B2869 for ; Thu, 24 Jul 2014 13:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 4CCWcFUdo3BZ for ; Thu, 24 Jul 2014 13:31:57 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 F0C5B1B28A1 for ; Thu, 24 Jul 2014 13:31:26 -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; Thu, 24 Jul 2014 21:30:52 +0100 From: Rick Taylor To: "manet@ietf.org" , "Snyder, Brian" Thread-Topic: Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8= Date: Thu, 24 Jul 2014 20:30:51 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net>, <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801148DAF62tssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/14SIzRwpX7hMcVqHpo2s1XXGCcE Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 20:31:59 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801148DAF62tssserver1hom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, All, As is often the case with me, I have changed my position on this one! After a long and messy fajita lunch with John Dowdell, he has pressed me to= actually drill down to what is the actual problem we believe Brian is tryi= ng to solve, and I believe I now have a clearer view. To recap: DLEP provides link state notification, what links are up or down,= what's the link like, and what's on the other end. The way DLEP identifie= s a link is by the MAC address of the router interface over which the remot= e DLEP session is running. This serves 2 purposes: 1) To uniquely identify= a link. 2) To allow a routing protocol to fast-start building adjacencies = without having to rely on hello timers, by advertising a layer-2 address to= send packets to. As I proposed in my extension draft, it is possible to split these 2 purpos= es, if and only if there is enough information supplied through DLEP to add= ress IP packets to the remote router via a link. This is the most importan= t part of identifiers, if there is no obvious way for a local router to mat= ch a remote router to a link, then it's all broken. In core DLEP (as alrea= dy mentioned) the MAC address does this, in my draft, the remote routers IP= address(es) MUST be supplied. And so to Brian's use-case. In his layer-2 bridging hub-spoke model, the h= ub isn't the issue, it's just stock DLEP. But, in the spoke modems, Brian = wants to avoid having to know the MAC address of the hub router, as there i= s only ever 1 link that is either up or down. So, the proposal was to iden= tify the link with the broadcast MAC (FF:FF:FF:FF:FF:FF) and forcing router= s to recognize this MAC as meaning "Go probe for the routers MAC". In retrospect, I have 3 problems with my aforementioned suggestion. 1) It adds a special case. 2) FF:FF:FF:FF:FF:FF is the broadcast MAC, and therefore should (like multi= cast MAC addresses) indicate information about broadcast, not treated as 'U= nknown'. 3) By not supplying a MAC address, a lot of the fast-start advantages for r= outing protocols are lost, in this case, you still need link local multicas= t hellos, all you know is when to start and stop saying hello. Also, Brian has latterly mentioned that in some configurations, spoke modem= s can actually pass layer-2 traffic to other spoke modems (via the hub at t= he RF layer). These are therefore alternate links/destinations, and there = must be some way of mapping the address of the attached router to the link = over which traffic is flowing, so FF:FF:FF:FF:FF:FF is definitely no good, = you must have MACs. Using 00:00:00:00:00:00 instead only fixes half the pr= oblem, you are still breaking fast-start. So, sorry Brian, I believe I was wrong, reusing the broadcast address as a = 'wildcard' link/destination ID isn't going to work consistently in the comm= on DLEP use-cases, and in yours it's probably a bad cludge. I have had this problem myself before, with military radios that did not (y= et) support DLEP, and only identified 'neighbours' by the radios RF-side MA= C. My solution was to add to my DLEP radio implementation for that kit (wh= ich proxied their management interface) a link-local multicast hello step. = This post-RF neighbour up, but pre-DLEP destination up, broadcasts some "W= ho is the router attached to radio MAC X?" and the router who is replies wi= th a unicast "It's me!", and the receiver can then unpack the senders MAC, = and then send on the DLEP destination up with the learned MAC. This is undeniably a pain. But, the pain is not DLEP's fault, it's just th= at if the information DLEP needs does not flow over the air within the radi= o's magic, it has to be done as a separate IP step within the radio DLEP pr= ocess (a workaround), or the radio magic needs to be changed (the best way)= . In Brian's case, and in the case of all the other radio manufacturers wh= o are reading this, you need to decide which of these two ways you want to = do it, but I now firmly believe that DLEP can't do what it can do by adding= a 'wildcard' address. I hope that helps? Rick ________________________________ From: manet [manet-bounces@ietf.org] on behalf of Rick Taylor [rick@tropica= lstormsoftware.com] Sent: 24 July 2014 16:46 To: Snyder, Brian; manet@ietf.org Subject: Re: [manet] Request to consider for DLEP As one of the people involved in the extensive discussions with Brian over = this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF solution, I= thought I ought to justify myself. Yes, it's a cludge. In an ideal world, the spoke modem in a hub and spoke = topology would announce it's link-state using the MAC address of the hub as= the destination identifier in the relevant signals. But, as Brian points = out, there are examples of existing technologies where a-priori configurati= on of the hub MAC, or retrofitting the passing of the hub MAC in the link-l= ayer signal is infeasible. In these cases, there needs to be a way for the= spoke modem to announce the link-state of the one and only link it has in = a generic way. Given the lack of knowledge of the hub MAC, any attached ro= uter will need to ARP/ND for it anyway, using the FF:FF:FF:FF:FF:FF address= , so there is some consistency there. Even if the all-FFs MAC is being used as a destination, there is nothing pr= eventing the same modem announcing other MAC destinations, with alternate l= ink state at a another time, so it doesn't break the existing DLEP model, i= n the same way that layer-3 has the default route concept (but obviously wi= th MAC's there is no concept of longest prefix, etc...) I think there needs to be some verbiage somewhere that states something alo= ng the lines of "If a modem will only ever have one link, e.g. a spoke in a= hub and spoke topology, and the MAC address of the destination router cann= ot be determined by the lower layer signalling, then the FF:FF:FF:FF:FF:FF = MAC address MAY be used, but this is NOT RECOMMENDED" (i.e. Do it properly = unless you *really* can't). @Brian: I think you might be arguing yourself into writing an informational= draft entitles "DLEP use-cases for Satcom". Also, as I think about it, this model might work for the 3G access point us= e-case. There is a link to a single destination, but, as with Satcom, the = MAC address of the destination router may not be available. Although, on f= urther consideration (I'm definitely thinking on my feet here) I think the = xG/LTE use-case is better addressed by my layer-3 extensions, as access-poi= nts don't operate as layer-2 bridges, and there may not even be a DLEP rout= er at the destination. Anyway, all food for thought and discussion... Rick --_000_38A5475DE83986499AEACD2CFAFC3F9801148DAF62tssserver1hom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Brian, All,

As is often the case with me, I have changed my position on this one!

After a long and messy fajita lunch with John Dowdell, he has pressed me to= actually drill down to what is the actual problem we believe Brian is tryi= ng to solve, and I believe I now have a clearer view.

To recap: DLEP provides link state notification, what links are up or down,= what's the link like, and what's on the other end.  The way DLEP iden= tifies a link is by the MAC address of the router interface over which the = remote DLEP session is running.  This serves 2 purposes: 1) To uniquely identify a link. 2) To allow a routing p= rotocol to fast-start building adjacencies without having to rely on hello = timers, by advertising a layer-2 address to send packets to.

As I proposed in my extension draft, it is possible to split these 2 purpos= es, if and only if there is enough information supplied through DLEP to add= ress IP packets to the remote router via a link.  This is the most imp= ortant part of identifiers, if there is no obvious way for a local router to match a remote router to a link, t= hen it's all broken.  In core DLEP (as already mentioned) the MAC addr= ess does this, in my draft, the remote routers IP address(es) MUST be suppl= ied.

And so to Brian's use-case.  In his layer-2 bridging hub-spoke model, = the hub isn't the issue, it's just stock DLEP.  But, in the spoke mode= ms, Brian wants to avoid having to know the MAC address of the hub router, = as there is only ever 1 link that is either up or down.  So, the proposal was to identify the link with the broad= cast MAC (FF:FF:FF:FF:FF:FF) and forcing routers to recognize this MAC as m= eaning "Go probe for the routers MAC". 

In retrospect, I have 3 problems with my aforementioned suggestion.
1) It adds a special case.
2) FF:FF:FF:FF:FF:FF is the broadcast MAC, and therefore should (like multi= cast MAC addresses) indicate information about broadcast, not treated as 'U= nknown'.
3) By not supplying a MAC address, a lot of the fast-start advantages for r= outing protocols are lost, in this case, you still need link local multicas= t hellos, all you know is when to start and stop saying hello.

Also, Brian has latterly mentioned that in some configurations, spoke modem= s can actually pass layer-2 traffic to other spoke modems (via the hub at t= he RF layer).  These are therefore alternate links/destinations, and t= here must be some way of mapping the address of the attached router to the link over which traffic is flowing, = so FF:FF:FF:FF:FF:FF is definitely no good, you must have MACs.  Using= 00:00:00:00:00:00 instead only fixes half the problem, you are still break= ing fast-start.

So, sorry Brian, I believe I was wrong, reusing the broadcast address as a = 'wildcard' link/destination ID isn't going to work consistently in the comm= on DLEP use-cases, and in yours it's probably a bad cludge. 

I have had this problem myself before, with military radios that did not (y= et) support DLEP, and only identified 'neighbours' by the radios RF-side MA= C.  My solution was to add to my DLEP radio implementation for that ki= t (which proxied their management interface) a link-local multicast hello step.  This post-RF neighbour up, but pr= e-DLEP destination up, broadcasts some "Who is the router attached to = radio MAC X?" and the router who is replies with a unicast "It's = me!", and the receiver can then unpack the senders MAC, and then send on the DLEP destination up with the learned MAC.

This is undeniably a pain.  But, the pain is not DLEP's fault, it's ju= st that if the information DLEP needs does not flow over the air within the= radio's magic, it has to be done as a separate IP step within the radio DL= EP process (a workaround), or the radio magic needs to be changed (the best way).  In Brian's case, and in th= e case of all the other radio manufacturers who are reading this, you need = to decide which of these two ways you want to do it, but I now firmly belie= ve that DLEP can't do what it can do by adding a 'wildcard' address.

I hope that helps?

Rick

 
From: manet [manet-bounces@ietf.org] on b= ehalf of Rick Taylor [rick@tropicalstormsoftware.com]
Sent: 24 July 2014 16:46
To: Snyder, Brian; manet@ietf.org
Subject: Re: [manet] Request to consider for DLEP

As one of the people involved in the extensive discussions with Brian = over this use case, and it was I who suggested the FF:FF:FF:FF:FF:FF soluti= on, I thought I ought to justify myself.

Yes, it's a cludge.  In an ideal world, the spoke modem in a hub and s= poke topology would announce it's link-state using the MAC address of the h= ub as the destination identifier in the relevant signals.  But, as Bri= an points out, there are examples of existing technologies where a-priori configuration of the hub MAC, or retrofitting = the passing of the hub MAC in the link-layer signal is infeasible.  In= these cases, there needs to be a way for the spoke modem to announce the l= ink-state of the one and only link it has in a generic way.  Given the lack of knowledge of the hub MAC, an= y attached router will need to ARP/ND for it anyway, using the FF:FF:FF:FF:= FF:FF address, so there is some consistency there.

Even if the all-FFs MAC is being used as a destination, there is nothing pr= eventing the same modem announcing other MAC destinations, with alternate l= ink state at a another time, so it doesn't break the existing DLEP model, i= n the same way that layer-3 has the default route concept (but obviously with MAC's there is no concept of= longest prefix, etc...)

I think there needs to be some verbiage somewhere that states something alo= ng the lines of "If a modem will only ever have one link, e.g. a spoke= in a hub and spoke topology, and the MAC address of the destination router= cannot be determined by the lower layer signalling, then the FF:FF:FF:FF:FF:FF MAC address MAY be used, but this i= s NOT RECOMMENDED" (i.e. Do it properly unless you *really* can't).
@Brian: I think you might be arguing yourself into writing an informational= draft entitles "DLEP use-cases for Satcom".

Also, as I think about it, this model might work for the 3G access point us= e-case.  There is a link to a single destination, but, as with Satcom,= the MAC address of the destination router may not be available.  Alth= ough, on further consideration (I'm definitely thinking on my feet here) I think the xG/LTE use-case is better addressed = by my layer-3 extensions, as access-points don't operate as layer-2 bridges= , and there may not even be a DLEP router at the destination.

Anyway, all food for thought and discussion...

Rick


--_000_38A5475DE83986499AEACD2CFAFC3F9801148DAF62tssserver1hom_-- From nobody Thu Jul 24 15:51:33 2014 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 B90771B290F for ; Thu, 24 Jul 2014 15:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 0DQWavPa90xt for ; Thu, 24 Jul 2014 15:51:27 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46D1B290C for ; Thu, 24 Jul 2014 15:51:26 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,727,1400040000"; d="scan'208";a="2577325" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 24 Jul 2014 18:51:25 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Thu, 24 Jul 2014 18:51:25 -0400 From: "Snyder, Brian" To: Rick Taylor , "manet@ietf.org" Thread-Topic: Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0A== Date: Thu, 24 Jul 2014 22:51:24 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net>, <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4Pr_VNs-Iv3yKyLE9lLqdz9xgZs Subject: Re: [manet] Request to consider for DLEP 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, 24 Jul 2014 22:51:30 -0000 Q29tbWVudHMgZW1iZWRkZWTigKYuLg0KDQpGcm9tOiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tA dHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVseSAyNCwgMjAx NCA0OjMxIFBNDQpUbzogbWFuZXRAaWV0Zi5vcmc7IFNueWRlciwgQnJpYW4NClN1YmplY3Q6IFJF OiBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQDQoNCkJyaWFuLCBBbGwsIA0KDQpBcyBpcyBv ZnRlbiB0aGUgY2FzZSB3aXRoIG1lLCBJIGhhdmUgY2hhbmdlZCBteSBwb3NpdGlvbiBvbiB0aGlz IG9uZSENCg0KQWZ0ZXIgYSBsb25nIGFuZCBtZXNzeSBmYWppdGEgbHVuY2ggd2l0aCBKb2huIERv d2RlbGwsIGhlIGhhcyBwcmVzc2VkIG1lIHRvIGFjdHVhbGx5IGRyaWxsIGRvd24gdG8gd2hhdCBp cyB0aGUgYWN0dWFsIHByb2JsZW0gd2UgYmVsaWV2ZSBCcmlhbiBpcyB0cnlpbmcgdG8gc29sdmUs IGFuZCBJIGJlbGlldmUgSSBub3cgaGF2ZSBhIGNsZWFyZXIgdmlldy4NCg0KVG8gcmVjYXA6IERM RVAgcHJvdmlkZXMgbGluayBzdGF0ZSBub3RpZmljYXRpb24sIHdoYXQgbGlua3MgYXJlIHVwIG9y IGRvd24sIHdoYXQncyB0aGUgbGluayBsaWtlLCBhbmQgd2hhdCdzIG9uIHRoZSBvdGhlciBlbmQu wqAgVGhlIHdheSBETEVQIGlkZW50aWZpZXMgYSBsaW5rIGlzIGJ5IHRoZSBNQUMgYWRkcmVzcyBv ZiB0aGUgcm91dGVyIGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSByZW1vdGUgRExFUCBzZXNzaW9u IGlzIHJ1bm5pbmcuwqAgVGhpcyBzZXJ2ZXMgMiBwdXJwb3NlczogMSkgVG8gdW5pcXVlbHkgaWRl bnRpZnkgYSBsaW5rLiAyKSBUbyBhbGxvdyBhIHJvdXRpbmcgcHJvdG9jb2wgdG8gZmFzdC1zdGFy dCBidWlsZGluZyBhZGphY2VuY2llcyB3aXRob3V0IGhhdmluZyB0byByZWx5IG9uIGhlbGxvIHRp bWVycywgYnkgYWR2ZXJ0aXNpbmcgYSBsYXllci0yIGFkZHJlc3MgdG8gc2VuZCBwYWNrZXRzIHRv Lg0KDQpbQlNTXSDigJMgQW5kIEkgZ3Vlc3MgSSBhbSBsb29raW5nIGZvciBzb21ldGhpbmcgZGlm ZmVyZW50LiAgSeKAmW0gbG9va2luZyBmb3IgbGluayBzdGF0ZSBub3RpZmljYXRpb25zICh3aXRo IG1ldHJpY3MpIHRvICAtIGFuZCB0aGlzIGlzIGEgZGlmZmVyZW50ICMyIOKAkyBhbGxvdyBhIHJv dXRpbmcgcHJvdG9jb2wgdG8gYmUgdHVuZWQgZm9yIG1pbmltdW0gS0VFUCBBTElWRSB0aW1lcnMg dG8gbWluaW1pemUgYmFuZHdpZHRoIHVzYWdlIHRvIGNvbnNlcnZlIHZlcnkgZXhwZW5zaXZlIGFu ZCBsaW1pdGVkIGJhbmR3aWR0aC4gIEluIGEgc2F0ZWxsaXRlIG5ldHdvcmssIHRoZXJlIGlzIG5v IG5lZWQgZm9yIGZhc3Qtc3RhcnRzLCBMMSBjb252ZXJnZW5jZSBjYW4gKGFuZCBpbiBhIHN1aXRh Ymx5IHNpemVkIG5ldHdvcmsgd2lsbCB0YWtlIHNlY29uZHMpLiAgSG93ZXZlciwgYmVjYXVzZSBt b2RlbXMgdGVuZCB0byBzdGF5IGluIG5ldHdvcmsgcXVpdGUgc3RhYmx5ICh0cmVlcyBhbmQgYnVp bGRpbmdzIGRvbuKAmXQgZ2V0IHRoZSB3YXkgb2Z0ZW4gaW4gdGhlIG9jZWFu4pi6KSwgdGhlIGJ1 aWxkaW5nIG9mIGFkamFjZW5jaWVzIGRvZXMgbm90IGhhcHBlbiBhbGwgdGhhdCBvZnRlbi4gSXTi gJlzIHdheSBtb3JlIGltcG9ydGFudCB0byBtZSB0byBjb25zZXJ2ZSBiYW5kd2lkdGggYW5kIGJl IHRyYW5zcGFyZW50Lg0KDQoNCkFzIEkgcHJvcG9zZWQgaW4gbXkgZXh0ZW5zaW9uIGRyYWZ0LCBp dCBpcyBwb3NzaWJsZSB0byBzcGxpdCB0aGVzZSAyIHB1cnBvc2VzLCBpZiBhbmQgb25seSBpZiB0 aGVyZSBpcyBlbm91Z2ggaW5mb3JtYXRpb24gc3VwcGxpZWQgdGhyb3VnaCBETEVQIHRvIGFkZHJl c3MgSVAgcGFja2V0cyB0byB0aGUgcmVtb3RlIHJvdXRlciB2aWEgYSBsaW5rLsKgIFRoaXMgaXMg dGhlIG1vc3QgaW1wb3J0YW50IHBhcnQgb2YgaWRlbnRpZmllcnMsIGlmIHRoZXJlIGlzIG5vIG9i dmlvdXMgd2F5IGZvciBhIGxvY2FsIHJvdXRlciB0byBtYXRjaCBhIHJlbW90ZSByb3V0ZXIgdG8g YSBsaW5rLCB0aGVuIGl0J3MgYWxsIGJyb2tlbi7CoCBJbiBjb3JlIERMRVAgKGFzIGFscmVhZHkg bWVudGlvbmVkKSB0aGUgTUFDIGFkZHJlc3MgZG9lcyB0aGlzLCBpbiBteSBkcmFmdCwgdGhlIHJl bW90ZSByb3V0ZXJzIElQIGFkZHJlc3MoZXMpIE1VU1QgYmUgc3VwcGxpZWQuDQoNCkFuZCBzbyB0 byBCcmlhbidzIHVzZS1jYXNlLsKgIEluIGhpcyBsYXllci0yIGJyaWRnaW5nIGh1Yi1zcG9rZSBt b2RlbCwgdGhlIGh1YiBpc24ndCB0aGUgaXNzdWUsIGl0J3MganVzdCBzdG9jayBETEVQLsKgIA0K W0JTU10g4oCTIEFncmVlZC4NCg0KQnV0LCBpbiB0aGUgc3Bva2UgbW9kZW1zLCBCcmlhbiB3YW50 cyB0byBhdm9pZCBoYXZpbmcgdG8ga25vdyB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGh1YiByb3V0 ZXIsIGFzIHRoZXJlIGlzIG9ubHkgZXZlciAxIGxpbmsgdGhhdCBpcyBlaXRoZXIgdXAgb3IgZG93 bi7CoCBTbywgdGhlIHByb3Bvc2FsIHdhcyB0byBpZGVudGlmeSB0aGUgbGluayB3aXRoIHRoZSBi cm9hZGNhc3QgTUFDIChGRjpGRjpGRjpGRjpGRjpGRikgYW5kIGZvcmNpbmcgcm91dGVycyB0byBy ZWNvZ25pemUgdGhpcyBNQUMgYXMgbWVhbmluZyAiR28gcHJvYmUgZm9yIHRoZSByb3V0ZXJzIE1B QyIuwqAgDQoNCkluIHJldHJvc3BlY3QsIEkgaGF2ZSAzIHByb2JsZW1zIHdpdGggbXkgYWZvcmVt ZW50aW9uZWQgc3VnZ2VzdGlvbi4NCjEpIEl0IGFkZHMgYSBzcGVjaWFsIGNhc2UuXA0KW0JTU10g 4oCTIFNhdGVsbGl0ZSBpcyBhbHdheXMgYSBzcGVjaWFsIGNhc2UgOykgIE1vc3QgZm9sa3MgZG9u 4oCZdCDigJhkZWZlbmTigJkgYmFuZHdpZHRoIGxpa2Ugd2UgZG8uICBFdmVyeSBkZWNpc2lvbiB3 ZSBtYWtlIGlzIHdpdGggdGhlIG5vdGlvbiB0aGF0IGl0IGNvc3RzIHRob3VzYW5kcyBhbmQgdGhv dXNhbmRzIG9mIGRvbGxhcnMgcGVyIE1CIHBlciBtb250aCBpbiBiYW5kd2lkdGggY29zdHMgYWxv bmUgYW5kIGFzIGEgcmVzdWx0IG9mIHRoYXQgbmV0d29ya3MgYXJlIHVzdWFsbHkgdmVyeSBvdmVy c3Vic2NyaWJlZC4NCg0KMikgRkY6RkY6RkY6RkY6RkY6RkYgaXMgdGhlIGJyb2FkY2FzdCBNQUMs IGFuZCB0aGVyZWZvcmUgc2hvdWxkIChsaWtlIG11bHRpY2FzdCBNQUMgYWRkcmVzc2VzKSBpbmRp Y2F0ZSBpbmZvcm1hdGlvbiBhYm91dCBicm9hZGNhc3QsIG5vdCB0cmVhdGVkIGFzICdVbmtub3du Jy4NCltCU1NdIOKAkyBUaGF04oCZcyB3aHkgaXTigJlzIGEgc3BlY2lhbCBjYXNlIDspLiAgSSBo YXZlIG5vIHJlYWwgZGVzaXJlIHRvIHVzZSBGRkZGRkZGRiDigJMgSSBkb27igJl0IHJlYWxseSBj YXJlIGFib3V0IHRoYXQsIEkgcHJvcG9zZSBhIHNwZWNpYWwgVExWIGZvciB0aGlzIHB1cnBvc2Ug YmVjYXVzZSBpZiB5b3UgcmVjYWxsIEkgZGlkbuKAmXQgd2FudCB0byByZS11c2Ugc29tZXRoaW5n IHRoYXQgYWxyZWFkeSBoYXMgYSAgcHVycG9zZSDigJMgdGhhdOKAmXMgZGVmaW5pdGVseSBtb3Jl IGNvbXBsZXggZWl0aGVyIHdpdGggY29uZmlnIG9yIHN0YXRlIG1hY2hpbmUga25vd2xlZGdlLCBh bmQgdGhlcmVmb3JlIGEgaGFyZGVyIHNlbGwuDQoNCjMpIEJ5IG5vdCBzdXBwbHlpbmcgYSBNQUMg YWRkcmVzcywgYSBsb3Qgb2YgdGhlIGZhc3Qtc3RhcnQgYWR2YW50YWdlcyBmb3Igcm91dGluZyBw cm90b2NvbHMgYXJlIGxvc3QsIGluIHRoaXMgY2FzZSwgeW91IHN0aWxsIG5lZWQgbGluayBsb2Nh bCBtdWx0aWNhc3QgaGVsbG9zLCBhbGwgeW91IGtub3cgaXMgd2hlbiB0byBzdGFydCBhbmQgc3Rv cCBzYXlpbmcgaGVsbG8uDQpbQlNTXSDigJMgQWN0dWFsbHksIHlvdSBjYW4gYWx3YXlzIHNlbmQg eW91ciBtdWx0aWNhc3QgcHJvYmVz4oCmIGlmIEnigJltIG91dCBvZiBuZXR3b3JrIHRoZXkganVz dCB3b27igJl0IGdvIGFueXdoZXJlLiBXaGF0IEkgd2FudCBpcyBmb3IgYSBET1dOIHRvIFVQIHRy YW5zaXRpb24gdG8gcmVzZXQgYW55IGNvbm5lY3RlZCBMMyBwZWVycyBhbmQgYXNzb2NpYXRlZCBy b3V0ZXMgKGFzIGlmIHlvdSBwdWxsZWQgdGhlIE5JQyBjYWJsZSkuIFRoZSByZXN0IHNob3VsZCBh bmQgY291bGQgaGFwcGVuIHdpdGhvdXQgYW55IHNwZWNpYWwga25vd2xlZGdlIOKAkyB0aGUgcm91 dGVyIHNob3VsZCBhY3QgbGlrZSBub3JtYWwuDQoNCg0KQWxzbywgQnJpYW4gaGFzIGxhdHRlcmx5 IG1lbnRpb25lZCB0aGF0IGluIHNvbWUgY29uZmlndXJhdGlvbnMsIHNwb2tlIG1vZGVtcyBjYW4g YWN0dWFsbHkgcGFzcyBsYXllci0yIHRyYWZmaWMgdG8gb3RoZXIgc3Bva2UgbW9kZW1zICh2aWEg dGhlIGh1YiBhdCB0aGUgUkYgbGF5ZXIpLsKgIFRoZXNlIGFyZSB0aGVyZWZvcmUgYWx0ZXJuYXRl IGxpbmtzL2Rlc3RpbmF0aW9ucywgYW5kIHRoZXJlIG11c3QgYmUgc29tZSB3YXkgb2YgbWFwcGlu ZyB0aGUgYWRkcmVzcyBvZiB0aGUgYXR0YWNoZWQgcm91dGVyIHRvIHRoZSBsaW5rIG92ZXIgd2hp Y2ggdHJhZmZpYyBpcyBmbG93aW5nLCBzbyBGRjpGRjpGRjpGRjpGRjpGRiBpcyBkZWZpbml0ZWx5 IG5vIGdvb2QsIHlvdSBtdXN0IGhhdmUgTUFDcy7CoCBVc2luZyAwMDowMDowMDowMDowMDowMCBp bnN0ZWFkIG9ubHkgZml4ZXMgaGFsZiB0aGUgcHJvYmxlbSwgeW91IGFyZSBzdGlsbCBicmVha2lu ZyBmYXN0LXN0YXJ0Lg0KW0JTU10g4oCTIFllcyBJIGFtIGtub3dpbmdseSBicmVha2luZyBmYXN0 LXN0YXJ0LiAgSXTigJlzIHBvc3NpYmxlIHNvbWVvbmUgY291bGQgY29uZmlndXJlIHVzIHRvIOKA mGtub3figJkgdGhlIG1hYyBpZiB0aGV5IHdhbnRlZCB0aGlzIGZlYXR1cmUg4oCTIGJ1dCBJIGRv dWJ0IGl0IHdvdWxkIGJlIHZlcnkgcG9wdWxhci4gIE1vc3QgZm9sa3Mgd291bGRu4oCZdCB3YW50 IHRoZSBPQU0gYnVyZGVuIHRvIHNhdmUgMSBzZWMgb24gc29tZXRoaW5nIHRoYXQgd2lsbCB0YWtl IHNheSA1IGFueXdheS4gIEFuZCB0aGVyZSBpcyBhbm90aGVyIGRpZmZlcmVuY2UgeW914oCZcmUg bWlzc2luZy4gIFRoYXQgZGlmZmVyZW5jZSBpcyBiZWNhdXNlIEnigJltIG5vdCBNRVNIIEkgKkRP TuKAmVQqIG5lZWQgdG8ga25vdyBhbnkgbWFjcyBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgbmV0 d29yay4gQ3VycmVudGx5IG1vZGVtcyBkbyBub3Qga25vdyB0aGF0IGluZm9ybWF0aW9uLiAgUmVn YXJkbGVzcyBvZiBWUFdTIG9yIFZQTFMgbW9kZS4gIFJlbWVtYmVyIHRoZSBtb2RlbXMgaGF2ZSBh IOKAmE5PVC1MT0NBTCBNQUMgdGhlbiBGV0QgT1RB4oCZIGxvZ2ljLiAgVGhpcyB3b3JrcyB3ZWxs IGZvciB1cywgYW5kIGluIGZhY3QgaXMgbWFuZGF0b3J5LiAgUmVhc29uIGJlaW5nIHRoYXQgaWYg b25lIGlzIGNvbmZpZ3VyZWQgdG8gYWxsb3cgaGFpcnBpbm5pbmcsIHRoZSBtb2RlbXMgd291bGQg cG90ZW50aWFsbHkgaGF2ZSB0byBsZWFybiBNQUMgYWRkcmVzc2VzIGluIHRoZSB0aG91c2FuZHMg dG8gaHVuZHJlZHMgb2YgdGhvdXNhbmRzLiBUaGF0IHNpbXBseSBjYW7igJl0IGFuZCB3b27igJl0 IHNjYWxlIG9uIG1vZGVtcy4gV2UgY29uc2Npb3VzbHkgZGVjaWRlZCBOT1QgdG8gc3RvcmUgdGhl IGh1YiBzaWRlIG1hYyBpbmZvcm1hdGlvbiDigJMgYmVjYXVzZSB3ZSBkb27igJl0IG5lZWQgaXQu ICBJdOKAmXMgbm90IGEgbWVzaCBzeXN0ZW0gYW55d2F5IHNvIGlmICBhIGN1c3RvbWVyIGRldmlj ZSB3YW50cyB0byB0YWxrIHRvIGFub3RoZXIgY3VzdG9tZXIgZGV2aWNlIG9mZiBhIG1vZGVtIGxh biDigJMgaGUgc3RpbGwgTVVTVCBnbyB0aHJvdWdoIHRoZSBodWIgYW55d2F5LiAgVGhlIGh1YiB3 aWxsIGhhdmUgYSBmdWxsIEZJQiBvZiB0aGUgbmV0d29yayBhbmQgaGFpcnBpbiBpdCBpZiBpdCBp cyBuZWNlc3NhcnkgKGFuZCBhbGxvd2VkKSB0byBkbyBzby4gIElmIEkgaGF2ZSB0byBtYWludGFp biB0aGlzIEwyIHN0YXRlIGZvciB0aGUgcm91dGVyIHRoZW4gSSBoYXZlIHRvbyBtdWNoIGNvbXBs aWNhdGlvbiBpbiBhIG1vZGVtIHRoYXQgaXQgaXMgbm90IGRlc2lnbmVkIG5vciBjYXBhYmxlIG9m IGhhbmRsaW5nLiAgRXZlbiBpZiBpdCBjb3VsZCwgaXQgc3RvcHMgbWUgZnJvbSBiZWluZyB0cmFu c3BhcmVudCB3aGljaCBpcyBhIHZlcnkgaW1wb3J0YW50IGRlc2lnbiBnb2FsIGZvciB1cy4gIE1v cmUgaW1wb3J0YW50bHkgdGhvdWdoLCBwdXR0aW5nIHRoaXMgT0FNIGJ1cmRlbiBvbiB0aGUgbW9k ZW0gd2lsbCBoYXZlIHNjYWxlIHJhbWlmaWNhdGlvbnMgdGhhdCBJ4oCZbSBub3Qgc3VyZSB3ZSBj b3VsZCBsaXZlIHdpdGguIChJdCBjb3VsZCBiZSBpbnZlc3RpZ2F0ZWQgdGhvdWdoKS4gIFNlZSBh IFNBVCBtb2RlbSBpbiBhIHN0YXIgbmV0d29yayB3aWxsIG9ubHkgZXZlciBoYXZlIDIgaW50ZXJm YWNlcyDigJMgb25lIGxhbiwgb25lIHJmLiAgSSB1bmRlcnN0YW5kIGEgcm91dGVyIG1heSBoYXZl IG1hbnksIGJ1dCBlc3NlbnRpYWxseSBvbiB0aGUgaW50ZXJmYWNlIHdlIGFyZSBpbnRlcm5ldHdv cmtpbmcgb24sIEkgZ3Vlc3MgSSBhbSB0cnlpbmcgdG8gZ2V0IHRoZSByb3V0ZXIgdG8gdGhpbmsg bGlrZSB0aGUgbW9kZW0gYSBsaXR0bGUgYml0IGJlY2F1c2UgaXQgd2lsbCBncmVhdGx5IHNpbXBs aWZ5IHRoZSBzeXN0ZW0uICBJIGZ1bGx5IHVuZGVyc3RhbmQgbXkgdXNlIGNhc2UgbWlnaHQgYmUg dGhlIG9ubHkgb25lIHRoYXQgdGhpbmtzIHRoaXMgd2F5IC0tLSBpdOKAmXMgY2xlYXIgRExFUCB3 YXNu4oCZdCBkZXNpZ25lZCBmb3IgdGhpcyB1c2UgY2FzZSBmcm9tIHRoZSBiZWdpbm5pbmcg4oCT IHdoaWNoIGlzIHdoeSBJIGVuZGVkIHVwIHVzaW5nIEJGRCB0byBiZWdpbiB3aXRoLg0KDQoNClNv LCBzb3JyeSBCcmlhbiwgSSBiZWxpZXZlIEkgd2FzIHdyb25nLCByZXVzaW5nIHRoZSBicm9hZGNh c3QgYWRkcmVzcyBhcyBhICd3aWxkY2FyZCcgbGluay9kZXN0aW5hdGlvbiBJRCBpc24ndCBnb2lu ZyB0byB3b3JrIGNvbnNpc3RlbnRseSBpbiB0aGUgY29tbW9uIERMRVAgdXNlLWNhc2VzLCBhbmQg aW4geW91cnMgaXQncyBwcm9iYWJseSBhIGJhZCBjbHVkZ2UuwqAgDQoNCltCU1NdIEkgZG9u4oCZ dCB1bmRlcnN0YW5kIHdoeSBpdOKAmXMgYSBjbHVkZ2UuIEFsbCBJIGFtIGFza2luZyBmb3IgaXMg dGhlIHJvdXRlciB0byBiZWhhdmUgZXhhY3RseSBsaWtlIGl0IHdvdWxkIGlmIGRsZXAgd2FzbuKA mXQgYmVpbmcgdXNlZCBhdCBhbGwuIEJ1dCB3aXRoIERMRVAgaXTigJlzIHBvc3NpYmxlIHRvIGNh bG0gZG93biB0aGUg4oCcU1RJTEwtVEhFUkXigJ0gcHJvYmVzIG9uY2Ugcm91dGluZyBhZGphY2Vu Y2llcyBhcmUgZGlzY292ZXJlZC4gIEnigJltIG5vdCBhc2tpbmcgYSByb3V0ZXIgdG8gZG8gc29t ZXRoaW5nIGl0IGNhbuKAmXQgaW50cmluc2ljYWxseSBkby4gIEkga25vdyBpdCBjYW4gYmVoYXZl IHRoaXMgd2F5IGJlY2F1c2UgdGhhdOKAmXMgZXNzZW50aWFsbHkgZXhhY3RseSB3aGF0IEJGRCBk b2VzIChqdXN0IHdpdGhvdXQgbWV0cmljcykuICANCg0KDQpJIGhhdmUgaGFkIHRoaXMgcHJvYmxl bSBteXNlbGYgYmVmb3JlLCB3aXRoIG1pbGl0YXJ5IHJhZGlvcyB0aGF0IGRpZCBub3QgKHlldCkg c3VwcG9ydCBETEVQLCBhbmQgb25seSBpZGVudGlmaWVkICduZWlnaGJvdXJzJyBieSB0aGUgcmFk aW9zIFJGLXNpZGUgTUFDLsKgIE15IHNvbHV0aW9uIHdhcyB0byBhZGQgdG8gbXkgRExFUCByYWRp byBpbXBsZW1lbnRhdGlvbiBmb3IgdGhhdCBraXQgKHdoaWNoIHByb3hpZWQgdGhlaXIgbWFuYWdl bWVudCBpbnRlcmZhY2UpIGEgbGluay1sb2NhbCBtdWx0aWNhc3QgaGVsbG8gc3RlcC7CoCBUaGlz IHBvc3QtUkYgbmVpZ2hib3VyIHVwLCBidXQgcHJlLURMRVAgZGVzdGluYXRpb24gdXAsIGJyb2Fk Y2FzdHMgc29tZSAiV2hvIGlzIHRoZSByb3V0ZXIgYXR0YWNoZWQgdG8gcmFkaW8gTUFDIFg/IiBh bmQgdGhlIHJvdXRlciB3aG8gaXMgcmVwbGllcyB3aXRoIGEgdW5pY2FzdCAiSXQncyBtZSEiLCBh bmQgdGhlIHJlY2VpdmVyIGNhbiB0aGVuIHVucGFjayB0aGUgc2VuZGVycyBNQUMsIGFuZCB0aGVu IHNlbmQgb24gdGhlIERMRVAgZGVzdGluYXRpb24gdXAgd2l0aCB0aGUgbGVhcm5lZCBNQUMuDQoN ClRoaXMgaXMgdW5kZW5pYWJseSBhIHBhaW4uwqAgQnV0LCB0aGUgcGFpbiBpcyBub3QgRExFUCdz IGZhdWx0LCBpdCdzIGp1c3QgdGhhdCBpZiB0aGUgaW5mb3JtYXRpb24gRExFUCBuZWVkcyBkb2Vz IG5vdCBmbG93IG92ZXIgdGhlIGFpciB3aXRoaW4gdGhlIHJhZGlvJ3MgbWFnaWMsIGl0IGhhcyB0 byBiZSBkb25lIGFzIGEgc2VwYXJhdGUgSVAgc3RlcCB3aXRoaW4gdGhlIHJhZGlvIERMRVAgcHJv Y2VzcyAoYSB3b3JrYXJvdW5kKSwgb3IgdGhlIHJhZGlvIG1hZ2ljIG5lZWRzIHRvIGJlIGNoYW5n ZWQgKHRoZSBiZXN0IHdheSkuwqAgSW4gQnJpYW4ncyBjYXNlLCBhbmQgaW4gdGhlIGNhc2Ugb2Yg YWxsIHRoZSBvdGhlciByYWRpbyBtYW51ZmFjdHVyZXJzIHdobyBhcmUgcmVhZGluZyB0aGlzLCB5 b3UgbmVlZCB0byBkZWNpZGUgd2hpY2ggb2YgdGhlc2UgdHdvIHdheXMgeW91IHdhbnQgdG8gZG8g aXQsIGJ1dCBJIG5vdyBmaXJtbHkgYmVsaWV2ZSB0aGF0IERMRVAgY2FuJ3QgZG8gd2hhdCBpdCBj YW4gZG8gYnkgYWRkaW5nIGEgJ3dpbGRjYXJkJyBhZGRyZXNzLg0KDQpbQlNTXSBJIHVuZGVyc3Rh bmQgdGhlIHJlcXVlc3QgaXMgb25seSBhcHBsaWNhYmxlIHRvIG1vZGVzIGluIHdoaWNoIHdlIGtu b3cgdGhlcmUgd2lsbCBub3QgYmUgbXVsdGlwbGUgRExFUCBzZXNzaW9ucyDigJMgYnV0IGdpdmVu IHRoYXTigJlzIGEgdmFsaWQgdXNlIGNhc2UgKGFsbCBub24tbWVzaCBuZXR3b3JrcyB3b3VsZCBm aXQgdGhpcyBJIGJlbGlldmUpIEkgdGhpbmsgaXQgd291bGQgd29yaywgaWYgdGhlcmUgd2FzIGFu eSBpbnRlcmVzdCBiZXNpZGVzIG1pbmUgOykgIA0KDQpBZ2FpbiwgSeKAmW0gbm90IGNvbWluZyBh dCB0aGlzIGJlY2F1c2UgSeKAmW0gYWZyYWlkIHRvIG1ha2Ugc29tZSBjaGFuZ2VzIHRvIHRoZSBt b2RlbS4gSSBjb3VsZCBwcm9iYWJseSBjb2RlIHRoaXMgdXAgaW4gYSBwcm90b3R5cGUgZWFzeSBl bm91Z2ggZWl0aGVyIHdheS4gIEnigJltIHN0aWNraW5nIHRvIG15IGd1bnMgb24gdGhpcyBvbmUg YmVjYXVzZSBJIGhhdmUgY29uY2VybnMgYWJvdXQ6DQoNCuKAoiBpdCBhZGRzIGFkZGl0aW9uYWwg T0FNIGFuZCBjb25maWcgbWFuYWdlbWVudCBjb21wbGV4aXR5IHRvIHRob3VzYW5kcyBvZiBub2Rl cy4gIEkgdGhpbmsgbW9zdCBtZXNoIHBlb3BsZSBjb25zaWRlciA0MCBtb2RlbXMgYSBiaWcgbmV0 d29yayDigJMgYnV0IEkgaGF2ZSB0byB0aGluayBhYm91dCB0aGluZ3MgaW4gdGVybXMgb2YgYSBo dW5kcmVkIHRob3VzYW5kLiAgSGF2aW5nIHRvIGNvbmZpZ3VyZSBzb21ldGhpbmcgdGhlbiBJIGRv bid0IHJlYWxseSBoYXZlIHRvIGNvbmZpZ3VyZSBub3Igb3RoZXJ3aXNlIGtub3cgaXMganVzdCBv bmUgbW9yZSB0aGluZyB0aGF0IGNvdWxkIGdvIHdyb25nLi4uIHdlIGRvbid0IGxpa2UgdGhpbmdz IHRvIGdvIHdyb25nIG9uIGEgbW9kZW0gYmVjYXVzZSB0aGV5IGFyZSB1c3VhbGx5IHZlcnkgaW5j b252ZW5pZW50bHkgbG9jYXRlZCA7KQ0K4oCiIGhvd2V2ZXIsIGF1dG8gZmlndXJpbmcgZXZlcnl0 aGluZyBvdXQgYW5kIHRyeWluZyB0byBzaGFyZSBhbGwgcG9zc2libGUgTUFDUyBpcyBhIHNjYWxl IGlzc3VlLCBJ4oCZbSBkb3VidGZ1bCBJIGNhbiBzb2x2ZS4gIFNvIGl0IHdvdWxkIHRoZXJlZm9y ZSBsaW1pdCB0aGlzIGZlYXR1cmUgdG8gc21hbGwgbmV0d29ya3MuIChFeGFjdGx5IGhvdyBzbWFs bCDigJMgSeKAmWQgaGF2ZSB0byBkbyBzb21lIG1hdGgpLg0K4oCiIE1vc3QgaW1wb3J0YW50bHkg LS0tIEl0IHdvdWxkIGJyZWFrIG91ciBkZXNpZ24gZ29hbCBvZiBiZWluZyBhIHRyYW5zcGFyZW50 IGJyaWRnZS4gIElmIHdlIGhhZCB0byDigJhrbm934oCZIGFuZCBjb25maWd1cmUgYSBzcGVjaWFs IE1BQyBvciBzZXQgb2YgTUFDIHdlIGFyZSBub3QgdHJhbnNwYXJlbnQuICBJZiB3ZSBhcmVuJ3Qg dHJhbnNwYXJlbnQsIHRoZW4gYSBjYXNlIGNvdWxkIGJlIG1hZGUgdG8ganVzdCBnbyBhaGVhZCBh bmQgdXNlIHVzIGluIEwzIG1vZGUgYW5kIG5vbmUgb2YgdGhpcyBpcyBuZWVkZWQuIFdlIGNhbiBq dXN0IHdpdGhkcmF3IHJvdXRlcyB3aGVuIG1vZGVtIGxlYXZlcyBuZXR3b3JrLg0KDQpTbywgeWVz LCBJIGFtIGFza2luZyBmb3IgdGhpcyB1c2UgY2FzZSB0byBnZXQgc3BlY2lhbCBjb25zaWRlcmF0 aW9u4oCmLiBJIHdvdWxkbuKAmXQgY29uc2lkZXIgaXQgdGhlIFNhdGVsbGl0ZSB1c2UgY2FzZSB0 aG91Z2gsIEkgd291bGQgY29uc2lkZXIgaXQgdGhlIOKAnFNpbXBsaWZpZWQgb3BlcmF0aW9ucyBp biBhIG5vbi1tZXNoIHJhZGlvIG5ldHdvcmvigJ0g4oCmLiB0aGVyZWZvcmUgaXQgY291bGQgYXBw bHkgdG8gbW9yZSBwZW9wbGUuDQoNCklmIHRoZXJlIGlzIG5vIGludGVyZXN0IGluIGZ1cnRoZXIg Y29uc2lkZXJhdGlvbiBvZiB0aGlzIHVzZSBjYXNlLCBmYWlyIGVub3VnaCDigJMgSeKAmW0gdXNl ZCB0byBzYXRlbGxpdGUgYmVpbmcgYSBsb25lIHdvbGYgOykgLS0gSSBzdGlsbCBoYXZlIHRoZSBi ZmQgcHJveHkgSSBwcmVzZW50ZWQgd2hpY2ggbW9zdGx5IHNvbHZlcyBteSBwcm9ibGVtLCBJIGNh biBhbHdheXMganVzdCBsb29rIHRvIG1hdHVyZSB0aGF0IHdpdGhpbiB0aGUgYmZkIGdyb3VwLg0K DQpJdCB3YXMgZ3JlYXQgbWVldGluZyB5b3UgYWxsIHRoaXMgd2VlayBhbmQgZXhwZXJpZW5jaW5n IG15IGZpcnN0IElFVEYuICBUaGFua3MgdG8gYWxsIGZvciB0aGF0IQ0KDQpUaGFua3MsDQpCcmlh bg0KDQoNCg0KSSBob3BlIHRoYXQgaGVscHM/DQoNClJpY2sNCg0KwqANCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG1hbmV0IFttYW5ldC1ib3VuY2VzQGll dGYub3JnXSBvbiBiZWhhbGYgb2YgUmljayBUYXlsb3IgW3JpY2tAdHJvcGljYWxzdG9ybXNvZnR3 YXJlLmNvbV0NClNlbnQ6IDI0IEp1bHkgMjAxNCAxNjo0Ng0KVG86IFNueWRlciwgQnJpYW47IG1h bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZv ciBETEVQDQpBcyBvbmUgb2YgdGhlIHBlb3BsZSBpbnZvbHZlZCBpbiB0aGUgZXh0ZW5zaXZlIGRp c2N1c3Npb25zIHdpdGggQnJpYW4gb3ZlciB0aGlzIHVzZSBjYXNlLCBhbmQgaXQgd2FzIEkgd2hv IHN1Z2dlc3RlZCB0aGUgRkY6RkY6RkY6RkY6RkY6RkYgc29sdXRpb24sIEkgdGhvdWdodCBJIG91 Z2h0IHRvIGp1c3RpZnkgbXlzZWxmLg0KDQpZZXMsIGl0J3MgYSBjbHVkZ2UuwqAgSW4gYW4gaWRl YWwgd29ybGQsIHRoZSBzcG9rZSBtb2RlbSBpbiBhIGh1YiBhbmQgc3Bva2UgdG9wb2xvZ3kgd291 bGQgYW5ub3VuY2UgaXQncyBsaW5rLXN0YXRlIHVzaW5nIHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUg aHViIGFzIHRoZSBkZXN0aW5hdGlvbiBpZGVudGlmaWVyIGluIHRoZSByZWxldmFudCBzaWduYWxz LsKgIEJ1dCwgYXMgQnJpYW4gcG9pbnRzIG91dCwgdGhlcmUgYXJlIGV4YW1wbGVzIG9mIGV4aXN0 aW5nIHRlY2hub2xvZ2llcyB3aGVyZSBhLXByaW9yaSBjb25maWd1cmF0aW9uIG9mIHRoZSBodWIg TUFDLCBvciByZXRyb2ZpdHRpbmcgdGhlIHBhc3Npbmcgb2YgdGhlIGh1YiBNQUMgaW4gdGhlIGxp bmstbGF5ZXIgc2lnbmFsIGlzIGluZmVhc2libGUuwqAgSW4gdGhlc2UgY2FzZXMsIHRoZXJlIG5l ZWRzIHRvIGJlIGEgd2F5IGZvciB0aGUgc3Bva2UgbW9kZW0gdG8gYW5ub3VuY2UgdGhlIGxpbmst c3RhdGUgb2YgdGhlIG9uZSBhbmQgb25seSBsaW5rIGl0IGhhcyBpbiBhIGdlbmVyaWMgd2F5LsKg IEdpdmVuIHRoZSBsYWNrIG9mIGtub3dsZWRnZSBvZiB0aGUgaHViIE1BQywgYW55IGF0dGFjaGVk IHJvdXRlciB3aWxsIG5lZWQgdG8gQVJQL05EIGZvciBpdCBhbnl3YXksIHVzaW5nIHRoZSBGRjpG RjpGRjpGRjpGRjpGRiBhZGRyZXNzLCBzbyB0aGVyZSBpcyBzb21lIGNvbnNpc3RlbmN5IHRoZXJl Lg0KDQpFdmVuIGlmIHRoZSBhbGwtRkZzIE1BQyBpcyBiZWluZyB1c2VkIGFzIGEgZGVzdGluYXRp b24sIHRoZXJlIGlzIG5vdGhpbmcgcHJldmVudGluZyB0aGUgc2FtZSBtb2RlbSBhbm5vdW5jaW5n IG90aGVyIE1BQyBkZXN0aW5hdGlvbnMsIHdpdGggYWx0ZXJuYXRlIGxpbmsgc3RhdGUgYXQgYSBh bm90aGVyIHRpbWUsIHNvIGl0IGRvZXNuJ3QgYnJlYWsgdGhlIGV4aXN0aW5nIERMRVAgbW9kZWws IGluIHRoZSBzYW1lIHdheSB0aGF0IGxheWVyLTMgaGFzIHRoZSBkZWZhdWx0IHJvdXRlIGNvbmNl cHQgKGJ1dCBvYnZpb3VzbHkgd2l0aCBNQUMncyB0aGVyZSBpcyBubyBjb25jZXB0IG9mIGxvbmdl c3QgcHJlZml4LCBldGMuLi4pDQoNCkkgdGhpbmsgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSB2ZXJi aWFnZSBzb21ld2hlcmUgdGhhdCBzdGF0ZXMgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiAi SWYgYSBtb2RlbSB3aWxsIG9ubHkgZXZlciBoYXZlIG9uZSBsaW5rLCBlLmcuIGEgc3Bva2UgaW4g YSBodWIgYW5kIHNwb2tlIHRvcG9sb2d5LCBhbmQgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBkZXN0 aW5hdGlvbiByb3V0ZXIgY2Fubm90IGJlIGRldGVybWluZWQgYnkgdGhlIGxvd2VyIGxheWVyIHNp Z25hbGxpbmcsIHRoZW4gdGhlIEZGOkZGOkZGOkZGOkZGOkZGIE1BQyBhZGRyZXNzIE1BWSBiZSB1 c2VkLCBidXQgdGhpcyBpcyBOT1QgUkVDT01NRU5ERUQiIChpLmUuIERvIGl0IHByb3Blcmx5IHVu bGVzcyB5b3UgKnJlYWxseSogY2FuJ3QpLg0KDQpAQnJpYW46IEkgdGhpbmsgeW91IG1pZ2h0IGJl IGFyZ3VpbmcgeW91cnNlbGYgaW50byB3cml0aW5nIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgZW50 aXRsZXMgIkRMRVAgdXNlLWNhc2VzIGZvciBTYXRjb20iLg0KDQpBbHNvLCBhcyBJIHRoaW5rIGFi b3V0IGl0LCB0aGlzIG1vZGVsIG1pZ2h0IHdvcmsgZm9yIHRoZSAzRyBhY2Nlc3MgcG9pbnQgdXNl LWNhc2UuwqAgVGhlcmUgaXMgYSBsaW5rIHRvIGEgc2luZ2xlIGRlc3RpbmF0aW9uLCBidXQsIGFz IHdpdGggU2F0Y29tLCB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGRlc3RpbmF0aW9uIHJvdXRlciBt YXkgbm90IGJlIGF2YWlsYWJsZS7CoCBBbHRob3VnaCwgb24gZnVydGhlciBjb25zaWRlcmF0aW9u IChJJ20gZGVmaW5pdGVseSB0aGlua2luZyBvbiBteSBmZWV0IGhlcmUpIEkgdGhpbmsgdGhlIHhH L0xURSB1c2UtY2FzZSBpcyBiZXR0ZXIgYWRkcmVzc2VkIGJ5IG15IGxheWVyLTMgZXh0ZW5zaW9u cywgYXMgYWNjZXNzLXBvaW50cyBkb24ndCBvcGVyYXRlIGFzIGxheWVyLTIgYnJpZGdlcywgYW5k IHRoZXJlIG1heSBub3QgZXZlbiBiZSBhIERMRVAgcm91dGVyIGF0IHRoZSBkZXN0aW5hdGlvbi4g DQoNCkFueXdheSwgYWxsIGZvb2QgZm9yIHRob3VnaHQgYW5kIGRpc2N1c3Npb24uLi4NCg0KUmlj aw0KDQo= From nobody Thu Jul 24 23:36:01 2014 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 E51711A0B0E for ; Thu, 24 Jul 2014 23:36:00 -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 e-CP5J6FsvRf for ; Thu, 24 Jul 2014 23:35:59 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6FA1A01D0 for ; Thu, 24 Jul 2014 23:35:59 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so4555156qgd.19 for ; Thu, 24 Jul 2014 23:35:58 -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=+qf/XY9OAuKWDxC4bmyYWaUO79jDn1o4NigYjLrQDek=; b=dSuBATczn7ZSfUSRAZqOGvnH+bNK0B4yhk6VVCKWuon5Tl4n75kgKipciyc1iJpTEh 9hSQ6qUtrfqBJml6msqbd5Z4UkgPWiEC6Fm6XOEyHbACvH+dQCmNEB7XJN6Dx71Ge5Rw t5orpTdej+RIISUWrk8+3b5MSoa3si2msgpNZ5JjyMn6+yIRUsfQp4vQ8vh9eN9yVZlD Ry+Qj87rwtjGxcTdGMWFrPFrKAcu1ZEdkkv9ZoUfE5U66Ie9Cq/XzRtQBuIUHTpJJw7W FOccaWvmIpEh13+Sfdoc2FkzOuloZ1A9SNo4I8EmCFJqID8ha+IvkNcaGBrN2cBxxqMo n7og== X-Received: by 10.140.88.243 with SMTP id t106mr9614015qgd.12.1406270158744; Thu, 24 Jul 2014 23:35:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Thu, 24 Jul 2014 23:35:38 -0700 (PDT) In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> From: Henning Rogge Date: Fri, 25 Jul 2014 08:35:38 +0200 Message-ID: To: "Snyder, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/De0wU489EP0cC1DVmU3EUfs7_rY Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 06:36:01 -0000 On Fri, Jul 25, 2014 at 12:51 AM, Snyder, Brian wrote= : > [BSS] =E2=80=93 And I guess I am looking for something different. I=E2= =80=99m looking for link state notifications (with metrics) to - and this = is a different #2 =E2=80=93 allow a routing protocol to be tuned for minimu= m KEEP ALIVE timers to minimize bandwidth usage to conserve very expensive = and limited bandwidth. In a satellite network, there is no need for fast-s= tarts, L1 convergence can (and in a suitably sized network will take second= s). However, because modems tend to stay in network quite stably (trees an= d buildings don=E2=80=99t get the way often in the ocean=E2=98=BA), the bui= lding of adjacencies does not happen all that often. It=E2=80=99s way more = important to me to conserve bandwidth and be transparent. I must admit I still fail to see why a special case is even necessary. We are talking about a network with hundred thousands clients connected via satellite to a Hub station. Yes, so we need to make sure that the clients don't talk more than necessary. But you said your client satellite modems are able to receive broadcast traffic... and maybe even unicasts delivered to a different client. This means pushing information from the Hub to all clients is reasonable cheap. This means transferring the Mac address to a client is dirt cheap, especially if Layer-2 at the Hub is able to tell that a new client connected to the satellite. What is the typical uptime of a client? And what percentage of traffic goes from the Hub to the clients? A rough guess would be great to better understand your problem. Henning Rogge From nobody Fri Jul 25 04:31:20 2014 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 D9B561B27B6 for ; Fri, 25 Jul 2014 04:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.016 X-Spam-Level: X-Spam-Status: No, score=-13.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 7ZIisL4Mlk_4 for ; Fri, 25 Jul 2014 04:31:17 -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 3D22B1A01A9 for ; Fri, 25 Jul 2014 04:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=887; q=dns/txt; s=iport; t=1406287878; x=1407497478; h=date:from:to:cc:subject:message-id:mime-version; bh=wVeRnHONn/SVmxJsW2z9pIRpfWqlTamxHkvX4wr/Cn4=; b=lcvP28ZeYxibNBQjX9yrUHIaM3RnfR2d8FgH0uT+LVi1fCPw+nfMgR6d KjopFBz5RQ6bzCfWUTjnbE8XmSKUUcs8hF864KDmF97MNKhOR4xiKPHFG LKVU0VZOl8YH0GXK/DbuokrgH6TXqJQj/hqnwWr4VoXXuGCgbyM4pXMsp w=; X-IronPort-AV: E=Sophos;i="5.01,730,1400025600"; d="scan'208";a="63965930" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 25 Jul 2014 11:31:17 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6PBVGcn016480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 11:31:16 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6PBVA9h024064; Fri, 25 Jul 2014 04:31:10 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6PBV9e4024063; Fri, 25 Jul 2014 04:31:09 -0700 Date: Fri, 25 Jul 2014 04:31:09 -0700 From: Toerless Eckert To: "Snyder, Brian" Message-ID: <20140725113109.GA7355@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wgvqcghXTlcWU-9X6VPjeKs-LXk Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - how to arp 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, 25 Jul 2014 11:31:19 -0000 This thread is getting long and discusses a lot of aspects. Maybe split it up to conclude on different aspects. I am confused about what options are required to send IP unicast packets: 1) Non-Broadcast-Multi-Access radio network. Sending of ethernet multicast/broadcast not supported. Therefore ARP does not work. Therefore DLEP must announce MAC and IP address of destinations. 2) Broadcast multi-access nework, eg: Satellite. Sending of ethernet multicast/broadcast supported, ARP works, DLEP does not need to carry destination IP-addresses, DLEP not required to supplant ARP. 3) Something else: radio network expects routers to insert any DMAC other than the natural destination MAC address of a destination into unicast IP packets. Like some default MAC address. Some mails sounded as if there was an ask for 3). I hope there is not. Thanks Toerless From nobody Fri Jul 25 04:40:11 2014 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 55D2E1B27ED for ; Fri, 25 Jul 2014 04:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.016 X-Spam-Level: X-Spam-Status: No, score=-13.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 X3qoKdY4j1XO for ; Fri, 25 Jul 2014 04:40:07 -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 B1B831B27B5 for ; Fri, 25 Jul 2014 04:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1345; q=dns/txt; s=iport; t=1406288407; x=1407498007; h=date:from:to:cc:subject:message-id:mime-version; bh=diwJHhczttdhzZXKcoY9AvDFnivIIPQZceXJ61c9+Iw=; b=mQS5HJ7bilG3i2hxvRoXSb6V01Y9miuBeDGyvPG646yJaCbSkhRKw/2r jW0P4M4Dxxi7HZIh8L0gIWpxhnLull8JLUc2CRUz9u7xK3YpQkTV3fAH9 4k/5pim47FC83Jgllc3zA5mumSd0rDbHb1F49arOyC1nQxxqdejVH0Ibq U=; X-IronPort-AV: E=Sophos;i="5.01,730,1400025600"; d="scan'208";a="342800650" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2014 11:40:07 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6PBe6Zv005613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 11:40:07 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6PBe1LO025370; Fri, 25 Jul 2014 04:40:01 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6PBe0x0025368; Fri, 25 Jul 2014 04:40:00 -0700 Date: Fri, 25 Jul 2014 04:40:00 -0700 From: Toerless Eckert To: "Snyder, Brian" Message-ID: <20140725114000.GB7355@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8SPPMGhvoFYVO1x13dKCLkFJbEw Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - default destination 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, 25 Jul 2014 11:40:09 -0000 Point 2: I am assuming the Satellite network is supporting ethetnet multicast/broadcast. If the DLEP modems of spokes do not indicate all other spokes as destinations with their MAC and IP addresses, then the spoke routers need to just do normal ARP. Now hub and spoe routers run some IGP. And the IGP has some hellos. And hellos from 2000 spokes are a relevant upstream bandwidth cost. Would actually be nice to have an actual example calculation what percentage of upstream bandwidth cost we are talking about. So, DLEP to the rescue. But without DLEP having to indicate all hub & spokes as destinations with MAC and IP. So... what is the logic: Hub and spokes send hellos very infrequently an use DLEP as an indication for the neighbors to be still alive. For the spokes we introduce one new magic DLEP destination to indicate "all neighbors are alive" because it simplifies the life of the RF network operator that ould otherwise have to do more provisioning such as eg: hub router MAC address provisioning into spoke modems. Or incurring a longer startup time to dynamically signal this to spoke modems via RF magic. And the question is now just how to encode that magic destination in DLEP. MAC broadcast may not be ideal, but maybe some othrer magic DMAC. All 0 ?. Is this correctly summarizing the ask ? From nobody Fri Jul 25 05:53:46 2014 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 3EF451B282A for ; Fri, 25 Jul 2014 05:53: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 6iGZsQR1bqfq for ; Fri, 25 Jul 2014 05:53:43 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB3C1B2825 for ; Fri, 25 Jul 2014 05:53:43 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so4481017qap.9 for ; Fri, 25 Jul 2014 05:53: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; bh=HYQa/WN5OfBPbJEfMq62mmD3BFZHKC/egILUsLjPso8=; b=MiXfSkjdFaQoLdOrju7rYbmHz5P7TrvIyCc1df01vE9K3k/qZYhRzypTBO/VsPzfBW Hq3nIJ7UQH5othlnmvJ/r1C4VdlngtC47z6PWAMRbziW6YrGMd57M+V8jM8pLrPMQ+XY a+lTLUNMjTxqE/8UTueT8yjFd7BAsVqUkH0zfTOdMmzsGHlphL6grWc74fk0pLKnjcn5 m9o/4ARBP4EQSE5fJiNBkfHaRxxN8vv9ZMHf5i0unNpdAjdRDDEFd7RyAaFfsAAtH9vE VLUG+GlyiNkVLymFio7rEtN4J51kRx37/30rj2az2Q5H8bYLBS6zMJt/V2ZFaRxd4mqY isbg== X-Received: by 10.140.97.117 with SMTP id l108mr25386594qge.29.1406292822391; Fri, 25 Jul 2014 05:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Fri, 25 Jul 2014 05:53:22 -0700 (PDT) In-Reply-To: <20140725114000.GB7355@cisco.com> References: <20140725114000.GB7355@cisco.com> From: Henning Rogge Date: Fri, 25 Jul 2014 14:53:22 +0200 Message-ID: To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vUh60obxtKQRSkdfqmvq7SOzLaQ Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - default destination 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, 25 Jul 2014 12:53:44 -0000 On Fri, Jul 25, 2014 at 1:40 PM, Toerless Eckert wrote: > And the question is now just how to encode that magic destination in > DLEP. MAC broadcast may not be ideal, but maybe some othrer > magic DMAC. All 0 ?. If the Hub end of the satellite link is connected to a switch (a few routers), how does this magic ethernet thing work? Or is the "destination Mac" completely optimized away and "regenerated" at the Hub? Henning Rogge From nobody Fri Jul 25 06:36:51 2014 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 526BA1A02DD for ; Fri, 25 Jul 2014 06:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 BFd6aYEe_zV3 for ; Fri, 25 Jul 2014 06:36:47 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 B08E31A0243 for ; Fri, 25 Jul 2014 06:36:46 -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, 25 Jul 2014 14:36:22 +0100 From: Rick Taylor To: Henning Rogge , "Snyder, Brian" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: AQHPp9bVBz332mowOEGhx2cRjj5qopuwxipW Date: Fri, 25 Jul 2014 13:36:21 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB2C9@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UfLgFb-ixuuWbnY4_x7VcTtVcjE Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 13:36:48 -0000 SSdtIHRyeWluZyB0byBzdGF5IHJlbGF0aXZlbHkgcXVpZXQgb24gdGhpcyB0b3BpYyBub3csIGJl Y2F1c2UgSSdtIGhvcGluZyBzb21lIG9mIHRoZSBETEVQIGd1cnUncyB3aWxsIGNoaXAgaW4gd2l0 aCB0aGVpciBhZHZpY2UgKHRoYW5rcyBIZW5uaW5nKS4KCkJ1dCwgRExFUCBnaXZlcyB5b3UgbGlu ayBzdGF0ZS9zZW5zaW5nLCBzbyB5b3UgY2FuIHR1cm4gZG93bi9vZmYgdGhlIElHUCBoZWFydGJl YXRzIGFzIHRoZSBETEVQIG1vZGVtIHdpbGwgdGVsbCB5b3UgdGhlIHN0YXRlIG9mIHRoZSBsaW5r IGl0IGhhcyBsZWFybnQgZnJvbSB0aGUgdW5kZXJseWluZyBSRi4gIAoKQ2hlZXJzLApSaWNrICAK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBIZW5uaW5nIFJv Z2dlIFtocm9nZ2VAZ21haWwuY29tXQpTZW50OiAyNSBKdWx5IDIwMTQgMDc6MzUKVG86IFNueWRl ciwgQnJpYW4KQ2M6IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW21h bmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQCgpPbiBGcmksIEp1bCAyNSwgMjAxNCBh dCAxMjo1MSBBTSwgU255ZGVyLCBCcmlhbiA8YnNueWRlckBpZGlyZWN0Lm5ldD4gd3JvdGU6Cj4g W0JTU10g4oCTIEFuZCBJIGd1ZXNzIEkgYW0gbG9va2luZyBmb3Igc29tZXRoaW5nIGRpZmZlcmVu dC4gIEnigJltIGxvb2tpbmcgZm9yIGxpbmsgc3RhdGUgbm90aWZpY2F0aW9ucyAod2l0aCBtZXRy aWNzKSB0byAgLSBhbmQgdGhpcyBpcyBhIGRpZmZlcmVudCAjMiDigJMgYWxsb3cgYSByb3V0aW5n IHByb3RvY29sIHRvIGJlIHR1bmVkIGZvciBtaW5pbXVtIEtFRVAgQUxJVkUgdGltZXJzIHRvIG1p bmltaXplIGJhbmR3aWR0aCB1c2FnZSB0byBjb25zZXJ2ZSB2ZXJ5IGV4cGVuc2l2ZSBhbmQgbGlt aXRlZCBiYW5kd2lkdGguICBJbiBhIHNhdGVsbGl0ZSBuZXR3b3JrLCB0aGVyZSBpcyBubyBuZWVk IGZvciBmYXN0LXN0YXJ0cywgTDEgY29udmVyZ2VuY2UgY2FuIChhbmQgaW4gYSBzdWl0YWJseSBz aXplZCBuZXR3b3JrIHdpbGwgdGFrZSBzZWNvbmRzKS4gIEhvd2V2ZXIsIGJlY2F1c2UgbW9kZW1z IHRlbmQgdG8gc3RheSBpbiBuZXR3b3JrIHF1aXRlIHN0YWJseSAodHJlZXMgYW5kIGJ1aWxkaW5n cyBkb27igJl0IGdldCB0aGUgd2F5IG9mdGVuIGluIHRoZSBvY2VhbuKYuiksIHRoZSBidWlsZGlu ZyBvZiBhZGphY2VuY2llcyBkb2VzIG5vdCBoYXBwZW4gYWxsIHRoYXQgb2Z0ZW4uIEl04oCZcyB3 YXkgbW9yZSBpbXBvcnRhbnQgdG8gbWUgdG8gY29uc2VydmUgYmFuZHdpZHRoIGFuZCBiZSB0cmFu c3BhcmVudC4KCkkgbXVzdCBhZG1pdCBJIHN0aWxsIGZhaWwgdG8gc2VlIHdoeSBhIHNwZWNpYWwg Y2FzZSBpcyBldmVuIG5lY2Vzc2FyeS4KCldlIGFyZSB0YWxraW5nIGFib3V0IGEgbmV0d29yayB3 aXRoIGh1bmRyZWQgdGhvdXNhbmRzIGNsaWVudHMKY29ubmVjdGVkIHZpYSBzYXRlbGxpdGUgdG8g YSBIdWIgc3RhdGlvbi4gWWVzLCBzbyB3ZSBuZWVkIHRvIG1ha2Ugc3VyZQp0aGF0IHRoZSBjbGll bnRzIGRvbid0IHRhbGsgbW9yZSB0aGFuIG5lY2Vzc2FyeS4KCkJ1dCB5b3Ugc2FpZCB5b3VyIGNs aWVudCBzYXRlbGxpdGUgbW9kZW1zIGFyZSBhYmxlIHRvIHJlY2VpdmUKYnJvYWRjYXN0IHRyYWZm aWMuLi4gYW5kIG1heWJlIGV2ZW4gdW5pY2FzdHMgZGVsaXZlcmVkIHRvIGEgZGlmZmVyZW50CmNs aWVudC4gVGhpcyBtZWFucyBwdXNoaW5nIGluZm9ybWF0aW9uIGZyb20gdGhlIEh1YiB0byBhbGwg Y2xpZW50cyBpcwpyZWFzb25hYmxlIGNoZWFwLgoKVGhpcyBtZWFucyB0cmFuc2ZlcnJpbmcgdGhl IE1hYyBhZGRyZXNzIHRvIGEgY2xpZW50IGlzIGRpcnQgY2hlYXAsCmVzcGVjaWFsbHkgaWYgTGF5 ZXItMiBhdCB0aGUgSHViIGlzIGFibGUgdG8gdGVsbCB0aGF0IGEgbmV3IGNsaWVudApjb25uZWN0 ZWQgdG8gdGhlIHNhdGVsbGl0ZS4KCgpXaGF0IGlzIHRoZSB0eXBpY2FsIHVwdGltZSBvZiBhIGNs aWVudD8gQW5kIHdoYXQgcGVyY2VudGFnZSBvZiB0cmFmZmljCmdvZXMgZnJvbSB0aGUgSHViIHRv IHRoZSBjbGllbnRzPyBBIHJvdWdoIGd1ZXNzIHdvdWxkIGJlIGdyZWF0IHRvCmJldHRlciB1bmRl cnN0YW5kIHlvdXIgcHJvYmxlbS4KCkhlbm5pbmcgUm9nZ2UK From nobody Fri Jul 25 06:37:40 2014 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 2A6371B27FA for ; Fri, 25 Jul 2014 06:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 NQWY94zAU_9c for ; Fri, 25 Jul 2014 06:37:25 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id B84761B2844 for ; Fri, 25 Jul 2014 06:37:24 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,731,1400040000"; d="scan'208";a="11421666" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 25 Jul 2014 09:37:10 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Fri, 25 Jul 2014 09:37:10 -0400 From: "Snyder, Brian" To: Henning Rogge Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0AAaqRUAAAX832A= Date: Fri, 25 Jul 2014 13:37:09 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CQPIRm57bYOHHqiJ2EcrR-ct1f4 Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 13:37:31 -0000 RW1iZWRkZWQuLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIZW5uaW5n IFJvZ2dlIFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMjUs IDIwMTQgMjozNiBBTQ0KVG86IFNueWRlciwgQnJpYW4NCkNjOiBSaWNrIFRheWxvcjsgbWFuZXRA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERM RVANCg0KT24gRnJpLCBKdWwgMjUsIDIwMTQgYXQgMTI6NTEgQU0sIFNueWRlciwgQnJpYW4gPGJz bnlkZXJAaWRpcmVjdC5uZXQ+IHdyb3RlOg0KPiBbQlNTXSDigJMgQW5kIEkgZ3Vlc3MgSSBhbSBs b29raW5nIGZvciBzb21ldGhpbmcgZGlmZmVyZW50LiAgSeKAmW0gbG9va2luZyBmb3IgbGluayBz dGF0ZSBub3RpZmljYXRpb25zICh3aXRoIG1ldHJpY3MpIHRvICAtIGFuZCB0aGlzIGlzIGEgZGlm ZmVyZW50ICMyIOKAkyBhbGxvdyBhIHJvdXRpbmcgcHJvdG9jb2wgdG8gYmUgdHVuZWQgZm9yIG1p bmltdW0gS0VFUCBBTElWRSB0aW1lcnMgdG8gbWluaW1pemUgYmFuZHdpZHRoIHVzYWdlIHRvIGNv bnNlcnZlIHZlcnkgZXhwZW5zaXZlIGFuZCBsaW1pdGVkIGJhbmR3aWR0aC4gIEluIGEgc2F0ZWxs aXRlIG5ldHdvcmssIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGZhc3Qtc3RhcnRzLCBMMSBjb252ZXJn ZW5jZSBjYW4gKGFuZCBpbiBhIHN1aXRhYmx5IHNpemVkIG5ldHdvcmsgd2lsbCB0YWtlIHNlY29u ZHMpLiAgSG93ZXZlciwgYmVjYXVzZSBtb2RlbXMgdGVuZCB0byBzdGF5IGluIG5ldHdvcmsgcXVp dGUgc3RhYmx5ICh0cmVlcyBhbmQgYnVpbGRpbmdzIGRvbuKAmXQgZ2V0IHRoZSB3YXkgb2Z0ZW4g aW4gdGhlIG9jZWFu4pi6KSwgdGhlIGJ1aWxkaW5nIG9mIGFkamFjZW5jaWVzIGRvZXMgbm90IGhh cHBlbiBhbGwgdGhhdCBvZnRlbi4gSXTigJlzIHdheSBtb3JlIGltcG9ydGFudCB0byBtZSB0byBj b25zZXJ2ZSBiYW5kd2lkdGggYW5kIGJlIHRyYW5zcGFyZW50Lg0KDQpJIG11c3QgYWRtaXQgSSBz dGlsbCBmYWlsIHRvIHNlZSB3aHkgYSBzcGVjaWFsIGNhc2UgaXMgZXZlbiBuZWNlc3NhcnkuDQoN CltCU1NdIC0gUGVyaGFwcyBub3QgbmVjZXNzYXJ5IC0gYnV0IEknbSB2ZXJ5IGNvbmNlcm5lZCB3 aXRoIHRyeWluZyB0byBvcHRpbWl6ZSBmb3Igc2NhbGUgYW5kIHRyYW5zcGFyZW5jeS4NCg0KV2Ug YXJlIHRhbGtpbmcgYWJvdXQgYSBuZXR3b3JrIHdpdGggaHVuZHJlZCB0aG91c2FuZHMgY2xpZW50 cyBjb25uZWN0ZWQgdmlhIHNhdGVsbGl0ZSB0byBhIEh1YiBzdGF0aW9uLiBZZXMsIHNvIHdlIG5l ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudHMgZG9uJ3QgdGFsayBtb3JlIHRoYW4gbmVj ZXNzYXJ5Lg0KDQpCdXQgeW91IHNhaWQgeW91ciBjbGllbnQgc2F0ZWxsaXRlIG1vZGVtcyBhcmUg YWJsZSB0byByZWNlaXZlIGJyb2FkY2FzdCB0cmFmZmljLi4uIGFuZCBtYXliZSBldmVuIHVuaWNh c3RzIGRlbGl2ZXJlZCB0byBhIGRpZmZlcmVudCBjbGllbnQuIFRoaXMgbWVhbnMgcHVzaGluZyBp bmZvcm1hdGlvbiBmcm9tIHRoZSBIdWIgdG8gYWxsIGNsaWVudHMgaXMgcmVhc29uYWJsZSBjaGVh cC4NCltCU1NdIC0gVGhleSB3b24ndCByZWNlaXZlIHVuaWNhc3QgZm9yIHNvbWVvbmUgZWxzZS4g IEhETEMgYWRkcmVzc2luZyBkZW11eGVzIHRoYXQuICBQdXNoaW5nIGJyb2FkY2FzdCBpcyBjaGVh cC4gIElFOiBBUlBzIGNhbiBmbG93IGZyZWVseSBhbmQgY2hlYXBseSBvbiB0aGUgZG93bnN0cmVh bS4NCg0KVGhpcyBtZWFucyB0cmFuc2ZlcnJpbmcgdGhlIE1hYyBhZGRyZXNzIHRvIGEgY2xpZW50 IGlzIGRpcnQgY2hlYXAsIGVzcGVjaWFsbHkgaWYgTGF5ZXItMiBhdCB0aGUgSHViIGlzIGFibGUg dG8gdGVsbCB0aGF0IGEgbmV3IGNsaWVudCBjb25uZWN0ZWQgdG8gdGhlIHNhdGVsbGl0ZS4NCltC U1NdIC0gSW4gdGhpcyBjYXNlIHRyYW5zZmVycmluZyBhIG1hYyBhZGRyZXNzIGlzIGNoZWFwIC0g dGhlIGFycCdzIGRvIGl0IHRocm91Z2ggdXMgLS0gdGhvdWdoIHRoZSBtb2RlbXMgY3VycmVudGx5 IGRvbid0IHRyYWNrIGFuZCByZWNvcmQgYW55IG9mIHRoZSBsZWFybnQgYWRkcmVzcyBPVEEuLi4g d2UganVzdCBsZXQgdGhlIGN1c3RvbWVyIGRldmljZXMgZG8gd2hhdCB0aGV5IHNob3VsZCBkbyBi eSBhbGwgbm9ybWFsIGNvbnZlbnRpb25zLiAoQVJQLCB0aW1lcnMsIGV0YykuICBNb2RlbXMgaGF2 ZSBubyBub3Rpb24gb2Ygd2VhdGhlciBvciBub3QgYW5vdGhlciBtb2RlbSBpcyBpbiBvciBvdXQg b2YgbmV0d29yay4gIE5vIHN0YXIgc3lzdGVtIHdvdWxkLiBUaGV5IGp1c3QgdHJhY2sgdGhlbXNl bHZlcy4gU28gaWYgTUFDIGFkZHJlc3NlcyBhcmUgc3VwcG9zZWQgdG8gYmUgc3RvcmVkIGFuZCBt YW5hZ2VkIGJ5IHRoZSBtb2RlbSBmb3IgRExFUCBtYW5hZ2VtZW50IGF1dG9tYXRpY2FsbHksIHdl IGEpIGFyZW4ndCB0cmFuc3BhcmVudCBhbnltb3JlIGIpIEhhdmUgYSBzY2FsZSBwcm9ibGVtIG1h bmFnaW5nIGFsbCB0aG9zZSBtYWNzIGMpIElmIHRoZXJlIGFyZSBtb3JlIG1hYyBhZGRyZXNzZXMg KG5vdCByb3V0ZXJzIHdlIHdvdWxkIGNhcmUgYWJvdXQgdmlhIGRsZXApIGhvdyBpcyBhIHRyYW5z cGFyZW50IHN3aXRjaCBzdXBwb3NlZCB0byAiS05PVyIgd2hpY2ggbWFjIGFkZHJlc3MgaXMgdGhl IHNwZWNpYWwgb25lIHRoYXQgc2hvdWxkIGJlICdzZXR1cCcgYXMgdGhlIGRsZXAgdGFyZ2V0LiAg SSB0aGluayB0aGF0IHdvdWxkIHJlcXVpcmUgc29tZSBzcGVjaWFsIGNvbmZpZyB0aGF0IHRoZW4g aGFzIHRvIGJlIG1hbmFnZWQgKGFsc28gYnJlYWtpbmcgdHJhbnNwYXJlbmN5KSBhbmQgY3JlYXRp bmcgT0FNIGFuZCBjaGFuZ2UgbWFuYWdlbWVudCBpc3N1ZXMuIFJlbWVtYmVyIHRoZSBMQU4gaXMg bm90ICdvdXInIGVxdWlwbWVudCwgc28gYWxsIHRoZSBzdWRkZW4gb25lIHdvdWxkIGhhdmUgdG8g Z2V0IGFuZCBtYW5hZ2UgbWFjIGFkZHJlc3NlcyBmb3IgYWxsIHRoZXNlIHNpdGVzLiAgV2UgYXJl IGdvaW5nIEwyIGluLW9yZGVyIHRvIGhlbHAgdXMgYW5kIG91ciBjbGllbnRzIG5vdCB3b3JyeSBh Ym91dCBlYWNoIG90aGVyJ3MgZXF1aXBtZW50IGFuZCBuZXR3b3JraW5nLg0KDQoNCldoYXQgaXMg dGhlIHR5cGljYWwgdXB0aW1lIG9mIGEgY2xpZW50PyBBbmQgd2hhdCBwZXJjZW50YWdlIG9mIHRy YWZmaWMgZ29lcyBmcm9tIHRoZSBIdWIgdG8gdGhlIGNsaWVudHM/IEEgcm91Z2ggZ3Vlc3Mgd291 bGQgYmUgZ3JlYXQgdG8gYmV0dGVyIHVuZGVyc3RhbmQgeW91ciBwcm9ibGVtLg0KW0JTU10gLSBU eXBpY2FsIHVwdGltZSB3b3VsZCBiZSBtZWFzdXJlZCBpbiBmcm9tIGhvdXJzIChNYXliZSBhIHBs YW5lIG1vdmluZyBhY3Jvc3Mgc2F0ZWxsaXRlIGZvb3RwcmludHMpIHRvIGhvcGVmdWxseSB5ZWFy cyAtIGEgc3RhdGlvbmFyeSBtb2RlbS4gIFRob3VnaCBwcmFjdGljYWxseSB0aGF04oCZcyBtYXli ZSBtb3JlIG5vcm1hbGx5IG1vbnRocyBkdWUgdG8gd2VhdGhlciwgdXBncmFkZXMsIGV0Yy4NCg0K SGVubmluZyBSb2dnZQ0K From nobody Fri Jul 25 06:46:37 2014 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 C35301A02FC for ; Fri, 25 Jul 2014 06:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 GulWh5OF4JjQ for ; Fri, 25 Jul 2014 06:46:28 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 5B60F1A02E3 for ; Fri, 25 Jul 2014 06:46:28 -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, 25 Jul 2014 14:46:04 +0100 From: Rick Taylor To: Toerless Eckert , "Snyder, Brian" Thread-Topic: [manet] DLEP/satellite - how to arp Thread-Index: AQHPp/vuEJ4azJo3kkqAZGcxnSi0KJuwyx61 Date: Fri, 25 Jul 2014 13:46:03 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB2E3@tss-server1.home.tropicalstormsoftware.com> References: <20140725113109.GA7355@cisco.com> In-Reply-To: <20140725113109.GA7355@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/MkLudWyIBSJV088iA9G9WKvyYR0 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - how to arp 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, 25 Jul 2014 13:46:30 -0000 Comments in line=0A= =0A= >This thread is getting long and discusses a lot of aspects. Maybe split=0A= it up to conclude on different aspects.=0A= =0A= Good plan=0A= =0A= >I am confused about what options are required to send IP unicast=0A= packets:=0A= =0A= The number of use-cases is starting to grow to greater number than the core= DLEP originally tried to address.=0A= =0A= > 1) Non-Broadcast-Multi-Access radio network. Sending of ethernet=0A= multicast/broadcast not supported. Therefore ARP does not work. Therefore= =0A= DLEP must announce MAC and IP address of destinations.=0A= =0A= This (I believe) is beyond the scope of core DLEP. I have kit like this, h= ence my proposed extension, but I would be very happy to merge my work into= the core spec.=0A= =0A= > 2) Broadcast multi-access nework, eg: Satellite. Sending of ethernet=0A= multicast/broadcast supported, ARP works, DLEP does not need to carry=0A= destination IP-addresses, DLEP not required to supplant ARP.=0A= =0A= This is the mode DLEP was developed to address, and expects the modems to o= perate in.=0A= =0A= > 3) Something else: radio network expects routers to insert any DMAC=0A= other than the natural destination MAC address of a destination into=0A= unicast IP packets. Like some default MAC address.=0A= =0A= This I believe is what Brian thinks he needs, not at the packet level, but = as a DLEP identifier (which re-uses the MAC). But my (new) opinion is that= 'wildcard' destinations might create more problems than they solve. I don'= t think what Brian is asking for is unreasonable, in giant hub-spoke networ= ks there has to be a way to manage the load on the spoke DLEP modem agent, = I'm just not sure we have the recommended solution for him yet. =0A= =0A= Cheers,=0A= =0A= Rick= From nobody Fri Jul 25 06:53:19 2014 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 C91EB1B2871 for ; Fri, 25 Jul 2014 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 ZxVIc5A9pSpd for ; Fri, 25 Jul 2014 06:53:16 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 695561B2864 for ; Fri, 25 Jul 2014 06:53:16 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,731,1400040000"; d="scan'208";a="11422295" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 25 Jul 2014 09:53:15 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Fri, 25 Jul 2014 09:53:15 -0400 From: "Snyder, Brian" To: Rick Taylor , Toerless Eckert Thread-Topic: [manet] DLEP/satellite - how to arp Thread-Index: AQHPp/vzIvh4+vqdiEe8vOokSGyS+puxEKOA//++t4A= Date: Fri, 25 Jul 2014 13:53:14 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF734304684F@VAUS-MBX03.idirect.net> References: <20140725113109.GA7355@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB2E3@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB2E3@tss-server1.home.tropicalstormsoftware.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: http://mailarchive.ietf.org/arch/msg/manet/epYFRbAkjCjasT3U_Q2QfsjieZc Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - how to arp 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, 25 Jul 2014 13:53:18 -0000 I would say I'm more in line with requesting #2. ie: DLEP not required to = supplant ARP. brian -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=20 Sent: Friday, July 25, 2014 9:46 AM To: Toerless Eckert; Snyder, Brian Cc: manet@ietf.org; Stan Ratliff (sratliff) Subject: RE: [manet] DLEP/satellite - how to arp Comments in line >This thread is getting long and discusses a lot of aspects. Maybe split it up to conclude on different aspects. Good plan >I am confused about what options are required to send IP unicast packets: The number of use-cases is starting to grow to greater number than the core= DLEP originally tried to address. > 1) Non-Broadcast-Multi-Access radio network. Sending of ethernet multicast/broadcast not supported. Therefore ARP does not work. Therefore D= LEP must announce MAC and IP address of destinations. This (I believe) is beyond the scope of core DLEP. I have kit like this, h= ence my proposed extension, but I would be very happy to merge my work into= the core spec. > 2) Broadcast multi-access nework, eg: Satellite. Sending of ethernet multicast/broadcast supported, ARP works, DLEP does not need to carry desti= nation IP-addresses, DLEP not required to supplant ARP. This is the mode DLEP was developed to address, and expects the modems to o= perate in. > 3) Something else: radio network expects routers to insert any DMAC other than the natural destination MAC address of a destination into unicas= t IP packets. Like some default MAC address. This I believe is what Brian thinks he needs, not at the packet level, but = as a DLEP identifier (which re-uses the MAC). But my (new) opinion is that= 'wildcard' destinations might create more problems than they solve. I don'= t think what Brian is asking for is unreasonable, in giant hub-spoke networ= ks there has to be a way to manage the load on the spoke DLEP modem agent, = I'm just not sure we have the recommended solution for him yet.=20 Cheers, Rick From nobody Fri Jul 25 07:05:12 2014 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 4F61D1B292E for ; Fri, 25 Jul 2014 07:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 MQlhELgyUIYP for ; Fri, 25 Jul 2014 07:05:06 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2D1B295C for ; Fri, 25 Jul 2014 07:04:09 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,731,1400040000"; d="scan'208";a="2599039" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 25 Jul 2014 10:04:08 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Fri, 25 Jul 2014 10:04:08 -0400 From: "Snyder, Brian" To: Toerless Eckert Thread-Topic: [manet] DLEP/satellite - default destination Thread-Index: AQHPp/0vh9b7bJj4vEqYXS8XW5vOFJuw0YaA Date: Fri, 25 Jul 2014 14:04:08 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343046909@VAUS-MBX03.idirect.net> References: <20140725114000.GB7355@cisco.com> In-Reply-To: <20140725114000.GB7355@cisco.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: http://mailarchive.ietf.org/arch/msg/manet/OeaJ4kXAhEVM0Mm0dZGnT-FKdH4 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - default destination 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, 25 Jul 2014 14:05:08 -0000 I would expect (ideally) the hello timers on the inroute are rather high an= d the therefore the hello timer from the one upstream router (that is adver= tising on the outroute) to be fairly low. So mostly all sessions will get = establshied based on seeing the every couple seconds hello from the outrout= e. Convergence will then kick off - but that has to happen anyway so there= is no 'extra cost' or way to minimize that (and should be fairly infrequen= t anyway). So yes I think you summarized my main ask - have some way (spec= ial mac or tlv) to signify to a router that this dlep session is a 'default= route' and just go ahead and act normally.... arp for a configured unicast= router or send -or- receive a multicast hello via an IGP. brian -----Original Message----- From: Toerless Eckert [mailto:eckert@cisco.com]=20 Sent: Friday, July 25, 2014 7:40 AM To: Snyder, Brian Cc: manet@ietf.org; Stan Ratliff (sratliff) Subject: Re: [manet] DLEP/satellite - default destination Point 2: I am assuming the Satellite network is supporting ethetnet multica= st/broadcast. If the DLEP modems of spokes do not indicate all other spokes= as destinations with their MAC and IP addresses, then the spoke routers ne= ed to just do normal ARP. Now hub and spoe routers run some IGP. And the IGP has some hellos. And hellos from 2000 spokes are a relevant upstream bandwidth cost. Would actually be nice to have an actual example calculation what percentag= e of upstream bandwidth cost we are talking about. So, DLEP to the rescue. But without DLEP having to indicate all hub & spoke= s as destinations with MAC and IP. So... what is the logic: Hub and spokes send hellos very infrequently an use DLEP as an indication f= or the neighbors to be still alive. For the spokes we introduce one new mag= ic DLEP destination to indicate "all neighbors are alive" because it simpli= fies the life of the RF network operator that ould otherwise have to do mor= e provisioning such as eg: hub router MAC address provisioning into spoke m= odems. Or incurring a longer startup time to dynamically signal this to spo= ke modems via RF magic. And the question is now just how to encode that magic destination in DLEP. = MAC broadcast may not be ideal, but maybe some othrer magic DMAC. All 0 ?. Is this correctly summarizing the ask ?=20 From nobody Fri Jul 25 07:07:47 2014 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 E47701B293E for ; Fri, 25 Jul 2014 07:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 AGttwfOlVJzD for ; Fri, 25 Jul 2014 07:07:40 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 163AA1B2986 for ; Fri, 25 Jul 2014 07:05:42 -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, 25 Jul 2014 15:05:07 +0100 From: Rick Taylor To: "Snyder, Brian" , Henning Rogge Thread-Topic: [manet] Request to consider for DLEP Thread-Index: AQHPp9bVBz332mowOEGhx2cRjj5qopuwup+AgAAU4JQ= Date: Fri, 25 Jul 2014 14:05:06 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xJht7mtxTniLQAMzsgHgaPFNM1E Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 14:07:45 -0000 VG9wLXBvc3RlZC4uLgoKU29ycnkgQnJpYW4sCgpJIHRoaW5rIG15IHVuZGVyc3RhbmRpbmcgb2Yg eW91ciBwcm9ibGVtIG1pZ2h0IHN0aWxsIGJlIHdyb25nLCBidXQgSSdsbCBtYWtlIHNvbWUgc3Vn Z2VzdGlvbnMgYW55d2F5Li4uCgpZb3UgZG9uJ3QgbmVlZCB0byBwcmVjb25maWd1cmUgdGhlIHNw b2tlIHJvdXRlciBNQUMgdGhhdCBnZXRzIHNlbnQgdG8gdGhlIGh1YiBiZWNhdXNlIHlvdSBjYW4g bGVhcm4gaXQgZnJvbSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBzcG9rZSBETEVQIHNlc3Npb24uICBU aGVuIHdoZW4gYW4gUkYgbGluayBpcyBlc3RhYmxpc2hlZCwgeW91IHNlbmQgaXQgdXAgdG8gdGhl IGh1YiwgYW5kIGl0IGNhbiByZXBvcnQgaXQgdGhyb3VnaCBpdCdzIGxvY2FsIERMRVAgc2Vzc2lv biwgYW5kIHZpY2UtdmVyc2EuCgpZb3UgZG9uJ3QgbmVlZCB0byByZXBvcnQgYWxsIGRlc3RpbmF0 aW9ucyBpbiBhbGwgc2Vzc2lvbnMsIG9ubHkgcmVsZXZhbnQgZGVzdGluYXRpb25zLiAgU28gaW4g dGhlIHNwb2tlIG1vZGVtLCB5b3Ugb25seSBuZWVkIHRvIHJlcG9ydCB0aGUgaHViIE1BQyBpbiB0 aGUgY29tbW9uIGNhc2UsIHVubGVzcyB5b3UgaGF2ZSB0dXJuZWQgb24gaGFpci1waW5uaW5nIGZv ciBzb21lIHN1YnNldCBvZiBzcG9rZXMsIGluIHdoaWNoIGNhc2UgeW91IG9ubHkgbmVlZCB0byBy ZXBvcnQgdGhvc2UgYWRkcmVzc2FibGUgTUFDcyBhcyBETEVQIGRlc3RpbmF0aW9ucy4KCkFzIEkg c2VlIGl0LCB5b3VyIHByb2JsZW0gaXMgYWxvbmcgdGhlIGxpbmVzIG9mICJPTUcsIEkgaGF2ZSAx MCwwMDAncyBzcG9rZXMgYW5kIEkgY2FuJ3QgaGF2ZSBhIG1hc3RlciBsaXN0IG9mIHNwb2tlIHJv dXRlciBNQUNzLCBhbmQgSSBkb24ndCB3YW50IHRvIHJlcG9ydCAxMCwwMDAncyBETEVQIHNlc3Np b25zIGV2ZXJ5d2hlcmUgd2hlbiBzcG9rZXMgY2FuIHJlYWxseSBvbmx5IHRhbGsgdG8gdGhlIGh1 YiIuICBBbmQgbXkgYW5zd2VyIGlzLCAiWW91IGRvbid0IGhhdmUgdG8gcmVwb3J0IGV2ZXJ5dGhp bmcsIGFsbCB0aGUgdGltZSwgYW5kIHlvdSBjYW4gbGVhcm4gdGhlIE1BQ3MgYXQgcnVudGltZS4i CgpDaGVlcnMsClJpY2sKIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkZyb206IFNueWRlciwgQnJpYW4gW2JzbnlkZXJAaWRpcmVjdC5uZXRdClNlbnQ6IDI1IEp1bHkg MjAxNCAxNDozNwpUbzogSGVubmluZyBSb2dnZQpDYzogUmljayBUYXlsb3I7IG1hbmV0QGlldGYu b3JnClN1YmplY3Q6IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVAKCkVt YmVkZGVkLi4uLgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogSGVubmluZyBSb2dn ZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dClNlbnQ6IEZyaWRheSwgSnVseSAyNSwgMjAxNCAy OjM2IEFNClRvOiBTbnlkZXIsIEJyaWFuCkNjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcK U3ViamVjdDogUmU6IFttYW5ldF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUAoKT24gRnJp LCBKdWwgMjUsIDIwMTQgYXQgMTI6NTEgQU0sIFNueWRlciwgQnJpYW4gPGJzbnlkZXJAaWRpcmVj dC5uZXQ+IHdyb3RlOgo+IFtCU1NdIOKAkyBBbmQgSSBndWVzcyBJIGFtIGxvb2tpbmcgZm9yIHNv bWV0aGluZyBkaWZmZXJlbnQuICBJ4oCZbSBsb29raW5nIGZvciBsaW5rIHN0YXRlIG5vdGlmaWNh dGlvbnMgKHdpdGggbWV0cmljcykgdG8gIC0gYW5kIHRoaXMgaXMgYSBkaWZmZXJlbnQgIzIg4oCT IGFsbG93IGEgcm91dGluZyBwcm90b2NvbCB0byBiZSB0dW5lZCBmb3IgbWluaW11bSBLRUVQIEFM SVZFIHRpbWVycyB0byBtaW5pbWl6ZSBiYW5kd2lkdGggdXNhZ2UgdG8gY29uc2VydmUgdmVyeSBl eHBlbnNpdmUgYW5kIGxpbWl0ZWQgYmFuZHdpZHRoLiAgSW4gYSBzYXRlbGxpdGUgbmV0d29yaywg dGhlcmUgaXMgbm8gbmVlZCBmb3IgZmFzdC1zdGFydHMsIEwxIGNvbnZlcmdlbmNlIGNhbiAoYW5k IGluIGEgc3VpdGFibHkgc2l6ZWQgbmV0d29yayB3aWxsIHRha2Ugc2Vjb25kcykuICBIb3dldmVy LCBiZWNhdXNlIG1vZGVtcyB0ZW5kIHRvIHN0YXkgaW4gbmV0d29yayBxdWl0ZSBzdGFibHkgKHRy ZWVzIGFuZCBidWlsZGluZ3MgZG9u4oCZdCBnZXQgdGhlIHdheSBvZnRlbiBpbiB0aGUgb2NlYW7i mLopLCB0aGUgYnVpbGRpbmcgb2YgYWRqYWNlbmNpZXMgZG9lcyBub3QgaGFwcGVuIGFsbCB0aGF0 IG9mdGVuLiBJdOKAmXMgd2F5IG1vcmUgaW1wb3J0YW50IHRvIG1lIHRvIGNvbnNlcnZlIGJhbmR3 aWR0aCBhbmQgYmUgdHJhbnNwYXJlbnQuCgpJIG11c3QgYWRtaXQgSSBzdGlsbCBmYWlsIHRvIHNl ZSB3aHkgYSBzcGVjaWFsIGNhc2UgaXMgZXZlbiBuZWNlc3NhcnkuCgpbQlNTXSAtIFBlcmhhcHMg bm90IG5lY2Vzc2FyeSAtIGJ1dCBJJ20gdmVyeSBjb25jZXJuZWQgd2l0aCB0cnlpbmcgdG8gb3B0 aW1pemUgZm9yIHNjYWxlIGFuZCB0cmFuc3BhcmVuY3kuCgpXZSBhcmUgdGFsa2luZyBhYm91dCBh IG5ldHdvcmsgd2l0aCBodW5kcmVkIHRob3VzYW5kcyBjbGllbnRzIGNvbm5lY3RlZCB2aWEgc2F0 ZWxsaXRlIHRvIGEgSHViIHN0YXRpb24uIFllcywgc28gd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhh dCB0aGUgY2xpZW50cyBkb24ndCB0YWxrIG1vcmUgdGhhbiBuZWNlc3NhcnkuCgpCdXQgeW91IHNh aWQgeW91ciBjbGllbnQgc2F0ZWxsaXRlIG1vZGVtcyBhcmUgYWJsZSB0byByZWNlaXZlIGJyb2Fk Y2FzdCB0cmFmZmljLi4uIGFuZCBtYXliZSBldmVuIHVuaWNhc3RzIGRlbGl2ZXJlZCB0byBhIGRp ZmZlcmVudCBjbGllbnQuIFRoaXMgbWVhbnMgcHVzaGluZyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBI dWIgdG8gYWxsIGNsaWVudHMgaXMgcmVhc29uYWJsZSBjaGVhcC4KW0JTU10gLSBUaGV5IHdvbid0 IHJlY2VpdmUgdW5pY2FzdCBmb3Igc29tZW9uZSBlbHNlLiAgSERMQyBhZGRyZXNzaW5nIGRlbXV4 ZXMgdGhhdC4gIFB1c2hpbmcgYnJvYWRjYXN0IGlzIGNoZWFwLiAgSUU6IEFSUHMgY2FuIGZsb3cg ZnJlZWx5IGFuZCBjaGVhcGx5IG9uIHRoZSBkb3duc3RyZWFtLgoKVGhpcyBtZWFucyB0cmFuc2Zl cnJpbmcgdGhlIE1hYyBhZGRyZXNzIHRvIGEgY2xpZW50IGlzIGRpcnQgY2hlYXAsIGVzcGVjaWFs bHkgaWYgTGF5ZXItMiBhdCB0aGUgSHViIGlzIGFibGUgdG8gdGVsbCB0aGF0IGEgbmV3IGNsaWVu dCBjb25uZWN0ZWQgdG8gdGhlIHNhdGVsbGl0ZS4KW0JTU10gLSBJbiB0aGlzIGNhc2UgdHJhbnNm ZXJyaW5nIGEgbWFjIGFkZHJlc3MgaXMgY2hlYXAgLSB0aGUgYXJwJ3MgZG8gaXQgdGhyb3VnaCB1 cyAtLSB0aG91Z2ggdGhlIG1vZGVtcyBjdXJyZW50bHkgZG9uJ3QgdHJhY2sgYW5kIHJlY29yZCBh bnkgb2YgdGhlIGxlYXJudCBhZGRyZXNzIE9UQS4uLiB3ZSBqdXN0IGxldCB0aGUgY3VzdG9tZXIg ZGV2aWNlcyBkbyB3aGF0IHRoZXkgc2hvdWxkIGRvIGJ5IGFsbCBub3JtYWwgY29udmVudGlvbnMu IChBUlAsIHRpbWVycywgZXRjKS4gIE1vZGVtcyBoYXZlIG5vIG5vdGlvbiBvZiB3ZWF0aGVyIG9y IG5vdCBhbm90aGVyIG1vZGVtIGlzIGluIG9yIG91dCBvZiBuZXR3b3JrLiAgTm8gc3RhciBzeXN0 ZW0gd291bGQuIFRoZXkganVzdCB0cmFjayB0aGVtc2VsdmVzLiBTbyBpZiBNQUMgYWRkcmVzc2Vz IGFyZSBzdXBwb3NlZCB0byBiZSBzdG9yZWQgYW5kIG1hbmFnZWQgYnkgdGhlIG1vZGVtIGZvciBE TEVQIG1hbmFnZW1lbnQgYXV0b21hdGljYWxseSwgd2UgYSkgYXJlbid0IHRyYW5zcGFyZW50IGFu eW1vcmUgYikgSGF2ZSBhIHNjYWxlIHByb2JsZW0gbWFuYWdpbmcgYWxsIHRob3NlIG1hY3MgYykg SWYgdGhlcmUgYXJlIG1vcmUgbWFjIGFkZHJlc3NlcyAobm90IHJvdXRlcnMgd2Ugd291bGQgY2Fy ZSBhYm91dCB2aWEgZGxlcCkgaG93IGlzIGEgdHJhbnNwYXJlbnQgc3dpdGNoIHN1cHBvc2VkIHRv ICJLTk9XIiB3aGljaCBtYWMgYWRkcmVzcyBpcyB0aGUgc3BlY2lhbCBvbmUgdGhhdCBzaG91bGQg YmUgJ3NldHVwJyBhcyB0aGUgZGxlcCB0YXJnZXQuICBJIHRoaW5rIHRoYXQgd291bGQgcmVxdWly ZSBzb21lIHNwZWNpYWwgY29uZmlnIHRoYXQgdGhlbiBoYXMgdG8gYmUgbWFuYWdlZCAoYWxzbyBi cmVha2luZyB0cmFuc3BhcmVuY3kpIGFuZCBjcmVhdGluZyBPQU0gYW5kIGNoYW5nZSBtYW5hZ2Vt ZW50IGlzc3Vlcy4gUmVtZW1iZXIgdGhlIExBTiBpcyBub3QgJ291cicgZXF1aXBtZW50LCBzbyBh bGwgdGhlIHN1ZGRlbiBvbmUgd291bGQgaGF2ZSB0byBnZXQgYW5kIG1hbmFnZSBtYWMgYWRkcmVz c2VzIGZvciBhbGwgdGhlc2Ugc2l0ZXMuICBXZSBhcmUgZ29pbmcgTDIgaW4tb3JkZXIgdG8gaGVs cCB1cyBhbmQgb3VyIGNsaWVudHMgbm90IHdvcnJ5IGFib3V0IGVhY2ggb3RoZXIncyBlcXVpcG1l bnQgYW5kIG5ldHdvcmtpbmcuCgoKV2hhdCBpcyB0aGUgdHlwaWNhbCB1cHRpbWUgb2YgYSBjbGll bnQ/IEFuZCB3aGF0IHBlcmNlbnRhZ2Ugb2YgdHJhZmZpYyBnb2VzIGZyb20gdGhlIEh1YiB0byB0 aGUgY2xpZW50cz8gQSByb3VnaCBndWVzcyB3b3VsZCBiZSBncmVhdCB0byBiZXR0ZXIgdW5kZXJz dGFuZCB5b3VyIHByb2JsZW0uCltCU1NdIC0gVHlwaWNhbCB1cHRpbWUgd291bGQgYmUgbWVhc3Vy ZWQgaW4gZnJvbSBob3VycyAoTWF5YmUgYSBwbGFuZSBtb3ZpbmcgYWNyb3NzIHNhdGVsbGl0ZSBm b290cHJpbnRzKSB0byBob3BlZnVsbHkgeWVhcnMgLSBhIHN0YXRpb25hcnkgbW9kZW0uICBUaG91 Z2ggcHJhY3RpY2FsbHkgdGhhdOKAmXMgbWF5YmUgbW9yZSBub3JtYWxseSBtb250aHMgZHVlIHRv IHdlYXRoZXIsIHVwZ3JhZGVzLCBldGMuCgpIZW5uaW5nIFJvZ2dlCg== From nobody Fri Jul 25 07:18:30 2014 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 3F6061A0243 for ; Fri, 25 Jul 2014 07:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 imNmsciMblXR for ; Fri, 25 Jul 2014 07:18:08 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 295CF1B2881 for ; Fri, 25 Jul 2014 07:18:08 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,731,1400040000"; d="scan'208";a="2599337" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 25 Jul 2014 10:18:07 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Fri, 25 Jul 2014 10:18:07 -0400 From: "Snyder, Brian" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0AAaqRUAAAX832AACbWtAAAIUehw Date: Fri, 25 Jul 2014 14:18:06 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PpDZlgwwbKrXZhaGGAkavJ7RepU Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 14:18:14 -0000 PkFzIEkgc2VlIGl0LCB5b3VyIHByb2JsZW0gaXMgYWxvbmcgdGhlIGxpbmVzIG9mICJPTUcsIEkg aGF2ZSAxMCwwMDAncyBzcG9rZXMgYW5kIEkgY2FuJ3QgaGF2ZSBhIG1hc3RlciBsaXN0IG9mIHNw b2tlIHJvdXRlciBNQUNzLCBhbmQgSSBkb24ndCB3YW50IHRvIHJlcG9ydCAxMCwwMDAncyBETEVQ IHNlc3Npb25zIGV2ZXJ5d2hlcmUgd2hlbiBzcG9rZXMgY2FuIHJlYWxseSBvbmx5IHRhbGsgdG8g dGhlIGh1YiIuICBBbmQgbXkgYW5zd2VyIGlzLCA+IllvdSBkb24ndCBoYXZlIHRvIHJlcG9ydCBl dmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUsIGFuZCB5b3UgY2FuIGxlYXJuIHRoZSBNQUNzIGF0IHJ1 bnRpbWUuIg0KDQpZZXMsIHRoYXQgaXMgYSBjb25jZXJuIG9mIG1pbmUuLi4gYnV0IG5vdCB0aGUg b25seSBvbmUuICBJIHVuZGVyc3RhbmQgSSBvbmx5IGhhdmUgdG8gcmVwb3J0IHdoYXQgSSB3YW50 IHRvbyBidXQgSSdtIGFsc28gY29uY2VybmVkIHdpdGggdGhlIG5vdGlvbiBJIGNhbiBhdXRvLWxl YXJuIGl0LiAgSG93IHdvdWxkIEkga25vdywgaW4gYSBWUExTIG5ldHdvcmsgd2hpY2ggbWFjIGlz IHRoZSB1cHN0cmVhbSByb3V0ZXI/IEkgY291bGQgYmUgaW51bmRhdGVkIHdpdGggTUFDcyBmcm9t IGFsbCBvdmVyIHRoZSBuZXR3b3JrLiBNYXliZSBzb21lIEknZCBjYXJlIGFib3V0IGFuZCBzb21l IEkgd291bGRuJ3QuICBCdXQgSSBjZXJ0YWlubHkgY291bGRuJ3QgdHJhY2sgdGhlbSBpbmRpdmlk dWFsbHkuIEkgaGF2ZSBubyBpZGVhIG9mIGFub3RoZXIgbW9kZW1zIHN0YXRlLiAgSSBvbmx5IGtu b3cgTVkgc3RhdGUgaW4gcmVsYXRpb24gdG8gdGhlIGh1YiAtIElFOiBhbSBJIGluIG5ldHdvcmsg b3Igbm90LiAgQWxzbyByZWNvZ25pemUgdGhhdCBpZiBJIGhhdmUgYSBodW5kcmVkIHRob3VzYW5k IE1BQyBhZGRyZXNzZXMgYW5kIEkgaGFkIHRvIHRyYWNrIHRoZW0gYWxsIC0tIHdlbGwgYSBjb21t b24gZGVzaWduIHdpdGggb3VyIG5ldHdvcmtzIGlzIGZvciBwZW9wbGUgdG8gdXNlIG11bHRpcGxl IFNWTnMgKHZsYW5zL3FpbnFzKSB0YWdzIFBFUiBtb2RlbS4gIE1hbnkgZGVzaWducyBoYXZlIDEy IGVhY2guIE91ciBuYW1lc3BhY2VzIGFyZSBrZXB0IHNlcGFyYXRlbHkuLi4uIHNvIGEgaHVuZHJl ZCB0aG91c2FuZCBtb2RlbXMgd2l0aCAxMiB2bGFucyB3b3VsZCBiZSAxLjIgTUlMTElPTiBtYWNz IHRoYXQgY291bGQgcG90ZW50aWFsbHkgYmUgc2Vlbi4NCg0KR3JhbnRlZCwgSSBkb27igJl0IHRo aW5rIHRoYXQgc2NhbGUgaXMgZ29pbmcgdG8gYmUgcm9sbCBvdXQgIzEgb2YgRExFUCB1c2UgY2Fz ZSAtIGJ1dCB3ZSBkbyBoYXZlIGN1c3RvbWVycyBvcGVyYXRpbmcgYXQgdGhhdCBzY2FsZS4gIElm ICdETEVQJyBmZWF0dXJlIGdldHMgcmVsZWFzZWQgLSB0aGV5IHdpbGwgd2FudCB0byB1c2UgaXQu DQoNCk5vIG1vZGVtIGN1cnJlbnRseSB0cmFja3MgYW55IE1BQ3MgZnJvbSB0aGUgaHViIHNpZGUg Zm9yIHRoaXMgcmVhc29uIC0tIGFuZCB3ZSBkb24ndCBuZWVkIHRvbyAoeWV0OikpLg0KDQpicmlh bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljayBUYXlsb3IgW21haWx0 bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb21dIA0KU2VudDogRnJpZGF5LCBKdWx5IDI1 LCAyMDE0IDEwOjA1IEFNDQpUbzogU255ZGVyLCBCcmlhbjsgSGVubmluZyBSb2dnZQ0KQ2M6IG1h bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZv ciBETEVQDQoNClRvcC1wb3N0ZWQuLi4NCg0KU29ycnkgQnJpYW4sDQoNCkkgdGhpbmsgbXkgdW5k ZXJzdGFuZGluZyBvZiB5b3VyIHByb2JsZW0gbWlnaHQgc3RpbGwgYmUgd3JvbmcsIGJ1dCBJJ2xs IG1ha2Ugc29tZSBzdWdnZXN0aW9ucyBhbnl3YXkuLi4NCg0KWW91IGRvbid0IG5lZWQgdG8gcHJl Y29uZmlndXJlIHRoZSBzcG9rZSByb3V0ZXIgTUFDIHRoYXQgZ2V0cyBzZW50IHRvIHRoZSBodWIg YmVjYXVzZSB5b3UgY2FuIGxlYXJuIGl0IGZyb20gdGhlIGVuZHBvaW50cyBvZiB0aGUgc3Bva2Ug RExFUCBzZXNzaW9uLiAgVGhlbiB3aGVuIGFuIFJGIGxpbmsgaXMgZXN0YWJsaXNoZWQsIHlvdSBz ZW5kIGl0IHVwIHRvIHRoZSBodWIsIGFuZCBpdCBjYW4gcmVwb3J0IGl0IHRocm91Z2ggaXQncyBs b2NhbCBETEVQIHNlc3Npb24sIGFuZCB2aWNlLXZlcnNhLg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBy ZXBvcnQgYWxsIGRlc3RpbmF0aW9ucyBpbiBhbGwgc2Vzc2lvbnMsIG9ubHkgcmVsZXZhbnQgZGVz dGluYXRpb25zLiAgU28gaW4gdGhlIHNwb2tlIG1vZGVtLCB5b3Ugb25seSBuZWVkIHRvIHJlcG9y dCB0aGUgaHViIE1BQyBpbiB0aGUgY29tbW9uIGNhc2UsIHVubGVzcyB5b3UgaGF2ZSB0dXJuZWQg b24gaGFpci1waW5uaW5nIGZvciBzb21lIHN1YnNldCBvZiBzcG9rZXMsIGluIHdoaWNoIGNhc2Ug eW91IG9ubHkgbmVlZCB0byByZXBvcnQgdGhvc2UgYWRkcmVzc2FibGUgTUFDcyBhcyBETEVQIGRl c3RpbmF0aW9ucy4NCg0KQXMgSSBzZWUgaXQsIHlvdXIgcHJvYmxlbSBpcyBhbG9uZyB0aGUgbGlu ZXMgb2YgIk9NRywgSSBoYXZlIDEwLDAwMCdzIHNwb2tlcyBhbmQgSSBjYW4ndCBoYXZlIGEgbWFz dGVyIGxpc3Qgb2Ygc3Bva2Ugcm91dGVyIE1BQ3MsIGFuZCBJIGRvbid0IHdhbnQgdG8gcmVwb3J0 IDEwLDAwMCdzIERMRVAgc2Vzc2lvbnMgZXZlcnl3aGVyZSB3aGVuIHNwb2tlcyBjYW4gcmVhbGx5 IG9ubHkgdGFsayB0byB0aGUgaHViIi4gIEFuZCBteSBhbnN3ZXIgaXMsICJZb3UgZG9uJ3QgaGF2 ZSB0byByZXBvcnQgZXZlcnl0aGluZywgYWxsIHRoZSB0aW1lLCBhbmQgeW91IGNhbiBsZWFybiB0 aGUgTUFDcyBhdCBydW50aW1lLiINCg0KQ2hlZXJzLA0KUmljaw0KIA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogU255ZGVyLCBCcmlhbiBbYnNueWRlckBp ZGlyZWN0Lm5ldF0NClNlbnQ6IDI1IEp1bHkgMjAxNCAxNDozNw0KVG86IEhlbm5pbmcgUm9nZ2UN CkNjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbWFuZXRdIFJl cXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVANCg0KRW1iZWRkZWQuLi4uDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIZW5uaW5nIFJvZ2dlIFttYWlsdG86aHJvZ2dlQGdtYWls LmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAyNSwgMjAxNCAyOjM2IEFNDQpUbzogU255ZGVyLCBC cmlhbg0KQ2M6IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5l dF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KDQpPbiBGcmksIEp1bCAyNSwgMjAxNCBh dCAxMjo1MSBBTSwgU255ZGVyLCBCcmlhbiA8YnNueWRlckBpZGlyZWN0Lm5ldD4gd3JvdGU6DQo+ IFtCU1NdIOKAkyBBbmQgSSBndWVzcyBJIGFtIGxvb2tpbmcgZm9yIHNvbWV0aGluZyBkaWZmZXJl bnQuICBJ4oCZbSBsb29raW5nIGZvciBsaW5rIHN0YXRlIG5vdGlmaWNhdGlvbnMgKHdpdGggbWV0 cmljcykgdG8gIC0gYW5kIHRoaXMgaXMgYSBkaWZmZXJlbnQgIzIg4oCTIGFsbG93IGEgcm91dGlu ZyBwcm90b2NvbCB0byBiZSB0dW5lZCBmb3IgbWluaW11bSBLRUVQIEFMSVZFIHRpbWVycyB0byBt aW5pbWl6ZSBiYW5kd2lkdGggdXNhZ2UgdG8gY29uc2VydmUgdmVyeSBleHBlbnNpdmUgYW5kIGxp bWl0ZWQgYmFuZHdpZHRoLiAgSW4gYSBzYXRlbGxpdGUgbmV0d29yaywgdGhlcmUgaXMgbm8gbmVl ZCBmb3IgZmFzdC1zdGFydHMsIEwxIGNvbnZlcmdlbmNlIGNhbiAoYW5kIGluIGEgc3VpdGFibHkg c2l6ZWQgbmV0d29yayB3aWxsIHRha2Ugc2Vjb25kcykuICBIb3dldmVyLCBiZWNhdXNlIG1vZGVt cyB0ZW5kIHRvIHN0YXkgaW4gbmV0d29yayBxdWl0ZSBzdGFibHkgKHRyZWVzIGFuZCBidWlsZGlu Z3MgZG9u4oCZdCBnZXQgdGhlIHdheSBvZnRlbiBpbiB0aGUgb2NlYW7imLopLCB0aGUgYnVpbGRp bmcgb2YgYWRqYWNlbmNpZXMgZG9lcyBub3QgaGFwcGVuIGFsbCB0aGF0IG9mdGVuLiBJdOKAmXMg d2F5IG1vcmUgaW1wb3J0YW50IHRvIG1lIHRvIGNvbnNlcnZlIGJhbmR3aWR0aCBhbmQgYmUgdHJh bnNwYXJlbnQuDQoNCkkgbXVzdCBhZG1pdCBJIHN0aWxsIGZhaWwgdG8gc2VlIHdoeSBhIHNwZWNp YWwgY2FzZSBpcyBldmVuIG5lY2Vzc2FyeS4NCg0KW0JTU10gLSBQZXJoYXBzIG5vdCBuZWNlc3Nh cnkgLSBidXQgSSdtIHZlcnkgY29uY2VybmVkIHdpdGggdHJ5aW5nIHRvIG9wdGltaXplIGZvciBz Y2FsZSBhbmQgdHJhbnNwYXJlbmN5Lg0KDQpXZSBhcmUgdGFsa2luZyBhYm91dCBhIG5ldHdvcmsg d2l0aCBodW5kcmVkIHRob3VzYW5kcyBjbGllbnRzIGNvbm5lY3RlZCB2aWEgc2F0ZWxsaXRlIHRv IGEgSHViIHN0YXRpb24uIFllcywgc28gd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgY2xp ZW50cyBkb24ndCB0YWxrIG1vcmUgdGhhbiBuZWNlc3NhcnkuDQoNCkJ1dCB5b3Ugc2FpZCB5b3Vy IGNsaWVudCBzYXRlbGxpdGUgbW9kZW1zIGFyZSBhYmxlIHRvIHJlY2VpdmUgYnJvYWRjYXN0IHRy YWZmaWMuLi4gYW5kIG1heWJlIGV2ZW4gdW5pY2FzdHMgZGVsaXZlcmVkIHRvIGEgZGlmZmVyZW50 IGNsaWVudC4gVGhpcyBtZWFucyBwdXNoaW5nIGluZm9ybWF0aW9uIGZyb20gdGhlIEh1YiB0byBh bGwgY2xpZW50cyBpcyByZWFzb25hYmxlIGNoZWFwLg0KW0JTU10gLSBUaGV5IHdvbid0IHJlY2Vp dmUgdW5pY2FzdCBmb3Igc29tZW9uZSBlbHNlLiAgSERMQyBhZGRyZXNzaW5nIGRlbXV4ZXMgdGhh dC4gIFB1c2hpbmcgYnJvYWRjYXN0IGlzIGNoZWFwLiAgSUU6IEFSUHMgY2FuIGZsb3cgZnJlZWx5 IGFuZCBjaGVhcGx5IG9uIHRoZSBkb3duc3RyZWFtLg0KDQpUaGlzIG1lYW5zIHRyYW5zZmVycmlu ZyB0aGUgTWFjIGFkZHJlc3MgdG8gYSBjbGllbnQgaXMgZGlydCBjaGVhcCwgZXNwZWNpYWxseSBp ZiBMYXllci0yIGF0IHRoZSBIdWIgaXMgYWJsZSB0byB0ZWxsIHRoYXQgYSBuZXcgY2xpZW50IGNv bm5lY3RlZCB0byB0aGUgc2F0ZWxsaXRlLg0KW0JTU10gLSBJbiB0aGlzIGNhc2UgdHJhbnNmZXJy aW5nIGEgbWFjIGFkZHJlc3MgaXMgY2hlYXAgLSB0aGUgYXJwJ3MgZG8gaXQgdGhyb3VnaCB1cyAt LSB0aG91Z2ggdGhlIG1vZGVtcyBjdXJyZW50bHkgZG9uJ3QgdHJhY2sgYW5kIHJlY29yZCBhbnkg b2YgdGhlIGxlYXJudCBhZGRyZXNzIE9UQS4uLiB3ZSBqdXN0IGxldCB0aGUgY3VzdG9tZXIgZGV2 aWNlcyBkbyB3aGF0IHRoZXkgc2hvdWxkIGRvIGJ5IGFsbCBub3JtYWwgY29udmVudGlvbnMuIChB UlAsIHRpbWVycywgZXRjKS4gIE1vZGVtcyBoYXZlIG5vIG5vdGlvbiBvZiB3ZWF0aGVyIG9yIG5v dCBhbm90aGVyIG1vZGVtIGlzIGluIG9yIG91dCBvZiBuZXR3b3JrLiAgTm8gc3RhciBzeXN0ZW0g d291bGQuIFRoZXkganVzdCB0cmFjayB0aGVtc2VsdmVzLiBTbyBpZiBNQUMgYWRkcmVzc2VzIGFy ZSBzdXBwb3NlZCB0byBiZSBzdG9yZWQgYW5kIG1hbmFnZWQgYnkgdGhlIG1vZGVtIGZvciBETEVQ IG1hbmFnZW1lbnQgYXV0b21hdGljYWxseSwgd2UgYSkgYXJlbid0IHRyYW5zcGFyZW50IGFueW1v cmUgYikgSGF2ZSBhIHNjYWxlIHByb2JsZW0gbWFuYWdpbmcgYWxsIHRob3NlIG1hY3MgYykgSWYg dGhlcmUgYXJlIG1vcmUgbWFjIGFkZHJlc3NlcyAobm90IHJvdXRlcnMgd2Ugd291bGQgY2FyZSBh Ym91dCB2aWEgZGxlcCkgaG93IGlzIGEgdHJhbnNwYXJlbnQgc3dpdGNoIHN1cHBvc2VkIHRvICJL Tk9XIiB3aGljaCBtYWMgYWRkcmVzcyBpcyB0aGUgc3BlY2lhbCBvbmUgdGhhdCBzaG91bGQgYmUg J3NldHVwJyBhcyB0aGUgZGxlcCB0YXJnZXQuICBJIHRoaW5rIHRoYXQgd291bGQgcmVxdWlyZSBz b21lIHNwZWNpYWwgY29uZmlnIHRoYXQgdGhlbiBoYXMgdG8gYmUgbWFuYWdlZCAoYWxzbyBicmVh a2luZyB0cmFuc3BhcmVuY3kpIGFuZCBjcmVhdGluZyBPQU0gYW5kIGNoYW5nZSBtYW5hZ2VtZW50 IGlzc3Vlcy4gUmVtZW1iZXIgdGhlIExBTiBpcyBub3QgJ291cicgZXF1aXBtZW50LCBzbyBhbGwg dGhlIHN1ZGRlbiBvbmUgd291bGQgaGF2ZSB0byBnZXQgYW5kIG1hbmFnZSBtYWMgYWRkcmVzc2Vz IGZvciBhbGwgdGhlc2Ugc2l0ZXMuICBXZSBhcmUgZ29pbmcgTDIgaW4tb3JkZXIgdG8gaGVscCB1 cyBhbmQgb3VyIGNsaWVudHMgbm90IHdvcnJ5IGFib3V0IGVhY2ggb3RoZXIncyBlcXVpcG1lbnQg YW5kIG5ldHdvcmtpbmcuDQoNCg0KV2hhdCBpcyB0aGUgdHlwaWNhbCB1cHRpbWUgb2YgYSBjbGll bnQ/IEFuZCB3aGF0IHBlcmNlbnRhZ2Ugb2YgdHJhZmZpYyBnb2VzIGZyb20gdGhlIEh1YiB0byB0 aGUgY2xpZW50cz8gQSByb3VnaCBndWVzcyB3b3VsZCBiZSBncmVhdCB0byBiZXR0ZXIgdW5kZXJz dGFuZCB5b3VyIHByb2JsZW0uDQpbQlNTXSAtIFR5cGljYWwgdXB0aW1lIHdvdWxkIGJlIG1lYXN1 cmVkIGluIGZyb20gaG91cnMgKE1heWJlIGEgcGxhbmUgbW92aW5nIGFjcm9zcyBzYXRlbGxpdGUg Zm9vdHByaW50cykgdG8gaG9wZWZ1bGx5IHllYXJzIC0gYSBzdGF0aW9uYXJ5IG1vZGVtLiAgVGhv dWdoIHByYWN0aWNhbGx5IHRoYXTigJlzIG1heWJlIG1vcmUgbm9ybWFsbHkgbW9udGhzIGR1ZSB0 byB3ZWF0aGVyLCB1cGdyYWRlcywgZXRjLg0KDQpIZW5uaW5nIFJvZ2dlDQo= From nobody Fri Jul 25 07:29:24 2014 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 0430B1B2949 for ; Fri, 25 Jul 2014 07:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 mYMVs27xMJ-q for ; Fri, 25 Jul 2014 07:29:13 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 8B0A81A0147 for ; Fri, 25 Jul 2014 07:29:12 -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, 25 Jul 2014 15:28:43 +0100 From: Rick Taylor To: "Snyder, Brian" , Henning Rogge Thread-Topic: [manet] Request to consider for DLEP Thread-Index: AQHPp9bVBz332mowOEGhx2cRjj5qopuwup+AgAAU4JT///aRAIAAEgue Date: Fri, 25 Jul 2014 14:28:42 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kfMbLSbn74Kh41a2pGl5nVXtK8w Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 14:29:16 -0000 SW5saW5lIGNvbW1lbnRzLi4uLgoKPj5BcyBJIHNlZSBpdCwgeW91ciBwcm9ibGVtIGlzIGFsb25n IHRoZSBsaW5lcyBvZiAiT01HLCBJIGhhdmUgMTAsMDAwJ3Mgc3Bva2VzIGFuZCBJIGNhbid0IGhh dmUgYSBtYXN0ZXIgbGlzdCBvZiBzcG9rZSByb3V0ZXIgTUFDcywgYW5kIEkgZG9uJ3Qgd2FudCB0 byByZXBvcnQgMTAsMDAwJ3MgRExFUCBzZXNzaW9ucyBldmVyeXdoZXJlIHdoZW4gc3Bva2VzIGNh biByZWFsbHkgb25seSB0YWxrIHRvIHRoZSBodWIiLiAgQW5kIG15IGFuc3dlciBpcywgIllvdSBk b24ndCBoYXZlIHRvIHJlcG9ydCBldmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUsIGFuZCB5b3UgY2Fu IGxlYXJuIHRoZSBNQUNzIGF0IHJ1bnRpbWUuIgoKPlllcywgdGhhdCBpcyBhIGNvbmNlcm4gb2Yg bWluZS4uLiBidXQgbm90IHRoZSBvbmx5IG9uZS4gIEkgdW5kZXJzdGFuZCBJIG9ubHkgaGF2ZSB0 byByZXBvcnQgd2hhdCBJIHdhbnQgdG9vIGJ1dCBJJ20gYWxzbyBjb25jZXJuZWQgd2l0aCB0aGUg bm90aW9uIEkgY2FuIGF1dG8tbGVhcm4gaXQuICBIb3cgd291bGQgSSBrbm93LCBpbiBhIFZQTFMg bmV0d29yayB3aGljaCBtYWMgaXMgdGhlIHVwc3RyZWFtIHJvdXRlcj8gSSBjb3VsZCBiZSBpbnVu ZGF0ZWQgd2l0aCBNQUNzIGZyb20gYWxsIG92ZXIgdGhlIG5ldHdvcmsuIE1heWJlIHNvbWUgSSdk IGNhcmUgYWJvdXQgYW5kIHNvbWUgSSB3b3VsZG4ndC4gIEJ1dCBJIGNlcnRhaW5seSBjb3VsZG4n dCB0cmFjayB0aGVtIGluZGl2aWR1YWxseS4gSSBoYXZlIG5vIGlkZWEgb2YgYW5vdGhlciBtb2Rl bXMgc3RhdGUuICBJIG9ubHkga25vdyBNWSBzdGF0ZSBpbiByZWxhdGlvbiB0byB0aGUgaHViIC0g SUU6IGFtIEkgaW4gbmV0d29yayBvciBub3QuICBBbHNvIHJlY29nbml6ZSB0aGF0IGlmIEkgaGF2 ZSBhIGh1bmRyZWQgdGhvdXNhbmQgTUFDIGFkZHJlc3NlcyBhbmQgSSBoYWQgdG8gdHJhY2sgdGhl bSBhbGwgLS0gd2VsbCBhIGNvbW1vbiBkZXNpZ24gd2l0aCBvdXIgbmV0d29ya3MgaXMgZm9yIHBl b3BsZSB0byB1c2UgbXVsdGlwbGUgU1ZOcyAodmxhbnMvcWlucXMpIHRhZ3MgUEVSIG1vZGVtLiAg TWFueSBkZXNpZ25zIGhhdmUgMTIgZWFjaC4gT3VyIG5hbWVzcGFjZXMgYXJlIGtlcHQgc2VwYXJh dGVseS4uLi4gc28gYSBodW5kcmVkIHRob3VzYW5kIG1vZGVtcyB3aXRoIDEyIHZsYW5zIHdvdWxk IGJlIDEuMiBNSUxMSU9OIG1hY3MgdGhhdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBzZWVuLgoKQWgt aGEhISBUaGUgRExFUCBkZXN0aW5hdGlvbiBNQUMgaXMgZGVmaW5lZCB2ZXJ5IHNwZWNpZmljYWxs eSBhcyB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGludGVyZmFjZSB0aGF0IHRoZSByb3V0ZXIgaXMg dXNpbmcgZm9yIHRoZSBUQ1Agc2Vzc2lvbiB0byB0aGUgbG9jYWwgbW9kZW0uICBUaGUgcm91dGVy IG1heSBoYXZlIGEgYmlsbGlvbiBvdGhlciBNQUMgYWRkcmVzc2VzLCBidXQgb25seSB0aGF0IG9u ZSBpcyBpbXBvcnRhbnQuICBJbiB0aGUgc3Bva2UgY2FzZSwgdGhlIHNhbWUgYXBwbGllcywgYW5k IGlmIHRoZSBzcG9rZXMgZG9uJ3QgbmVlZCB0byBrbm93IGFib3V0IG90aGVyIHNwb2tlcywgZG9u J3QgdGVsbCB0aGVtLgoKPiBHcmFudGVkLCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBzY2FsZSBpcyBn b2luZyB0byBiZSByb2xsIG91dCAjMSBvZiBETEVQIHVzZSBjYXNlIC0gYnV0IHdlIGRvIGhhdmUg Y3VzdG9tZXJzIG9wZXJhdGluZyBhdCB0aGF0IHNjYWxlLiAgSWYgJ0RMRVAnIGZlYXR1cmUgZ2V0 cyByZWxlYXNlZCAtIHRoZXkgd2lsbCB3YW50IHRvIHVzZSBpdC4KCkFic29sdXRlbHksIHdoaWNo IGlzIHdoeSBJIGFuZCBvdGhlcnMgYXJlIHNwZW5kaW5nIHNvbWUgY3ljbGVzIHRvIGdldCB0aGlz IHNvcnRlZC4KCj4gTm8gbW9kZW0gY3VycmVudGx5IHRyYWNrcyBhbnkgTUFDcyBmcm9tIHRoZSBo dWIgc2lkZSBmb3IgdGhpcyByZWFzb24gLS0gYW5kIHdlIGRvbid0IG5lZWQgdG9vICh5ZXQ6KSku CgpIb3BlZnVsbHkgbXkgYW5zd2VyIGFib3ZlIHdpbGwgaGF2ZSBoZWxwZWQ/CgpSaWNrCgotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tAdHJv cGljYWxzdG9ybXNvZnR3YXJlLmNvbV0KU2VudDogRnJpZGF5LCBKdWx5IDI1LCAyMDE0IDEwOjA1 IEFNClRvOiBTbnlkZXIsIEJyaWFuOyBIZW5uaW5nIFJvZ2dlCkNjOiBtYW5ldEBpZXRmLm9yZwpT dWJqZWN0OiBSRTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQCgpUb3AtcG9z dGVkLi4uCgpTb3JyeSBCcmlhbiwKCkkgdGhpbmsgbXkgdW5kZXJzdGFuZGluZyBvZiB5b3VyIHBy b2JsZW0gbWlnaHQgc3RpbGwgYmUgd3JvbmcsIGJ1dCBJJ2xsIG1ha2Ugc29tZSBzdWdnZXN0aW9u cyBhbnl3YXkuLi4KCllvdSBkb24ndCBuZWVkIHRvIHByZWNvbmZpZ3VyZSB0aGUgc3Bva2Ugcm91 dGVyIE1BQyB0aGF0IGdldHMgc2VudCB0byB0aGUgaHViIGJlY2F1c2UgeW91IGNhbiBsZWFybiBp dCBmcm9tIHRoZSBlbmRwb2ludHMgb2YgdGhlIHNwb2tlIERMRVAgc2Vzc2lvbi4gIFRoZW4gd2hl biBhbiBSRiBsaW5rIGlzIGVzdGFibGlzaGVkLCB5b3Ugc2VuZCBpdCB1cCB0byB0aGUgaHViLCBh bmQgaXQgY2FuIHJlcG9ydCBpdCB0aHJvdWdoIGl0J3MgbG9jYWwgRExFUCBzZXNzaW9uLCBhbmQg dmljZS12ZXJzYS4KCllvdSBkb24ndCBuZWVkIHRvIHJlcG9ydCBhbGwgZGVzdGluYXRpb25zIGlu IGFsbCBzZXNzaW9ucywgb25seSByZWxldmFudCBkZXN0aW5hdGlvbnMuICBTbyBpbiB0aGUgc3Bv a2UgbW9kZW0sIHlvdSBvbmx5IG5lZWQgdG8gcmVwb3J0IHRoZSBodWIgTUFDIGluIHRoZSBjb21t b24gY2FzZSwgdW5sZXNzIHlvdSBoYXZlIHR1cm5lZCBvbiBoYWlyLXBpbm5pbmcgZm9yIHNvbWUg c3Vic2V0IG9mIHNwb2tlcywgaW4gd2hpY2ggY2FzZSB5b3Ugb25seSBuZWVkIHRvIHJlcG9ydCB0 aG9zZSBhZGRyZXNzYWJsZSBNQUNzIGFzIERMRVAgZGVzdGluYXRpb25zLgoKQXMgSSBzZWUgaXQs IHlvdXIgcHJvYmxlbSBpcyBhbG9uZyB0aGUgbGluZXMgb2YgIk9NRywgSSBoYXZlIDEwLDAwMCdz IHNwb2tlcyBhbmQgSSBjYW4ndCBoYXZlIGEgbWFzdGVyIGxpc3Qgb2Ygc3Bva2Ugcm91dGVyIE1B Q3MsIGFuZCBJIGRvbid0IHdhbnQgdG8gcmVwb3J0IDEwLDAwMCdzIERMRVAgc2Vzc2lvbnMgZXZl cnl3aGVyZSB3aGVuIHNwb2tlcyBjYW4gcmVhbGx5IG9ubHkgdGFsayB0byB0aGUgaHViIi4gIEFu ZCBteSBhbnN3ZXIgaXMsICJZb3UgZG9uJ3QgaGF2ZSB0byByZXBvcnQgZXZlcnl0aGluZywgYWxs IHRoZSB0aW1lLCBhbmQgeW91IGNhbiBsZWFybiB0aGUgTUFDcyBhdCBydW50aW1lLiIKCkNoZWVy cywKUmljawoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBT bnlkZXIsIEJyaWFuIFtic255ZGVyQGlkaXJlY3QubmV0XQpTZW50OiAyNSBKdWx5IDIwMTQgMTQ6 MzcKVG86IEhlbm5pbmcgUm9nZ2UKQ2M6IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZwpTdWJq ZWN0OiBSRTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQCgpFbWJlZGRlZC4u Li4KCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0 bzpocm9nZ2VAZ21haWwuY29tXQpTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMjozNiBBTQpU bzogU255ZGVyLCBCcmlhbgpDYzogUmljayBUYXlsb3I7IG1hbmV0QGlldGYub3JnClN1YmplY3Q6 IFJlOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVAKCk9uIEZyaSwgSnVsIDI1 LCAyMDE0IGF0IDEyOjUxIEFNLCBTbnlkZXIsIEJyaWFuIDxic255ZGVyQGlkaXJlY3QubmV0PiB3 cm90ZToKPiBbQlNTXSDigJMgQW5kIEkgZ3Vlc3MgSSBhbSBsb29raW5nIGZvciBzb21ldGhpbmcg ZGlmZmVyZW50LiAgSeKAmW0gbG9va2luZyBmb3IgbGluayBzdGF0ZSBub3RpZmljYXRpb25zICh3 aXRoIG1ldHJpY3MpIHRvICAtIGFuZCB0aGlzIGlzIGEgZGlmZmVyZW50ICMyIOKAkyBhbGxvdyBh IHJvdXRpbmcgcHJvdG9jb2wgdG8gYmUgdHVuZWQgZm9yIG1pbmltdW0gS0VFUCBBTElWRSB0aW1l cnMgdG8gbWluaW1pemUgYmFuZHdpZHRoIHVzYWdlIHRvIGNvbnNlcnZlIHZlcnkgZXhwZW5zaXZl IGFuZCBsaW1pdGVkIGJhbmR3aWR0aC4gIEluIGEgc2F0ZWxsaXRlIG5ldHdvcmssIHRoZXJlIGlz IG5vIG5lZWQgZm9yIGZhc3Qtc3RhcnRzLCBMMSBjb252ZXJnZW5jZSBjYW4gKGFuZCBpbiBhIHN1 aXRhYmx5IHNpemVkIG5ldHdvcmsgd2lsbCB0YWtlIHNlY29uZHMpLiAgSG93ZXZlciwgYmVjYXVz ZSBtb2RlbXMgdGVuZCB0byBzdGF5IGluIG5ldHdvcmsgcXVpdGUgc3RhYmx5ICh0cmVlcyBhbmQg YnVpbGRpbmdzIGRvbuKAmXQgZ2V0IHRoZSB3YXkgb2Z0ZW4gaW4gdGhlIG9jZWFu4pi6KSwgdGhl IGJ1aWxkaW5nIG9mIGFkamFjZW5jaWVzIGRvZXMgbm90IGhhcHBlbiBhbGwgdGhhdCBvZnRlbi4g SXTigJlzIHdheSBtb3JlIGltcG9ydGFudCB0byBtZSB0byBjb25zZXJ2ZSBiYW5kd2lkdGggYW5k IGJlIHRyYW5zcGFyZW50LgoKSSBtdXN0IGFkbWl0IEkgc3RpbGwgZmFpbCB0byBzZWUgd2h5IGEg c3BlY2lhbCBjYXNlIGlzIGV2ZW4gbmVjZXNzYXJ5LgoKW0JTU10gLSBQZXJoYXBzIG5vdCBuZWNl c3NhcnkgLSBidXQgSSdtIHZlcnkgY29uY2VybmVkIHdpdGggdHJ5aW5nIHRvIG9wdGltaXplIGZv ciBzY2FsZSBhbmQgdHJhbnNwYXJlbmN5LgoKV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBuZXR3b3Jr IHdpdGggaHVuZHJlZCB0aG91c2FuZHMgY2xpZW50cyBjb25uZWN0ZWQgdmlhIHNhdGVsbGl0ZSB0 byBhIEh1YiBzdGF0aW9uLiBZZXMsIHNvIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNs aWVudHMgZG9uJ3QgdGFsayBtb3JlIHRoYW4gbmVjZXNzYXJ5LgoKQnV0IHlvdSBzYWlkIHlvdXIg Y2xpZW50IHNhdGVsbGl0ZSBtb2RlbXMgYXJlIGFibGUgdG8gcmVjZWl2ZSBicm9hZGNhc3QgdHJh ZmZpYy4uLiBhbmQgbWF5YmUgZXZlbiB1bmljYXN0cyBkZWxpdmVyZWQgdG8gYSBkaWZmZXJlbnQg Y2xpZW50LiBUaGlzIG1lYW5zIHB1c2hpbmcgaW5mb3JtYXRpb24gZnJvbSB0aGUgSHViIHRvIGFs bCBjbGllbnRzIGlzIHJlYXNvbmFibGUgY2hlYXAuCltCU1NdIC0gVGhleSB3b24ndCByZWNlaXZl IHVuaWNhc3QgZm9yIHNvbWVvbmUgZWxzZS4gIEhETEMgYWRkcmVzc2luZyBkZW11eGVzIHRoYXQu ICBQdXNoaW5nIGJyb2FkY2FzdCBpcyBjaGVhcC4gIElFOiBBUlBzIGNhbiBmbG93IGZyZWVseSBh bmQgY2hlYXBseSBvbiB0aGUgZG93bnN0cmVhbS4KClRoaXMgbWVhbnMgdHJhbnNmZXJyaW5nIHRo ZSBNYWMgYWRkcmVzcyB0byBhIGNsaWVudCBpcyBkaXJ0IGNoZWFwLCBlc3BlY2lhbGx5IGlmIExh eWVyLTIgYXQgdGhlIEh1YiBpcyBhYmxlIHRvIHRlbGwgdGhhdCBhIG5ldyBjbGllbnQgY29ubmVj dGVkIHRvIHRoZSBzYXRlbGxpdGUuCltCU1NdIC0gSW4gdGhpcyBjYXNlIHRyYW5zZmVycmluZyBh IG1hYyBhZGRyZXNzIGlzIGNoZWFwIC0gdGhlIGFycCdzIGRvIGl0IHRocm91Z2ggdXMgLS0gdGhv dWdoIHRoZSBtb2RlbXMgY3VycmVudGx5IGRvbid0IHRyYWNrIGFuZCByZWNvcmQgYW55IG9mIHRo ZSBsZWFybnQgYWRkcmVzcyBPVEEuLi4gd2UganVzdCBsZXQgdGhlIGN1c3RvbWVyIGRldmljZXMg ZG8gd2hhdCB0aGV5IHNob3VsZCBkbyBieSBhbGwgbm9ybWFsIGNvbnZlbnRpb25zLiAoQVJQLCB0 aW1lcnMsIGV0YykuICBNb2RlbXMgaGF2ZSBubyBub3Rpb24gb2Ygd2VhdGhlciBvciBub3QgYW5v dGhlciBtb2RlbSBpcyBpbiBvciBvdXQgb2YgbmV0d29yay4gIE5vIHN0YXIgc3lzdGVtIHdvdWxk LiBUaGV5IGp1c3QgdHJhY2sgdGhlbXNlbHZlcy4gU28gaWYgTUFDIGFkZHJlc3NlcyBhcmUgc3Vw cG9zZWQgdG8gYmUgc3RvcmVkIGFuZCBtYW5hZ2VkIGJ5IHRoZSBtb2RlbSBmb3IgRExFUCBtYW5h Z2VtZW50IGF1dG9tYXRpY2FsbHksIHdlIGEpIGFyZW4ndCB0cmFuc3BhcmVudCBhbnltb3JlIGIp IEhhdmUgYSBzY2FsZSBwcm9ibGVtIG1hbmFnaW5nIGFsbCB0aG9zZSBtYWNzIGMpIElmIHRoZXJl IGFyZSBtb3JlIG1hYyBhZGRyZXNzZXMgKG5vdCByb3V0ZXJzIHdlIHdvdWxkIGNhcmUgYWJvdXQg dmlhIGRsZXApIGhvdyBpcyBhIHRyYW5zcGFyZW50IHN3aXRjaCBzdXBwb3NlZCB0byAiS05PVyIg d2hpY2ggbWFjIGFkZHJlc3MgaXMgdGhlIHNwZWNpYWwgb25lIHRoYXQgc2hvdWxkIGJlICdzZXR1 cCcgYXMgdGhlIGRsZXAgdGFyZ2V0LiAgSSB0aGluayB0aGF0IHdvdWxkIHJlcXVpcmUgc29tZSBz cGVjaWFsIGNvbmZpZyB0aGF0IHRoZW4gaGFzIHRvIGJlIG1hbmFnZWQgKGFsc28gYnJlYWtpbmcg dHJhbnNwYXJlbmN5KSBhbmQgY3JlYXRpbmcgT0FNIGFuZCBjaGFuZ2UgbWFuYWdlbWVudCBpc3N1 ZXMuIFJlbWVtYmVyIHRoZSBMQU4gaXMgbm90ICdvdXInIGVxdWlwbWVudCwgc28gYWxsIHRoZSBz dWRkZW4gb25lIHdvdWxkIGhhdmUgdG8gZ2V0IGFuZCBtYW5hZ2UgbWFjIGFkZHJlc3NlcyBmb3Ig YWxsIHRoZXNlIHNpdGVzLiAgV2UgYXJlIGdvaW5nIEwyIGluLW9yZGVyIHRvIGhlbHAgdXMgYW5k IG91ciBjbGllbnRzIG5vdCB3b3JyeSBhYm91dCBlYWNoIG90aGVyJ3MgZXF1aXBtZW50IGFuZCBu ZXR3b3JraW5nLgoKCldoYXQgaXMgdGhlIHR5cGljYWwgdXB0aW1lIG9mIGEgY2xpZW50PyBBbmQg d2hhdCBwZXJjZW50YWdlIG9mIHRyYWZmaWMgZ29lcyBmcm9tIHRoZSBIdWIgdG8gdGhlIGNsaWVu dHM/IEEgcm91Z2ggZ3Vlc3Mgd291bGQgYmUgZ3JlYXQgdG8gYmV0dGVyIHVuZGVyc3RhbmQgeW91 ciBwcm9ibGVtLgpbQlNTXSAtIFR5cGljYWwgdXB0aW1lIHdvdWxkIGJlIG1lYXN1cmVkIGluIGZy b20gaG91cnMgKE1heWJlIGEgcGxhbmUgbW92aW5nIGFjcm9zcyBzYXRlbGxpdGUgZm9vdHByaW50 cykgdG8gaG9wZWZ1bGx5IHllYXJzIC0gYSBzdGF0aW9uYXJ5IG1vZGVtLiAgVGhvdWdoIHByYWN0 aWNhbGx5IHRoYXTigJlzIG1heWJlIG1vcmUgbm9ybWFsbHkgbW9udGhzIGR1ZSB0byB3ZWF0aGVy LCB1cGdyYWRlcywgZXRjLgoKSGVubmluZyBSb2dnZQo= From nobody Fri Jul 25 09:24:28 2014 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 67F661B291C for ; Fri, 25 Jul 2014 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Bmt9JNX8t04G for ; Fri, 25 Jul 2014 09:24:23 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 945E21A0277 for ; Fri, 25 Jul 2014 09:24:22 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,732,1400040000"; d="scan'208";a="11428075" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 25 Jul 2014 12:24:21 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Fri, 25 Jul 2014 12:24:20 -0400 From: "Snyder, Brian" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0AAaqRUAAAX832AACbWtAAAIUehw///ECACAACSwsA== Date: Fri, 25 Jul 2014 16:24:20 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Jud3FNY4Po6lTedmSqe2XfUU4PY Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 16:24:25 -0000 UmljaywNCg0KPkFoLWhhISEgVGhlIERMRVAgZGVzdGluYXRpb24gTUFDIGlzIGRlZmluZWQgdmVy eSBzcGVjaWZpY2FsbHkgYXMgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2UgdGhhdCB0 aGUgcm91dGVyIGlzIHVzaW5nIGZvciB0aGUgVENQIHNlc3Npb24gdG8gdGhlIGxvY2FsIG1vZGVt LiAgVGhlIHJvdXRlciBtYXkgaGF2ZSBhIGJpbGxpb24gb3RoZXIgTUFDIGFkZHJlc3NlcywgYnV0 IG9ubHkgdGhhdCBvbmUgaXMgaW1wb3J0YW50LiAgSW4gdGhlID5zcG9rZSBjYXNlLCB0aGUgc2Ft ZSBhcHBsaWVzLCBhbmQgaWYgdGhlIHNwb2tlcyBkb24ndCBuZWVkIHRvIGtub3cgYWJvdXQgb3Ro ZXIgc3Bva2VzLCBkb24ndCB0ZWxsIHRoZW0uDQoNCkhvbGQgb24uICBJIHRob3VnaHQgaXQgd2Fz IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgZmFyIHNpZGUgcm91dGVyIChvdGhlcndpc2UgaXQgd291 bGQgc3RpbGwgbmVlZCB0byBhcnApLiAgWW91ciBjb21tZW50IC0tLSB0aGUgTE9DQUwgbW9kZW0g d291bGQgZ3JlYXRseSBjaGFuZ2UgdGhlIGlzc3VlIGluIG15IG1pbmQgLS0tIGJ1dCBob3cgZG9l cyBrbm93aW5nIGEgbG9jYWwgTUFDIGhlbHAgTDMgY29udmVyZ2UgYW55IGZhc3RlciAtIHRoYXQg d291bGQgbWVhbiBpdCBzdGlsbCBuZWVkcyB0byBhcnAgb3IgbWNhc3QgaGVsbG8gdG8gZmluZCBm YXIgc2lkZSBndXlzIHNvIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZW4gaG93IHRoZSAnZmFzdC1z dGFydCcgc3R1ZmYgd29ya3MgeW91IHdlcmUgZGlzY3Vzc2luZyBhcyB0aGUgcG9pbnQgb2YgdGhp cy4uLi4uDQoNCkluIHRoaXMgZGlhZ3JhbSBiZWxvdzoNCg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfC0tLS0tICBNRE0xIC0tLS0gUlRSMSAtLS0gTkVUMQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNClVwUnRyIC0tLS0tICAgU2F0SFVCICAgLS0tLS0tICBPVVRFUlNQQUNFIC0tLS0t LS0tLS0gICBNRE0yIC0tLS0gUlRSMiAtLS0gTkVUMg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0gIE1ETTMgLS0tLSBSVFIzIC0tLSBO RVQzDQoNCg0KTGV0J3Mgc2F5IFJUUjEsIFJUUjIsIGFuZCBSVFIzIGFsbCB3YW50IHRvIG1ha2Ug YSBbT1NQRnxFSUdSUHxCR1BdIG5laWdoYm9yIHRvIFVwUlRSLiAgVVBSVFIgd2FudHMgMyBuZWln aGJvcnMuICBUaGVyZSBhcmUgMiB2bGFucyBvbiBlYWNoLg0KDQpXaGF0IGRvZXMgTURNWCBoYXZl IHRvIHRlbGwgUlRSWCB2aWEgRExFUD8gICBIb3cgbWFueSBNQUMgQWRkcmVzc2VzIChNdWx0aXBs ZSBWTEFOUykgYW5kIHdoaWNoIG9uZXM/DQoNCg0KTm93IHdoYXQgaWYgd2hpbGUgdGhlIFJGIHN5 c3RlbSBpcyBub3QgTUVTSCwgSSBhbSBhbGxvd2luZyBoYWlycGlubmluZyAoVlBMUyBtb2RlKS4u Li4gU28gTkVUMSBjYW4gdGFsayB0byBORVQyIHZpYSBTYXRIVUIuICBUaGVuIHdoYXQgZG8gdGhl eSBhbGwgaGF2ZSBsZWFybj8NCg0KDQoNCk1heWJlIGEgY29uY3JldGUgZXhhbXBsZSB3aWxsIGhl bHAgdGhpcyBzaW5rIGluLg0KDQpUaGFua3MsDQpCcmlhbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNv ZnR3YXJlLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTA6MjkgQU0NClRvOiBT bnlkZXIsIEJyaWFuOyBIZW5uaW5nIFJvZ2dlDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6 IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVANCg0KSW5saW5lIGNvbW1l bnRzLi4uLg0KDQo+PkFzIEkgc2VlIGl0LCB5b3VyIHByb2JsZW0gaXMgYWxvbmcgdGhlIGxpbmVz IG9mICJPTUcsIEkgaGF2ZSAxMCwwMDAncyBzcG9rZXMgYW5kIEkgY2FuJ3QgaGF2ZSBhIG1hc3Rl ciBsaXN0IG9mIHNwb2tlIHJvdXRlciBNQUNzLCBhbmQgSSBkb24ndCB3YW50IHRvIHJlcG9ydCAx MCwwMDAncyBETEVQIHNlc3Npb25zIGV2ZXJ5d2hlcmUgd2hlbiBzcG9rZXMgY2FuIHJlYWxseSBv bmx5IHRhbGsgdG8gdGhlIGh1YiIuICBBbmQgbXkgYW5zd2VyIGlzLCAiWW91IGRvbid0IGhhdmUg dG8gcmVwb3J0IGV2ZXJ5dGhpbmcsIGFsbCB0aGUgdGltZSwgYW5kIHlvdSBjYW4gbGVhcm4gdGhl IE1BQ3MgYXQgcnVudGltZS4iDQoNCj5ZZXMsIHRoYXQgaXMgYSBjb25jZXJuIG9mIG1pbmUuLi4g YnV0IG5vdCB0aGUgb25seSBvbmUuICBJIHVuZGVyc3RhbmQgSSBvbmx5IGhhdmUgdG8gcmVwb3J0 IHdoYXQgSSB3YW50IHRvbyBidXQgSSdtIGFsc28gY29uY2VybmVkIHdpdGggdGhlIG5vdGlvbiBJ IGNhbiBhdXRvLWxlYXJuIGl0LiAgSG93IHdvdWxkIEkga25vdywgaW4gYSBWUExTIG5ldHdvcmsg d2hpY2ggbWFjIGlzIHRoZSB1cHN0cmVhbSByb3V0ZXI/IEkgY291bGQgYmUgaW51bmRhdGVkIHdp dGggTUFDcyBmcm9tIGFsbCBvdmVyIHRoZSBuZXR3b3JrLiBNYXliZSBzb21lIEknZCBjYXJlIGFi b3V0IGFuZCBzb21lIEkgd291bGRuJ3QuICBCdXQgSSBjZXJ0YWlubHkgY291bGRuJ3QgdHJhY2sg dGhlbSBpbmRpdmlkdWFsbHkuIEkgaGF2ZSBubyBpZGVhIG9mIGFub3RoZXIgbW9kZW1zIHN0YXRl LiAgSSBvbmx5IGtub3cgTVkgc3RhdGUgaW4gcmVsYXRpb24gdG8gdGhlIGh1YiAtIElFOiBhbSBJ IGluIG5ldHdvcmsgb3Igbm90LiAgQWxzbyByZWNvZ25pemUgdGhhdCBpZiBJIGhhdmUgYSBodW5k cmVkIHRob3VzYW5kIE1BQyBhZGRyZXNzZXMgYW5kIEkgaGFkIHRvIHRyYWNrIHRoZW0gYWxsIC0t IHdlbGwgYSBjb21tb24gZGVzaWduIHdpdGggb3VyIG5ldHdvcmtzIGlzIGZvciBwZW9wbGUgdG8g dXNlIG11bHRpcGxlIFNWTnMgKHZsYW5zL3FpbnFzKSB0YWdzIFBFUiBtb2RlbS4gIE1hbnkgZGVz aWducyBoYXZlIDEyIGVhY2guIE91ciBuYW1lc3BhY2VzIGFyZSBrZXB0IHNlcGFyYXRlbHkuLi4u IHNvIGEgaHVuZHJlZCB0aG91c2FuZCBtb2RlbXMgd2l0aCAxMiB2bGFucyB3b3VsZCBiZSAxLjIg TUlMTElPTiBtYWNzIHRoYXQgY291bGQgcG90ZW50aWFsbHkgYmUgc2Vlbi4NCg0KQWgtaGEhISBU aGUgRExFUCBkZXN0aW5hdGlvbiBNQUMgaXMgZGVmaW5lZCB2ZXJ5IHNwZWNpZmljYWxseSBhcyB0 aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGludGVyZmFjZSB0aGF0IHRoZSByb3V0ZXIgaXMgdXNpbmcg Zm9yIHRoZSBUQ1Agc2Vzc2lvbiB0byB0aGUgbG9jYWwgbW9kZW0uICBUaGUgcm91dGVyIG1heSBo YXZlIGEgYmlsbGlvbiBvdGhlciBNQUMgYWRkcmVzc2VzLCBidXQgb25seSB0aGF0IG9uZSBpcyBp bXBvcnRhbnQuICBJbiB0aGUgc3Bva2UgY2FzZSwgdGhlIHNhbWUgYXBwbGllcywgYW5kIGlmIHRo ZSBzcG9rZXMgZG9uJ3QgbmVlZCB0byBrbm93IGFib3V0IG90aGVyIHNwb2tlcywgZG9uJ3QgdGVs bCB0aGVtLg0KDQo+IEdyYW50ZWQsIEkgZG9u4oCZdCB0aGluayB0aGF0IHNjYWxlIGlzIGdvaW5n IHRvIGJlIHJvbGwgb3V0ICMxIG9mIERMRVAgdXNlIGNhc2UgLSBidXQgd2UgZG8gaGF2ZSBjdXN0 b21lcnMgb3BlcmF0aW5nIGF0IHRoYXQgc2NhbGUuICBJZiAnRExFUCcgZmVhdHVyZSBnZXRzIHJl bGVhc2VkIC0gdGhleSB3aWxsIHdhbnQgdG8gdXNlIGl0Lg0KDQpBYnNvbHV0ZWx5LCB3aGljaCBp cyB3aHkgSSBhbmQgb3RoZXJzIGFyZSBzcGVuZGluZyBzb21lIGN5Y2xlcyB0byBnZXQgdGhpcyBz b3J0ZWQuDQoNCj4gTm8gbW9kZW0gY3VycmVudGx5IHRyYWNrcyBhbnkgTUFDcyBmcm9tIHRoZSBo dWIgc2lkZSBmb3IgdGhpcyByZWFzb24gLS0gYW5kIHdlIGRvbid0IG5lZWQgdG9vICh5ZXQ6KSku DQoNCkhvcGVmdWxseSBteSBhbnN3ZXIgYWJvdmUgd2lsbCBoYXZlIGhlbHBlZD8NCg0KUmljaw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljayBUYXlsb3IgW21haWx0bzpy aWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb21dDQpTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIw MTQgMTA6MDUgQU0NClRvOiBTbnlkZXIsIEJyaWFuOyBIZW5uaW5nIFJvZ2dlDQpDYzogbWFuZXRA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERM RVANCg0KVG9wLXBvc3RlZC4uLg0KDQpTb3JyeSBCcmlhbiwNCg0KSSB0aGluayBteSB1bmRlcnN0 YW5kaW5nIG9mIHlvdXIgcHJvYmxlbSBtaWdodCBzdGlsbCBiZSB3cm9uZywgYnV0IEknbGwgbWFr ZSBzb21lIHN1Z2dlc3Rpb25zIGFueXdheS4uLg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBwcmVjb25m aWd1cmUgdGhlIHNwb2tlIHJvdXRlciBNQUMgdGhhdCBnZXRzIHNlbnQgdG8gdGhlIGh1YiBiZWNh dXNlIHlvdSBjYW4gbGVhcm4gaXQgZnJvbSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBzcG9rZSBETEVQ IHNlc3Npb24uICBUaGVuIHdoZW4gYW4gUkYgbGluayBpcyBlc3RhYmxpc2hlZCwgeW91IHNlbmQg aXQgdXAgdG8gdGhlIGh1YiwgYW5kIGl0IGNhbiByZXBvcnQgaXQgdGhyb3VnaCBpdCdzIGxvY2Fs IERMRVAgc2Vzc2lvbiwgYW5kIHZpY2UtdmVyc2EuDQoNCllvdSBkb24ndCBuZWVkIHRvIHJlcG9y dCBhbGwgZGVzdGluYXRpb25zIGluIGFsbCBzZXNzaW9ucywgb25seSByZWxldmFudCBkZXN0aW5h dGlvbnMuICBTbyBpbiB0aGUgc3Bva2UgbW9kZW0sIHlvdSBvbmx5IG5lZWQgdG8gcmVwb3J0IHRo ZSBodWIgTUFDIGluIHRoZSBjb21tb24gY2FzZSwgdW5sZXNzIHlvdSBoYXZlIHR1cm5lZCBvbiBo YWlyLXBpbm5pbmcgZm9yIHNvbWUgc3Vic2V0IG9mIHNwb2tlcywgaW4gd2hpY2ggY2FzZSB5b3Ug b25seSBuZWVkIHRvIHJlcG9ydCB0aG9zZSBhZGRyZXNzYWJsZSBNQUNzIGFzIERMRVAgZGVzdGlu YXRpb25zLg0KDQpBcyBJIHNlZSBpdCwgeW91ciBwcm9ibGVtIGlzIGFsb25nIHRoZSBsaW5lcyBv ZiAiT01HLCBJIGhhdmUgMTAsMDAwJ3Mgc3Bva2VzIGFuZCBJIGNhbid0IGhhdmUgYSBtYXN0ZXIg bGlzdCBvZiBzcG9rZSByb3V0ZXIgTUFDcywgYW5kIEkgZG9uJ3Qgd2FudCB0byByZXBvcnQgMTAs MDAwJ3MgRExFUCBzZXNzaW9ucyBldmVyeXdoZXJlIHdoZW4gc3Bva2VzIGNhbiByZWFsbHkgb25s eSB0YWxrIHRvIHRoZSBodWIiLiAgQW5kIG15IGFuc3dlciBpcywgIllvdSBkb24ndCBoYXZlIHRv IHJlcG9ydCBldmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUsIGFuZCB5b3UgY2FuIGxlYXJuIHRoZSBN QUNzIGF0IHJ1bnRpbWUuIg0KDQpDaGVlcnMsDQpSaWNrDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IFNueWRlciwgQnJpYW4gW2JzbnlkZXJAaWRpcmVj dC5uZXRdDQpTZW50OiAyNSBKdWx5IDIwMTQgMTQ6MzcNClRvOiBIZW5uaW5nIFJvZ2dlDQpDYzog UmljayBUYXlsb3I7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW21hbmV0XSBSZXF1ZXN0 IHRvIGNvbnNpZGVyIGZvciBETEVQDQoNCkVtYmVkZGVkLi4uLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21d DQpTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMjozNiBBTQ0KVG86IFNueWRlciwgQnJpYW4N CkNjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJl cXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVANCg0KT24gRnJpLCBKdWwgMjUsIDIwMTQgYXQgMTI6 NTEgQU0sIFNueWRlciwgQnJpYW4gPGJzbnlkZXJAaWRpcmVjdC5uZXQ+IHdyb3RlOg0KPiBbQlNT XSDigJMgQW5kIEkgZ3Vlc3MgSSBhbSBsb29raW5nIGZvciBzb21ldGhpbmcgZGlmZmVyZW50LiAg SeKAmW0gbG9va2luZyBmb3IgbGluayBzdGF0ZSBub3RpZmljYXRpb25zICh3aXRoIG1ldHJpY3Mp IHRvICAtIGFuZCB0aGlzIGlzIGEgZGlmZmVyZW50ICMyIOKAkyBhbGxvdyBhIHJvdXRpbmcgcHJv dG9jb2wgdG8gYmUgdHVuZWQgZm9yIG1pbmltdW0gS0VFUCBBTElWRSB0aW1lcnMgdG8gbWluaW1p emUgYmFuZHdpZHRoIHVzYWdlIHRvIGNvbnNlcnZlIHZlcnkgZXhwZW5zaXZlIGFuZCBsaW1pdGVk IGJhbmR3aWR0aC4gIEluIGEgc2F0ZWxsaXRlIG5ldHdvcmssIHRoZXJlIGlzIG5vIG5lZWQgZm9y IGZhc3Qtc3RhcnRzLCBMMSBjb252ZXJnZW5jZSBjYW4gKGFuZCBpbiBhIHN1aXRhYmx5IHNpemVk IG5ldHdvcmsgd2lsbCB0YWtlIHNlY29uZHMpLiAgSG93ZXZlciwgYmVjYXVzZSBtb2RlbXMgdGVu ZCB0byBzdGF5IGluIG5ldHdvcmsgcXVpdGUgc3RhYmx5ICh0cmVlcyBhbmQgYnVpbGRpbmdzIGRv buKAmXQgZ2V0IHRoZSB3YXkgb2Z0ZW4gaW4gdGhlIG9jZWFu4pi6KSwgdGhlIGJ1aWxkaW5nIG9m IGFkamFjZW5jaWVzIGRvZXMgbm90IGhhcHBlbiBhbGwgdGhhdCBvZnRlbi4gSXTigJlzIHdheSBt b3JlIGltcG9ydGFudCB0byBtZSB0byBjb25zZXJ2ZSBiYW5kd2lkdGggYW5kIGJlIHRyYW5zcGFy ZW50Lg0KDQpJIG11c3QgYWRtaXQgSSBzdGlsbCBmYWlsIHRvIHNlZSB3aHkgYSBzcGVjaWFsIGNh c2UgaXMgZXZlbiBuZWNlc3NhcnkuDQoNCltCU1NdIC0gUGVyaGFwcyBub3QgbmVjZXNzYXJ5IC0g YnV0IEknbSB2ZXJ5IGNvbmNlcm5lZCB3aXRoIHRyeWluZyB0byBvcHRpbWl6ZSBmb3Igc2NhbGUg YW5kIHRyYW5zcGFyZW5jeS4NCg0KV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBuZXR3b3JrIHdpdGgg aHVuZHJlZCB0aG91c2FuZHMgY2xpZW50cyBjb25uZWN0ZWQgdmlhIHNhdGVsbGl0ZSB0byBhIEh1 YiBzdGF0aW9uLiBZZXMsIHNvIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudHMg ZG9uJ3QgdGFsayBtb3JlIHRoYW4gbmVjZXNzYXJ5Lg0KDQpCdXQgeW91IHNhaWQgeW91ciBjbGll bnQgc2F0ZWxsaXRlIG1vZGVtcyBhcmUgYWJsZSB0byByZWNlaXZlIGJyb2FkY2FzdCB0cmFmZmlj Li4uIGFuZCBtYXliZSBldmVuIHVuaWNhc3RzIGRlbGl2ZXJlZCB0byBhIGRpZmZlcmVudCBjbGll bnQuIFRoaXMgbWVhbnMgcHVzaGluZyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBIdWIgdG8gYWxsIGNs aWVudHMgaXMgcmVhc29uYWJsZSBjaGVhcC4NCltCU1NdIC0gVGhleSB3b24ndCByZWNlaXZlIHVu aWNhc3QgZm9yIHNvbWVvbmUgZWxzZS4gIEhETEMgYWRkcmVzc2luZyBkZW11eGVzIHRoYXQuICBQ dXNoaW5nIGJyb2FkY2FzdCBpcyBjaGVhcC4gIElFOiBBUlBzIGNhbiBmbG93IGZyZWVseSBhbmQg Y2hlYXBseSBvbiB0aGUgZG93bnN0cmVhbS4NCg0KVGhpcyBtZWFucyB0cmFuc2ZlcnJpbmcgdGhl IE1hYyBhZGRyZXNzIHRvIGEgY2xpZW50IGlzIGRpcnQgY2hlYXAsIGVzcGVjaWFsbHkgaWYgTGF5 ZXItMiBhdCB0aGUgSHViIGlzIGFibGUgdG8gdGVsbCB0aGF0IGEgbmV3IGNsaWVudCBjb25uZWN0 ZWQgdG8gdGhlIHNhdGVsbGl0ZS4NCltCU1NdIC0gSW4gdGhpcyBjYXNlIHRyYW5zZmVycmluZyBh IG1hYyBhZGRyZXNzIGlzIGNoZWFwIC0gdGhlIGFycCdzIGRvIGl0IHRocm91Z2ggdXMgLS0gdGhv dWdoIHRoZSBtb2RlbXMgY3VycmVudGx5IGRvbid0IHRyYWNrIGFuZCByZWNvcmQgYW55IG9mIHRo ZSBsZWFybnQgYWRkcmVzcyBPVEEuLi4gd2UganVzdCBsZXQgdGhlIGN1c3RvbWVyIGRldmljZXMg ZG8gd2hhdCB0aGV5IHNob3VsZCBkbyBieSBhbGwgbm9ybWFsIGNvbnZlbnRpb25zLiAoQVJQLCB0 aW1lcnMsIGV0YykuICBNb2RlbXMgaGF2ZSBubyBub3Rpb24gb2Ygd2VhdGhlciBvciBub3QgYW5v dGhlciBtb2RlbSBpcyBpbiBvciBvdXQgb2YgbmV0d29yay4gIE5vIHN0YXIgc3lzdGVtIHdvdWxk LiBUaGV5IGp1c3QgdHJhY2sgdGhlbXNlbHZlcy4gU28gaWYgTUFDIGFkZHJlc3NlcyBhcmUgc3Vw cG9zZWQgdG8gYmUgc3RvcmVkIGFuZCBtYW5hZ2VkIGJ5IHRoZSBtb2RlbSBmb3IgRExFUCBtYW5h Z2VtZW50IGF1dG9tYXRpY2FsbHksIHdlIGEpIGFyZW4ndCB0cmFuc3BhcmVudCBhbnltb3JlIGIp IEhhdmUgYSBzY2FsZSBwcm9ibGVtIG1hbmFnaW5nIGFsbCB0aG9zZSBtYWNzIGMpIElmIHRoZXJl IGFyZSBtb3JlIG1hYyBhZGRyZXNzZXMgKG5vdCByb3V0ZXJzIHdlIHdvdWxkIGNhcmUgYWJvdXQg dmlhIGRsZXApIGhvdyBpcyBhIHRyYW5zcGFyZW50IHN3aXRjaCBzdXBwb3NlZCB0byAiS05PVyIg d2hpY2ggbWFjIGFkZHJlc3MgaXMgdGhlIHNwZWNpYWwgb25lIHRoYXQgc2hvdWxkIGJlICdzZXR1 cCcgYXMgdGhlIGRsZXAgdGFyZ2V0LiAgSSB0aGluayB0aGF0IHdvdWxkIHJlcXVpcmUgc29tZSBz cGVjaWFsIGNvbmZpZyB0aGF0IHRoZW4gaGFzIHRvIGJlIG1hbmFnZWQgKGFsc28gYnJlYWtpbmcg dHJhbnNwYXJlbmN5KSBhbmQgY3JlYXRpbmcgT0FNIGFuZCBjaGFuZ2UgbWFuYWdlbWVudCBpc3N1 ZXMuIFJlbWVtYmVyIHRoZSBMQU4gaXMgbm90ICdvdXInIGVxdWlwbWVudCwgc28gYWxsIHRoZSBz dWRkZW4gb25lIHdvdWxkIGhhdmUgdG8gZ2V0IGFuZCBtYW5hZ2UgbWFjIGFkZHJlc3NlcyBmb3Ig YWxsIHRoZXNlIHNpdGVzLiAgV2UgYXJlIGdvaW5nIEwyIGluLW9yZGVyIHRvIGhlbHAgdXMgYW5k IG91ciBjbGllbnRzIG5vdCB3b3JyeSBhYm91dCBlYWNoIG90aGVyJ3MgZXF1aXBtZW50IGFuZCBu ZXR3b3JraW5nLg0KDQoNCldoYXQgaXMgdGhlIHR5cGljYWwgdXB0aW1lIG9mIGEgY2xpZW50PyBB bmQgd2hhdCBwZXJjZW50YWdlIG9mIHRyYWZmaWMgZ29lcyBmcm9tIHRoZSBIdWIgdG8gdGhlIGNs aWVudHM/IEEgcm91Z2ggZ3Vlc3Mgd291bGQgYmUgZ3JlYXQgdG8gYmV0dGVyIHVuZGVyc3RhbmQg eW91ciBwcm9ibGVtLg0KW0JTU10gLSBUeXBpY2FsIHVwdGltZSB3b3VsZCBiZSBtZWFzdXJlZCBp biBmcm9tIGhvdXJzIChNYXliZSBhIHBsYW5lIG1vdmluZyBhY3Jvc3Mgc2F0ZWxsaXRlIGZvb3Rw cmludHMpIHRvIGhvcGVmdWxseSB5ZWFycyAtIGEgc3RhdGlvbmFyeSBtb2RlbS4gIFRob3VnaCBw cmFjdGljYWxseSB0aGF04oCZcyBtYXliZSBtb3JlIG5vcm1hbGx5IG1vbnRocyBkdWUgdG8gd2Vh dGhlciwgdXBncmFkZXMsIGV0Yy4NCg0KSGVubmluZyBSb2dnZQ0K From nobody Fri Jul 25 09:25:25 2014 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 AC9C91B2925 for ; Fri, 25 Jul 2014 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 O0tyeHeP9WVm for ; Fri, 25 Jul 2014 09:25:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137BB1B291D for ; Fri, 25 Jul 2014 09:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2951; q=dns/txt; s=iport; t=1406305520; x=1407515120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uF5PVUmHp0tvxj6bdm2zztJedM1Lsk6rf51JCtOKzs0=; b=GkNJ2/LPhMTwF2X2QSSh9Kmhw3nLwOQJA5OV0UpNMFBOE78rMxqrTlxM vKMXzgH9tAT0CEqjmqPXoeih5jhvGl3g7AOsyCP0I6NGh+58ENiqaVtHU AK4+d1pkaobtAZOm4wO26zW0vP5qyTs2qdf1tHiYYslX+j1S9bX44ZvDS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAM+D0lOtJA2G/2dsb2JhbABZgw6BKQTRUwGBEBZ3hAMBAQEDATo/BQcEAgEIEQQBAR8JBzIUCQgCBA4FGYghCL8WF45pEQEdMwcGgyiBGwWbR5RKg0hsgQw5 X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="342939972" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jul 2014 16:25:19 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6PGPJqo004797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 16:25:19 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 11:25:18 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] DLEP/satellite - default destination Thread-Index: AQHPp/0vyyEmY0/pD0WqQM1esuMWZpuxJnEAgAAncQA= Date: Fri, 25 Jul 2014 16:25:18 +0000 Message-ID: References: <20140725114000.GB7355@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343046909@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343046909@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B0A7F23A384AC4CBA38144D96690A84@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bZt64Lug0uvJ1f5ILyY8dq9QO2Y Cc: "manet@ietf.org" Subject: Re: [manet] DLEP/satellite - default destination 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, 25 Jul 2014 16:25:21 -0000 Again, I'm completely and totally confused by this entire thread.=20 For purposes of a DLEP discussion, I fail to see why the spoke side of SATC= OM is nothing more than a subset of MESH. Essentially, it's a mesh with 1 d= estination - the hub. In an earlier email on this thread, the claim was mad= e that DLEP wasn't designed for this case - I disagree. I think it will wor= k just fine.=20 Regards, Stan On Jul 25, 2014, at 10:04 AM, "Snyder, Brian" wrote: > I would expect (ideally) the hello timers on the inroute are rather high = and the therefore the hello timer from the one upstream router (that is adv= ertising on the outroute) to be fairly low. So mostly all sessions will ge= t establshied based on seeing the every couple seconds hello from the outro= ute. Convergence will then kick off - but that has to happen anyway so the= re is no 'extra cost' or way to minimize that (and should be fairly infrequ= ent anyway). So yes I think you summarized my main ask - have some way (sp= ecial mac or tlv) to signify to a router that this dlep session is a 'defau= lt route' and just go ahead and act normally.... arp for a configured unica= st router or send -or- receive a multicast hello via an IGP. >=20 > brian >=20 > -----Original Message----- > From: Toerless Eckert [mailto:eckert@cisco.com]=20 > Sent: Friday, July 25, 2014 7:40 AM > To: Snyder, Brian > Cc: manet@ietf.org; Stan Ratliff (sratliff) > Subject: Re: [manet] DLEP/satellite - default destination >=20 > Point 2: I am assuming the Satellite network is supporting ethetnet multi= cast/broadcast. If the DLEP modems of spokes do not indicate all other spok= es as destinations with their MAC and IP addresses, then the spoke routers = need to just do normal ARP. >=20 > Now hub and spoe routers run some IGP. And the IGP has some hellos. > And hellos from 2000 spokes are a relevant upstream bandwidth cost. > Would actually be nice to have an actual example calculation what percent= age of upstream bandwidth cost we are talking about. >=20 > So, DLEP to the rescue. But without DLEP having to indicate all hub & spo= kes as destinations with MAC and IP. So... what is the logic: >=20 > Hub and spokes send hellos very infrequently an use DLEP as an indication= for the neighbors to be still alive. For the spokes we introduce one new m= agic DLEP destination to indicate "all neighbors are alive" because it simp= lifies the life of the RF network operator that ould otherwise have to do m= ore provisioning such as eg: hub router MAC address provisioning into spoke= modems. Or incurring a longer startup time to dynamically signal this to s= poke modems via RF magic. >=20 > And the question is now just how to encode that magic destination in DLEP= . MAC broadcast may not be ideal, but maybe some othrer magic DMAC. All 0 ?= . >=20 > Is this correctly summarizing the ask ?=20 From nobody Fri Jul 25 09:30:11 2014 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 1597F1B295F for ; Fri, 25 Jul 2014 09:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 n6IKsYnNjP9q for ; Fri, 25 Jul 2014 09:30:06 -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 B5BE31B2928 for ; Fri, 25 Jul 2014 09:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13646; q=dns/txt; s=iport; t=1406305806; x=1407515406; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q83fFcYY7zhHJcwSV45/+gVq7EyYd3EKBLTgGzO1rBY=; b=PRmwFz8Iv6cSR3fjOuOzl+hSacyMJ3WSuRH68yThmWpqW7PfA3AbVmM2 yJ6uLIDN2HOJGl8Pm/erV0ZEOZbWrU7GEtca5uefZ45UbGCywklQm/OCI ai1MeLegW5fQWhGhQhOFh/rTilITBi3kW76rdHwwfwrRZbhd/J/cox3Hp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFALGF0lOtJA2L/2dsb2JhbABZgw5SVwSCdMcQCodFARl3FneEAwEBAQMBAQEBIBE6BAcFBwQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAgQKBAWILgMJCA2ncJAUDYZ8EwSBLIhSgyCBVRYnGwcGgnI2gRsFlyiCHIIDjiiGIoNIbIEDAh4i X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="342870648" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2014 16:30:05 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6PGU5It008245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 16:30:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 11:30:05 -0500 From: "Stan Ratliff (sratliff)" To: "Snyder, Brian" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0AAcwYYAAA64qIAAAPnkAAAAdDsAAABexQAABAnYAAAAMxyA Date: Fri, 25 Jul 2014 16:30:04 +0000 Message-ID: <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="utf-8" Content-ID: <70EED533C5C5FB4F848DAE39B7A8B93F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vDV0ChxzE1oh57SkizmIwao5aek Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 16:30:09 -0000 DQpPbiBKdWwgMjUsIDIwMTQsIGF0IDEyOjI0IFBNLCAiU255ZGVyLCBCcmlhbiIgPGJzbnlkZXJA aWRpcmVjdC5uZXQ+DQogd3JvdGU6DQoNCj4gUmljaywNCj4gDQo+PiBBaC1oYSEhIFRoZSBETEVQ IGRlc3RpbmF0aW9uIE1BQyBpcyBkZWZpbmVkIHZlcnkgc3BlY2lmaWNhbGx5IGFzIHRoZSBNQUMg YWRkcmVzcyBvZiB0aGUgaW50ZXJmYWNlIHRoYXQgdGhlIHJvdXRlciBpcyB1c2luZyBmb3IgdGhl IFRDUCBzZXNzaW9uIHRvIHRoZSBsb2NhbCBtb2RlbS4gIFRoZSByb3V0ZXIgbWF5IGhhdmUgYSBi aWxsaW9uIG90aGVyIE1BQyBhZGRyZXNzZXMsIGJ1dCBvbmx5IHRoYXQgb25lIGlzIGltcG9ydGFu dC4gIEluIHRoZSA+c3Bva2UgY2FzZSwgdGhlIHNhbWUgYXBwbGllcywgYW5kIGlmIHRoZSBzcG9r ZXMgZG9uJ3QgbmVlZCB0byBrbm93IGFib3V0IG90aGVyIHNwb2tlcywgZG9uJ3QgdGVsbCB0aGVt Lg0KPiANCj4gSG9sZCBvbi4gIEkgdGhvdWdodCBpdCB3YXMgdGhlIE1BQyBhZGRyZXNzIG9mIHRo ZSBmYXIgc2lkZSByb3V0ZXIgKG90aGVyd2lzZSBpdCB3b3VsZCBzdGlsbCBuZWVkIHRvIGFycCku ICBZb3VyIGNvbW1lbnQgLS0tIHRoZSBMT0NBTCBtb2RlbSB3b3VsZCBncmVhdGx5IGNoYW5nZSB0 aGUgaXNzdWUgaW4gbXkgbWluZCAtLS0gYnV0IGhvdyBkb2VzIGtub3dpbmcgYSBsb2NhbCBNQUMg aGVscCBMMyBjb252ZXJnZSBhbnkgZmFzdGVyIC0gdGhhdCB3b3VsZCBtZWFuIGl0IHN0aWxsIG5l ZWRzIHRvIGFycCBvciBtY2FzdCBoZWxsbyB0byBmaW5kIGZhciBzaWRlIGd1eXMgc28gSSBkb27i gJl0IHVuZGVyc3RhbmQgdGhlbiBob3cgdGhlICdmYXN0LXN0YXJ0JyBzdHVmZiB3b3JrcyB5b3Ug d2VyZSBkaXNjdXNzaW5nIGFzIHRoZSBwb2ludCBvZiB0aGlzLi4uLi4NCj4gDQo+IEluIHRoaXMg ZGlhZ3JhbSBiZWxvdzoNCj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0g IE1ETTEgLS0tLSBSVFIxIC0tLSBORVQxDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g VXBSdHIgLS0tLS0gICBTYXRIVUIgICAtLS0tLS0gIE9VVEVSU1BBQ0UgLS0tLS0tLS0tLSAgIE1E TTIgLS0tLSBSVFIyIC0tLSBORVQyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tICBNRE0zIC0tLS0gUlRSMyAtLS0gTkVUMw0KPiAN Cj4gDQo+IExldCdzIHNheSBSVFIxLCBSVFIyLCBhbmQgUlRSMyBhbGwgd2FudCB0byBtYWtlIGEg W09TUEZ8RUlHUlB8QkdQXSBuZWlnaGJvciB0byBVcFJUUi4gIFVQUlRSIHdhbnRzIDMgbmVpZ2hi b3JzLiAgVGhlcmUgYXJlIDIgdmxhbnMgb24gZWFjaC4NCg0KKkJ5IGRlZmluaXRpb24qLCBVcFJ0 ciBpbiB0aGlzIGNhc2UgaGFzIDYgbmVpZ2hib3JzLCBub3QgMy4gRWFjaCBWTEFOIGlzIGEgbmVp Z2hib3IuDQoNCj4gDQo+IFdoYXQgZG9lcyBNRE1YIGhhdmUgdG8gdGVsbCBSVFJYIHZpYSBETEVQ PyAgIEhvdyBtYW55IE1BQyBBZGRyZXNzZXMgKE11bHRpcGxlIFZMQU5TKSBhbmQgd2hpY2ggb25l cz8NCg0KVGhhdCdzIHRoZSBydWIuIE1ETTEsIGZvciBleGFtcGxlLCBjYW4gdGVsbCBSVFIxICpv bmx5KiBhYm91dCBVcFJ0ci4gKFNwZWNpZmljYWxseSwgdGhlIFZMQU5TIG9uIFVwUnRyKS4gU28s IHdoaWxlIFVwUnRyIGhhcyA2IG5laWdoYm9ycyAoYnV0IHdlJ3ZlIGFscmVhZHkgc2FpZCB0aGUg aHViIGlzbid0IHRoZSBwcm9ibGVtKSwgUlRSMSBvbmx5IHNlZXMgMi4gDQoNClN0YW4NCg0KDQo+ IA0KPiANCj4gTm93IHdoYXQgaWYgd2hpbGUgdGhlIFJGIHN5c3RlbSBpcyBub3QgTUVTSCwgSSBh bSBhbGxvd2luZyBoYWlycGlubmluZyAoVlBMUyBtb2RlKS4uLi4gU28gTkVUMSBjYW4gdGFsayB0 byBORVQyIHZpYSBTYXRIVUIuICBUaGVuIHdoYXQgZG8gdGhleSBhbGwgaGF2ZSBsZWFybj8NCj4g DQo+IA0KPiANCj4gTWF5YmUgYSBjb25jcmV0ZSBleGFtcGxlIHdpbGwgaGVscCB0aGlzIHNpbmsg aW4uDQo+IA0KPiBUaGFua3MsDQo+IEJyaWFuDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogUmljayBUYXlsb3IgW21haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1z b2Z0d2FyZS5jb21dIA0KPiBTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTA6MjkgQU0NCj4g VG86IFNueWRlciwgQnJpYW47IEhlbm5pbmcgUm9nZ2UNCj4gQ2M6IG1hbmV0QGlldGYub3JnDQo+ IFN1YmplY3Q6IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVANCj4gDQo+ IElubGluZSBjb21tZW50cy4uLi4NCj4gDQo+Pj4gQXMgSSBzZWUgaXQsIHlvdXIgcHJvYmxlbSBp cyBhbG9uZyB0aGUgbGluZXMgb2YgIk9NRywgSSBoYXZlIDEwLDAwMCdzIHNwb2tlcyBhbmQgSSBj YW4ndCBoYXZlIGEgbWFzdGVyIGxpc3Qgb2Ygc3Bva2Ugcm91dGVyIE1BQ3MsIGFuZCBJIGRvbid0 IHdhbnQgdG8gcmVwb3J0IDEwLDAwMCdzIERMRVAgc2Vzc2lvbnMgZXZlcnl3aGVyZSB3aGVuIHNw b2tlcyBjYW4gcmVhbGx5IG9ubHkgdGFsayB0byB0aGUgaHViIi4gIEFuZCBteSBhbnN3ZXIgaXMs ICJZb3UgZG9uJ3QgaGF2ZSB0byByZXBvcnQgZXZlcnl0aGluZywgYWxsIHRoZSB0aW1lLCBhbmQg eW91IGNhbiBsZWFybiB0aGUgTUFDcyBhdCBydW50aW1lLiINCj4gDQo+PiBZZXMsIHRoYXQgaXMg YSBjb25jZXJuIG9mIG1pbmUuLi4gYnV0IG5vdCB0aGUgb25seSBvbmUuICBJIHVuZGVyc3RhbmQg SSBvbmx5IGhhdmUgdG8gcmVwb3J0IHdoYXQgSSB3YW50IHRvbyBidXQgSSdtIGFsc28gY29uY2Vy bmVkIHdpdGggdGhlIG5vdGlvbiBJIGNhbiBhdXRvLWxlYXJuIGl0LiAgSG93IHdvdWxkIEkga25v dywgaW4gYSBWUExTIG5ldHdvcmsgd2hpY2ggbWFjIGlzIHRoZSB1cHN0cmVhbSByb3V0ZXI/IEkg Y291bGQgYmUgaW51bmRhdGVkIHdpdGggTUFDcyBmcm9tIGFsbCBvdmVyIHRoZSBuZXR3b3JrLiBN YXliZSBzb21lIEknZCBjYXJlIGFib3V0IGFuZCBzb21lIEkgd291bGRuJ3QuICBCdXQgSSBjZXJ0 YWlubHkgY291bGRuJ3QgdHJhY2sgdGhlbSBpbmRpdmlkdWFsbHkuIEkgaGF2ZSBubyBpZGVhIG9m IGFub3RoZXIgbW9kZW1zIHN0YXRlLiAgSSBvbmx5IGtub3cgTVkgc3RhdGUgaW4gcmVsYXRpb24g dG8gdGhlIGh1YiAtIElFOiBhbSBJIGluIG5ldHdvcmsgb3Igbm90LiAgQWxzbyByZWNvZ25pemUg dGhhdCBpZiBJIGhhdmUgYSBodW5kcmVkIHRob3VzYW5kIE1BQyBhZGRyZXNzZXMgYW5kIEkgaGFk IHRvIHRyYWNrIHRoZW0gYWxsIC0tIHdlbGwgYSBjb21tb24gZGVzaWduIHdpdGggb3VyIG5ldHdv cmtzIGlzIGZvciBwZW9wbGUgdG8gdXNlIG11bHRpcGxlIFNWTnMgKHZsYW5zL3FpbnFzKSB0YWdz IFBFUiBtb2RlbS4gIE1hbnkgZGVzaWducyBoYXZlIDEyIGVhY2guIE91ciBuYW1lc3BhY2VzIGFy ZSBrZXB0IHNlcGFyYXRlbHkuLi4uIHNvIGEgaHVuZHJlZCB0aG91c2FuZCBtb2RlbXMgd2l0aCAx MiB2bGFucyB3b3VsZCBiZSAxLjIgTUlMTElPTiBtYWNzIHRoYXQgY291bGQgcG90ZW50aWFsbHkg YmUgc2Vlbi4NCj4gDQo+IEFoLWhhISEgVGhlIERMRVAgZGVzdGluYXRpb24gTUFDIGlzIGRlZmlu ZWQgdmVyeSBzcGVjaWZpY2FsbHkgYXMgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2Ug dGhhdCB0aGUgcm91dGVyIGlzIHVzaW5nIGZvciB0aGUgVENQIHNlc3Npb24gdG8gdGhlIGxvY2Fs IG1vZGVtLiAgVGhlIHJvdXRlciBtYXkgaGF2ZSBhIGJpbGxpb24gb3RoZXIgTUFDIGFkZHJlc3Nl cywgYnV0IG9ubHkgdGhhdCBvbmUgaXMgaW1wb3J0YW50LiAgSW4gdGhlIHNwb2tlIGNhc2UsIHRo ZSBzYW1lIGFwcGxpZXMsIGFuZCBpZiB0aGUgc3Bva2VzIGRvbid0IG5lZWQgdG8ga25vdyBhYm91 dCBvdGhlciBzcG9rZXMsIGRvbid0IHRlbGwgdGhlbS4NCj4gDQo+PiBHcmFudGVkLCBJIGRvbuKA mXQgdGhpbmsgdGhhdCBzY2FsZSBpcyBnb2luZyB0byBiZSByb2xsIG91dCAjMSBvZiBETEVQIHVz ZSBjYXNlIC0gYnV0IHdlIGRvIGhhdmUgY3VzdG9tZXJzIG9wZXJhdGluZyBhdCB0aGF0IHNjYWxl LiAgSWYgJ0RMRVAnIGZlYXR1cmUgZ2V0cyByZWxlYXNlZCAtIHRoZXkgd2lsbCB3YW50IHRvIHVz ZSBpdC4NCj4gDQo+IEFic29sdXRlbHksIHdoaWNoIGlzIHdoeSBJIGFuZCBvdGhlcnMgYXJlIHNw ZW5kaW5nIHNvbWUgY3ljbGVzIHRvIGdldCB0aGlzIHNvcnRlZC4NCj4gDQo+PiBObyBtb2RlbSBj dXJyZW50bHkgdHJhY2tzIGFueSBNQUNzIGZyb20gdGhlIGh1YiBzaWRlIGZvciB0aGlzIHJlYXNv biAtLSBhbmQgd2UgZG9uJ3QgbmVlZCB0b28gKHlldDopKS4NCj4gDQo+IEhvcGVmdWxseSBteSBh bnN3ZXIgYWJvdmUgd2lsbCBoYXZlIGhlbHBlZD8NCj4gDQo+IFJpY2sNCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJpY2sgVGF5bG9yIFttYWlsdG86cmlja0B0cm9w aWNhbHN0b3Jtc29mdHdhcmUuY29tXQ0KPiBTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTA6 MDUgQU0NCj4gVG86IFNueWRlciwgQnJpYW47IEhlbm5pbmcgUm9nZ2UNCj4gQ2M6IG1hbmV0QGll dGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERM RVANCj4gDQo+IFRvcC1wb3N0ZWQuLi4NCj4gDQo+IFNvcnJ5IEJyaWFuLA0KPiANCj4gSSB0aGlu ayBteSB1bmRlcnN0YW5kaW5nIG9mIHlvdXIgcHJvYmxlbSBtaWdodCBzdGlsbCBiZSB3cm9uZywg YnV0IEknbGwgbWFrZSBzb21lIHN1Z2dlc3Rpb25zIGFueXdheS4uLg0KPiANCj4gWW91IGRvbid0 IG5lZWQgdG8gcHJlY29uZmlndXJlIHRoZSBzcG9rZSByb3V0ZXIgTUFDIHRoYXQgZ2V0cyBzZW50 IHRvIHRoZSBodWIgYmVjYXVzZSB5b3UgY2FuIGxlYXJuIGl0IGZyb20gdGhlIGVuZHBvaW50cyBv ZiB0aGUgc3Bva2UgRExFUCBzZXNzaW9uLiAgVGhlbiB3aGVuIGFuIFJGIGxpbmsgaXMgZXN0YWJs aXNoZWQsIHlvdSBzZW5kIGl0IHVwIHRvIHRoZSBodWIsIGFuZCBpdCBjYW4gcmVwb3J0IGl0IHRo cm91Z2ggaXQncyBsb2NhbCBETEVQIHNlc3Npb24sIGFuZCB2aWNlLXZlcnNhLg0KPiANCj4gWW91 IGRvbid0IG5lZWQgdG8gcmVwb3J0IGFsbCBkZXN0aW5hdGlvbnMgaW4gYWxsIHNlc3Npb25zLCBv bmx5IHJlbGV2YW50IGRlc3RpbmF0aW9ucy4gIFNvIGluIHRoZSBzcG9rZSBtb2RlbSwgeW91IG9u bHkgbmVlZCB0byByZXBvcnQgdGhlIGh1YiBNQUMgaW4gdGhlIGNvbW1vbiBjYXNlLCB1bmxlc3Mg eW91IGhhdmUgdHVybmVkIG9uIGhhaXItcGlubmluZyBmb3Igc29tZSBzdWJzZXQgb2Ygc3Bva2Vz LCBpbiB3aGljaCBjYXNlIHlvdSBvbmx5IG5lZWQgdG8gcmVwb3J0IHRob3NlIGFkZHJlc3NhYmxl IE1BQ3MgYXMgRExFUCBkZXN0aW5hdGlvbnMuDQo+IA0KPiBBcyBJIHNlZSBpdCwgeW91ciBwcm9i bGVtIGlzIGFsb25nIHRoZSBsaW5lcyBvZiAiT01HLCBJIGhhdmUgMTAsMDAwJ3Mgc3Bva2VzIGFu ZCBJIGNhbid0IGhhdmUgYSBtYXN0ZXIgbGlzdCBvZiBzcG9rZSByb3V0ZXIgTUFDcywgYW5kIEkg ZG9uJ3Qgd2FudCB0byByZXBvcnQgMTAsMDAwJ3MgRExFUCBzZXNzaW9ucyBldmVyeXdoZXJlIHdo ZW4gc3Bva2VzIGNhbiByZWFsbHkgb25seSB0YWxrIHRvIHRoZSBodWIiLiAgQW5kIG15IGFuc3dl ciBpcywgIllvdSBkb24ndCBoYXZlIHRvIHJlcG9ydCBldmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUs IGFuZCB5b3UgY2FuIGxlYXJuIHRoZSBNQUNzIGF0IHJ1bnRpbWUuIg0KPiANCj4gQ2hlZXJzLA0K PiBSaWNrDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEZyb206IFNueWRlciwgQnJpYW4gW2JzbnlkZXJAaWRpcmVjdC5uZXRdDQo+IFNlbnQ6IDI1IEp1 bHkgMjAxNCAxNDozNw0KPiBUbzogSGVubmluZyBSb2dnZQ0KPiBDYzogUmljayBUYXlsb3I7IG1h bmV0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIg Zm9yIERMRVANCj4gDQo+IEVtYmVkZGVkLi4uLg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dDQo+ IFNlbnQ6IEZyaWRheSwgSnVseSAyNSwgMjAxNCAyOjM2IEFNDQo+IFRvOiBTbnlkZXIsIEJyaWFu DQo+IENjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYW5l dF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KPiANCj4gT24gRnJpLCBKdWwgMjUsIDIw MTQgYXQgMTI6NTEgQU0sIFNueWRlciwgQnJpYW4gPGJzbnlkZXJAaWRpcmVjdC5uZXQ+IHdyb3Rl Og0KPj4gW0JTU10g4oCTIEFuZCBJIGd1ZXNzIEkgYW0gbG9va2luZyBmb3Igc29tZXRoaW5nIGRp ZmZlcmVudC4gIEnigJltIGxvb2tpbmcgZm9yIGxpbmsgc3RhdGUgbm90aWZpY2F0aW9ucyAod2l0 aCBtZXRyaWNzKSB0byAgLSBhbmQgdGhpcyBpcyBhIGRpZmZlcmVudCAjMiDigJMgYWxsb3cgYSBy b3V0aW5nIHByb3RvY29sIHRvIGJlIHR1bmVkIGZvciBtaW5pbXVtIEtFRVAgQUxJVkUgdGltZXJz IHRvIG1pbmltaXplIGJhbmR3aWR0aCB1c2FnZSB0byBjb25zZXJ2ZSB2ZXJ5IGV4cGVuc2l2ZSBh bmQgbGltaXRlZCBiYW5kd2lkdGguICBJbiBhIHNhdGVsbGl0ZSBuZXR3b3JrLCB0aGVyZSBpcyBu byBuZWVkIGZvciBmYXN0LXN0YXJ0cywgTDEgY29udmVyZ2VuY2UgY2FuIChhbmQgaW4gYSBzdWl0 YWJseSBzaXplZCBuZXR3b3JrIHdpbGwgdGFrZSBzZWNvbmRzKS4gIEhvd2V2ZXIsIGJlY2F1c2Ug bW9kZW1zIHRlbmQgdG8gc3RheSBpbiBuZXR3b3JrIHF1aXRlIHN0YWJseSAodHJlZXMgYW5kIGJ1 aWxkaW5ncyBkb27igJl0IGdldCB0aGUgd2F5IG9mdGVuIGluIHRoZSBvY2VhbuKYuiksIHRoZSBi dWlsZGluZyBvZiBhZGphY2VuY2llcyBkb2VzIG5vdCBoYXBwZW4gYWxsIHRoYXQgb2Z0ZW4uIEl0 4oCZcyB3YXkgbW9yZSBpbXBvcnRhbnQgdG8gbWUgdG8gY29uc2VydmUgYmFuZHdpZHRoIGFuZCBi ZSB0cmFuc3BhcmVudC4NCj4gDQo+IEkgbXVzdCBhZG1pdCBJIHN0aWxsIGZhaWwgdG8gc2VlIHdo eSBhIHNwZWNpYWwgY2FzZSBpcyBldmVuIG5lY2Vzc2FyeS4NCj4gDQo+IFtCU1NdIC0gUGVyaGFw cyBub3QgbmVjZXNzYXJ5IC0gYnV0IEknbSB2ZXJ5IGNvbmNlcm5lZCB3aXRoIHRyeWluZyB0byBv cHRpbWl6ZSBmb3Igc2NhbGUgYW5kIHRyYW5zcGFyZW5jeS4NCj4gDQo+IFdlIGFyZSB0YWxraW5n IGFib3V0IGEgbmV0d29yayB3aXRoIGh1bmRyZWQgdGhvdXNhbmRzIGNsaWVudHMgY29ubmVjdGVk IHZpYSBzYXRlbGxpdGUgdG8gYSBIdWIgc3RhdGlvbi4gWWVzLCBzbyB3ZSBuZWVkIHRvIG1ha2Ug c3VyZSB0aGF0IHRoZSBjbGllbnRzIGRvbid0IHRhbGsgbW9yZSB0aGFuIG5lY2Vzc2FyeS4NCj4g DQo+IEJ1dCB5b3Ugc2FpZCB5b3VyIGNsaWVudCBzYXRlbGxpdGUgbW9kZW1zIGFyZSBhYmxlIHRv IHJlY2VpdmUgYnJvYWRjYXN0IHRyYWZmaWMuLi4gYW5kIG1heWJlIGV2ZW4gdW5pY2FzdHMgZGVs aXZlcmVkIHRvIGEgZGlmZmVyZW50IGNsaWVudC4gVGhpcyBtZWFucyBwdXNoaW5nIGluZm9ybWF0 aW9uIGZyb20gdGhlIEh1YiB0byBhbGwgY2xpZW50cyBpcyByZWFzb25hYmxlIGNoZWFwLg0KPiBb QlNTXSAtIFRoZXkgd29uJ3QgcmVjZWl2ZSB1bmljYXN0IGZvciBzb21lb25lIGVsc2UuICBIRExD IGFkZHJlc3NpbmcgZGVtdXhlcyB0aGF0LiAgUHVzaGluZyBicm9hZGNhc3QgaXMgY2hlYXAuICBJ RTogQVJQcyBjYW4gZmxvdyBmcmVlbHkgYW5kIGNoZWFwbHkgb24gdGhlIGRvd25zdHJlYW0uDQo+ IA0KPiBUaGlzIG1lYW5zIHRyYW5zZmVycmluZyB0aGUgTWFjIGFkZHJlc3MgdG8gYSBjbGllbnQg aXMgZGlydCBjaGVhcCwgZXNwZWNpYWxseSBpZiBMYXllci0yIGF0IHRoZSBIdWIgaXMgYWJsZSB0 byB0ZWxsIHRoYXQgYSBuZXcgY2xpZW50IGNvbm5lY3RlZCB0byB0aGUgc2F0ZWxsaXRlLg0KPiBb QlNTXSAtIEluIHRoaXMgY2FzZSB0cmFuc2ZlcnJpbmcgYSBtYWMgYWRkcmVzcyBpcyBjaGVhcCAt IHRoZSBhcnAncyBkbyBpdCB0aHJvdWdoIHVzIC0tIHRob3VnaCB0aGUgbW9kZW1zIGN1cnJlbnRs eSBkb24ndCB0cmFjayBhbmQgcmVjb3JkIGFueSBvZiB0aGUgbGVhcm50IGFkZHJlc3MgT1RBLi4u IHdlIGp1c3QgbGV0IHRoZSBjdXN0b21lciBkZXZpY2VzIGRvIHdoYXQgdGhleSBzaG91bGQgZG8g YnkgYWxsIG5vcm1hbCBjb252ZW50aW9ucy4gKEFSUCwgdGltZXJzLCBldGMpLiAgTW9kZW1zIGhh dmUgbm8gbm90aW9uIG9mIHdlYXRoZXIgb3Igbm90IGFub3RoZXIgbW9kZW0gaXMgaW4gb3Igb3V0 IG9mIG5ldHdvcmsuICBObyBzdGFyIHN5c3RlbSB3b3VsZC4gVGhleSBqdXN0IHRyYWNrIHRoZW1z ZWx2ZXMuIFNvIGlmIE1BQyBhZGRyZXNzZXMgYXJlIHN1cHBvc2VkIHRvIGJlIHN0b3JlZCBhbmQg bWFuYWdlZCBieSB0aGUgbW9kZW0gZm9yIERMRVAgbWFuYWdlbWVudCBhdXRvbWF0aWNhbGx5LCB3 ZSBhKSBhcmVuJ3QgdHJhbnNwYXJlbnQgYW55bW9yZSBiKSBIYXZlIGEgc2NhbGUgcHJvYmxlbSBt YW5hZ2luZyBhbGwgdGhvc2UgbWFjcyBjKSBJZiB0aGVyZSBhcmUgbW9yZSBtYWMgYWRkcmVzc2Vz IChub3Qgcm91dGVycyB3ZSB3b3VsZCBjYXJlIGFib3V0IHZpYSBkbGVwKSBob3cgaXMgYSB0cmFu c3BhcmVudCBzd2l0Y2ggc3VwcG9zZWQgdG8gIktOT1ciIHdoaWNoIG1hYyBhZGRyZXNzIGlzIHRo ZSBzcGVjaWFsIG9uZSB0aGF0IHNob3VsZCBiZSAnc2V0dXAnIGFzIHRoZSBkbGVwIHRhcmdldC4g IEkgdGhpbmsgdGhhdCB3b3VsZCByZXF1aXJlIHNvbWUgc3BlY2lhbCBjb25maWcgdGhhdCB0aGVu IGhhcyB0byBiZSBtYW5hZ2VkIChhbHNvIGJyZWFraW5nIHRyYW5zcGFyZW5jeSkgYW5kIGNyZWF0 aW5nIE9BTSBhbmQgY2hhbmdlIG1hbmFnZW1lbnQgaXNzdWVzLiBSZW1lbWJlciB0aGUgTEFOIGlz IG5vdCAnb3VyJyBlcXVpcG1lbnQsIHNvIGFsbCB0aGUgc3VkZGVuIG9uZSB3b3VsZCBoYXZlIHRv IGdldCBhbmQgbWFuYWdlIG1hYyBhZGRyZXNzZXMgZm9yIGFsbCB0aGVzZSBzaXRlcy4gIFdlIGFy ZSBnb2luZyBMMiBpbi1vcmRlciB0byBoZWxwIHVzIGFuZCBvdXIgY2xpZW50cyBub3Qgd29ycnkg YWJvdXQgZWFjaCBvdGhlcidzIGVxdWlwbWVudCBhbmQgbmV0d29ya2luZy4NCj4gDQo+IA0KPiBX aGF0IGlzIHRoZSB0eXBpY2FsIHVwdGltZSBvZiBhIGNsaWVudD8gQW5kIHdoYXQgcGVyY2VudGFn ZSBvZiB0cmFmZmljIGdvZXMgZnJvbSB0aGUgSHViIHRvIHRoZSBjbGllbnRzPyBBIHJvdWdoIGd1 ZXNzIHdvdWxkIGJlIGdyZWF0IHRvIGJldHRlciB1bmRlcnN0YW5kIHlvdXIgcHJvYmxlbS4NCj4g W0JTU10gLSBUeXBpY2FsIHVwdGltZSB3b3VsZCBiZSBtZWFzdXJlZCBpbiBmcm9tIGhvdXJzIChN YXliZSBhIHBsYW5lIG1vdmluZyBhY3Jvc3Mgc2F0ZWxsaXRlIGZvb3RwcmludHMpIHRvIGhvcGVm dWxseSB5ZWFycyAtIGEgc3RhdGlvbmFyeSBtb2RlbS4gIFRob3VnaCBwcmFjdGljYWxseSB0aGF0 4oCZcyBtYXliZSBtb3JlIG5vcm1hbGx5IG1vbnRocyBkdWUgdG8gd2VhdGhlciwgdXBncmFkZXMs IGV0Yy4NCj4gDQo+IEhlbm5pbmcgUm9nZ2UNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K From nobody Fri Jul 25 09:37:15 2014 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 543581A033D for ; Fri, 25 Jul 2014 09:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Jb_qEJZW8oIG for ; Fri, 25 Jul 2014 09:37:08 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 767E81A031B for ; Fri, 25 Jul 2014 09:37:07 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,732,1400040000"; d="scan'208";a="2602693" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport2.idirect.net with ESMTP; 25 Jul 2014 12:37:06 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Fri, 25 Jul 2014 12:37:06 -0400 From: "Snyder, Brian" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0AAaqRUAAAX832AACbWtAAAIUehw///ECACAACSwsP///TkAgABC2xA= Date: Fri, 25 Jul 2014 16:37:06 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.com> In-Reply-To: <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jWDkJ8y50QQqwU21h92qoiRwopI Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 16:37:10 -0000 ZW1iZWRkZWQuLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGFuIFJh dGxpZmYgKHNyYXRsaWZmKSBbbWFpbHRvOnNyYXRsaWZmQGNpc2NvLmNvbV0gDQpTZW50OiBGcmlk YXksIEp1bHkgMjUsIDIwMTQgMTI6MzAgUE0NClRvOiBTbnlkZXIsIEJyaWFuDQpDYzogUmljayBU YXlsb3I7IEhlbm5pbmcgUm9nZ2U7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0 XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQDQoNCg0KT24gSnVsIDI1LCAyMDE0LCBhdCAx MjoyNCBQTSwgIlNueWRlciwgQnJpYW4iIDxic255ZGVyQGlkaXJlY3QubmV0Pg0KIHdyb3RlOg0K DQo+IFJpY2ssDQo+IA0KPj4gQWgtaGEhISBUaGUgRExFUCBkZXN0aW5hdGlvbiBNQUMgaXMgZGVm aW5lZCB2ZXJ5IHNwZWNpZmljYWxseSBhcyB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGludGVyZmFj ZSB0aGF0IHRoZSByb3V0ZXIgaXMgdXNpbmcgZm9yIHRoZSBUQ1Agc2Vzc2lvbiB0byB0aGUgbG9j YWwgbW9kZW0uICBUaGUgcm91dGVyIG1heSBoYXZlIGEgYmlsbGlvbiBvdGhlciBNQUMgYWRkcmVz c2VzLCBidXQgb25seSB0aGF0IG9uZSBpcyBpbXBvcnRhbnQuICBJbiB0aGUgPnNwb2tlIGNhc2Us IHRoZSBzYW1lIGFwcGxpZXMsIGFuZCBpZiB0aGUgc3Bva2VzIGRvbid0IG5lZWQgdG8ga25vdyBh Ym91dCBvdGhlciBzcG9rZXMsIGRvbid0IHRlbGwgdGhlbS4NCj4gDQo+IEhvbGQgb24uICBJIHRo b3VnaHQgaXQgd2FzIHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgZmFyIHNpZGUgcm91dGVyIChvdGhl cndpc2UgaXQgd291bGQgc3RpbGwgbmVlZCB0byBhcnApLiAgWW91ciBjb21tZW50IC0tLSB0aGUg TE9DQUwgbW9kZW0gd291bGQgZ3JlYXRseSBjaGFuZ2UgdGhlIGlzc3VlIGluIG15IG1pbmQgLS0t IGJ1dCBob3cgZG9lcyBrbm93aW5nIGEgbG9jYWwgTUFDIGhlbHAgTDMgY29udmVyZ2UgYW55IGZh c3RlciAtIHRoYXQgd291bGQgbWVhbiBpdCBzdGlsbCBuZWVkcyB0byBhcnAgb3IgbWNhc3QgaGVs bG8gdG8gZmluZCBmYXIgc2lkZSBndXlzIHNvIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZW4gaG93 IHRoZSAnZmFzdC1zdGFydCcgc3R1ZmYgd29ya3MgeW91IHdlcmUgZGlzY3Vzc2luZyBhcyB0aGUg cG9pbnQgb2YgdGhpcy4uLi4uDQo+IA0KPiBJbiB0aGlzIGRpYWdyYW0gYmVsb3c6DQo+IA0KPiAN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tICBNRE0xIC0tLS0gUlRSMSAtLS0gTkVU MQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+IFVwUnRyIC0tLS0tICAgU2F0SFVCICAg LS0tLS0tICBPVVRFUlNQQUNFIC0tLS0tLS0tLS0gICBNRE0yIC0tLS0gUlRSMiAtLS0gTkVUMg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwt LS0tLSAgTURNMyAtLS0tIFJUUjMgLS0tIE5FVDMNCj4gDQo+IA0KPiBMZXQncyBzYXkgUlRSMSwg UlRSMiwgYW5kIFJUUjMgYWxsIHdhbnQgdG8gbWFrZSBhIFtPU1BGfEVJR1JQfEJHUF0gbmVpZ2hi b3IgdG8gVXBSVFIuICBVUFJUUiB3YW50cyAzIG5laWdoYm9ycy4gIFRoZXJlIGFyZSAyIHZsYW5z IG9uIGVhY2guDQoNCipCeSBkZWZpbml0aW9uKiwgVXBSdHIgaW4gdGhpcyBjYXNlIGhhcyA2IG5l aWdoYm9ycywgbm90IDMuIEVhY2ggVkxBTiBpcyBhIG5laWdoYm9yLg0KDQpbQlNTXSAtIFRoYXTi gJlzIHdoYXQgSSBleHBlY3RlZC4NCg0KPiANCj4gV2hhdCBkb2VzIE1ETVggaGF2ZSB0byB0ZWxs IFJUUlggdmlhIERMRVA/ICAgSG93IG1hbnkgTUFDIEFkZHJlc3NlcyAoTXVsdGlwbGUgVkxBTlMp IGFuZCB3aGljaCBvbmVzPw0KDQpUaGF0J3MgdGhlIHJ1Yi4gTURNMSwgZm9yIGV4YW1wbGUsIGNh biB0ZWxsIFJUUjEgKm9ubHkqIGFib3V0IFVwUnRyLiAoU3BlY2lmaWNhbGx5LCB0aGUgVkxBTlMg b24gVXBSdHIpLiBTbywgd2hpbGUgVXBSdHIgaGFzIDYgbmVpZ2hib3JzIChidXQgd2UndmUgYWxy ZWFkeSBzYWlkIHRoZSBodWIgaXNuJ3QgdGhlIHByb2JsZW0pLCBSVFIxIG9ubHkgc2VlcyAyLiAN Cg0KDQpbQlNTXSAtIFJpZ2h0LiB0aGF04oCZcyB3aGF0IEkgd2FzIGV4cGVjdGluZyB0aGUgYW5z d2VyIHRvIGJlLiAgQnV0IHRoZW4gaXQgaXNu4oCZdCB0aGUgbG9jYWwgTUFDIGFkZHJlc3MgUlRS MSBuZWVkcywgaXRzIFVQUlRSIE1BQyBBZGRyZXNzIC0gaGUgaXMgdGVsbGluZyBoaW0gYWJvdXQg dGhlIFJFTU9URSBtYWMsIG5vdCBsb2NhbC4uLiB3aGljaCBtZWFucyB0aGUgTURNcyB3b3VsZCBu ZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdG8ga25vdyB3aGF0IHRoYXQgaXMgKHBlciBWTEFOIC0gZXZl biB0aG91Z2ggaXRsbCBtb3N0IGxpa2VseSBhbHdheXMgYmUgdGhlIHNhbWUpLg0KDQpOb3cgaWYg d2Ugd2FudCBORVQxIHRvIHRhbGsgdG8gTkVUMiAtIHRoZW4gSSdtIGFzc3VtaW5nIHRoZSBSVFIy IG1hYyBoYXMgdG8gYmUgdG9sZCB0byBSVFIxIGFzIHdlbGwgdmlhIERMRVAgdG9vLiBDb3JyZWN0 PyAgU28gdGhlbiwgaW5zdGVhZCBvZiBsZXR0aW5nIHRoZSBSVFJOIGZpbmQgUlRSTicgbmF0dXJh bGx5IHRoZSB3YXkgYSBidW5jaCBvZiByb3V0ZXJzIG9uIGFuIElHUCB3b3VsZCwgIE1ETU4gd291 bGQgaGF2ZSB0byB0ZWxsIFJUUk4gYWJvdXQgdGhlIGVudGlyZSBzZXQgb2YgUlRScyAodGhhdCBh cmVuJ3QgaGltc2VsZikuICANCg0KVGhhdCdzIHdoYXQgSSdtIGhlYXJpbmcgZnJvbSB0aGlzIGNv bnZlcnNhdGlvbi4uLiB5b3UgaGF2ZSB0byB0ZWxsIHRoZW0gRVZFUlkgc3BlY2lmaWMgZGVzdGlu YXRpb24uICBOb3cgYWxsIHRoZSBzdWRkZW4sIGluIHRoaXMgVlBMUyBhcmNoaXRlY3R1cmUgYW5k IHVzaW5nIERMRVAsIHRoZSBNRE1zIGhhdmUgdG8gbWFpbnRhaW4gYSBNQUMgdG8gTURNIG1hcCB0 aGF0IGNvdWxkIGJlIEhVR0UuICBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIHBhcnQgdGhhdCBz Y2FsZXMuDQoNCklmIEknbSBpbiBWUFdTIG1vZGUgKE5FVDEgY2FuJ3Qgc2VlIE5FVDIpIHRoZW4g SSBhZ3JlZSAtIGl0J3Mgbm90IHRoYXQgaGFyZCBvZiBhIHByb2JsZW0gdG8gc29sdmUgLSB0aG91 Z2ggdGhlcmUgc3RpbGwgbmVlZHMgdG8gYmUgYWRkaXRpb25hbCBPQU0ga25vd2xlZGdlIG9uIHRo ZSBNRE0gd2hpY2ggYnJlYWtzIG15IHRyYW5zcGFyZW5jeSBkZXNpZ24gLSBidXQgSSBjb3VsZCBt YXliZSBsaXZlIHdpdGggdGhhdCBpZiBpdCB3YXMgYSBib3VuZGVkIHNldCBvZiBzYXkgMTIgTUFD cyAoIyBvZiBWTEFOcyBleHBlY3RlZCB0byBnZXR0aW5nIHJvdXRpbmcgcGVlcnMgb24gcGVyIG1v ZGVtIC0gd29yc3QgY2FzZSkuDQoNCg0KQXJlIG15IGV4dHJhcG9sYXRpb25zIGhlcmUgY29ycmVj dD8NCg0KVGhhbmtzLGJyaWFuDQoNCg0KU3Rhbg0KDQoNCj4gDQo+IA0KPiBOb3cgd2hhdCBpZiB3 aGlsZSB0aGUgUkYgc3lzdGVtIGlzIG5vdCBNRVNILCBJIGFtIGFsbG93aW5nIGhhaXJwaW5uaW5n IChWUExTIG1vZGUpLi4uLiBTbyBORVQxIGNhbiB0YWxrIHRvIE5FVDIgdmlhIFNhdEhVQi4gIFRo ZW4gd2hhdCBkbyB0aGV5IGFsbCBoYXZlIGxlYXJuPw0KPiANCj4gDQo+IA0KPiBNYXliZSBhIGNv bmNyZXRlIGV4YW1wbGUgd2lsbCBoZWxwIHRoaXMgc2luayBpbi4NCj4gDQo+IFRoYW5rcywNCj4g QnJpYW4NCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSaWNr IFRheWxvciBbbWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbV0gDQo+IFNlbnQ6 IEZyaWRheSwgSnVseSAyNSwgMjAxNCAxMDoyOSBBTQ0KPiBUbzogU255ZGVyLCBCcmlhbjsgSGVu bmluZyBSb2dnZQ0KPiBDYzogbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttYW5ldF0g UmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KPiANCj4gSW5saW5lIGNvbW1lbnRzLi4uLg0K PiANCj4+PiBBcyBJIHNlZSBpdCwgeW91ciBwcm9ibGVtIGlzIGFsb25nIHRoZSBsaW5lcyBvZiAi T01HLCBJIGhhdmUgMTAsMDAwJ3Mgc3Bva2VzIGFuZCBJIGNhbid0IGhhdmUgYSBtYXN0ZXIgbGlz dCBvZiBzcG9rZSByb3V0ZXIgTUFDcywgYW5kIEkgZG9uJ3Qgd2FudCB0byByZXBvcnQgMTAsMDAw J3MgRExFUCBzZXNzaW9ucyBldmVyeXdoZXJlIHdoZW4gc3Bva2VzIGNhbiByZWFsbHkgb25seSB0 YWxrIHRvIHRoZSBodWIiLiAgQW5kIG15IGFuc3dlciBpcywgIllvdSBkb24ndCBoYXZlIHRvIHJl cG9ydCBldmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUsIGFuZCB5b3UgY2FuIGxlYXJuIHRoZSBNQUNz IGF0IHJ1bnRpbWUuIg0KPiANCj4+IFllcywgdGhhdCBpcyBhIGNvbmNlcm4gb2YgbWluZS4uLiBi dXQgbm90IHRoZSBvbmx5IG9uZS4gIEkgdW5kZXJzdGFuZCBJIG9ubHkgaGF2ZSB0byByZXBvcnQg d2hhdCBJIHdhbnQgdG9vIGJ1dCBJJ20gYWxzbyBjb25jZXJuZWQgd2l0aCB0aGUgbm90aW9uIEkg Y2FuIGF1dG8tbGVhcm4gaXQuICBIb3cgd291bGQgSSBrbm93LCBpbiBhIFZQTFMgbmV0d29yayB3 aGljaCBtYWMgaXMgdGhlIHVwc3RyZWFtIHJvdXRlcj8gSSBjb3VsZCBiZSBpbnVuZGF0ZWQgd2l0 aCBNQUNzIGZyb20gYWxsIG92ZXIgdGhlIG5ldHdvcmsuIE1heWJlIHNvbWUgSSdkIGNhcmUgYWJv dXQgYW5kIHNvbWUgSSB3b3VsZG4ndC4gIEJ1dCBJIGNlcnRhaW5seSBjb3VsZG4ndCB0cmFjayB0 aGVtIGluZGl2aWR1YWxseS4gSSBoYXZlIG5vIGlkZWEgb2YgYW5vdGhlciBtb2RlbXMgc3RhdGUu ICBJIG9ubHkga25vdyBNWSBzdGF0ZSBpbiByZWxhdGlvbiB0byB0aGUgaHViIC0gSUU6IGFtIEkg aW4gbmV0d29yayBvciBub3QuICBBbHNvIHJlY29nbml6ZSB0aGF0IGlmIEkgaGF2ZSBhIGh1bmRy ZWQgdGhvdXNhbmQgTUFDIGFkZHJlc3NlcyBhbmQgSSBoYWQgdG8gdHJhY2sgdGhlbSBhbGwgLS0g d2VsbCBhIGNvbW1vbiBkZXNpZ24gd2l0aCBvdXIgbmV0d29ya3MgaXMgZm9yIHBlb3BsZSB0byB1 c2UgbXVsdGlwbGUgU1ZOcyAodmxhbnMvcWlucXMpIHRhZ3MgUEVSIG1vZGVtLiAgTWFueSBkZXNp Z25zIGhhdmUgMTIgZWFjaC4gT3VyIG5hbWVzcGFjZXMgYXJlIGtlcHQgc2VwYXJhdGVseS4uLi4g c28gYSBodW5kcmVkIHRob3VzYW5kIG1vZGVtcyB3aXRoIDEyIHZsYW5zIHdvdWxkIGJlIDEuMiBN SUxMSU9OIG1hY3MgdGhhdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBzZWVuLg0KPiANCj4gQWgtaGEh ISBUaGUgRExFUCBkZXN0aW5hdGlvbiBNQUMgaXMgZGVmaW5lZCB2ZXJ5IHNwZWNpZmljYWxseSBh cyB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGludGVyZmFjZSB0aGF0IHRoZSByb3V0ZXIgaXMgdXNp bmcgZm9yIHRoZSBUQ1Agc2Vzc2lvbiB0byB0aGUgbG9jYWwgbW9kZW0uICBUaGUgcm91dGVyIG1h eSBoYXZlIGEgYmlsbGlvbiBvdGhlciBNQUMgYWRkcmVzc2VzLCBidXQgb25seSB0aGF0IG9uZSBp cyBpbXBvcnRhbnQuICBJbiB0aGUgc3Bva2UgY2FzZSwgdGhlIHNhbWUgYXBwbGllcywgYW5kIGlm IHRoZSBzcG9rZXMgZG9uJ3QgbmVlZCB0byBrbm93IGFib3V0IG90aGVyIHNwb2tlcywgZG9uJ3Qg dGVsbCB0aGVtLg0KPiANCj4+IEdyYW50ZWQsIEkgZG9u4oCZdCB0aGluayB0aGF0IHNjYWxlIGlz IGdvaW5nIHRvIGJlIHJvbGwgb3V0ICMxIG9mIERMRVAgdXNlIGNhc2UgLSBidXQgd2UgZG8gaGF2 ZSBjdXN0b21lcnMgb3BlcmF0aW5nIGF0IHRoYXQgc2NhbGUuICBJZiAnRExFUCcgZmVhdHVyZSBn ZXRzIHJlbGVhc2VkIC0gdGhleSB3aWxsIHdhbnQgdG8gdXNlIGl0Lg0KPiANCj4gQWJzb2x1dGVs eSwgd2hpY2ggaXMgd2h5IEkgYW5kIG90aGVycyBhcmUgc3BlbmRpbmcgc29tZSBjeWNsZXMgdG8g Z2V0IHRoaXMgc29ydGVkLg0KPiANCj4+IE5vIG1vZGVtIGN1cnJlbnRseSB0cmFja3MgYW55IE1B Q3MgZnJvbSB0aGUgaHViIHNpZGUgZm9yIHRoaXMgcmVhc29uIC0tIGFuZCB3ZSBkb24ndCBuZWVk IHRvbyAoeWV0OikpLg0KPiANCj4gSG9wZWZ1bGx5IG15IGFuc3dlciBhYm92ZSB3aWxsIGhhdmUg aGVscGVkPw0KPiANCj4gUmljaw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogUmljayBUYXlsb3IgW21haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb21d DQo+IFNlbnQ6IEZyaWRheSwgSnVseSAyNSwgMjAxNCAxMDowNSBBTQ0KPiBUbzogU255ZGVyLCBC cmlhbjsgSGVubmluZyBSb2dnZQ0KPiBDYzogbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6 IFttYW5ldF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KPiANCj4gVG9wLXBvc3RlZC4u Lg0KPiANCj4gU29ycnkgQnJpYW4sDQo+IA0KPiBJIHRoaW5rIG15IHVuZGVyc3RhbmRpbmcgb2Yg eW91ciBwcm9ibGVtIG1pZ2h0IHN0aWxsIGJlIHdyb25nLCBidXQgSSdsbCBtYWtlIHNvbWUgc3Vn Z2VzdGlvbnMgYW55d2F5Li4uDQo+IA0KPiBZb3UgZG9uJ3QgbmVlZCB0byBwcmVjb25maWd1cmUg dGhlIHNwb2tlIHJvdXRlciBNQUMgdGhhdCBnZXRzIHNlbnQgdG8gdGhlIGh1YiBiZWNhdXNlIHlv dSBjYW4gbGVhcm4gaXQgZnJvbSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBzcG9rZSBETEVQIHNlc3Np b24uICBUaGVuIHdoZW4gYW4gUkYgbGluayBpcyBlc3RhYmxpc2hlZCwgeW91IHNlbmQgaXQgdXAg dG8gdGhlIGh1YiwgYW5kIGl0IGNhbiByZXBvcnQgaXQgdGhyb3VnaCBpdCdzIGxvY2FsIERMRVAg c2Vzc2lvbiwgYW5kIHZpY2UtdmVyc2EuDQo+IA0KPiBZb3UgZG9uJ3QgbmVlZCB0byByZXBvcnQg YWxsIGRlc3RpbmF0aW9ucyBpbiBhbGwgc2Vzc2lvbnMsIG9ubHkgcmVsZXZhbnQgZGVzdGluYXRp b25zLiAgU28gaW4gdGhlIHNwb2tlIG1vZGVtLCB5b3Ugb25seSBuZWVkIHRvIHJlcG9ydCB0aGUg aHViIE1BQyBpbiB0aGUgY29tbW9uIGNhc2UsIHVubGVzcyB5b3UgaGF2ZSB0dXJuZWQgb24gaGFp ci1waW5uaW5nIGZvciBzb21lIHN1YnNldCBvZiBzcG9rZXMsIGluIHdoaWNoIGNhc2UgeW91IG9u bHkgbmVlZCB0byByZXBvcnQgdGhvc2UgYWRkcmVzc2FibGUgTUFDcyBhcyBETEVQIGRlc3RpbmF0 aW9ucy4NCj4gDQo+IEFzIEkgc2VlIGl0LCB5b3VyIHByb2JsZW0gaXMgYWxvbmcgdGhlIGxpbmVz IG9mICJPTUcsIEkgaGF2ZSAxMCwwMDAncyBzcG9rZXMgYW5kIEkgY2FuJ3QgaGF2ZSBhIG1hc3Rl ciBsaXN0IG9mIHNwb2tlIHJvdXRlciBNQUNzLCBhbmQgSSBkb24ndCB3YW50IHRvIHJlcG9ydCAx MCwwMDAncyBETEVQIHNlc3Npb25zIGV2ZXJ5d2hlcmUgd2hlbiBzcG9rZXMgY2FuIHJlYWxseSBv bmx5IHRhbGsgdG8gdGhlIGh1YiIuICBBbmQgbXkgYW5zd2VyIGlzLCAiWW91IGRvbid0IGhhdmUg dG8gcmVwb3J0IGV2ZXJ5dGhpbmcsIGFsbCB0aGUgdGltZSwgYW5kIHlvdSBjYW4gbGVhcm4gdGhl IE1BQ3MgYXQgcnVudGltZS4iDQo+IA0KPiBDaGVlcnMsDQo+IFJpY2sNCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogU255ZGVyLCBCcmlhbiBb YnNueWRlckBpZGlyZWN0Lm5ldF0NCj4gU2VudDogMjUgSnVseSAyMDE0IDE0OjM3DQo+IFRvOiBI ZW5uaW5nIFJvZ2dlDQo+IENjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVj dDogUkU6IFttYW5ldF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KPiANCj4gRW1iZWRk ZWQuLi4uDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5n IFJvZ2dlIFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDI1 LCAyMDE0IDI6MzYgQU0NCj4gVG86IFNueWRlciwgQnJpYW4NCj4gQ2M6IFJpY2sgVGF5bG9yOyBt YW5ldEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVy IGZvciBETEVQDQo+IA0KPiBPbiBGcmksIEp1bCAyNSwgMjAxNCBhdCAxMjo1MSBBTSwgU255ZGVy LCBCcmlhbiA8YnNueWRlckBpZGlyZWN0Lm5ldD4gd3JvdGU6DQo+PiBbQlNTXSDigJMgQW5kIEkg Z3Vlc3MgSSBhbSBsb29raW5nIGZvciBzb21ldGhpbmcgZGlmZmVyZW50LiAgSeKAmW0gbG9va2lu ZyBmb3IgbGluayBzdGF0ZSBub3RpZmljYXRpb25zICh3aXRoIG1ldHJpY3MpIHRvICAtIGFuZCB0 aGlzIGlzIGEgZGlmZmVyZW50ICMyIOKAkyBhbGxvdyBhIHJvdXRpbmcgcHJvdG9jb2wgdG8gYmUg dHVuZWQgZm9yIG1pbmltdW0gS0VFUCBBTElWRSB0aW1lcnMgdG8gbWluaW1pemUgYmFuZHdpZHRo IHVzYWdlIHRvIGNvbnNlcnZlIHZlcnkgZXhwZW5zaXZlIGFuZCBsaW1pdGVkIGJhbmR3aWR0aC4g IEluIGEgc2F0ZWxsaXRlIG5ldHdvcmssIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGZhc3Qtc3RhcnRz LCBMMSBjb252ZXJnZW5jZSBjYW4gKGFuZCBpbiBhIHN1aXRhYmx5IHNpemVkIG5ldHdvcmsgd2ls bCB0YWtlIHNlY29uZHMpLiAgSG93ZXZlciwgYmVjYXVzZSBtb2RlbXMgdGVuZCB0byBzdGF5IGlu IG5ldHdvcmsgcXVpdGUgc3RhYmx5ICh0cmVlcyBhbmQgYnVpbGRpbmdzIGRvbuKAmXQgZ2V0IHRo ZSB3YXkgb2Z0ZW4gaW4gdGhlIG9jZWFu4pi6KSwgdGhlIGJ1aWxkaW5nIG9mIGFkamFjZW5jaWVz IGRvZXMgbm90IGhhcHBlbiBhbGwgdGhhdCBvZnRlbi4gSXTigJlzIHdheSBtb3JlIGltcG9ydGFu dCB0byBtZSB0byBjb25zZXJ2ZSBiYW5kd2lkdGggYW5kIGJlIHRyYW5zcGFyZW50Lg0KPiANCj4g SSBtdXN0IGFkbWl0IEkgc3RpbGwgZmFpbCB0byBzZWUgd2h5IGEgc3BlY2lhbCBjYXNlIGlzIGV2 ZW4gbmVjZXNzYXJ5Lg0KPiANCj4gW0JTU10gLSBQZXJoYXBzIG5vdCBuZWNlc3NhcnkgLSBidXQg SSdtIHZlcnkgY29uY2VybmVkIHdpdGggdHJ5aW5nIHRvIG9wdGltaXplIGZvciBzY2FsZSBhbmQg dHJhbnNwYXJlbmN5Lg0KPiANCj4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBuZXR3b3JrIHdpdGgg aHVuZHJlZCB0aG91c2FuZHMgY2xpZW50cyBjb25uZWN0ZWQgdmlhIHNhdGVsbGl0ZSB0byBhIEh1 YiBzdGF0aW9uLiBZZXMsIHNvIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudHMg ZG9uJ3QgdGFsayBtb3JlIHRoYW4gbmVjZXNzYXJ5Lg0KPiANCj4gQnV0IHlvdSBzYWlkIHlvdXIg Y2xpZW50IHNhdGVsbGl0ZSBtb2RlbXMgYXJlIGFibGUgdG8gcmVjZWl2ZSBicm9hZGNhc3QgdHJh ZmZpYy4uLiBhbmQgbWF5YmUgZXZlbiB1bmljYXN0cyBkZWxpdmVyZWQgdG8gYSBkaWZmZXJlbnQg Y2xpZW50LiBUaGlzIG1lYW5zIHB1c2hpbmcgaW5mb3JtYXRpb24gZnJvbSB0aGUgSHViIHRvIGFs bCBjbGllbnRzIGlzIHJlYXNvbmFibGUgY2hlYXAuDQo+IFtCU1NdIC0gVGhleSB3b24ndCByZWNl aXZlIHVuaWNhc3QgZm9yIHNvbWVvbmUgZWxzZS4gIEhETEMgYWRkcmVzc2luZyBkZW11eGVzIHRo YXQuICBQdXNoaW5nIGJyb2FkY2FzdCBpcyBjaGVhcC4gIElFOiBBUlBzIGNhbiBmbG93IGZyZWVs eSBhbmQgY2hlYXBseSBvbiB0aGUgZG93bnN0cmVhbS4NCj4gDQo+IFRoaXMgbWVhbnMgdHJhbnNm ZXJyaW5nIHRoZSBNYWMgYWRkcmVzcyB0byBhIGNsaWVudCBpcyBkaXJ0IGNoZWFwLCBlc3BlY2lh bGx5IGlmIExheWVyLTIgYXQgdGhlIEh1YiBpcyBhYmxlIHRvIHRlbGwgdGhhdCBhIG5ldyBjbGll bnQgY29ubmVjdGVkIHRvIHRoZSBzYXRlbGxpdGUuDQo+IFtCU1NdIC0gSW4gdGhpcyBjYXNlIHRy YW5zZmVycmluZyBhIG1hYyBhZGRyZXNzIGlzIGNoZWFwIC0gdGhlIGFycCdzIGRvIGl0IHRocm91 Z2ggdXMgLS0gdGhvdWdoIHRoZSBtb2RlbXMgY3VycmVudGx5IGRvbid0IHRyYWNrIGFuZCByZWNv cmQgYW55IG9mIHRoZSBsZWFybnQgYWRkcmVzcyBPVEEuLi4gd2UganVzdCBsZXQgdGhlIGN1c3Rv bWVyIGRldmljZXMgZG8gd2hhdCB0aGV5IHNob3VsZCBkbyBieSBhbGwgbm9ybWFsIGNvbnZlbnRp b25zLiAoQVJQLCB0aW1lcnMsIGV0YykuICBNb2RlbXMgaGF2ZSBubyBub3Rpb24gb2Ygd2VhdGhl ciBvciBub3QgYW5vdGhlciBtb2RlbSBpcyBpbiBvciBvdXQgb2YgbmV0d29yay4gIE5vIHN0YXIg c3lzdGVtIHdvdWxkLiBUaGV5IGp1c3QgdHJhY2sgdGhlbXNlbHZlcy4gU28gaWYgTUFDIGFkZHJl c3NlcyBhcmUgc3VwcG9zZWQgdG8gYmUgc3RvcmVkIGFuZCBtYW5hZ2VkIGJ5IHRoZSBtb2RlbSBm b3IgRExFUCBtYW5hZ2VtZW50IGF1dG9tYXRpY2FsbHksIHdlIGEpIGFyZW4ndCB0cmFuc3BhcmVu dCBhbnltb3JlIGIpIEhhdmUgYSBzY2FsZSBwcm9ibGVtIG1hbmFnaW5nIGFsbCB0aG9zZSBtYWNz IGMpIElmIHRoZXJlIGFyZSBtb3JlIG1hYyBhZGRyZXNzZXMgKG5vdCByb3V0ZXJzIHdlIHdvdWxk IGNhcmUgYWJvdXQgdmlhIGRsZXApIGhvdyBpcyBhIHRyYW5zcGFyZW50IHN3aXRjaCBzdXBwb3Nl ZCB0byAiS05PVyIgd2hpY2ggbWFjIGFkZHJlc3MgaXMgdGhlIHNwZWNpYWwgb25lIHRoYXQgc2hv dWxkIGJlICdzZXR1cCcgYXMgdGhlIGRsZXAgdGFyZ2V0LiAgSSB0aGluayB0aGF0IHdvdWxkIHJl cXVpcmUgc29tZSBzcGVjaWFsIGNvbmZpZyB0aGF0IHRoZW4gaGFzIHRvIGJlIG1hbmFnZWQgKGFs c28gYnJlYWtpbmcgdHJhbnNwYXJlbmN5KSBhbmQgY3JlYXRpbmcgT0FNIGFuZCBjaGFuZ2UgbWFu YWdlbWVudCBpc3N1ZXMuIFJlbWVtYmVyIHRoZSBMQU4gaXMgbm90ICdvdXInIGVxdWlwbWVudCwg c28gYWxsIHRoZSBzdWRkZW4gb25lIHdvdWxkIGhhdmUgdG8gZ2V0IGFuZCBtYW5hZ2UgbWFjIGFk ZHJlc3NlcyBmb3IgYWxsIHRoZXNlIHNpdGVzLiAgV2UgYXJlIGdvaW5nIEwyIGluLW9yZGVyIHRv IGhlbHAgdXMgYW5kIG91ciBjbGllbnRzIG5vdCB3b3JyeSBhYm91dCBlYWNoIG90aGVyJ3MgZXF1 aXBtZW50IGFuZCBuZXR3b3JraW5nLg0KPiANCj4gDQo+IFdoYXQgaXMgdGhlIHR5cGljYWwgdXB0 aW1lIG9mIGEgY2xpZW50PyBBbmQgd2hhdCBwZXJjZW50YWdlIG9mIHRyYWZmaWMgZ29lcyBmcm9t IHRoZSBIdWIgdG8gdGhlIGNsaWVudHM/IEEgcm91Z2ggZ3Vlc3Mgd291bGQgYmUgZ3JlYXQgdG8g YmV0dGVyIHVuZGVyc3RhbmQgeW91ciBwcm9ibGVtLg0KPiBbQlNTXSAtIFR5cGljYWwgdXB0aW1l IHdvdWxkIGJlIG1lYXN1cmVkIGluIGZyb20gaG91cnMgKE1heWJlIGEgcGxhbmUgbW92aW5nIGFj cm9zcyBzYXRlbGxpdGUgZm9vdHByaW50cykgdG8gaG9wZWZ1bGx5IHllYXJzIC0gYSBzdGF0aW9u YXJ5IG1vZGVtLiAgVGhvdWdoIHByYWN0aWNhbGx5IHRoYXTigJlzIG1heWJlIG1vcmUgbm9ybWFs bHkgbW9udGhzIGR1ZSB0byB3ZWF0aGVyLCB1cGdyYWRlcywgZXRjLg0KPiANCj4gSGVubmluZyBS b2dnZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo= From nobody Fri Jul 25 10:01:35 2014 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 3EB951A0173 for ; Fri, 25 Jul 2014 10:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 ChcdjLie9EHA for ; Fri, 25 Jul 2014 10:01:31 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 25E041A0037 for ; Fri, 25 Jul 2014 10:01:30 -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, 25 Jul 2014 18:00:47 +0100 From: Rick Taylor To: "Snyder, Brian" , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: AQHPp9bVBz332mowOEGhx2cRjj5qopuwup+AgAAU4JT///aRAIAAEguegAAROgCAAAGaAIAAAfcAgAAXBt8= Date: Fri, 25 Jul 2014 16:59:30 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB3D5@tss-server1.home.tropicalstormsoftware.com> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.com>, <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BAvZuEJP_LmpZJ8IY-w7oLyd3EE Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 17:01:33 -0000 QnJpYW4sCgpJJ20gZ2V0dGluZyBiYWZmbGVkIGFzIHlvdSBBU0NJSSBkaWFncmFtIGxvc3QgYWxs IGZvcm1hdHRpbmcuICBDYW4geW91IHJlZHJhdyBpdCBhcyBhIHBuZyBvciBzb21ldGhpbmcgYW5k IHNlbmQgaXQgYmFjayBvdXQ/CgpDaGVlcnMsCgpSaWNrCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KRnJvbTogU255ZGVyLCBCcmlhbiBbYnNueWRlckBpZGlyZWN0Lm5l dF0KU2VudDogMjUgSnVseSAyMDE0IDE3OjM3ClRvOiBTdGFuIFJhdGxpZmYgKHNyYXRsaWZmKQpD YzogUmljayBUYXlsb3I7IEhlbm5pbmcgUm9nZ2U7IG1hbmV0QGlldGYub3JnClN1YmplY3Q6IFJF OiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVAKCmVtYmVkZGVkLi4uLgoKLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogU3RhbiBSYXRsaWZmIChzcmF0bGlmZikgW21h aWx0bzpzcmF0bGlmZkBjaXNjby5jb21dClNlbnQ6IEZyaWRheSwgSnVseSAyNSwgMjAxNCAxMjoz MCBQTQpUbzogU255ZGVyLCBCcmlhbgpDYzogUmljayBUYXlsb3I7IEhlbm5pbmcgUm9nZ2U7IG1h bmV0QGlldGYub3JnClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9y IERMRVAKCgpPbiBKdWwgMjUsIDIwMTQsIGF0IDEyOjI0IFBNLCAiU255ZGVyLCBCcmlhbiIgPGJz bnlkZXJAaWRpcmVjdC5uZXQ+CiB3cm90ZToKCj4gUmljaywKPgo+PiBBaC1oYSEhIFRoZSBETEVQ IGRlc3RpbmF0aW9uIE1BQyBpcyBkZWZpbmVkIHZlcnkgc3BlY2lmaWNhbGx5IGFzIHRoZSBNQUMg YWRkcmVzcyBvZiB0aGUgaW50ZXJmYWNlIHRoYXQgdGhlIHJvdXRlciBpcyB1c2luZyBmb3IgdGhl IFRDUCBzZXNzaW9uIHRvIHRoZSBsb2NhbCBtb2RlbS4gIFRoZSByb3V0ZXIgbWF5IGhhdmUgYSBi aWxsaW9uIG90aGVyIE1BQyBhZGRyZXNzZXMsIGJ1dCBvbmx5IHRoYXQgb25lIGlzIGltcG9ydGFu dC4gIEluIHRoZSA+c3Bva2UgY2FzZSwgdGhlIHNhbWUgYXBwbGllcywgYW5kIGlmIHRoZSBzcG9r ZXMgZG9uJ3QgbmVlZCB0byBrbm93IGFib3V0IG90aGVyIHNwb2tlcywgZG9uJ3QgdGVsbCB0aGVt Lgo+Cj4gSG9sZCBvbi4gIEkgdGhvdWdodCBpdCB3YXMgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBm YXIgc2lkZSByb3V0ZXIgKG90aGVyd2lzZSBpdCB3b3VsZCBzdGlsbCBuZWVkIHRvIGFycCkuICBZ b3VyIGNvbW1lbnQgLS0tIHRoZSBMT0NBTCBtb2RlbSB3b3VsZCBncmVhdGx5IGNoYW5nZSB0aGUg aXNzdWUgaW4gbXkgbWluZCAtLS0gYnV0IGhvdyBkb2VzIGtub3dpbmcgYSBsb2NhbCBNQUMgaGVs cCBMMyBjb252ZXJnZSBhbnkgZmFzdGVyIC0gdGhhdCB3b3VsZCBtZWFuIGl0IHN0aWxsIG5lZWRz IHRvIGFycCBvciBtY2FzdCBoZWxsbyB0byBmaW5kIGZhciBzaWRlIGd1eXMgc28gSSBkb27igJl0 IHVuZGVyc3RhbmQgdGhlbiBob3cgdGhlICdmYXN0LXN0YXJ0JyBzdHVmZiB3b3JrcyB5b3Ugd2Vy ZSBkaXNjdXNzaW5nIGFzIHRoZSBwb2ludCBvZiB0aGlzLi4uLi4KPgo+IEluIHRoaXMgZGlhZ3Jh bSBiZWxvdzoKPgo+Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tICBNRE0xIC0tLS0g UlRSMSAtLS0gTkVUMQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPiBVcFJ0ciAtLS0tLSAg IFNhdEhVQiAgIC0tLS0tLSAgT1VURVJTUEFDRSAtLS0tLS0tLS0tICAgTURNMiAtLS0tIFJUUjIg LS0tIE5FVDIKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfC0tLS0tICBNRE0zIC0tLS0gUlRSMyAtLS0gTkVUMwo+Cj4KPiBMZXQncyBzYXkgUlRS MSwgUlRSMiwgYW5kIFJUUjMgYWxsIHdhbnQgdG8gbWFrZSBhIFtPU1BGfEVJR1JQfEJHUF0gbmVp Z2hib3IgdG8gVXBSVFIuICBVUFJUUiB3YW50cyAzIG5laWdoYm9ycy4gIFRoZXJlIGFyZSAyIHZs YW5zIG9uIGVhY2guCgoqQnkgZGVmaW5pdGlvbiosIFVwUnRyIGluIHRoaXMgY2FzZSBoYXMgNiBu ZWlnaGJvcnMsIG5vdCAzLiBFYWNoIFZMQU4gaXMgYSBuZWlnaGJvci4KCltCU1NdIC0gVGhhdOKA mXMgd2hhdCBJIGV4cGVjdGVkLgoKPgo+IFdoYXQgZG9lcyBNRE1YIGhhdmUgdG8gdGVsbCBSVFJY IHZpYSBETEVQPyAgIEhvdyBtYW55IE1BQyBBZGRyZXNzZXMgKE11bHRpcGxlIFZMQU5TKSBhbmQg d2hpY2ggb25lcz8KClRoYXQncyB0aGUgcnViLiBNRE0xLCBmb3IgZXhhbXBsZSwgY2FuIHRlbGwg UlRSMSAqb25seSogYWJvdXQgVXBSdHIuIChTcGVjaWZpY2FsbHksIHRoZSBWTEFOUyBvbiBVcFJ0 cikuIFNvLCB3aGlsZSBVcFJ0ciBoYXMgNiBuZWlnaGJvcnMgKGJ1dCB3ZSd2ZSBhbHJlYWR5IHNh aWQgdGhlIGh1YiBpc24ndCB0aGUgcHJvYmxlbSksIFJUUjEgb25seSBzZWVzIDIuCgoKW0JTU10g LSBSaWdodC4gdGhhdOKAmXMgd2hhdCBJIHdhcyBleHBlY3RpbmcgdGhlIGFuc3dlciB0byBiZS4g IEJ1dCB0aGVuIGl0IGlzbuKAmXQgdGhlIGxvY2FsIE1BQyBhZGRyZXNzIFJUUjEgbmVlZHMsIGl0 cyBVUFJUUiBNQUMgQWRkcmVzcyAtIGhlIGlzIHRlbGxpbmcgaGltIGFib3V0IHRoZSBSRU1PVEUg bWFjLCBub3QgbG9jYWwuLi4gd2hpY2ggbWVhbnMgdGhlIE1ETXMgd291bGQgbmVlZCB0byBiZSBj b25maWd1cmVkIHRvIGtub3cgd2hhdCB0aGF0IGlzIChwZXIgVkxBTiAtIGV2ZW4gdGhvdWdoIGl0 bGwgbW9zdCBsaWtlbHkgYWx3YXlzIGJlIHRoZSBzYW1lKS4KCk5vdyBpZiB3ZSB3YW50IE5FVDEg dG8gdGFsayB0byBORVQyIC0gdGhlbiBJJ20gYXNzdW1pbmcgdGhlIFJUUjIgbWFjIGhhcyB0byBi ZSB0b2xkIHRvIFJUUjEgYXMgd2VsbCB2aWEgRExFUCB0b28uIENvcnJlY3Q/ICBTbyB0aGVuLCBp bnN0ZWFkIG9mIGxldHRpbmcgdGhlIFJUUk4gZmluZCBSVFJOJyBuYXR1cmFsbHkgdGhlIHdheSBh IGJ1bmNoIG9mIHJvdXRlcnMgb24gYW4gSUdQIHdvdWxkLCAgTURNTiB3b3VsZCBoYXZlIHRvIHRl bGwgUlRSTiBhYm91dCB0aGUgZW50aXJlIHNldCBvZiBSVFJzICh0aGF0IGFyZW4ndCBoaW1zZWxm KS4KClRoYXQncyB3aGF0IEknbSBoZWFyaW5nIGZyb20gdGhpcyBjb252ZXJzYXRpb24uLi4geW91 IGhhdmUgdG8gdGVsbCB0aGVtIEVWRVJZIHNwZWNpZmljIGRlc3RpbmF0aW9uLiAgTm93IGFsbCB0 aGUgc3VkZGVuLCBpbiB0aGlzIFZQTFMgYXJjaGl0ZWN0dXJlIGFuZCB1c2luZyBETEVQLCB0aGUg TURNcyBoYXZlIHRvIG1haW50YWluIGEgTUFDIHRvIE1ETSBtYXAgdGhhdCBjb3VsZCBiZSBIVUdF LiAgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBwYXJ0IHRoYXQgc2NhbGVzLgoKSWYgSSdtIGlu IFZQV1MgbW9kZSAoTkVUMSBjYW4ndCBzZWUgTkVUMikgdGhlbiBJIGFncmVlIC0gaXQncyBub3Qg dGhhdCBoYXJkIG9mIGEgcHJvYmxlbSB0byBzb2x2ZSAtIHRob3VnaCB0aGVyZSBzdGlsbCBuZWVk cyB0byBiZSBhZGRpdGlvbmFsIE9BTSBrbm93bGVkZ2Ugb24gdGhlIE1ETSB3aGljaCBicmVha3Mg bXkgdHJhbnNwYXJlbmN5IGRlc2lnbiAtIGJ1dCBJIGNvdWxkIG1heWJlIGxpdmUgd2l0aCB0aGF0 IGlmIGl0IHdhcyBhIGJvdW5kZWQgc2V0IG9mIHNheSAxMiBNQUNzICgjIG9mIFZMQU5zIGV4cGVj dGVkIHRvIGdldHRpbmcgcm91dGluZyBwZWVycyBvbiBwZXIgbW9kZW0gLSB3b3JzdCBjYXNlKS4K CgpBcmUgbXkgZXh0cmFwb2xhdGlvbnMgaGVyZSBjb3JyZWN0PwoKVGhhbmtzLGJyaWFuCgoKU3Rh bgoKCj4KPgo+IE5vdyB3aGF0IGlmIHdoaWxlIHRoZSBSRiBzeXN0ZW0gaXMgbm90IE1FU0gsIEkg YW0gYWxsb3dpbmcgaGFpcnBpbm5pbmcgKFZQTFMgbW9kZSkuLi4uIFNvIE5FVDEgY2FuIHRhbGsg dG8gTkVUMiB2aWEgU2F0SFVCLiAgVGhlbiB3aGF0IGRvIHRoZXkgYWxsIGhhdmUgbGVhcm4/Cj4K Pgo+Cj4gTWF5YmUgYSBjb25jcmV0ZSBleGFtcGxlIHdpbGwgaGVscCB0aGlzIHNpbmsgaW4uCj4K PiBUaGFua3MsCj4gQnJpYW4KPgo+Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9t OiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbV0KPiBT ZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTA6MjkgQU0KPiBUbzogU255ZGVyLCBCcmlhbjsg SGVubmluZyBSb2dnZQo+IENjOiBtYW5ldEBpZXRmLm9yZwo+IFN1YmplY3Q6IFJFOiBbbWFuZXRd IFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVAKPgo+IElubGluZSBjb21tZW50cy4uLi4KPgo+ Pj4gQXMgSSBzZWUgaXQsIHlvdXIgcHJvYmxlbSBpcyBhbG9uZyB0aGUgbGluZXMgb2YgIk9NRywg SSBoYXZlIDEwLDAwMCdzIHNwb2tlcyBhbmQgSSBjYW4ndCBoYXZlIGEgbWFzdGVyIGxpc3Qgb2Yg c3Bva2Ugcm91dGVyIE1BQ3MsIGFuZCBJIGRvbid0IHdhbnQgdG8gcmVwb3J0IDEwLDAwMCdzIERM RVAgc2Vzc2lvbnMgZXZlcnl3aGVyZSB3aGVuIHNwb2tlcyBjYW4gcmVhbGx5IG9ubHkgdGFsayB0 byB0aGUgaHViIi4gIEFuZCBteSBhbnN3ZXIgaXMsICJZb3UgZG9uJ3QgaGF2ZSB0byByZXBvcnQg ZXZlcnl0aGluZywgYWxsIHRoZSB0aW1lLCBhbmQgeW91IGNhbiBsZWFybiB0aGUgTUFDcyBhdCBy dW50aW1lLiIKPgo+PiBZZXMsIHRoYXQgaXMgYSBjb25jZXJuIG9mIG1pbmUuLi4gYnV0IG5vdCB0 aGUgb25seSBvbmUuICBJIHVuZGVyc3RhbmQgSSBvbmx5IGhhdmUgdG8gcmVwb3J0IHdoYXQgSSB3 YW50IHRvbyBidXQgSSdtIGFsc28gY29uY2VybmVkIHdpdGggdGhlIG5vdGlvbiBJIGNhbiBhdXRv LWxlYXJuIGl0LiAgSG93IHdvdWxkIEkga25vdywgaW4gYSBWUExTIG5ldHdvcmsgd2hpY2ggbWFj IGlzIHRoZSB1cHN0cmVhbSByb3V0ZXI/IEkgY291bGQgYmUgaW51bmRhdGVkIHdpdGggTUFDcyBm cm9tIGFsbCBvdmVyIHRoZSBuZXR3b3JrLiBNYXliZSBzb21lIEknZCBjYXJlIGFib3V0IGFuZCBz b21lIEkgd291bGRuJ3QuICBCdXQgSSBjZXJ0YWlubHkgY291bGRuJ3QgdHJhY2sgdGhlbSBpbmRp dmlkdWFsbHkuIEkgaGF2ZSBubyBpZGVhIG9mIGFub3RoZXIgbW9kZW1zIHN0YXRlLiAgSSBvbmx5 IGtub3cgTVkgc3RhdGUgaW4gcmVsYXRpb24gdG8gdGhlIGh1YiAtIElFOiBhbSBJIGluIG5ldHdv cmsgb3Igbm90LiAgQWxzbyByZWNvZ25pemUgdGhhdCBpZiBJIGhhdmUgYSBodW5kcmVkIHRob3Vz YW5kIE1BQyBhZGRyZXNzZXMgYW5kIEkgaGFkIHRvIHRyYWNrIHRoZW0gYWxsIC0tIHdlbGwgYSBj b21tb24gZGVzaWduIHdpdGggb3VyIG5ldHdvcmtzIGlzIGZvciBwZW9wbGUgdG8gdXNlIG11bHRp cGxlIFNWTnMgKHZsYW5zL3FpbnFzKSB0YWdzIFBFUiBtb2RlbS4gIE1hbnkgZGVzaWducyBoYXZl IDEyIGVhY2guIE91ciBuYW1lc3BhY2VzIGFyZSBrZXB0IHNlcGFyYXRlbHkuLi4uIHNvIGEgaHVu ZHJlZCB0aG91c2FuZCBtb2RlbXMgd2l0aCAxMiB2bGFucyB3b3VsZCBiZSAxLjIgTUlMTElPTiBt YWNzIHRoYXQgY291bGQgcG90ZW50aWFsbHkgYmUgc2Vlbi4KPgo+IEFoLWhhISEgVGhlIERMRVAg ZGVzdGluYXRpb24gTUFDIGlzIGRlZmluZWQgdmVyeSBzcGVjaWZpY2FsbHkgYXMgdGhlIE1BQyBh ZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2UgdGhhdCB0aGUgcm91dGVyIGlzIHVzaW5nIGZvciB0aGUg VENQIHNlc3Npb24gdG8gdGhlIGxvY2FsIG1vZGVtLiAgVGhlIHJvdXRlciBtYXkgaGF2ZSBhIGJp bGxpb24gb3RoZXIgTUFDIGFkZHJlc3NlcywgYnV0IG9ubHkgdGhhdCBvbmUgaXMgaW1wb3J0YW50 LiAgSW4gdGhlIHNwb2tlIGNhc2UsIHRoZSBzYW1lIGFwcGxpZXMsIGFuZCBpZiB0aGUgc3Bva2Vz IGRvbid0IG5lZWQgdG8ga25vdyBhYm91dCBvdGhlciBzcG9rZXMsIGRvbid0IHRlbGwgdGhlbS4K Pgo+PiBHcmFudGVkLCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBzY2FsZSBpcyBnb2luZyB0byBiZSBy b2xsIG91dCAjMSBvZiBETEVQIHVzZSBjYXNlIC0gYnV0IHdlIGRvIGhhdmUgY3VzdG9tZXJzIG9w ZXJhdGluZyBhdCB0aGF0IHNjYWxlLiAgSWYgJ0RMRVAnIGZlYXR1cmUgZ2V0cyByZWxlYXNlZCAt IHRoZXkgd2lsbCB3YW50IHRvIHVzZSBpdC4KPgo+IEFic29sdXRlbHksIHdoaWNoIGlzIHdoeSBJ IGFuZCBvdGhlcnMgYXJlIHNwZW5kaW5nIHNvbWUgY3ljbGVzIHRvIGdldCB0aGlzIHNvcnRlZC4K Pgo+PiBObyBtb2RlbSBjdXJyZW50bHkgdHJhY2tzIGFueSBNQUNzIGZyb20gdGhlIGh1YiBzaWRl IGZvciB0aGlzIHJlYXNvbiAtLSBhbmQgd2UgZG9uJ3QgbmVlZCB0b28gKHlldDopKS4KPgo+IEhv cGVmdWxseSBteSBhbnN3ZXIgYWJvdmUgd2lsbCBoYXZlIGhlbHBlZD8KPgo+IFJpY2sKPgo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogUmljayBUYXlsb3IgW21haWx0bzpyaWNr QHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb21dCj4gU2VudDogRnJpZGF5LCBKdWx5IDI1LCAyMDE0 IDEwOjA1IEFNCj4gVG86IFNueWRlciwgQnJpYW47IEhlbm5pbmcgUm9nZ2UKPiBDYzogbWFuZXRA aWV0Zi5vcmcKPiBTdWJqZWN0OiBSRTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBE TEVQCj4KPiBUb3AtcG9zdGVkLi4uCj4KPiBTb3JyeSBCcmlhbiwKPgo+IEkgdGhpbmsgbXkgdW5k ZXJzdGFuZGluZyBvZiB5b3VyIHByb2JsZW0gbWlnaHQgc3RpbGwgYmUgd3JvbmcsIGJ1dCBJJ2xs IG1ha2Ugc29tZSBzdWdnZXN0aW9ucyBhbnl3YXkuLi4KPgo+IFlvdSBkb24ndCBuZWVkIHRvIHBy ZWNvbmZpZ3VyZSB0aGUgc3Bva2Ugcm91dGVyIE1BQyB0aGF0IGdldHMgc2VudCB0byB0aGUgaHVi IGJlY2F1c2UgeW91IGNhbiBsZWFybiBpdCBmcm9tIHRoZSBlbmRwb2ludHMgb2YgdGhlIHNwb2tl IERMRVAgc2Vzc2lvbi4gIFRoZW4gd2hlbiBhbiBSRiBsaW5rIGlzIGVzdGFibGlzaGVkLCB5b3Ug c2VuZCBpdCB1cCB0byB0aGUgaHViLCBhbmQgaXQgY2FuIHJlcG9ydCBpdCB0aHJvdWdoIGl0J3Mg bG9jYWwgRExFUCBzZXNzaW9uLCBhbmQgdmljZS12ZXJzYS4KPgo+IFlvdSBkb24ndCBuZWVkIHRv IHJlcG9ydCBhbGwgZGVzdGluYXRpb25zIGluIGFsbCBzZXNzaW9ucywgb25seSByZWxldmFudCBk ZXN0aW5hdGlvbnMuICBTbyBpbiB0aGUgc3Bva2UgbW9kZW0sIHlvdSBvbmx5IG5lZWQgdG8gcmVw b3J0IHRoZSBodWIgTUFDIGluIHRoZSBjb21tb24gY2FzZSwgdW5sZXNzIHlvdSBoYXZlIHR1cm5l ZCBvbiBoYWlyLXBpbm5pbmcgZm9yIHNvbWUgc3Vic2V0IG9mIHNwb2tlcywgaW4gd2hpY2ggY2Fz ZSB5b3Ugb25seSBuZWVkIHRvIHJlcG9ydCB0aG9zZSBhZGRyZXNzYWJsZSBNQUNzIGFzIERMRVAg ZGVzdGluYXRpb25zLgo+Cj4gQXMgSSBzZWUgaXQsIHlvdXIgcHJvYmxlbSBpcyBhbG9uZyB0aGUg bGluZXMgb2YgIk9NRywgSSBoYXZlIDEwLDAwMCdzIHNwb2tlcyBhbmQgSSBjYW4ndCBoYXZlIGEg bWFzdGVyIGxpc3Qgb2Ygc3Bva2Ugcm91dGVyIE1BQ3MsIGFuZCBJIGRvbid0IHdhbnQgdG8gcmVw b3J0IDEwLDAwMCdzIERMRVAgc2Vzc2lvbnMgZXZlcnl3aGVyZSB3aGVuIHNwb2tlcyBjYW4gcmVh bGx5IG9ubHkgdGFsayB0byB0aGUgaHViIi4gIEFuZCBteSBhbnN3ZXIgaXMsICJZb3UgZG9uJ3Qg aGF2ZSB0byByZXBvcnQgZXZlcnl0aGluZywgYWxsIHRoZSB0aW1lLCBhbmQgeW91IGNhbiBsZWFy biB0aGUgTUFDcyBhdCBydW50aW1lLiIKPgo+IENoZWVycywKPiBSaWNrCj4KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogU255ZGVyLCBCcmlhbiBbYnNu eWRlckBpZGlyZWN0Lm5ldF0KPiBTZW50OiAyNSBKdWx5IDIwMTQgMTQ6MzcKPiBUbzogSGVubmlu ZyBSb2dnZQo+IENjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcKPiBTdWJqZWN0OiBSRTog W21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQCj4KPiBFbWJlZGRlZC4uLi4KPgo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogSGVubmluZyBSb2dnZSBbbWFpbHRv Omhyb2dnZUBnbWFpbC5jb21dCj4gU2VudDogRnJpZGF5LCBKdWx5IDI1LCAyMDE0IDI6MzYgQU0K PiBUbzogU255ZGVyLCBCcmlhbgo+IENjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcKPiBT dWJqZWN0OiBSZTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQCj4KPiBPbiBG cmksIEp1bCAyNSwgMjAxNCBhdCAxMjo1MSBBTSwgU255ZGVyLCBCcmlhbiA8YnNueWRlckBpZGly ZWN0Lm5ldD4gd3JvdGU6Cj4+IFtCU1NdIOKAkyBBbmQgSSBndWVzcyBJIGFtIGxvb2tpbmcgZm9y IHNvbWV0aGluZyBkaWZmZXJlbnQuICBJ4oCZbSBsb29raW5nIGZvciBsaW5rIHN0YXRlIG5vdGlm aWNhdGlvbnMgKHdpdGggbWV0cmljcykgdG8gIC0gYW5kIHRoaXMgaXMgYSBkaWZmZXJlbnQgIzIg 4oCTIGFsbG93IGEgcm91dGluZyBwcm90b2NvbCB0byBiZSB0dW5lZCBmb3IgbWluaW11bSBLRUVQ IEFMSVZFIHRpbWVycyB0byBtaW5pbWl6ZSBiYW5kd2lkdGggdXNhZ2UgdG8gY29uc2VydmUgdmVy eSBleHBlbnNpdmUgYW5kIGxpbWl0ZWQgYmFuZHdpZHRoLiAgSW4gYSBzYXRlbGxpdGUgbmV0d29y aywgdGhlcmUgaXMgbm8gbmVlZCBmb3IgZmFzdC1zdGFydHMsIEwxIGNvbnZlcmdlbmNlIGNhbiAo YW5kIGluIGEgc3VpdGFibHkgc2l6ZWQgbmV0d29yayB3aWxsIHRha2Ugc2Vjb25kcykuICBIb3dl dmVyLCBiZWNhdXNlIG1vZGVtcyB0ZW5kIHRvIHN0YXkgaW4gbmV0d29yayBxdWl0ZSBzdGFibHkg KHRyZWVzIGFuZCBidWlsZGluZ3MgZG9u4oCZdCBnZXQgdGhlIHdheSBvZnRlbiBpbiB0aGUgb2Nl YW7imLopLCB0aGUgYnVpbGRpbmcgb2YgYWRqYWNlbmNpZXMgZG9lcyBub3QgaGFwcGVuIGFsbCB0 aGF0IG9mdGVuLiBJdOKAmXMgd2F5IG1vcmUgaW1wb3J0YW50IHRvIG1lIHRvIGNvbnNlcnZlIGJh bmR3aWR0aCBhbmQgYmUgdHJhbnNwYXJlbnQuCj4KPiBJIG11c3QgYWRtaXQgSSBzdGlsbCBmYWls IHRvIHNlZSB3aHkgYSBzcGVjaWFsIGNhc2UgaXMgZXZlbiBuZWNlc3NhcnkuCj4KPiBbQlNTXSAt IFBlcmhhcHMgbm90IG5lY2Vzc2FyeSAtIGJ1dCBJJ20gdmVyeSBjb25jZXJuZWQgd2l0aCB0cnlp bmcgdG8gb3B0aW1pemUgZm9yIHNjYWxlIGFuZCB0cmFuc3BhcmVuY3kuCj4KPiBXZSBhcmUgdGFs a2luZyBhYm91dCBhIG5ldHdvcmsgd2l0aCBodW5kcmVkIHRob3VzYW5kcyBjbGllbnRzIGNvbm5l Y3RlZCB2aWEgc2F0ZWxsaXRlIHRvIGEgSHViIHN0YXRpb24uIFllcywgc28gd2UgbmVlZCB0byBt YWtlIHN1cmUgdGhhdCB0aGUgY2xpZW50cyBkb24ndCB0YWxrIG1vcmUgdGhhbiBuZWNlc3Nhcnku Cj4KPiBCdXQgeW91IHNhaWQgeW91ciBjbGllbnQgc2F0ZWxsaXRlIG1vZGVtcyBhcmUgYWJsZSB0 byByZWNlaXZlIGJyb2FkY2FzdCB0cmFmZmljLi4uIGFuZCBtYXliZSBldmVuIHVuaWNhc3RzIGRl bGl2ZXJlZCB0byBhIGRpZmZlcmVudCBjbGllbnQuIFRoaXMgbWVhbnMgcHVzaGluZyBpbmZvcm1h dGlvbiBmcm9tIHRoZSBIdWIgdG8gYWxsIGNsaWVudHMgaXMgcmVhc29uYWJsZSBjaGVhcC4KPiBb QlNTXSAtIFRoZXkgd29uJ3QgcmVjZWl2ZSB1bmljYXN0IGZvciBzb21lb25lIGVsc2UuICBIRExD IGFkZHJlc3NpbmcgZGVtdXhlcyB0aGF0LiAgUHVzaGluZyBicm9hZGNhc3QgaXMgY2hlYXAuICBJ RTogQVJQcyBjYW4gZmxvdyBmcmVlbHkgYW5kIGNoZWFwbHkgb24gdGhlIGRvd25zdHJlYW0uCj4K PiBUaGlzIG1lYW5zIHRyYW5zZmVycmluZyB0aGUgTWFjIGFkZHJlc3MgdG8gYSBjbGllbnQgaXMg ZGlydCBjaGVhcCwgZXNwZWNpYWxseSBpZiBMYXllci0yIGF0IHRoZSBIdWIgaXMgYWJsZSB0byB0 ZWxsIHRoYXQgYSBuZXcgY2xpZW50IGNvbm5lY3RlZCB0byB0aGUgc2F0ZWxsaXRlLgo+IFtCU1Nd IC0gSW4gdGhpcyBjYXNlIHRyYW5zZmVycmluZyBhIG1hYyBhZGRyZXNzIGlzIGNoZWFwIC0gdGhl IGFycCdzIGRvIGl0IHRocm91Z2ggdXMgLS0gdGhvdWdoIHRoZSBtb2RlbXMgY3VycmVudGx5IGRv bid0IHRyYWNrIGFuZCByZWNvcmQgYW55IG9mIHRoZSBsZWFybnQgYWRkcmVzcyBPVEEuLi4gd2Ug anVzdCBsZXQgdGhlIGN1c3RvbWVyIGRldmljZXMgZG8gd2hhdCB0aGV5IHNob3VsZCBkbyBieSBh bGwgbm9ybWFsIGNvbnZlbnRpb25zLiAoQVJQLCB0aW1lcnMsIGV0YykuICBNb2RlbXMgaGF2ZSBu byBub3Rpb24gb2Ygd2VhdGhlciBvciBub3QgYW5vdGhlciBtb2RlbSBpcyBpbiBvciBvdXQgb2Yg bmV0d29yay4gIE5vIHN0YXIgc3lzdGVtIHdvdWxkLiBUaGV5IGp1c3QgdHJhY2sgdGhlbXNlbHZl cy4gU28gaWYgTUFDIGFkZHJlc3NlcyBhcmUgc3VwcG9zZWQgdG8gYmUgc3RvcmVkIGFuZCBtYW5h Z2VkIGJ5IHRoZSBtb2RlbSBmb3IgRExFUCBtYW5hZ2VtZW50IGF1dG9tYXRpY2FsbHksIHdlIGEp IGFyZW4ndCB0cmFuc3BhcmVudCBhbnltb3JlIGIpIEhhdmUgYSBzY2FsZSBwcm9ibGVtIG1hbmFn aW5nIGFsbCB0aG9zZSBtYWNzIGMpIElmIHRoZXJlIGFyZSBtb3JlIG1hYyBhZGRyZXNzZXMgKG5v dCByb3V0ZXJzIHdlIHdvdWxkIGNhcmUgYWJvdXQgdmlhIGRsZXApIGhvdyBpcyBhIHRyYW5zcGFy ZW50IHN3aXRjaCBzdXBwb3NlZCB0byAiS05PVyIgd2hpY2ggbWFjIGFkZHJlc3MgaXMgdGhlIHNw ZWNpYWwgb25lIHRoYXQgc2hvdWxkIGJlICdzZXR1cCcgYXMgdGhlIGRsZXAgdGFyZ2V0LiAgSSB0 aGluayB0aGF0IHdvdWxkIHJlcXVpcmUgc29tZSBzcGVjaWFsIGNvbmZpZyB0aGF0IHRoZW4gaGFz IHRvIGJlIG1hbmFnZWQgKGFsc28gYnJlYWtpbmcgdHJhbnNwYXJlbmN5KSBhbmQgY3JlYXRpbmcg T0FNIGFuZCBjaGFuZ2UgbWFuYWdlbWVudCBpc3N1ZXMuIFJlbWVtYmVyIHRoZSBMQU4gaXMgbm90 ICdvdXInIGVxdWlwbWVudCwgc28gYWxsIHRoZSBzdWRkZW4gb25lIHdvdWxkIGhhdmUgdG8gZ2V0 IGFuZCBtYW5hZ2UgbWFjIGFkZHJlc3NlcyBmb3IgYWxsIHRoZXNlIHNpdGVzLiAgV2UgYXJlIGdv aW5nIEwyIGluLW9yZGVyIHRvIGhlbHAgdXMgYW5kIG91ciBjbGllbnRzIG5vdCB3b3JyeSBhYm91 dCBlYWNoIG90aGVyJ3MgZXF1aXBtZW50IGFuZCBuZXR3b3JraW5nLgo+Cj4KPiBXaGF0IGlzIHRo ZSB0eXBpY2FsIHVwdGltZSBvZiBhIGNsaWVudD8gQW5kIHdoYXQgcGVyY2VudGFnZSBvZiB0cmFm ZmljIGdvZXMgZnJvbSB0aGUgSHViIHRvIHRoZSBjbGllbnRzPyBBIHJvdWdoIGd1ZXNzIHdvdWxk IGJlIGdyZWF0IHRvIGJldHRlciB1bmRlcnN0YW5kIHlvdXIgcHJvYmxlbS4KPiBbQlNTXSAtIFR5 cGljYWwgdXB0aW1lIHdvdWxkIGJlIG1lYXN1cmVkIGluIGZyb20gaG91cnMgKE1heWJlIGEgcGxh bmUgbW92aW5nIGFjcm9zcyBzYXRlbGxpdGUgZm9vdHByaW50cykgdG8gaG9wZWZ1bGx5IHllYXJz IC0gYSBzdGF0aW9uYXJ5IG1vZGVtLiAgVGhvdWdoIHByYWN0aWNhbGx5IHRoYXTigJlzIG1heWJl IG1vcmUgbm9ybWFsbHkgbW9udGhzIGR1ZSB0byB3ZWF0aGVyLCB1cGdyYWRlcywgZXRjLgo+Cj4g SGVubmluZyBSb2dnZQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCj4gbWFuZXQgbWFpbGluZyBsaXN0Cj4gbWFuZXRAaWV0Zi5vcmcKPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Cgo= From nobody Fri Jul 25 10:18:37 2014 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 764141A035C for ; Fri, 25 Jul 2014 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 PYS2h0SENZqR for ; Fri, 25 Jul 2014 10:18:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A511A0345 for ; Fri, 25 Jul 2014 10:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2009; q=dns/txt; s=iport; t=1406308705; x=1407518305; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8jjMlFh105/45Yin/bWyUXEb3pUxn+HWRuPVfzQwjKg=; b=AnLo4Fi2AhiblCRiXP2fAf13OswK/qkaMCMNcOMDuepTTYn9kx0Q8kET tekIY8tx6eJT9jvUxbEz8RDN87T4WgzZ1R2+Ff1wEhUgrptiUAnarYBZK 0+RYLZy+7fQGfgC0p1LISRXmwPgSORZPpvQNXDGjwaAlWCIg7yX+k1HCG s=; X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="64052355" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 25 Jul 2014 17:18:24 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6PHIOlI010232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 17:18:24 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6PHIN1f005836; Fri, 25 Jul 2014 10:18:23 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6PHINZq005835; Fri, 25 Jul 2014 10:18:23 -0700 Date: Fri, 25 Jul 2014 10:18:22 -0700 From: "Toerless Eckert (eckert)" To: "Stan Ratliff (sratliff)" Message-ID: <20140725171822.GC7355@cisco.com> References: <20140725114000.GB7355@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343046909@VAUS-MBX03.idirect.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CrAWRG6jSng-21W5ze2l-1dizAs Cc: "manet@ietf.org" Subject: Re: [manet] DLEP/satellite - default destination 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, 25 Jul 2014 17:18:34 -0000 On Fri, Jul 25, 2014 at 04:25:18PM +0000, Stan Ratliff (sratliff) wrote: > Again, I'm completely and totally confused by this entire thread. > > For purposes of a DLEP discussion, I fail to see why the spoke side of SATCOM is nothing more than a subset of MESH. Essentially, it's a mesh with 1 destination - the hub. In an earlier email on this thread, the claim was made that DLEP wasn't designed for this case - I disagree. I think it will work just fine. I don't think that claim is valid, so lets assume we have moved beyond that. Yes, DLEP would work just fine, except that Bryan is claiming the following: If the spoke modems where to support indicating the correct MAC address of the hub router in the DLEP destination, then this would have one or two of the following downsides for the customer: 1) The operator of the SAT solution might need to manually provision the hub router MAC into the spoke modems, so that the modem can be lightweight and immediately announce that statically configured MAC in the destination as soon as it sees the RF being up. Aka: downside Opex overhead. 2) The hub side equipment would need to dynamically signal the hub router MAC address via RF protocols, and that would have to happen after the RF to the spoke is up and running, and that would increase the time until the spoke modem could announce that destination in DLEP and therefore make the bringup of the spoke slower. Aka: downside convergence speed. I am leaving out the argument "doing 2) would be more work for the modem vendor", because the proposed default-destination would be more work for the router vendor, and just shifting dev work in either direction doesn't seem to be a relevant customer benefit or downside, so not a good criteria. I may be wrong on that, so if there is a difference for the customer, we might consider this aspect too. Bryan: Is this summarizing it correctly ? Am i forgetting something ? Cheers Toerless From nobody Fri Jul 25 10:25:18 2014 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 EBCB11A01E2 for ; Fri, 25 Jul 2014 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 itB_wcP1vPt0 for ; Fri, 25 Jul 2014 10:25:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3C51A0400 for ; Fri, 25 Jul 2014 10:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1794; q=dns/txt; s=iport; t=1406309111; x=1407518711; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=J3Go0RV7o8kRuJwzQ11LRm8rYU138oqH30I+IxknnUc=; b=JpjcBX1voW1AQvLb0izbtHZzgNVChPtge3IYV+SDc2r8e59gtVMaccaa DfVS3RotWxeWDzSr6tinvUXKbB6IoLjuWFuVg6oM9dtUZAy4LhkFnZNT7 +g2W9NrK1+6qzzGk/IyuJuv1uO5nDwejhUjnLJWzyLSJ95Mcn+hytD9O1 4=; X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="339775198" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2014 17:25:10 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6PHPA9P028899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 17:25:10 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6PHP4mO006196; Fri, 25 Jul 2014 10:25:04 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6PHP32b006195; Fri, 25 Jul 2014 10:25:03 -0700 Date: Fri, 25 Jul 2014 10:25:03 -0700 From: Toerless Eckert To: Henning Rogge Message-ID: <20140725172503.GD7355@cisco.com> References: <20140725114000.GB7355@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JU3UwPY2zOnzqg6CyWYtBU2RDws Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - default destination 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, 25 Jul 2014 17:25:14 -0000 Henning: The DMAC used in the default destination DLEP announcement is a special value by which the router recognizes this to be a special destination. The router would not use this MAC address in actual data packets as a destination MAC address. Instead, it would solely use it to detect RF failure: When the default destination is withdrawn, then the router would have to immediately consider all actual destinations unreachable. This behavior would not change in the face of multiple headend device/routers. The spoke router would only learn about hub routers via their IGP hellos, and he would consider any hub router only reachable when the hub routers hello packets hae not timed out AND when he default-destination is announced. What the default destination does NOT help with - i think - is when there are two hub routers, and one of them goes offline. The spoke modem could of course not withdraf the default destination from DLEP. At best, the spoke modems could withdraw the default destination when the hub modem has no active DLEP session at all, aka: all hub routers down/unreachable. Hopefully Brian can chime in an reaffirm or reject that this is how he thinks this could work. Cheers Toerless On Fri, Jul 25, 2014 at 02:53:22PM +0200, Henning Rogge wrote: > On Fri, Jul 25, 2014 at 1:40 PM, Toerless Eckert wrote: > > And the question is now just how to encode that magic destination in > > DLEP. MAC broadcast may not be ideal, but maybe some othrer > > magic DMAC. All 0 ?. > > If the Hub end of the satellite link is connected to a switch (a few > routers), how does this magic ethernet thing work? Or is the > "destination Mac" completely optimized away and "regenerated" at the > Hub? > > Henning Rogge From nobody Fri Jul 25 10:28:48 2014 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 846321A01D2 for ; Fri, 25 Jul 2014 10:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 VdEyHr-85g-2 for ; Fri, 25 Jul 2014 10:28:46 -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 3F2F31A0240 for ; Fri, 25 Jul 2014 10:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1406309326; x=1407518926; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HhjSdtdbsn+lKLHim1yk5ImhmTiJX2vsPt6PdywbzGQ=; b=DQq8wj9DTzvqTF+xyLcIXWpOVe8nodZOGwwItUwwsY7XAYQAU49AUoIX r8ev6vEnwOQyj1Uzua24uPN20qWN75ne+4+MVTEZvggZFxulsx7XZdg7F sHIEVrwtsTNwimdVmnsRHs6yIM0QYVHO1z99aqP0C5FrZ77Cge6a3Yhi5 E=; X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="64067393" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 25 Jul 2014 17:28:45 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6PHSjSZ031263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 17:28:45 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6PHSERG006501; Fri, 25 Jul 2014 10:28:14 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6PHS81o006420; Fri, 25 Jul 2014 10:28:08 -0700 Date: Fri, 25 Jul 2014 10:28:08 -0700 From: Toerless Eckert To: Rick Taylor Message-ID: <20140725172808.GE7355@cisco.com> References: <20140725113109.GA7355@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB2E3@tss-server1.home.tropicalstormsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB2E3@tss-server1.home.tropicalstormsoftware.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/J8fIiQHzuSDAg7DDxB1BjUNG7IE Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - how to arp 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, 25 Jul 2014 17:28:47 -0000 On Fri, Jul 25, 2014 at 01:46:03PM +0000, Rick Taylor wrote: > > 1) Non-Broadcast-Multi-Access radio network. Sending of ethernet > multicast/broadcast not supported. Therefore ARP does not work. Therefore > DLEP must announce MAC and IP address of destinations. > > This (I believe) is beyond the scope of core DLEP. I have kit like this, hence my proposed extension, but I would be very happy to merge my work into the core spec. Oh. That makes me surprised. I thought this is the use case why DLEP can signal not only MAC address, but also IP-address of destinations. If not for this use-case, what then is the signaling of the IP-address of a destination good for ? > > > 2) Broadcast multi-access nework, eg: Satellite. Sending of ethernet > multicast/broadcast supported, ARP works, DLEP does not need to carry > destination IP-addresses, DLEP not required to supplant ARP. > > This is the mode DLEP was developed to address, and expects the modems to operate in. > > > 3) Something else: radio network expects routers to insert any DMAC > other than the natural destination MAC address of a destination into > unicast IP packets. Like some default MAC address. > > This I believe is what Brian thinks he needs, not at the packet level, but as a DLEP identifier (which re-uses the MAC). But my (new) opinion is that 'wildcard' destinations might create more problems than they solve. I don't think what Brian is asking for is unreasonable, in giant hub-spoke networks there has to be a way to manage the load on the spoke DLEP modem agent, I'm just not sure we have the recommended solution for him yet. Right, but when we only do this at the DLEP level, thats the other mail thread. Here i am just trying to figure out if there are any use cases expecting that routers fudge around with actual data packet DMACs. And i am happy if not ;-) Cheers Toerless From nobody Fri Jul 25 10:49:29 2014 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 892411A031C for ; Fri, 25 Jul 2014 10:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_65=0.6, 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 pqD5Xa4E-UgW for ; Fri, 25 Jul 2014 10:49:24 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315A71A02DF for ; Fri, 25 Jul 2014 10:49:24 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so1152219igb.16 for ; Fri, 25 Jul 2014 10:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fkAapkfo4sJ4PVz6C1PglmhKSLKEZ+aEPCCEpTR2b9I=; b=GmkOJWq+jLfUlvXOSgnZWXZiVaZnsrR4rgag2CfgwFllc8WXI7EHzQbGlt0+5GyQWT TBDt1XKdHbxn/BoSMWQr69WaiZsquLMk3bhF4ZWOI8GUnELL3w5yPJEkK4J1FJEA0KfX Zfken6A+Zvlxz3ZjwiLJkKY4rQ0aPO71r0mPT4A72kwMFM7xsHEMrvfCRkKL2/cjjJ1D kCzc7W8des/fLvAEVqlDLmkvSO39R2vEvK8jokZHulLfowmeHJkjQfM5hA5JB+c+ydnq EtKIms4JhD/7IpdERQ0HkK6OXeC3Ir4DA4p2uQB8cm7Ctu1o6fH2qY5tqvm8bTfYDYEE qPeQ== X-Received: by 10.50.56.38 with SMTP id x6mr7828493igp.30.1406310563622; Fri, 25 Jul 2014 10:49:23 -0700 (PDT) Received: from [10.2.2.8] (dynamic-acs-24-144-141-5.zoominternet.net. [24.144.141.5]) by mx.google.com with ESMTPSA id ci7sm6502705igb.11.2014.07.25.10.49.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 10:49:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Shawn Jury In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> Date: Fri, 25 Jul 2014 13:49:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> To: "Snyder, Brian" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/EKe2XOhGWo771yaTN_X3b3BPxuU Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Request to consider for DLEP 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, 25 Jul 2014 17:49:27 -0000 Brian, I'm curious about how your BFD proxy would work in this case. Since = you are not letting the BFD packets go between the two sites (MDM1 and = MDM2 for example), how does MDM1 know when to tell RTR1 that MDM2 is = gone and BFD should tear down the IGP session between the devices, = especially since you would still need a BFD session for each VLAN? In = my mind, I'm seeing this mechanic as the same one that is needed for = DLEP to work. Shawn On Jul 25, 2014, at 12:37 PM, Snyder, Brian wrote: > embedded.... >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: Friday, July 25, 2014 12:30 PM > To: Snyder, Brian > Cc: Rick Taylor; Henning Rogge; manet@ietf.org > Subject: Re: [manet] Request to consider for DLEP >=20 >=20 > On Jul 25, 2014, at 12:24 PM, "Snyder, Brian" > wrote: >=20 >> Rick, >>=20 >>> Ah-ha!! The DLEP destination MAC is defined very specifically as the = MAC address of the interface that the router is using for the TCP = session to the local modem. The router may have a billion other MAC = addresses, but only that one is important. In the >spoke case, the same = applies, and if the spokes don't need to know about other spokes, don't = tell them. >>=20 >> Hold on. I thought it was the MAC address of the far side router = (otherwise it would still need to arp). Your comment --- the LOCAL = modem would greatly change the issue in my mind --- but how does knowing = a local MAC help L3 converge any faster - that would mean it still needs = to arp or mcast hello to find far side guys so I don=E2=80=99t = understand then how the 'fast-start' stuff works you were discussing as = the point of this..... >>=20 >> In this diagram below: >>=20 >>=20 >> = |----- MDM1 ---- RTR1 --- NET1 >> = | >> UpRtr ----- SatHUB ------ OUTERSPACE ---------- MDM2 ---- RTR2 = --- NET2 >> = | >> = |----- MDM3 ---- RTR3 --- NET3 >>=20 >>=20 >> Let's say RTR1, RTR2, and RTR3 all want to make a [OSPF|EIGRP|BGP] = neighbor to UpRTR. UPRTR wants 3 neighbors. There are 2 vlans on each. >=20 > *By definition*, UpRtr in this case has 6 neighbors, not 3. Each VLAN = is a neighbor. >=20 > [BSS] - That=E2=80=99s what I expected. >=20 >>=20 >> What does MDMX have to tell RTRX via DLEP? How many MAC Addresses = (Multiple VLANS) and which ones? >=20 > That's the rub. MDM1, for example, can tell RTR1 *only* about UpRtr. = (Specifically, the VLANS on UpRtr). So, while UpRtr has 6 neighbors (but = we've already said the hub isn't the problem), RTR1 only sees 2.=20 >=20 >=20 > [BSS] - Right. that=E2=80=99s what I was expecting the answer to be. = But then it isn=E2=80=99t the local MAC address RTR1 needs, its UPRTR = MAC Address - he is telling him about the REMOTE mac, not local... which = means the MDMs would need to be configured to know what that is (per = VLAN - even though itll most likely always be the same). >=20 > Now if we want NET1 to talk to NET2 - then I'm assuming the RTR2 mac = has to be told to RTR1 as well via DLEP too. Correct? So then, instead = of letting the RTRN find RTRN' naturally the way a bunch of routers on = an IGP would, MDMN would have to tell RTRN about the entire set of RTRs = (that aren't himself). =20 >=20 > That's what I'm hearing from this conversation... you have to tell = them EVERY specific destination. Now all the sudden, in this VPLS = architecture and using DLEP, the MDMs have to maintain a MAC to MDM map = that could be HUGE. I don't think this is the part that scales. >=20 > If I'm in VPWS mode (NET1 can't see NET2) then I agree - it's not that = hard of a problem to solve - though there still needs to be additional = OAM knowledge on the MDM which breaks my transparency design - but I = could maybe live with that if it was a bounded set of say 12 MACs (# of = VLANs expected to getting routing peers on per modem - worst case). >=20 >=20 > Are my extrapolations here correct? >=20 > Thanks,brian >=20 >=20 > Stan >=20 >=20 >>=20 >>=20 >> Now what if while the RF system is not MESH, I am allowing = hairpinning (VPLS mode).... So NET1 can talk to NET2 via SatHUB. Then = what do they all have learn? >>=20 >>=20 >>=20 >> Maybe a concrete example will help this sink in. >>=20 >> Thanks, >> Brian >>=20 >>=20 >> -----Original Message----- >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=20 >> Sent: Friday, July 25, 2014 10:29 AM >> To: Snyder, Brian; Henning Rogge >> Cc: manet@ietf.org >> Subject: RE: [manet] Request to consider for DLEP >>=20 >> Inline comments.... >>=20 >>>> As I see it, your problem is along the lines of "OMG, I have = 10,000's spokes and I can't have a master list of spoke router MACs, and = I don't want to report 10,000's DLEP sessions everywhere when spokes can = really only talk to the hub". And my answer is, "You don't have to = report everything, all the time, and you can learn the MACs at runtime." >>=20 >>> Yes, that is a concern of mine... but not the only one. I = understand I only have to report what I want too but I'm also concerned = with the notion I can auto-learn it. How would I know, in a VPLS = network which mac is the upstream router? I could be inundated with MACs = from all over the network. Maybe some I'd care about and some I = wouldn't. But I certainly couldn't track them individually. I have no = idea of another modems state. I only know MY state in relation to the = hub - IE: am I in network or not. Also recognize that if I have a = hundred thousand MAC addresses and I had to track them all -- well a = common design with our networks is for people to use multiple SVNs = (vlans/qinqs) tags PER modem. Many designs have 12 each. Our namespaces = are kept separately.... so a hundred thousand modems with 12 vlans would = be 1.2 MILLION macs that could potentially be seen. >>=20 >> Ah-ha!! The DLEP destination MAC is defined very specifically as the = MAC address of the interface that the router is using for the TCP = session to the local modem. The router may have a billion other MAC = addresses, but only that one is important. In the spoke case, the same = applies, and if the spokes don't need to know about other spokes, don't = tell them. >>=20 >>> Granted, I don=E2=80=99t think that scale is going to be roll out #1 = of DLEP use case - but we do have customers operating at that scale. If = 'DLEP' feature gets released - they will want to use it. >>=20 >> Absolutely, which is why I and others are spending some cycles to get = this sorted. >>=20 >>> No modem currently tracks any MACs from the hub side for this reason = -- and we don't need too (yet:)). >>=20 >> Hopefully my answer above will have helped? >>=20 >> Rick >>=20 >> -----Original Message----- >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >> Sent: Friday, July 25, 2014 10:05 AM >> To: Snyder, Brian; Henning Rogge >> Cc: manet@ietf.org >> Subject: RE: [manet] Request to consider for DLEP >>=20 >> Top-posted... >>=20 >> Sorry Brian, >>=20 >> I think my understanding of your problem might still be wrong, but = I'll make some suggestions anyway... >>=20 >> You don't need to preconfigure the spoke router MAC that gets sent to = the hub because you can learn it from the endpoints of the spoke DLEP = session. Then when an RF link is established, you send it up to the = hub, and it can report it through it's local DLEP session, and = vice-versa. >>=20 >> You don't need to report all destinations in all sessions, only = relevant destinations. So in the spoke modem, you only need to report = the hub MAC in the common case, unless you have turned on hair-pinning = for some subset of spokes, in which case you only need to report those = addressable MACs as DLEP destinations. >>=20 >> As I see it, your problem is along the lines of "OMG, I have 10,000's = spokes and I can't have a master list of spoke router MACs, and I don't = want to report 10,000's DLEP sessions everywhere when spokes can really = only talk to the hub". And my answer is, "You don't have to report = everything, all the time, and you can learn the MACs at runtime." >>=20 >> Cheers, >> Rick >>=20 >> ________________________________________ >> From: Snyder, Brian [bsnyder@idirect.net] >> Sent: 25 July 2014 14:37 >> To: Henning Rogge >> Cc: Rick Taylor; manet@ietf.org >> Subject: RE: [manet] Request to consider for DLEP >>=20 >> Embedded.... >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@gmail.com] >> Sent: Friday, July 25, 2014 2:36 AM >> To: Snyder, Brian >> Cc: Rick Taylor; manet@ietf.org >> Subject: Re: [manet] Request to consider for DLEP >>=20 >> On Fri, Jul 25, 2014 at 12:51 AM, Snyder, Brian = wrote: >>> [BSS] =E2=80=93 And I guess I am looking for something different. = I=E2=80=99m looking for link state notifications (with metrics) to - = and this is a different #2 =E2=80=93 allow a routing protocol to be = tuned for minimum KEEP ALIVE timers to minimize bandwidth usage to = conserve very expensive and limited bandwidth. In a satellite network, = there is no need for fast-starts, L1 convergence can (and in a suitably = sized network will take seconds). However, because modems tend to stay = in network quite stably (trees and buildings don=E2=80=99t get the way = often in the ocean=E2=98=BA), the building of adjacencies does not = happen all that often. It=E2=80=99s way more important to me to conserve = bandwidth and be transparent. >>=20 >> I must admit I still fail to see why a special case is even = necessary. >>=20 >> [BSS] - Perhaps not necessary - but I'm very concerned with trying to = optimize for scale and transparency. >>=20 >> We are talking about a network with hundred thousands clients = connected via satellite to a Hub station. Yes, so we need to make sure = that the clients don't talk more than necessary. >>=20 >> But you said your client satellite modems are able to receive = broadcast traffic... and maybe even unicasts delivered to a different = client. This means pushing information from the Hub to all clients is = reasonable cheap. >> [BSS] - They won't receive unicast for someone else. HDLC addressing = demuxes that. Pushing broadcast is cheap. IE: ARPs can flow freely and = cheaply on the downstream. >>=20 >> This means transferring the Mac address to a client is dirt cheap, = especially if Layer-2 at the Hub is able to tell that a new client = connected to the satellite. >> [BSS] - In this case transferring a mac address is cheap - the arp's = do it through us -- though the modems currently don't track and record = any of the learnt address OTA... we just let the customer devices do = what they should do by all normal conventions. (ARP, timers, etc). = Modems have no notion of weather or not another modem is in or out of = network. No star system would. They just track themselves. So if MAC = addresses are supposed to be stored and managed by the modem for DLEP = management automatically, we a) aren't transparent anymore b) Have a = scale problem managing all those macs c) If there are more mac addresses = (not routers we would care about via dlep) how is a transparent switch = supposed to "KNOW" which mac address is the special one that should be = 'setup' as the dlep target. I think that would require some special = config that then has to be managed (also breaking transparency) and = creating OAM and change management issues. Remember the LAN is not 'our' = equipment, so all the sudden one would have to get and manage mac = addresses for all these sites. We are going L2 in-order to help us and = our clients not worry about each other's equipment and networking. >>=20 >>=20 >> What is the typical uptime of a client? And what percentage of = traffic goes from the Hub to the clients? A rough guess would be great = to better understand your problem. >> [BSS] - Typical uptime would be measured in from hours (Maybe a plane = moving across satellite footprints) to hopefully years - a stationary = modem. Though practically that=E2=80=99s maybe more normally months due = to weather, upgrades, etc. >>=20 >> Henning Rogge >> _______________________________________________ >> 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 Fri Jul 25 12:55:41 2014 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 272151A037A for ; Fri, 25 Jul 2014 12:55:37 -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 nznUka_6WwOC for ; Fri, 25 Jul 2014 12:55:35 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435031A03BE for ; Fri, 25 Jul 2014 12:55:35 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so8294907vcb.10 for ; Fri, 25 Jul 2014 12:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=06WCkTr7xR4G3yMejgScTlgtod0ejLpF7ezTKdoBVVk=; b=a2vUmJAI8TMcqfAPIVuXIXsk6uPJsZkxlVisYcWfeDdRpZHwIWHZiWuqc7eC+CpLh0 Bk4t0GONAw2BIGPVMBXXvmCPgpT0bTlGU6+xPSWvEvsImviFwMGSTVYdurPIWTBAwuXD f2YS5yaFjs3U+TWQDji00txkHOKmP5edpGhx0= 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:content-type; bh=06WCkTr7xR4G3yMejgScTlgtod0ejLpF7ezTKdoBVVk=; b=H8UMSXRnUAzORxiMG41T4XalvV/Rw4QlNM+mb3UDJULio9Vx08jeMRHbtsG/r2Bvk0 90Iiyb8cEHOMFOEli/KNl7jXygvxwFBfSj7K5O8JM8rQxaLejYLl6G3CqsF4Dz19gqrK 7f4JUA6ByMOYziUaGk8BRy1DvcVFrhkMkwfENslMaGz70rnJ2Iw4OvFOZIb9OqPLdZ/K 9T3ybCTSVc5YxLlhHaOtwhgzoicpq7OYplnMR8w2UnHzn0xf7yQGA97e6M0PnvAcTiZe +QMKZTUeRdiN31G86Jro91q9JhxCuSP19NRkwLOtrsivDisakmb9fncMf0FFmAOJuMAp ZqkQ== X-Gm-Message-State: ALoCoQlV5lDMhYEFF+MF3EvRYYjvTlg4qrwIHRM7AdoZ6iRNdFELjCd6DYxhvhEGiV6uuHDDcDDw MIME-Version: 1.0 X-Received: by 10.220.160.67 with SMTP id m3mr5126120vcx.56.1406318133251; Fri, 25 Jul 2014 12:55:33 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Fri, 25 Jul 2014 12:55:33 -0700 (PDT) In-Reply-To: <20140725193054.19479.42522.idtracker@ietfa.amsl.com> References: <20140725193054.19479.42522.idtracker@ietfa.amsl.com> Date: Fri, 25 Jul 2014 15:55:33 -0400 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PG1wLbgitzZRqaelC28sB7dwbos Subject: [manet] Fwd: New Version Notification for draft-clausen-manet-rfc6779bis-00.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, 25 Jul 2014 19:55:37 -0000 Hi, we have posted a new draft that obsoletes RFC6779 (NHDP-MIB) and that extends it according to what is specified in section 6 of draft-ietf-manet-nhdp-optimization. The logical next step would be to submit an update to draft-ietf-manet-nhdp-optimization (with section 6 removed). If we adopt draft-clausen-manet-rfc6779bis-00, we can then proceed to WGLC and progression of both these documents together. WG chairs, given that the changes were only the ones that are specified in section 6 of draft-ietf-manet-nhdp-optimization (which is adopted by the WG), can we submit this MIB update as draft-ietf-manet-rfc6779bis? Besides the requested changes specified in section 6 of draft-ietf-manet-nhdp-optimization, there was no change of the MIB module (other than a handful of minor editorial edits): http://tools.ietf.org/rfcdiff?url1=rfc6779.txt&url2=draft-clausen-manet-rfc6779bis-00.txt Regards Ulrich ---------- Forwarded message ---------- From: Date: Fri, Jul 25, 2014 at 3:30 PM Subject: New Version Notification for draft-clausen-manet-rfc6779bis-00.txt To: Ian D Chakeres , Ulrich Herberg , "Thomas H. Clausen" , "Robert G. Cole" , Thomas Heide Clausen A new version of I-D, draft-clausen-manet-rfc6779bis-00.txt has been successfully submitted by Ulrich Herberg and posted to the IETF repository. Name: draft-clausen-manet-rfc6779bis Revision: 00 Title: Definition of Managed Objects for the Neighborhood Discovery Protocol Document date: 2014-07-25 Group: Individual Submission Pages: 70 URL: http://www.ietf.org/internet-drafts/draft-clausen-manet-rfc6779bis-00.txt Status: https://datatracker.ietf.org/doc/draft-clausen-manet-rfc6779bis/ Htmlized: http://tools.ietf.org/html/draft-clausen-manet-rfc6779bis-00 Abstract: This document revises, extends, and replaces RFC 6779. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Jul 26 07:26:13 2014 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 CCDD51B282B for ; Sat, 26 Jul 2014 07:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 yeCS6DDMEeNy for ; Sat, 26 Jul 2014 07:26:09 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 1E9291B2827 for ; Sat, 26 Jul 2014 07:26:09 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Sat, 26 Jul 2014 15:25:44 +0100 From: Rick Taylor To: Stan Ratliff , "manet@ietf.org" Thread-Topic: DLEP proposal Thread-Index: Ac+o3XvLRUL7CWhaQo6Djlcvb9S7qg== Date: Sat, 26 Jul 2014 14:25:43 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB 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: http://mailarchive.ietf.org/arch/msg/manet/7w5uKo0I21tsKis-OarNuZCn688 Subject: [manet] DLEP proposal 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: Sat, 26 Jul 2014 14:26:11 -0000 Stan, All,=0A= =0A= As DLEP starts to get picked up and looked at, an increasing number of pote= ntial implementers keep getting confused about what we within the DLEP DT s= ee as a simple issue: Destination MAC addresses.=0A= =0A= As I have stated before, DLEP uses MAC addresses for 2 distinct purposes: 1= ) As a destination discriminator/identifier, 2) To advertise the attached r= outer's MAC address.=0A= =0A= Ignoring the specifics of my unusual use-case of layer-3 modems, in my draf= t extension I suggest changing destination MAC addresses to unique numeric = identifiers generated by the modem. On consideration I think it makes more= sense to do this for core DLEP, and add the MAC address as a data-item TLV= , much like layer-3 addresses are currently handled.=0A= =0A= Hopefully this will make the DLEP model more obvious to newcomers: A desti= nation has an ID, and some data-items describing it, one of which MUST be a= MAC address TLV. The semantics of the protocol are unchanged, we don't ca= re about extra octets on the local link (in principle), and the meaning mig= ht be clearer to readers.=0A= =0A= I would suggest a 32-bit destination identifier, and I assume that most RF = equipment has some concept of a 'link id' that might be reusable/mappable i= n the DLEP agent, so I don't believe it adds extra burden on implementers.= =0A= =0A= The MAC address TLV should be obvious to formulate: Type =3D TBD, Length = =3D 6, Value =3D MAC octets. Unlike IP address TLVs there is no need for A= dd/Drop indicators.=0A= =0A= It has the advantage that the DLEP draft text can talk about destinations a= s concept in one section, and then discuss router MACs and addresses in ano= ther discrete section, hopefully avoiding some first-pass confusion in the = reader.=0A= =0A= The only thing this proposal breaks is multicast destinations, but having h= ad a long chat with Toerless Eckert who is heavily involved in the PIM WG, = we may not have thought through the multicast/anycast/broadcast part of DLE= P thoroughly yet (and that requires a new thread). =0A= =0A= It also might solve a use-case problem we have skirted around: 1 modem with= 2 DLEP sessions to 2 routers. With this proposal, a single set of destina= tion identifiers could be used, and 2 MAC TLV's added to the destination up= , i.e. "I have two upstream routers, go chat..."=0A= =0A= Lobbying for one of my corner-cases, I would suggest that the Destination U= p signal text states something like: "A destination up signal MUST include = 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV. It SHOULD p= rovide a MAC address TLV, and it is RECOMMENDED that at least 1 IPv4 or IPV= 6 address TLV be included." =0A= =0A= As I think about it, MAC-less destinations with IP multicast addresses/subn= ets might be the better way to handle multicast destinations...=0A= =0A= Anyway, "fire in the hole!"=0A= =0A= Cheers,=0A= =0A= Rick=0A= =0A= =0A= From wuxiong.zhang@wico.sh Sat Jul 26 07:44:01 2014 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 0BA721B282F for ; Sat, 26 Jul 2014 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 f2HKtO0k-mmk for ; Sat, 26 Jul 2014 07:43:57 -0700 (PDT) Received: from mail.wico.sh (mail.wico.sh [112.64.125.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA1C1B282B for ; Sat, 26 Jul 2014 07:43:55 -0700 (PDT) X-Footer: d2ljby5zaA== Received: from [112.64.61.145] ([112.64.61.145]) by mail.wico.sh (Kerio Connect 7.3.0) for manet@ietf.org; Sat, 26 Jul 2014 22:44:18 +0800 From: =?utf-8?Q?=E5=BC=A0=E6=AD=A6=E9=9B=84?= To: manet@ietf.org Organization: shrcwc Message-ID: <20140726144418.e77b9632@mail.wico.sh> Date: Sat, 26 Jul 2014 14:44:18 +0000 X-Mailer: Kerio Connect 7.3.0 WebMail X-User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-----------a9325a6093acf938ed728b3604cf9263" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aMD1F0BjGPeymKG1c0GqUCPJb5I Subject: [manet] Postdoc Positions, ShanghaiTech University 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: Sat, 26 Jul 2014 14:48:55 -0000 This is a multi-part message in MIME format. -------------a9325a6093acf938ed728b3604cf9263 Content-Type: multipart/alternative; boundary="-----------1d9c3b8a331b512ac4975899aea01e26" -------------1d9c3b8a331b512ac4975899aea01e26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Professor Yang Yang (http://sist.shanghaitech.edu.cn/StaffDetail.asp=3Fi= d=3D4) and his group is currently working on several key research projec= ts in the areas of LTE/5G systems, wireless sensor networks & Internet o= f Things, and heterogeneous wireless networks, which have been generousl= y funded by the 863 Hi-Tech R&D program (MOST), the National Science and= Technology Major Project (MIIT), the National Natural Science Foundatio= n of China (NSFC), and Shanghai local government (STCSM). The group is e= quipped with state-of-the-art research facilities and equipments, worth = more than 10M US dollars.=20 We invite highly motivated individuals with a Ph.D. degree to work with = us on data analysis, information retrieval, autonomous intelligent contr= ol, system modeling, and algorithm/application developments across heter= ogeneous sensor networks.=20 Qualifications:=20 (1) PhD degree in electrical/electronic engineering, computer science, a= utomatic control, or related areas. (2) Solid research experience in communication networks, data sciences, = channel/network/traffic measurement and modeling, intelligent systems, p= erformance analysis and optimization, wireless sensor networks or intern= et of things.=20 (3) Good publication track record or system design and implementation ex= periences.=20 (4) Strong mathematical skills and system simulation development experie= nces. (5) Good communication skills and capability of supervising research stu= dents.=20 (6) Fluent in oral and written English.=20 Applications: Qualified applicants are invited to submit (all in English) a cover lett= er, a CV including copies of 2/3 representative publications, and three = letters of reference to: hr-sist@shanghaitech.edu.cn (cc to yangyang@sha= nghaitech.edu.cn). We provide very competitive salary and benefits for t= his post.=20 Deadline: August 31st, 2014 -- ShanghaiTech University Email: YangYang@ShanghaiTech.edu.cn New Book: Heterogeneous Cellular Networks http://www.cambridge.org/9781107023093 =20 -------------1d9c3b8a331b512ac4975899aea01e26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Professor Yang Yang (http://sist.shanghaitech.edu.cn/StaffDetail.asp=3Fid=3D4)<= span style=3D"font-family: Arial; font-size: 14px; line-height: 23.79999= 9237060547px; background-color: rgb(255, 255, 255);"> and his group is currently working on= several key research projects in the areas of LTE/5G systems, wireless = sensor networks & Internet of Things, and heterogeneous wireless net= works, which have been generously funded by the 863 Hi-Tech R&D prog= ram (MOST), the National Science and Technology Major Project (MIIT), th= e National Natural Science Foundation of China (NSFC), and Shanghai loca= l government (STCSM). The group is equipped with state-of-the-art resear= ch facilities and equipments, worth more than 10M US dollars. 


Qualifications: 
(1) PhD degree i= n electrical/electronic engineering, computer science, automatic control= , or related areas.
(2) Solid research experience in communication networks, d= ata sciences, channel/network/traffic measurement and modeling, intellig= ent systems, performance analysis and optimization, wireless sensor netw= orks or internet of things. 
(3) Good publication track record or system = design and implementation experiences. 
(4) Strong mathematical skills an= d system simulation development experiences.
(5) Good communication skills and= capability of supervising research students. 
(6) Fluent in oral and wri= tten English. 

Applications:
Qualified applicants are invited to su= bmit (all in English) a cover letter, a CV including copies of 2/3 repre= sentative publications, and three letters of reference to: <= /span>hr-sist@shanghaitech.edu.cn&nbs= p;(cc to yangyang@shanghaitech.edu.cn). We provide very competitive salary and benefits for this = post. 

Deadline: August 31st, 2014

--
ShanghaiTech Universi= ty
Ema= il: YangYang@ShanghaiTech.edu.cn
New Book: Heterogeneous Cell= ular Networks
= = http://www.cambridge.org/9781107023093
-------------1d9c3b8a331b512ac4975899aea01e26-- -------------a9325a6093acf938ed728b3604cf9263 Content-Type: application/msword Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Postdoc-YangYang.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOAAAAAAAAAAA EAAAOwAAAAEAAAD+////AAAAADcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEABoAJBAAA8FK/AAAAAAAAEAAAAAAACAAApg8AAA4AYmpiarSitKIAAAAAAAAAAAAAAAAAAAAA AAAECBYAOBoAANbIAADWyAAAmAcAAAAAAAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAGYHAAAAAAAAZgcAAK8U AAAAAAAArxQAAAAAAACvFAAAAAAAAK8UAAAAAAAArxQAABQAAAAAAAAAAAAAAP////8AAAAAwxQA AAAAAADDFAAAAAAAAMMUAAA4AAAA+xQAABwAAAAXFQAAFAAAAMMUAAAAAAAAXRwAAKgBAAArFQAA AAAAACsVAAAAAAAAKxUAAAAAAAArFQAAAAAAACsVAAAAAAAAXxYAAAAAAABfFgAAAAAAAF8WAAAA AAAA3BsAAAIAAADeGwAAAAAAAN4bAAAAAAAA3hsAAAAAAADeGwAAAAAAAN4bAAAAAAAA3hsAACQA AAAFHgAAogIAAKcgAAA6AAAAAhwAABUAAAAAAAAAAAAAAAAAAAAAAAAArxQAAAAAAABfFgAAAAAA AAAAAAAAAAAAAAAAAAAAAABfFgAAAAAAAF8WAAAAAAAAXxYAAAAAAABfFgAAAAAAAAIcAAAAAAAA AAAAAAAAAACvFAAAAAAAAK8UAAAAAAAAKxUAAAAAAAAAAAAAAAAAACsVAAA0AQAAFxwAABYAAABd FwAAAAAAAF0XAAAAAAAAXRcAAAAAAABfFgAAoAAAAK8UAAAAAAAAKxUAAAAAAACvFAAAAAAAACsV AAAAAAAA3BsAAAAAAAAAAAAAAAAAAF0XAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAXxYAAAAAAADcGwAAAAAAAAAAAAAAAAAAXRcAAAAAAABdFwAA HgAAANYZAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIhoAAAAAAAArFQAAAAAAAP////8AAAAAcOehSTKg zwEAAAAAAAAAAMMUAAAAAAAA/xYAAAAAAADuGQAACAAAAAAAAAAAAAAAyBsAABQAAAAtHAAAMAAA AF0cAAAAAAAA9hkAACwAAADhIAAAAAAAAP8WAABeAAAA4SAAABAAAAAiGgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi GgAALgEAAOEgAAAAAAAAAAAAAAAAAACvFAAAAAAAAFAbAAB4AAAAXxYAAAAAAABfFgAAAAAAAF0X AAAAAAAAXxYAAAAAAABfFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXxYA AAAAAABfFgAAAAAAAF8WAAAAAAAAAhwAAAAAAAACHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAXRcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8WAAAA AAAAXxYAAAAAAABfFgAAAAAAAF0cAAAAAAAAXxYAAAAAAABfFgAAAAAAAF8WAAAAAAAAXxYAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAOEgAAAAAAAAXxYAAAAAAABf FgAAAAAAAF8WAAAAAAAAXxYAAAAAAABfFgAAAAAAAF8WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfFgAAAAAAAF8WAAAAAAAAXxYA AAAAAABmBwAADwwAAHUTAAA6AQAABQASAQAACQQECAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBvc3Rk b2MgUmVzZWFyY2ggRmVsbG93IFBvc2l0aW9uIGluIHRoZSBTY2hvb2wgb2YgSW5mb3JtYXRpb24g U2NpZW5jZSBhbmQgVGVjaG5vbG9neSwgU2hhbmdoYWlUZWNoIFVuaXZlcnNpdHkNDVByb2Zlc3Nv ciBZYW5nIFlhbmcgKGh0dHA6Ly9zaXN0LnNoYW5naGFpdGVjaC5lZHUuY24vU3RhZmZEZXRhaWwu YXNwP2lkPTQpIGFuZCBoaXMgZ3JvdXAgaXMgY3VycmVudGx5IHdvcmtpbmcgb24gc2V2ZXJhbCBr ZXkgcmVzZWFyY2ggcHJvamVjdHMgaW4gdGhlIGFyZWFzIG9mIExURS81RyBzeXN0ZW1zLCB3aXJl bGVzcyBzZW5zb3IgbmV0d29ya3MgJiBJbnRlcm5ldCBvZiBUaGluZ3MsIGFuZCBoZXRlcm9nZW5l b3VzIHdpcmVsZXNzIG5ldHdvcmtzLCB3aGljaCBoYXZlIGJlZW4gZ2VuZXJvdXNseSBmdW5kZWQg YnkgdGhlIDg2MyBIaS1UZWNoIFImRCBwcm9ncmFtIChNT1NUKSwgdGhlIE5hdGlvbmFsIFNjaWVu Y2UgYW5kIFRlY2hub2xvZ3kgTWFqb3IgUHJvamVjdCAoTUlJVCksIHRoZSBOYXRpb25hbCBOYXR1 cmFsIFNjaWVuY2UgRm91bmRhdGlvbiBvZiBDaGluYSAoTlNGQyksIGFuZCBTaGFuZ2hhaSBsb2Nh bCBnb3Zlcm5tZW50IChTVENTTSkuIFRoZSBncm91cCBpcyBlcXVpcHBlZCB3aXRoIHN0YXRlLW9m LXRoZS1hcnQgcmVzZWFyY2ggZmFjaWxpdGllcyBhbmQgZXF1aXBtZW50cywgd29ydGggbW9yZSB0 aGFuIDEwTSBVUyBkb2xsYXJzLiANDVdlIGludml0ZSBoaWdobHkgbW90aXZhdGVkIGluZGl2aWR1 YWxzIHdpdGggYSBQaC5ELiBkZWdyZWUgdG8gd29yayB3aXRoIHVzIG9uIGRhdGEgYW5hbHlzaXMs IGluZm9ybWF0aW9uIHJldHJpZXZhbCwgYXV0b25vbW91cyBpbnRlbGxpZ2VudCBjb250cm9sLCBz eXN0ZW0gbW9kZWxpbmcsIGFuZCBhbGdvcml0aG0vYXBwbGljYXRpb24gZGV2ZWxvcG1lbnRzIGFj cm9zcyBoZXRlcm9nZW5lb3VzIHNlbnNvciBuZXR3b3Jrcy4gDQ1RdWFsaWZpY2F0aW9uczogDQ0o MSkgUGhEIGRlZ3JlZSBpbiBlbGVjdHJpY2FsL2VsZWN0cm9uaWMgZW5naW5lZXJpbmcsIGNvbXB1 dGVyIHNjaWVuY2UsIGF1dG9tYXRpYyBjb250cm9sLCBvciByZWxhdGVkIGFyZWFzLg0NKDIpIFNv bGlkIHJlc2VhcmNoIGV4cGVyaWVuY2UgaW4gY29tbXVuaWNhdGlvbiBuZXR3b3JrcywgZGF0YSBz Y2llbmNlcywgY2hhbm5lbC9uZXR3b3JrL3RyYWZmaWMgbWVhc3VyZW1lbnQgYW5kIG1vZGVsaW5n LCBpbnRlbGxpZ2VudCBzeXN0ZW1zLCBwZXJmb3JtYW5jZSBhbmFseXNpcyBhbmQgb3B0aW1pemF0 aW9uLCB3aXJlbGVzcyBzZW5zb3IgbmV0d29ya3Mgb3IgaW50ZXJuZXQgb2YgdGhpbmdzLiANDSgz KSBHb29kIHB1YmxpY2F0aW9uIHRyYWNrIHJlY29yZCBvciBzeXN0ZW0gZGVzaWduIGFuZCBpbXBs ZW1lbnRhdGlvbiBleHBlcmllbmNlcy4gDQ0oNCkgU3Ryb25nIG1hdGhlbWF0aWNhbCBza2lsbHMg YW5kIHN5c3RlbSBzaW11bGF0aW9uIGRldmVsb3BtZW50IGV4cGVyaWVuY2VzLg0NKDUpIEdvb2Qg Y29tbXVuaWNhdGlvbiBza2lsbHMgYW5kIGNhcGFiaWxpdHkgb2Ygc3VwZXJ2aXNpbmcgcmVzZWFy Y2ggc3R1ZGVudHMuIA0NKDYpIEZsdWVudCBpbiBvcmFsIGFuZCB3cml0dGVuIEVuZ2xpc2guIA0N QXBwbGljYXRpb25zOg0NUXVhbGlmaWVkIGFwcGxpY2FudHMgYXJlIGludml0ZWQgdG8gc3VibWl0 IChhbGwgaW4gRW5nbGlzaCkgYaBjb3ZlciBsZXR0ZXIsIGEgQ1YgaW5jbHVkaW5nIGNvcGllcyBv ZiAyLzMgcmVwcmVzZW50YXRpdmUgcHVibGljYXRpb25zLCBhbmQgdGhyZWUgbGV0dGVycyBvZiBy ZWZlcmVuY2UgdG86IGhyLXNpc3RAc2hhbmdoYWl0ZWNoLmVkdS5jbiAoY2MgdG8geWFuZ3lhbmdA c2hhbmdoYWl0ZWNoLmVkdS5jbikuIFdlIHByb3ZpZGUgdmVyeSBjb21wZXRpdGl2ZSBzYWxhcnkg YW5kIGJlbmVmaXRzIGZvciB0aGlzIHBvc3QuIA0NRGVhZGxpbmU6oEF1Z3VzdCAzMXN0LCAyMDE0 DQMNDQQNDQMNDQQNDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAEIAAAH CAAAGQgAACEIAAAjCAAAJwgAAF4IAABfCAAAbggAAHMIAAB5CAAAgwgAAIQIAAC4CAAAuggAAMgI AADKCAAA1QgAAOwIAAD1CAAAGgkAAEsJAACfCQAAowkAAKsJAAC7CQAAvwkAAM0JAADzCQAA9QkA AFQKAABVCgAAVgoAAGcKAABoCgAAxQoAAMcKAADRCgAA4goAAPMKAAD1CgAAAQsAAAoLAAASCwAA FwsAADULAAA2CwAAOwsAADwLAABSCwAAcAsAAHoLAACGCwAAkQsAAJILAACTCwAAugsAAPbu9u7k 9u727uDb4NbP1uDb4NvK28XbwMXbxdvF28XKvMq3ysWyramtqa2yraSfpJiUpLKtsp+yrQAAAAAA AAAGFmjjCkIAAAwVaItJ2gAWaOMKQgAACRZooyAFAG8oAQkWaOMKQgBvKAEGFmiqCk8AAAkWaKoK TwBvKAEJFmjwZv8AbygBCRZo+TRIAG8oAQYWaJEkAAAACRZo6kFLAG8oAQkWaFQi+gBvKAEJFmiR JAAAbygBDBVocTPFABZocTPFAAAJFmhxM8UAbygBCRZomgEiAG8oAQYWaIdJMwAAEhVooyAFABZo mgEiADUIgW8oAQAPFWijIAUAFmiHSTMANQiBEhVooyAFABZoh0kzADUIgW8oATkACAAAbggAAG8I AADGCgAAxwoAALoLAAC7CwAAzAsAAM0LAAA5DAAAOgwAACENAAAiDQAAdg0AAHcNAADFDQAAxg0A ABYOAAAXDgAAQA4AAEEOAABPDgAAUA4AAHsPAAB8DwAAmA8AAJoPAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdk 4wpCAAAEAABnZKMgBQAABAAAZ2QKGSMAAAQAAGdkwh+2AAAEAABnZIdJMwAAGroLAAC7CwAAyQsA AMsLAADMCwAAzQsAAN8LAAACDAAAEwwAACYMAAAyDAAANwwAADkMAAA6DAAATQwAAHIMAABzDAAA ggwAAIoMAACSDAAAtAwAAMkMAADwDAAAIA0AACENAAAiDQAAaA0AAHUNAAB2DQAAdw0AAHsNAACF DQAAlQ0AAMMNAADEDQAAxQ0AAMYNAADHDQAAyA0AANENAADYDQAA5w0AABUOAAAWDgAAFw4AABkO AABADgAAQQ4AAE4OAABPDgAAUA4AALUOAAD37+Xv4NzX09fT19zO3NfJ18nEydfE1+C818nX08S1 sc61xKrcztzTpsncyc7Jn5eNzoYAAAAAAAAAAAAMFWijIAUAFmiaASIAABIVaKMgBQAWaKMgBQA1 CIFvKAEADxVooyAFABZomgEiADUIgQwWaKMgBQBcCIFvKAEABhZoRFQxAAAMFWiLSdoAFmijIAUA AAYWaAoZIwAADBVoi0naABZoChkjAAAPFWijIAUAFmjhBuMAbygBCRZoChkjAG8oAQkWaERUMQBv KAEJFmijIAUAbygBBhZo4QbjAAAJFmjhBuMAbygBBhZowh+2AAAJFmjCH7YAbygBEhVooyAFABZo wh+2ADUIgW8oAQAPFWijIAUAFmjCH7YANQiBDxVooyAFABZoqgpPAG8oAQAztQ4AALcOAAC5DgAA yA4AANwOAADeDgAA4A4AAPUOAAD4DgAA+Q4AAPwOAAAUDwAAHA8AADgPAAB0DwAAeA8AAHsPAAB8 DwAAhQ8AAIYPAACNDwAAlw8AAJgPAACZDwAAmw8AAJwPAACeDwAAnw8AAKEPAACiDwAApQ8AAKYP AAD38Pfw6/Dr8Ovm3+vX69LrysC567m1ramtqa2pram1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmhZJmsAAA8DagAAAAAW aFkmawBVCAEGFmiaASIAAAwVaI5mBQAWaJoBIgAAEhVojmYFABZomgEiADUIgVwIgQAPFWiOZgUA FmiOZgUAbygBCRZomFXSAG8oAQ8VaAMT9QAWaI5mBQBvKAEMFWgDE/UAFmiOZgUAAAkWaAMT9QBv KAEJFmiOZgUAbygBDBVooyAFABZomgEiAAAPFWijIAUAFmijIAUAbygBAB+aDwAAmw8AAJ0PAACe DwAAoA8AAKEPAACjDwAApA8AAKUPAACmDwAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAZ2SHSTMAAAQAAGdk4wpCAAABAAAACTYAMZA4ATJQAgA6cDt2 NwAfsIIuILDGQSGwCAcisAgHI5CgBSSQoAUlsAAAF7BTAxiw4AMMkKkBAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoEGAASAAEACwEPAAcAAwAEAAMAAAAE AAgAAACYAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA+AgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAAqAAAADYGAAA2BgAAFgAAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAAuAAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAAGgBAABIAQAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACwAwAANgYAADIG AAAYAAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQA AJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAyBgAAKAIAANgBAADoAQAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQ BAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQA AGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAA YAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABg BAAAcAQAAIAEAACQBAAAOAEAAFgBAAD4AQAACAIAABgCAABWAgAAfgIAACAAAABPSgMAUEoEAFFK AwBfSAEEbUgJBG5IBAhzSAkEdEgECAAAAABKAABg8f8CAEoADBAAADt2NwAAAAIAY2uHZQAACwAA AAMkAzEkAGEkAwAgAENKFQBLSAIAX0gBBGFKFgBtSAkEbkgECHNICQR0SAQIAAAAAAAAAAAAAAAA AAAAAAAAJABBYPL/oQAkAAwMAAAAAAAAEAAGANiepIu1az2EV1tTTwAAAABCAGkA8/+zAEIADB0A AAAAAAAwBgQAbmYakGiIPGgAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACAA ayD0/8EAIAAADQAAAAAAADAGAwDgZRdSaIgAAAIADAAAAAAAXABeAAEA8gBcAAwJAACLSdoAMAYG AG5mGpAoAFF/2XopAAAAGQAPAAMkABOkZAAUpGQAMSQBWyQBXCQBYSQAABwAQ0oYAEtIAABPSgQA UEoEAFFKBABeSgQAYUoYACoAVUCiAAEBKgAMDAAAmgEiADAGAwCFjf6UpWMAAAwAPioBQioHcGgA AP8AQgD+D6IAEQFCAAwAAACaASIAAAAVAGEAcABwAGwAZQAtAGMAbwBuAHYAZQByAHQAZQBkAC0A cwBwAGEAYwBlAAAAAAAiAFcAogAhASIADBAAAJoBIgBgAQIAgYm5cAAABgA1CIFcCIEiAFgAogAx ASIADBAAAJoBIgBAAQIAOl8DjAAABgA2CIFdCIFOAB8AAQBCAU4ADA0VAOMKQgAwBgIAdZgJdwAA JwAUAAMkAQ3GCAACORByIAECJmQGAQABRyQAUMYIAAAA/wYBAQBhJAEACABDShIAYUoSADIA/g+i AFEBMgAMARQA4wpCADAGBwB1mAl3IABDAGgAYQByAAAADABDShIAS0gCAGFKEgA8ACAAAQBiATwA DA0XAOMKQgAwBgIAdZgagQAAFgAWAAMkAA3GCAACORByIAECRyQAYSQACABDShIAYUoSADIA/g+i AHEBMgAMARYA4wpCADAGBwB1mBqBIABDAGgAYQByAAAADABDShIAS0gCAGFKEgBQSwMEFAAGAAgA AAAhAIKKvBP6AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHLasMwEEX3hf6D0LbYcroo pdjOokl3fSzSDxjksS1qj4Q0Ccnfd+y4ULoILXQjEGLOmXtVro/joA4Yk/NU6VVeaIVkfeOoq/T7 7im71yoxUAODJ6z0CZNe19dX5e4UMCmZplTpnjk8GJNsjyOk3AckeWl9HIHlGjsTwH5Ah+a2KO6M 9cRInPHE0HX5KgtE16B6g8gvMIrHsKDw+/kMJICYC1irxzNhWqLSEMLgLLBEMAdqfugz37bOYuPt fhRpPoMX2M0EM79cYPU/6i/nBlvYD6y2R+niXH/EIf0t21JrLpNz/tS7kC4YLpe3tGHmv60/AQAA //8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D 0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jh dj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5Fx X9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj5 1v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVN YW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sN WSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1e uSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQDHHG0UnAYAAFEbAAAWAAAA dGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZTW8bRRi+I/EfRntvYyd2Gkd1qtixG2jTRrFb1ON4Pd6d enZnNTNO6htqj0hIiIJ6oBLiwgEBlVoJJMqvSSkqRepf4J2Z3fVOvCZJG0EF9SHxzj7v98e8M754 6U7E0D4RkvK46VXPVzxEYp8PaRw0vRv97rk1D0mF4yFmPCZNb0qkd2nj/fcu4nUVkoggoI/lOm56 oVLJ+tKS9GEZy/M8ITG8G3ERYQWPIlgaCnwAfCO2tFyprC5FmMYeinEEbK+PRtQn6NnPv7z45oG3 kXHvMBARK6kXfCZ6mjdxSAx2OK5qhJzKNhNoH7OmB4KG/KBP7igPMSwVvGh6FfPxljYuLuH1lIip BbQFuq75pHQpwXC8bGSKYJALrXZrjQtbOX8DYGoe1+l02p1qzs8AsO+DpVaXIs9ad63ayngWQPbr PO92pV6pufgC/5U5nRutVqveSHWxTA3Ifq3N4dcqq7XNZQdvQBZfn8PXWpvt9qqDNyCLX53Ddy80 Vmsu3oBCRuPxHFoHtNtNueeQEWfbpfA1gK9VUvgMBdmQZ5cWMeKxWpRrEb7NRRcAGsiwojFS04SM sA9p3MbRQFCsBeB1ggtv7JIv55a0LCR9QRPV9D5MMJTEjN+rp9+/evoYHd59cnj3p8N79w7v/mgZ OVTbOA6KVC+//ezPhx+jPx5//fL+F+V4WcT/9sMnz379vBwI5TNT5/mXj35/8uj5g09ffHe/BL4p 8KAI79OISHSNHKA9HoFhxiuu5mQgTkfRDzEtUmzGgcQx1lJK+HdU6KCvTTFLo+Po0SKuB28KaB9l wMuT247CvVBMFC2RfCWMHOAO56zFRakXrmhZBTf3J3FQLlxMirg9jPfLZLdx7MS3M0mgb2Zp6Rje Domj5i7DscIBiYlC+h0fE1Ji3S1KHb/uUF9wyUcK3aKohWmpS/p04GTTjGibRhCXaZnNEG/HNzs3 UYuzMqu3yL6LhKrArET5PmGOGy/jicJRGcs+jljR4VexCsuU7E2FX8R1pIJIB4Rx1BkSKctorguw txD0Kxg6VmnYd9g0cpFC0XEZz6uY8yJyi4/bIY6SMmyPxmER+4EcQ4pitMtVGXyHuxWinyEOOF4Y 7puUOOE+vhvcoIGj0ixB9JuJ0LGEVu104IjGf9eOGYV+bHPg7NoxNMDnXz0syay3tRFvwp5UVgnb R9rvItzRptvmYkjf/p67hSfxLoE0n9943rXcdy3X+8+33EX1fNJGO+ut0Hb13GCHYjMiRwsn5BFl rKemjFyVZkiWsE8Mu7Co6czxkOQnpiSEr2lfd3CBwIYGCa4+oirshTiBAbvqaSaBTFkHEiVcwsHO LJfy1ngY0pU9Ftb1gcH2A4nVDh/a5RW9nJ0LcjZmtwnM4TMTtKIZnFTYyoWUKZj9OsKqWqkTS6sa 1Uyrc6TlJkMM502DxdybMIAgGFvAy6twQNei4WCCGRlqv9u9NwuLicJZhkiGeEjSGGm752NUNUHK csXcBEDulMRIH/KO8VpBWkOzfQNpJwlSUVxtgbgsem8SpSyDZ1HSdXukHFlcLE4Wo4Om16gv1z3k 46TpjeBMC1+jBKIu9cyHWQA3Q74SNu2PLWZT5bNoNjLD3CKowjWF9fucwU4fSIRUW1iGNjXMqzQF WKwlWf2X6+DWszLAZvpraLGyBsnwr2kBfnRDS0Yj4qtisAsr2nf2MW2lfKKI6IXDAzRgE7GHIfw6 VcGeIZVwNWE6gn6AezTtbfPKbc5p0RVvrwzOrmOWhDhtt7pEs0q2cFPHuQ7mqaAe2FaquzHu9KaY kj8jU4pp/D8zRe8ncFOwMtQR8OEeV2Ck67XpcaFCDl0oCanfFTA4mN4B2QJ3sfAakgpuk81/Qfb1 f1tzlocpazjwqT0aIEFhP1KhIGQX2pLJvmOYVdO9y7JkKSOTUQV1ZWLVHpB9wvq6B67qvd1DIaS6 6SZpGzC4o/nnPqcVNAj0kFOsN6eH5HuvrYF/evKxxQxGuX3YDDSZ/3MVS3ZVS2/Is723aIh+MRuz allVgLDCVtBIy/41VTjlVms71pzFy/VMOYjivMWwmA9ECdz3IP0H9j8qfEZMGusNtc/3oLci+KFB M4O0gaw+ZwcPpBukXRzA4GQXbTJpVta16eikvZZt1mc86eZyjzhba3aSeJ/S2flw5opzavEsnZ16 2PG1XVvoaojs0RKFpVF2kDGBMb9pFX914oPbEOgtuN+fMCVNMsFvSgLD6NkzdQDFbyUa0o2/AAAA //8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1l TWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6H Yb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIO J0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFB c9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AA AAA2AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMA AACKAAAAHAAAAAAAAAAAAAAAAAAUAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQIt ABQABgAIAAAAIQDHHG0UnAYAAFEbAAAWAAAAAAAAAAAAAAAAANECAAB0aGVtZS90aGVtZS90aGVt ZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAoQkAAHRoZW1l L3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAACcCgAAAAA8 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8 YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdp bmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBh Y2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2Nl bnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0i aGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAAAACmBwAADQAAGgAAAAD/////AAAAAAMAAAAG AAAABgAAAAkAAAAMAAAADAAAAAwAAAAMAAAADAAAAAwAAAAMAAAADAAAAA8AAAAACAAAugsAALUO AACmDwAACAAAAAoAAAALAAAAAAgAAJoPAACmDwAACQAAAAwAAAAPAADwQAAAAAAABvAgAAAAAgwA AAMAAAACAAAAAgAAAAIAAAACAAAAAQAAAAEAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC 8JIAAAAgAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAA AAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQ AMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAEPAALwSAAAABAACPAIAAAAAQAA AAAIAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAA BQAAAAAAAACDAAAAugAAAJ8BAACgAQAAogEAAKMBAAC0BAAAtAQAAPkGAAAUBwAAHAcAABwHAAA4 BwAAOAcAAHQHAAB4BwAAlwcAAJgHAACaBwAAmwcAAJ0HAACeBwAAoAcAAKEHAACjBwAApwcAAAcA BAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwACAAcAAgAHAAIABwACAAcAAgAAAAAAuwMA AM0DAABBBgAATwYAAHwHAACXBwAAmAcAAJoHAACbBwAAnQcAAJ4HAACgBwAAoQcAAKMHAACnBwAA BwAFAAcABQAHAAUABwAHAAIABwACAAcAAgAHAAIAAQBNbiV4tqriZ/8P/w//D/8P/w//D/8P/w// DxAAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9K BQBRSgUAbygAAQB28AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUG XoSgBWCEmP5PSgUAUUoFAG8oAAEAdvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGE mP4VxgUAAXAIBl6EcAhghJj+T0oFAFFKBQBvKAABAHbwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KBQBRSgUAbygAAQB28AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8oAAEAdvABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oFAFFKBQBv KAABAHbwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY /k9KBQBRSgUAbygAAQB28AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQAB gBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAdvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQ GRGEmP4VxgUAAVAZBl6EUBlghJj+T0oFAFFKBQBvKAABAHbwAQAAAE1uJXgAAAAAAAAAAAAAAAD/ //////8BAAAAAAD//wEAAAASAL5FIng8TnLWQhSU64Qx5pDKkqblti/qyChmJOOCXnaCEiEwOw0A aA6KBm1yAiwAAAAABQAIACMCAAB4AAAAbmVRDm1yAiwAAAAABQAIACMCAAB4AAAAICF8F21yAiwA AAAABQAIACMCAAB4AAAAbXICLAAAAAAAAAAAAAECAAIA+CRwMm1yAiwAAAAABQAIACMCAAB4AAAA hlwAPW1yAiwAAAAABQAIACMCAAB4AAAAJ1PQRm1yAiwAAAAABQAIACMCAAB4AAAAVlqKSgAAAAAA AAAAAAECAAIAeR37T21yAiwAAAAABQAIACMCAAB4AAAA6AGnU21yAiwAAAAABQAIACMCAAB4AAAA c140YW1yAiwAAAAABQAIACMCAAB4AAAA8zCrd21yAiwAAAAABQAIACMCAAB4AAAADkxvem1yAiwA AAAABQAIACMCAAB4AAAAGAAAAAQAAAAIAAAA5QAAAAAAAAAXAAAAkSQAAKMgBQCOZgUAmgEiAAoZ IwBEVDEAh0kzADt2NwA6QD0A4wpCAPk0SADqQUsAqgpPAFkmawDCH7YAADy+AHEzxQCYVdIAi0na AOEG4wCZMOwAAxP1AFQi+gDwZv8AAAAAAJgHAACaBwAAAAAAAAEAAAD/QAGAAQC4AAAAuAAAAADQ xgMBAAEAuAAAAAAAAAC4AAAAlP+rFQIQAAAAAAAAAKYHAABoAAAQAEAAAP//AQAAAAcAVQBuAGsA bgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAH AAAARx6QAQAAAgIGAwUEBQIDBP8qAOBBeADACQAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4A ZQB3ACAAUgBvAG0AYQBuAAAANR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAA AFMAeQBtAGIAbwBsAAAAMy6QAQAAAgsGBAICAgICBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEEA cgBpAGEAbAAAADcukAEAAAIPBQICAgQDAgT/AgDg/6wAQAEAAAAAAAAAnwEAAAAAAABDAGEAbABp AGIAcgBpAAAAOw6QAYYDAgEGAAMBAQEBAQMAAAAAAI8oFgAAAAAAAAABAAQAAAAAAItbU08AAFMA aQBtAFMAdQBuAAAAOw6QAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBu AGcAZABpAG4AZwBzAAAAQR6QAQAAAgQFAwUEBgMCBP8CAOD/JABCAAAAAAAAAACfAQAAAAAAAEMA YQBtAGIAcgBpAGEAIABNAGEAdABoAAAAIAAEADEIiBgAAKQBAABoAQAAAABZVSeHaH0nRwAAAAAJ AJMAAAAiAQAAdgYAAAEAAwAAAAQAA5ANAAAAIgEAAHYGAAABAAMAAAANAAAAAAAAAGEEAAAAAAAA AwA/ABsAIQAlACkALAAuADoAOwA+AD8AXQB9AKIAqACwALcAxwLJAhUgFiAZIB0gJiAwIDIgMyA6 IAMhNiIBMAIwAzAJMAswDTAPMBEwFTAXMB4wNv46/j7+QP5E/lr+XP5e/gH/Av8F/wf/Cf8M/w7/ Gv8b/x//Pf9A/1z/Xf9e/+D/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAKABbAHsAowClALcAGCAcIAgw CjAMMA4wEDAUMBYwHTBZ/lv+Xf4E/wj/Dv87/1v/4f/l/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0AJwAgoASAAAAAAAAAAAAAAAAAAAAlQcAAJUH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAAAAAAAAAAACTODUQAAAAAAAPz9AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhIWAAA AAAJ8P8PAQgkUAAAqAMAAP///3////9/////f////3////9/////f////3+HSTMAAAQAADIAAAAA AAAAAAAAAAAAAAAAAAAAAAAhBAAAAAAAAAAAAAAAAAAAAAAAABAcAAAGAAAAAAAAAAAAeAAAAHgA AAAAAAAAAAAAAKAFAAD//xIAAAAAAAAAAAAAAAAAAAAEAFkAYQBuAGcABABZAGEAbgBnAAAAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAYAAAABAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAABUAQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAAnAAAAAQAAACoAAAABQAAALgAAAAH AAAAxAAAAAgAAADUAAAACQAAAOQAAAASAAAA8AAAAAoAAAAQAQAADAAAABwBAAANAAAAKAEAAA4A AAA0AQAADwAAADwBAAAQAAAARAEAABMAAABMAQAAAgAAAKgDAAAeAAAABAAAAAAAAAAeAAAABAAA AAAAAAAeAAAACAAAAFlhbmcAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAIAAAA WWFuZwAAAAAeAAAABAAAADkAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAA MiGJFAAAAEAAAAAAXnpZQpzPAUAAAAAAOPxFMqDPAQMAAAABAAAAAwAAACIBAAADAAAAdgYAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA rAAAAAoAAAABAAAAWAAAAA8AAABgAAAABQAAAGwAAAAGAAAAdAAAABEAAAB8AAAAFwAAAIQAAAAL AAAAjAAAABAAAACUAAAAEwAAAJwAAAAWAAAApAAAAAIAAACoAwAAHgAAAAQAAAAAAAAAAwAAAA0A AAADAAAAAwAAAAMAAACVBwAAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAD+//// DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAAP7///8XAAAAGAAAABkAAAAaAAAAGwAAABwAAAAd AAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA/v///ygAAAApAAAAKgAAACsA AAAsAAAALQAAAC4AAAD+////MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAAP7////9////OQAA ADoAAAD+/////v///z0AAAD+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA8B+jSTKg zwE8AAAAAAMAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP//////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAAAPEgAAAAAAAAVwBvAHIAZABEAG8AYwB1 AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEKAAAA BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOBoAAAAAAAAF AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACcAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALwAAAAAQAAAAAAAATQBzAG8ARABhAHQAYQBTAHQAbwByAGUAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAQD//////////wcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACDRmUkyoM8BcOehSTKgzwEAAAAAAAAAAAAAAABaAEgA3QDJAMkAUwDbAFEA QQBVAFcAMwDbAN4AUwBTANcA1QDVANoA0ABRAD0APQAAAAAAAAAAAAAAAAAAAAAAMgABAf////// ////CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAINGZSTKgzwFw56FJMqDPAQAAAAAAAAAAAAAAAEkA dABlAG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKAAIB/////wkAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAOgAAAAAAAAAUAByAG8AcABlAHIAdABpAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABYAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAAVQEAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAGAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAIAAAADAAAA/v///wUAAAAGAAAABwAAAAgAAAAJAAAA/v///wsAAAD+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////88YjpT b3VyY2VzIFNlbGVjdGVkU3R5bGU9IlxBUEEuWFNMIiBTdHlsZU5hbWU9IkFQQSBGaWZ0aCBFZGl0 aW9uIiB4bWxuczpiPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvb2ZmaWNlRG9j dW1lbnQvMjAwNi9iaWJsaW9ncmFwaHkiIHhtbG5zPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9y bWF0cy5vcmcvb2ZmaWNlRG9jdW1lbnQvMjAwNi9iaWJsaW9ncmFwaHkiPjwvYjpTb3VyY2VzPg0K AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRG LTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8ZHM6ZGF0YXN0b3JlSXRlbSBkczppdGVtSUQ9IntBNTY5 N0Y2NC1EMDJFLTQ1MDEtOURFRi1FNDkyREY1RDdBQzF9IiB4bWxuczpkcz0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL29mZmljZURvY3VtZW50LzIwMDYvY3VzdG9tWG1sIj48ZHM6 c2NoZW1hUmVmcz48ZHM6c2NoZW1hUmVmIGRzOnVyaT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL29mZmljZURvY3VtZW50LzIwMDYvYmlibGlvZ3JhcGh5Ii8+PC9kczpzY2hlbWFS ZWZzPjwvZHM6ZGF0YXN0b3JlSXRlbT4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARiMAAABNaWNyb3NvZnQgT2ZmaWNl IFdvcmQgOTctMjAwMyDOxLW1AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJx AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -------------a9325a6093acf938ed728b3604cf9263-- From nobody Sat Jul 26 09:33:19 2014 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 EE5511A03A6 for ; Sat, 26 Jul 2014 09:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 yvI4VNK5r5Ek for ; Sat, 26 Jul 2014 09:33:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1AC1A0339 for ; Sat, 26 Jul 2014 09:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5380; q=dns/txt; s=iport; t=1406392395; x=1407601995; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9AoNalLyVXvCZAvUreVGJgxCsZgCL4+yI7oJ0D04gv0=; b=M2UhTOBJQF/88SNN6ISQByoHrmIg52661RYTYZYhu+zp8pCVD3dT6qNd PI17MzzDDp64aFRF4a7/Ry+ZumgD7keQTR1PUTt3tNOCyAVP9uTDEC8Xa g52tCg2qO1ETGg0GFROCexozl1wY+QQ/KAFxkj3eq7ku6+YVO5dr7VYD2 0=; X-IronPort-AV: E=Sophos;i="5.01,735,1400025600"; d="scan'208";a="343139792" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2014 16:33:13 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6QGXC3s004517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2014 16:33:12 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6QGX4xM030872; Sat, 26 Jul 2014 09:33:04 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6QGWvAq030865; Sat, 26 Jul 2014 09:32:57 -0700 Date: Sat, 26 Jul 2014 09:32:57 -0700 From: Toerless Eckert To: Rick Taylor Message-ID: <20140726163257.GA28917@cisco.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wln7W9rp0vDLQ88LhZsPchYJgtI Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] DLEP proposal 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: Sat, 26 Jul 2014 16:33:17 -0000 a) I have not tried to wrap my head around the L3 use case yet. b) There are not only 48, but also 64-bit MAC addresses. No idea when/if they would ever be applicable to DLEP, just saying. c) Your email sounds as if this new identifier for a destination is solely there to allow writing a more logical draft. I don't think that is true though, and i think a nicer reading draft text wouldn't be good enough justification for adding a protocol identifier that router and modem coder would need to implement. 1) Having a destination identifier separate from DMAC would of course allow to have destinations change their DMAC. If that is useful, i don't know. If we do know a use case and we do this protocol change, then it would be great to mentoin that use-case. 2) Having a destination identifier separate from DMAC would allow for destinations to NOT have a DMAC, eg: making DMAC optional. I do not know if you intend to support this: 2.1) for a "normal" destination (router/host), i can not see how this would work. Without MAC nor IP, a router could IMHO not make heads or tail out of such a destination. 2.2) for a special "default destination" which i think is what Bryan would like to see for sat spoke modems, this would work. The "default destination" does not need MAC or IP identification. It needs to have a pre-defined, unique identifier though so that a DLEP router recognizes it and appropriately deals with it. 2.3) Another special destination could be a destination that really only says "network DOES/DOES-NOT support L2 multicast". That somehow is missing. If a (radio) network does NOT support L2 multicast, then all modems need to announce "normal" destinations with both MAC and IP address, so that routers can use DLEP to replace ARP, and routers would need to replicate IP multicast as replicated ethernet unicast across the (radio) network. If the radio network DOES support L2 multicast, then MAC addresses formal destinations are IMHO still mandatory, but IP addresses are optional. If supported by the DLEP modems, they can help to optimize the RTTs of ARP away and save RF bandwidth. 2.3) If the concept of destination is meant to be used to indicate individual multicast groups, that warrants a longer discussion, let me put this into another mail thread. Cheers Toerless On Sat, Jul 26, 2014 at 02:25:43PM +0000, Rick Taylor wrote: > Stan, All, > > As DLEP starts to get picked up and looked at, an increasing number of potential implementers keep getting confused about what we within the DLEP DT see as a simple issue: Destination MAC addresses. > > As I have stated before, DLEP uses MAC addresses for 2 distinct purposes: 1) As a destination discriminator/identifier, 2) To advertise the attached router's MAC address. > > Ignoring the specifics of my unusual use-case of layer-3 modems, in my draft extension I suggest changing destination MAC addresses to unique numeric identifiers generated by the modem. On consideration I think it makes more sense to do this for core DLEP, and add the MAC address as a data-item TLV, much like layer-3 addresses are currently handled. > > Hopefully this will make the DLEP model more obvious to newcomers: A destination has an ID, and some data-items describing it, one of which MUST be a MAC address TLV. The semantics of the protocol are unchanged, we don't care about extra octets on the local link (in principle), and the meaning might be clearer to readers. > > I would suggest a 32-bit destination identifier, and I assume that most RF equipment has some concept of a 'link id' that might be reusable/mappable in the DLEP agent, so I don't believe it adds extra burden on implementers. > > The MAC address TLV should be obvious to formulate: Type = TBD, Length = 6, Value = MAC octets. Unlike IP address TLVs there is no need for Add/Drop indicators. > > It has the advantage that the DLEP draft text can talk about destinations as concept in one section, and then discuss router MACs and addresses in another discrete section, hopefully avoiding some first-pass confusion in the reader. > > The only thing this proposal breaks is multicast destinations, but having had a long chat with Toerless Eckert who is heavily involved in the PIM WG, we may not have thought through the multicast/anycast/broadcast part of DLEP thoroughly yet (and that requires a new thread). > > It also might solve a use-case problem we have skirted around: 1 modem with 2 DLEP sessions to 2 routers. With this proposal, a single set of destination identifiers could be used, and 2 MAC TLV's added to the destination up, i.e. "I have two upstream routers, go chat..." > > Lobbying for one of my corner-cases, I would suggest that the Destination Up signal text states something like: "A destination up signal MUST include 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV. It SHOULD provide a MAC address TLV, and it is RECOMMENDED that at least 1 IPv4 or IPV6 address TLV be included." > > As I think about it, MAC-less destinations with IP multicast addresses/subnets might be the better way to handle multicast destinations... > > Anyway, "fire in the hole!" > > Cheers, > > Rick From nobody Sat Jul 26 10:07:04 2014 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 48FDF1A02D9 for ; Sat, 26 Jul 2014 10:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.016 X-Spam-Level: X-Spam-Status: No, score=-13.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 Ik5M1uMHc6P3 for ; Sat, 26 Jul 2014 10:06:56 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FB41A035E for ; Sat, 26 Jul 2014 10:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3202; q=dns/txt; s=iport; t=1406394416; x=1407604016; h=date:from:to:subject:message-id:mime-version; bh=URcsEggja/PSiXA4F9zamyfw+Ovb1npZ2U7WDBz+G1w=; b=lXHNpZSx/SLPjStk2FHCD385qjOOgHydMnzMuXuCv2mh4ig6R5HmGE56 snRe1UiZf+K3Leq8tGZfD5RtPWPcQglpes6koksfJzG58OHB+8Id/JSkZ NGH9WATQB3w63GN/sKkeCVADd4Ctxfs56y9GBt+IKo86vaRz603qsSF7s o=; X-IronPort-AV: E=Sophos;i="5.01,735,1400025600"; d="scan'208";a="64218853" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 26 Jul 2014 17:06:55 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6QH6tjB027092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2014 17:06:55 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6QH6nEV032383; Sat, 26 Jul 2014 10:06:49 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6QH6n30032382; Sat, 26 Jul 2014 10:06:49 -0700 Date: Sat, 26 Jul 2014 10:06:49 -0700 From: Toerless Eckert To: "manet@ietf.org" , Stan Ratliff Message-ID: <20140726170649.GB28917@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3sa_rdsVtZAnuvmbKMfhATaJ17o Subject: Re: [manet] DLEP ip multicast destinations 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: Sat, 26 Jul 2014 17:06:58 -0000 Some thoughts about IP multicast and DLEP: a) As mentioned in another thread, there seems to be no indication in DLEP whether or not the radio network supports L2 multicast. I think it would be great if there was such an indication, so the router(s) would know whether they need to send L3 multicast as L2 unicast (so called NBMA mode). It would also help to indicate that unicast destination entries MUST have IP address entries. b) The current Multicast dfefinition in DLEP is very lightweight, which is nice because modem vendors could implement a lot of different things. It is bad though, because to router vendors, the current DLEP mechanisms do not expose what the modems do and therefore router vendors can not automatically adopt to what modems need. A couple of different situations: b.1) The modem connected to the router is set up to only forward specific multicast traffic to that router, if the router indicates interest in the multicast via: I) DLEP destination II) IGMP III) PIM IV) GARP/GMRP b.2) The RF network is set up to indicate multicast destinations via DLEP to routers only if the routers indicate interest in the multicast via: I) DLEP destination II) IGMP III) PIM IV) GARP/GMRP Of course, b.2) does not imply b.1). The DLEP modems may not constrain any IP multicast, but they may indicate the multicast path characteristic based on what other modem/router need to receive it. As you can see, without DLEP modems telling routers how they operate for multicast, the DLEP router setup for multicast is a mess of nerd knobs and a mess of protocols that likely need to be supported. Traditionally, modems have primarily supported IGMP snooping, which is a hack, but they have done it because "hosts" normally speak IGMP. But then a lot of these modems (eg; HAIPE) started to get used not in conjunction with hosts, but with routers, and that made life really really miserable for those routers: They had to do IGMP where they really wanted to do PIM. And they could not give up PIM, because the router on the other side of the modem still needed it. So we ended up having to do both. PIM snooping is not much better. Unlike IGMP snooping in modems/switches, which at least has an information RFC, PIM snooping (luckily ?) does not even have one. Long time ago, we did put in RFC3488 (RGMP) for router<->switch/modem communications that helps to overcome those snooping issues. Alas, it was done so early that we did then not get SSM support in. Long story short: It would be very helpfull to understand better, what the stakeholder in DLEP really expect to get done with multicast, and/or what already exists or is planned in modem implementations. That would help a lot to decide what DLEP should do, and how we can best document it. IMHO, Ideally, DLEP should allow to run multicast over a radio network with the optional ability of modems to to constrain the forwarding of IP multicast to only those routers that need it. And without forcing routers to do IGMP. Cheers Toerless From nobody Sat Jul 26 22:31:06 2014 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 5D8181A0068 for ; Sat, 26 Jul 2014 22:31: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 a17yw170oh3E for ; Sat, 26 Jul 2014 22:31:02 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38521A0025 for ; Sat, 26 Jul 2014 22:31:01 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so4071843yha.38 for ; Sat, 26 Jul 2014 22:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tr0gNv6LvV40t+nK3Vkv6jFkbMWchcw5Q/vL4xkORLE=; b=JQ4xkvmtsXvv5Qa3eDXMcgXqfp5iPbflNiZsX6aU3/9+tvSIFZNUYDvCltt7s1OaBh XpzcWHFE3xi7ezMc70O1nnrc/oOryV4K/5Vb3hoU7huz8IOPisVbBkDGRO7o3UD7tfvI D/xV8KcsZJm4rxmgFYzoan3EterP2wFynA1M4vyZpLb0U24wTZ0IwtC+eNJeNyIqmBKN QP6o+LpTyv1WpVBVOShI6fIFuNeq4tnJm6Lgu3Wabm0SgVfY9wmHml4QiPzW94lR/V8E QSlbCzjtdJJaOB+wSqXtMBmr3ynksWCQgmYD9a2XYLYNXcVsnfp6Vgp8lwY1AXm39Ure axeg== MIME-Version: 1.0 X-Received: by 10.236.142.227 with SMTP id i63mr18198044yhj.88.1406439060995; Sat, 26 Jul 2014 22:31:00 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Sat, 26 Jul 2014 22:31:00 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> Date: Sun, 27 Jul 2014 07:31:00 +0200 Message-ID: From: Abdussalam Baryun To: Rick Taylor Content-Type: multipart/alternative; boundary=20cf300e5293a106eb04ff261cf5 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9-nYadLQW06sdqwPZqWatj2Rw0s Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 05:31:04 -0000 --20cf300e5293a106eb04ff261cf5 Content-Type: text/plain; charset=UTF-8 Hi Rick, Thanks. IMO for simplicity and flexible purposes I think DLEP does not need any changes, but maybe editorial, because the draft makes clear assumptions and does not go into modem configuring or router configuring. However, my comments below, On Saturday, July 26, 2014, Rick Taylor wrote: > Stan, All, > > As DLEP starts to get picked up and looked at, an increasing number of > potential implementers keep getting confused about what we within the DLEP > DT see as a simple issue: Destination MAC addresses. I think we consider that DLEP destinations/neighbours have MAC addresses. > As I have stated before, DLEP uses MAC addresses for 2 distinct purposes: > 1) As a destination discriminator/identifier, 2) To advertise the attached > router's MAC address. > > Ignoring the specifics of my unusual use-case of layer-3 modems, in my > draft extension I suggest changing destination MAC addresses to unique > numeric identifiers generated by the modem. On consideration I think it > makes more sense to do this for core DLEP, and add the MAC address as a > data-item TLV, much like layer-3 addresses are currently handled. We want DLEP to consider wide use cases, so if we do that suggestion then DLEP core may loose flexibility as the suggestion (which I understand its purposes) can still be added as extension to core. > Hopefully this will make the DLEP model more obvious to newcomers: A > destination has an ID, and some data-items describing it, one of which MUST > be a MAC address TLV. The semantics of the protocol are unchanged, we > don't care about extra octets on the local link (in principle), and the > meaning might be clearer to readers. I agree with you, but I think is was mentioned some where in the draft (not sure). > I would suggest a 32-bit destination identifier, and I assume that most RF > equipment has some concept of a 'link id' that might be reusable/mappable > in the DLEP agent, so I don't believe it adds extra burden on implementers. why? does DLEP not cover that issue of link between modems. Each MAC address has one link so it already identifies it. > > The MAC address TLV should be obvious to formulate: Type = TBD, Length = > 6, Value = MAC octets. Unlike IP address TLVs there is no need for > Add/Drop indicators. > > It has the advantage that the DLEP draft text can talk about destinations > as concept in one section, and then discuss router MACs and addresses in > another discrete section, hopefully avoiding some first-pass confusion in > the reader. I think the introduction does clarify that, but maybe not much focus on one item as the destinations because it considers many items together. > > The only thing this proposal breaks is multicast destinations, but having > had a long chat with Toerless Eckert who is heavily involved in the PIM WG, > we may not have thought through the multicast/anycast/broadcast part of > DLEP thoroughly yet (and that requires a new thread). DLEP does another special multicast it is not similar to the L3 multicast. > It also might solve a use-case problem we have skirted around: 1 modem > with 2 DLEP sessions to 2 routers. With this proposal, a single set of > destination identifiers could be used, and 2 MAC TLV's added to the > destination up, i.e. "I have two upstream routers, go chat..." The DLEP protocol is that: Each modem has only one DLEP-session to one router. > Lobbying for one of my corner-cases, I would suggest that the Destination > Up signal text states something like: "A destination up signal MUST include > 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV. You may say L2 address TLV. However, that may make DLEP not flexible to cover all possible destinations and use cases. It SHOULD provide a MAC address TLV, and it is RECOMMENDED that at least 1 > IPv4 or IPV6 address TLV be included." Yes, we can use "should" rather than "must". > > As I think about it, MAC-less destinations with IP multicast > addresses/subnets might be the better way to handle multicast > destinations... DLEP is designed to have MAC addresses, but we can make it L2 addresses to be general. We have two kind of DLEP destinations; 1) at L2 , 2) at L3. So DLEP handles multicast addresses of L2 and not L3. AB > > Anyway, "fire in the hole!" > W > Cheers, > > Rick > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf300e5293a106eb04ff261cf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rick,

Thanks. IMO for simplicity and flexible=C2=A0pu= rposes=C2=A0I=C2=A0think DLEP does not need any changes, but maybe editoria= l,=C2=A0because the draft=C2=A0makes clear=C2=A0assumptions=C2=A0and=C2=A0d= oes not go into modem configuring or router configuring. However, my commen= ts below,

On Saturday, July 26, 2014, Rick Taylor wrote:
Stan, All,

As DLEP starts to get picked up and looked at, an increasing number of pote= ntial implementers keep getting confused about what we within the DLEP DT s= ee as a simple issue: Destination MAC addresses.

I think we consider=C2=A0that DLEP=C2=A0destinations/neighbours= =C2=A0have=C2=A0MAC addresses.=C2=A0


As I have stated before, DLEP uses MAC addresses for 2 distinct purposes: 1= ) As a destination discriminator/identifier, 2) To advertise the attached r= outer's MAC address.

Ignoring the specifics of my unusual use-case of layer-3 modems, in my draf= t extension I suggest changing destination MAC addresses to unique numeric = identifiers generated by the modem. =C2=A0On consideration I think it makes= more sense to do this for core DLEP, and add the MAC address as a data-ite= m TLV, much like layer-3 addresses are currently handled.

We want DLEP to consider wide use cases, so if we do th= at suggestion then DLEP core may loose flexibility as the suggestion (which= I understand its purposes)=C2=A0can still be added as extension to core.= =C2=A0


Hopefully this will make the DLEP model more obvious to newcomers: =C2=A0A = destination has an ID, and some data-items describing it, one of which MUST= be a MAC address TLV. =C2=A0The semantics of the protocol are unchanged, w= e don't care about extra octets on the local link (in principle), and t= he meaning might be clearer to readers.

I agree with you,=C2=A0but=C2=A0I think is was mentione= d some where in the draft (not sure).=C2=A0


I would suggest a 32-bit destination identifier, and I assume that most RF = equipment has some concept of a 'link id' that might be reusable/ma= ppable in the DLEP agent, so I don't believe it adds extra burden on im= plementers.

why?=C2=A0does DLEP not cover that issue of link betwee= n modems. Each MAC address has one link so it already identifies it.
<= div>=C2=A0

The MAC address TLV should be obvious to formulate: Type =3D TBD, Length = =3D 6, Value =3D MAC octets. =C2=A0Unlike IP address TLVs there is no need = for Add/Drop indicators.

It has the advantage that the DLEP draft text can talk about destinations a= s concept in one section, and then discuss router MACs and addresses in ano= ther discrete section, hopefully avoiding some first-pass confusion in the = reader.

I think the introduction does clarify that, but maybe n= ot much focus on one item as the=C2=A0destinations because it considers man= y items together.=C2=A0
=C2=A0

It also might solve a use-case problem we have skirted around: 1 modem with= 2 DLEP sessions to 2 routers. =C2=A0With this proposal, a single set of de= stination identifiers could be used, and 2 MAC TLV's added to the desti= nation up, i.e. "I have two upstream routers, go chat..."

The DLEP protocol is that:=C2=A0Each modem has only one= DLEP-session to one router.=C2=A0=C2=A0


Lobbying for one of my corner-cases, I would suggest that the Destination U= p signal text states something like: "A destination up signal MUST inc= lude 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV. =C2=A0<= /blockquote>

You may say= L2 address TLV. However, that may make DLEP not flexible to=C2=A0cover all= possible=C2=A0destinations and use cases.

It SHOULD provide a MAC addre= ss TLV, and it is RECOMMENDED that at least 1 IPv4 or IPV6 address TLV be i= ncluded."

Yes, we can use "should" rather than "mu= st".=C2=A0
=C2=A0

As I think about it, MAC-less destinations with IP multicast addresses/subn= ets might be the better way to handle multicast destinations...

DLEP is designed to have MAC addresses, but we can mak= e it L2 addresses to be general.=C2=A0
We have two kind of DLEP=C2=A0destinations; 1) at L2 , 2) at L3. So DL= EP handles multicast addresses=C2=A0of L2 and=C2=A0not L3.=C2=A0
=

AB
=C2=A0

Anyway, "fire in the hole!"
W
Cheers,

Rick



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--20cf300e5293a106eb04ff261cf5-- From nobody Sun Jul 27 07:27:25 2014 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 8603B1A0276 for ; Sun, 27 Jul 2014 07:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 w5mcMegoq02y for ; Sun, 27 Jul 2014 07:27:22 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 E4AAE1A026E for ; Sun, 27 Jul 2014 07:27:20 -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; Sun, 27 Jul 2014 15:26:50 +0100 From: Rick Taylor To: Toerless Eckert Thread-Topic: [manet] DLEP proposal Thread-Index: AQHPqO9CBLm7Ds35Rki/xAnaEAWf0puz9QEA Date: Sun, 27 Jul 2014 14:26:37 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> <20140726163257.GA28917@cisco.com> In-Reply-To: <20140726163257.GA28917@cisco.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: http://mailarchive.ietf.org/arch/msg/manet/e0VfcHw8qZnBCO1GpmnizK1Air8 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 14:27:23 -0000 Comments inline... -----Original Message----- From: Toerless Eckert [mailto:eckert@cisco.com]=20 Sent: 26 July 2014 17:33 To: Rick Taylor Cc: Stan Ratliff; manet@ietf.org Subject: Re: [manet] DLEP proposal > a) I have not tried to wrap my head around the L3 use case yet. Don't worry about the L3 use-case. I'm trying to concentrate on 'tradition= al' DLEP here. > b) There are not only 48, but also 64-bit MAC addresses. No idea when/if they would ever be applicable to DLEP, just saying. Indeed, but given the TLV includes an explicit length field, I think it jus= t works. > c) Your email sounds as if this new identifier for a destination is solely there to allow writing a more logical draft. I don't think that is true though, and i think a nicer reading draft text wouldn't be good enough justification for adding a protocol identifier that router and modem coder would need to implement. Not solely, clarity might be a useful side effect. > 1) Having a destination identifier separate from DMAC would of course allow to have destinations change their DMAC. If that is useful, i don't know. If we do know a use case and we do this protocol change, then it would be great to mentoin that use-case. I don't have a specific use-case for this, but it would allow routers to ch= ange MAC during the lifetime of a session. How the TCP session stays up during a MAC change is beyond my ken however..= . > 2) Having a destination identifier separate from DMAC would allow for destinations to NOT have a DMAC, eg: making DMAC optional. I do not know if you intend to support this: This I can see being useful for 3 cases:=20 a) L3 only modems (out of scope here). b) Broad/Any/Multi-cast. c) 1 modem talking DLEP to multiple routers (1 destination, N router MACs) > 2.1) for a "normal" destination (router/host), i can not see how this would work. Without MAC nor IP, a router could IMHO not make heads or tail out of such a destination. Correct, there must be at least 1 address, L2 or L3. > 2.2) for a special "default destination" which i think is what Bryan would like to see for sat spoke modems, this would work. The "default destination" does not need MAC or IP identification. It needs to have a pre-defined, unique identifier though so that a DLEP router recognizes it and appropriately deals with it. I'm not keen on a 'magic number' to mean default destination. I would rath= er have a TLV that means "This is the default link for layer2 traffic". DL= EP TLV's are the best way to communicate properties of a destination, rathe= r than encoding the properties into the identifier itself. This is the rea= son for my change of heart with Brian's proposal. =20 > 2.3) Another special destination could be a destination that really only says "network DOES/DOES-NOT support L2 multicast". That somehow is missing. Hmmm, the ability to have a 'Multicast accessibility TLV' alongside an Addr= ess TLV would fit with this identifier model. But the specifics of multicas= t are better discussed in another thread I think. > If a (radio) network does NOT support L2 multicast, then all modems need to announce "normal" destinations with both MAC and IP address, so that routers can use DLEP to replace ARP, and routers would need to replicate IP multicast as replicated ethernet unicast across the (radio) network. Absolutely, if there is no L2 broadcast capability in the modem, there MUST= be an address provided for a destination. In fact DLEP is harsher, and cu= rrently forces that there MUST be an L2 address for a destination whether b= roadcast is an option or not (again this ties in with Brian's problem). > If the radio network DOES support L2 multicast, then MAC addresses formal destinations are IMHO still mandatory, but IP addresses are optional. If supported by the DLEP modems, they can help to optimize the RTTs of ARP away and save RF bandwidth. Yes, that's stock DLEP as it currently stands. Without address information= , there is no way for a router to match the flow of packets to/from a desti= nation to the link over which the packets will travel. > 2.3) If the concept of destination is meant to be used to indicate individual multicast groups, that warrants a longer discussion, let me put this into another mail thread. I would like the concept of destination to have a single consistent meaning= for uni/broad/any/multi-cast. Originally Stan was calling them Neighbours= , Radio guys often call them Links, but Destinations is a better name: It'= s the grouping for a set of 1 or more remote addresses and metrics for the = path to them, 1 in the unicast case, N in the multicast case. (Flows are t= o be addressed in a later draft, don't go there!)=20 Thanks for your constructive feedback, Rick From nobody Sun Jul 27 07:42:41 2014 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 7A1EE1A02A3 for ; Sun, 27 Jul 2014 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 u4Rbcz-9NnfK for ; Sun, 27 Jul 2014 07:42:34 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 C06B51A028B for ; Sun, 27 Jul 2014 07:42:32 -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; Sun, 27 Jul 2014 15:41:53 +0100 From: Rick Taylor To: Abdussalam Baryun Thread-Topic: [manet] DLEP proposal Thread-Index: AQHPqVv0NvjJ0G2O9kOsz+i0mCv+bJuz+t7Q Date: Sun, 27 Jul 2014 14:41:59 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB8B1@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801148DB8B1tssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9sBvwUJ1GV_EHaz3-_uGVRssLDA Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 14:42:38 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801148DB8B1tssserver1hom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW5saW5l4oCmDQoNCkZyb206IEFiZHVzc2FsYW0gQmFyeXVuIFttYWlsdG86YWJk dXNzYWxhbWJhcnl1bkBnbWFpbC5jb21dDQpTZW50OiAyNyBKdWx5IDIwMTQgMDY6MzENClRvOiBS aWNrIFRheWxvcg0KQ2M6IFN0YW4gUmF0bGlmZjsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbWFuZXRdIERMRVAgcHJvcG9zYWwNCg0KSGkgUmljaywNCg0KVGhhbmtzLiBJTU8gZm9yIHNp bXBsaWNpdHkgYW5kIGZsZXhpYmxlIHB1cnBvc2VzIEkgdGhpbmsgRExFUCBkb2VzIG5vdCBuZWVk IGFueSBjaGFuZ2VzLCBidXQgbWF5YmUgZWRpdG9yaWFsLCBiZWNhdXNlIHRoZSBkcmFmdCBtYWtl cyBjbGVhciBhc3N1bXB0aW9ucyBhbmQgZG9lcyBub3QgZ28gaW50byBtb2RlbSBjb25maWd1cmlu ZyBvciByb3V0ZXIgY29uZmlndXJpbmcuDQoNCkluIG15IGV4cGVyaWVuY2UsIGEgbG90IG9mIHBl b3BsZSBtaXNzIHRoZSBkdWFsIHVzZSBvZiBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzc2VzIGluIERM RVAgYW5kIG5lZWQgaXQgZXhwbGFpbmVkLiAgQWxzbywgSSBiZWxpZXZlIHNlcGFyYXRpbmcgdGhl IHR3byBtaWdodCBlbmFibGUgc29tZSBvZiB0aGUgbXVsdGljYXN0IGlzc3VlcyB3ZSBoYXZlIHRv IGJlIHNpbXBsaWZpZWQuDQoNCkhvd2V2ZXIsIG15IGNvbW1lbnRzIGJlbG93LA0KDQpPbiBTYXR1 cmRheSwgSnVseSAyNiwgMjAxNCwgUmljayBUYXlsb3Igd3JvdGU6DQpTdGFuLCBBbGwsDQoNCkFz IERMRVAgc3RhcnRzIHRvIGdldCBwaWNrZWQgdXAgYW5kIGxvb2tlZCBhdCwgYW4gaW5jcmVhc2lu ZyBudW1iZXIgb2YgcG90ZW50aWFsIGltcGxlbWVudGVycyBrZWVwIGdldHRpbmcgY29uZnVzZWQg YWJvdXQgd2hhdCB3ZSB3aXRoaW4gdGhlIERMRVAgRFQgc2VlIGFzIGEgc2ltcGxlIGlzc3VlOiBE ZXN0aW5hdGlvbiBNQUMgYWRkcmVzc2VzLg0KDQpJIHRoaW5rIHdlIGNvbnNpZGVyIHRoYXQgRExF UCBkZXN0aW5hdGlvbnMvbmVpZ2hib3VycyBoYXZlIE1BQyBhZGRyZXNzZXMuDQoNClllcywgSW4g Y29yZSBETEVQLCB0aGV5IGRvLiAgSSBhbSBwcm9wb3NpbmcgY2hhbmdpbmcgdGhlIHBhY2tldCBs YXlvdXQsIG5vdCByZW1vdmluZyBNQUNzLg0KDQoNCkFzIEkgaGF2ZSBzdGF0ZWQgYmVmb3JlLCBE TEVQIHVzZXMgTUFDIGFkZHJlc3NlcyBmb3IgMiBkaXN0aW5jdCBwdXJwb3NlczogMSkgQXMgYSBk ZXN0aW5hdGlvbiBkaXNjcmltaW5hdG9yL2lkZW50aWZpZXIsIDIpIFRvIGFkdmVydGlzZSB0aGUg YXR0YWNoZWQgcm91dGVyJ3MgTUFDIGFkZHJlc3MuDQoNCklnbm9yaW5nIHRoZSBzcGVjaWZpY3Mg b2YgbXkgdW51c3VhbCB1c2UtY2FzZSBvZiBsYXllci0zIG1vZGVtcywgaW4gbXkgZHJhZnQgZXh0 ZW5zaW9uIEkgc3VnZ2VzdCBjaGFuZ2luZyBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzc2VzIHRvIHVu aXF1ZSBudW1lcmljIGlkZW50aWZpZXJzIGdlbmVyYXRlZCBieSB0aGUgbW9kZW0uICBPbiBjb25z aWRlcmF0aW9uIEkgdGhpbmsgaXQgbWFrZXMgbW9yZSBzZW5zZSB0byBkbyB0aGlzIGZvciBjb3Jl IERMRVAsIGFuZCBhZGQgdGhlIE1BQyBhZGRyZXNzIGFzIGEgZGF0YS1pdGVtIFRMViwgbXVjaCBs aWtlIGxheWVyLTMgYWRkcmVzc2VzIGFyZSBjdXJyZW50bHkgaGFuZGxlZC4NCg0KV2Ugd2FudCBE TEVQIHRvIGNvbnNpZGVyIHdpZGUgdXNlIGNhc2VzLCBzbyBpZiB3ZSBkbyB0aGF0IHN1Z2dlc3Rp b24gdGhlbiBETEVQIGNvcmUgbWF5IGxvb3NlIGZsZXhpYmlsaXR5IGFzIHRoZSBzdWdnZXN0aW9u ICh3aGljaCBJIHVuZGVyc3RhbmQgaXRzIHB1cnBvc2VzKSBjYW4gc3RpbGwgYmUgYWRkZWQgYXMg ZXh0ZW5zaW9uIHRvIGNvcmUuDQoNClllcywgaXQgY291bGQgZXhpc3QgYXMgYW4gZXh0ZW5zaW9u IG9ubHksIHRoYXQgd2FzIHRoZSBwb2ludCBvZiBteSBkcmFmdCwgYnV0IEkgdGhpbmsgaXQgbWln aHQgYmUgdXNlZnVsIGluIHRoZSBjb3JlIHNwZWMuDQoNCg0KSG9wZWZ1bGx5IHRoaXMgd2lsbCBt YWtlIHRoZSBETEVQIG1vZGVsIG1vcmUgb2J2aW91cyB0byBuZXdjb21lcnM6ICBBIGRlc3RpbmF0 aW9uIGhhcyBhbiBJRCwgYW5kIHNvbWUgZGF0YS1pdGVtcyBkZXNjcmliaW5nIGl0LCBvbmUgb2Yg d2hpY2ggTVVTVCBiZSBhIE1BQyBhZGRyZXNzIFRMVi4gIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIHBy b3RvY29sIGFyZSB1bmNoYW5nZWQsIHdlIGRvbid0IGNhcmUgYWJvdXQgZXh0cmEgb2N0ZXRzIG9u IHRoZSBsb2NhbCBsaW5rIChpbiBwcmluY2lwbGUpLCBhbmQgdGhlIG1lYW5pbmcgbWlnaHQgYmUg Y2xlYXJlciB0byByZWFkZXJzLg0KDQpJIGFncmVlIHdpdGggeW91LCBidXQgSSB0aGluayBpcyB3 YXMgbWVudGlvbmVkIHNvbWUgd2hlcmUgaW4gdGhlIGRyYWZ0IChub3Qgc3VyZSkuDQoNClRoZSBk cmFmdCBpbXBsaWVzIHRoYXQgZGVzdGluYXRpb25zIE1VU1QgaGF2ZSBhIE1BQyBiZWNhdXNlIHRo ZSBkZXN0aW5hdGlvbiBpZGVudGlmaWVyIElTIHRoZSBNQUMuDQoNCg0KSSB3b3VsZCBzdWdnZXN0 IGEgMzItYml0IGRlc3RpbmF0aW9uIGlkZW50aWZpZXIsIGFuZCBJIGFzc3VtZSB0aGF0IG1vc3Qg UkYgZXF1aXBtZW50IGhhcyBzb21lIGNvbmNlcHQgb2YgYSAnbGluayBpZCcgdGhhdCBtaWdodCBi ZSByZXVzYWJsZS9tYXBwYWJsZSBpbiB0aGUgRExFUCBhZ2VudCwgc28gSSBkb24ndCBiZWxpZXZl IGl0IGFkZHMgZXh0cmEgYnVyZGVuIG9uIGltcGxlbWVudGVycy4NCg0Kd2h5PyBkb2VzIERMRVAg bm90IGNvdmVyIHRoYXQgaXNzdWUgb2YgbGluayBiZXR3ZWVuIG1vZGVtcy4gRWFjaCBNQUMgYWRk cmVzcyBoYXMgb25lIGxpbmsgc28gaXQgYWxyZWFkeSBpZGVudGlmaWVzIGl0Lg0KDQpXaGF0IGlm IHRoZXJlIGFyZSBtdWx0aXBsZSByb3V0ZXJzIGNvbm5lY3RlZCBsb2NhbGx5IHRvIG9uZSBtb2Rl bSwgd2hhdCBpcyB0aGUgZGVzdGluYXRpb24gTUFDIHJlcG9ydGVkIGF0IG90aGVyIG1vZGVtcyBp biB0aGUgcmFkaW8gbmV0Pw0KDQoNClRoZSBNQUMgYWRkcmVzcyBUTFYgc2hvdWxkIGJlIG9idmlv dXMgdG8gZm9ybXVsYXRlOiBUeXBlID0gVEJELCBMZW5ndGggPSA2LCBWYWx1ZSA9IE1BQyBvY3Rl dHMuICBVbmxpa2UgSVAgYWRkcmVzcyBUTFZzIHRoZXJlIGlzIG5vIG5lZWQgZm9yIEFkZC9Ecm9w IGluZGljYXRvcnMuDQoNCkl0IGhhcyB0aGUgYWR2YW50YWdlIHRoYXQgdGhlIERMRVAgZHJhZnQg dGV4dCBjYW4gdGFsayBhYm91dCBkZXN0aW5hdGlvbnMgYXMgY29uY2VwdCBpbiBvbmUgc2VjdGlv biwgYW5kIHRoZW4gZGlzY3VzcyByb3V0ZXIgTUFDcyBhbmQgYWRkcmVzc2VzIGluIGFub3RoZXIg ZGlzY3JldGUgc2VjdGlvbiwgaG9wZWZ1bGx5IGF2b2lkaW5nIHNvbWUgZmlyc3QtcGFzcyBjb25m dXNpb24gaW4gdGhlIHJlYWRlci4NCg0KSSB0aGluayB0aGUgaW50cm9kdWN0aW9uIGRvZXMgY2xh cmlmeSB0aGF0LCBidXQgbWF5YmUgbm90IG11Y2ggZm9jdXMgb24gb25lIGl0ZW0gYXMgdGhlIGRl c3RpbmF0aW9ucyBiZWNhdXNlIGl0IGNvbnNpZGVycyBtYW55IGl0ZW1zIHRvZ2V0aGVyLg0KDQoN ClRoZSBvbmx5IHRoaW5nIHRoaXMgcHJvcG9zYWwgYnJlYWtzIGlzIG11bHRpY2FzdCBkZXN0aW5h dGlvbnMsIGJ1dCBoYXZpbmcgaGFkIGEgbG9uZyBjaGF0IHdpdGggVG9lcmxlc3MgRWNrZXJ0IHdo byBpcyBoZWF2aWx5IGludm9sdmVkIGluIHRoZSBQSU0gV0csIHdlIG1heSBub3QgaGF2ZSB0aG91 Z2h0IHRocm91Z2ggdGhlIG11bHRpY2FzdC9hbnljYXN0L2Jyb2FkY2FzdCBwYXJ0IG9mIERMRVAg dGhvcm91Z2hseSB5ZXQgKGFuZCB0aGF0IHJlcXVpcmVzIGEgbmV3IHRocmVhZCkuDQoNCkRMRVAg ZG9lcyBhbm90aGVyIHNwZWNpYWwgbXVsdGljYXN0IGl0IGlzIG5vdCBzaW1pbGFyIHRvIHRoZSBM MyBtdWx0aWNhc3QuDQoNCkRMRVAgZG9lc27igJl0IGRvIG11bHRpY2FzdCwgaXQgdGFsa3MgYWJv dXQgbXVsdGljYXN0LCBidXQgaXQgc3RpbGwgbmVlZHMgc29tZSBjYXJlZnVsIHJldmlldy4NCg0K DQpJdCBhbHNvIG1pZ2h0IHNvbHZlIGEgdXNlLWNhc2UgcHJvYmxlbSB3ZSBoYXZlIHNraXJ0ZWQg YXJvdW5kOiAxIG1vZGVtIHdpdGggMiBETEVQIHNlc3Npb25zIHRvIDIgcm91dGVycy4gIFdpdGgg dGhpcyBwcm9wb3NhbCwgYSBzaW5nbGUgc2V0IG9mIGRlc3RpbmF0aW9uIGlkZW50aWZpZXJzIGNv dWxkIGJlIHVzZWQsIGFuZCAyIE1BQyBUTFYncyBhZGRlZCB0byB0aGUgZGVzdGluYXRpb24gdXAs IGkuZS4gIkkgaGF2ZSB0d28gdXBzdHJlYW0gcm91dGVycywgZ28gY2hhdC4uLiINCg0KVGhlIERM RVAgcHJvdG9jb2wgaXMgdGhhdDogRWFjaCBtb2RlbSBoYXMgb25seSBvbmUgRExFUC1zZXNzaW9u IHRvIG9uZSByb3V0ZXIuDQoNCk5vdCB0cnVlIChhbnltb3JlKS4gIFRoaXMgd2FzIHZpZXdlZCBh cyBhbiB1bm5lY2Vzc2FyeSByZXN0cmljdGlvbiBieSB0aGUgRExFUCBEVCBhbmQgd2FzIHBsYW5u ZWQgZm9yIHJlbW92YWwuICBIb3dldmVyLCBpZiBpdCBjYW7igJl0IGJlIGhhbmRsZWQgY2xlYW5s eSwgdGhlbiBpdCBtaWdodCBjb21lIGJhY2suDQoNCg0KTG9iYnlpbmcgZm9yIG9uZSBvZiBteSBj b3JuZXItY2FzZXMsIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBEZXN0aW5hdGlvbiBVcCBzaWdu YWwgdGV4dCBzdGF0ZXMgc29tZXRoaW5nIGxpa2U6ICJBIGRlc3RpbmF0aW9uIHVwIHNpZ25hbCBN VVNUIGluY2x1ZGUgMSBNQUMgYWRkcmVzcyBUTFYgb3IgMSBJUHY0IGFkZHJlc3MgVExWIG9yIDEg SVB2NiBhZGRyZXNzIFRMVi4NCg0KWW91IG1heSBzYXkgTDIgYWRkcmVzcyBUTFYuIEhvd2V2ZXIs IHRoYXQgbWF5IG1ha2UgRExFUCBub3QgZmxleGlibGUgdG8gY292ZXIgYWxsIHBvc3NpYmxlIGRl c3RpbmF0aW9ucyBhbmQgdXNlIGNhc2VzLg0KDQpPa2F5LCBwZXJoYXBzIEkgc2hvdWxkIHNheTog 4oCcTVVTVCBjb250YWluIGF0IGxlYXN0IG9uZSBMMiBvciBMMyBhZGRyZXNzIFRMVuKAnS4gICBJ IGFncmVlIHdpdGggeW91Lg0KDQpJdCBTSE9VTEQgcHJvdmlkZSBhIE1BQyBhZGRyZXNzIFRMViwg YW5kIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYXQgbGVhc3QgMSBJUHY0IG9yIElQVjYgYWRkcmVz cyBUTFYgYmUgaW5jbHVkZWQuIg0KDQpZZXMsIHdlIGNhbiB1c2UgInNob3VsZCIgcmF0aGVyIHRo YW4gIm11c3QiLg0KDQoNCkFzIEkgdGhpbmsgYWJvdXQgaXQsIE1BQy1sZXNzIGRlc3RpbmF0aW9u cyB3aXRoIElQIG11bHRpY2FzdCBhZGRyZXNzZXMvc3VibmV0cyBtaWdodCBiZSB0aGUgYmV0dGVy IHdheSB0byBoYW5kbGUgbXVsdGljYXN0IGRlc3RpbmF0aW9ucy4uLg0KDQpETEVQIGlzIGRlc2ln bmVkIHRvIGhhdmUgTUFDIGFkZHJlc3NlcywgYnV0IHdlIGNhbiBtYWtlIGl0IEwyIGFkZHJlc3Nl cyB0byBiZSBnZW5lcmFsLg0KDQpZZXMsIHRoYXQgd291bGQgZml0IHdpdGggdGhpcyBwcm9wb3Nh bC4gIEN1cnJlbnRseSBETEVQIHVzZXMgNDgtYml0IE1BQyBhZGRyZXNzZXMsIGJ1dCBpdCB3b3Vs ZCBiZSBuaWNlIHRvIHVzZSBnZW5lcmljIEwyIGFkZHJlc3NlcywgYWx0aG91Z2ggSeKAmW0gbm90 IHN1cmUgYW55b25lIGlzIGludGVuZGluZyB0byB1c2UgYW55dGhpbmcgYXBhcnQgZnJvbSBFdGhl cm5ldCBhdCBsYXllci0yLCBwZXJoYXBzIExpbmstMTY/DQoNCldlIGhhdmUgdHdvIGtpbmQgb2Yg RExFUCBkZXN0aW5hdGlvbnM7IDEpIGF0IEwyICwgMikgYXQgTDMuIFNvIERMRVAgaGFuZGxlcyBt dWx0aWNhc3QgYWRkcmVzc2VzIG9mIEwyIGFuZCBub3QgTDMuDQoNCkkgZGlzYWdyZWUsIERMRVAg aGFzIERlc3RpbmF0aW9ucy4gIEEgZGVzdGluYXRpb24gbWlnaHQgYmUgYSBzaW5nbGUgZW5kcG9p bnQgb3IgYSBtdWx0aXBvaW50LiAgVGhlIEwyIG9yIEwzIGFkZHJlc3NlcyBhcmUganVzdCBwcm9w ZXJ0aWVzIG9mIHRoZSBEZXN0aW5hdGlvbi4NCg0KQUINCg0KVGhhbmtzIGZvciByZXZpZXdpbmcg QUIhDQoNClJpY2sNCg0KDQoNCg0KQW55d2F5LCAiZmlyZSBpbiB0aGUgaG9sZSEiDQpXDQpDaGVl cnMsDQoNClJpY2sNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPGphdmFzY3JpcHQ6 Oz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg== --_000_38A5475DE83986499AEACD2CFAFC3F9801148DB8B1tssserver1hom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNvbW1lbnRzIGlubGluZeKApjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20n PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBB YmR1c3NhbGFtIEJhcnl1biBbbWFpbHRvOmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tXSA8YnI+ PGI+U2VudDo8L2I+IDI3IEp1bHkgMjAxNCAwNjozMTxicj48Yj5Ubzo8L2I+IFJpY2sgVGF5bG9y PGJyPjxiPkNjOjwvYj4gU3RhbiBSYXRsaWZmOyBtYW5ldEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0 OjwvYj4gUmU6IFttYW5ldF0gRExFUCBwcm9wb3NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPkhpIFJpY2ssPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzLiBJTU8g Zm9yIHNpbXBsaWNpdHkgYW5kIGZsZXhpYmxlJm5ic3A7cHVycG9zZXMmbmJzcDtJJm5ic3A7dGhp bmsgRExFUCBkb2VzIG5vdCBuZWVkIGFueSBjaGFuZ2VzLCBidXQgbWF5YmUgZWRpdG9yaWFsLCZu YnNwO2JlY2F1c2UgdGhlIGRyYWZ0Jm5ic3A7bWFrZXMgY2xlYXImbmJzcDthc3N1bXB0aW9ucyZu YnNwO2FuZCZuYnNwO2RvZXMgbm90IGdvIGludG8gbW9kZW0gY29uZmlndXJpbmcgb3Igcm91dGVy IGNvbmZpZ3VyaW5nLiA8c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5JbiBteSBleHBlcmllbmNlLCBhIGxvdCBvZiBwZW9wbGUgbWlzcyB0aGUgZHVhbCB1c2Ug b2YgZGVzdGluYXRpb24gTUFDIGFkZHJlc3NlcyBpbiBETEVQIGFuZCBuZWVkIGl0IGV4cGxhaW5l ZC4gwqBBbHNvLCBJIGJlbGlldmUgc2VwYXJhdGluZyB0aGUgdHdvIG1pZ2h0IGVuYWJsZSBzb21l IG9mIHRoZSBtdWx0aWNhc3QgaXNzdWVzIHdlIGhhdmUgdG8gYmUgc2ltcGxpZmllZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5Ib3dldmVyLCBt eSBjb21tZW50cyBiZWxvdyw8YnI+PGJyPk9uIFNhdHVyZGF5LCBKdWx5IDI2LCAyMDE0LCBSaWNr IFRheWxvciB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+U3RhbiwgQWxs LDxicj48YnI+QXMgRExFUCBzdGFydHMgdG8gZ2V0IHBpY2tlZCB1cCBhbmQgbG9va2VkIGF0LCBh biBpbmNyZWFzaW5nIG51bWJlciBvZiBwb3RlbnRpYWwgaW1wbGVtZW50ZXJzIGtlZXAgZ2V0dGlu ZyBjb25mdXNlZCBhYm91dCB3aGF0IHdlIHdpdGhpbiB0aGUgRExFUCBEVCBzZWUgYXMgYSBzaW1w bGUgaXNzdWU6IERlc3RpbmF0aW9uIE1BQyBhZGRyZXNzZXMuPG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+SSB0aGluayB3ZSBjb25zaWRlciZuYnNwO3RoYXQgRExFUCZuYnNwO2Rlc3Rp bmF0aW9ucy9uZWlnaGJvdXJzJm5ic3A7aGF2ZSZuYnNwO01BQyBhZGRyZXNzZXMuJm5ic3A7PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlllcywgSW4gY29yZSBETEVQLCB0aGV5IGRvLsKgIEkgYW0gcHJvcG9zaW5nIGNo YW5naW5nIHRoZSBwYWNrZXQgbGF5b3V0LCBub3QgcmVtb3ZpbmcgTUFDcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkFzIEkgaGF2ZSBzdGF0 ZWQgYmVmb3JlLCBETEVQIHVzZXMgTUFDIGFkZHJlc3NlcyBmb3IgMiBkaXN0aW5jdCBwdXJwb3Nl czogMSkgQXMgYSBkZXN0aW5hdGlvbiBkaXNjcmltaW5hdG9yL2lkZW50aWZpZXIsIDIpIFRvIGFk dmVydGlzZSB0aGUgYXR0YWNoZWQgcm91dGVyJ3MgTUFDIGFkZHJlc3MuPGJyPjxicj5JZ25vcmlu ZyB0aGUgc3BlY2lmaWNzIG9mIG15IHVudXN1YWwgdXNlLWNhc2Ugb2YgbGF5ZXItMyBtb2RlbXMs IGluIG15IGRyYWZ0IGV4dGVuc2lvbiBJIHN1Z2dlc3QgY2hhbmdpbmcgZGVzdGluYXRpb24gTUFD IGFkZHJlc3NlcyB0byB1bmlxdWUgbnVtZXJpYyBpZGVudGlmaWVycyBnZW5lcmF0ZWQgYnkgdGhl IG1vZGVtLiAmbmJzcDtPbiBjb25zaWRlcmF0aW9uIEkgdGhpbmsgaXQgbWFrZXMgbW9yZSBzZW5z ZSB0byBkbyB0aGlzIGZvciBjb3JlIERMRVAsIGFuZCBhZGQgdGhlIE1BQyBhZGRyZXNzIGFzIGEg ZGF0YS1pdGVtIFRMViwgbXVjaCBsaWtlIGxheWVyLTMgYWRkcmVzc2VzIGFyZSBjdXJyZW50bHkg aGFuZGxlZC48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2Ug d2FudCBETEVQIHRvIGNvbnNpZGVyIHdpZGUgdXNlIGNhc2VzLCBzbyBpZiB3ZSBkbyB0aGF0IHN1 Z2dlc3Rpb24gdGhlbiBETEVQIGNvcmUgbWF5IGxvb3NlIGZsZXhpYmlsaXR5IGFzIHRoZSBzdWdn ZXN0aW9uICh3aGljaCBJIHVuZGVyc3RhbmQgaXRzIHB1cnBvc2VzKSZuYnNwO2NhbiBzdGlsbCBi ZSBhZGRlZCBhcyBleHRlbnNpb24gdG8gY29yZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+WWVzLCBpdCBj b3VsZCBleGlzdCBhcyBhbiBleHRlbnNpb24gb25seSwgdGhhdCB3YXMgdGhlIHBvaW50IG9mIG15 IGRyYWZ0LCBidXQgSSB0aGluayBpdCBtaWdodCBiZSB1c2VmdWwgaW4gdGhlIGNvcmUgc3BlYy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkhv cGVmdWxseSB0aGlzIHdpbGwgbWFrZSB0aGUgRExFUCBtb2RlbCBtb3JlIG9idmlvdXMgdG8gbmV3 Y29tZXJzOiAmbmJzcDtBIGRlc3RpbmF0aW9uIGhhcyBhbiBJRCwgYW5kIHNvbWUgZGF0YS1pdGVt cyBkZXNjcmliaW5nIGl0LCBvbmUgb2Ygd2hpY2ggTVVTVCBiZSBhIE1BQyBhZGRyZXNzIFRMVi4g Jm5ic3A7VGhlIHNlbWFudGljcyBvZiB0aGUgcHJvdG9jb2wgYXJlIHVuY2hhbmdlZCwgd2UgZG9u J3QgY2FyZSBhYm91dCBleHRyYSBvY3RldHMgb24gdGhlIGxvY2FsIGxpbmsgKGluIHByaW5jaXBs ZSksIGFuZCB0aGUgbWVhbmluZyBtaWdodCBiZSBjbGVhcmVyIHRvIHJlYWRlcnMuPG86cD48L286 cD48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgYWdyZWUgd2l0aCB5b3UsJm5i c3A7YnV0Jm5ic3A7SSB0aGluayBpcyB3YXMgbWVudGlvbmVkIHNvbWUgd2hlcmUgaW4gdGhlIGRy YWZ0IChub3Qgc3VyZSkuJm5ic3A7PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+VGhlIGRyYWZ0IGltcGxpZXMgdGhhdCBkZXN0aW5hdGlvbnMgTVVTVCBoYXZl IGEgTUFDIGJlY2F1c2UgdGhlIGRlc3RpbmF0aW9uIGlkZW50aWZpZXIgSVMgdGhlIE1BQy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkkgd291 bGQgc3VnZ2VzdCBhIDMyLWJpdCBkZXN0aW5hdGlvbiBpZGVudGlmaWVyLCBhbmQgSSBhc3N1bWUg dGhhdCBtb3N0IFJGIGVxdWlwbWVudCBoYXMgc29tZSBjb25jZXB0IG9mIGEgJ2xpbmsgaWQnIHRo YXQgbWlnaHQgYmUgcmV1c2FibGUvbWFwcGFibGUgaW4gdGhlIERMRVAgYWdlbnQsIHNvIEkgZG9u J3QgYmVsaWV2ZSBpdCBhZGRzIGV4dHJhIGJ1cmRlbiBvbiBpbXBsZW1lbnRlcnMuPG86cD48L286 cD48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPndoeT8mbmJzcDtkb2VzIERMRVAg bm90IGNvdmVyIHRoYXQgaXNzdWUgb2YgbGluayBiZXR3ZWVuIG1vZGVtcy4gRWFjaCBNQUMgYWRk cmVzcyBoYXMgb25lIGxpbmsgc28gaXQgYWxyZWFkeSBpZGVudGlmaWVzIGl0LjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5XaGF0IGlmIHRoZXJlIGFyZSBtdWx0aXBsZSByb3V0ZXJzIGNvbm5lY3RlZCBsb2NhbGx5IHRv IG9uZSBtb2RlbSwgd2hhdCBpcyB0aGUgZGVzdGluYXRpb24gTUFDIHJlcG9ydGVkIGF0IG90aGVy IG1vZGVtcyBpbiB0aGUgcmFkaW8gbmV0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90 ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20n PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+VGhlIE1BQyBhZGRyZXNzIFRMViBzaG91bGQgYmUgb2J2 aW91cyB0byBmb3JtdWxhdGU6IFR5cGUgPSBUQkQsIExlbmd0aCA9IDYsIFZhbHVlID0gTUFDIG9j dGV0cy4gJm5ic3A7VW5saWtlIElQIGFkZHJlc3MgVExWcyB0aGVyZSBpcyBubyBuZWVkIGZvciBB ZGQvRHJvcCBpbmRpY2F0b3JzLjxicj48YnI+SXQgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCB0aGUg RExFUCBkcmFmdCB0ZXh0IGNhbiB0YWxrIGFib3V0IGRlc3RpbmF0aW9ucyBhcyBjb25jZXB0IGlu IG9uZSBzZWN0aW9uLCBhbmQgdGhlbiBkaXNjdXNzIHJvdXRlciBNQUNzIGFuZCBhZGRyZXNzZXMg aW4gYW5vdGhlciBkaXNjcmV0ZSBzZWN0aW9uLCBob3BlZnVsbHkgYXZvaWRpbmcgc29tZSBmaXJz dC1wYXNzIGNvbmZ1c2lvbiBpbiB0aGUgcmVhZGVyLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90 ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5JIHRoaW5rIHRoZSBpbnRyb2R1Y3Rpb24gZG9lcyBjbGFyaWZ5 IHRoYXQsIGJ1dCBtYXliZSBub3QgbXVjaCBmb2N1cyBvbiBvbmUgaXRlbSBhcyB0aGUmbmJzcDtk ZXN0aW5hdGlvbnMgYmVjYXVzZSBpdCBjb25zaWRlcnMgbWFueSBpdGVtcyB0b2dldGhlci4mbmJz cDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxwIGNsYXNzPU1zb05vcm1hbD48YnI+VGhlIG9u bHkgdGhpbmcgdGhpcyBwcm9wb3NhbCBicmVha3MgaXMgbXVsdGljYXN0IGRlc3RpbmF0aW9ucywg YnV0IGhhdmluZyBoYWQgYSBsb25nIGNoYXQgd2l0aCBUb2VybGVzcyBFY2tlcnQgd2hvIGlzIGhl YXZpbHkgaW52b2x2ZWQgaW4gdGhlIFBJTSBXRywgd2UgbWF5IG5vdCBoYXZlIHRob3VnaHQgdGhy b3VnaCB0aGUgbXVsdGljYXN0L2FueWNhc3QvYnJvYWRjYXN0IHBhcnQgb2YgRExFUCB0aG9yb3Vn aGx5IHlldCAoYW5kIHRoYXQgcmVxdWlyZXMgYSBuZXcgdGhyZWFkKS48bzpwPjwvbzpwPjwvcD48 L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RExFUCBkb2VzIGFub3RoZXIgc3BlY2lhbCZu YnNwO211bHRpY2FzdCZuYnNwO2l0IGlzIG5vdCBzaW1pbGFyIHRvIHRoZSZuYnNwO0wzIG11bHRp Y2FzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RExFUCBkb2VzbuKAmXQgZG8gbXVsdGljYXN0LCBpdCB0 YWxrcyBhYm91dCBtdWx0aWNhc3QsIGJ1dCBpdCBzdGlsbCBuZWVkcyBzb21lIGNhcmVmdWwgcmV2 aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxwIGNsYXNzPU1zb05vcm1hbD48 YnI+SXQgYWxzbyBtaWdodCBzb2x2ZSBhIHVzZS1jYXNlIHByb2JsZW0gd2UgaGF2ZSBza2lydGVk IGFyb3VuZDogMSBtb2RlbSB3aXRoIDIgRExFUCBzZXNzaW9ucyB0byAyIHJvdXRlcnMuICZuYnNw O1dpdGggdGhpcyBwcm9wb3NhbCwgYSBzaW5nbGUgc2V0IG9mIGRlc3RpbmF0aW9uIGlkZW50aWZp ZXJzIGNvdWxkIGJlIHVzZWQsIGFuZCAyIE1BQyBUTFYncyBhZGRlZCB0byB0aGUgZGVzdGluYXRp b24gdXAsIGkuZS4gJnF1b3Q7SSBoYXZlIHR3byB1cHN0cmVhbSByb3V0ZXJzLCBnbyBjaGF0Li4u JnF1b3Q7PG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBE TEVQIHByb3RvY29sIGlzIHRoYXQ6Jm5ic3A7RWFjaCBtb2RlbSBoYXMgb25seSBvbmUgRExFUC1z ZXNzaW9uIHRvIG9uZSByb3V0ZXIuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5Ob3QgdHJ1ZSAoYW55bW9yZSkuwqAgVGhpcyB3YXMgdmlld2VkIGFzIGFuIHVubmVjZXNz YXJ5IHJlc3RyaWN0aW9uIGJ5IHRoZSBETEVQIERUIGFuZCB3YXMgcGxhbm5lZCBmb3IgcmVtb3Zh bC7CoCBIb3dldmVyLCBpZiBpdCBjYW7igJl0IGJlIGhhbmRsZWQgY2xlYW5seSwgdGhlbiBpdCBt aWdodCBjb21lIGJhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20nPjxwIGNsYXNzPU1zb05vcm1hbD48YnI+TG9iYnlpbmcgZm9yIG9uZSBvZiBteSBj b3JuZXItY2FzZXMsIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBEZXN0aW5hdGlvbiBVcCBzaWdu YWwgdGV4dCBzdGF0ZXMgc29tZXRoaW5nIGxpa2U6ICZxdW90O0EgZGVzdGluYXRpb24gdXAgc2ln bmFsIE1VU1QgaW5jbHVkZSAxIE1BQyBhZGRyZXNzIFRMViBvciAxIElQdjQgYWRkcmVzcyBUTFYg b3IgMSBJUHY2IGFkZHJlc3MgVExWLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+WW91IG1heSBzYXkgTDIgYWRkcmVzcyBUTFYuIEhvd2V2ZXIsIHRo YXQgbWF5IG1ha2UgRExFUCBub3QgZmxleGlibGUgdG8mbmJzcDtjb3ZlciBhbGwgcG9zc2libGUm bmJzcDtkZXN0aW5hdGlvbnMgYW5kIHVzZSBjYXNlcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+T2theSwgcGVyaGFw cyBJIHNob3VsZCBzYXk6IOKAnE1VU1QgY29udGFpbiBhdCBsZWFzdCBvbmUgTDIgb3IgTDMgYWRk cmVzcyBUTFbigJ0uIMKgwqBJIGFncmVlIHdpdGggeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20nPjxwIGNsYXNzPU1zb05vcm1hbD5JdCBTSE9VTEQgcHJvdmlkZSBhIE1BQyBhZGRy ZXNzIFRMViwgYW5kIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYXQgbGVhc3QgMSBJUHY0IG9yIElQ VjYgYWRkcmVzcyBUTFYgYmUgaW5jbHVkZWQuJnF1b3Q7PG86cD48L286cD48L3A+PC9ibG9ja3F1 b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlllcywgd2UgY2FuIHVzZSAmcXVvdDtzaG91bGQmcXVvdDsg cmF0aGVyIHRoYW4gJnF1b3Q7bXVzdCZxdW90Oy4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2tx dW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20nPjxwIGNsYXNzPU1zb05vcm1hbD48YnI+QXMgSSB0aGluayBhYm91dCBpdCwgTUFDLWxlc3Mg ZGVzdGluYXRpb25zIHdpdGggSVAgbXVsdGljYXN0IGFkZHJlc3Nlcy9zdWJuZXRzIG1pZ2h0IGJl IHRoZSBiZXR0ZXIgd2F5IHRvIGhhbmRsZSBtdWx0aWNhc3QgZGVzdGluYXRpb25zLi4uPG86cD48 L286cD48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkRMRVAgaXMgZGVzaWduZWQg dG8gaGF2ZSBNQUMgYWRkcmVzc2VzLCBidXQgd2UgY2FuIG1ha2UgaXQgTDIgYWRkcmVzc2VzIHRv IGJlIGdlbmVyYWwuPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+WWVzLCB0aGF0IHdvdWxkIGZpdCB3aXRoIHRoaXMgcHJvcG9zYWwuwqAgQ3VycmVudGx5IERM RVAgdXNlcyA0OC1iaXQgTUFDIGFkZHJlc3NlcywgYnV0IGl0IHdvdWxkIGJlIG5pY2UgdG8gdXNl IGdlbmVyaWMgTDIgYWRkcmVzc2VzLCBhbHRob3VnaCBJ4oCZbSBub3Qgc3VyZSBhbnlvbmUgaXMg aW50ZW5kaW5nIHRvIHVzZSBhbnl0aGluZyBhcGFydCBmcm9tIEV0aGVybmV0IGF0IGxheWVyLTIs IHBlcmhhcHMgTGluay0xNj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldlIGhh dmUgdHdvIGtpbmQgb2YgRExFUCZuYnNwO2Rlc3RpbmF0aW9uczsgMSkgYXQgTDIgLCAyKSBhdCBM My4gU28gRExFUCBoYW5kbGVzIG11bHRpY2FzdCBhZGRyZXNzZXMmbmJzcDtvZiBMMiBhbmQmbmJz cDtub3QgTDMuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGRpc2FncmVlLCBE TEVQIGhhcyBEZXN0aW5hdGlvbnMuwqAgQSBkZXN0aW5hdGlvbiBtaWdodCBiZSBhIHNpbmdsZSBl bmRwb2ludCBvciBhIG11bHRpcG9pbnQuwqAgVGhlIEwyIG9yIEwzIGFkZHJlc3NlcyBhcmUganVz dCBwcm9wZXJ0aWVzIG9mIHRoZSBEZXN0aW5hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+QUI8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIGZvciByZXZpZXdpbmcg QUIhPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SaWNrPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86 cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkFueXdh eSwgJnF1b3Q7ZmlyZSBpbiB0aGUgaG9sZSEmcXVvdDs8YnI+Vzxicj5DaGVlcnMsPGJyPjxicj5S aWNrPGJyPjxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPm1hbmV0IG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJqYXZhc2NyaXB0Ojsi Pm1hbmV0QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PC9k aXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_38A5475DE83986499AEACD2CFAFC3F9801148DB8B1tssserver1hom_-- From nobody Sun Jul 27 07:56:56 2014 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 758571A028B for ; Sun, 27 Jul 2014 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 5lw6Xr5fn3lj for ; Sun, 27 Jul 2014 07:56:53 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 4D3391A02D7 for ; Sun, 27 Jul 2014 07:56:53 -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; Sun, 27 Jul 2014 15:56:29 +0100 From: Rick Taylor To: "manet@ietf.org" Thread-Topic: [manet] DLEP proposal Thread-Index: AQHPqO9CBLm7Ds35Rki/xAnaEAWf0puz9QEAgAALEYA= Date: Sun, 27 Jul 2014 14:56:28 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB8CD@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> <20140726163257.GA28917@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.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: http://mailarchive.ietf.org/arch/msg/manet/0FoziRg-KGSkY_JXq-I6XV47atM Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 14:56:54 -0000 As I continue my fight with jetlag, I shall summarize my proposal, hoping i= t is clearer. All I'm suggesting is not using the remote DLEP router peer's MAC address a= s the primary key of the destination, but making it a property of the desti= nation, and just using a locally generated number as the primary key. It's= generally viewed as good practice in the database world to do this kind of= normalization, and I'm proposing that we do the same with DLEP. The most obvious complication with this proposal is currently DLEP suggests= that routers request metrics for multicast destinations by sending a Neigh= bour_Up signal to the local modem using the MAC address of the multicast gr= oup they are interested in. Continuing to use this method would require bo= th router and modem to agree a mechanism to generate consistent destination= identifiers. However, I am of the opinion that the MAC method is probably= not the best way to handle multicast destinations and should be handled in= a different way.=20 Also, I happen to know that some people on their first reading of the draft= become confused about the use of MAC addresses as identifiers as well as a= ddresses, and think that as a side-effect of my proposal, this confusion mi= ght disappear, but I don't consider this alone to be a reason to change the= draft. Regards, Rick From nobody Sun Jul 27 08:18:22 2014 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 4C8BB1A033B for ; Sun, 27 Jul 2014 08:18:14 -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 DuA1oKZ7RYvI for ; Sun, 27 Jul 2014 08:18:11 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066D81A0334 for ; Sun, 27 Jul 2014 08:18:10 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so6624515qab.32 for ; Sun, 27 Jul 2014 08:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mPxSskzcOjuIEj+EQsWkLcy5aOs0TL1vr5r9TVsohyY=; b=e7Tgxxc+mg20yqwyCYF6OCp1xjoC+SK4YEig05NUfZ/SrhAecW9ZPNK0ekDSdIjlFj k6q+qjwqrpsBAsq4MLB4gRaK7ws+7Zu5MbJqkdE9ubvh2TOHkrpYfpUsBUviEQeDNNxd WxX5Q17P6ID9uuch5bWAK7bOsRHOkzOHXg5re1Lwp5RufHCf0DSgCJwX4fnH3Raht+vH 9Dc8u/9rc7K7Q0Gw/K25W0LBnJPnVOEBLEdYg1x4eprHlt5IeCyXwYdpbQrHlEGI46ne /QWs7D95ho3c1yxSlmMrXX3bLiMSzDgtm9mZjEWOaHsQp/mGBF35JS9DOjm/bwa4EXac QyUw== X-Received: by 10.224.138.8 with SMTP id y8mr49581114qat.38.1406474290194; Sun, 27 Jul 2014 08:18:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Sun, 27 Jul 2014 08:17:50 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB8CD@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> <20140726163257.GA28917@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB8CD@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Sun, 27 Jul 2014 17:17:50 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HbPOV9SL-zcCbWCEmg425ugA1sw Cc: "manet@ietf.org" Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 15:18:14 -0000 On Sun, Jul 27, 2014 at 4:56 PM, Rick Taylor wrote: > As I continue my fight with jetlag, I shall summarize my proposal, hoping= it is clearer. > > All I'm suggesting is not using the remote DLEP router peer's MAC address= as the primary key of the destination, but making it a property of the des= tination, and just using a locally generated number as the primary key. It= 's generally viewed as good practice in the database world to do this kind = of normalization, and I'm proposing that we do the same with DLEP. > > The most obvious complication with this proposal is currently DLEP sugges= ts that routers request metrics for multicast destinations by sending a Nei= ghbour_Up signal to the local modem using the MAC address of the multicast = group they are interested in. Continuing to use this method would require = both router and modem to agree a mechanism to generate consistent destinati= on identifiers. However, I am of the opinion that the MAC method is probab= ly not the best way to handle multicast destinations and should be handled = in a different way. > > Also, I happen to know that some people on their first reading of the dra= ft become confused about the use of MAC addresses as identifiers as well as= addresses, and think that as a side-effect of my proposal, this confusion = might disappear, but I don't consider this alone to be a reason to change t= he draft. So the normal output would have a single MAC address as an attribute? Or maybe multiple MAC addresses? And the "L3 DLEP" you suggested would have IP addresses but no MAC addresses as attributes? ----------------- I wonder if we should keep this for a DLEP-07 draft... we did a lot of work for the -06 draft, getting it out would be a real help. Henning Rogge From nobody Sun Jul 27 08:55:09 2014 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 D32121A0648 for ; Sun, 27 Jul 2014 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 cG5QOBcHwMp4 for ; Sun, 27 Jul 2014 08:55:06 -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 A43AB1A059F for ; Sun, 27 Jul 2014 08:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7367; q=dns/txt; s=iport; t=1406476507; x=1407686107; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8hCACeBJ8D/rGNne1bhFohJn0028z+5zLd19I7XzjBs=; b=hprnIitH2qWa1D6rVdfyA97Q8jJT8dED6nZxQinO4s6v8OGsndvQHdRM +chE0X2j48Nyxgy0lxUN2IvdRgYrG53cHerLLc/Y1lUjIeUhFIL+u+F20 gw1gNzPe1io1R0TEZCtWb0nADJ91j1AisFiLcMdzjCQWmxARNzbFWJ+fo g=; X-IronPort-AV: E=Sophos;i="5.01,742,1400025600"; d="scan'208";a="64395783" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 27 Jul 2014 15:55:06 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6RFt4Nj028305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2014 15:55:04 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6RFssVs030601; Sun, 27 Jul 2014 08:54:54 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6RFsp5g030600; Sun, 27 Jul 2014 08:54:51 -0700 Date: Sun, 27 Jul 2014 08:54:51 -0700 From: Toerless Eckert To: Rick Taylor Message-ID: <20140727155451.GA29102@cisco.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> <20140726163257.GA28917@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/M37eUr4pg1el5eOt10qKB63EdcQ Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 15:55:09 -0000 On Sun, Jul 27, 2014 at 02:26:37PM +0000, Rick Taylor wrote: > > b) There are not only 48, but also 64-bit MAC addresses. > No idea when/if they would ever be applicable to DLEP, just saying. > > Indeed, but given the TLV includes an explicit length field, I think it just works. draft says explicitly length=6. Might be worth saying length= what the length of AC is (currently 6 or 8 are known). > > 1) Having a destination identifier separate from DMAC would of > course allow to have destinations change their DMAC. If that is > useful, i don't know. If we do know a use case and we do this > protocol change, then it would be great to mentoin that use-case. > > I don't have a specific use-case for this, but it would allow routers to change MAC during the lifetime of a session. I don't know a "simple" example of router changing MAC address But one case i forgot to mention is that a router might have more than one MAC address. The classical case is HSRP/VRRP where there is an additional virtual MAC and IP address. Probably worth to discuss in a separate thread or even draft extension to DLEP if this is of interest, otherwise this thread becomes too long. > How the TCP session stays up during a MAC change is beyond my ken however... TCP should only care about IP addresses, but it might indeed be a challenge if the network stack on router/modem are "challenged". > > 2) Having a destination identifier separate from DMAC would allow > for destinations to NOT have a DMAC, eg: making DMAC optional. > I do not know if you intend to support this: > > This I can see being useful for 3 cases: > a) L3 only modems (out of scope here). > b) Broad/Any/Multi-cast. True. MAC address in multicast destination has no good purpose if IP is present. > c) 1 modem talking DLEP to multiple routers (1 destination, N router MACs) Don't understand that case. DLEP session is TCP, can only go to one router. > > 2.1) for a "normal" destination (router/host), i can not see how > this would work. Without MAC nor IP, a router could IMHO not > make heads or tail out of such a destination. > > Correct, there must be at least 1 address, L2 or L3. If we really make DMAC optional for the "normal" case where there is L2 multicast support on the radio (ARP exists), then that is indeed true. But i am worried that we very well spec in DLEP what we expect routers and modems to support: I don't want that router from Vendor A think they only need to announce IP address in this "normal" case, and routers from Vendor B think that they only need to announce DMAC. And they're then surprised to see destinations that do it differently. And the modems might be confused either. The way it stands right now, that the DMAC is mandatory in the "normal" case and IP optional on top of it is certainly a lot easier guaranteeing interop. > > 2.2) for a special "default destination" which i think is what Bryan > would like to see for sat spoke modems, this would work. The > "default destination" does not need MAC or IP identification. It > needs to have a pre-defined, unique identifier though so that a > DLEP router recognizes it and appropriately deals with it. > > I'm not keen on a 'magic number' to mean default destination. I would rather have a TLV that means "This is the default link for layer2 traffic". DLEP TLV's are the best way to communicate properties of a destination, rather than encoding the properties into the identifier itself. This is the reason for my change of heart with Brian's proposal. Ok, thats fine. So the draft text to explain the identifier would then say something like the following to explain the identifier: The identifier solely exists to unique identify a particular destination, there is no other semantic attached to the identifier. Using such an identifier permits that no other TLV of a destination is mandatory because it would need to double-serve as an identifier for the destination. Every other TLV can therefore also potentially change during the livetime of the destination. Whether or not specific TLVs are optional and/or permitted to change is subject to other sections of this document. > > 2.3) Another special destination could be a destination that > really only says "network DOES/DOES-NOT support L2 multicast". > That somehow is missing. > > Hmmm, the ability to have a 'Multicast accessibility TLV' alongside an Address TLV would fit with this identifier model. But the specifics of multicast are better discussed in another thread I think. Right. Just trying to find justifications for a separate identifier that are not just "document nicety". Aka: "default destination", "multicast capability destination" could be destinations without either IP nor MAC TLV but with other TLVs indicating their purpose. This could be IMHO sufficient functional justification for an identifier, even if for "normal" destinations we figure out that we should always signal a MAC to make interop easier (see above). > > If a (radio) network does NOT support L2 multicast, > then all modems need to announce "normal" destinations with > both MAC and IP address, so that routers can use DLEP to replace ARP, > and routers would need to replicate IP multicast as replicated > ethernet unicast across the (radio) network. > > Absolutely, if there is no L2 broadcast capability in the modem, there MUST be an address provided for a destination. In fact DLEP is harsher, and currently forces that there MUST be an L2 address for a destination whether broadcast is an option or not (again this ties in with Brian's problem). > > > If the radio network DOES support L2 multicast, then MAC addresses > formal destinations are IMHO still mandatory, but IP addresses > are optional. If supported by the DLEP modems, they can help to > optimize the RTTs of ARP away and save RF bandwidth. > > Yes, that's stock DLEP as it currently stands. Without address information, there is no way for a router to match the flow of packets to/from a destination to the link over which the packets will travel. > > > 2.3) If the concept of destination is meant to be used to indicate > individual multicast groups, that warrants a longer discussion, let > me put this into another mail thread. > > I would like the concept of destination to have a single consistent meaning for uni/broad/any/multi-cast. Originally Stan was calling them Neighbours, Radio guys often call them Links, but Destinations is a better name: It's the grouping for a set of 1 or more remote addresses and metrics for the path to them, 1 in the unicast case, N in the multicast case. (Flows are to be addressed in a later draft, don't go there!) Yes, destinations make sense. So far "special" cases like "default" and multicast "group/channel" nicely fit under the umbrella of what people would call a "destination". Lets hope we don't find another use case where "destination" is not a good word ;-)) > Thanks for your constructive feedback, Sure. Cheers Toerless > Rick > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From nobody Sun Jul 27 10:53:44 2014 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 CAA8B1A0AE5 for ; Sun, 27 Jul 2014 10:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 b0H71Rn8EONy for ; Sun, 27 Jul 2014 10:53:42 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [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 361821A0AD7 for ; Sun, 27 Jul 2014 10:53:42 -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; Sun, 27 Jul 2014 18:53:00 +0100 From: Rick Taylor To: Henning Rogge Thread-Topic: [manet] DLEP proposal Thread-Index: AQHPqO9CBLm7Ds35Rki/xAnaEAWf0puz9QEAgAALEYD///knAIAAOxmA Date: Sun, 27 Jul 2014 17:52:59 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148DB960@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801148DB5AA@tss-server1.home.tropicalstormsoftware.com> <20140726163257.GA28917@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB88A@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DB8CD@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/__a3bmenfujZ9kMOKqr_gEa9stw Cc: "manet@ietf.org" Subject: Re: [manet] DLEP proposal 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: Sun, 27 Jul 2014 17:53:44 -0000 SGVubmluZywNCg0KWWVzLCB0aGUgY29tbW9uIGNhc2Ugd291bGQgYmUgYSBzaW5nbGUgTUFDL0wy IGFkZHJlc3MgVExWIHBlciBkZXN0aW5hdGlvbiBhcyBiZWZvcmUsIGJ1dCBpdCBkb2VzIG9wZW4g dXAgdGhlIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIE1BQyBhZGRyZXNzZXMgKDIgcm91dGVyIHNl c3Npb25zIHdpdGggMSBtb2RlbSksIG9yIGp1c3QgTDMgdW5pY2FzdCBhZGRyZXNzIG9yIG11bHRp Y2FzdCBhZGRyZXNzZXMuDQoNCkFzIGZhciBhcyBhY2NlcHRpbmcgb3Igc2NoZWR1bGluZyBzdWNo IGEgY2hhbmdlLCB0aGUgZGVjaXNpb24gaXMgd2l0aCBTdGFuIGFuZCB0aGUgb3RoZXIgYXV0aG9y cywgYnV0IEkgZ2V0IHBvaW50IGFib3V0IHB1Ymxpc2hpbmcgRExFUC0wNiBiZWZvcmUgY3JhbW1p bmcgaW4gbmV3IHN0dWZmLg0KDQpSaWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBIZW5uaW5nIFJvZ2dlIFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0gDQpTZW50OiAyNyBK dWx5IDIwMTQgMTY6MTgNClRvOiBSaWNrIFRheWxvcg0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW21hbmV0XSBETEVQIHByb3Bvc2FsDQoNCk9uIFN1biwgSnVsIDI3LCAyMDE0IGF0 IDQ6NTYgUE0sIFJpY2sgVGF5bG9yIDxyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb20+IHdy b3RlOg0KPiBBcyBJIGNvbnRpbnVlIG15IGZpZ2h0IHdpdGggamV0bGFnLCBJIHNoYWxsIHN1bW1h cml6ZSBteSBwcm9wb3NhbCwgaG9waW5nIGl0IGlzIGNsZWFyZXIuDQo+DQo+IEFsbCBJJ20gc3Vn Z2VzdGluZyBpcyBub3QgdXNpbmcgdGhlIHJlbW90ZSBETEVQIHJvdXRlciBwZWVyJ3MgTUFDIGFk ZHJlc3MgYXMgdGhlIHByaW1hcnkga2V5IG9mIHRoZSBkZXN0aW5hdGlvbiwgYnV0IG1ha2luZyBp dCBhIHByb3BlcnR5IG9mIHRoZSBkZXN0aW5hdGlvbiwgYW5kIGp1c3QgdXNpbmcgYSBsb2NhbGx5 IGdlbmVyYXRlZCBudW1iZXIgYXMgdGhlIHByaW1hcnkga2V5LiAgSXQncyBnZW5lcmFsbHkgdmll d2VkIGFzIGdvb2QgcHJhY3RpY2UgaW4gdGhlIGRhdGFiYXNlIHdvcmxkIHRvIGRvIHRoaXMga2lu ZCBvZiBub3JtYWxpemF0aW9uLCBhbmQgSSdtIHByb3Bvc2luZyB0aGF0IHdlIGRvIHRoZSBzYW1l IHdpdGggRExFUC4NCj4NCj4gVGhlIG1vc3Qgb2J2aW91cyBjb21wbGljYXRpb24gd2l0aCB0aGlz IHByb3Bvc2FsIGlzIGN1cnJlbnRseSBETEVQIHN1Z2dlc3RzIHRoYXQgcm91dGVycyByZXF1ZXN0 IG1ldHJpY3MgZm9yIG11bHRpY2FzdCBkZXN0aW5hdGlvbnMgYnkgc2VuZGluZyBhIE5laWdoYm91 cl9VcCBzaWduYWwgdG8gdGhlIGxvY2FsIG1vZGVtIHVzaW5nIHRoZSBNQUMgYWRkcmVzcyBvZiB0 aGUgbXVsdGljYXN0IGdyb3VwIHRoZXkgYXJlIGludGVyZXN0ZWQgaW4uICBDb250aW51aW5nIHRv IHVzZSB0aGlzIG1ldGhvZCB3b3VsZCByZXF1aXJlIGJvdGggcm91dGVyIGFuZCBtb2RlbSB0byBh Z3JlZSBhIG1lY2hhbmlzbSB0byBnZW5lcmF0ZSBjb25zaXN0ZW50IGRlc3RpbmF0aW9uIGlkZW50 aWZpZXJzLiAgSG93ZXZlciwgSSBhbSBvZiB0aGUgb3BpbmlvbiB0aGF0IHRoZSBNQUMgbWV0aG9k IGlzIHByb2JhYmx5IG5vdCB0aGUgYmVzdCB3YXkgdG8gaGFuZGxlIG11bHRpY2FzdCBkZXN0aW5h dGlvbnMgYW5kIHNob3VsZCBiZSBoYW5kbGVkIGluIGEgZGlmZmVyZW50IHdheS4NCj4NCj4gQWxz bywgSSBoYXBwZW4gdG8ga25vdyB0aGF0IHNvbWUgcGVvcGxlIG9uIHRoZWlyIGZpcnN0IHJlYWRp bmcgb2YgdGhlIGRyYWZ0IGJlY29tZSBjb25mdXNlZCBhYm91dCB0aGUgdXNlIG9mIE1BQyBhZGRy ZXNzZXMgYXMgaWRlbnRpZmllcnMgYXMgd2VsbCBhcyBhZGRyZXNzZXMsIGFuZCB0aGluayB0aGF0 IGFzIGEgc2lkZS1lZmZlY3Qgb2YgbXkgcHJvcG9zYWwsIHRoaXMgY29uZnVzaW9uIG1pZ2h0IGRp c2FwcGVhciwgYnV0IEkgZG9uJ3QgY29uc2lkZXIgdGhpcyBhbG9uZSB0byBiZSBhIHJlYXNvbiB0 byBjaGFuZ2UgdGhlIGRyYWZ0Lg0KDQpTbyB0aGUgbm9ybWFsIG91dHB1dCB3b3VsZCBoYXZlIGEg c2luZ2xlIE1BQyBhZGRyZXNzIGFzIGFuIGF0dHJpYnV0ZT8NCk9yIG1heWJlIG11bHRpcGxlIE1B QyBhZGRyZXNzZXM/DQoNCkFuZCB0aGUgIkwzIERMRVAiIHlvdSBzdWdnZXN0ZWQgd291bGQgaGF2 ZSBJUCBhZGRyZXNzZXMgYnV0IG5vIE1BQyBhZGRyZXNzZXMgYXMgYXR0cmlidXRlcz8NCg0KLS0t LS0tLS0tLS0tLS0tLS0NCg0KSSB3b25kZXIgaWYgd2Ugc2hvdWxkIGtlZXAgdGhpcyBmb3IgYSBE TEVQLTA3IGRyYWZ0Li4uIHdlIGRpZCBhIGxvdCBvZiB3b3JrIGZvciB0aGUgLTA2IGRyYWZ0LCBn ZXR0aW5nIGl0IG91dCB3b3VsZCBiZSBhIHJlYWwgaGVscC4NCg0KSGVubmluZyBSb2dnZQ0K From nobody Mon Jul 28 00:18:11 2014 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 87D0A1A0292 for ; Mon, 28 Jul 2014 00:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 RvXVcCM2PAVE for ; Mon, 28 Jul 2014 00:18:05 -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 903EA1A02DA for ; Mon, 28 Jul 2014 00:17:52 -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 1XBfBv-0004I6-8M for manet@ietf.org; Mon, 28 Jul 2014 09:17:51 +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 1XBfBv-0004sS-4Z for manet@ietf.org; Mon, 28 Jul 2014 09:17:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 28 Jul 2014 09:17:50 +0200 Message-ID: <53D5F918.5090804@fkie.fraunhofer.de> Date: Mon, 28 Jul 2014 09:17:44 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> In-Reply-To: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070104050208060702000000" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19233/Mon Jul 28 02:13:34 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8318846d41f6f18a0ab4cdd00a4712ab Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2R8T01MFAJY9Nl1ivlH4Bzs_VhI Subject: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.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: Mon, 28 Jul 2014 07:18:07 -0000 --------------ms070104050208060702000000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the first revision of my "NHDP dualstack optimization" draft to the IETF. Looking forward to your comments. Henning Rogge -------- Forwarded Message -------- Subject: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.txt Date: Mon, 28 Jul 2014 00:15:22 -0700 From: internet-drafts@ietf.org To: Henning Rogge , Henning Rogge A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.tx= t has been successfully submitted by Henning Rogge and posted to the IETF repository. Name: draft-rogge-manet-nhdp-dualstack-optimization Revision: 00 Title: Optimized flooding for NHDP Dual Stack routers Document date: 2014-07-28 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-rogge-manet-nhdp-dualstack-opti= mization-00.txt Status: https://datatracker.ietf.org/doc/draft-rogge-manet-nhdp-dualstack-optimiz= ation/ Htmlized: http://tools.ietf.org/html/draft-rogge-manet-nhdp-dualstack-optimization-= 00 Abstract: This document specifies an optimization for the flooding of RFC5444 control traffic with NHDP. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070104050208060702000000 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 Fw0xNDA3MjgwNzE3NDlaMCMGCSqGSIb3DQEJBDEWBBTorJppUJqOtk8c44UV2BoU6DJuvzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwc+7mWULaHqLZldKex56WnzqwTL9Lzoe9qXWeAuA/+w/ V/Sr83gH/vzvWEyx926B86nOiT54NmoAfpKOBS9sHHrqRN+tu6uj86WdXajUmNKspehU2o6y knnJfIyrGPj6tNs83Zg7KOv1Httdn7FDbDd7ytb8FwdIqs7vfl3fivKMUuvQwAYyHL/GIU+P TnraK0C1o0F5WxRsBHmhfCVRqg1iPxifijr8uWnAqiUDBZeX4qCPJpL1L2vmJCaOMsL2F1rt IcgdkmFr5wa6kaH2CIxK4ZTTnKf6HlgIPde3QYEBeSpu2BjZJJm6w6a2rzgPDfo43NrX6brT oRnhpfMMFgAAAAAAAA== --------------ms070104050208060702000000-- From nobody Mon Jul 28 02:10:17 2014 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 270A61A033C for ; Mon, 28 Jul 2014 02:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 SBiiIj-M3ign for ; Mon, 28 Jul 2014 02:10:11 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6AD1A031F for ; Mon, 28 Jul 2014 02:10:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,747,1400022000"; d="scan'208";a="461435047" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 28 Jul 2014 10:10:08 +0100 X-IronPort-AV: E=Sophos;i="5.01,747,1400022000"; d="scan'208";a="59204673" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 28 Jul 2014 10:10:17 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.175]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Mon, 28 Jul 2014 10:10:17 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.txt Thread-Index: AQHPqjQrN7kTgCtzmUCC7urGmb9+ppu1L9VA Date: Mon, 28 Jul 2014 09:10:17 +0000 Message-ID: References: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> <53D5F918.5090804@fkie.fraunhofer.de> In-Reply-To: <53D5F918.5090804@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/q33rU5L1JbYAg5uBg35TYMYoGMI Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.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: Mon, 28 Jul 2014 09:10:16 -0000 SSBhZG1pdCB0byBub3QgaGF2aW5nIHJlYWQgZXZlcnkgZGV0YWlsLCBidXQgSSBmaW5kIHRoaXMg cXVpdGUgdW5kZXJzcGVjaWZpZWQgaW4gdGVybXMgb2YgaG93IHRoZSBkdWFsIHN0YWNrIGlzIG9y Z2FuaXNlZCB3aGVuIGl0IGlzIGRlc2NyaWJlZCBhcyBhIGNvbWJpbmVkIGltcGxlbWVudGF0aW9u LCBub3QgdHdvIHNlcGFyYXRlIGltcGxlbWVudGF0aW9ucy4gV2hhdCBpcyBkaWZmZXJlbnQgdG8g cnVubmluZyBhbiBJUHY0IGFuZCBhbiBJUHY2IGltcGxlbWVudGF0aW9uLCB3aXRoIGEgc21hbGwg Y2hhbmdlIHRvIHRoZSBsYXR0ZXIgKGp1c3QgdGhlIGxhdHRlcj8pLiBUaGVyZSBhcmUgbG90cyBv ZiBxdWVzdGlvbnMsIHN1Y2ggYXMgaWYgd2Ugc2hvdWxkIGF0dGVtcHQgdG8gdXNlIHRoZSBzYW1l IG1lc3NhZ2Ugc2NoZWR1bGVzICh0aGF0J3MganVzdCBhbiBleGFtcGxlKS4NCg0KSSBhbHNvIHdv dWxkIGxpa2UgdG8ga25vdyBhYm91dCBpbnRlcm9wZXJhYmlsaXR5IHdpdGggbm9uLWR1YWwtc3Rh Y2sgaW1wbGVtZW50YXRpb25zLiBBbmQgbGF0ZXIgYWJvdXQgd2hhdCBoYXBwZW5zIHdpdGggT0xT UnYyLiAoSSB3b3VsZG4ndCBiZSBoYXBweSB3aXRoIGEgZHVhbCBzdGFjayBOSERQIHVubGVzcyBJ IGtuZXcgd2hhdCBoYXBwZW5lZCB3aXRoIE9MU1JWMiBhbHNvLikNCg0KQXQgdGhlIGRldGFpbCBs ZXZlbCwgdGhpcyBzZWVtcyB0byBhc3N1bWUgY29tcHVsc29yeSBvcmlnaW5hdG9yIGFkZHJlc3Nl cy4gQnV0IHRoZXkgYXJlIG5vdCBjb21wdWxzb3J5IGluIHN0YW5kYXJkIE5IRFAgLSBvbmx5IHdo ZW4gdXNlZCB3aXRoIE9MU1J2Mi4NCg0KKEkgYWxzbyB3YW50IHRvIHJlbmFtZSB0aGUgTF8gZWxl bWVudCwgYnV0IGxldCdzIGFkZHJlc3MgdGhlIGJpZyBwaWN0dXJlIGl0ZW1zLikNCg0KLS0gDQpD aHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRp b24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFu YWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJl DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4 SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NMKgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0K DQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdh cndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFy bmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdh bGVzIE5vOiAxOTk2Njg3DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1h bmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbm5pbmcg Um9nZ2UNClNlbnQ6IDI4IEp1bHkgMjAxNCAwODoxOA0KVG86IG1hbmV0QGlldGYub3JnDQpTdWJq ZWN0OiBbbWFuZXRdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yb2dn ZS1tYW5ldC1uaGRwLWR1YWxzdGFjay1vcHRpbWl6YXRpb24tMDAudHh0DQoNCkhpLA0KDQpJIGhh dmUgdXBsb2FkZWQgdGhlIGZpcnN0IHJldmlzaW9uIG9mIG15ICJOSERQIGR1YWxzdGFjayBvcHRp bWl6YXRpb24iDQpkcmFmdCB0byB0aGUgSUVURi4NCg0KTG9va2luZyBmb3J3YXJkIHRvIHlvdXIg Y29tbWVudHMuDQoNCkhlbm5pbmcgUm9nZ2UNCg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2Fn ZSAtLS0tLS0tLQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQt cm9nZ2UtbWFuZXQtbmhkcC1kdWFsc3RhY2stb3B0aW1pemF0aW9uLTAwLnR4dA0KRGF0ZTogTW9u LCAyOCBKdWwgMjAxNCAwMDoxNToyMiAtMDcwMA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnDQpUbzogSGVubmluZyBSb2dnZSA8aGVubmluZy5yb2dnZUBma2llLmZyYXVuaG9mZXIuZGU+ LCBIZW5uaW5nIFJvZ2dlIDxoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZT4NCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9nZ2UtbWFuZXQtbmhkcC1kdWFsc3RhY2stb3B0 aW1pemF0aW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIZW5u aW5nIFJvZ2dlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LXJvZ2dlLW1hbmV0LW5oZHAtZHVhbHN0YWNrLW9wdGltaXphdGlvbg0KUmV2aXNpb246CTAw DQpUaXRsZToJCU9wdGltaXplZCBmbG9vZGluZyBmb3IgTkhEUCBEdWFsIFN0YWNrIHJvdXRlcnMN CkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMjgNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTgNClVSTDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXJvZ2dlLW1hbmV0LW5oZHAtZHVhbHN0YWNrLW9wdGltaXphdGlvbi0wMC50eHQNClN0YXR1 czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJvZ2dlLW1hbmV0LW5o ZHAtZHVhbHN0YWNrLW9wdGltaXphdGlvbi8NCkh0bWxpemVkOg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcm9nZ2UtbWFuZXQtbmhkcC1kdWFsc3RhY2stb3B0aW1pemF0aW9uLTAw DQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbiBvcHRpbWl6YXRp b24gZm9yIHRoZSBmbG9vZGluZyBvZiBSRkM1NDQ0DQogICBjb250cm9sIHRyYWZmaWMgd2l0aCBO SERQLg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQotLQ0KRGlwbG9tLUluZm9ybWF0aWtlciBIZW5uaW5nIFJvZ2dl ICwgRnJhdW5ob2Zlci1JbnN0aXR1dCBmw7xyIEtvbW11bmlrYXRpb24sIEluZm9ybWF0aW9uc3Zl cmFyYmVpdHVuZyB1bmQgRXJnb25vbWllIEZLSUUgS29tbXVuaWthdGlvbnNzeXN0ZW1lIChLT00p IEZyYXVuaG9mZXIgU3RyYcOfZSAyMCwgNTMzNDMgV2FjaHRiZXJnLCBHZXJtYW55DQpUZWxlZm9u ICs0OSAyMjggOTQzNS05NjEsICAgRmF4ICs0OSAyMjggOTQzNSA2ODUNCm1haWx0bzpoZW5uaW5n LnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZSBodHRwOi8vd3d3LmZraWUuZnJhdW5ob2Zlci5kZQ0K DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRl IGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5v dCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3Ry aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Mon Jul 28 03:16:16 2014 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 07A0B1A0385 for ; Mon, 28 Jul 2014 03:16:14 -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 UaXZlo2ssxSg for ; Mon, 28 Jul 2014 03:16:12 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D94C1A036C for ; Mon, 28 Jul 2014 03:16:12 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 142so4549877ykq.38 for ; Mon, 28 Jul 2014 03:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qqgSzt/wT81FOvdUKngKIY/k8Wa9ajmr52ITImGWrBk=; b=bKQkpLAfBxfVyZbSR5dP/IQyHOZnRGh9I7C8qr+6xchXuvHgyJ+k1C2JeqQdOSiPfN vFJ94QsJK8peNzQa5KbzDZ4ahE4LtP7NFfcd7mpT431eEuBEpD5loPm7waCm2zlXM3d4 lqts2ryx/MwCwH3v62BXrgoeMz+DCSG2WNNZfAITCiJG3Od9d5cA0uM/iSdLqRh2KdI4 Gy1kyEZ1G0yVsF/NJEUNqajv8995oQcXOXADrBS/ffXmLusI7jiVYmTOPiMHGBiN6Z21 ma9j4eVuHK6zGqfHQH0GbfOwmazZFlmcUGLitjTJqEtOIpn1Hq6y70rVlOoK15q+yKBE FZCg== MIME-Version: 1.0 X-Received: by 10.236.10.66 with SMTP id 42mr49801228yhu.68.1406542571377; Mon, 28 Jul 2014 03:16:11 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Mon, 28 Jul 2014 03:16:11 -0700 (PDT) In-Reply-To: <53D5F918.5090804@fkie.fraunhofer.de> References: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> <53D5F918.5090804@fkie.fraunhofer.de> Date: Mon, 28 Jul 2014 12:16:11 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a1136b28c5419a404ff3e3638 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7xMqElh8BmhtXNuOdqi4B0ehbEw Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.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: Mon, 28 Jul 2014 10:16:14 -0000 --001a1136b28c5419a404ff3e3638 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I did not misunderstood I think the draft does not follow RFC5498 which I think makes it flexible and benefits from UDP packets advantages. Also specifies that RFC5444 messages are allowed to not need to have an RFC5444 packet (I remember discussing this before and some refused the idea) just UDP packets which is another advantage. Please reply if I misunderstood. AB On Monday, July 28, 2014, Henning Rogge wrote: > Hi, > > I have uploaded the first revision of my "NHDP dualstack optimization" > draft to the IETF. > > Looking forward to your comments. > > Henning Rogge > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-rogge-manet-nhdp-dualstack-optimization-00.txt > Date: Mon, 28 Jul 2014 00:15:22 -0700 > From: internet-drafts@ietf.org > To: Henning Rogge >, > Henning Rogge > > > > > A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.tx= t > has been successfully submitted by Henning Rogge and posted to the > IETF repository. > > Name: draft-rogge-manet-nhdp-dualstack-optimization > Revision: 00 > Title: Optimized flooding for NHDP Dual Stack routers > Document date: 2014-07-28 > Group: Individual Submission > Pages: 8 > URL: > > http://www.ietf.org/internet-drafts/draft-rogge-manet-nhdp-dualstack-opti= mization-00.txt > Status: > > https://datatracker.ietf.org/doc/draft-rogge-manet-nhdp-dualstack-optimiz= ation/ > Htmlized: > http://tools.ietf.org/html/draft-rogge-manet-nhdp-dualstack-optimization-= 00 > > > Abstract: > This document specifies an optimization for the flooding of RFC5444 > control traffic with NHDP. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de > http://www.fkie.fraunhofer.de > > > > --001a1136b28c5419a404ff3e3638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I did not misunderstood I think the=C2=A0draft does not follow RFC5498 w= hich I think=C2=A0makes it flexible and benefits from UDP packets advantage= s. Also specifies that=C2=A0RFC5444 messages are allowed to=C2=A0not need t= o have an=C2=A0RFC5444 packet (I remember discussing this before and some r= efused the idea)=C2=A0just UDP packets which is another advantage. Please r= eply if I misunderstood.=C2=A0

AB

On Monday, July 28, 2014, Henning Rogge wrote:
Hi,

I have uploaded the first revision of my "NHDP dualstack optimization&= quot;
draft to the IETF.

Looking forward to your comments.

Henning Rogge


-------- Forwarded Message --------
Subject: New Version Notification for
draft-rogge-manet-nhdp-dualstack-optimization-00.txt
Date: Mon, 28 Jul 2014 00:15:22 -0700
From: internet-drafts@ietf.org
To: Henning Rogge <henning.rogge@fkie.fr= aunhofer.de>, Henning Rogge
<henning.rogge@fkie.fraunhofer.de>= ;


A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.txt<= br> has been successfully submitted by Henning Rogge and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-rogge-manet-nhdp-dualstack-o= ptimization
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optimized flooding for NHDP Dual S= tack routers
Document date: =C2=A02014-07-28
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08
URL:
http://www.ietf.org/internet-dr= afts/draft-rogge-manet-nhdp-dualstack-optimization-00.txt
Status:
https://datatracker.ietf.org/doc/draft-r= ogge-manet-nhdp-dualstack-optimization/
Htmlized:
http://tools.ietf.org/html/draft-rogge-manet= -nhdp-dualstack-optimization-00


Abstract:
=C2=A0 =C2=A0This document specifies an optimization for the flooding of RF= C5444
=C2=A0 =C2=A0control traffic with NHDP.





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

The IETF Secretariat


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



--001a1136b28c5419a404ff3e3638-- From nobody Mon Jul 28 03:16:45 2014 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 A1ED61A036C for ; Mon, 28 Jul 2014 03:16:34 -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 28o2IahIDCb4 for ; Mon, 28 Jul 2014 03:16:30 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E721A03A1 for ; Mon, 28 Jul 2014 03:16:19 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so4724339yha.14 for ; Mon, 28 Jul 2014 03:16:18 -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=zpklZgAuPv/NHmwJEulSeXb7y6+cT8oV2/cCJTBxqhk=; b=U8KdIHPzrYRvRjeCusSHgm52C2+060D+sNBIb+qAlKzVbS9dkpIesfHHWS1dIB2yFK hWBBBGYftoCgf9Ji1i8NBskk5rAzAYKV1eAyWKIEPEv4d/a6xH48XXQkkK7vhUdULcPj YYJFSZZdLZIoUXSQv6R5B49fY/UHTfynGHYAkqteavuSdSadK0Y8j6sfP/+oO466YxlF GXy4Wl3iVpxszmOIkP5Tew8E2HmlAo32f6QAyuWtzviLFT5OrOA1rRauwPXHE0No0j+Z qA384m0FwH2BuyPRpqbNqlUERjhI2J+mtXhWUXmSe2wqKygczG+hzqn0gXoU2GJMp/p/ tc0Q== MIME-Version: 1.0 X-Received: by 10.236.32.227 with SMTP id o63mr49308339yha.31.1406542578430; Mon, 28 Jul 2014 03:16:18 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Mon, 28 Jul 2014 03:16:18 -0700 (PDT) In-Reply-To: <53D5F918.5090804@fkie.fraunhofer.de> References: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> <53D5F918.5090804@fkie.fraunhofer.de> Date: Mon, 28 Jul 2014 12:16:18 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0160b3b8bfba7404ff3e36e8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rpo7lPdW6SBg5UBmUVpikP3N7lg Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.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: Mon, 28 Jul 2014 10:16:34 -0000 --089e0160b3b8bfba7404ff3e36e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I did not misunderstood I think the draft does not follow RFC5498 which I think makes it flexible and benefits from UDP packets advantages. Also specifies that RFC5444 messages are allowed to not need to have an RFC5444 packet (I remember discussing this before and some refused the idea) just UDP packets which is another advantage. Please reply if I misunderstood. AB On Monday, July 28, 2014, Henning Rogge wrote: > Hi, > > I have uploaded the first revision of my "NHDP dualstack optimization" > draft to the IETF. > > Looking forward to your comments. > > Henning Rogge > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-rogge-manet-nhdp-dualstack-optimization-00.txt > Date: Mon, 28 Jul 2014 00:15:22 -0700 > From: internet-drafts@ietf.org > To: Henning Rogge , Henning Rogge > > > > A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.tx= t > has been successfully submitted by Henning Rogge and posted to the > IETF repository. > > Name: draft-rogge-manet-nhdp-dualstack-optimization > Revision: 00 > Title: Optimized flooding for NHDP Dual Stack routers > Document date: 2014-07-28 > Group: Individual Submission > Pages: 8 > URL: > > http://www.ietf.org/internet-drafts/draft-rogge-manet-nhdp-dualstack-opti= mization-00.txt > Status: > > https://datatracker.ietf.org/doc/draft-rogge-manet-nhdp-dualstack-optimiz= ation/ > Htmlized: > http://tools.ietf.org/html/draft-rogge-manet-nhdp-dualstack-optimization-= 00 > > > Abstract: > This document specifies an optimization for the flooding of RFC5444 > control traffic with NHDP. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > --089e0160b3b8bfba7404ff3e36e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I did not misunderstood I think the=C2=A0draft does not follow RFC5498 w= hich I think=C2=A0makes it flexible and benefits from UDP packets advantage= s. Also specifies that=C2=A0RFC5444 messages are allowed to=C2=A0not need t= o have an=C2=A0RFC5444 packet (I remember discussing this before and some r= efused the idea)=C2=A0just UDP packets which is another advantage. Please r= eply if I misunderstood.=C2=A0

AB

On Monday, July 28, 2014, Henning Rogge wrote:
Hi,

I have uploaded the first revision of my "NHDP dualstack optimization&= quot;
draft to the IETF.

Looking forward to your comments.

Henning Rogge


-------- Forwarded Message --------
Subject: New Version Notification for
draft-rogge-manet-nhdp-dualstack-optimization-00.txt
Date: Mon, 28 Jul 2014 00:15:22 -0700
From: internet-drafts@ietf.org
To: Henning Rogge <henning.rogge@fkie.fraunhofer.de>, Henning = Rogge
<henning.rogge@fkie.fraunhofer.de>


A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.txt<= br> has been successfully submitted by Henning Rogge and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-rogge-manet-nhdp-dualstack-o= ptimization
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optimized flooding for NHDP Dual S= tack routers
Document date: =C2=A02014-07-28
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08
URL:
http://www.ietf.org/internet-dr= afts/draft-rogge-manet-nhdp-dualstack-optimization-00.txt
Status:
https://datatracker.ietf.org/doc/draft-r= ogge-manet-nhdp-dualstack-optimization/
Htmlized:
http://tools.ietf.org/html/draft-rogge-manet= -nhdp-dualstack-optimization-00


Abstract:
=C2=A0 =C2=A0This document specifies an optimization for the flooding of RF= C5444
=C2=A0 =C2=A0control traffic with NHDP.





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

The IETF Secretariat


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



--089e0160b3b8bfba7404ff3e36e8-- From nobody Mon Jul 28 04:00:25 2014 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 336651A015B for ; Mon, 28 Jul 2014 04:00:23 -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 kg9UuZbbmuX4 for ; Mon, 28 Jul 2014 04:00:19 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEEA1A03F5 for ; Mon, 28 Jul 2014 04:00:19 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so8394544qgd.19 for ; Mon, 28 Jul 2014 04:00:18 -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=loo/a7BeI6Xre7J1YRPQJnzcg5idaNlh5GLtqw/zyYA=; b=mEVFMYlstYJqjK1+1f66VR3NyBBLZg/lM/IV38MefVSweysj2KnZxVv35c+9xgnwbX rjEJPep8gzPgZght7oaun/NFuiiA8oNYZ1ovO3R/x6DW/QAp9IQURQMhv8C/dM9KKka8 kcVTy0hCM81LMC2Qr213yyC657BfpH6X6lnV2SwooQ1wWGJZbOyRIjxW6X0T41eD2VYK F6uDfbj9MBdH4sn0U5NYz8VDseyLzYmqYjLSR6dNjeavO+urerMwJ2MuXphNB7d6sLHk ClJfZZwPdddjnGs92POTFl18QITR34O2Xt8pSFI5v3FEKZR8zTFI9ju8l3VPSsImUk+o mw0g== X-Received: by 10.140.94.197 with SMTP id g63mr2502866qge.90.1406545218537; Mon, 28 Jul 2014 04:00:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Mon, 28 Jul 2014 03:59:58 -0700 (PDT) In-Reply-To: References: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> <53D5F918.5090804@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 28 Jul 2014 12:59:58 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zrsgz3zebzMe0telspAEcQosamI Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.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: Mon, 28 Jul 2014 11:00:23 -0000 On Mon, Jul 28, 2014 at 11:10 AM, Dearlove, Christopher (UK) wrote: > I admit to not having read every detail, but I find this quite underspecified in terms of how the dual stack is organised when it is described as a combined implementation, not two separate implementations. You need a way to put IPv4 RFC5444 messages into IPv6 UDP/RFC5444 packets... and to parse this messages. You could do this with separate implementation and a pipe between them, but combining both instances makes it easier. > What is different to running an IPv4 and an IPv6 implementation, with a small change to the latter (just the latter?). Would not work, because the IPv4 implementation could not parse IPv6 RFC5444 messages incoming through IPv4 UDP packets (and a RFC5444 packet). > There are lots of questions, such as if we should attempt to use the same message schedules (that's just an example). Yes, this would (of course) help... > I also would like to know about interoperability with non-dual-stack implementations. And later about what happens with OLSRv2. (I wouldn't be happy with a dual stack NHDP unless I knew what happened with OLSRV2 also.) I tested my "dual stack" implementation with IPv4-only nodes, IPv6-only nodes and nodes that run both IPv4-only and IPv6-only routing instance. It should work with all of them because it downgrades to "IPv4 messages over IPv4 packet, IPv6 messages over IPv6 packets" in the presence of IPv4- or IPv6-only nodes. > At the detail level, this seems to assume compulsory originator addresses. But they are not compulsory in standard NHDP - only when used with OLSRv2. Yes. The requirements are NHDP plus an originator address. Doesn't need to be one defined by OLSRv2, but it needs this address. > (I also want to rename the L_ element, but let's address the big picture items.) no problem with this (both the renaming and doing it later). Henning Rogge From nobody Mon Jul 28 04:03:33 2014 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 6145A1A03D7 for ; Mon, 28 Jul 2014 04:03:31 -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 ZOjV9IHWUWt4 for ; Mon, 28 Jul 2014 04:03:30 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C663D1A03F7 for ; Mon, 28 Jul 2014 04:03:27 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so7486428qaq.15 for ; Mon, 28 Jul 2014 04:03:27 -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=/s3xLWxUboWL+TZEbElzcM4IntuTvx3S01sBbS/dAl8=; b=0SAtZmqyu+FnUh0QTF0SJ6ol6M2IzwQ4bMXcabrT6gKbtiGWve/pJJhaynqSGpLrgi Iyof+IInaaNDRim/8Eztyfc5FNnE1FtXBBbDnB8UDHtUQlqFjQ9KVjRXEZwQozMK3Xua 5p0CEuGmmrBBf5vKZSogSGYfbtyk2SCI2HfFxjhibfMOpEKFieQUHRz39tFz1MJ5hOGH R4EtobP1bzs+vAw5ro14NX3NY5xdPmbd18uOKpUU062IbscxHQ6V7XaaIct8gOf+TQE2 lexsRVW91JBvRDv15vgkDrnP2B2vnfNdlMFUROJ1Kr0S8V0n66ErIzYPgDNt5z2qRE5G ak3w== X-Received: by 10.140.94.197 with SMTP id g63mr2537399qge.90.1406545407070; Mon, 28 Jul 2014 04:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Mon, 28 Jul 2014 04:03:06 -0700 (PDT) In-Reply-To: References: <20140728071522.14544.48715.idtracker@ietfa.amsl.com> <53D5F918.5090804@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 28 Jul 2014 13:03:06 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W4rrJiiaNFnE9BgfNkZuRp2irIs Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.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: Mon, 28 Jul 2014 11:03:31 -0000 On Mon, Jul 28, 2014 at 12:16 PM, Abdussalam Baryun wrote: > If I did not misunderstood You did (misunderstood) > I think the draft does not follow RFC5498 which I > think makes it flexible and benefits from UDP packets advantages. No, it does follow RFC5498. RFC5498 does not mandate to put only address length 4 RFC5444 messages into RFC5444 packets that are in IPv4 UDP packets. > Also > specifies that RFC5444 messages are allowed to not need to have an RFC5444 > packet (I remember discussing this before and some refused the idea) just > UDP packets which is another advantage. Please reply if I misunderstood. The problem is that the phrase "IPv4 RFC5444 packet" doesn't make much sense, because the RFC5444 packet header is not address family aware. Maybe I should add two definitions "IPv4/6 RFC5444 packet" to the draft that mean IPv4/6 UDP packet with RFC5444 packet inside. Henning Rogge From nobody Mon Jul 28 06:19:15 2014 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 0F27E1B27F5 for ; Mon, 28 Jul 2014 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 B8dgSH8lbXlm for ; Mon, 28 Jul 2014 06:19:08 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDB91ABC10 for ; Mon, 28 Jul 2014 06:19:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 9CA04D40172; Mon, 28 Jul 2014 06:19:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 5F75AD4015E; Mon, 28 Jul 2014 06:19:03 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_366DA933-603C-42E5-A073-E5A1C7C2100F" Date: Mon, 28 Jul 2014 15:19:00 +0200 Message-Id: To: manet , "" , manet-ads Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IUvvSIs7IOVJ_kVHw1juTAOhA2s Cc: Christopher Dearlove Subject: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 28 Jul 2014 13:19:11 -0000 --Apple-Mail=_366DA933-603C-42E5-A073-E5A1C7C2100F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear WG Chairs,=20 Dear Chris, all, As the author indicated by email recently, he believes that = draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC.=20 As a reminder, this document aims for publication as a Proposed = Standard. I have, therefore, reviewed the document carefully. In my opinion, the = author is right =97 in my opinion this document is ready for WGLC. Moreover, I believe that it is a highly important document for the WG to = produce, as it fills a real need, and does so by relying on = already-published crypto RFCs, rather than by coming up with something = esoteric. I have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that should be = blocking. One of the issues is =93need a non-jetlagged ADs advice to be sure we do = the right thing=94, the other is =97 I think =97 a minor mix-up with a = trivial editorial resolution and zero technical impact on this = specification. Either way, for information, I include all issues and nits that I=92ve = found in the below. Issues: o In my opinion, =93Updates 7182=94 is inappropriate. What = this document does is: (i) only things permissible by RFC7182, and=20= (ii) makes registration from IANA registries = set up by RFC7182 (noting, of course, that RFC7181 doesn=92t= =93Updates 5444=94=20 when making registrations for TC = messages from the repositories=20 set up by RFC5444 as a case of = precedent) Consequently, I believe that the abstract, introduction, = and document=20 header, needs updates to reflect that this is not an = update. =09 Caveat Lector: I have bounced this around with the = author, and I=20 think that the conclusion is that we = need just a friendly=20 ADs opinion =97 my understanding is that = the author =93wants this out, but wants it done = right, also=94, something to which I can but adhere. =09 I believe that we should WGLC the = document. If the AD finds the time to address this issue = during WGLC, great - otherwise, we can reflect this in the = =93Document Writeup=94 that the AD will consider with the = publication request =97 as this (imo) is procedural/editorial, and = certainly not technical. o Introduction, 4th paragraph: Isn=92t it RFC7183 which does shared-secret-key ICVs? I = just did a quick grep through of =93shared=94 in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that case. = And =93secret=94 is not mentioned anywhere in 7182 Nits: o Introduction, 1st paragraph: OLD: This specification extends the TLV definitions therein by defining two new cryptographic = function code points that allow the use of an identity-based signature = (IBS) as an ICV. NEW: This specification defines two new cryptographic = function=20 code points from within the registries set up by = [RFC7182],=20 that allow the use of an identity-based = signature (IBS) as an ICV. o Introduction, 2nd paragraph, 1st line: I took a double-take when I saw the parenthesis=20 =93(protocol participant)=94 =97 that seems a little = odd, and I am on a crusade against redundant and hard-to-parse terminology ;) I think that what is meant is =93router, which is = running a routing=20 protocol which is based on RFC5444=94, so could the = document not say that? In any event, I do not see =93protocol participant=94 = defined or anywhere else, and so it seems unfortunate to *not* be explicit here. o Introduction, 3rd paragraph: OLD: Two options for the choice of identity are = supported (the two code points allocated). NEW: Two options for the choice of identity are = supported (as reflected by the two code points allocated). o Introduction, 7th paragraph: Caveating that using this introduces the danger that =93if= you catch the=20 trusted authority, then you=92re screwed=94 is awesome. = I see that=20 this is repeated and reworded in the Security = Considerations section, and I approve.=20 Now, my question is then, if this should not be stated = in the Applicability=20 statement, also? Something to the effect of that this = applies to networks where all routers can (at some point) be in contact with = the TA (to be keyed), but that this can be off-line =97 and probably = should be off-line since the TA really, really should be protected. It might be argued that the forward-reference to Section = 6 captures this =97 I still think, that a few choice words in the = applicability statement would help greatly. o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to = quantify the=20 computational load? I asked a crypto-wonk-colleague, who = said something to the effect of =93the document is perfectly = right, on this point, but I do not have a paper just off the top of my = head with=20 interesting data to offer=94. For that reason alone, = it=92d be interesting=20 if you did ;) o Throw-away comment, I appreciate particularly the last paragraph of the introduction. o Section 4.1, first bullet OLD: o The ICV is not calculated as = cryptographic-function(hash- function(content)) as defined in [RFC7182], but = (like the HMAC ICVs defined there) uses the hash function within = the cryptographic function. The option "none" is not = permitted for hash-function, and the hash function must have a = known fixed length of N octets, as specified in Section 4.2. NEW: o The ICV is not calculated as = cryptographic-function(hash- function(content)) as defined in [RFC7182], but = (like the HMAC ICVs defined in [RFC7182]) uses the hash function = within the cryptographic function. The option "none" is not = permitted for hash-function, and the hash function must have a = known fixed length of N octets, as specified in Section 4.2. o While we are at it, it it crystal-clear to everybody = that =93Section 4.2=94 in the bullet above is to *this* document, as not RFC7182? o Section 4.3, 2nd bullet There=92s a LOT of information embedded in this bullet, = and reading it suggests that it, readability-wise, might benefit from = embedding a: =85 =85 =85 o IANA Considerations: Given recent experiences in this WG and with requesting = IANA=20 registrations, may I suggest that this be modified to = say, more explicitly: 1) IANA is requested to reserve ECCSI with = description ___=20 and reference =93This Specification=94 2) IANA is requested to reserve = ECCSI-ADDR=85. (similar) 3) The =93Cryptographic Functions = Registry=94, defined in=20 [RFC7182], with these registrations = made, will look like Table 1, which replaces Table 11 of = [RFC7182] 4) Obviously, include in Table 1 the = registrations from RFC7182. 5) That this document does not modify the = expert review guidelines as set forth in = RFC7182 for future allocations. That=92s all. Thanks for writing this document, Chris.=09 Respectfully, Thomas= --Apple-Mail=_366DA933-603C-42E5-A073-E5A1C7C2100F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = WG Chairs, 
Dear Chris, all,

As the author = indicated by email recently, he believes = that draft-ietf-manet-olsrv2-management-snapshot is ready for = WGLC. 

As a reminder, this document = aims for publication as a Proposed Standard.

I = have, therefore, reviewed the document carefully. In my opinion, the = author is right =97 in my opinion this document is ready for = WGLC.

Moreover, I believe that it is a = highly important document for the WG to produce, as it fills a real = need, and does so by relying on already-published crypto RFCs, rather = than by coming up with something esoteric.

I = have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that should = be blocking.

One of the issues is =93need= a non-jetlagged ADs advice to be sure we do the right thing=94, the = other is =97 I think =97 a minor mix-up with a trivial editorial = resolution and zero technical impact on this = specification.

Either way, for information, I = include all issues and nits that I=92ve found in the = below.

Issues:

=
= o = In my opinion, =93Updates 7182=94 is inappropriate. What this = document does is:
(i) only = things permissible by RFC7182, and 
= (ii) = makes registration from IANA registries set up by = RFC7182
(noting, = of course, that RFC7181 doesn=92t =93Updates 5444=94 
=   =  when making registrations for TC messages from the = repositories 
 set = up by RFC5444 as a case of precedent)
= Consequently, I believe that the abstract, introduction, and = document 
header, needs updates to = reflect that this is not an update.
=
Caveat Lector: I have = bounced this around with the author, and I 
= think that the conclusion is that we need just a = friendly 
ADs = opinion =97 my understanding is that the author
= =93wants this out, but wants it done right, also=94, = something
to which = I can but adhere.
= I believe that we should WGLC the document. If the = AD
= finds the time to address this issue during WGLC, = great -
= otherwise, we can reflect this in the =93Document = Writeup=94
that the = AD will consider with the publication request =97 as
= this (imo) is procedural/editorial, and certainly not = technical.

o Introduction, 4th = paragraph:

Isn=92t it RFC7183 which = does shared-secret-key ICVs? I just did a quick
= grep through of =93shared=94 in 7182, and found just a few = mentions, notably
setting a side a = value for key-id-length in that case. And =93secret=94 is = not
mentioned anywhere in = 7182


Nits:
= o = Introduction, 1st paragraph:
= OLD:
This = specification extends the TLV definitions
= therein by defining two new cryptographic function code points = that
= allow the use of an identity-based signature = (IBS) as an ICV.

NEW:
= This specification defines two new cryptographic = function 
code points from = within the registries set up by [RFC7182], 
= that allow the use of an identity-based signature (IBS) as an = ICV.

o Introduction, 2nd paragraph, 1st = line:
= I took a double-take when I saw the = parenthesis 
=93(protocol = participant)=94 =97 that seems a little odd, and I am on a = crusade
against redundant and = hard-to-parse terminology ;)

I = think that what is meant is =93router, which is running a = routing 
protocol which is based = on RFC5444=94, so could the document not say
= that?

In any event, I do not = see =93protocol participant=94 defined or anywhere else,
= and so it seems unfortunate to *not* be explicit = here.

o Introduction, 3rd = paragraph:

OLD:
= Two options for the choice of identity are supported (the two = code
= points = allocated).

NEW:
= Two options for the choice of identity are supported (as = reflected
by the two code = points allocated).


o = Introduction, 7th paragraph:
= Caveating that using this introduces the danger that =93if you = catch the 
trusted authority, then = you=92re screwed=94 is awesome. I see that 
= this is repeated and reworded in the Security Considerations = section,
and I = approve. 

Now, my question is then, = if this should not be stated in the Applicability 
= statement, also? Something to the effect of that this applies to = networks
where all routers can (at = some point) be in contact with the TA (to be
= keyed), but that this can be off-line =97 and probably should be = off-line
since the TA really, = really should be protected.

= It might be argued that the forward-reference to Section 6 = captures
this =97 I still think, = that a few choice words in the applicability statement
= would help greatly.

o = Introduction, 9th paragraph:
= Any [academic? otherwise] work that you can cite to quantify = the 
computational load? I = asked a crypto-wonk-colleague, who said
= something to the effect of =93the document is perfectly right, on = this
= point, but I do not have a paper just off the top of = my head with 
interesting data to = offer=94. For that reason alone, it=92d be = interesting 
if you did = ;)

o Throw-away comment, I appreciate = particularly the last
paragraph of the = introduction.

o Section 4.1, first = bullet

OLD:
=    o  The ICV is not calculated as = cryptographic-function(hash-
      =  function(content)) as defined in [RFC7182], but (like the = HMAC
=        ICVs defined there) uses the = hash function within the
     =   cryptographic function.  The option "none" is not permitted = for
=        hash-function, and the hash function = must have a known fixed
     =   length of N octets, as specified in Section = 4.2.

= NEW:
   o  The = ICV is not calculated as cryptographic-function(hash-
=        function(content)) as defined in = [RFC7182], but (like the HMAC
     =   ICVs defined in [RFC7182]) uses the hash function within = the
       cryptographic = function.  The option "none" is not permitted for
=        hash-function, and the hash function = must have a known fixed
     =   length of N octets, as specified in Section = 4.2.

o While we are at it, it it = crystal-clear to everybody that =93Section 4.2=94 in
= the bullet above is to *this* document, as not = RFC7182?

o Section 4.3, 2nd = bullet
= There=92s a LOT of information embedded in this = bullet, and reading it
suggests that it, = readability-wise, might benefit from embedding a:
= <list style=3D=93hanging=94>
= <t hangText=3D=93Packet TLVs=94>=85</t>
= <t hangText=3D=93Message TLVs=94>=85</t>
= <t hangText=3D=93Address Block = TLVs=94>=85</t>
= </list>

o IANA = Considerations:

Given recent experiences = in this WG and with requesting IANA 
= registrations, may I suggest that this be modified to say, = more
= explicitly:

= 1) = IANA is requested to reserve ECCSI with description = ___ 
and = reference =93This Specification=94

= 2) = IANA is requested to reserve ECCSI-ADDR=85. = (similar)

3) The = =93Cryptographic Functions Registry=94, defined in 
= [RFC7182], with these registrations made, will = look
= like Table 1, which replaces Table 11 of = [RFC7182]

4) = Obviously, include in Table 1 the registrations = from
= RFC7182.

= 5) = That this document does not modify the expert
= review guidelines as set forth in RFC7182 for
= future allocations.

That=92s all. Thanks = for writing this document, Chris. =


Respectfully,
Thomas
= --Apple-Mail=_366DA933-603C-42E5-A073-E5A1C7C2100F-- From nobody Mon Jul 28 06:19:52 2014 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 533091B27F5 for ; Mon, 28 Jul 2014 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YwBhhIk_o3L9 for ; Mon, 28 Jul 2014 06:19:38 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AA91B280D for ; Mon, 28 Jul 2014 06:19:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id E2696D40172; Mon, 28 Jul 2014 06:19:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 487FAD4015E; Mon, 28 Jul 2014 06:19:31 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_63C32323-BF2B-4114-BD7F-BEA41A09DF97" Message-Id: <139E2EC0-4D23-4590-AE9A-87FBE7165A18@thomasclausen.org> Date: Mon, 28 Jul 2014 15:19:31 +0200 To: manet , "" , manet-ads Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0LVTqc8caToOepCdsH_kjxtuvak Subject: [manet] Ready for WGLC: Advancing draft-ietf-manet-olsrv2-management-snapshot 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, 28 Jul 2014 13:19:48 -0000 --Apple-Mail=_63C32323-BF2B-4114-BD7F-BEA41A09DF97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG Chairs, As indicated in Toronto, the authors believe that = draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC.=20 As a reminder, this document aims for publication as an Informational = RFC. Would you kindly let us know your thoughts on this matter, at your = earliest convenience, preferably by issuing a WGLC? Respectfully, Thomas= --Apple-Mail=_63C32323-BF2B-4114-BD7F-BEA41A09DF97 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear WG Chairs,

As indicated in Toronto, the authors believe that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 

As a reminder, this document aims for publication as an Informational RFC.

Would you kindly let us know your thoughts on this matter, at your earliest convenience, preferably by issuing a WGLC?

Respectfully,

Thomas
--Apple-Mail=_63C32323-BF2B-4114-BD7F-BEA41A09DF97-- From nobody Mon Jul 28 06:33:30 2014 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 565281A0331 for ; Mon, 28 Jul 2014 06:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xMJAq9afTeWF for ; Mon, 28 Jul 2014 06:33:28 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358511A01D5 for ; Mon, 28 Jul 2014 06:33:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id F1517D40189; Mon, 28 Jul 2014 06:33:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 436ACD4015E; Mon, 28 Jul 2014 06:33:24 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_74B789F7-1CE7-428D-A4E9-5084FACA64CD" Date: Mon, 28 Jul 2014 15:33:22 +0200 Message-Id: To: manet , "" , manet-ads Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JwWTpfz-3QP9FFnbOMhzI3bunuA Cc: Christopher Dearlove Subject: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis 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, 28 Jul 2014 13:33:29 -0000 --Apple-Mail=_74B789F7-1CE7-428D-A4E9-5084FACA64CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear WG Chairs, co-authors, all, As indicated in Toronto, the authors believe that the remaining issue = with draft-ietf-manet-nhdp-optimization was how to properly do the = updates to the MIB module of RFC6779. We believe that Toronto confirmed that the way forward was to do an = RFC6779bis document, which reflects the MIB considerations section = (Section 6) from draft-ietf-manet-nhdp-optimization, which the WG = already adopted, into RFC6779. As Ulrich indicated in his recent mail, this is what = draft-clausen-manet-rfc6779bis does =97 nothing more, nothing less. I believe that with this issue resolved, = draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis = essentially are ready for WGLC.=20 As a reminder, both documents aims publication as an Proposed Standard = RFCs. Procedurally, I would like to enter a rapid succession of: 1) Submission of draft-clausen-manet-rfc6779bis-00 as = draft-ietf-manet-rfc6779bis-00 2) Submission of draft-ietf-manet-nhdp-optimization-01, = with the only difference to -00 being section 6 removed, and replaced by a reference to=20= draft-clausen-manet-rfc6779bis-00 as = draft-ietf-manet-rfc6779bis-00 3) A WGLC being issued for both these documents, = concurrently. WG Chairs, would you kindly let us know your thoughts on this matter, at = your earliest convenience, so that we may aim at a WGLC soon, such that = the WG will have visible progress to report at the RTG Area Open = Meeting? Respectfully, Thomas= --Apple-Mail=_74B789F7-1CE7-428D-A4E9-5084FACA64CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = WG Chairs, co-authors, all,

As indicated in Toronto, = the authors believe that the remaining issue with = draft-ietf-manet-nhdp-optimization was how to properly do the updates to = the MIB module of RFC6779.

We believe that = Toronto confirmed that the way forward was to do an RFC6779bis document, = which reflects the MIB considerations section (Section 6) = from draft-ietf-manet-nhdp-optimization, which the WG already = adopted, into RFC6779.

As Ulrich indicated in = his recent mail, this is what draft-clausen-manet-rfc6779bis does =97= nothing more, nothing less.

I believe that = with this issue resolved, draft-ietf-manet-nhdp-optimization & = draft-clausen-manet-rfc6779bis essentially = are ready for = WGLC. 

As a reminder, both = documents aims publication as an Proposed Standard = RFCs.

Procedurally, I would like to enter a = rapid succession of:

1) = Submission of draft-clausen-manet-rfc6779bis-00 = as draft-ietf-manet-rfc6779bis-00

2) = Submission of draft-ietf-manet-nhdp-optimization-01, with = the only difference to -00
being section 6 removed, = and replaced by a reference to 
= draft-clausen-manet-rfc6779bis-00 = as draft-ietf-manet-rfc6779bis-00

3) A WGLC = being issued for both these documents, = concurrently.

WG Chairs, would you kindly let = us know your thoughts on this matter, at your earliest convenience, so = that we may aim at a WGLC soon, such that the WG will have visible = progress to report at the RTG Area Open = Meeting?

Respectfully,

T= homas
= --Apple-Mail=_74B789F7-1CE7-428D-A4E9-5084FACA64CD-- From nobody Mon Jul 28 06:58:24 2014 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 6203E1B2825 for ; Mon, 28 Jul 2014 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_AS_SEEN=1.461] 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 5QfK4AMOSYly for ; Mon, 28 Jul 2014 06:58:21 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFBF1B2820 for ; Mon, 28 Jul 2014 06:58:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id D74E9D40758; Mon, 28 Jul 2014 06:58:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 6F819D40172; Mon, 28 Jul 2014 06:58:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_74621FCA-4395-43A6-BE61-78F4A00DD2C7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Mon, 28 Jul 2014 15:58:14 +0200 Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SA9i7vxOUW2HBoeXqK6xW4DnZ54 Cc: manet-ads , "manet@ietf.org" , Joe Macker , Stan Ratliff Subject: Re: [manet] MANET action items (as seen by Justin Dean) 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, 28 Jul 2014 13:58:22 -0000 --Apple-Mail=_74621FCA-4395-43A6-BE61-78F4A00DD2C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Abdussalam, On Jul 23, 2014, at 14:18, Abdussalam Baryun = wrote: > On Tue, Jul 22, 2014 at 10:35 PM, Justin Dean = wrote: > Notes on action items coming out of the MANET working group meeting. = (this list is not exhaustive of the topics covered in the meeting) >=20 > 1) A suggestion was made to ask Stan if dlep editing help would be = helpful. If yes who should that person(s) be? >=20 > 2) What to do with the report MIB; Kill, finish, revise? >=20 > 3) Request for WG adoption of SMF sec threat document was made. No = one in the room had read the draft, but there was positive room reaction = to adopting a document with this subject and no negative reaction as = measured by hum. Please read the draft and comment. > =20 > The WG should read the draft and discuss before adopting or humming = and I hope the chairs consider the high volume of drafts to give me more = time before their decisions. The documents were submitted well in advance of the meeting, before the = document submission deadline that precedes all IETF meetings, and were = announced on the list at about the same time. There were not a whole lot of new WG documents in MANET this time = around, and there were no updates to two of the documents which = otherwise are WG documents, made before that official deadline =97 = compared to other WGs, I don=92t think that this can be considered a = particularly high volume of drafts, and the drafts are not particularly = complex nor wrong either. > 6) Request for WG adoption of OLSRv2 multi-path for experimental = status was made. No one in the room had read the draft, there was mixed = but positive reaction as measured by hum. Please read the draft and = comment. > =20 > I reject until we get time to review and do our priorities on other = drafts. I agree, that it would be good to see forward progress on the documents, = for which there has been none.=20 As you have no doubt also observed, for both draft-ietf-manet-aodvv2 and = draft-ietf-manet-dlep, there have been ample feedback and reviews given = on the mailing list, but (for the former) that feedback has not been = reflected in the recent versions of the document, and (for the latter) = there has been no new version for a while (but, a lot of good = discussion). While the authors of these two documents work to figure out to spin new = revisions among themselves, revisions which fold in all the feedback = that the WG has provided, the rest of the WG can=92t be expected to = simply idle when there=92re other things to do. Perhaps your volunteering to help the authors of draft-ietf-manet-aodvv2 = and draft-ietf-manet-dlep in the editorial process might be a way for = you to contribute to making progress? > 7) Request for WG adoption of ODMRP was made. Discussion within the = room touched upon the charter and was generally positive to multicast = work but again charter. No hum was held. > =20 > I dont support adopting reactive multicast until we finish the = reactive standard For what it=92s worth, there=92s actually no dependency between ODMRP = and the reactive unicast protocol =97 I would even make the case that = ODMRP would work quite nicely on a network on which OLSRv2 provides = unicast routing, since ODMRP in that case could take advantage of = OLSRv2=92s optimized flooding (for example) for diffusing its control = messages and maintaining link status tracking.=20 Thomas > =20 > AB >=20 >=20 > Justin Dean >=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=_74621FCA-4395-43A6-BE61-78F4A00DD2C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Abdussalam,

On Jul 23, 2014, at = 14:18, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

On Tue, Jul 22, 2014 at 10:35 PM, Justin Dean = <bebemaster@gmail.com> wrote:
Notes on action items coming out of the MANET working = group meeting. (this list is not exhaustive of the topics covered in the = meeting)

1) A suggestion was made to ask Stan if dlep editing help would be = helpful. If yes who should that person(s) be?

2) What to do with = the report MIB; Kill, finish, revise?

3) Request for WG adoption = of SMF sec threat document was made.  No one in the room had read = the draft, but there was positive room reaction to adopting a document = with this subject and no negative reaction as measured by hum. =  Please read the draft and comment.
 
The WG should read the draft and discuss before adopting or humming = and I hope the chairs consider the high volume of drafts to give me more = time before their decisions.

The documents were submitted = well in advance of the meeting, before the document submission deadline = that precedes all IETF meetings, and were announced on the list at about = the same time.

There were not a whole lot of = new WG documents in MANET this time around, and there were no updates to = two of the documents which otherwise are WG documents, made before that = official deadline =97 compared to other WGs, I don=92t think that this = can be considered a particularly high volume of drafts, and the drafts = are not particularly complex nor wrong = either.

6) Request for WG adoption of OLSRv2 multi-path for experimental = status was made.  No one in the room had read the draft, there was = mixed but positive reaction as measured by hum.  Please read the = draft and comment.
 
I reject until we get time to review and do our priorities on other = drafts.

I agree, that it would be = good to see forward progress on the documents, for which there has been = none. 

As you have no doubt also observed, = for both draft-ietf-manet-aodvv2 and draft-ietf-manet-dlep, there have = been ample feedback and reviews given on the mailing list, but (for the = former) that feedback has not been reflected in the recent versions of = the document, and (for the latter) there has been no new version for a = while (but, a lot of good discussion).

While = the authors of these two documents work to figure out to spin new = revisions among themselves, revisions which fold in all the feedback = that the WG has provided, the rest of the WG can=92t be expected to = simply idle when there=92re other things to = do.

Perhaps your volunteering to help the = authors of draft-ietf-manet-aodvv2 and draft-ietf-manet-dlep in the = editorial process might be a way for you to contribute to making = progress?


7) Request for WG adoption of ODMRP was made. =  Discussion within the room touched upon the charter and was = generally positive to multicast work but again charter. No hum was = held.
 
I dont support adopting reactive multicast until we finish the = reactive standard

For what = it=92s worth, there=92s actually no dependency between ODMRP and the = reactive unicast protocol =97 I would even make the case that ODMRP = would work quite nicely on a network on which OLSRv2 provides unicast = routing, since ODMRP in that case could take advantage of OLSRv2=92s = optimized flooding (for example) for diffusing its control messages and = maintaining link status = tracking. 

Thomas

 
AB


Justin = Dean

____________________________________= ___________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

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

= --Apple-Mail=_74621FCA-4395-43A6-BE61-78F4A00DD2C7-- From nobody Mon Jul 28 06:58:49 2014 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 67D131B282E for ; Mon, 28 Jul 2014 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 AIZxODLQhW53 for ; Mon, 28 Jul 2014 06:58:42 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC951B282B for ; Mon, 28 Jul 2014 06:58:38 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,749,1400040000"; d="scan'208";a="2770574" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport2.idirect.net with ESMTP; 28 Jul 2014 09:58:37 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Mon, 28 Jul 2014 09:58:37 -0400 From: "Snyder, Brian" To: Toerless Eckert , Henning Rogge Thread-Topic: [manet] DLEP/satellite - default destination Thread-Index: AQHPp/0vh9b7bJj4vEqYXS8XW5vOFJuxAegAgABL6ICABDjJgA== Date: Mon, 28 Jul 2014 13:58:36 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343048A80@VAUS-MBX03.idirect.net> References: <20140725114000.GB7355@cisco.com> <20140725172503.GD7355@cisco.com> In-Reply-To: <20140725172503.GD7355@cisco.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: http://mailarchive.ietf.org/arch/msg/manet/fIl2iIMqvdL62RH3EImzrZ4Bph0 Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - default destination 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, 28 Jul 2014 13:58:45 -0000 Toerless , all, >The DMAC used in the default destination DLEP announcement is a special va= lue by which the router recognizes this to be a >special destination. The r= outer would not use this MAC address in actual data packets as a destinatio= n MAC address. So this speaks to what Rick was saying about why even tie this id to a MAC = address then... If we just consider it some unique discriminator id (like b= fd) then it can help simplify the model here, at least in my mind. Further= more if this 'ID' isn't actually used by any of the routers - couldn't I ju= st make it up? Whats to stop me from picking any locally generated # that = I want too - so long as I am guaranteed the router doesn't actually try and= use it instead of ARP, then my concerns get diluted - because I don't have= to start saving and tracking MACs I otherwise wouldn't care about - and I = can stay more transparent - with no OAM operator overhead also... no? At least in my use case, I am not so concerned with tracking multiple route= rs at all - I am concerned with optimally passing on RF link state informat= ion to assist the routers in optimally converging L3 tables with regards to= timing and overhead. If a router dies but the RF is fine - I would expect= the routers to figure that out themselves. If I can assist that convergen= ce I would consider it - but I view that as much less of a likely issue in = sat networks then RF troubles. Brian -----Original Message----- From: Toerless Eckert [mailto:eckert@cisco.com]=20 Sent: Friday, July 25, 2014 1:25 PM To: Henning Rogge Cc: Snyder, Brian; manet@ietf.org; Stan Ratliff (sratliff) Subject: Re: [manet] DLEP/satellite - default destination Henning: The DMAC used in the default destination DLEP announcement is a special val= ue by which the router recognizes this to be a special destination. The rou= ter would not use this MAC address in actual data packets as a destination = MAC address. Instead, it would solely use it to detect RF failure: When the default dest= ination is withdrawn, then the router would have to immediately consider al= l actual destinations unreachable. This behavior would not change in the face of multiple headend device/route= rs. The spoke router would only learn about hub routers via their IGP hellos, a= nd he would consider any hub router only reachable when the hub routers hel= lo packets hae not timed out AND when he default-destination is announced. What the default destination does NOT help with - i think - is when there a= re two hub routers, and one of them goes offline. The spoke modem could of = course not withdraf the default destination from DLEP. At best, the spoke m= odems could withdraw the default destination when the hub modem has no acti= ve DLEP session at all, aka: all hub routers down/unreachable. Hopefully Brian can chime in an reaffirm or reject that this is how he thin= ks this could work. Cheers Toerless On Fri, Jul 25, 2014 at 02:53:22PM +0200, Henning Rogge wrote: > On Fri, Jul 25, 2014 at 1:40 PM, Toerless Eckert wrote= : > > And the question is now just how to encode that magic destination in=20 > > DLEP. MAC broadcast may not be ideal, but maybe some othrer magic=20 > > DMAC. All 0 ?. >=20 > If the Hub end of the satellite link is connected to a switch (a few=20 > routers), how does this magic ethernet thing work? Or is the=20 > "destination Mac" completely optimized away and "regenerated" at the=20 > Hub? >=20 > Henning Rogge From nobody Mon Jul 28 07:12:02 2014 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 CA0AB1B283F for ; Mon, 28 Jul 2014 07:11:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ff9wdsEJRQBu for ; Mon, 28 Jul 2014 07:11:54 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2961B2840 for ; Mon, 28 Jul 2014 07:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 7538FD51941; Mon, 28 Jul 2014 07:11:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id A7C6ED4034A; Mon, 28 Jul 2014 07:11:51 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 28 Jul 2014 16:11:48 +0200 To: manet , "" , manet-ads Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fd1kjTcaFAPyObVQ1qWnCMaBH6E Subject: [manet] Request for WG Adoption: draft-yi-manet-smf-sec-threats 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, 28 Jul 2014 14:11:59 -0000 Dear WG chairs, As indicated in Toronto, the authors would like to see = draft-yi-manet-smf-sec-threats adopted as a WG document. The document is currently an individual document, and can be found here: http://tools.ietf.org/html/draft-yi-manet-smf-sec-threats-00 The presentation that was made in Toronto, including some motivational = material for this document, can be found here: https://tools.ietf.org/agenda/90/slides/slides-90-manet-11.pdf An additional motivating factor for publication is, that with the = resurge in interest in multicast protocols for MANETs, and with the = increased understanding of the expectations to security that std. track = MANET protocols are (and, rightfully so) subject to by the SEC-ADs, we = probably need to =93think security from the onset=94 for any multicast = efforts that we take on, if we are to be successful. The intent is to publish this document as an Informational RFC, similar = to how we did with RFC7186. It seems the right time to do so, given that we: o by now have had time to acquire some experience with = RFC6121 (SMF),=20 o have not yet engaged on moving SMF to standards track, = and to do so we=20 must understand and address security better o while we not (yet) have committed to a group-oriented = multicast protocol, discussions and interest has resurged with someone = actively pushing for that -- and I=92d bet that there would be lessons to = share into such an activity. WG Chairs, therefore: would you kindly let us know your thoughts on this = matter, at your earliest convenience, preferably by issuing a call for = WG adoption? Working Group in general: we much appreciate feedback, comments, and = sharing of your own analysis of and experiences with SMF, so that we may = fold that into future revisions of this document. Respectfully, and for the authors, Thomas= From nobody Mon Jul 28 07:22:23 2014 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 E65E21A01CB for ; Mon, 28 Jul 2014 07:22:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pRmneLduPt7g for ; Mon, 28 Jul 2014 07:22:13 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320301A0252 for ; Mon, 28 Jul 2014 07:22:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id F02C4D51941; Mon, 28 Jul 2014 07:22:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id E1FF7D40758; Mon, 28 Jul 2014 07:22:08 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jul 2014 16:22:05 +0200 Message-Id: <8ED4BC01-95FE-485C-B2DD-2CC4755CEB7B@thomasclausen.org> To: manet , "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/r1A-TVM3aprWau-yOamB-idYqAE Cc: Jiazi YI Subject: [manet] Advancing draft-clausen-manet-olsrv2-sec-threats 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, 28 Jul 2014 14:22:20 -0000 All, As announced in Toronto, we=92ve submitted = draft-clausen-manet-olsrv2-sec-threats. You can find it here: = http://tools.ietf.org/html/draft-clausen-manet-olsrv2-sec-threats-00 Now, we did not present it in Toronto, since we didn=92t manage to get = it in before the official deadline =97 and, we do believe that deadlines = are there for a reason. Therefore, this email. This document has as objective to do to RFC7181 (OLSRv2) as RFC7186 did = to RFC6130 (NHDP): document the threat analysis that we did as part of = the design process of the protocol. This document will, in a coming version, got a bit farther than did = RFC7186: given RFC7182 and RFC7183 provides some =93mandatory to = implement=94 security mechanisms for OLSRv2, the document will (try to) = reflect on how those alleviate some of the threats identified, and point = out which (if any) are not yet alleviated. As a reminder, this document aims for publication as an informational = RFC. It=92s very much work in progress, we did submit it only recently during = the IETF week, we do think that there=92s some work that needs doing, = and we therefore do not ask for WG adoption yet. What we do ask is for those of you working with, building on, extending, = deploying, coding, dreaming of (you know who you are=85), and otherwise = using OLSRv2 to review and give us comments, thoughts, feedback, etc. We do plan on spinning new revisions fairly frequently in the months to = come, or so =97 and, if all goes according to how we hope it will, we = will be ready to be asking for WG adoption towards the end of August. So, let=92s have it=85 ;) Respectfully, and for the authors, Thomas From nobody Mon Jul 28 07:27:16 2014 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 1ABF51B2818 for ; Mon, 28 Jul 2014 07:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 4sINSpWFt7q1 for ; Mon, 28 Jul 2014 07:27:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6AE1B2813 for ; Mon, 28 Jul 2014 07:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2211; q=dns/txt; s=iport; t=1406557633; x=1407767233; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sRcawCsX1uuGI9eDbWnJv0l7JWhiOoAkHCiESI+eNEc=; b=jkzvqA+XlBUnq9YjfCAxln30kIlw9juWwuWfibSxC7OgiSFGYNfG/oBS TA8N+/Fj9hbVNzkJF5ez9nCUZ4qo/nHXKWEETycADaMNH1BtkVga5ioJX uAW904l09zpqezcNNIj+KoDf1iWAxDPz/TTR/SEjhT4YCzgFwBCzgurVv s=; X-IronPort-AV: E=Sophos;i="5.01,749,1400025600"; d="scan'208";a="64575386" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 28 Jul 2014 14:27:13 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6SERCbj007846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 14:27:12 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s6SER1cD000519; Mon, 28 Jul 2014 07:27:01 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s6SER1Sw000518; Mon, 28 Jul 2014 07:27:01 -0700 Date: Mon, 28 Jul 2014 07:27:01 -0700 From: Toerless Eckert To: "Snyder, Brian" Message-ID: <20140728142701.GA31858@cisco.com> References: <20140725114000.GB7355@cisco.com> <20140725172503.GD7355@cisco.com> <84585478AABBBF4B9DF597FC0F84AF7343048A80@VAUS-MBX03.idirect.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343048A80@VAUS-MBX03.idirect.net> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Rq_9iHfTFK_sIIovWTSxm1ktCFc Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP/satellite - default destination 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, 28 Jul 2014 14:27:15 -0000 On Mon, Jul 28, 2014 at 01:58:36PM +0000, Snyder, Brian wrote: > Toerless , all, > > >The DMAC used in the default destination DLEP announcement is a special value by which the router recognizes this to be a >special destination. The router would not use this MAC address in actual data packets as a destination MAC address. > > So this speaks to what Rick was saying about why even tie this id to a MAC address then... If we just consider it some unique discriminator id (like bfd) then it can help simplify the model here, at least in my mind. Furthermore if this 'ID' isn't actually used by any of the routers - couldn't I just make it up? Whats to stop me from picking any locally generated # that I want too - so long as I am guaranteed the router doesn't actually try and use it instead of ARP, then my concerns get diluted - because I don't have to start saving and tracking MACs I otherwise wouldn't care about - and I can stay more transparent - with no OAM operator overhead also... no? Given how its Ricks idea, i hope it will validate his goal if we try to interpret it: -> That ID would be locally generated by the modem to distinguish the different destinations it announces and sends to the router via the DLEP session. Or vice versa, router to modem. -> Ultimatly, we would need for the default destination some other TLV to indicate that it is a default-destination. > At least in my use case, I am not so concerned with tracking multiple routers at all - I am concerned with optimally passing on RF link state information to assist the routers in optimally converging L3 tables with regards to timing and overhead. If a router dies but the RF is fine - I would expect the routers to figure that out themselves. If I can assist that convergence I would consider it - but I view that as much less of a likely issue in sat networks then RF troubles. Well, that problem we need to consider beyond the DLEP encoding of default destination is how routers would choose to detect that a router on the remote side has failed. If DLEP implements the default location, do you think deployments would not need the BFD proxy idea anymore ? Cheers Toerless From nobody Mon Jul 28 07:37:50 2014 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 93D0B1A0385 for ; Mon, 28 Jul 2014 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WM-mgb7OPSEh for ; Mon, 28 Jul 2014 07:37:43 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3598A1A0252 for ; Mon, 28 Jul 2014 07:37:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id EB4DBD548F9; Mon, 28 Jul 2014 07:37:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id BB2B2D54AE5; Mon, 28 Jul 2014 07:37:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7BF11797-648E-4E3B-BCBC-920B5AF3DFA6" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Mon, 28 Jul 2014 16:37:36 +0200 Message-Id: <5BAD70D6-1E6E-4CF5-803B-54CF3B7BD4E5@thomasclausen.org> References: To: manet , "" , manet-ads X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2ri4drUoWc4dqhpKrk5P-0wN58c Cc: Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 28 Jul 2014 14:37:49 -0000 --Apple-Mail=_7BF11797-648E-4E3B-BCBC-920B5AF3DFA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 28, 2014, at 15:19, Thomas Clausen = wrote: > Dear WG Chairs,=20 > Dear Chris, all, >=20 > As the author indicated by email recently, he believes that = draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC.=20 >=20 And, Ulrich just pointed out to me in private that the above should be = "draft-ietf-manet-ibs=94, of course =97 I thought I was being clever = using email templates, and all. Apologies, and thank you Ulrich for = catching my screwup. Thomas > As a reminder, this document aims for publication as a Proposed = Standard. >=20 > I have, therefore, reviewed the document carefully. In my opinion, the = author is right =97 in my opinion this document is ready for WGLC. >=20 > Moreover, I believe that it is a highly important document for the WG = to produce, as it fills a real need, and does so by relying on = already-published crypto RFCs, rather than by coming up with something = esoteric. >=20 > I have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that should be = blocking. >=20 > One of the issues is =93need a non-jetlagged ADs advice to be sure we = do the right thing=94, the other is =97 I think =97 a minor mix-up with = a trivial editorial resolution and zero technical impact on this = specification. >=20 > Either way, for information, I include all issues and nits that I=92ve = found in the below. >=20 > Issues: >=20 > o In my opinion, =93Updates 7182=94 is inappropriate. What = this document does is: > (i) only things permissible by RFC7182, and=20= > (ii) makes registration from IANA registries = set up by RFC7182 > (noting, of course, that RFC7181 doesn=92t= =93Updates 5444=94=20 > when making registrations for TC = messages from the repositories=20 > set up by RFC5444 as a case of = precedent) > Consequently, I believe that the abstract, introduction, = and document=20 > header, needs updates to reflect that this is not an = update. > =09 > Caveat Lector: I have bounced this around with the = author, and I=20 > think that the conclusion is that we = need just a friendly=20 > ADs opinion =97 my understanding is that = the author > =93wants this out, but wants it done = right, also=94, something > to which I can but adhere. > =09 > I believe that we should WGLC the = document. If the AD > finds the time to address this issue = during WGLC, great - > otherwise, we can reflect this in the = =93Document Writeup=94 > that the AD will consider with the = publication request =97 as > this (imo) is procedural/editorial, and = certainly not technical. >=20 > o Introduction, 4th paragraph: >=20 > Isn=92t it RFC7183 which does shared-secret-key ICVs? I = just did a quick > grep through of =93shared=94 in 7182, and found just a = few mentions, notably > setting a side a value for key-id-length in that case. = And =93secret=94 is not > mentioned anywhere in 7182 >=20 >=20 > Nits: > o Introduction, 1st paragraph: > OLD: > This specification extends the TLV definitions > therein by defining two new cryptographic = function code points that > allow the use of an identity-based signature = (IBS) as an ICV. >=20 > NEW: > This specification defines two new cryptographic = function=20 > code points from within the registries set up by = [RFC7182],=20 > that allow the use of an identity-based = signature (IBS) as an ICV. >=20 > o Introduction, 2nd paragraph, 1st line: > I took a double-take when I saw the parenthesis=20 > =93(protocol participant)=94 =97 that seems a little = odd, and I am on a crusade > against redundant and hard-to-parse terminology ;) >=20 > I think that what is meant is =93router, which is = running a routing=20 > protocol which is based on RFC5444=94, so could the = document not say > that? >=20 > In any event, I do not see =93protocol participant=94 = defined or anywhere else, > and so it seems unfortunate to *not* be explicit here. >=20 > o Introduction, 3rd paragraph: >=20 > OLD: > Two options for the choice of identity are = supported (the two code > points allocated). >=20 > NEW: > Two options for the choice of identity are = supported (as reflected > by the two code points allocated). >=20 >=20 > o Introduction, 7th paragraph: > Caveating that using this introduces the danger that =93if= you catch the=20 > trusted authority, then you=92re screwed=94 is awesome. = I see that=20 > this is repeated and reworded in the Security = Considerations section, > and I approve.=20 >=20 > Now, my question is then, if this should not be stated = in the Applicability=20 > statement, also? Something to the effect of that this = applies to networks > where all routers can (at some point) be in contact with = the TA (to be > keyed), but that this can be off-line =97 and probably = should be off-line > since the TA really, really should be protected. >=20 > It might be argued that the forward-reference to Section = 6 captures > this =97 I still think, that a few choice words in the = applicability statement > would help greatly. >=20 > o Introduction, 9th paragraph: > Any [academic? otherwise] work that you can cite to = quantify the=20 > computational load? I asked a crypto-wonk-colleague, who = said > something to the effect of =93the document is perfectly = right, on this > point, but I do not have a paper just off the top of my = head with=20 > interesting data to offer=94. For that reason alone, = it=92d be interesting=20 > if you did ;) >=20 > o Throw-away comment, I appreciate particularly the last > paragraph of the introduction. >=20 > o Section 4.1, first bullet >=20 > OLD: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in [RFC7182], but = (like the HMAC > ICVs defined there) uses the hash function within = the > cryptographic function. The option "none" is not = permitted for > hash-function, and the hash function must have a = known fixed > length of N octets, as specified in Section 4.2. >=20 > NEW: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in [RFC7182], but = (like the HMAC > ICVs defined in [RFC7182]) uses the hash function = within the > cryptographic function. The option "none" is not = permitted for > hash-function, and the hash function must have a = known fixed > length of N octets, as specified in Section 4.2. >=20 > o While we are at it, it it crystal-clear to everybody = that =93Section 4.2=94 in > the bullet above is to *this* document, as not RFC7182? >=20 > o Section 4.3, 2nd bullet > There=92s a LOT of information embedded in this bullet, = and reading it > suggests that it, readability-wise, might benefit from = embedding a: > > =85 > =85 > =85 > >=20 > o IANA Considerations: >=20 > Given recent experiences in this WG and with requesting = IANA=20 > registrations, may I suggest that this be modified to = say, more > explicitly: >=20 > 1) IANA is requested to reserve ECCSI with = description ___=20 > and reference =93This Specification=94 >=20 > 2) IANA is requested to reserve = ECCSI-ADDR=85. (similar) >=20 > 3) The =93Cryptographic Functions = Registry=94, defined in=20 > [RFC7182], with these registrations = made, will look > like Table 1, which replaces Table 11 of = [RFC7182] >=20 > 4) Obviously, include in Table 1 the = registrations from > RFC7182. >=20 > 5) That this document does not modify the = expert > review guidelines as set forth in = RFC7182 for > future allocations. >=20 > That=92s all. Thanks for writing this document, Chris.=09 >=20 >=20 > Respectfully, >=20 > Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_7BF11797-648E-4E3B-BCBC-920B5AF3DFA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 28, 2014, at 15:19, Thomas = Clausen <thomas@thomasclausen.org> = wrote:

Dear = WG Chairs, 
Dear Chris, all,

As the author = indicated by email recently, he believes = that draft-ietf-manet-olsrv2-management-snapshot is ready for = WGLC. 


And, Ulrich just pointed out to me in private that the above should be = "draft-ietf-manet-ibs=94, of course =97 I thought I was being clever = using email templates, and all. Apologies, and thank you Ulrich for = catching my = screwup.

Thomas

As a reminder, = this document aims for publication as a Proposed = Standard.

I have, therefore, reviewed the = document carefully. In my opinion, the author is right =97 in my = opinion this document is ready for = WGLC.

Moreover, I believe that it is a = highly important document for the WG to produce, as it fills a real = need, and does so by relying on already-published crypto RFCs, rather = than by coming up with something esoteric.

I = have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that should = be blocking.

One of the issues is =93need= a non-jetlagged ADs advice to be sure we do the right thing=94, the = other is =97 I think =97 a minor mix-up with a trivial editorial = resolution and zero technical impact on this = specification.

Either way, for information, I = include all issues and nits that I=92ve found in the = below.

Issues:

=
= o = In my opinion, =93Updates 7182=94 is inappropriate. What this = document does is:
(i) only = things permissible by RFC7182, and 
= (ii) = makes registration from IANA registries set up by = RFC7182
(noting, = of course, that RFC7181 doesn=92t =93Updates 5444=94 
=   =  when making registrations for TC messages from the = repositories 
 set = up by RFC5444 as a case of precedent)
= Consequently, I believe that the abstract, introduction, and = document 
header, needs updates to = reflect that this is not an update.
=
Caveat Lector: I have = bounced this around with the author, and I 
= think that the conclusion is that we need just a = friendly 
ADs = opinion =97 my understanding is that the author
= =93wants this out, but wants it done right, also=94, = something
to which = I can but adhere.
= I believe that we should WGLC the document. If the = AD
= finds the time to address this issue during WGLC, = great -
= otherwise, we can reflect this in the =93Document = Writeup=94
that the = AD will consider with the publication request =97 as
= this (imo) is procedural/editorial, and certainly not = technical.

o Introduction, 4th = paragraph:

Isn=92t it RFC7183 which = does shared-secret-key ICVs? I just did a quick
= grep through of =93shared=94 in 7182, and found just a few = mentions, notably
setting a side a = value for key-id-length in that case. And =93secret=94 is = not
mentioned anywhere in = 7182


Nits:
= o = Introduction, 1st paragraph:
= OLD:
This = specification extends the TLV definitions
= therein by defining two new cryptographic function code points = that
= allow the use of an identity-based signature = (IBS) as an ICV.

NEW:
= This specification defines two new cryptographic = function 
code points from = within the registries set up by [RFC7182], 
= that allow the use of an identity-based signature (IBS) as an = ICV.

o Introduction, 2nd paragraph, 1st = line:
= I took a double-take when I saw the = parenthesis 
=93(protocol = participant)=94 =97 that seems a little odd, and I am on a = crusade
against redundant and = hard-to-parse terminology ;)

I = think that what is meant is =93router, which is running a = routing 
protocol which is based = on RFC5444=94, so could the document not say
= that?

In any event, I do not = see =93protocol participant=94 defined or anywhere else,
= and so it seems unfortunate to *not* be explicit = here.

o Introduction, 3rd = paragraph:

OLD:
= Two options for the choice of identity are supported (the two = code
= points = allocated).

NEW:
= Two options for the choice of identity are supported (as = reflected
by the two code = points allocated).


o = Introduction, 7th paragraph:
= Caveating that using this introduces the danger that =93if you = catch the 
trusted authority, then = you=92re screwed=94 is awesome. I see that 
= this is repeated and reworded in the Security Considerations = section,
and I = approve. 

Now, my question is then, = if this should not be stated in the Applicability 
= statement, also? Something to the effect of that this applies to = networks
where all routers can (at = some point) be in contact with the TA (to be
= keyed), but that this can be off-line =97 and probably should be = off-line
since the TA really, = really should be protected.

= It might be argued that the forward-reference to Section 6 = captures
this =97 I still think, = that a few choice words in the applicability statement
= would help greatly.

o = Introduction, 9th paragraph:
= Any [academic? otherwise] work that you can cite to quantify = the 
computational load? I = asked a crypto-wonk-colleague, who said
= something to the effect of =93the document is perfectly right, on = this
= point, but I do not have a paper just off the top of = my head with 
interesting data to = offer=94. For that reason alone, it=92d be = interesting 
if you did = ;)

o Throw-away comment, I appreciate = particularly the last
paragraph of the = introduction.

o Section 4.1, first = bullet

OLD:
=    o  The ICV is not calculated as = cryptographic-function(hash-
      =  function(content)) as defined in [RFC7182], but (like the = HMAC
=        ICVs defined there) uses the = hash function within the
     =   cryptographic function.  The option "none" is not permitted = for
=        hash-function, and the hash function = must have a known fixed
     =   length of N octets, as specified in Section = 4.2.

NEW:
=    o  The ICV is not calculated as = cryptographic-function(hash-
      =  function(content)) as defined in [RFC7182], but (like the = HMAC
       ICVs defined in = [RFC7182]) uses the hash function within the
=        cryptographic function.  The = option "none" is not permitted for
=        hash-function, and the hash function = must have a known fixed
     =   length of N octets, as specified in Section = 4.2.

o While we are at it, it it = crystal-clear to everybody that =93Section 4.2=94 in
= the bullet above is to *this* document, as not = RFC7182?

o Section 4.3, 2nd = bullet
= There=92s a LOT of information embedded in this = bullet, and reading it
suggests that it, = readability-wise, might benefit from embedding a:
= <list style=3D=93hanging=94>
= <t hangText=3D=93Packet TLVs=94>=85</t>
= <t hangText=3D=93Message TLVs=94>=85</t>
= <t hangText=3D=93Address Block = TLVs=94>=85</t>
= </list>

o IANA = Considerations:

Given recent experiences = in this WG and with requesting IANA 
= registrations, may I suggest that this be modified to say, = more
= explicitly:

= 1) = IANA is requested to reserve ECCSI with description = ___ 
and = reference =93This Specification=94

= 2) = IANA is requested to reserve ECCSI-ADDR=85. = (similar)

3) The = =93Cryptographic Functions Registry=94, defined in 
= [RFC7182], with these registrations made, will = look
= like Table 1, which replaces Table 11 of = [RFC7182]

4) = Obviously, include in Table 1 the registrations = from
= RFC7182.

= 5) = That this document does not modify the expert
= review guidelines as set forth in RFC7182 for
= future allocations.

That=92s all. Thanks = for writing this document, Chris. =


Respectfully,
Thomas
_____________________________________= __________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_7BF11797-648E-4E3B-BCBC-920B5AF3DFA6-- From nobody Mon Jul 28 08:23:54 2014 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 3ABC31A03C1 for ; Mon, 28 Jul 2014 08:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Nz6qtsl5NuIn for ; Mon, 28 Jul 2014 08:23:48 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAD71A02E6 for ; Mon, 28 Jul 2014 08:23:48 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@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.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,749,1400040000"; d="png'150?scan'150,208,150";a="11615096" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 28 Jul 2014 11:23:47 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Mon, 28 Jul 2014 11:23:47 -0400 From: "Snyder, Brian" To: Rick Taylor , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Request to consider for DLEP Thread-Index: Ac+nQZ9HOC7baM2BRYeBGpl+qgu8wQAEY1/nAAjzGz8ABKPI0AAaqRUAAAX832AACbWtAAAIUehw///ECACAACSwsP///TkAgABC2xD//8VeAP/7pvIQ Date: Mon, 28 Jul 2014 15:23:46 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7343048C98@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.com>, <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB3D5@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148DB3D5@tss-server1.home.tropicalstormsoftware.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="_002_84585478AABBBF4B9DF597FC0F84AF7343048C98VAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YG0R0zWeZRAEe5-pvf-foifsaso Cc: "manet@ietf.org" Subject: Re: [manet] Request to consider for DLEP 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, 28 Jul 2014 15:23:51 -0000 --_002_84585478AABBBF4B9DF597FC0F84AF7343048C98VAUSMBX03idirec_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaywNCg0KQXR0YWNoZWQgaXMgcGljdHVyZSBpbiBhIGJpbmFyeSBmb3JtYXQuDQoNClRoYW5r cyxicmlhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljayBUYXlsb3Ig W21haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb21dIA0KU2VudDogRnJpZGF5LCBK dWx5IDI1LCAyMDE0IDEyOjU5IFBNDQpUbzogU255ZGVyLCBCcmlhbjsgU3RhbiBSYXRsaWZmIChz cmF0bGlmZikNCkNjOiBIZW5uaW5nIFJvZ2dlOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFttYW5ldF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KDQpCcmlhbiwNCg0KSSdtIGdl dHRpbmcgYmFmZmxlZCBhcyB5b3UgQVNDSUkgZGlhZ3JhbSBsb3N0IGFsbCBmb3JtYXR0aW5nLiAg Q2FuIHlvdSByZWRyYXcgaXQgYXMgYSBwbmcgb3Igc29tZXRoaW5nIGFuZCBzZW5kIGl0IGJhY2sg b3V0Pw0KDQpDaGVlcnMsDQoNClJpY2sNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IFNueWRlciwgQnJpYW4gW2JzbnlkZXJAaWRpcmVjdC5uZXRdDQpTZW50 OiAyNSBKdWx5IDIwMTQgMTc6MzcNClRvOiBTdGFuIFJhdGxpZmYgKHNyYXRsaWZmKQ0KQ2M6IFJp Y2sgVGF5bG9yOyBIZW5uaW5nIFJvZ2dlOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtt YW5ldF0gUmVxdWVzdCB0byBjb25zaWRlciBmb3IgRExFUA0KDQplbWJlZGRlZC4uLi4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0YW4gUmF0bGlmZiAoc3JhdGxpZmYpIFtt YWlsdG86c3JhdGxpZmZAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDI1LCAyMDE0IDEy OjMwIFBNDQpUbzogU255ZGVyLCBCcmlhbg0KQ2M6IFJpY2sgVGF5bG9yOyBIZW5uaW5nIFJvZ2dl OyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gUmVxdWVzdCB0byBjb25zaWRl ciBmb3IgRExFUA0KDQoNCk9uIEp1bCAyNSwgMjAxNCwgYXQgMTI6MjQgUE0sICJTbnlkZXIsIEJy aWFuIiA8YnNueWRlckBpZGlyZWN0Lm5ldD4NCiB3cm90ZToNCg0KPiBSaWNrLA0KPg0KPj4gQWgt aGEhISBUaGUgRExFUCBkZXN0aW5hdGlvbiBNQUMgaXMgZGVmaW5lZCB2ZXJ5IHNwZWNpZmljYWxs eSBhcyB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGludGVyZmFjZSB0aGF0IHRoZSByb3V0ZXIgaXMg dXNpbmcgZm9yIHRoZSBUQ1Agc2Vzc2lvbiB0byB0aGUgbG9jYWwgbW9kZW0uICBUaGUgcm91dGVy IG1heSBoYXZlIGEgYmlsbGlvbiBvdGhlciBNQUMgYWRkcmVzc2VzLCBidXQgb25seSB0aGF0IG9u ZSBpcyBpbXBvcnRhbnQuICBJbiB0aGUgPnNwb2tlIGNhc2UsIHRoZSBzYW1lIGFwcGxpZXMsIGFu ZCBpZiB0aGUgc3Bva2VzIGRvbid0IG5lZWQgdG8ga25vdyBhYm91dCBvdGhlciBzcG9rZXMsIGRv bid0IHRlbGwgdGhlbS4NCj4NCj4gSG9sZCBvbi4gIEkgdGhvdWdodCBpdCB3YXMgdGhlIE1BQyBh ZGRyZXNzIG9mIHRoZSBmYXIgc2lkZSByb3V0ZXIgKG90aGVyd2lzZSBpdCB3b3VsZCBzdGlsbCBu ZWVkIHRvIGFycCkuICBZb3VyIGNvbW1lbnQgLS0tIHRoZSBMT0NBTCBtb2RlbSB3b3VsZCBncmVh dGx5IGNoYW5nZSB0aGUgaXNzdWUgaW4gbXkgbWluZCAtLS0gYnV0IGhvdyBkb2VzIGtub3dpbmcg YSBsb2NhbCBNQUMgaGVscCBMMyBjb252ZXJnZSBhbnkgZmFzdGVyIC0gdGhhdCB3b3VsZCBtZWFu IGl0IHN0aWxsIG5lZWRzIHRvIGFycCBvciBtY2FzdCBoZWxsbyB0byBmaW5kIGZhciBzaWRlIGd1 eXMgc28gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlbiBob3cgdGhlICdmYXN0LXN0YXJ0JyBzdHVm ZiB3b3JrcyB5b3Ugd2VyZSBkaXNjdXNzaW5nIGFzIHRoZSBwb2ludCBvZiB0aGlzLi4uLi4NCj4N Cj4gSW4gdGhpcyBkaWFncmFtIGJlbG93Og0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8LS0tLS0gIE1ETTEgLS0tLSBSVFIxIC0tLSBORVQxDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCj4gVXBSdHIgLS0tLS0gICBTYXRIVUIgICAtLS0tLS0gIE9VVEVSU1BBQ0UgLS0tLS0t LS0tLSAgIE1ETTIgLS0tLSBSVFIyIC0tLSBORVQyDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tICBNRE0zIC0tLS0gUlRSMyAtLS0g TkVUMw0KPg0KPg0KPiBMZXQncyBzYXkgUlRSMSwgUlRSMiwgYW5kIFJUUjMgYWxsIHdhbnQgdG8g bWFrZSBhIFtPU1BGfEVJR1JQfEJHUF0gbmVpZ2hib3IgdG8gVXBSVFIuICBVUFJUUiB3YW50cyAz IG5laWdoYm9ycy4gIFRoZXJlIGFyZSAyIHZsYW5zIG9uIGVhY2guDQoNCipCeSBkZWZpbml0aW9u KiwgVXBSdHIgaW4gdGhpcyBjYXNlIGhhcyA2IG5laWdoYm9ycywgbm90IDMuIEVhY2ggVkxBTiBp cyBhIG5laWdoYm9yLg0KDQpbQlNTXSAtIFRoYXTigJlzIHdoYXQgSSBleHBlY3RlZC4NCg0KPg0K PiBXaGF0IGRvZXMgTURNWCBoYXZlIHRvIHRlbGwgUlRSWCB2aWEgRExFUD8gICBIb3cgbWFueSBN QUMgQWRkcmVzc2VzIChNdWx0aXBsZSBWTEFOUykgYW5kIHdoaWNoIG9uZXM/DQoNClRoYXQncyB0 aGUgcnViLiBNRE0xLCBmb3IgZXhhbXBsZSwgY2FuIHRlbGwgUlRSMSAqb25seSogYWJvdXQgVXBS dHIuIChTcGVjaWZpY2FsbHksIHRoZSBWTEFOUyBvbiBVcFJ0cikuIFNvLCB3aGlsZSBVcFJ0ciBo YXMgNiBuZWlnaGJvcnMgKGJ1dCB3ZSd2ZSBhbHJlYWR5IHNhaWQgdGhlIGh1YiBpc24ndCB0aGUg cHJvYmxlbSksIFJUUjEgb25seSBzZWVzIDIuDQoNCg0KW0JTU10gLSBSaWdodC4gdGhhdOKAmXMg d2hhdCBJIHdhcyBleHBlY3RpbmcgdGhlIGFuc3dlciB0byBiZS4gIEJ1dCB0aGVuIGl0IGlzbuKA mXQgdGhlIGxvY2FsIE1BQyBhZGRyZXNzIFJUUjEgbmVlZHMsIGl0cyBVUFJUUiBNQUMgQWRkcmVz cyAtIGhlIGlzIHRlbGxpbmcgaGltIGFib3V0IHRoZSBSRU1PVEUgbWFjLCBub3QgbG9jYWwuLi4g d2hpY2ggbWVhbnMgdGhlIE1ETXMgd291bGQgbmVlZCB0byBiZSBjb25maWd1cmVkIHRvIGtub3cg d2hhdCB0aGF0IGlzIChwZXIgVkxBTiAtIGV2ZW4gdGhvdWdoIGl0bGwgbW9zdCBsaWtlbHkgYWx3 YXlzIGJlIHRoZSBzYW1lKS4NCg0KTm93IGlmIHdlIHdhbnQgTkVUMSB0byB0YWxrIHRvIE5FVDIg LSB0aGVuIEknbSBhc3N1bWluZyB0aGUgUlRSMiBtYWMgaGFzIHRvIGJlIHRvbGQgdG8gUlRSMSBh cyB3ZWxsIHZpYSBETEVQIHRvby4gQ29ycmVjdD8gIFNvIHRoZW4sIGluc3RlYWQgb2YgbGV0dGlu ZyB0aGUgUlRSTiBmaW5kIFJUUk4nIG5hdHVyYWxseSB0aGUgd2F5IGEgYnVuY2ggb2Ygcm91dGVy cyBvbiBhbiBJR1Agd291bGQsICBNRE1OIHdvdWxkIGhhdmUgdG8gdGVsbCBSVFJOIGFib3V0IHRo ZSBlbnRpcmUgc2V0IG9mIFJUUnMgKHRoYXQgYXJlbid0IGhpbXNlbGYpLg0KDQpUaGF0J3Mgd2hh dCBJJ20gaGVhcmluZyBmcm9tIHRoaXMgY29udmVyc2F0aW9uLi4uIHlvdSBoYXZlIHRvIHRlbGwg dGhlbSBFVkVSWSBzcGVjaWZpYyBkZXN0aW5hdGlvbi4gIE5vdyBhbGwgdGhlIHN1ZGRlbiwgaW4g dGhpcyBWUExTIGFyY2hpdGVjdHVyZSBhbmQgdXNpbmcgRExFUCwgdGhlIE1ETXMgaGF2ZSB0byBt YWludGFpbiBhIE1BQyB0byBNRE0gbWFwIHRoYXQgY291bGQgYmUgSFVHRS4gIEkgZG9uJ3QgdGhp bmsgdGhpcyBpcyB0aGUgcGFydCB0aGF0IHNjYWxlcy4NCg0KSWYgSSdtIGluIFZQV1MgbW9kZSAo TkVUMSBjYW4ndCBzZWUgTkVUMikgdGhlbiBJIGFncmVlIC0gaXQncyBub3QgdGhhdCBoYXJkIG9m IGEgcHJvYmxlbSB0byBzb2x2ZSAtIHRob3VnaCB0aGVyZSBzdGlsbCBuZWVkcyB0byBiZSBhZGRp dGlvbmFsIE9BTSBrbm93bGVkZ2Ugb24gdGhlIE1ETSB3aGljaCBicmVha3MgbXkgdHJhbnNwYXJl bmN5IGRlc2lnbiAtIGJ1dCBJIGNvdWxkIG1heWJlIGxpdmUgd2l0aCB0aGF0IGlmIGl0IHdhcyBh IGJvdW5kZWQgc2V0IG9mIHNheSAxMiBNQUNzICgjIG9mIFZMQU5zIGV4cGVjdGVkIHRvIGdldHRp bmcgcm91dGluZyBwZWVycyBvbiBwZXIgbW9kZW0gLSB3b3JzdCBjYXNlKS4NCg0KDQpBcmUgbXkg ZXh0cmFwb2xhdGlvbnMgaGVyZSBjb3JyZWN0Pw0KDQpUaGFua3MsYnJpYW4NCg0KDQpTdGFuDQoN Cg0KPg0KPg0KPiBOb3cgd2hhdCBpZiB3aGlsZSB0aGUgUkYgc3lzdGVtIGlzIG5vdCBNRVNILCBJ IGFtIGFsbG93aW5nIGhhaXJwaW5uaW5nIChWUExTIG1vZGUpLi4uLiBTbyBORVQxIGNhbiB0YWxr IHRvIE5FVDIgdmlhIFNhdEhVQi4gIFRoZW4gd2hhdCBkbyB0aGV5IGFsbCBoYXZlIGxlYXJuPw0K Pg0KPg0KPg0KPiBNYXliZSBhIGNvbmNyZXRlIGV4YW1wbGUgd2lsbCBoZWxwIHRoaXMgc2luayBp bi4NCj4NCj4gVGhhbmtzLA0KPiBCcmlhbg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3 YXJlLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDI1LCAyMDE0IDEwOjI5IEFNDQo+IFRvOiBT bnlkZXIsIEJyaWFuOyBIZW5uaW5nIFJvZ2dlDQo+IENjOiBtYW5ldEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSRTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQDQo+DQo+IElubGlu ZSBjb21tZW50cy4uLi4NCj4NCj4+PiBBcyBJIHNlZSBpdCwgeW91ciBwcm9ibGVtIGlzIGFsb25n IHRoZSBsaW5lcyBvZiAiT01HLCBJIGhhdmUgMTAsMDAwJ3Mgc3Bva2VzIGFuZCBJIGNhbid0IGhh dmUgYSBtYXN0ZXIgbGlzdCBvZiBzcG9rZSByb3V0ZXIgTUFDcywgYW5kIEkgZG9uJ3Qgd2FudCB0 byByZXBvcnQgMTAsMDAwJ3MgRExFUCBzZXNzaW9ucyBldmVyeXdoZXJlIHdoZW4gc3Bva2VzIGNh biByZWFsbHkgb25seSB0YWxrIHRvIHRoZSBodWIiLiAgQW5kIG15IGFuc3dlciBpcywgIllvdSBk b24ndCBoYXZlIHRvIHJlcG9ydCBldmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUsIGFuZCB5b3UgY2Fu IGxlYXJuIHRoZSBNQUNzIGF0IHJ1bnRpbWUuIg0KPg0KPj4gWWVzLCB0aGF0IGlzIGEgY29uY2Vy biBvZiBtaW5lLi4uIGJ1dCBub3QgdGhlIG9ubHkgb25lLiAgSSB1bmRlcnN0YW5kIEkgb25seSBo YXZlIHRvIHJlcG9ydCB3aGF0IEkgd2FudCB0b28gYnV0IEknbSBhbHNvIGNvbmNlcm5lZCB3aXRo IHRoZSBub3Rpb24gSSBjYW4gYXV0by1sZWFybiBpdC4gIEhvdyB3b3VsZCBJIGtub3csIGluIGEg VlBMUyBuZXR3b3JrIHdoaWNoIG1hYyBpcyB0aGUgdXBzdHJlYW0gcm91dGVyPyBJIGNvdWxkIGJl IGludW5kYXRlZCB3aXRoIE1BQ3MgZnJvbSBhbGwgb3ZlciB0aGUgbmV0d29yay4gTWF5YmUgc29t ZSBJJ2QgY2FyZSBhYm91dCBhbmQgc29tZSBJIHdvdWxkbid0LiAgQnV0IEkgY2VydGFpbmx5IGNv dWxkbid0IHRyYWNrIHRoZW0gaW5kaXZpZHVhbGx5LiBJIGhhdmUgbm8gaWRlYSBvZiBhbm90aGVy IG1vZGVtcyBzdGF0ZS4gIEkgb25seSBrbm93IE1ZIHN0YXRlIGluIHJlbGF0aW9uIHRvIHRoZSBo dWIgLSBJRTogYW0gSSBpbiBuZXR3b3JrIG9yIG5vdC4gIEFsc28gcmVjb2duaXplIHRoYXQgaWYg SSBoYXZlIGEgaHVuZHJlZCB0aG91c2FuZCBNQUMgYWRkcmVzc2VzIGFuZCBJIGhhZCB0byB0cmFj ayB0aGVtIGFsbCAtLSB3ZWxsIGEgY29tbW9uIGRlc2lnbiB3aXRoIG91ciBuZXR3b3JrcyBpcyBm b3IgcGVvcGxlIHRvIHVzZSBtdWx0aXBsZSBTVk5zICh2bGFucy9xaW5xcykgdGFncyBQRVIgbW9k ZW0uICBNYW55IGRlc2lnbnMgaGF2ZSAxMiBlYWNoLiBPdXIgbmFtZXNwYWNlcyBhcmUga2VwdCBz ZXBhcmF0ZWx5Li4uLiBzbyBhIGh1bmRyZWQgdGhvdXNhbmQgbW9kZW1zIHdpdGggMTIgdmxhbnMg d291bGQgYmUgMS4yIE1JTExJT04gbWFjcyB0aGF0IGNvdWxkIHBvdGVudGlhbGx5IGJlIHNlZW4u DQo+DQo+IEFoLWhhISEgVGhlIERMRVAgZGVzdGluYXRpb24gTUFDIGlzIGRlZmluZWQgdmVyeSBz cGVjaWZpY2FsbHkgYXMgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2UgdGhhdCB0aGUg cm91dGVyIGlzIHVzaW5nIGZvciB0aGUgVENQIHNlc3Npb24gdG8gdGhlIGxvY2FsIG1vZGVtLiAg VGhlIHJvdXRlciBtYXkgaGF2ZSBhIGJpbGxpb24gb3RoZXIgTUFDIGFkZHJlc3NlcywgYnV0IG9u bHkgdGhhdCBvbmUgaXMgaW1wb3J0YW50LiAgSW4gdGhlIHNwb2tlIGNhc2UsIHRoZSBzYW1lIGFw cGxpZXMsIGFuZCBpZiB0aGUgc3Bva2VzIGRvbid0IG5lZWQgdG8ga25vdyBhYm91dCBvdGhlciBz cG9rZXMsIGRvbid0IHRlbGwgdGhlbS4NCj4NCj4+IEdyYW50ZWQsIEkgZG9u4oCZdCB0aGluayB0 aGF0IHNjYWxlIGlzIGdvaW5nIHRvIGJlIHJvbGwgb3V0ICMxIG9mIERMRVAgdXNlIGNhc2UgLSBi dXQgd2UgZG8gaGF2ZSBjdXN0b21lcnMgb3BlcmF0aW5nIGF0IHRoYXQgc2NhbGUuICBJZiAnRExF UCcgZmVhdHVyZSBnZXRzIHJlbGVhc2VkIC0gdGhleSB3aWxsIHdhbnQgdG8gdXNlIGl0Lg0KPg0K PiBBYnNvbHV0ZWx5LCB3aGljaCBpcyB3aHkgSSBhbmQgb3RoZXJzIGFyZSBzcGVuZGluZyBzb21l IGN5Y2xlcyB0byBnZXQgdGhpcyBzb3J0ZWQuDQo+DQo+PiBObyBtb2RlbSBjdXJyZW50bHkgdHJh Y2tzIGFueSBNQUNzIGZyb20gdGhlIGh1YiBzaWRlIGZvciB0aGlzIHJlYXNvbiAtLSBhbmQgd2Ug ZG9uJ3QgbmVlZCB0b28gKHlldDopKS4NCj4NCj4gSG9wZWZ1bGx5IG15IGFuc3dlciBhYm92ZSB3 aWxsIGhhdmUgaGVscGVkPw0KPg0KPiBSaWNrDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJpY2sgVGF5bG9yIFttYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdh cmUuY29tXQ0KPiBTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTA6MDUgQU0NCj4gVG86IFNu eWRlciwgQnJpYW47IEhlbm5pbmcgUm9nZ2UNCj4gQ2M6IG1hbmV0QGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJFOiBbbWFuZXRdIFJlcXVlc3QgdG8gY29uc2lkZXIgZm9yIERMRVANCj4NCj4gVG9wLXBv c3RlZC4uLg0KPg0KPiBTb3JyeSBCcmlhbiwNCj4NCj4gSSB0aGluayBteSB1bmRlcnN0YW5kaW5n IG9mIHlvdXIgcHJvYmxlbSBtaWdodCBzdGlsbCBiZSB3cm9uZywgYnV0IEknbGwgbWFrZSBzb21l IHN1Z2dlc3Rpb25zIGFueXdheS4uLg0KPg0KPiBZb3UgZG9uJ3QgbmVlZCB0byBwcmVjb25maWd1 cmUgdGhlIHNwb2tlIHJvdXRlciBNQUMgdGhhdCBnZXRzIHNlbnQgdG8gdGhlIGh1YiBiZWNhdXNl IHlvdSBjYW4gbGVhcm4gaXQgZnJvbSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBzcG9rZSBETEVQIHNl c3Npb24uICBUaGVuIHdoZW4gYW4gUkYgbGluayBpcyBlc3RhYmxpc2hlZCwgeW91IHNlbmQgaXQg dXAgdG8gdGhlIGh1YiwgYW5kIGl0IGNhbiByZXBvcnQgaXQgdGhyb3VnaCBpdCdzIGxvY2FsIERM RVAgc2Vzc2lvbiwgYW5kIHZpY2UtdmVyc2EuDQo+DQo+IFlvdSBkb24ndCBuZWVkIHRvIHJlcG9y dCBhbGwgZGVzdGluYXRpb25zIGluIGFsbCBzZXNzaW9ucywgb25seSByZWxldmFudCBkZXN0aW5h dGlvbnMuICBTbyBpbiB0aGUgc3Bva2UgbW9kZW0sIHlvdSBvbmx5IG5lZWQgdG8gcmVwb3J0IHRo ZSBodWIgTUFDIGluIHRoZSBjb21tb24gY2FzZSwgdW5sZXNzIHlvdSBoYXZlIHR1cm5lZCBvbiBo YWlyLXBpbm5pbmcgZm9yIHNvbWUgc3Vic2V0IG9mIHNwb2tlcywgaW4gd2hpY2ggY2FzZSB5b3Ug b25seSBuZWVkIHRvIHJlcG9ydCB0aG9zZSBhZGRyZXNzYWJsZSBNQUNzIGFzIERMRVAgZGVzdGlu YXRpb25zLg0KPg0KPiBBcyBJIHNlZSBpdCwgeW91ciBwcm9ibGVtIGlzIGFsb25nIHRoZSBsaW5l cyBvZiAiT01HLCBJIGhhdmUgMTAsMDAwJ3Mgc3Bva2VzIGFuZCBJIGNhbid0IGhhdmUgYSBtYXN0 ZXIgbGlzdCBvZiBzcG9rZSByb3V0ZXIgTUFDcywgYW5kIEkgZG9uJ3Qgd2FudCB0byByZXBvcnQg MTAsMDAwJ3MgRExFUCBzZXNzaW9ucyBldmVyeXdoZXJlIHdoZW4gc3Bva2VzIGNhbiByZWFsbHkg b25seSB0YWxrIHRvIHRoZSBodWIiLiAgQW5kIG15IGFuc3dlciBpcywgIllvdSBkb24ndCBoYXZl IHRvIHJlcG9ydCBldmVyeXRoaW5nLCBhbGwgdGhlIHRpbWUsIGFuZCB5b3UgY2FuIGxlYXJuIHRo ZSBNQUNzIGF0IHJ1bnRpbWUuIg0KPg0KPiBDaGVlcnMsDQo+IFJpY2sNCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBTbnlkZXIsIEJyaWFuIFti c255ZGVyQGlkaXJlY3QubmV0XQ0KPiBTZW50OiAyNSBKdWx5IDIwMTQgMTQ6MzcNCj4gVG86IEhl bm5pbmcgUm9nZ2UNCj4gQ2M6IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSRTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZvciBETEVQDQo+DQo+IEVtYmVkZGVk Li4uLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5nIFJv Z2dlIFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDI1LCAy MDE0IDI6MzYgQU0NCj4gVG86IFNueWRlciwgQnJpYW4NCj4gQ2M6IFJpY2sgVGF5bG9yOyBtYW5l dEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21hbmV0XSBSZXF1ZXN0IHRvIGNvbnNpZGVyIGZv ciBETEVQDQo+DQo+IE9uIEZyaSwgSnVsIDI1LCAyMDE0IGF0IDEyOjUxIEFNLCBTbnlkZXIsIEJy aWFuIDxic255ZGVyQGlkaXJlY3QubmV0PiB3cm90ZToNCj4+IFtCU1NdIOKAkyBBbmQgSSBndWVz cyBJIGFtIGxvb2tpbmcgZm9yIHNvbWV0aGluZyBkaWZmZXJlbnQuICBJ4oCZbSBsb29raW5nIGZv ciBsaW5rIHN0YXRlIG5vdGlmaWNhdGlvbnMgKHdpdGggbWV0cmljcykgdG8gIC0gYW5kIHRoaXMg aXMgYSBkaWZmZXJlbnQgIzIg4oCTIGFsbG93IGEgcm91dGluZyBwcm90b2NvbCB0byBiZSB0dW5l ZCBmb3IgbWluaW11bSBLRUVQIEFMSVZFIHRpbWVycyB0byBtaW5pbWl6ZSBiYW5kd2lkdGggdXNh Z2UgdG8gY29uc2VydmUgdmVyeSBleHBlbnNpdmUgYW5kIGxpbWl0ZWQgYmFuZHdpZHRoLiAgSW4g YSBzYXRlbGxpdGUgbmV0d29yaywgdGhlcmUgaXMgbm8gbmVlZCBmb3IgZmFzdC1zdGFydHMsIEwx IGNvbnZlcmdlbmNlIGNhbiAoYW5kIGluIGEgc3VpdGFibHkgc2l6ZWQgbmV0d29yayB3aWxsIHRh a2Ugc2Vjb25kcykuICBIb3dldmVyLCBiZWNhdXNlIG1vZGVtcyB0ZW5kIHRvIHN0YXkgaW4gbmV0 d29yayBxdWl0ZSBzdGFibHkgKHRyZWVzIGFuZCBidWlsZGluZ3MgZG9u4oCZdCBnZXQgdGhlIHdh eSBvZnRlbiBpbiB0aGUgb2NlYW7imLopLCB0aGUgYnVpbGRpbmcgb2YgYWRqYWNlbmNpZXMgZG9l cyBub3QgaGFwcGVuIGFsbCB0aGF0IG9mdGVuLiBJdOKAmXMgd2F5IG1vcmUgaW1wb3J0YW50IHRv IG1lIHRvIGNvbnNlcnZlIGJhbmR3aWR0aCBhbmQgYmUgdHJhbnNwYXJlbnQuDQo+DQo+IEkgbXVz dCBhZG1pdCBJIHN0aWxsIGZhaWwgdG8gc2VlIHdoeSBhIHNwZWNpYWwgY2FzZSBpcyBldmVuIG5l Y2Vzc2FyeS4NCj4NCj4gW0JTU10gLSBQZXJoYXBzIG5vdCBuZWNlc3NhcnkgLSBidXQgSSdtIHZl cnkgY29uY2VybmVkIHdpdGggdHJ5aW5nIHRvIG9wdGltaXplIGZvciBzY2FsZSBhbmQgdHJhbnNw YXJlbmN5Lg0KPg0KPiBXZSBhcmUgdGFsa2luZyBhYm91dCBhIG5ldHdvcmsgd2l0aCBodW5kcmVk IHRob3VzYW5kcyBjbGllbnRzIGNvbm5lY3RlZCB2aWEgc2F0ZWxsaXRlIHRvIGEgSHViIHN0YXRp b24uIFllcywgc28gd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgY2xpZW50cyBkb24ndCB0 YWxrIG1vcmUgdGhhbiBuZWNlc3NhcnkuDQo+DQo+IEJ1dCB5b3Ugc2FpZCB5b3VyIGNsaWVudCBz YXRlbGxpdGUgbW9kZW1zIGFyZSBhYmxlIHRvIHJlY2VpdmUgYnJvYWRjYXN0IHRyYWZmaWMuLi4g YW5kIG1heWJlIGV2ZW4gdW5pY2FzdHMgZGVsaXZlcmVkIHRvIGEgZGlmZmVyZW50IGNsaWVudC4g VGhpcyBtZWFucyBwdXNoaW5nIGluZm9ybWF0aW9uIGZyb20gdGhlIEh1YiB0byBhbGwgY2xpZW50 cyBpcyByZWFzb25hYmxlIGNoZWFwLg0KPiBbQlNTXSAtIFRoZXkgd29uJ3QgcmVjZWl2ZSB1bmlj YXN0IGZvciBzb21lb25lIGVsc2UuICBIRExDIGFkZHJlc3NpbmcgZGVtdXhlcyB0aGF0LiAgUHVz aGluZyBicm9hZGNhc3QgaXMgY2hlYXAuICBJRTogQVJQcyBjYW4gZmxvdyBmcmVlbHkgYW5kIGNo ZWFwbHkgb24gdGhlIGRvd25zdHJlYW0uDQo+DQo+IFRoaXMgbWVhbnMgdHJhbnNmZXJyaW5nIHRo ZSBNYWMgYWRkcmVzcyB0byBhIGNsaWVudCBpcyBkaXJ0IGNoZWFwLCBlc3BlY2lhbGx5IGlmIExh eWVyLTIgYXQgdGhlIEh1YiBpcyBhYmxlIHRvIHRlbGwgdGhhdCBhIG5ldyBjbGllbnQgY29ubmVj dGVkIHRvIHRoZSBzYXRlbGxpdGUuDQo+IFtCU1NdIC0gSW4gdGhpcyBjYXNlIHRyYW5zZmVycmlu ZyBhIG1hYyBhZGRyZXNzIGlzIGNoZWFwIC0gdGhlIGFycCdzIGRvIGl0IHRocm91Z2ggdXMgLS0g dGhvdWdoIHRoZSBtb2RlbXMgY3VycmVudGx5IGRvbid0IHRyYWNrIGFuZCByZWNvcmQgYW55IG9m IHRoZSBsZWFybnQgYWRkcmVzcyBPVEEuLi4gd2UganVzdCBsZXQgdGhlIGN1c3RvbWVyIGRldmlj ZXMgZG8gd2hhdCB0aGV5IHNob3VsZCBkbyBieSBhbGwgbm9ybWFsIGNvbnZlbnRpb25zLiAoQVJQ LCB0aW1lcnMsIGV0YykuICBNb2RlbXMgaGF2ZSBubyBub3Rpb24gb2Ygd2VhdGhlciBvciBub3Qg YW5vdGhlciBtb2RlbSBpcyBpbiBvciBvdXQgb2YgbmV0d29yay4gIE5vIHN0YXIgc3lzdGVtIHdv dWxkLiBUaGV5IGp1c3QgdHJhY2sgdGhlbXNlbHZlcy4gU28gaWYgTUFDIGFkZHJlc3NlcyBhcmUg c3VwcG9zZWQgdG8gYmUgc3RvcmVkIGFuZCBtYW5hZ2VkIGJ5IHRoZSBtb2RlbSBmb3IgRExFUCBt YW5hZ2VtZW50IGF1dG9tYXRpY2FsbHksIHdlIGEpIGFyZW4ndCB0cmFuc3BhcmVudCBhbnltb3Jl IGIpIEhhdmUgYSBzY2FsZSBwcm9ibGVtIG1hbmFnaW5nIGFsbCB0aG9zZSBtYWNzIGMpIElmIHRo ZXJlIGFyZSBtb3JlIG1hYyBhZGRyZXNzZXMgKG5vdCByb3V0ZXJzIHdlIHdvdWxkIGNhcmUgYWJv dXQgdmlhIGRsZXApIGhvdyBpcyBhIHRyYW5zcGFyZW50IHN3aXRjaCBzdXBwb3NlZCB0byAiS05P VyIgd2hpY2ggbWFjIGFkZHJlc3MgaXMgdGhlIHNwZWNpYWwgb25lIHRoYXQgc2hvdWxkIGJlICdz ZXR1cCcgYXMgdGhlIGRsZXAgdGFyZ2V0LiAgSSB0aGluayB0aGF0IHdvdWxkIHJlcXVpcmUgc29t ZSBzcGVjaWFsIGNvbmZpZyB0aGF0IHRoZW4gaGFzIHRvIGJlIG1hbmFnZWQgKGFsc28gYnJlYWtp bmcgdHJhbnNwYXJlbmN5KSBhbmQgY3JlYXRpbmcgT0FNIGFuZCBjaGFuZ2UgbWFuYWdlbWVudCBp c3N1ZXMuIFJlbWVtYmVyIHRoZSBMQU4gaXMgbm90ICdvdXInIGVxdWlwbWVudCwgc28gYWxsIHRo ZSBzdWRkZW4gb25lIHdvdWxkIGhhdmUgdG8gZ2V0IGFuZCBtYW5hZ2UgbWFjIGFkZHJlc3NlcyBm b3IgYWxsIHRoZXNlIHNpdGVzLiAgV2UgYXJlIGdvaW5nIEwyIGluLW9yZGVyIHRvIGhlbHAgdXMg YW5kIG91ciBjbGllbnRzIG5vdCB3b3JyeSBhYm91dCBlYWNoIG90aGVyJ3MgZXF1aXBtZW50IGFu ZCBuZXR3b3JraW5nLg0KPg0KPg0KPiBXaGF0IGlzIHRoZSB0eXBpY2FsIHVwdGltZSBvZiBhIGNs aWVudD8gQW5kIHdoYXQgcGVyY2VudGFnZSBvZiB0cmFmZmljIGdvZXMgZnJvbSB0aGUgSHViIHRv IHRoZSBjbGllbnRzPyBBIHJvdWdoIGd1ZXNzIHdvdWxkIGJlIGdyZWF0IHRvIGJldHRlciB1bmRl cnN0YW5kIHlvdXIgcHJvYmxlbS4NCj4gW0JTU10gLSBUeXBpY2FsIHVwdGltZSB3b3VsZCBiZSBt ZWFzdXJlZCBpbiBmcm9tIGhvdXJzIChNYXliZSBhIHBsYW5lIG1vdmluZyBhY3Jvc3Mgc2F0ZWxs aXRlIGZvb3RwcmludHMpIHRvIGhvcGVmdWxseSB5ZWFycyAtIGEgc3RhdGlvbmFyeSBtb2RlbS4g IFRob3VnaCBwcmFjdGljYWxseSB0aGF04oCZcyBtYXliZSBtb3JlIG5vcm1hbGx5IG1vbnRocyBk dWUgdG8gd2VhdGhlciwgdXBncmFkZXMsIGV0Yy4NCj4NCj4gSGVubmluZyBSb2dnZQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWls aW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldA0KDQo= --_002_84585478AABBBF4B9DF597FC0F84AF7343048C98VAUSMBX03idirec_ Content-Type: image/png; name="Capture.PNG" Content-Description: Capture.PNG Content-Disposition: attachment; filename="Capture.PNG"; size=5630; creation-date="Mon, 28 Jul 2014 15:23:11 GMT"; modification-date="Mon, 28 Jul 2014 15:23:11 GMT" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAkAAAACeCAYAAADaMbVAAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAABWTSURBVHhe7d2LkaO6FgXQjssBOR5H08lMMIwx YH4CJLcxwlq3auq9mqZBWkfARnzmp/r5qfxhYAwYA8aAMWAMGAMljYGfR2f9R4AAAQIECBAoReCe fQSgUoqtnwQIECBAgEAjIAAZCQQIECBAgEBxAgJQcSXXYQIECBAgQEAAMgYIECBAgACB4gQEoOJK rsMECBAgQICAAGQMECBAgAABAsUJCEDFlVyHCRAgQIAAAQHIGCBAgAABAgSKExCAiiu5DhMgQIAA AQICkDFAgAABAgQIFCcgABVXch0mQIAAAQIEBCBjgAABAgQIEChOQAAqruQ6TIAAAQIECAhAxgAB AgQIECBQnIAAVFzJdZgAAQIECBAQgIwBAgQIECBAoDgBAai4kuswAQIECBAgIAAZAwQIECBAgEBx AgJQcSXXYQIECBAgQEAAMgYIECBAgACB4gQEoOJKrsMECBAgQICAAGQMECBAgAABAsUJCEDFlVyH CRAgQIAAAQHIGCBAgAABAgSKExCAiiu5DhMgQIAAAQICkDFAgACBscC/26X6udyqf2AIEPheAQHo e2urZwQIvCYgAL3m5rcInEpAADpVuTSWAIEPCJwtAD3aWx/Mfy7VbWXa6vdaL3P/M5jd6n+3/dlj PT/VJbCiv2znWbZ/t+pSb+P6+4FKpm0ibHGt+pb+q26XsVPjPvjT9mt7XZO2ZeDSt3nY57adv9fZ +FoaO834irc6bGwIQGk7iKUJEPh+gXMGoEt1qU/OS8HicYJtl5kFoMkJrzsZ/4z/vjnhvbadetQ8 A1jWAWjc56bNC8EyEAq6vaOxiltXLi7DQDMLwIsBKBCWQoeIFavDxoYA9P0Hcz0kQCBN4JwB6Frd Aifd0Qn5Hnxu9Ql9KwDVvxSYkehO6q9vpw4S7cxAtjNA4TAYbG5iAOpMh+vqQmUOLuP6TkLfjgHo MAMBKO3AaGkCBL5f4KwB6Pd+s+YavH3V/H194n3MNsQEoOeMTR8I+lmN9O30o0YACme/412m9R3N Ju4YgA4bGwLQ9x/M9ZAAgTSB8wagecBpJnP62zEpAeielka3f9bWs7Wdw05yCaWf37bqnmNZuM2T NAO0sa7umZkDZ8aG/e9nZVpAAShhJFmUAAECJxU4cwBqQksz29P815x4u2c63hWAUrdzngAUfqg5 OJQ3A1DCujILQN24ec4WRj8Enf681GFjwwzQSY/Qmk2AwG4CwQDUBov+jZ92VmDvv4/o5XjmYnIr ZXLielsAmp6wN7aTfJI7wHU6A9Q9FLw4KbMZgKa3D4fBdFrYyFtg73IJjKvZDNgwTJsBitgTLUKA AIGTC5x6Bqie82nf1qrfZH8EnsEZPCUANW8nhZ4BaueWEraTHIAOGEOLt8CWPoqZEIBmMyqz/kUG oB1dVvsvAO0ob9UECBDIRODsAegee5qHoa/Xxzd3hjMY8QGoWccwPM1PkPHbOWcAurd67fXtpAC0 sa7sboG1FWvfBrzex9L0cwChV/0Xd+GN1+DbSN18Z+lTz0G5BZbJEVczCBDIRuD8AWjwzZ3J7EVU AOpegZ/87vK3bcZvltWFnG7ntAGoDZPBk3JqAFpbV64BqKtl4EObAlA2hywNIUCAwHsEviEAdd+c mX7QLhyA5l83Dl2EB094bVh6dTtbX69+T0Xj1rJ0Qp/eCnyuLTkAdcF0/mzQ7IvSG1/1jutR2lLL gaadDZy0qXtGatb20C3DTavQF7bXv2ye1rvA0maA/kxoBQQIfJnA2QLQl/HrDoHPCAhAn3G2FQIE ziMgAJ2nVlpK4GUBAehlOr9IgMCXCghAX1pY3SIwFBCAjAcCBAgQIECgOAEBqLiS6zABAgQIECAg ABkDBAgQIECAQHECAlBxJddhAgQIECBAQAAyBggQIECAAIHiBASg4kquwwQIECBAgIAAZAwQIEBg LOA1eCOCQAECAlABRdZFAgSSBASgJC4LEzingAB0zrppNQEC+wkIQPvZWjOBbAQEoGxKoSEECGQi IABlUgjNILCngAC0p651EyBwRgEB6IxV02YCiQICUCKYxQkQ+HoBAejrS6yDBKpKADIKCBAgMBYQ gIwIAgUICEAFFFkXCRBIEhCAkrgsTOCcAgLQOeum1QQI7CcgAO1na80EshEQgLIphYYQIJCJgACU SSE0g8CeAgLQnrrWTYDAGQUEoDNWTZsJJAoIQIlgFidA4OsFBKCvL7EOEvAWmDFAgACBqYAAZEwQ KEDADFABRdZFAgSSBASgJC4LEzingAB0zrppNQEC+wkIQPvZWjOBbAQEoGxKoSEECGQiIABlUgjN ILCngAC0p651EyBAgAABAlkKCEBZlkWjCBAgQIAAgT0FBKA9da2bAAECBAgQyFJAAMqyLBpFgAAB AgQI7CkgAO2pa90ECBAgQIBAlgICUJZl0SgCBAgQIEBgTwEBaE9d6yZAgAABAgSyFBCAsiyLRhEg QIAAAQJ7CnQB6DewkcfHwH6uVehna21qfu9n8id9PXv2+9Pr/r2OPa6pqAsNXq7Rv+p2uW9zsKG1 eoZ+po5j9KBHoJDxzm2NZvvKYKy06w/X4r7c5Vb9a5uZUq+18Ziynuq+9cc4u/dhbUzP13mpbl3D 7+2P6d+n99mzb683HVtP+/UcC5tj6ae6DIs2G3fp26nuZ5frZPy/69j4rvpt7w9/3Y9D58Z8XPr+ B9r5e73v+yn7crzVR8bGfgFojNXsZJMdJID3rkGbz3ragg8OLk1hEwPhgtX+AShUx8S251OMF1vS 7bTTA3x3kBp7xAegSXNW9oeYi5HQMvP9bns8ztfT9X/pAHitrvX+vXDmCu77/27VZbAPxPTvxeIV +2uN6aW6TC6ERiCPOrTLzALQpN6PZevjeGi8v7ademwMh00XxnIKQXH71UA1cT8O7R85uQwD4CwA LwagyHPEitVHDD4VgO6XeI+dZzSwiwhAzUkydOWUdGTOJABVj3asX+0n9esEC3cnksDFbz118RjX w/rmFIDm+932eAy2P9DPunSPg3e9Uz/Gxfygt2o3qL0A9P4doTO9rczkd//kx62u41YAqpvYhaDA zPIr25n1OrD+98ukrXFtfwgGtcQAFDw3Tpt4oMt4HG1PYiTtyykZYA+D1AA0PuD1U/XDgRAzYKZT 8PVJtTuJdNtYnXpLG8MHLt3OEqxe0synBUNXRcPbip3Vp2eAygtA81uJkxtjzS2gmJPH81bPwtVR 6oFzMqpj9rvntPLKeIwPQM3YblYVClah2abwrph00Dxwbz7TpnvTpdDb1+9xzI0cw82xux/Df9mO ANSHyvVTRDv7dsDU2LS+o5neHWeAPjI2XgpA9S/NdpY+GUZPoS8c8EP3pM904JmH9+6ZqNA98uYk MQ+Q20m7uSBbek7rXc8ADU/W8Se0M9dr3Pb0GZN8ZoDCt676C4vwMxvB9odm/iazPtOTaDgUCUCf 2jeGdZzXZnzsSAlAzUVQ+Hifup2ZRYYzzNHns64zSRcyK7eXhzgHugz7P5vR/WQA2sPgpQA0ep5l fvU3vGf4nLUIJdfVABR5D/FTR5O/bud5/3z7gdGU24VB6+FDhW9/CPoNt/P+avnJ31+49TNswvQA uV8Amr5YEPHw4dIV48p4nLe/ncUc7feBmbHp/hxh1zmGx/H6Q7WfHAZn3NaojrOTR1O/0ax75AzQ WgCazxCvb2drNjUH9+jzWXQAmuzHm7M6x154jo8Hk7ZEPwS9sC9H3wLbyeA9AWh8MAyfEALPjawF oFnImuwK7Q7d3xZqA9Pef//nPbJ/ur8f9+En42Oel/rsDFB9p6N5BmjpgddNnr3rk7r+rQZHnMSX bwnMV756qyfpynF73d2Be/34Oh+PUQf80DN909tgEXbjAJRw0ZNa57MvvzVOAz8Pnri6wTAZa++a AXq+FRi5nfEkR+BFmWm/9q7jpmP/xuLifpWwH8fso8GXCPZyiej/KOR+aAYoyuCFfeR+MqvqURd8 1T10sA5NcU4H/eKU4TTU/CUAvdLZbH5n+FxQ4BmhhAfGPx6AHhlo/iZINrRvb8jWM1zzK5P9ZoDW A0L0fjczGvdxNaS1v7s+89i1c+v5qb4hMdt8e2m/fIXhC9HmSvz5LGdrkBKAtgL/8DbJ1nb6SZOI mfGD6pW8XyUEoOe5c+GCP4e34lb7/4EAtKtBF4DCd6jGz/rU4y8cgMbPSQQPZqFBUXgAekw/h8LO TgFo7QHmrXv38yu1hKv1gw5c79rsauBbrFX4Tbnw/vM8C80/FTEKHKkB6LHDLq6z94nYf0eYK8Fm cqtl9szAQlEEoHeN1rVQ2db5ep29kRsfgOYXBEu3TC8R26lbGzML8n6d+DVGn8/6NJe2Hy/so7m4 BPvfHffuNQ5/Byjy/LBxfNrdoAtA4W87zA/ioQeUt64ImnEROdOxGLLiB2xWS9YFnqT78XTe1GXh w3LBWw5pD0H3H60LfcdjXuu1gf/n1/qzKtJWY8Lf+wm9Etysaf3h43dMnYdaHA4Rk/G1OR7XxtQw qC19CmE6nju70DeU1l6c2KqJn28JLM7gT15ieRydY94C654bmxzP/r6dvD+rEbVfDYuRNAMUPjfu fuLfGjyDny9dnPRvcoeeRfx7APqIwfMW2ORLxUtfgH7uKKN7sXEAoSvpHnH5gbyEWmW56Px2wWRw TO5rX3+Hrxf3XQpZpdwC6y9Q4r7SvXSbo6zwE/bvnj1be75mWK9m+Y2DwuaBc1q3uFeXwxcow3XF f8jxebJc6cvWft5YRDzAHThRZ7mDZ9qolAuYcACaj7fQeH99O/OvHffPdObzAPx6AIj7OnI3ROLW lZfL8jkmfHGzeHs8dJtv8Zj3IYPUfwtsdQo/0wOBZhEgQIAAAQIERgICkAFBgAABAgQIFCcgABVX ch0mQIAAAQIEUgMQMQIECBAgQIDA6QUEoNOXUAcIECBAgACBVAEBKFXM8gQIECBAgMDpBQSg05dQ BwgQIECAAIFUAQEoVczyBAgQIECAwOkFBKDTl1AHCBAgQIAAgVQBAShVzPIECHy7wONrtgv/QOW3 913/CBQjIAAVU2odJUAgUkAAioSyGIEzCwhAZ66ethMgsIeAALSHqnUSyExAAMqsIJpDgMDhAgLQ 4SXQAAL7CwhA+xvbAgEC5xIQgM5VL60l8JKAAPQSm18iQOCLBQSgLy6urhHoBAQgY4EAAQJjAQHI iCBQgIAAVECRdZEAgSQBASiJy8IEzikgAJ2zblpNgMB+AgLQfrbWTCAbAQEom1JoCAECmQgIQJkU QjMI7CkgAO2pa90ECJxRQAA6Y9W0mUCigACUCGZxAgS+XkAA+voS6yCBqhKAjAICBAiMBQQgI4JA AQICUAFF1kUCBJIEBKAkLgsTOKeAAHTOumk1AQL7CQhA+9laM4FsBASgbEqhIQQIZCIgAGVSCM0g sKeAALSnrnUTIECAAAECWQoIQFmWRaMIECBAgACBPQUEoD11rZsAAQIECBDIUkAAyrIsGkWAAAEC BAjsKSAA7alr3QQIECBAgECWAgJQlmXRKAIECBAgQGBPAQFoT13rJkDgjAJegz9j1bSZQKKAAJQI ZnECBL5eQAD6+hLrIAH/FpgxQIAAganA2QLQo7311ezPpbr9W67n77Ve5v7ncqu6xfrfbX/2WM9P dQms6C/bqarf6tquu2lreBtHjsawxfXe8u6/f9XtMnbq+vL832uz9Pa6unXm49K3edjntp2/19n4 Who7zfiKtzpsbJgBOnJ3s20CBHIUOGcAulSX+uTcnoBnrv9u1eUekB7LzALQ5IT3WLY+0Y//vjnh vbadOnwNm9adPJeae8S4aNo07nMTGheCZSAUPKNS5LpychkGmlkAXgxAgbAUKt6K1WEGAtARu5lt EiCQs8A5A9C1ugVOuqMT8j343OoT+lYAaqYwmhA0SChdQHhlO/N6NzMfoZmmo8ZGKAB1DsGglhiA Vtf17PRxLuP6TkLfjgHosLEhAB21q9kuAQK5Cpw1AP22t5nmoaI5qdYn8ceMRkwAuhenmf3or/D7 gLB0kl7eTnhGSgDKyWVa39Fs4icDUBu+dw/HAlCuh2DtIkDgKIHzBqB5wGkmc/pbOykB6J6ARrd/ 1taztZ1xLbvnQyJvn3xoIMxngDbamTQDFNPnmGX2wxj2v7vd+XwU7GMB6IMGAtB+g8maCRA4p8CZ A1ATWobP2zQnlO5q+l0BKHU79xg2eYA4r/DTB7jJQ85rDyltBqCYdeXjMg6Abbu62cLoh6DTn5c6 bGwIQOc8QGs1AQL7CQQDUBss+rd+2hP43n8f0c3gias7cU9OXG8LQF2gidzOtBvPB26XAsYBrtMZ oM0HtTcD0PT24fhB8FBpP+YS2PhsBmwYpj82AzR4g27vJ+QFoIiji0UIEChK4NQzQM9bXs2V+CPw DE4kKQFo+RmgZjgMb5NsbSc0gKbrP3qQLd4CGzwzNWpjQgB6znIsrWuw4qNcVvv/wQBUU3zEQAA6 epezfQIEchM4ewDqvqtyuV4fb3INL6TjA1D7fZrAW2D9d3Hah6EjtnPOAPQ4E7/tNfjVdWUZgB4p txlD9xpPPwcQfGtuaWdecwz8jgCU21FRewgQKELg/AGou4Iev/H1vLLeegusewV+Mlux/J2cre3U QSn0WvXKd4sOGGnhE/o8CD6bljQD9NBvPgb5DJV5uSwFmucHNCc1fE8AOtDADNABe5lNEiCQtcA3 BKDuyn36KnF4Bmj+dePQ4xdr38l5ZTu7v+acOMrWA0Dc15G7Tcau6/nMz+Ar2Ue5LAea7mvV4xAb avv0S+PxYXH7S+SJ5dxeXADaNrIEAQJlCZwtAJVVHb0l8CYBAehNkFZDgMDXCAhAX1NKHSGwLCAA GR0ECBAYCwhARgSBAgQEoAKKrIsECBAgQIDAWEAAMiIIECBAgACB4gQEoOJKrsMECBAgQICAAGQM ECBAgAABAsUJCEDFlVyHCRAgQIAAAQHIGCBAgAABAgSKExCAiiu5DhMgQIAAAQICkDFAgAABAgQI FCcgABVXch0mQIAAAQIEBCBjgAABAgQIEChOQAAqruQ6TIAAAQIECAhAxgABAgQIECBQnIAAVFzJ dZgAAQIECBAQgIwBAgQIECBAoDgBAai4kuswAQIECBAgIAAZAwQIECBAgEBxAgJQcSXXYQIECBAg QEAAMgYIECBAgACB4gQEoOJKrsMECBAgQICAAGQMECBAgAABAsUJCEDFlVyHCRAgQIAAAQHIGCBA gAABAgSKExCAiiu5DhMgQIAAAQICkDFAgAABAgQIFCcgABVXch0mQIAAAQIEBCBjgAABAgQIEChO 4BmA7v+n8oeBMWAMGAPGgDFgDBQyBv4DoghetFNsFnEAAAAASUVORK5CYII= --_002_84585478AABBBF4B9DF597FC0F84AF7343048C98VAUSMBX03idirec_-- From nobody Mon Jul 28 08:59:05 2014 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 C4D351A0334 for ; Mon, 28 Jul 2014 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5slBFycoWpdH for ; Mon, 28 Jul 2014 08:58:50 -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 80F4B1A03E3 for ; Mon, 28 Jul 2014 08:58:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,749,1400022000"; d="scan'208,217";a="390002702" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 28 Jul 2014 16:58:46 +0100 X-IronPort-AV: E=Sophos; i="5.01,749,1400022000"; d="scan'208,217"; a="66367494" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 28 Jul 2014 16:58:54 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Mon, 28 Jul 2014 16:58:54 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , manet , "" , manet-ads Thread-Topic: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs Thread-Index: AQHPqmaMr2jXtWmnY0aFPOP7noXFq5u1fWEAgAAbz6A= Date: Mon, 28 Jul 2014 15:58:38 +0000 Message-ID: References: <5BAD70D6-1E6E-4CF5-803B-54CF3B7BD4E5@thomasclausen.org> In-Reply-To: <5BAD70D6-1E6E-4CF5-803B-54CF3B7BD4E5@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1A664GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/C5pcL5b4ZufnwrboJV-R4h6wBfg Cc: Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 28 Jul 2014 15:58:58 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1A664GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks Thomas for this. I'm just going to pick up one point for this email = (not meaning that I'm disregarding the other points). o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to= quantify the computational load? I asked a crypto-wonk-colleague= , who said something to the effect of "the document is perfect= ly right, on this point, but I do not have a paper just off the top o= f my head with interesting data to offer". For that reason alone, = it'd be interesting if you did ;) Unfortunately, no I don't, though I must admit to not trying to look hard. = The last interested academic that I spoke to on this matter was interested = in our results, rather than providing any results himself. We have experimental results that I'm reasonably sure show faster signature= s and verifications than other forms of IBS we have implemented (at least t= wo others at various times). That's in large part because ECCSI does not us= e pairings (see the companion RFC 6508 for an algorithm that does) and the = expensive operations (both by repute and in our experience) are pairings an= d exponentiations of elements in the codomain of the pairing. However I don= 't have a set of crystal clear results comparing the signature only with no= thing else changed. In principle we could do this, but for various reasons = that would take longer than I have time to spare. (They weren't all created= for the same purpose.) Any results would also be dependent on the choice o= f crypto library, and even decisions made within the library. For example I= 've had a significant factor speedup using a different option within a libr= ary in one case. So, in short, that paragraph is about what I think I can say without steppi= ng where I couldn't back up comments. I'd like to strengthen it, but I thin= k that's where I can go. Anyone who has a reference (and I will look a bit further) please let me kn= ow. Non-paywalled references in strong preference. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen Sent: 28 July 2014 15:38 To: manet; ; manet-ads Cc: Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. On Jul 28, 2014, at 15:19, Thomas Clausen > wrote: Dear WG Chairs, Dear Chris, all, As the author indicated by email recently, he believes that draft-ietf-mane= t-olsrv2-management-snapshot is ready for WGLC. And, Ulrich just pointed out to me in private that the above should be "dra= ft-ietf-manet-ibs", of course - I thought I was being clever using email te= mplates, and all. Apologies, and thank you Ulrich for catching my screwup. Thomas As a reminder, this document aims for publication as a Proposed Standard. I have, therefore, reviewed the document carefully. In my opinion, the auth= or is right - in my opinion this document is ready for WGLC. Moreover, I believe that it is a highly important document for the WG to pr= oduce, as it fills a real need, and does so by relying on already-published= crypto RFCs, rather than by coming up with something esoteric. I have two issues, and handful nits, that I expect the author will consider= along with any other WGLC comments they may receive. Of course, if a new v= ersion is spun before WGLC is requested, then I'll gladly review that, also= . Point being: let's get a call started on this document, none of my nits a= nd issues are of the sort that should be blocking. One of the issues is "need a non-jetlagged ADs advice to be sure we do the = right thing", the other is - I think - a minor mix-up with a trivial editor= ial resolution and zero technical impact on this specification. Either way, for information, I include all issues and nits that I've found = in the below. Issues: o In my opinion, "Updates 7182" is inappropriate. What= this document does is: (i) only things permissible by = RFC7182, and (ii) makes registration from IAN= A registries set up by RFC7182 (noting, of course, that RF= C7181 doesn't "Updates 5444" when making registrations = for TC messages from the repositories set up by RFC5444 as a cas= e of precedent) Consequently, I believe that the abstract, introduc= tion, and document header, needs updates to reflect that this is not a= n update. Caveat Lector: I have bounced this around with the = author, and I think that the conclusion i= s that we need just a friendly ADs opinion - my understand= ing is that the author "wants this out, but wants = it done right, also", something to which I can but adhere. I believe that we should WG= LC the document. If the AD finds the time to address t= his issue during WGLC, great - otherwise, we can reflect t= his in the "Document Writeup" that the AD will consider w= ith the publication request - as this (imo) is procedural/ed= itorial, and certainly not technical. o Introduction, 4th paragraph: Isn't it RFC7183 which does shared-secret-key ICVs?= I just did a quick grep through of "shared" in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that ca= se. And "secret" is not mentioned anywhere in 7182 Nits: o Introduction, 1st paragraph: OLD: This specification extends the TLV defi= nitions therein by defining two new cryptograph= ic function code points that allow the use of an identity-based sign= ature (IBS) as an ICV. NEW: This specification defines two new cryp= tographic function code points from within the registries = set up by [RFC7182], that allow the use of an identity-based= signature (IBS) as an ICV. o Introduction, 2nd paragraph, 1st line: I took a double-take when I saw the parenthesis "(protocol participant)" - that seems a little odd,= and I am on a crusade against redundant and hard-to-parse terminology ;) I think that what is meant is "router, which is run= ning a routing protocol which is based on RFC5444", so could the d= ocument not say that? In any event, I do not see "protocol participant" d= efined or anywhere else, and so it seems unfortunate to *not* be explicit he= re. o Introduction, 3rd paragraph: OLD: Two options for the choice of identity = are supported (the two code points allocated). NEW: Two options for the choice of identity = are supported (as reflected by the two code points allocated). o Introduction, 7th paragraph: Caveating that using this introduces the danger tha= t "if you catch the trusted authority, then you're screwed" is awesome.= I see that this is repeated and reworded in the Security Consi= derations section, and I approve. Now, my question is then, if this should not be sta= ted in the Applicability statement, also? Something to the effect of that th= is applies to networks where all routers can (at some point) be in contact= with the TA (to be keyed), but that this can be off-line - and probabl= y should be off-line since the TA really, really should be protected. It might be argued that the forward-reference to Se= ction 6 captures this - I still think, that a few choice words in th= e applicability statement would help greatly. o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to= quantify the computational load? I asked a crypto-wonk-colleague= , who said something to the effect of "the document is perfect= ly right, on this point, but I do not have a paper just off the top o= f my head with interesting data to offer". For that reason alone, = it'd be interesting if you did ;) o Throw-away comment, I appreciate particularly the la= st paragraph of the introduction. o Section 4.1, first bullet OLD: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined there) uses the hash function w= ithin the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. NEW: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined in [RFC7182]) uses the hash fun= ction within the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. o While we are at it, it it crystal-clear to everybody= that "Section 4.2" in the bullet above is to *this* document, as not RFC7= 182? o Section 4.3, 2nd bullet There's a LOT of information embedded in this bulle= t, and reading it suggests that it, readability-wise, might benefit f= rom embedding a: ... ... o IANA Considerations: Given recent experiences in this WG and with reques= ting IANA registrations, may I suggest that this be modified = to say, more explicitly: 1) IANA is requested to reserve= ECCSI with description ___ and reference "This Specifi= cation" 2) IANA is requested to reserve= ECCSI-ADDR.... (similar) 3) The "Cryptographic Functions= Registry", defined in [RFC7182], with these regis= trations made, will look like Table 1, which replace= s Table 11 of [RFC7182] 4) Obviously, include in Table = 1 the registrations from RFC7182. 5) That this document does not = modify the expert review guidelines as set fo= rth in RFC7182 for future allocations. That's all. Thanks for writing this document, Chris. Respectfully, Thomas _______________________________________________ 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1A664GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Thanks Thomas for this. I= ’m just going to pick up one point for this email (not meaning that I= ’m disregarding the other points).

 <= /p>

   &nb= sp;        o          Introduction, 9th paragraph:

   &nb= sp;            =         Any [academic? otherwise] work that you can cite to quantify the =

   &nb= sp;            =         computational load? I asked a crypto-wonk-colleague, who said

   &nb= sp;            =         something to the effect of “the document is perfectly right, on this<= o:p>

   &nb= sp;            =         point, but I do not have a paper just off the top of my head with = ;

   &nb= sp;            =         interesting data to offer”. For that reason alone, it’d be inte= resting 

   &nb= sp;            =         if you did ;)

 <= /p>

Unfortunately, no I don&#= 8217;t, though I must admit to not trying to look hard. The last interested= academic that I spoke to on this matter was interested in our results, rather than providing any results himself.

 <= /p>

We have experimental resu= lts that I’m reasonably sure show faster signatures and verifications= than other forms of IBS we have implemented (at least two others at various times). That’s in large part because ECCSI does not use p= airings (see the companion RFC 6508 for an algorithm that does) and the exp= ensive operations (both by repute and in our experience) are pairings and e= xponentiations of elements in the codomain of the pairing. However I don’t have a set of crystal clear results = comparing the signature only with nothing else changed. In principle we cou= ld do this, but for various reasons that would take longer than I have time= to spare. (They weren’t all created for the same purpose.) Any results would also be dependent on the choice of cr= ypto library, and even decisions made within the library. For example IR= 17;ve had a significant factor speedup using a different option within a li= brary in one case.

 <= /p>

So, in short, that paragr= aph is about what I think I can say without stepping where I couldn’t= back up comments. I’d like to strengthen it, but I think that’s where I can go.

 <= /p>

Anyone who has a referenc= e (and I will look a bit further) please let me know. Non-paywalled referen= ces in strong preference.

 <= /p>

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

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

 <= /p>

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen
Sent: 28 July 2014 15:38
To: manet; <manet-chairs@tools.ietf.org>; manet-ads
Cc: Christopher Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs<= o:p>

 

 

*** WARNING ***=

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

 

On Jul 28, 2014, at 15:19, Thomas Clausen <thomas@thomasclausen.org> wrot= e:



Dear WG Chairs, 

Dear Chris, all,

 

As the author indicated by email recently, he believ= es that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 

 

 

And, Ulrich just pointed out to me in private that t= he above should be "draft-ietf-manet-ibs”, of course — I t= hought I was being clever using email templates, and all. Apologies, and th= ank you Ulrich for catching my screwup.

 

Thomas



As a reminder, this document aims for publication as= a Proposed Standard.

 

I have, therefore, reviewed the document carefully. = In my opinion, the author is right — in my opinion this document is ready for WGLC.

 

Moreover, I believe that it is a highly important do= cument for the WG to produce, as it fills a real need, and does so by relyi= ng on already-published crypto RFCs, rather than by coming up with somethin= g esoteric.

 

I have two issues, and handful nits, that I expect t= he author will consider along with any other WGLC comments they may receive= . Of course, if a new version is spun before WGLC is requested, then I̵= 7;ll gladly review that, also. Point being: let’s get a call started on this document, none of my nits and= issues are of the sort that should be blocking.

 

One of the issues is “need a non-jetlagged ADs= advice to be sure we do the right thing”, the other is — I thi= nk — a minor mix-up with a trivial editorial resolution and zero tech= nical impact on this specification.

 

Either way, for information, I include all issues an= d nits that I’ve found in the below.

 

Issues:

 

   &nb= sp;        o          In my opinion, “Updates 7182” is inappropriate. What thi= s document does is:

   &nb= sp;            =             &nb= sp;       (i)      &nb= sp;  only things permissible by RFC7182, and 

   &nb= sp;            =             &nb= sp;       (ii)      &n= bsp; makes registration from IANA registries set up by RFC7182<= /o:p>

   &nb= sp;            =             &nb= sp;            =        (noting, of course, that RFC7181 doesn’t “Updates 5444&#= 8221; 

   &nb= sp;            =             &nb= sp;             &= nbsp;      when making registrations for TC= messages from the repositories 

   &nb= sp;            =             &nb= sp;            =         set up by RFC5444 as a case of precedent)

   &nb= sp;            =         Consequently, I believe that the abstract, introduction, and document =

   &nb= sp;            =         header, needs updates to reflect that this is not an update.

   &nb= sp;            =        

   &nb= sp;            =         Caveat Lector: I have bounced this around with the author, and I =

   &nb= sp;            =             &nb= sp;            =        think that the conclusion is that we need just a friendly =

   &nb= sp;            =             &nb= sp;            =        ADs opinion — my understanding is that the author

   &nb= sp;            =             &nb= sp;            =        “wants this out, but wants it done right, also”, somethi= ng

   &nb= sp;            =             &nb= sp;            =        to which I can but adhere.

   &nb= sp;            =        

   &nb= sp;            =             &nb= sp;            =        I believe that we should WGLC the document. If the AD

   &nb= sp;            =             &nb= sp;            =        finds the time to address this issue during WGLC, great -=

   &nb= sp;            =             &nb= sp;            =        otherwise, we can reflect this in the “Document Writeup”=

   &nb= sp;            =             &nb= sp;            =        that the AD will consider with the publication request — as

   &nb= sp;            =             &nb= sp;            =        this (imo) is procedural/editorial, and certainly not technical.

 

   &nb= sp;        o          Introduction, 4th paragraph:

 

   &nb= sp;            =         Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quic= k

   &nb= sp;            =         grep through of “shared” in 7182, and found just a few mentions= , notably

   &nb= sp;            =         setting a side a value for key-id-length in that case. And “secr= et” is not

   &nb= sp;            =         mentioned anywhere in 7182

 

 

Nits:

   &nb= sp;        o          Introduction, 1st paragraph:

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       This specification extends the TLV definitions

   &nb= sp;            =             &nb= sp;       therein by defining two new cryptographic function code points that<= o:p>

   &nb= sp;            =             &nb= sp;       allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       This specification defines two new cryptographic function =

   &nb= sp;            =             &nb= sp;       code points from within the registries set up by [RFC7182], 

   &nb= sp;            =             &nb= sp;       that allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;        o          Introduction, 2nd paragraph, 1st line:

   &nb= sp;            =         I took a double-take when I saw the parenthesis 

   &nb= sp;            =         “(protocol participant)” — that seems a little odd, and I= am on a crusade

   &nb= sp;            =         against redundant and hard-to-parse terminology ;)

 

   &nb= sp;            =         I think that what is meant is “router, which is running a routing&nbs= p;

   &nb= sp;            =         protocol which is based on RFC5444”, so could the document not say

   &nb= sp;            =         that?

 

   &nb= sp;            =         In any event, I do not see “protocol participant” defined or an= ywhere else,

   &nb= sp;            =         and so it seems unfortunate to *not* be explicit here.

 

   &nb= sp;        o          Introduction, 3rd paragraph:

 

   &nb= sp;            =         OLD:

   &nb= sp;             = ;            &n= bsp;      Two options for the choice of identity are supported (the two code

   &nb= sp;            =             &nb= sp;       points allocated).

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (as reflected

   &nb= sp;            =             &nb= sp;       by the two code points allocated).

 

 

   &nb= sp;        o          Introduction, 7th paragraph:

   &nb= sp;            =         Caveating that using this introduces the danger that “if you catch th= e 

   &nb= sp;            =         trusted authority, then you’re screwed” is awesome. I see that&= nbsp;

   &nb= sp;            =         this is repeated and reworded in the Security Considerations section,<= /o:p>

   &nb= sp;            =         and I approve. 

 

   &nb= sp;            =         Now, my question is then, if this should not be stated in the Applicability=  

   &nb= sp;            =         statement, also? Something to the effect of that this applies to networks

   &nb= sp;            =         where all routers can (at some point) be in contact with the TA (to be=

   &nb= sp;            =         keyed), but that this can be off-line — and probably should be off-li= ne

   &nb= sp;            =         since the TA really, really should be protected.

 

   &nb= sp;            =         It might be argued that the forward-reference to Section 6 captures

   &nb= sp;            =         this — I still think, that a few choice words in the applicability st= atement

   &nb= sp;            =         would help greatly.

 

   &nb= sp;        o          Introduction, 9th paragraph:

   &nb= sp;            =         Any [academic? otherwise] work that you can cite to quantify the =

   &nb= sp;            =         computational load? I asked a crypto-wonk-colleague, who said

   &nb= sp;            =         something to the effect of “the document is perfectly right, on this<= o:p>

   &nb= sp;            =         point, but I do not have a paper just off the top of my head with = ;

   &nb= sp;            =         interesting data to offer”. For that reason alone, it’d be inte= resting 

   &nb= sp;            =         if you did ;)

 

   &nb= sp;        o          Throw-away comment, I appreciate particularly the last

   &nb= sp;            =         paragraph of the introduction.

 

   &nb= sp;        o          Section 4.1, first bullet

 

   &nb= sp;            =         OLD:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined there) uses the hash function withi= n the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;            =                length of N octets, as specified in Section 4.2.=

 

   &nb= sp;            =         NEW:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined in [RFC7182]) uses the hash functio= n within the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;            =                length of N octets, as specified in Section 4.2.=

 

   &nb= sp;        o          While we are at it, it it crystal-clear to everybody that “Sec= tion 4.2” in

   &nb= sp;            =         the bullet above is to *this* document, as not RFC7182?

 

   &nb= sp;        o          Section 4.3, 2nd bullet

   &nb= sp;            =         There’s a LOT of information embedded in this bullet, and reading it<= o:p>

   &nb= sp;            =         suggests that it, readability-wise, might benefit from embedding a:

   &nb= sp;            =             &nb= sp;       <list style=3D“hanging”>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Packet TLVs”>…</t>=

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Message TLVs”>…</t>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Address Block TLVs”>…</t&g= t;

   &nb= sp;            =             &nb= sp;       </list>

 

   &nb= sp;        o          IANA Considerations:

 

   &nb= sp;            =         Given recent experiences in this WG and with requesting IANA 

   &nb= sp;            =         registrations, may I suggest that this be modified to say, more<= /p>

   &nb= sp;            =         explicitly:

 

   &nb= sp;            =             &nb= sp;       1)      = ;   IANA is requested to reserve ECCSI with description __= _ 

   &nb= sp;            =             &nb= sp;            =        and reference “This Specification”

 

   &nb= sp;            =             &nb= sp;       2)      = ;   IANA is requested to reserve ECCSI-ADDR…. (simil= ar)

 

   &nb= sp;            =             &nb= sp;       3)      = ;   The “Cryptographic Functions Registry”, de= fined in 

   &nb= sp;            =             &nb= sp;            =        [RFC7182], with these registrations made, will look

   &nb= sp;            =             &nb= sp;            =        like Table 1, which replaces Table 11 of [RFC7182]

 

   &nb= sp;            =             &nb= sp;       4)      = ;   Obviously, include in Table 1 the registrations from

   &nb= sp;            =             &nb= sp;            =        RFC7182.

 

   &nb= sp;            =             &nb= sp;       5)      = ;   That this document does not modify the expert

   &nb= sp;            =             &nb= sp;            =        review guidelines as set forth in RFC7182 for

   &nb= sp;            =             &nb= sp;            =        future allocations.

 

That’s all. Thanks for writing this document, = Chris. 

 

 

Respectfully,

 

Thomas

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/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.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1A664GLKXM0002VGREEN_-- From nobody Mon Jul 28 09:06:11 2014 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 D9DA01A0367 for ; Mon, 28 Jul 2014 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VYkuq6bEwc_D for ; Mon, 28 Jul 2014 09:05:57 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC791A0362 for ; Mon, 28 Jul 2014 09:05:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D162D2406B2; Mon, 28 Jul 2014 09:05:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1185A2401A9; Mon, 28 Jul 2014 09:05:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C1D89541-B8DD-4108-AB75-709A4A6E73E0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Mon, 28 Jul 2014 18:05:37 +0200 Message-Id: <8D2A87A9-3296-4E44-B78C-BC5FB9E7F416@thomasclausen.org> References: <5BAD70D6-1E6E-4CF5-803B-54CF3B7BD4E5@thomasclausen.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GnmlRnR3j8c7_kotwU9t0bpLytU Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 28 Jul 2014 16:06:02 -0000 --Apple-Mail=_C1D89541-B8DD-4108-AB75-709A4A6E73E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chrism On Jul 28, 2014, at 17:58, Dearlove, Christopher (UK) = wrote: > Thanks Thomas for this. I=92m just going to pick up one point for this = email (not meaning that I=92m disregarding the other points). > =20 Sure thing - I was actually thinking about factoring this out in a = separate email as it is of more general interest, then decided against = it. > o Introduction, 9th paragraph: > Any [academic? otherwise] work that you can = cite to quantify the=20 > computational load? I asked a = crypto-wonk-colleague, who said > something to the effect of =93the document is = perfectly right, on this > point, but I do not have a paper just off the = top of my head with=20 > interesting data to offer=94. For that reason = alone, it=92d be interesting=20 > if you did ;) > =20 > Unfortunately, no I don=92t, though I must admit to not trying to look = hard. The last interested academic that I spoke to on this matter was = interested in our results, rather than providing any results himself. Alright, I=92ll try to ask around my local crypto wonks =97 it=92d be = good if everybody on the list would do the same. Thomas > =20 > We have experimental results that I=92m reasonably sure show faster = signatures and verifications than other forms of IBS we have implemented = (at least two others at various times). That=92s in large part because = ECCSI does not use pairings (see the companion RFC 6508 for an algorithm = that does) and the expensive operations (both by repute and in our = experience) are pairings and exponentiations of elements in the codomain = of the pairing. However I don=92t have a set of crystal clear results = comparing the signature only with nothing else changed. In principle we = could do this, but for various reasons that would take longer than I = have time to spare. (They weren=92t all created for the same purpose.) = Any results would also be dependent on the choice of crypto library, and = even decisions made within the library. For example I=92ve had a = significant factor speedup using a different option within a library in = one case. > =20 > So, in short, that paragraph is about what I think I can say without = stepping where I couldn=92t back up comments. I=92d like to strengthen = it, but I think that=92s where I can go. > =20 > Anyone who has a reference (and I will look a bit further) please let = me know. Non-paywalled references in strong preference. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas = Clausen > Sent: 28 July 2014 15:38 > To: manet; ; manet-ads > Cc: Christopher Dearlove > Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, clickhere. > If you feel the email is suspicious, please follow this process. >=20 > =20 > On Jul 28, 2014, at 15:19, Thomas Clausen = wrote: >=20 >=20 > Dear WG Chairs,=20 > Dear Chris, all, > =20 > As the author indicated by email recently, he believes that = draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC.=20 > =20 > =20 > And, Ulrich just pointed out to me in private that the above should be = "draft-ietf-manet-ibs=94, of course =97 I thought I was being clever = using email templates, and all. Apologies, and thank you Ulrich for = catching my screwup. > =20 > Thomas >=20 >=20 > As a reminder, this document aims for publication as a Proposed = Standard. > =20 > I have, therefore, reviewed the document carefully. In my opinion, the = author is right =97in my opinion this document is ready for WGLC. > =20 > Moreover, I believe that it is a highly important document for the WG = to produce, as it fills a real need, and does so by relying on = already-published crypto RFCs, rather than by coming up with something = esoteric. > =20 > I have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that should be = blocking. > =20 > One of the issues is =93need a non-jetlagged ADs advice to be sure we = do the right thing=94, the other is =97 I think =97 a minor mix-up with = a trivial editorial resolution and zero technical impact on this = specification. > =20 > Either way, for information, I include all issues and nits that I=92ve = found in the below. > =20 > Issues: > =20 > o In my opinion, =93Updates 7182=94 is = inappropriate. What this document does is: > (i) only things = permissible by RFC7182, and=20 > (ii) makes registration = from IANA registries set up by RFC7182 > (noting, of course, = that RFC7181 doesn=92t =93Updates 5444=94=20 > when making = registrations for TC messages from the repositories=20 > set up by RFC5444 as = a case of precedent) > Consequently, I believe that the abstract, = introduction, and document=20 > header, needs updates to reflect that this is = not an update. > =20 > Caveat Lector: I have bounced this around with = the author, and I=20 > think that the = conclusion is that we need just a friendly=20 > ADs opinion =97 my = understanding is that the author > =93wants this out, but = wants it done right, also=94, something > to which I can but = adhere. > =20 > I believe that we = should WGLC the document. If the AD > finds the time to = address this issue during WGLC, great - > otherwise, we can = reflect this in the =93Document Writeup=94 > that the AD will = consider with the publication request =97 as > this (imo) is = procedural/editorial, and certainly not technical. > =20 > o Introduction, 4th paragraph: > =20 > Isn=92t it RFC7183 which does = shared-secret-key ICVs? I just did a quick > grep through of =93shared=94 in 7182, and = found just a few mentions, notably > setting a side a value for key-id-length in = that case. And =93secret=94 is not > mentioned anywhere in 7182 > =20 > =20 > Nits: > o Introduction, 1st paragraph: > OLD: > This specification extends the TLV = definitions > therein by defining two new = cryptographic function code points that > allow the use of an identity-based = signature (IBS) as an ICV. > =20 > NEW: > This specification defines two new = cryptographic function=20 > code points from within the = registries set up by [RFC7182],=20 > that allow the use of an = identity-based signature (IBS) as an ICV. > =20 > o Introduction, 2nd paragraph, 1st line: > I took a double-take when I saw the = parenthesis=20 > =93(protocol participant)=94 =97 that seems a = little odd, and I am on a crusade > against redundant and hard-to-parse = terminology ;) > =20 > I think that what is meant is =93router, which = is running a routing=20 > protocol which is based on RFC5444=94, so = could the document not say > that? > =20 > In any event, I do not see =93protocol = participant=94 defined or anywhere else, > and so it seems unfortunate to *not* be = explicit here. > =20 > o Introduction, 3rd paragraph: > =20 > OLD: > Two options for the choice of = identity are supported (the two code > points allocated). > =20 > NEW: > Two options for the choice of = identity are supported (as reflected > by the two code points allocated). > =20 > =20 > o Introduction, 7th paragraph: > Caveating that using this introduces the = danger that =93if you catch the=20 > trusted authority, then you=92re screwed=94 is = awesome. I see that=20 > this is repeated and reworded in the Security = Considerations section, > and I approve.=20 > =20 > Now, my question is then, if this should not = be stated in the Applicability=20 > statement, also? Something to the effect of = that this applies to networks > where all routers can (at some point) be in = contact with the TA (to be > keyed), but that this can be off-line =97 and = probably should be off-line > since the TA really, really should be = protected. > =20 > It might be argued that the forward-reference = to Section 6 captures > this =97 I still think, that a few choice = words in the applicability statement > would help greatly. > =20 > o Introduction, 9th paragraph: > Any [academic? otherwise] work that you can = cite to quantify the=20 > computational load? I asked a = crypto-wonk-colleague, who said > something to the effect of =93the document is = perfectly right, on this > point, but I do not have a paper just off the = top of my head with=20 > interesting data to offer=94. For that reason = alone, it=92d be interesting=20 > if you did ;) > =20 > o Throw-away comment, I appreciate particularly = the last > paragraph of the introduction. > =20 > o Section 4.1, first bullet > =20 > OLD: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in = [RFC7182], but (like the HMAC > ICVs defined there) uses the hash = function within the > cryptographic function. The option = "none" is not permitted for > hash-function, and the hash function = must have a known fixed > length of N octets, as specified in = Section 4.2. > =20 > NEW: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in = [RFC7182], but (like the HMAC > ICVs defined in [RFC7182]) uses the = hash function within the > cryptographic function. The option = "none" is not permitted for > hash-function, and the hash function = must have a known fixed > length of N octets, as specified in = Section 4.2. > =20 > o While we are at it, it it crystal-clear to = everybody that =93Section 4.2=94 in > the bullet above is to *this* document, as not = RFC7182? > =20 > o Section 4.3, 2nd bullet > There=92s a LOT of information embedded in = this bullet, and reading it > suggests that it, readability-wise, might = benefit from embedding a: > > =85 > =85 > =85 > > =20 > o IANA Considerations: > =20 > Given recent experiences in this WG and with = requesting IANA=20 > registrations, may I suggest that this be = modified to say, more > explicitly: > =20 > 1) IANA is requested to = reserve ECCSI with description ___=20 > and reference =93This = Specification=94 > =20 > 2) IANA is requested to = reserve ECCSI-ADDR=85. (similar) > =20 > 3) The =93Cryptographic = Functions Registry=94, defined in=20 > [RFC7182], with these = registrations made, will look > like Table 1, which = replaces Table 11 of [RFC7182] > =20 > 4) Obviously, include in = Table 1 the registrations from > RFC7182. > =20 > 5) That this document does = not modify the expert > review guidelines as = set forth in RFC7182 for > future allocations. > =20 > That=92s all. Thanks for writing this document, Chris.=20 > =20 > =20 > Respectfully, > =20 > Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_C1D89541-B8DD-4108-AB75-709A4A6E73E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Chrism

On Jul 28, 2014, at 17:58, = Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

Thanks Thomas for this. I=92m just going to pick up = one point for this email (not meaning that I=92m disregarding the other = points).
 

Sure = thing - I was actually thinking about factoring this out in a separate = email as it is of more general interest, then decided against = it.

        &= nbsp;   o        &= nbsp; Introduction, 9th = paragraph:
        &= nbsp;           &nb= sp;   Any [academic? = otherwise] work that you can cite to quantify = the 
        &= nbsp;           &nb= sp;   computational load? = I asked a crypto-wonk-colleague, who said
        &= nbsp;           &nb= sp;   something to the = effect of =93the document is perfectly right, on = this
        &= nbsp;           &nb= sp;   point, but I do = not have a paper just off the top of my head = with 
        &= nbsp;           &nb= sp;   interesting data to = offer=94. For that reason alone, it=92d be = interesting 
        &= nbsp;           &nb= sp;   if you did = ;)
 
Unfortunately, no I don=92t, though I must admit to = not trying to look hard. The last interested academic that I spoke to on = this matter was interested in our results, rather than providing any = results = himself.

Alright, = I=92ll try to ask around my local crypto wonks =97 it=92d be good if = everybody on the list would do the = same.

Thomas

 
We have experimental results that I=92m reasonably = sure show faster signatures and verifications than other forms of IBS we = have implemented (at least two others at various times). That=92s in = large part because ECCSI does not use pairings (see the companion RFC = 6508 for an algorithm that does) and the expensive operations (both by = repute and in our experience) are pairings and exponentiations of = elements in the codomain of the pairing. However I don=92t have a set of = crystal clear results comparing the signature only with nothing else = changed. In principle we could do this, but for various reasons that = would take longer than I have time to spare. (They weren=92t all created = for the same purpose.) Any results would also be dependent on the choice = of crypto library, and even decisions made within the library. For = example I=92ve had a significant factor speedup using a different option = within a library in one case.
 
So, in short, that = paragraph is about what I think I can say without stepping where I = couldn=92t back up comments. I=92d like to strengthen it, but I think = that=92s where I can go.
 
Anyone who has a = reference (and I will look a bit further) please let me know. = Non-paywalled references in strong = preference.
 
--
Christopher = Dearlove
Senior Principal Engineer, Information Assurance = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas = Clausen
Sent: 28 July 2014 = 15:38
To: manet; <manet-chairs@tools.ietf.org>; = manet-ads
Cc: Christopher = Dearlove
Subject: Re: [manet] Ready for WGLC: = Advancing draft-ietf-manet-ibs
 
 
*** = WARNING ***

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

 
On = Jul 28, 2014, at 15:19, Thomas Clausen <thomas@thomasclausen.org> = wrote:


Dear = WG Chairs, 
Dear = Chris, all,
 
As = the author indicated by email recently, he believes = that draft-ietf-manet-olsrv2-management-snapshot is ready for = WGLC. 
 
 
And, Ulrich just pointed out to me in private that the above = should be "draft-ietf-manet-ibs=94, of course =97 I thought I was being = clever using email templates, and all. Apologies, and thank you Ulrich = for catching my screwup.
 
Thomas


As a = reminder, this document aims for publication as a Proposed = Standard.
 
I = have, therefore, reviewed the document carefully. In my opinion, the = author is right =97in my opinion this document is ready for = WGLC.
 
Moreover, I believe that it is a highly important document for = the WG to produce, as it fills a real need, and does so by relying on = already-published crypto RFCs, rather than by coming up with something = esoteric.
 
I = have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none = of my nits and issues are of the sort that should be = blocking.
 
One = of the issues is =93need a non-jetlagged ADs advice to be sure we do the = right thing=94, the other is =97 I think =97 a minor mix-up with a = trivial editorial resolution and zero technical impact on this = specification.
 
Either way, for information, I include all issues and nits that = I=92ve found in the below.
 
Issues:
 
        &= nbsp;   o        &= nbsp; In my = opinion, =93Updates 7182=94 is inappropriate. What this document does = is:
        &= nbsp;           &nb= sp;            = ;   (i)         only things = permissible by RFC7182, and 
        &= nbsp;           &nb= sp;            = ;   (ii)        makes registration = from IANA registries set up by RFC7182
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  (noting, of course, = that RFC7181 doesn=92t =93Updates = 5444=94 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;   when making = registrations for TC messages from the = repositories 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;   set up by = RFC5444 as a case of precedent)
        &= nbsp;           &nb= sp;   Consequently, I = believe that the abstract, introduction, and = document 
        &= nbsp;           &nb= sp;   header, needs = updates to reflect that this is not an = update.
        &= nbsp;           &nb= sp;  
        &= nbsp;           &nb= sp;   Caveat Lector: I = have bounced this around with the author, and = I 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  think= that the conclusion is that we need just a = friendly 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  ADs = opinion =97 my understanding is that the = author
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  =93wants this out, = but wants it done right, also=94, = something
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  to = which I can but adhere.
        &= nbsp;           &nb= sp;  
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  I = believe that we should WGLC the document. If the = AD
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  finds= the time to address this issue during WGLC, great = -
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  otherwise, we can = reflect this in the =93Document Writeup=94
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  that = the AD will consider with the publication request =97 = as
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  this = (imo) is procedural/editorial, and certainly not = technical.
 
        &= nbsp;   o        &= nbsp; Introduction, 4th = paragraph:
 
        &= nbsp;           &nb= sp;   Isn=92t it RFC7183 = which does shared-secret-key ICVs? I just did a = quick
        &= nbsp;           &nb= sp;   grep through of = =93shared=94 in 7182, and found just a few mentions, = notably
        &= nbsp;           &nb= sp;   setting a side a = value for key-id-length in that case. And =93secret=94 is = not
        &= nbsp;           &nb= sp;   mentioned anywhere = in 7182
 
 
Nits:
        &= nbsp;   o        &= nbsp; Introduction, 1st = paragraph:
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;            = ;   This specification = extends the TLV definitions
        &= nbsp;           &nb= sp;            = ;   therein by defining = two new cryptographic function code points = that
        &= nbsp;           &nb= sp;            = ;   allow the use of an = identity-based signature (IBS) as an = ICV.
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;            = ;   This specification = defines two new cryptographic = function 
        &= nbsp;           &nb= sp;            = ;   code points from = within the registries set up by = [RFC7182], 
        &= nbsp;           &nb= sp;            = ;   that allow the use = of an identity-based signature (IBS) as an = ICV.
 
        &= nbsp;   o        &= nbsp; Introduction, 2nd = paragraph, 1st line:
        &= nbsp;           &nb= sp;   I= took a double-take when I saw the = parenthesis 
        &= nbsp;           &nb= sp;   =93(protocol = participant)=94 =97 that seems a little odd, and I am on a = crusade
        &= nbsp;           &nb= sp;   against redundant = and hard-to-parse terminology ;)
 
        &= nbsp;           &nb= sp;   I= think that what is meant is =93router, which is running a = routing 
        &= nbsp;           &nb= sp;   protocol which is = based on RFC5444=94, so could the document not = say
        &= nbsp;           &nb= sp;   that?
=
 
        &= nbsp;           &nb= sp;   In any event, I do = not see =93protocol participant=94 defined or anywhere = else,
        &= nbsp;           &nb= sp;   and so it seems = unfortunate to *not* be explicit here.
 
        &= nbsp;   o        &= nbsp; Introduction, 3rd = paragraph:
 
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;   =             &n= bsp;           Two options for the = choice of identity are supported (the two = code
        &= nbsp;           &nb= sp;            = ;   points = allocated).
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;            = ;   Two= options for the choice of identity are supported (as = reflected
        &= nbsp;           &nb= sp;            = ;   by = the two code points allocated).
 
 
        &= nbsp;   o        &= nbsp; Introduction, 7th = paragraph:
        &= nbsp;           &nb= sp;   Caveating that using = this introduces the danger that =93if you catch = the 
        &= nbsp;           &nb= sp;   trusted authority, = then you=92re screwed=94 is awesome. I see = that 
        &= nbsp;           &nb= sp;   this is repeated and = reworded in the Security Considerations = section,
        &= nbsp;           &nb= sp;   and I = approve. 
 
        &= nbsp;           &nb= sp;   Now, my question is = then, if this should not be stated in the = Applicability 
        &= nbsp;           &nb= sp;   statement, also? = Something to the effect of that this applies to = networks
        &= nbsp;           &nb= sp;   where all routers = can (at some point) be in contact with the TA (to = be
        &= nbsp;           &nb= sp;   keyed), but that = this can be off-line =97 and probably should be = off-line
        &= nbsp;           &nb= sp;   since the TA really, = really should be protected.
 
        &= nbsp;           &nb= sp;   It might be argued = that the forward-reference to Section 6 = captures
        &= nbsp;           &nb= sp;   this =97 I still = think, that a few choice words in the applicability = statement
        &= nbsp;           &nb= sp;   would help = greatly.
 
        &= nbsp;   o        &= nbsp; Introduction, 9th = paragraph:
        &= nbsp;           &nb= sp;   Any [academic? = otherwise] work that you can cite to quantify = the 
        &= nbsp;           &nb= sp;   computational load? = I asked a crypto-wonk-colleague, who = said
        &= nbsp;           &nb= sp;   something to the = effect of =93the document is perfectly right, on = this
        &= nbsp;           &nb= sp;   point, but I do = not have a paper just off the top of my head = with 
        &= nbsp;           &nb= sp;   interesting data to = offer=94. For that reason alone, it=92d be = interesting 
        &= nbsp;           &nb= sp;   if you did = ;)
 
        &= nbsp;   o        &= nbsp; Throw-away = comment, I appreciate particularly the = last
        &= nbsp;           &nb= sp;   paragraph of the = introduction.
 
        &= nbsp;   o        &= nbsp; Section = 4.1, first bullet
 
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;      o =  The ICV is not calculated as = cryptographic-function(hash-
        &= nbsp;           &nb= sp;         =  function(content)) as defined in [RFC7182], but (like the = HMAC
        &= nbsp;           &nb= sp;        =   ICVs defined there) uses the hash function within = the
        &= nbsp;           &nb= sp;        =   cryptographic function.  The option "none" is not permitted = for
        &= nbsp;           &nb= sp;        =   hash-function, and the hash function must have a known = fixed
        &= nbsp;           &nb= sp;        =   length of N octets, as specified in Section = 4.2.
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;      o =  The ICV is not calculated as = cryptographic-function(hash-
        &= nbsp;           &nb= sp;         =  function(content)) as defined in [RFC7182], but (like the = HMAC
        &= nbsp;           &nb= sp;        =   ICVs defined in [RFC7182]) uses the hash function within = the
        &= nbsp;           &nb= sp;        =   cryptographic function.  The option "none" is not permitted = for
        &= nbsp;           &nb= sp;        =   hash-function, and the hash function must have a known = fixed
        &= nbsp;           &nb= sp;        =   length of N octets, as specified in Section = 4.2.
 
        &= nbsp;   o        &= nbsp; While we = are at it, it it crystal-clear to everybody that =93Section 4.2=94 = in
        &= nbsp;           &nb= sp;   the bullet above is = to *this* document, as not RFC7182?
 
        &= nbsp;   o        &= nbsp; Section = 4.3, 2nd bullet
        &= nbsp;           &nb= sp;   There=92s a LOT of = information embedded in this bullet, and reading = it
        &= nbsp;           &nb= sp;   suggests that it, = readability-wise, might benefit from embedding = a:
        &= nbsp;           &nb= sp;            = ;   <list = style=3D=93hanging=94>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Packet = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Message = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Address Block = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;   </list>
 
        &= nbsp;   o        &= nbsp; IANA = Considerations:
 
        &= nbsp;           &nb= sp;   Given recent = experiences in this WG and with requesting = IANA 
        &= nbsp;           &nb= sp;   registrations, may I = suggest that this be modified to say, = more
        &= nbsp;           &nb= sp;   explicitly:=
 
        &= nbsp;           &nb= sp;            = ;   1)        <= span class=3D"Apple-converted-space"> IANA is = requested to reserve ECCSI with description = ___ 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  and = reference =93This Specification=94
 
        &= nbsp;           &nb= sp;            = ;   2)        <= span class=3D"Apple-converted-space"> IANA is = requested to reserve ECCSI-ADDR=85. = (similar)
 
        &= nbsp;           &nb= sp;            = ;   3)        <= span class=3D"Apple-converted-space"> The = =93Cryptographic Functions Registry=94, defined = in 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  [RFC7182], with = these registrations made, will look
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  like = Table 1, which replaces Table 11 of = [RFC7182]
 
        &= nbsp;           &nb= sp;            = ;   4)        <= span class=3D"Apple-converted-space"> Obviously, = include in Table 1 the registrations = from
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  RFC7182.
 
        &= nbsp;           &nb= sp;            = ;   5)        <= span class=3D"Apple-converted-space"> That this = document does not modify the expert
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  review guidelines as = set forth in RFC7182 for
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  future = allocations.
 
That=92s all. Thanks for writing this document, Chris. 
 
 
Respectfully,
 
Thomas
_______________________________________________
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.
***************************************************************= *****

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

= --Apple-Mail=_C1D89541-B8DD-4108-AB75-709A4A6E73E0-- From nobody Mon Jul 28 09:21:22 2014 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 AD0731A030E for ; Mon, 28 Jul 2014 09:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 0prSslcBqHJB for ; Mon, 28 Jul 2014 09:21:19 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906701A030B for ; Mon, 28 Jul 2014 09:21:18 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so7584762wgh.32 for ; Mon, 28 Jul 2014 09:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=kxsXBEkj1N94sIg7omr9yoKg5cZqRKuGGqtRlt5A8kM=; b=wuCmKlHSgP7Cw72iY1pXdyDgPwDSstgLM26vhHNKvTMoFn24xVajqEYls4cd5BGDwT J5T73IJq13jaDiWERbEi/FpFmEFb2KR2agA8p8VYJ02Xs3DTskK3z3BiueY0RnqOuGF/ rwOVs5MLfIQb2keapb7qe+s6be2ugbsRG1X+CygEzQxmfD1EiIpcK7Zy6tpNNv0fsIGT dJ4CfZptV4mLmlBenCQYTfge1tpv/KcUJ4RfYx7vyTHL2SLTkKuDHXHq3iA79JveTJxU YmuQPaxwM8M67LmjlgNu773K1qIs0VHBdddvh03JZveAGbDLhFdcXVdp3PbY4i51zCI6 /D9w== MIME-Version: 1.0 X-Received: by 10.194.237.135 with SMTP id vc7mr52559723wjc.86.1406564474450; Mon, 28 Jul 2014 09:21:14 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Mon, 28 Jul 2014 09:21:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Jul 2014 18:21:14 +0200 X-Google-Sender-Auth: PuhhC7PubdOC2oyK1xV8jht87mU Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=089e01494148da7a1f04ff434f9c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/utMBW9qXHqUJ7ptuwBffFYsZkPg Subject: Re: [manet] About olsrv2-multipath, following the discussion on IETF90 meeting 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, 28 Jul 2014 16:21:21 -0000 --089e01494148da7a1f04ff434f9c Content-Type: text/plain; charset=UTF-8 Dear all, In recent days, I have got lot of questions, comments and suggestions on the draft (mainly off the list). Thanks very much for all the reviews and discussions. They helps a lot for improving the draft! Some of the issues are raised multiple times. I think it would be helpful to summarise some of them, because some of you might have the same questions/concerns also. A new revision of the draft will be made soon, to clarify/address the issues. o Strict source routing or loose source routing? Using strict source routing or loose source routing depends on the number of hops of the route, and the existence of OLSRv2 routers (without multipath support). There is a parameter MAX_SRC_HOPS that defines the maximum number of hops allowed in the source routing header (by default, it is set to 10 so as to avoid exceeding the maximum IPv4 header length). If the calculated path is less than MAX_SRC_HOPS, then it's strict source routing -- or else, loose source routing. Another case of loose source routing is used is that, there are OLSRv2 routers in the calculated paths. Those routers must not be included in the source routing header. o If loose source routing, how the "key" routers are selected? There are several basic rules for being a "key" router: - The key router must be a MP-OLSR Router, so that it can handle the swapping operation correctly. - Without further information (such as routers with higher priority, or routers to be avoided), they are uniformly chosen in the calculated paths. - If there are some MP-OLSR routers with greater capacity (such as bigger WILLINGNESS value), they should be firstly chosen. We will clarify those rules in the new revision of the draft, and put "smarter choice of key routers" in the "experiments to be conducted" section. Note that, as long as the first rule is followed, there is no issue of interoperability. o Overhead because of source routing? It inevitable that certain overhead is introduced because of IP source routing. However, with loose source routing and compression mechanisms in IPv6, the overhead is limited. This multipath extension (probably OLSRv2 also?) is not for low power and lossy networks. At least, in the scenarios that we faced, adding ~30 octets in the header is quite acceptable. o Ambiguities because of loose source routing? The loose source routing is used if: 1) the path length is longer than MAX_SRC_HOPS; 2) There are OLSRv2 routers in the paths. For the first case, with our experience, a maximum of 10 hops to define the route can already provide good enough granularity, given the number of paths is normally less than 4. For the second case, if there are router that don't support multipath, there are possibilities that the datagrams don't follow exactly the the paths calculated. This is a compromise of OLSRv2 and MP-OLSRv2 mixed networks. When we are talking about interoperability with OLSRv2, it doesn't mean that the network can provide the same performance as all the routers support this multipath extension, but the network won't break with mixed routers, and provide as least the same performance as OLSRv2. o In some documents, such as RFC2991, discussed the concerns like variable latencies and packet reordering. Although the issues discussed in RFC2991 (the forwarder potentially has several next-hops for any given destination) are not exactly the same as this extension, the flow is splited among multiple paths also. It's true that splitting a flow would cause packet ordering problems in some scenarios. But in dynamic ad hoc networks, it can bring improvements. If you have 2 more minutes to check in detail, I uploaded an old revision of one of the references http://jiaziyi.com/documents/MPOLSR_old.pdf (in the published version, some figures are removed because some of the reviewers think it's too verbose :) You can go to figure 13 directly, which gives the average jitter in a simple and stable scenario. You can see that MP-OLSR do has larger jitter in this kind of scenarios. However, if we go to dynamic scenarios, as shown in figure 15, the MP-OLSR has actually less average latency variation. There is one more paragraph explaining it following the figure 15, if you are interested. o Some services prefer flow-by-flow distribution, so it would be helpful to use multipath for certain services, and normal OLSRv2 for the others. This is actually a very good idea. Because with our experiences, we know well multipath routing can bring benefits for some applications (especially audio/video transmissions), but it's probably not the case for every services. Then it would be helpful to specify that the applications can decide if multipath routing is used, by using DiffServ code point, etc. o Why end-to-end path? Why not allow each router to make its own decision? There are issues with hop-by-hop multipath: - Potential loops; - More serious delay variations, because datagrams can be forwarded by much more different routers; - No guarantee of disjointness. The reasons that end-to-end source route based approach is use are: - In some scenarios, there are requirements that certain router must (or must not) be used; - By having control of the paths, the delay can be provisioned; - An very important application of this extension is Forward Error Correction coding. For example, we encode two data packets into 3 projections with certain redundancies, and then transmit the 3 projections into the three disjoint paths. At the final destination, we need only 2 projections to recover the original 2 data packets --- even one of the projections is lost. This method is not very efficient for single path router, because the packet drop is normally continuous for a single path: if all the 3 projections are lost, we can do nothing about it. o Is gateway to other routing domain supported? On this aspect, MP-OLSRv2 has no difference with OLSRv2. So yes. o Some of the implementations mentioned in the "Implementation Status" are OLSR version 1? Yes. There have been a lot of work when OLSRv2 is not well-known. In fact, the basic algorithm of multipath routing has no difference for OLSR and OLSRv2. Therefore, the performance studies are valid for both protocols. Given there are also a lot of OLSR networks running in the field, we believe it would be beneficial to have all the implementations. Actually, in the queries that we got regarding multipath routing, there are more based on OLSR version 1 :) Again, thanks for all the valuable comments, and we are looking forward to your further feedback. regards Jiazi On Wed, Jul 23, 2014 at 11:56 AM, Jiazi YI wrote: > Hi, > > Thanks very much for the discussion on olsrv2-multipath during the > meeting. I would like to add a few words regarding the comments during the > discussions. > > o Why do multipath routing in MANET, rather than other WGs? > > The olsrv2-multipath is an extension of OLSRv2. Based on our experience, > multipath is more interesting if the topology is dynamic, or link breakage > is frequent. In fact, the simulation results (in which the link is assumed > relatively stable) show that the performance is very close between the two > in static scenarios. The performance gain is much more interesting in > dynamic networks. > > o Source routing? > > The olsrv2-multipath uses IP source routing (loose source routing for > IPv4, RFC6553 for IPv6), so that it can be interoperable with OLSRv2 and > its other extensions (such as new metrics, multi-topology, etc.). > Theres nothing inherently preventing other mechanism for 'forcing traffic > along certain paths' -- for example, one could imagine setting up a > label-switched path for each path in a multi-path flow, if such was > desired. It might be a good idea for the next version of the I-D to > indicate this, although we do not have any operational experiences with > this. It might be an interesting expansion to the document, and to the > experiment it is to enable, to try to understand which other ways of > 'forcing traffic along certain paths' are valid. Adrian, thank you for > triggering those thoughts. > > o Multipath for re-active protocols? > > I know that there have been several proposals that published as academic > papers. But I have to point out that the way doing multi-path for re-active > protocols is very different for pro-active protocols. > For pro-active protocol, we have already a topology map of the network, so > it's much simpler to calculate desired paths. In re-active protocol, to > obtain enough information to get multiple paths, more route discovery > messages are required, which might cause unpredictable behaviours. > I remember in the IETF Maastricht, there was a presentation about > multipath-dymo using multiple interfaces. That was totally a different way > compared to this olsrv2-multipath draft, and has special layer 2 > requirements (such as multiple interfaces). > > > The draft is aimed to be a light-weight extension of OLSRv2 -- and it is, > regarding its size: 16 pages in total -- and if you cut the references, > implementation status, copy right, etc, you have less than 10 pages to read > :) > > Please review the document, the authors are very eager to incorporate your > comments. As I heard it (granted, I attended remotely) there was a single > hum 'against' adopting the document. The authors are actually quite excited > about that, since divergent opinions is a source for inspiration: what's > the reason for the 'hum against'? Anything in the document that can be done > better, or which in your opinion and experience would 'break the internet' > or be sub-optimal? If you could elaborate, then that would allow > improvements, which would be immensely helpful. > > Of course, if you want to 'anonymize' by way of relaying through the > chairs or the ADs, that's quite alright -- our objective is to build the > best possible OLSRv2 extension possible, so through whichever form your > opinion is relayed, it's valuable to us, and we want to express our > appreciation." > > The work behind this draft was developed more than a decade ago, and has > existed and been improved for years, with very interesting outcome. Thanks > to the multiple open-source implementations in different platforms, the > protocol has been tested by different researchers, engineers all over the > world. We believe it's time to have it clearly specified, and published as > an experimental RFC. > > We've been holding back pushing for this, since we felt that OLSRv2 -- > with its support for IPV6, and for security, and for extensibility -- > should be finalized before pushing for extensions like this. > > regards > > Jiazi > > --089e01494148da7a1f04ff434f9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

In recent days, I have = got lot of questions, comments and suggestions on the draft (mainly off the= list). Thanks very much for all the reviews and discussions. They helps a = lot for improving the draft!

Some of the issues are raised multiple times. =C2=A0I t= hink it would be helpful to summarise some of them, because some of you mig= ht have the same questions/concerns also.=C2=A0
A new revision of= the draft will be made soon, to clarify/address the issues.=C2=A0

=C2=A0o Strict source routing or loose source rout= ing?
=C2=A0
=C2=A0 =C2=A0Using strict source routing or= loose source routing depends on the number of hops of the route, and the e= xistence of OLSRv2 routers (without multipath support).=C2=A0
=C2=A0 =C2=A0There is a parameter MAX_SRC_HOPS that defines the maximu= m number of hops allowed in the source routing header (by default, it is se= t to 10 so as to avoid exceeding the maximum IPv4 header length). If the ca= lculated path is less than MAX_SRC_HOPS, then it's strict source routin= g -- or else, loose source routing.=C2=A0
Another case of loose source routing is used is that, there are OLSRv2= routers in the calculated paths. Those routers must not be included in the= source routing header.=C2=A0


=C2= =A0o If loose source routing, how the "key" routers are selected?=
=C2=A0
There are several basic rules for being a "key&q= uot; router:
-= The key router must be a MP-OLSR Router, so that it can handle the swappin= g operation correctly.=C2=A0
- Without further i= nformation (such as routers with higher priority, or routers to be avoided)= , they are uniformly chosen in the calculated paths.=C2=A0
- If there are some MP-OLSR ro= uters with greater capacity (such as bigger WILLINGNESS value), they should= be firstly chosen.=C2=A0

We will clarify those rules in the new revision of the = draft, and put "smarter choice of key routers" in the "exper= iments to be conducted" section. Note that, as long as the first rule = is followed, there is no issue of interoperability. =C2=A0

=C2=A0o Overhead because of source routing?
= =C2=A0
=C2=A0 =C2=A0It inevitable that certain overhead is introd= uced because of IP source routing. However, with loose source routing and c= ompression mechanisms in IPv6, the overhead is limited.=C2=A0
=C2=A0 =C2=A0This multipath extension (probably OLSRv2 also?) is not f= or low power and lossy networks. At least, in the scenarios that we faced, = adding ~30 octets in the header is quite acceptable.=C2=A0
=C2=A0=
=C2=A0o Ambiguities because of loose source routing?

=C2=A0 =C2=A0The loose source routing is used if: 1) th= e path length is longer than MAX_SRC_HOPS; 2) There are OLSRv2 routers in t= he paths.=C2=A0
=C2=A0 =C2=A0For the first case, with our experie= nce, a maximum of 10 hops to define the route can already provide good enou= gh granularity, given the number of paths is normally less than 4.
=C2=A0 =C2=A0For the second case, if there are router that don't s= upport multipath, there are possibilities that the datagrams don't foll= ow exactly the the paths calculated. This is a compromise of OLSRv2 and MP-= OLSRv2 mixed networks.=C2=A0
=C2=A0 =C2=A0When we are talking about interoperability with OLSRv2, i= t doesn't mean that the network can provide the same performance as all= the routers support this multipath extension, but the network won't br= eak with mixed routers, and provide as least the same performance as OLSRv2= . =C2=A0=C2=A0
=C2=A0
=C2=A0o In some documents, such as RFC2991, discussed= the concerns like variable latencies and packet reordering.=C2=A0
=C2=A0
=C2=A0 =C2=A0Although the issues discussed in RFC2991 (t= he forwarder potentially has several next-hops for any given destination) a= re not exactly the same as this extension, the flow is splited among multip= le paths also.=C2=A0
=C2=A0 =C2=A0It's true that splitting a flow would cause packet or= dering problems in some scenarios. But in dynamic ad hoc networks, it can b= ring improvements.=C2=A0
=C2=A0 =C2=A0If you have 2 more minutes = to check in detail, I uploaded an old revision of one of the references http://jiaziyi.com/doc= uments/MPOLSR_old.pdf =C2=A0(in the published version, some figures are= removed because some of the reviewers think it's too verbose :)=C2=A0<= /div>
=C2=A0 =C2=A0You can go to figure 13 directly, which gives the average= jitter in a simple and stable scenario. You can see that MP-OLSR do has la= rger jitter in this kind of scenarios.=C2=A0
=C2=A0 =C2=A0However= , if we go to dynamic scenarios, as shown in figure 15, the MP-OLSR has act= ually less average latency variation. There is one more paragraph explainin= g it following the figure 15, if you are interested.=C2=A0

=C2=A0o Some services prefer flow-by-flow distribution,= so it would be helpful to use multipath for certain services, and normal O= LSRv2 for the others.=C2=A0
=C2=A0
=C2=A0 =C2=A0This is= actually a very good idea. Because with our experiences, we know well mult= ipath routing can bring benefits for some applications (especially audio/vi= deo transmissions), but it's probably not the case for every services. = Then it would be helpful to specify that the applications can decide if mul= tipath routing is used, by using DiffServ code point, etc.=C2=A0
=C2=A0
=C2=A0o Why end-to-end path? Why not allow each route= r to make its own decision?
=C2=A0
There are issues wit= h hop-by-hop multipath:
- Potential loops;
- More serious dela= y variations, because datagrams can be forwarded by much more different rou= ters;
- No gua= rantee of disjointness.=C2=A0
The reas= ons that end-to-end source route based approach is use are:
- In some scenarios, there ar= e requirements that certain router must (or must not) be used;=C2=A0
- By having control= of the paths, the delay can be provisioned;
- An very important application of this exte= nsion is Forward Error Correction coding. For example, we encode two data p= ackets into 3 projections with certain redundancies, and then transmit the = 3 projections into the three disjoint paths. At the final destination, we n= eed only 2 projections to recover the original 2 data packets --- even one = of the projections is lost. This method is not very efficient for single pa= th router, because the packet drop is normally continuous for a single path= : if all the 3 projections are lost, we can do nothing about it.=C2=A0


=C2=A0o Is gateway to other routing doma= in supported?=C2=A0
=C2=A0
=C2=A0 =C2=A0On this aspect,= MP-OLSRv2 has no difference with OLSRv2. So yes.=C2=A0
=C2=A0
=C2=A0o Some of the implementations mentioned in the "Implemen= tation Status" are OLSR version 1?
=C2=A0
=C2=A0 =C2=A0Yes. There have been a lot of work when = OLSRv2 is not well-known. In fact, the basic algorithm of multipath routing= has no difference for OLSR and OLSRv2. Therefore, the performance studies = are valid for both protocols. Given there are also a lot of OLSR networks r= unning in the field, we believe it would be beneficial to have all the impl= ementations. Actually, in the queries that we got regarding multipath routi= ng, there are more based on OLSR version 1 :)

Again, thanks for all the valuable comments, and = we are looking forward to your further feedback.=C2=A0

=
regards

Jiazi


On Wed, Jul 23, 2014 at 11:56 AM, Jiazi = YI <ietf@jiaziyi.com> wrote:
Hi,

Thanks very much for the= discussion on olsrv2-multipath during the meeting. I would like to add a f= ew words regarding the comments during the discussions.

o Why do multipath routing in MANET, rather than other WGs?
=
The olsrv2-multipath is an extension of OLSRv2. Based on our= experience, multipath is more interesting if the topology is dynamic, or l= ink breakage is frequent. In fact, the simulation results (in which the lin= k is assumed relatively stable) show that the performance is very close bet= ween the two in static scenarios. The performance gain is much more interes= ting in dynamic networks.

o Source routing?

The olsrv2-m= ultipath uses IP source routing (loose source routing for IPv4, RFC6553 for= IPv6), so that it can be interoperable with OLSRv2 and its other extension= s (such as new metrics, multi-topology, etc.).
Theres nothing inherently preventing other mechanism for 'forcing = traffic along certain paths' -- for example, one could imagine setting = up a label-switched path for each path in a multi-path flow, if such was de= sired. It might be a good idea for the next version of the I-D to indicate = this, although we do not have any operational experiences with this. It mig= ht be an interesting expansion to the document, and to the experiment it is= to enable, to try to understand which other ways of 'forcing traffic a= long certain paths' are valid. Adrian, thank you for =C2=A0triggering t= hose thoughts.=C2=A0

o Multipath for re-active protocols?

I know that there have been several proposals that published as acad= emic papers. But I have to point out that the way doing multi-path for re-a= ctive protocols is very different for pro-active protocols.
For pro-active protocol, we have already a topology map of the network= , so it's much simpler to calculate desired paths. In re-active protoco= l, to obtain enough information to get multiple paths, more route discovery= messages are required, which might cause unpredictable behaviours.
I remember in the IETF Maastricht, there was a presentation about mult= ipath-dymo using multiple interfaces. That was totally a different way comp= ared to this olsrv2-multipath draft, and has special layer 2 requirements (= such as multiple interfaces).=C2=A0


The draft is aimed to be a light-weight = extension of OLSRv2 -- and it is, regarding its size: 16 pages in total -- = and if you cut the references, implementation status, copy right, etc, you = have less than 10 pages to read :)

Please review the document, the authors are very eager = to incorporate your comments. As I heard it (granted, I attended remotely) = there was a single hum 'against' adopting the document. The authors= are actually quite excited about that, since divergent opinions is a sourc= e for inspiration: =C2=A0what's the reason for the 'hum against'= ;? Anything in the document that can be done better, or which in your opini= on and experience would 'break the internet' or be sub-optimal? If = you could elaborate, then that would allow improvements, which would be imm= ensely helpful.

Of course, if you want to 'anonymize' by way of= relaying through the chairs or the ADs, that's quite alright -- our ob= jective is to build the best possible OLSRv2 extension possible, so through= whichever form your opinion is relayed, it's valuable to us, and we wa= nt to express our appreciation."

The work behind this draft was developed more than a de= cade ago, and has existed and been improved for years, with very interestin= g outcome. Thanks to the multiple open-source implementations in different = platforms, the protocol has been tested by different researchers, engineers= all over the world. We believe it's time to have it clearly specified,= and published as an experimental RFC.

We've been holding back pushing for this, since we = felt that OLSRv2 -- with its support for IPV6, and for security, and for ex= tensibility -- should be finalized before pushing for extensions like this.=

regards

Jiazi


--089e01494148da7a1f04ff434f9c-- From nobody Mon Jul 28 09:35:56 2014 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 9D7D81A03E7 for ; Mon, 28 Jul 2014 09:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bmmneNwS02xe for ; Mon, 28 Jul 2014 09:35:43 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7A61A039A for ; Mon, 28 Jul 2014 09:35:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1010D24759E; Mon, 28 Jul 2014 09:35:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BF95A247554; Mon, 28 Jul 2014 09:35:24 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_494A7F44-B763-4BF7-AE9A-926029B142F7" Date: Mon, 28 Jul 2014 18:35:21 +0200 Message-Id: To: manet , "" , manet-ads Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/v4NbwZj8n7B5LYnaUMRMBCDWItE Cc: "Dr. Emmanuel Baccelli" Subject: [manet] Ready for WGLC: Advancing draft-ietf-manet-olsrv2-dat-metric 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, 28 Jul 2014 16:35:52 -0000 --Apple-Mail=_494A7F44-B763-4BF7-AE9A-926029B142F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear WG Chairs, ADs, Dear Henning, Emmanuel, all, As one of the authors indicated by email recently, he believes that = draft-ietf-manet-olsrv2-dat-metric is ready for WGLC.=20 As a reminder, this document aims for publication as an Experimental = RFC. I have, therefore, reviewed the document carefully. In my opinion, the = author is right =97 in my opinion this document is ready for WGLC, and = my comments can (at the authors discretion) be addressed either by = spinning a new revision now, or during the WGLC. Moreover, I believe that it is a highly important document for the WG to = produce. Currently, hop-count metrics are all that=92s specified =97 = although experience shows that they have well-known issues, and that = OLSRv2 therefore supports (of course) and encourages other metric types = to be developed. Is this metric =93the one and only, be-all-end-all=94 of metrics? = Probably not. But, it has the merits of being one that has been = developed through extensive testing in OLSRv1 (RFC3626). That probably = means that it=92s also well applicable for similar deployments with = OLSRv2, given the (algorithmic) similarity between OLSRv1 and OLSRv2 =97 = experiments will tell us, and so publication as an Experimental RFC = seems appropriate With that being said, I previously indicated that I have a few nits = identified, and the lack of an =93This is the experiment(s) that = publishing this RFC will enable=94 is one. Our benevolent ADs are = =93strongly suggesting=94 such sections in Experimental RFC, and I think = that we as a WG should try to not intentionally irritate them by sending = documents forward which do not have that. I think that a subsection to the introduction would do quite nicely (see = how we did in OLSRv2-MT, or how they did in RFC6971). Other than the = =93will this work as well in OLSRv2 as it did in OLSRv1=94 experiment, I = think that there are a lots of interesting experiments possible. Through = the below, I will try to point to some thing that jumps out at me when I = read the document, and which I think could benefit from a separate = section and discussion. The challenge, IMO, would be to define a set of =93experiments necessary = to determine if taking this to PS, or to declaring this metric historic=94= =97 I would *love* to have a better metric than hop-count standardized, = but I do not think that we=92re quite there yet. So perhaps some = back-and-forth there would be a good idea, as to what experiment(s) = would allow us to determine this?=20 I have handful of issues and a handful of nits, that I expect the = authors will consider along with any other WGLC comments they may = receive. Of course, if a new version is spun before WGLC is requested, = then I=92ll gladly review that, also. Point being: let=92s get a call = started on this document, none of my nits and issues are of the sort = that should be blocking issuing a WGLC. Issues: =09 Placeholder for the =93Needs a =91The Experiments=92 Section=94, = which was discussed above ;) It appears evident when reading the introduction and = applicability statement, that this metric surely must need some =93hooks=94 into the data = forwarding path, or into the L2 data structures =97 as well as, as you = indicate, needs to learn=20 something about the static properties of the L2 (link rate). For = the latter, you state that DLEP can be used, as well as static configuration. = For the former, one is left with baited breath until section 9.3, wherein it is = kinda-sorta hinted that one doesn=92t, the RFC5444 packets exchanged = suffice. Unless you plan on thus pulling an Agatha Christie on the = reader, perhaps something regarding this could be stated in the applicability = statement? The document uses the ill-defined term =93node=94 =97 which is = incorrect in a specification. Please harmonize to the use of =93Router=94 or = =93OLSRv2 Router=94 as is done in RFC7181, both for correctness and for coherence = with 7181 and related specifications. (And, =93node=94 occurs only thrice, = so should be fairly easy to replace ;) ) I am not sure if the term =93mesh networks=94 is one that we=92re = actually using a lot - I believe that we=92ve said =93OLSRv2 routed network=94, = to be precise, in other documents. Technically, there=92s nothing wrong with = =93mesh networks=94 except that many people do (incorrectly) think =93layer 2=94 = when they hear that=20 term. I would suggest to do what we can to avoid confusion ;) Would you mind, in the References, to replace a reference: OLD: [OLSRV2] Clausen, T., Jacquet, P., and C. Dearlove, "The = Optimized Link State Routing Protocol version 2", = draft-ietf-manet- olsrv2-19 , March 2013. NEW: [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The = Optimized Link State Routing Protocol version 2", RFC7181 , = March 2013. Nits: Introduction, 1st paragraph is oddly phrased, notably as RFC3626 = was not a =93standard=94 but an =93Experimental RFC": OLD: One of the major shortcomings of OLSR [RFC3626] is = the missing of a link cost metric between mesh nodes. Operational = experience with mesh networks gathered since the standardization of = OLSR has revealed that wireless networks links can have highly variable = and heterogeneous properties. This makes a hopcount = metric insufficient for effective mesh routing. NEW: One of the shortcomings of OLSR [RFC3626] is the lack = of a granular link cost metric between mesh nodes. Operational = experience with mesh networks gathered since the publication of OLSR = [RFC3626] has revealed that wireless networks links can have highly variable = and heterogeneous properties. This makes a hopcount = metric insufficient for effective mesh routing. Ultimate paragraph in introduction: OLD: This document describes a Directional Airtime routing = metric for OLSRv2, a successor of the OLSR.org routing metric = for [RFC3626]. It takes both the loss rate and the link speed into = account to provide a more accurate picture of the mesh network links. NEW: This document describes a Directional Airtime routing = metric for OLSRv2, a successor to the ETX-derived OLSR.org = routing metric for [RFC3626]. It takes both the loss rate and the link speed into = account to provide a more accurate picture of the links within the = network. Terminology: For when discussing =93UNDEFINED=94, please specify that = this is used only for the descriptions of the processing in this document, and = that the =93value for UNDEFINED=94 does not need to be agreed upon across routers in a = deployment? If that is the case, then please remove the last = sentence =93Might be -1 for this protocol=94 Applicability Statement, last sentence in the penultimate = paragraph, is it possible to be=20 a little more careful that the example looks like an = example: OLD: It might be necessary to increase the data-rate of the multicast transmissions, e.g. set = the multicast data-rate to 6 MBit/s if you use IEEE 802.11g only. NEW: It might, for example in IEEE 802.11g, be necessary = to increase the data-rate of the multicast transmissions, e.g. set = the multicast data-rate to 6 MBit/s. Applicability statement, ultimate paragraph, I have a little bit = of a hard time parsing: The metric can only handle a certain range of packet = loss and unicast data-rate. Maximum packet loss is "ETX 8" (1 of 8 = packets is successfully sent to the receiver, without link layer retransmissions), the unicast data-rate can be = between 1 kBit/s and 2 GBit/s. The metric has been designed for data-rates = of 1 MBit/s and hundreds of MBit/s. Specifically,=94The metric=94 =97 that corresponds to = what? "The DAT metric" (if so, then I suggest saying that). A little bit later, you = talk about =93ETX 8=94 =97 which to someone versed in over-the-air metrics isn=92t = gibberish, but which to someone who=92s not, most definitely is. The = notation =93ETX 8=94 is not introduced - can you rephrase that? Perhaps by = simply removing =93ETX 8=94 and expanding on the parenthesis? Probably a nit, but isn=92t the title for section 4 wrong (I = think that it is =93rationalE=94)? Section 4, first paragraph: OLD: The Directional Airtime Metric has been inspired by = the publications on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, = but has several key differences. NEW: The Directional Airtime Metric has been inspired by = the publications on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, = but differs from both of these in several ways. Section 4, general: Thank you for this section, this rationale is very = helpful and educative, and establishes the relationship to RFC7181 quite well. Section 6, I have some general questions: Any of these need to be exchanged between two routers, = over the air?=20 I am asking because either it is too specific, or too = vague? =93Floating point number between 1,0 and 2.0, large = enough to=85.=94 =09 Section 6.1 =93Recommended Values=94 This almost reads as if it could be part of the =93The = Experiment=94 section, thus: =93In the community networks, where this has = been deployed, which includes [=85], [=85.], and [=85.], the values = below were those which experiments showed to work satisfactory. = Understanding that these networks represent one type of OLSRv2 = deployments, and may not be representative for all possible OLSRv2 = deployments, nor even for all possible community network deployments, = this leads to two questions, where further experimentation is required: o Is this set of parameters = generally applicable to Community=20 Mesh Networks, or are there = adaptations required? o Is this set of parameters = generally applicable to other OLSRv2 deployments, or are there = different parameter sets which apply? =93 Obviously, another part of the experiment would = be =93=85and, can we come=20 up with an even better metric that doesn=92t = need parametrization at all, yet would work everywhere?=94 =97 although that may = be one of those pie-in-the-sky things. Section 7 starts a bit oddly, how about: OLD: This specification defines the following = constants, which cannot be changed without making the metric outputs = incomparable: NEW: This specification defines two constants, = agreement on which is required, from all the OLSRv2 routers = participating in the same deployment.=20 Two routers which use different values for = these constants will not be able to generate metric values which can be = correctly interpreted by both. These constants are: But, I also want to say, that it is awesome that you do = point this out so clearly. Is there any doubt as to if those constants are = =93universal=94, or is there some experiment to be done here? [My gut-feeling tells me = =93no=94, but my gut has=20 been wrong before=85] Section 8, first paragraph: I would appreciate if you would point out if you need to = update the Information Bases in RFC6130, specifically if you need to update = elements other than those which you specify in this document. I would also appreciate a pointer to if you use (but not = update) information in the information bases in RFC6130. Finally, I would like to suggest: OLD: This specification extends the Link Set Tuples = of the Interface Information Base, as defined in [RFC6130] = section 7.1, by the following additional elements for each link = tuple when being used with this metric: NEW: This specification extends the Link Set of the = Interface Information Base, as defined in [RFC6130] = section 7.1, by adding the following elements to each link tuple: And, with this, I would add L_DAT_last_pkt_seqno = to the list on same level as the other 6 elements. I know that it is = not always that it is used, but with the caveat you give (which you should = keep in a modified form) that can be left for an implementer to figure = out. The extension in this document needs it, so it=92s something that this = doc imposes on 6130. Section 9.2, suggest that the title be rephrased to something = like =93Minimum Requirements to an OLSRv2 Implementation for = using this metric=94 I would actually also like to see this piece of = information included in the applicability statement. =09 Section 9.2, what would happen, would there be a possible = back-up mode in case no INTERVAL_TIME TLV is included? Worst case, could = you not make an assumption based on a VALIDITY_TIME TLV present? = How bad would that be? Do we know? Or, is this something = worth experimenting with (to the experiments section)? Right now, that = particular experiment is not enabled by this document (as it requires = INTERVAL_TIME), so perhaps it is =93known to be FUBAR=94 =97 in which case, = actually, stating that (and why) in the experiments section would be = awesome. Section 9.3, when I read this my initial thought (from reading = the paragraph between 9.3 and 9.3.1) that =93Oh, ok, so this tells me what to = do if my implementation is not able to add the packet sequence number=94 - but = then, 9.3.1 immediately kills this hope. So, is this not a requirement, that = would belong in 9.2 also? OK, I am being intentional daft here=85..I think that = you need to point out clearly, but section 9 does not seem quite the right place for = that, that: =93There are these two modes of operation. In = either case, the=20 requirements from 9.2 apply. If you use mode B, = then the requirements from 9.2 AND 9.3 apply. For both modes of operation, the processing in = section X applies. If you use mode B, then the processing in = section Y also applies" =09 This, because section 9 =93Packets and messages=94 start = out looking more=20 like what is expected from a 5444 packet/message, but = from 9.3.1 diverts more into a set of processing directives.=20 I think that the processing directives are clear and = well written (thank you for adopting a non-ambiguous and clear format for this, = it is refreshing and appreciated), but I think that it would be awesome to = have a slightly different structure, something like this (don=92t get hung up in = the specifics of =93Mode B=94, you have a better term, and this is just to indicate the = basic idea): 9. Packets and Messages 9.1 Definitions 9.2 Requirements to an OLSRv2 Implementation = Using This Metric 9.3 Additional Requirements to an OLSRv2 = Implementation using Mode B 10. Processing Directives 10.1 Processing Directives for =93Mode A=94 10.2 Additional Processing Directives for when = using =93Mode B=94 I note that section 10 in the above would have a ton of = subsections, essentially capturing the current 9.3.1 to 11 Section 12 - IANA =97 this baffled me. Do we not need a = code-point assigned from among the LINK_METRIC space? Or, was a decision made to = not do this,=20 and to instead use the 224-255 type extension space for = this experiment?=20 I would think that if that was the case, then some = documentation of this would be good to include in this section. But, I would be very very supportive of an assignment of = a Type Extension to LINK_METRIC for this DAT metric type. Section 13 - Security, this needs a review; notably RFC6622 has = been obsoleted by RFC7182. I think that you probably also want to look at = RFC7183, and consider if, perhaps, some of the provisions from the MTI part of = 7183 would not guard against a few things there? Appendix B You use Linkspeed here, but "link speed=94 in the = introduction, and =93link-speed=94=20 in section 5. Then, in some areas, you talk about = =93unicast data rate=94 =97 are=20 those the same, or different concepts? Could you do an = editorial pass and unify this terminology, please? Respectfully, Thomas =09 --Apple-Mail=_494A7F44-B763-4BF7-AE9A-926029B142F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = WG Chairs, ADs,
Dear Henning, Emmanuel, all,

As = one of the authors indicated by email recently, he believes = that draft-ietf-manet-olsrv2-dat-metric is ready for = WGLC. 

As a reminder, this document = aims for publication as an Experimental RFC.

I = have, therefore, reviewed the document carefully. In my opinion, the = author is right =97 in my opinion this document is ready = for WGLC, and my comments can (at the authors discretion) be addressed = either by spinning a new revision now, or during the = WGLC.

Moreover, I believe that it is a = highly important document for the WG to produce. Currently, hop-count = metrics are all that=92s specified =97 although experience shows that = they have well-known issues, and that OLSRv2 therefore supports (of = course) and encourages other metric types to be = developed.

Is this metric =93the one and only, = be-all-end-all=94 of metrics? Probably not. But, it has the merits of = being one that has been developed through extensive testing in OLSRv1 = (RFC3626). That probably means that it=92s also well applicable for = similar deployments with OLSRv2, given the (algorithmic) similarity = between OLSRv1 and OLSRv2 =97 experiments will tell us, and so = publication as an Experimental RFC seems = appropriate

With that being said, I previously = indicated that I have a few nits identified, and the lack of an =93This = is the experiment(s) that publishing this RFC will enable=94 is one. Our = benevolent ADs are =93strongly suggesting=94 such sections in = Experimental RFC, and I think that we as a WG should try to not = intentionally irritate them by sending documents forward which do not = have that.

I think that a subsection to the = introduction would do quite nicely (see how we did in OLSRv2-MT, or how = they did in RFC6971). Other than the =93will this work as well in OLSRv2 = as it did in OLSRv1=94 experiment, I think that there are a lots of = interesting experiments possible. Through the below, I will try to point = to some thing that jumps out at me when I read the document, and which I = think could benefit from a separate section and = discussion.

The challenge, IMO, would be to = define a set of =93experiments necessary to determine if taking this to = PS, or to declaring this metric historic=94 =97 I would *love* to have a = better metric than hop-count standardized, but I do not think that we=92re= quite there yet. So perhaps some back-and-forth there would be a good = idea, as to what experiment(s) would allow us to determine = this? 

I have handful of issues and a = handful of nits, that I expect the authors will consider along with any = other WGLC comments they may receive. Of course, if a new version is = spun before WGLC is requested, then I=92ll gladly review that, also. = Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that = should be blocking issuing a = WGLC.

Issues:
=
Placeholder for the =93Needs a = =91The Experiments=92 Section=94, which was discussed above = ;)

It appears evident when reading = the introduction and applicability statement,
that this = metric surely must need some =93hooks=94 into the data = forwarding
path, or into the L2 data = structures =97 as well as, as you indicate, needs to = learn 
something about the static = properties of the L2 (link rate). For the latter, you
state = that DLEP can be used, as well as static configuration.  For the = former,
one is left with baited breath = until section 9.3, wherein it is kinda-sorta
hinted = that one doesn=92t, the RFC5444 packets exchanged = suffice.
Unless you plan on thus pulling = an Agatha Christie on the reader, perhaps
something = regarding this could be stated in the applicability = statement?

The document uses the ill-defined = term =93node=94 =97 which is incorrect in a
= specification. Please harmonize to the use of =93Router=94 or = =93OLSRv2 Router=94
as is done in RFC7181, both for = correctness and for coherence with 7181
and = related specifications. (And, =93node=94 occurs only thrice, so should = be
= fairly easy to replace ;) )

I am not = sure if the term =93mesh networks=94 is one that we=92re actually = using
= a lot - I believe that we=92ve said =93OLSRv2 routed network=94, = to be precise,
in other documents. Technically, = there=92s nothing wrong with =93mesh networks=94
except = that many people do (incorrectly) think =93layer 2=94 when they hear = that 
term. I would suggest to do what = we can to avoid confusion ;)

Would you = mind, in the References, to replace a reference:
= OLD:
	   [OLSRV2]   Clausen, T., =
Jacquet, P., and C. Dearlove, "The Optimized
        	=
      Link State Routing Protocol version 2", draft-ietf-=
manet-
	  =
            olsrv2-19 , March 2013.


	   [RFC7181]   Clausen, T., Jacquet, P., and C. =
Dearlove, "The Optimized
        	      Link State Routing =
Protocol version 2", RFC7181 , March 2013.
=

Nits:
= Introduction, 1st paragraph is oddly phrased, notably as RFC3626 = was not a =93standard=94 but an =93Experimental = RFC":

OLD:
=    One of the major shortcomings of OLSR [RFC3626] is = the missing of a
   link cost = metric between mesh nodes.  Operational experience = with
=    mesh networks gathered since the = standardization of OLSR has revealed
=    that wireless networks links can have highly = variable and
  =  heterogeneous properties.  This makes a hopcount metric = insufficient
   for = effective mesh routing.

NEW:
   One of the = shortcomings of OLSR [RFC3626] is the lack of a granular
=    link cost metric between mesh nodes. =  Operational experience with
   mesh = networks gathered since the publication of  OLSR [RFC3626] has = revealed
   that wireless networks links can = have highly variable and
  =  heterogeneous properties.  This makes a hopcount metric = insufficient
   for = effective mesh routing.

Ultimate = paragraph in introduction:
OLD:
=    This document describes a Directional Airtime = routing metric for
   OLSRv2, a = successor of the OLSR.org routing metric = for [RFC3626].  It
   takes both = the loss rate and the link speed into account to provide = a
=    more accurate picture of the mesh network = links.

NEW:
=    This document describes a Directional Airtime = routing metric for
   OLSRv2, a = successor to the ETX-derived OLSR.org = routing metric for [RFC3626].  It
=    takes both the loss rate and the link speed into = account to provide a
   more = accurate picture of the links within the = network.

Terminology:
= For when discussing =93UNDEFINED=94, please specify that this is = used only for the
descriptions of the = processing in this document, and that the =93value for = UNDEFINED=94
does not need to be = agreed upon across routers in a deployment?
= If that is the case, then please remove the last sentence =93Might = be -1 for this protocol=94

= Applicability Statement, last sentence in the penultimate = paragraph, is it possible to be 
a = little more careful that the example looks like an = example:

OLD:
=    It might be necessary to increase = the
=    data-rate of the multicast transmissions, e.g. set = the multicast
   data-rate to = 6 MBit/s if you use IEEE 802.11g = only.

NEW:
=    It might, for example in IEEE 802.11g, be necessary = to increase the
   data-rate of = the multicast transmissions, e.g. set the multicast
=    data-rate to 6 = MBit/s.

= Applicability statement, ultimate paragraph, I have a little bit = of a hard time parsing:
   The metric = can only handle a certain range of packet loss and = unicast
   data-rate. =  Maximum packet loss is "ETX 8" (1 of 8 packets is
=    successfully sent to the receiver, without link = layer
=    retransmissions), the unicast data-rate can = be between 1 kBit/s and 2
   GBit/s. The = metric has been designed for data-rates of 1 MBit/s and
=    hundreds of MBit/s.

= Specifically,=94The metric=94 =97  that corresponds to what? = "The DAT metric" (if
so, then I suggest saying = that). A little bit later, you talk about =93ETX 8=94 =97
= which to someone versed in over-the-air metrics isn=92t = gibberish, but which
to someone who=92s not, = most definitely is.  The notation =93ETX 8=94 is
= not introduced - can you rephrase that? Perhaps by simply = removing
=93ETX 8=94 and expanding = on the parenthesis?

Probably = a nit, but isn=92t the title for section 4 wrong (I think that it is = =93rationalE=94)?

Section 4, first = paragraph:

OLD:
=    The Directional Airtime Metric has been inspired by = the publications
   on the ETX = [MOBICOM03] and ETT [MOBICOM04] metric, but has several
=    key differences.

= NEW:
   The = Directional Airtime Metric has been inspired by the = publications
   on the ETX = [MOBICOM03] and ETT [MOBICOM04] metric, but differs = from
     both of = these in several ways.

Section = 4, general:
Thank you for this = section, this rationale is very helpful and educative, = and
= establishes the relationship to RFC7181 quite = well.

Section 6, I have some general = questions:
Any of these need to be = exchanged between two routers, over the air? 
I = am asking because either it is too specific, or too = vague?
= =93Floating point number between 1,0 and 2.0, = large enough to=85.=94
=

Section 6.1 =93Recommended = Values=94
This almost reads as if = it could be part of the =93The Experiment=94 section, = thus:

=93In the = community networks, where this has been deployed, which
=  includes [=85], [=85.], and [=85.], the values below were = those which
 experiments = showed to work satisfactory. Understanding that these
=  networks represent one type of OLSRv2 deployments, and = may not
 be = representative for all possible OLSRv2 deployments, nor even = for
=  all possible community network deployments, this = leads to two questions,
 where = further experimentation is required:

= o = Is this set of parameters generally applicable to = Community 
= Mesh Networks, or are there adaptations = required?

o Is this = set of parameters generally applicable to other OLSRv2
= deployments, or are there different parameter sets which = apply?
= =93

Obviously, = another part of the experiment would be =93=85and, can we = come 
up with an even = better metric that doesn=92t need parametrization at all, = yet
= would work everywhere?=94 =97 although that may be one of = those pie-in-the-sky
= things.

Section 7 starts a bit oddly, how = about:
= OLD:
=    This specification defines the following constants, = which cannot be
  =  changed without making the metric outputs = incomparable:

= NEW:
   This = specification defines two constants, agreement on which = is
=    required, from all the OLSRv2 routers = participating in the same deployment. 
=    Two routers which use different values for these = constants will not be able
   to = generate metric values which can be correctly interpreted by both. = These
  =  constants are:

= But, I also want to say, that it is awesome that you do point = this out so clearly.
Is there any doubt as to = if those constants are =93universal=94, or is there some
= experiment to be done here? [My gut-feeling tells me =93no=94, = but my gut has 
been wrong = before=85]

Section 8, first = paragraph:

I would appreciate if you = would point out if you need to update the Information
= Bases in RFC6130, specifically if you need to update elements = other than those
which you specify in this = document.

I would also appreciate a = pointer to if you use (but not update) information in
= the information bases in RFC6130.

= Finally, I would like to suggest:

= OLD:
  This = specification extends the Link Set Tuples of the = Interface
  =  Information Base, as defined in [RFC6130] section 7.1, by = the
=    following additional elements for each link = tuple when being used
   with = this metric:

= NEW:
  This = specification extends the Link Set of the Interface
=    Information Base, as defined in [RFC6130] section = 7.1, by adding the
  =  following elements to each link = tuple:

And, with this, I = would add L_DAT_last_pkt_seqno to the list on same
= level as the other 6 elements. I know that it is not always that = it is used,
but with the = caveat you give (which you should keep in a modified = form)
= that can be left for an implementer to figure = out. The extension in this
document needs = it, so it=92s something that this doc imposes on = 6130.

Section 9.2, suggest that the = title be rephrased to something like
= =93Minimum Requirements to an OLSRv2 Implementation for using = this metric=94
I would actually also = like to see this piece of information included in
= the applicability statement.
=
Section 9.2, what would happen, = would there be a possible back-up mode in
= case no INTERVAL_TIME TLV is included? Worst case, could you = not
= make an assumption based on a VALIDITY_TIME TLV present? = How
= bad would that be? Do we know? Or, is this something worth = experimenting
with (to the experiments = section)? Right now, that particular experiment
= is not enabled by this document (as it requires INTERVAL_TIME), = so
= perhaps it is =93known to be FUBAR=94 =97 in which case, = actually, stating
that (and why) in the = experiments section would be awesome.

Section = 9.3, when I read this my initial thought (from reading the paragraph = between
9.3 and 9.3.1) that =93Oh, = ok, so this tells me what to do if my implementation
= is not able to add the packet sequence number=94 - but then, = 9.3.1 immediately
kills this hope. So, is = this not a requirement, that would belong in 9.2 = also?

OK, I am being = intentional daft here=85..I think that you need to point out = clearly,
but section 9 does not = seem quite the right place for that, = that:

=93There are = these two modes of operation. In either case, the 
=  requirements from 9.2 apply. If you use mode B, then = the
=  requirements from 9.2 AND 9.3 = apply.

 For both = modes of operation, the processing in section X applies.
=  If you use mode B, then the processing in section Y also = applies"
= This, because section 9 =93Packets and messages=94 start out = looking more 
like what is expected = from a 5444 packet/message, but from 9.3.1 diverts
= more into a set of processing = directives. 

I think that the = processing directives are clear and well written (thank = you
= for adopting a non-ambiguous and clear format for this, it is = refreshing and
appreciated), but I think = that it would be awesome to have a slightly different
= structure, something like this (don=92t get hung up in the = specifics of =93Mode B=94,
you have a better term, = and this is just to indicate the basic = idea):

9. Packets and = Messages
9.1 = Definitions
9.2 Requirements = to an OLSRv2 Implementation Using This Metric
= 9.3 Additional Requirements to an OLSRv2 Implementation using = Mode B

10. Processing = Directives
10.1 Processing = Directives for =93Mode A=94
10.2 Additional = Processing Directives for when using =93Mode = B=94

I note that section 10 in = the above would have a ton of subsections, essentially
= capturing the current 9.3.1 to 11

Section = 12 - IANA =97 this baffled me. Do we not need a code-point assigned = from
= among the LINK_METRIC space? Or, was a decision made to = not do this, 
and to instead use the = 224-255 type extension space for this experiment? 
I = would think that if that was the case, then some documentation of this = would
= be good to include in this = section.

But, I would be very very = supportive of an assignment of a Type Extension to
= LINK_METRIC for this DAT metric = type.

Section 13 - Security, this needs = a review; notably RFC6622 has been obsoleted by
= RFC7182. I think that you probably also want to look at RFC7183, = and consider
if, perhaps, some of the = provisions from the MTI part of 7183 would not guard
= against a few things there?

Appendix = B
= You use Linkspeed here, but "link speed=94 in the introduction, = and =93link-speed=94 
in section 5. Then, in = some areas, you talk about =93unicast data rate=94 =97 = are 
those the same, or = different concepts? Could you do an editorial pass and
= unify this terminology, = please?

Respectfully,

Th= omas
=

= --Apple-Mail=_494A7F44-B763-4BF7-AE9A-926029B142F7-- From nobody Mon Jul 28 09:51:27 2014 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 1DB731A0643 for ; Mon, 28 Jul 2014 09:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mIuln8izVk2X for ; Mon, 28 Jul 2014 09:51:23 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9FA1A063E for ; Mon, 28 Jul 2014 09:51:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7C0E1247546; Mon, 28 Jul 2014 09:51:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E313F240674; Mon, 28 Jul 2014 09:51:21 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_0FDFE18A-E5B8-4D1B-B6CE-AB7258BDD0A8" Message-Id: <2CB654B4-77A4-4502-ADA8-49C1F1432944@thomasclausen.org> Date: Mon, 28 Jul 2014 18:51:13 +0200 To: manet , manet-ads , "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/VXFGSBj1aiQ5ZS2zDuTdFV1coY4 Subject: [manet] Ready for Publication Request: Advancing 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: Mon, 28 Jul 2014 16:51:25 -0000 --Apple-Mail=_0FDFE18A-E5B8-4D1B-B6CE-AB7258BDD0A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear WG Chairs, all, As we indicated in Toronto at the meeting, = draft-ietf-manet-olsrv2-multitopology completed WGLC.=20 The WGLC was started on July 1, and completed on July 14. = draft-ietf-manet-olsrv2-multitopology-04 reflects all comments, and = idnits, identified during the WGLC. As a reminder, this document aims for publication as an Experimental RFC Its official status is, currently "WG Consensus: Waiting for Write-Up=94 = =97 which means that it is awaiting assignment of a =93Document = Shepherd=94 and that a =93Document Shepherd Write-up=94 be produced. = Once that is completed, I believe, a publication request can be made to = the ADs. Ulrich Herberg generously offered at the mike in Toronto, that he was = willing to shepherd this document. The document tracker indicates, = however, that no document shepherd has been assigned to this document = yet. The authors would like to request that a document shepherd be assigned = to this document, and that the process for this document be resumed. Respectfully yours, Thomas= --Apple-Mail=_0FDFE18A-E5B8-4D1B-B6CE-AB7258BDD0A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = WG Chairs, all,

As we indicated in Toronto at = the meeting, draft-ietf-manet-olsrv2-multitopology completed = WGLC. 

The WGLC was started on July 1, and = completed on July 14. draft-ietf-manet-olsrv2-multitopology-04 reflects = all comments, and idnits, identified during the = WGLC.

As a reminder, this document aims for = publication as an Experimental RFC

Its official = status is, currently "WG Consensus: Waiting for Write-Up=94 =97 which = means that it is awaiting assignment of a =93Document Shepherd=94 and = that a =93Document Shepherd Write-up=94 be produced. Once that is = completed, I believe, a publication request can be made to the = ADs.

Ulrich Herberg generously offered at = the mike in Toronto, that he was willing to shepherd this document. The = document tracker indicates, however, that no document shepherd has been = assigned to this document yet.

The = authors would like to request that a document shepherd be assigned to = this document, and that the process for this document be = resumed.

Respectfully = yours,

Thomas
= --Apple-Mail=_0FDFE18A-E5B8-4D1B-B6CE-AB7258BDD0A8-- From nobody Mon Jul 28 10:46:34 2014 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 311B61A03C2 for ; Mon, 28 Jul 2014 10:46:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 eyL-L7Rr00bD for ; Mon, 28 Jul 2014 10:46:25 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58C81A0406 for ; Mon, 28 Jul 2014 10:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B71A2240674; Mon, 28 Jul 2014 10:46:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.2.231.146] (unknown [37.160.109.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BB5FB240098; Mon, 28 Jul 2014 10:46:24 -0700 (PDT) Content-Type: multipart/mixed; boundary=Apple-Mail-9F5DB7E5-062A-478D-9083-4BF6877FCED7 Content-Transfer-Encoding: 7bit From: Thomas Clausen Mime-Version: 1.0 (1.0) Date: Mon, 28 Jul 2014 19:46:22 +0200 Message-Id: <4857CBDE-DA81-4A80-9840-B3E6F43D7081@thomasclausen.org> To: manet , "" , manet-ads X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/v4_wcBQN8CgPFX7kZX95viTyYSQ Subject: [manet] Summary of Collective Next Steps - with some errors fixed (with respect to presentation in Toronto) 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, 28 Jul 2014 17:46:29 -0000 --Apple-Mail-9F5DB7E5-062A-478D-9083-4BF6877FCED7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable All, In Toronto, I showed this slide -- which reflected the collective status of t= he documents for which an "immanent action has been requested or suggested".= It's auto-generated from a(n ever evolving) spreadsheet I use for IETF docu= ment tracking. As it was suggested to me that this was actually useful, I'm shooting out an= updated version, and will probably do that at "irregular intervals" in the f= uture. Best, Thomas --Apple-Mail-9F5DB7E5-062A-478D-9083-4BF6877FCED7 Content-Type: application/pdf; name="Collective Next Steps.pdf" Content-Disposition: attachment; filename="Collective Next Steps.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAF1UrtOAzEQ7P0VU94VcWyfH3ctr4ICKcISBaKKkgC6IyRE iM/HXnsTFMAuPNrnzK53WGAHTXe/gUpXK2MRfI/9Cmtyn1sf8AYlh3y8r6lCUc50Sh8LVBip7Ijn VC6XUkidclOqC22CdMEaeNfJ3nReLCdcRDhPAfWJE+YxZqJxjUc0usVMSYPGMlAMAgPTihLTswVt Ip6SZgwu2bNlMP4Cq2IRzfJQ01845rP60KSCT4i3uI51ov+IA4kTJ3F2sHKwg0lizzXecZtjly9m wPzvD60gRceQd076+JuRUyGtzgfYIHvdOVcYpTWUfdAjChVTxp2HHV+LtPxdSNqPX5L/w/xm0rja YvENPbJ3wgplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKMjcxCmVuZG9iagoyIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIg L01lZGlhQm94IFswIDAgMTAyNCA3NjhdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Gb250IDw8IC9UVDEgNyAwIFIgL1RUMiA4IDAgUiA+PiAvWE9iamVjdCA8 PCAvRm0xCjkgMCBSID4+ID4+CmVuZG9iago5IDAgb2JqCjw8IC9MZW5ndGggMTAgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZQox IC9CQm94IFs5OCA0MiA5NzQgNjE1XSAvUmVzb3VyY2VzIDExIDAgUiAvR3JvdXAgPDwgL1MgL1Ry YW5zcGFyZW5jeSAvQ1MgL0RldmljZVJHQgovSSB0cnVlIC9LIGZhbHNlID4+ID4+CnN0cmVhbQp4 Ae1byW4bRxS891c0fBoC5nj25WhHsuFAihWJgAMEOTiy6CWiZcl0DOfr82amq3oWzkbRSIwEOpCc vetV1Xv9enSrf9a3Os904sd6o/M0dAM/rn5e259R4AZpkiVatmW69ustz1Uv9QftyZ/vBZGWg/Xd lS62PXq6CfTRzbwbqf4blReVp4jj2PWjLNah57l5Huo4d7PYj2Pc2NfF390bdSsf5ZPpwE/dPMwD HWe+68Vpri83+slKe67neYFeXWo/cOPqYHxZbfSj1SqUa6zWyjm6ufy8ufqwXejVe328klHdA0AZ pQWwHFeYZ9VYMDgJhpsmqTxxz+gkfBhdFPpulAsiGJ2qRjc8Jv2rdp4vBIJAOx/M5/ZqoZeNLa8X qvzNHa/Nodp8Xmxf4ZztZ7Pt00L/plc/tnFS9yJaiVMcpwKLhIwsCLzAzaI8IVDK8A80qAEV576b +WkkQGV1GvQCpYrgF0A9xhgv8WX7zgz2xnwCQxl8BSEQOq82KIcY3ppTgBcudYdTeWQb7bU5RDm4 7QbnyO0s6JYcSRi7QZClOk6jwTGrOuEbY8Zjbt+2hsznbQZchHcIZykCriTYbuLVZR9ItBLPxrst +1q80yxw/SwUzzDxniyM0XgraqYv3ro/3gyvOVc5Vnh9Edc7I15q86UJy7PyUzk9TMiizNhEkwkD JtjkhHP59tW7O3nmvSxwirWLo3teWrN2iV/kiW8bTRdu7jWt3fckA4SJG3hJaFy9V86llxfUBsh3 C1VplR623i6hRkZpu15SZTwQcrdHLW+MV16beJAZ1MmfEGuAL71XVg5v9cZcj7fi03ALnma75E2x 6RXG+LH9WG05bxvE2ZnfVFEvzCsQmvkNEbb5zYQYto0Q12QceWGVHCeGma6N9PYT0H5qIHhhPs+x 41QEL6rwtbMyu6pzlYNDeQ05suLMSd1wd6JVVlcWLVUroPrKqRIta3qAi6Y3jlaaxMYxm3DJQ/cW Oy2dP//06bMUcc9Ofvh2Wo+S1JXclLGMCwM3TP00GdF6lEkaS+LoH9b6O6P1362obPadQoZaNa0G yYDSkIBROjsQU4U77pDObNTOzmEbEMAZvlwcH0ECKHEuRDUin6hWKFEv5mBlayiqTnbtCdpYMqGC iBoU1AFNIGuBRgW1UBtSkDbVU+U9zr0VpK+HWVFQpqjskmhUQPpWHqoYpFTEkiyj2HeTPEz2EFBp fLXEJMnyK6iArNmb0Gr1ELOUcpjK1jZzMaux2F6y9GQq5UEmTUoNJalvTzo157f90zNAPiTBNpuQ vYD75Bp0QvYy1Utf9tIzsldBt3s3A5rZC2i1pTeQ6q30JrK0k+tZ//ALpi9kDFzrQcldyfmS5oqU XmM2Sjh84pT1jfF78hB7dhThYeqGNUdE0YlLoB7rnUnK8xV8VvdtNwi70W6QKXjRm5FYS651szDJ aR9J6EZB6nfyby2blPbh524Y+PlkGmPYRIx1rdiHUbhyADR3ImoMI8OHwnan07S6FVspyqsWB27A 6/F5dhTl5qDalH2OFemuFR1OXSgHGD96EQI4IC96kQniWA7oqItZ/TuppNkvIlzsF02AK06CqtsU zcXrHGmRrCXLkChJRB7y0FC1spSaG/HQP3BZuM4sPyqbBRQYdAmBjNqR3NPakW0wWZC8uHSGMVJx Fr7FhPmLGTifjdrEQxIBDJygwQ3QqMQBGNZaNrSMGNaCeTV+8ybbhTpIIVEYr1W+Md4gj9wwjkMa b5q6USYqbk98WsYr57hZHqWHMd6KhTWDm97k2OmnymHMyPQAbLVODajhxsx9woXquh/NxAq/cSR+ I2hSeE6IUTFPwNrG1Nk3HJaBosMiUhMcFtEaEwMd9viXs2O6Bkq/02MabneGdbLQflZ07xvCnDn3 7FnXMXUCp1HEArUcoBggLWs5YDGZuY9BHCqSX8Bb0ADyh+wv0NSiQcDXOjsMYRW7gQbHatnCGpwd RyQlkyiwL6bNLoq0GRlPPky7888dHGDRhCtr0TNoBS0GKAEJhCUJbZNqglgqdFod4XswpDszkkoy 8BM3S8N0rqEFqfSj/dCfTAskAxM4bTuk7NruYWhgEPiBu8CIWEGCSESZc1dE5K++SJSrBRPsary1 2o0A7Qph6NjVgEZREM6OhfSHTBv0hTHubn+o5F1ZdEzoD9UmSrz0ET1e3Wu9tTYB0ptywZp1oR/K dCYPfM260I8jN0/CzppDLR2z5JkNG8AC6ahhGoE2+Y9UAh+hadKQp+AIeCAM4ytaeNjRnKNq56EJ HfZTWLz0GqZzhWvxiY1RaWfJKJVr4ug1WZAS6QyKzifbJsDpKrIqEYYUaToio4q0a94YPFtMBnlp KMkuK1qbEOzIYm9wZM2moCQEArwmjAl0lHa+5NiCgKLpzGSBZ+d1dwXO6JR3LPpkVbsDpwNwns1j uYW35BcSlIto7AWO4iYrE7MYcfrcMPUJIMGj80khD4yFgwQVoBIOiaBxJHT23ou5dUYcNJGy1LKO ZBa6JxgSS5TZhvQYgAIeDJ02A0PCAV3YbB9Hj/ZxagkakbKzAwYCuxirbY/J2IEbk5lcTHAY/VJU DjW5Q4qVF1EOICTH0NqjnLb74gwAC+RJaRSArDMMHPbdA3kdyRrUQekodR2JiBetJtT8RYcwKN7L Cv1kcigAAENCDC2zvmGHkLftZ4LeyYSq1wh/kXjvHYvhtR5UeAzIUIXXtwKIqPRlYeQqdme+8xXA gsBe6nqBN75CVntTsCCwH0grPJ4MVIu+tb6d0Jc5ETSZ5naVF1jS00xI1pldloqrMHUKrCh69mRt 0VrpeSe08coHo0DWTliCxbxkZiiqJoqpAVEzjDVRRsa/7ysvNqGDhuidYPwDbSTmtWkAsIuEMZMv /IJkwpSK9POgrAD+o6tg8tJCEmVJwN4FYjMwZy4sQl4k9eTtwugwOa5qZtVKI6oc0y8Kdqp9VHqH NbGC4IXFCUZ4v+/LS8hWhLaj+wHeQ/fAd8yESfy92qcNBGyjnh3jPV92o/IJwT7Knw3B/9qXNZTR Jr9dAeehqG8nar94M98T1ziM9qu6oKb9b7oQA0Ogn2ytoTAzbI1LKKd6OO3IlKShlX3f7+7vXjIY HbcYcGK4xeyIjLuFar3OdrI3AmN1Et2CELTdgggMvKoGCIxh/pteVStfPWv9c1Cov8hE472O9Gnx Wpr8nT9jg3Xpy6KdpJ9yBulrWYQPy//v2egslRe9hSF227W+KP4X52/MXaFyCmVuZHN0cmVhbQpl bmRvYmoKMTAgMCBvYmoKMjQ0MAplbmRvYmoKMTEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gL0ZvbnQgPDwgL1RUMyAxNiAwIFIgPj4gL1hPYmplY3QgPDwgL0ZtMiAxMyAwIFIKPj4g Pj4KZW5kb2JqCjEzIDAgb2JqCjw8IC9MZW5ndGggMTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZQoxIC9CQm94IFs5OCA0MiA5 NzQgNjE1XSAvUmVzb3VyY2VzIDE1IDAgUiAvR3JvdXAgPDwgL1MgL1RyYW5zcGFyZW5jeSAvQ1Mg L0RldmljZVJHQgovSSB0cnVlIC9LIGZhbHNlID4+ID4+CnN0cmVhbQp4AZVXS7LjIAzc+xScwAXm Z47xVnOC+SySqXrv/osRAbU6sZOX2YUuqyV1IyCf7sN9ura7tLm9FpdrdF8/3Q/31/k1+rb72ORX 9nnftyS/agqhluy+fveoErK7utj2tbW49NVFVy7nuJa0d0i+pNUf9wsfDYKc61qL3258F/l2LBcK mjkeefTTWYmQrEWqnkRYKtFi5I9M+HaU1Gpct5CVCUtiQoRi0mnvza8p7luQKrpcrfmt/9py3GsL UziEmHqASELvV++rSmirkWYPvgqnkO8ppZC7P83XEHxaxJ+DZFcoy81Dwmz8CJ2Q6NZT2qfq7dWd qWCYUWrsQmlGG63sZZMmZZvJJos5drVqyt1HacPILKnawTtEMUcJLNYKeWLRcrBIQ2ARM6tCqdS1 RNknt12uq6mX2BFC9KF31LYSYupdtpw63HtTFpTMFpn2qp1Tfhozgu4tsvJVBZZeMaY8S/PEoq7W mUWW9MwOYFS0FrIQNpLG0FJJRRQrUlltvmtX697iTTvZHQgxixQSB1TcFPO6lTQdwmIkeTFDZJAV RwZpKiE25UB/zM72MKEqYO1cbNNb8Sc57swRS17PD+q9ujMjDBs9iIJWGdp625oZAWcW60SliTWs eyxtOEOr2dfz2eHjTXnZGZQL0Yj9Mf3j4WaEJ/0DIsJDksmIb43xUeTeut40xIhIxSbjO1eLhtjF 7ABhKJatpTXKlTO0p9XQ/r2xAPFC4lMyCEP8qj5BPaV+uiCcrhZgtCUpXmMdYcIpA/Hu1YIENBrA zCJWDRbdJ5Uz6vvbX0NEthM5AIWy7jXWaZGtnoxH7/d4tWgu2Q5nOhlm/LOAZTOILTKZySKkIYtC bGtsW3AXuafnC8+w24viqCI5QJwYEo3n00kxEWpI8/3NgdbgAHerDhCx3Da0GmleDAkfUJQLMgCj u4P4HwvA+H/fGVjQGReu1srLcfWbn5cirZ7srfNni+bi8VdMzEC3xI/OrADeWwvCaW8B471l8Wdp hPM/xh8JaPMBo/GnPrBxCRvavWHRrJ3Gn1hUoZr636eyjfGn1Uhz2Hy93/H4p4eLAzGNPzCyiPh1 jxDEFjHlmQrALN7G37A5qu+e0FqzaGZnge0BYJTgpJCZdJ7Qotiz/2egsSkChEtU/jTLK1j+vcgB 11+jWGlvzx8wbBGIzaIFGFlE/LpHCLqzCOHX5UwFYBSPKSJs7LRpkaj1+n1pSc0iYDZF0ImP8Iek H/8AyeFlmwplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjkzNQplbmRvYmoKMTUgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIF0gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRp YUJveCBbMCAwIDEwMjQgNzY4XSAvQ291bnQgMSAvS2lkcyBbIDIgMCBSIF0gPj4KZW5kb2JqCjE3 IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiAvVmVyc2lvbiAvMS40ID4+CmVu ZG9iagoxMiAwIG9iagpbIDIgMCBSIC9YWVogMCA3NjggMCBdCmVuZG9iago3IDAgb2JqCjw8IC9U eXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1FZVlJKVStBcmlhbE1UIC9G b250RGVzY3JpcHRvcgoxOCAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENo YXIgMzIgL0xhc3RDaGFyIDEyMCAvV2lkdGhzIFsgMjc4CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDMzMyAwIDAgNTU2IDU1NiA1NTYgMCA1NTYgMCAwIDU1NiA1NTYgMCAwIDAgMCAwIDAKMCAwIDAg MCA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMAowIDAgNTAwIDAgNTU2IDAgMCAwIDIyMiAwIDAgMjIyIDAgMCA1NTYgNTU2IDAg MCA1MDAgMjc4IDAgNTAwIDAgNTAwIF0gPj4KZW5kb2JqCjE4IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvRm9udE5hbWUgL1FZVlJKVStBcmlhbE1UIC9GbGFncyAzMiAvRm9udEJCb3gg Wy02NjUgLTMyNSAyMDAwIDEwMDZdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTA1IC9EZXNjZW50 IC0yMTIgL0NhcEhlaWdodCA3MTYgL1N0ZW1WIDAgL0xlYWRpbmcKMzMgL1hIZWlnaHQgNTE5IC9B dmdXaWR0aCA0NDEgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxlMiAxOSAwIFIgPj4KZW5kb2JqCjE5 IDAgb2JqCjw8IC9MZW5ndGggMjAgMCBSIC9MZW5ndGgxIDE1NDc2IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AYV7CXwURfZ/VXX39JyZnkkykzky08kkE2ASAkkgBCLpQAJi5D7MYCIJ EOSUQPBGCMoZUfAWVhc81nPRSQgYUJes54qyuOu14gEqKh4R1h+LBzLz/1ZPQNmfn99/Oq/qVdXr Ol69evXqdYVQQoiVtBKBaLMWNTaT/XQOct4A/G3WVcvUB/zvfUMIvZMQw5Q5zZcv+tsF9xYSIh8j RPru8oXXznlE+c96Qmz/IiRr7tymxtnWHf94jZBCDe8P5hnOYuNhpK9BOmfuomXXRLfIh5C+D+na hYtnNU4+VfM20ieR7r+o8Zpm8aQE+gE5SKtXNC5q+izj0uuRruLp5sUty+hyFkN6NtLjmpc2Nee+ O3Yf0p2EWP6CPIqH/6zEQJ5DrJJob46e/V8B09MCEYkEzKCnZGL8L6pk0vS7ueZzuZZz2O8jVmTb eotS9Niuhwpx6LGTpCJOA6RLe4kH4JUeJR4xTDIISXwJAM8TX8bnJY7xch6zr0Hd1QuEPEZ20Hlk B9lHXqAn8NbTZA/pJH8jblJF7iPLyZ1kHcY4HTkbyCQ8EvLvpJ5EJykkD2D+HyAHQHsJWUH2EhfN SHxFVpI1wlt4aw16nk0qyQSymNxCL05cSerIYfEmUkouJleQZtqaqE3cmrg98TD5E9kj/C1xhliI l8zCcyDxnfSvxIekAG/cRbaQw/R20y6ioZVWUN5PlpKtQr1IE5cnfkYPssjV6INIxpIDtJtFUHsT +ZJm0OXCSNTyUCKWeAlUflJP5pKtZC8dREezLKkuMTZxgLjQxjWodQvpILvxdJHnySFqlU4kHk6c IB6ST8ZgPJ3k77RbiJ9ZFa8A3yRwqS8pQ8li8hfyKnmThuhf2WLJKhVJmnRd4m3Mx0AyFb19FG9+ QX9gK/CsFF4RRyVGkBTw5TbObfIy+YR6aSEdT6exvmwx+6OwFFKUj3cHktlkHvh9L2r/mEbobmZl B4WHxCfF04bM+JFECmYkTP5A7id/pTaMVKUt9Eb6Lv2MjWQz2B/Yp8Kd4uPiP+VGjPoysojcQp4k P1AnHUIn0kvpXLqcrqO30S30AH2THmOVbApbwI4Lc4UlwvPiCDyTxRbxJmmtdLPhWLw2/lL8H/Ef EkWJtWQi5GEVen8X+SNGtoccJO/jOUw+pRK10BQ8Ks2iU+n1eFbQW+iD9DH6OO1EK2/ST+lX9Hv6 H3qaETwG5mNZLBtPiC1lV7M72X3sIJ432bfsJ8EtZAsRYZBQLkSFxejVOmEznl3CJ6JXPCgmwOci 6W5pm/SY9KT0gnTCYJVvNBLjG788dKbfmY/jJL4+fne8I96Z+ISkYw694EKQlKP3jXjmY77vhsQ9 Td6iVvDOS/vR4fRicGYGnU+X0GvAydV0K/2T3ven6HPg0nv0OPpsY369z/3ZIDaCjcdzGWtiS9hm djvrZO+ynwVZsAh2IV3oJ4wW6oUmYZlwrXC3EBPeED4SPhVOCb/gSYhmMShmi2ExIo4WZ4hXin8U vxS/lOqk16XPDWbDIsNaQ5fh3/Jgebg8QZ4o18ub5N3y28YGSOeLZBd5BhJ47kePCKuEamEXuZUV ix72d/Z3yPMMMlsYyyCp7DG6nt1AO1mOdI1hGBtGx5ETYhi8foVtY6fYMGEsraGTyXw2MFmhIU18 Ali5+CLpEZ/D2P6Omq8xWOkKdtxgJR2UsDIoy5eFAWJEeJ0cEg5TWXyAfCCaqZv2sEeFCZCC58Xh Ui3JEu4jTwlL6A1kF6smxHzauBFyPI4+Ab0whRbRH4UEEdg4SFGp8Bm5iSxg/yI9WMfryT10tng5 uZUU0+XkS/IIVkVf6QpDP0M6fY3NE9tYKu0kTHwcoyujOVSQ0shqWi9sNRxn75MryUHRTD4W/oze H2RPCWPFE9IkOhcr4AaylixJrCLXSrXiP+nlRKDTSK54BNptuVAkZiFeCa1SB522G6t7L/RApTAW ORmQnIshF1OhIbbiuRd6QoQEzcMavwRa7O+k0zCFdZHLpRQKrUOI+Hp8EpmeeIRsSVxOrkjcTgqg D9YllqPGx8jnZBN5jK6JX0+aSQAr52N6sTSKHZRGJQpYG3ufTWZ3nz+/4HYuzSBf43kKMzNcepa0 ie+RyaQisTHxDqS7DzTsFjKTXESOYpTfoYULhW5SHB/H2hOjhGaM9zCZmHg0EaRmMjexkIzH/vYn WSKNcgRzHKP/xHivJ01sUmKZ0BSfBz5sAhc0cOtK6J8N2sipUyq1iuEXlA8bWjakdFBJcdHAAYX9 C/Ij/fr2yQvn5oSys9RgINPv83oy3K70tFSnQ7Gn2KwWs8koGyRRYJTkV4dGNaixcENMDIcuvLCA p0ONyGj8TUZDTEXWqPNpYip/rxFF51FqoJzzX5RaklI7R0kVtZyUF+Sr1SE1dqAqpHbR6RNrgd9S FYqqsR4dH6vjm3XcBjwrCy+o1Rlzq9QYbVCrY6OumttW3VBVkE/bLeaRoZFN5oJ80m62ALUAi7lD ze3UPZzqCHNXD21nxGjDEGPeUFV1zBPCq6hGyK1unB2bMLG2usqXlRUtyI/RkbNCM2MkNCJmj+gk ZKTeTMwwMibrzajzYhgNuVltz+9u29ilkJkNEevs0OzGutqY0Ig6qmOOCNqtirmvO5rxaxKVO0fW rvttqU9oq86Yp3LitrZ1amz7xNrfvOvL4jVEo6gD77LcUQ1to9D0RsxUzWQVrbE10doYXYMmVT4S Pqrk+JpC1TynYb4aM4VGhOa2zW/A1HjbYmTStVkdXq+2J3GEeKvVtim1oaxYhS8Ubazyt6eRtknX 7vRoquf8koL8dsWRZGx7ir0Xsdp+izSB6ckyHdPJOVYz6RxnKe9RaExMg0TNUtGT2hDGNIQHTUNI 26whmAD8ohRvxWZjRubFTCMb2pShPB9DpDEpVwmpbf8hkIBQz7fn5zT25hhylf8QXsjl5JyoxWjj WTwWicT69eMiIo/EnKKPw/X0oIL8q7pYKNSsqIjAPjIBvG2MDi0E+7Oy+ATf3KWRmUjEWifWJtMq menrIFphJBpjDbyk+2xJ+lRe0nq25NzrDSFIcqduxKbHjOFzf3bFlVo9d2iMuv6P4qZkec3kUM3E 6bVqdVtDr9TWTDkvlSznDAXfUNaLxVJH1go+hjyOMZ+gl0Io66afI0Gi1hoTc/Fn0IV6dpdshFTq OVQdFVMaLkyGUXNWVu+a+f+91JU4wd/So19f6x1GbGikt6PJbseGnZc+r3vWNqFmClQOq5kyva3N fF4ZRC3ZyzG9ESSeTKnNUkfGyFSszFz8dSW6h3CI+mIaWIaSKVhFenbU15s8j9DX+1IUPy6dBfmj oDPb2kaF1FFtDW2NXYnWmSFVCbXtYS+wF9qaq6HtkoLTldh7sy82amMUHJtLh2J5MDKiPUTXT2zX 6PrJ02v3KDjPrJ9S28EoG9kwIsqnhY2cUtvLFn3OuOhjDrHDQF1zAxcHG4HIOJ05shy5CCg2vV9U ofsXTSKniSp2gwrCVUm72Hy2CLT5mqeZNQtsLB3LGA0R5pWaQeARm2/JiIxTjtYrX5DCsT0DB5Al tD51UFZ6JetLu3bt4vUwMjXxpeiQuolCMunUdsa7p5m9AVFKC9hsblNX4lin3c6mckTz2GzAHMTK c4jLakVo5XmkMBKJHEBwgFT0VKApX7vhf9d0EjUZeE1fdNpsOvKd5rFYgDmIwnOIYrXykOedq/LX OjsNqkfxQ8Q6mGr5C9SbC+AE2BNHtJmiYR1bb1lvfy1FMsmWDFadenH6RZ6Rvimpdel1nkm+BfIC y6zUhekLPA2+a9nVhqss19nXGe6V71ZeyzjE3jW8a/nA7j038BaTlhUqGWCixKSYmGlz0NFCIFZa CnJVbNKMbA68enNGRDlVH+lBsCTS0zt0Wr8Ex50h/EcB0Wiq4hxcXORyOdMVZghl54VTFVdx0WCH Eg5ly4apC97aflXHshHz33rg7Wtv2/P48uWPP75i+UX17C0q0gv+PGNnPHEoHo+/uOPeZ+j98XuO n8AZYv5389ZyGcC5m53G3JnJ05oqaDZHyQJxJdvEthjFP4vURAwSE0wStTK636z33szHRKiKd7sS RzoVBVPXlfhac+gT6tcnNEWfUHBZ8/DpOjsn+vx4rZJms5dIZzkxQKIqzl1M8lj20nK6hiQFbkkE fIFE8B84Uz72TDmpqHCXUUfZwAG0ntRHskIOg0EeNHhwaTE73Vn51pR7Pi1cJl4/fHnwqdH7Z/Cx lcOekzG2AH21V5ZMDsWWkZpqmGrrSpzsdDh05DvNpCjAAmlSgIuomxMEArw04E9BSQACirCLPatZ mdntVoOKgzE16HCWFb59gIcHSGEP72kFD1+CkeXrXQa8QavTyfQGNZPdASzZzhHN4kxlUwNpPI/X 3YGq+VKxWNhUIN9qOhd/rzW+Rnh7vDW9MW3wMGmY4Vlpn+FZ+VXja355jDVqnZKywDo75Trndakb nM85P/d+7jvhte6zPJPKfIpfyVQCiuEvOCTLEH4jYhNmyxswK0aDYb/fm+b3e41+r0CZ0esXbAGl iz28c7yDOrpoxi4+AqKzw06Z1dzifgvc5rJOn2Wr4H1R6BDN6thVgcPsYraSiWwvyyFBuqk9Kewn IeyRcuUkpL38THlFz5n6ow4nn1kE61L6R1JuUF5CAvOsLwG+AoaQelq/NBrNTc8Kl2LGBw8eVALR N8h5g/m6SE+DJOBPlH8pZe7ch7Yef2zL9TfeR/ek/viPt05d+OgLD9YFduyoLJ/VveKlz+csuOO+ ttSD73+9o/aJ5x5e38hPTwynTCIq0l6sAxsNa4Odtda51q3Wx62vWaWLhYttd4qCE7wgVoMgS2aL IBMrhGK/IKYJgijYCLPaRFl4lj0LFwCj2zUzEUWQkP1msYvNeUaSzFpmsMR8dsUA4QqMTQXyna7J zF20VLPJWnaoRG7NGiRvtjO+Qiy2tBLCFKYyAekj+jtAju7mEsl2pXTRjTpXv8Uq0RfMSS6G5coX ir5elJPlp8odZZy3ZWXr+kdEsNZut2MFYQPfQ2yJjzucZVgLb2uW4jIhu6BMEDMzy3kVUSwx0Ghp Vs1SZm2dUGbVwmXWbD/igjJOEIliYxlEix3F6SGH4KDs7jOr2f13vPJKZ3wQnfEnYfcvF/0p/gAm /64zC7AWG8FfF3xbNtKspbxkoyL+mFE0gXd8XQ1gVDRZbS2CwLggjddFR2Beu7HF9A0Zj8P9DCZU IFpMV0KpeTDw2/nAxykn65eUjz3ZM045xbWEAqHiUlXm0MeMgS7R9ysDEQxyaLDTWdoo7NoY76kZ bN8j3Pg/G8Sfd2y8K+6Mn+76YAf9mr4KF6VAJmM/80BvuEmIDGAkuZQ7rcQX6M/nBPqBTe3f35kV MEh9Ak5bwGTlWg+b0klMC5CIHapP3/KAJBc0R/RCe4bAC7na1BGuNYGcTG6MQk66la//dL3GdH1j TD+7Meq742+2SOidSE8ZlknvTvmM3hF9U+QdAcI7clTfMTmi5/W2z9Uymv1Fy+aEvFm+bfIGechH +uv49E0JjaEtyvfn3wIa10oHuWhf1xjXmPAX1q8GSKYBcBvcQJeLy4xLLEutV9quc99M2uhGca1x lWW1da3tFvcbjldSndmQ5w6/6uWRqhbyqEANI9ICfVUrCWQQK7qxvT/9tSeBln0maupil2tKpMWu qdiJ7JTYFTuzd9HbdhdltMQEKqC8I6cl/ewGo6Zr6Sx988BzW+3J+h4uNZEeIL1jq9cHxxcJJIbr G/6DxllClkSjNBweVNKrZmQXlA0JZRPkpKbxPTipiIQ0168JOr954Rf7ur9esGjdLfFT778fP3Xb zLUL5q7ZMOfy9UPHbJ686rEdN658VPD1vXf+9kOHt8+5p2/+S+ufSxBKuzf9lU6Zu/qmGbPWrf4l MXbz+Edab3ziMb6XzUl8KV0lvUUyyVu7ZrH5mYwmRQu7KxBtBrd3VFJkmwXfxLLMVrI6czPZKj0p /Mm2R+i0vWp7kxzN/J9MR4oz05GZKfQz9HH086vB0bZpaZekT/PMlRZkXu+82blV2JKy1f8YfZg9 5ngnJRVeEq+SpnhFqJyPO/qUoc1uraBPmWInVPSlBqyCLyCalLD9IhJWKaXeoDusGqkRMmyYavQE ZtXpKzRSP5avT4Rc58O4c7g5n6GyuJ0TidCl1G0QQ9k5bFCJM6e4SHTLYa7dWXqak3NV7HzhgviL n/fE3/vD03TkCx/S/GH7il+44/HP6hZ9sfahTxkbePz0X+kV//wc1ueR1wu23/5g/Phtz8a/auMf A8A7LGopCN1uoje0Oy18DObU9BJjhtWlr71jWhbHjEwQVNmYJstGJguC0SQyZpKNoqAaDLBWvtUX NJDvoZSxyiUnX/RI/6B5+XCletVCVcsES4Ol2dJqkSxGk8pNpG7NhsZUdEPttZVO6TWh6JSuzoH8 rFl0u0nUrVZU2akbsV2JHzUzX5Gk3jwsyg1FXfFyVQ8Vp9Qv6VX2XNWXV5RDemEdla0T+0fW3fBS 0uLZQ4TEkWesjhKjioBAaw8cAIZHoNo7jdqoMuiA7t2jyoxaURItKpOzPWV8und7gBYlUZ4b0lHN EiqTU9IAqTx9cncq0Mwkmgk0naM/tqcntwjekv5Dw2gaewV1FDtC1HHfqwLb++ovcWnv6VXiyp9H ia2nW5NzVQfd+w3kfABL1/JmCbPEFmGZKObmDRLK/COFMfLFmdXBqpxReZOFqFyXeUmfDakpIcyJ rlBzziK5ZxGok2RR3lkExGA7tC+IkwiIkwiIkwiIT2mjOFEfWziH5Qh5uYPtJaGq3OrC6eq00NTc hZb5tgUpc9KaMq61XGe7zn6DcmVOS+5aoc2ywdZmv0VZk3NT7u22u+13pwd6Dc+CrLDTF/aawn1p mJC+XqdYNDCMDx2M2Aqu9W3wMV+uy1YQyMuluZILQnVS0xWyFCgwBQIuQV81EeinekBvVK8bTIU9 ycenFeTmpNgsUpY/M+CD8w6+OwPNzclGnkEK+Aq8qJFN3eSl3h58NdFXsi7BClXpBDhBmulmaqBd NKalFvAmedPo8UWmMOlL+8LC70xJYVOBnNRsvKa+3iKMiYadfGnwIiBgH1YGkB81O6dxTuFy7xk4 69LkTj32KMSgR+HKAEJ8Th0oZ+ojR3lwkpuAUA5cEVOgEFYCRX3uh3NRammAQSVwtZsXzsnTVTPX za5enZGe5naJbq6lDTgo5YTrnrHN+NsNi5+YPKFuWHzhxHmXr/j+zod+Wivtte94PPZA2RD6fm3r dWtP3/9q/H+20PeUK265ZERLVfXlIXdjpPShpsV/nT3vjVUpN9+66tLxxcUL+gzbddWVB1uWfZWU 1QmJY0KPOJx46fRec78kZaWd2i1Uw1ezZlgSotNvkTP8Ir6upMtGziVZ39NlfX+XcUpFDt/fIwfe fkWfZOWl+iIOfGMdbbLSoH9k6kj35NTJ7obUBvcf2B+ErbaHlYe9VqPNY57P5gnzpSutzbZW2yPW Xabd5l1Wq8u61voZE1KyZ9gX21faBTtO+U9o1w7AiXMCaUC3NpPt5AiBxU/sdnzAPNdHP7qek2Lk Cicl24eJy7FEghQfVynVuGKiGj8m0Qu5bqJeTkbH+NNzDso0KFfITE7hRLKZE8kQLYQDfSUv9aqt +iXc6sevfmmv62IPodzH0rP0ZKRnae8+XOgoK1Tqj+JPn3nMdxRbAyaSOEr0E/C5Web7glDennn8 qUPxH5Z+tWHHh8GnPSunr3/i4dXzb6Vr3M8cpJnU/GfKVj39gG/BwhffeveFG7mdX5M4JgYwZ+nw VUzW3EHiT8cmUC/Vm6ZamoQF0mJTk8UI2+GobpU7gGiT+FAz/TzMc74v/Zx2yisOdA71DPRXOsd6 K/0TnfAN+Budi7yN/msM16SfYqcyFHxMtdvc7gmuBlezS3D57ZuV7QpTFNHnN8tkL3uCj17XWvpS VDjXFHD6rlRIi1uDTf6hvpiAJA8IQL7WtwUg3Zopr19JzEZt3iBSO3PDJTzWKgOwiII06CpWcmQt p18Jn5jxsiCruqBl8DUpYyAIk5OF4zqmycWHJnsCJaXJ7ZpPE/aYsWeOjlOw+mBY4zeWb91Yo5Gj FT0wBuvLzywp148V/KCmH8ih7ZfwnVyfLoUUFxFHmpyl20U0C6sVO7pw2d787/Z8FT9O0z58B98b fzlm7lgza+OZQ2yidci0Dcsfp9PcD3XSIBXwca9P/OP4T4r69N659K61I+c+gkXH8IWJ0HLs5dy/ dUC7zDSYj2y8abNpuylm6jYdNp0wycQUNDWbWk3berOOmBImcxB+GHzvgjfDIKyg8GsYRLNBzpWI uE3cLsbEbvGIaOgWT4iMiKr4JlKiCEWmTxGQnzU3X76iyHkomnmrYhoXeJR9DSIdietCg5xfNDPn rDjOOHrCb/ZteDKWYufmR5SKHp15XNNx9i1dEkkdVJwuYHtc39nZKX5z8ODpdDF8GtcmKL6vEVqq j/mz3ZI+YOwQ3TtLh+helJ0lg5LxgIHJODs36V3JTXeX2GH4bJMOS+J4BCckISg1S61SQhLhKDQz IVe3UHhNuqWSXjyoZBuh3VAOjOAg/yb0hIiSJBd0QyWTc4HoXCA6F4jOBWLkLABFkgVAEmdtmF5e kHHi+bzgzMBRVWcHZwFP8R+sBMdNndLen0fx+a7Ces3DerURD12wOz2Di2oqN305wk9VWgvHPHqB UzZ7rKMNFxqnGaLGyw3zjMYSZahzqGtQRrVS46xxVWfUSXWmSUq9s941KWORtMg0W1nkXOSanXE1 TTcZJNulwhRpivlS60KhSWoyL7Sa3X5RdvgtlrQcn8bXjQ+aEKvnnMNLRrtIJxU5P9jpOpAj+ppK ngOxuDiirzW+TFNzcksGyJTIiqxicQ487KM+nj+GL1/gKTnEmsLdo05eOdwIEDmCTiDUly2BZwjM tuoshwsVuIYqg6QCDBvo5cuY+xTP/nqwiOtP1f+a8aufcUk9WcJP+abJ0mTTTGmmSaT1Ud1YS1VK sa2S5DZKfnvUqXp4w8sfUNf139x8ON6zp2Pd2o6da9Z14MNu3q1XxT85c+CbG2mA2t54/Y1/vPz6 fn3NrovPE7Mwh0544mZqt1qVAuUCpUYRK9SYyoJqX2sosyi9KHNEZrO6WTUOdQ/1XeS+yBc1Xmqt c9f55hsXWOcpi9wLfN3qW2kfZXzkfStwNO1o4IiaUF0hMaJE0geJQ5VR4kXKdOVzyzeZccXiSIHK 9RtkanD5UywkxZPzppkqZs3cYG41i6o+iao+odwTo1n4KdysTyXSP2Omej0zfDaRk/Q6AzmmhTi7 zctoajErduYS0k1hN22nMXqCikFagdsgAhT6L5q+Tihc0mwqhUuah3wCqX40AsUpXWfopC5+GKe6 vUcx48A9wdGlGZQ7N87Ooa45xipnTsJOOpuHLRWapAd/jjLdWwYf2ZKlZEkqXDK6WwxGEPcWh/Mc OJ6eO6que3jo7XPXvzn/ysPXT9/U3/HIVdc8+eiylvb4POn5tokTNybufSh++uaLh545LTx84KXX 33l9/3tcB1XA1mnHHA4Q3Nr1YnZa9lDTRaaqnGnZTdnLTbeaVuc8kvpk/guCzeT2ZrgH1OS/65Z8 bCpjShE1Z9QZ60x15jpLnbXONt843zTfPN8y3zrf1hnuzLNzMy6n7+Cc6eaoZXZ4dp9loWU5rTl3 mO+z3t7nnvy7Bjxsftz6UN7DfXaGXw67+vDJ4DzKPovAoE/m5JxFdBo+TToNR3Qajug0HMnECUdz BsqmG/NyrWbRq4bTRUv/TC83lbI9+Xyqgp4Kz3jPDM/TnoMeg90T9Cz2HPaIQc8mD/M8j6WYDvWk 7+IaNCDD5q1RpuCmDCNUofx43r0zzVXCY01JcZRQ2r8uc2Emy/Sny9ghTkJTYAvhfsDezeMLLZUL gujvbwnCSs/xaKkZJUX89UIunp6MZMglyqN/N/HgQAnNp/K3PPpnD4++k3u62KUdck4/vLrLX/Zm PwrsC12mgSQ/xegI5wOQr3W/UD+v3lQW7IqGou4iVlHUWsSKuEWSQ/SF0ft5RU1ymU3VEd4BjiT9 /GqOXRdyu949u8q7ChX9s4YuAkvhDdp1F5M9+zChFbjOwHA66DU76peM7RV37kRXcFBYOg5n3Ihu NS6B/fHrYtDtRRBV9CzhTjB9J+EHCGwhcCXz44N+Nho4YOS1mpZXEAhJaflhh+JUUhXBkG1TfcTU R/ZRqQBBIA3JrJSQj2SHbFZjX7OP9skzmQ0R0UeCSqaPQh0q5Up5MtDPs/0iq1at0rWkvhTr8U1s KdyMpb0uoLxwHu4YlXAv9X8dTNwudwBODW4hhSs67BuuX37NoNw7XtkyvnJIv9sm3/D8dEfM2jJv +XyXq9C3et890+a9csPB9+kF/gVLm6ouCGXkFo1ZNW70tX2CkQuvvzxjUt2k0pA/M9WcU1y5vG76 tkv+zNdpTuJ71k/aAt/lv/YQM2QwFC6BZxK2IZBWD2wgq81MBeJS4B00Qz0KFruSTbKpzZlrpQnZ WG2qbpCb5VZ5sywS7E/b5ZjcLb8pG7CHfadbQ0C4QtS3we/1ox9yfsSq1HN+1CUNOT/rgg3kBNev 2AMNfP6RTu7d8l42n2TQwe1zfmsgYSqh4nq4e+PoSRhKPdyZy9Wbo7hYeY2bCZFIrpvzLzzIERpU 7CjV/c+6940p3ovLZy7MX716565dqZE+gQe2KcObHmSzNlJ5YfyWjWfuGJsPNz8lCIRjuGNppl/3 ntvckpGYjQZqMBPJZJQok3L4AKXCyEcHlI8OoHFo2gquZH3PDJIoyXaUmbkGsTnKTC6nv8TIA3g+ vt6JGEtej0HxL80UyCohfRAgdUwzwTYjLgRIHdJW9OlfQlQEdmtf0scUNpeRQeYLyWjzNFwpjBpr TXPoHDbPOM90DbmaXs2uNV5jutq8jq5ja4UN8npjm+l+cq/pNvOfyYPm58kzcrv5NfKy+RB5x/wt +cx8mpw052M45gziMvchYXOpeTzRzCZJc7pKJPiwSs5+E8N4+NAJ+nRSs3PlauafZGFVgBc8T9+U OFf0XCZJVguWWOFHEfAGcCByIEIKKyqQp7uDzbLRmGsyp5lMZlwSY7Ax03CKlMxmgltFRnxfNshm k0CoVGil1myjpmmw1Zmpi/p2aTBOmQRMM6lMo9mWr//JpaPH6zlTf6bem9FzlDtAIA5l8HjxVVkB 4Vgn6Q6vdf0zuN8ripMjP4n8xtyJREh9NIsWp7rcg0tTiyl9Kr7wL0dzgxmRb/fErxDDZ1ZfvnjK VWw9t7a5fOCOrvBvyIdCP+yVj3Q7tRhEZjIwgw3DsOu62F4Y4VJRoXszfc/YndQO35mBy8UET9l0 +93i3Ua4U+3dUrehW37dbrJrrjKvkGpKt3mVQXSoZRW91WIsdF4iRuWopTblHnqv+V7LM6zL+jfL /pQ3lEPCO6Z/2D5QPjc7nb1zZbESp8OeYYPaRTvH8IkQmN2Ay43EbGYG3Q3IGQQG8MinzTHgg5XR ZKIGgwnXubDY7QqsR2q32xQLPkwzm0WwKmYDPOhm5RXyiokpucSEC8kmgdlewQEz1yqkWa2C2WTC pxkD7Bl81DKPd1LnGNsKa7bZ3mgwrdDw8cr3jGaYYGg1CIYuNlJLUYUVLHs8eDnGsVx3AdSfTE4i 5lD5HN/+vqg/N4N8Hvkc1mP2+CTW4yMV4d2329cZX1qXoryUDBHJKUp5ubEcc8w/YHWmZGSWwZ/7 sWbJxLcpN75gufV0R1aZwnWeOb2MZmeVmTT/WX8kvmstITjbRmDnQhCKoZEHl5YCCwl51E5Xx7d8 8lB/f37uzvfit9GbPzo0NP4V60PjP40eMKL4dNx65u/0omi8HuOCS5lt+nRt2cIZ9vL/GH3J6+MH T4/kEkT02A6LinvswUudnhfgPXl4fBwZqZCfn/75Otzt4DX99ucyIIvf04RtUSm2kKmAw4BygBfQ CJgsvUrmAO6TppE6kZAJyKuhr5L1gJuAVwHWIb8C9eQg9gL4vXMXnqG4M7uW3SdcLDwofiu1GRrk 3cbNOC1/bZ5rucian0JSbrc/qOBmvd4zF/keJ+37cdZmuN1RSKbBXTRXzMQFE5wPQeHs7b8B96LJ xOi0SRdNjVQunde4cOwUnQJEiTzc1/29nwuZAmrlXxnSsV95iQ+3ogeSwWQUuRC3wMfjtvpktHgJ bvNfSnBdeYoAGzAj+OZzQl9yBMCEvh2RzOAeIU/I7BgW1LqE0E5nepG9skBQ0a9CPVQRLgY8DdgH EMkMIYBSBeFKQCvgacA+wJsAAzoV0EtVxIsB2wBHAAYhU/B34Nt/ZZ7gwbsejNAuuMlxQAIgkCDC QsB4wAzAJsA2gEGn4zmLASsB+wAnAAaiCe6O24vRd3fHzXq0c/7CIj3ZmEzW1evJnZdEk/HYicm4 akySbGiSbGBJMrv/iGScl5+MnblFrah8p9lW1F0JRxQG6ULHmxFS9hKxQzMHyXYhncQATEBX9RxN cO7MCRdt2yeIhApMoLjSHkx0C7TD5iiqNLMEO47JD7LvWE+yhPXsTHEUbau8iH1KngbsAwjsUzyf sE/ISnaE8xxhBWAbYB/gIOA4wMCO4DmM52P2MbGzj0ghoAIwA7ANsA9wHCCzjxAq7EMud3rI8QoA Yx8iVNgHGNYHCO3sELBD7FCim73VUVpWtEdHIoW9SDC3F3H7ehGnq6iL/bPjp76QqDBmGhL1rJBN hpNiIbsjd2CwS8joKJ8X7GKf7VQjwe2VA9jbJAZg6MnbaPltogImABoAzQADsHeBvUtaAZsB2wEx AKQMoQJQ2X7AG4B38c3jXaIBJgCM7M0ONNPFDnaERwQrXbgc/ioWSZAdYPyfO4LsDfaKHr/OXtbj 1xAHkL+fvdIRCJJKC8oJ3lEQK4gLUS6xv+7McQYTlQ62DxwMIiwEVADGA2YANgEMbB/L7pgddKKS Z8l+6LYg6yBf6fEj5EEj0eYHtfBICKDKg/DQC4Ah2KZuCzMtfPcWJHkQvvV2YDwIr94IjAfh61YB 40F44VXAeBCePR8YD8LTZwDjQXj8FGAIutgfn8nJC5aOX0DVSju7Gly6Gly6Gly6moj43wM85Cdo uCD7Q0e/fuDYVi3St1+wdS9tfY62TqKtD9LWJtq6grauoq3ltPUy2hqhrX7aGqCtGm19lg4BK1qp 1nleskzLoK37aesO2tpCW8O0NZe25tBWlZZqXSyrYwxWHaJqPdpZyRcdy9p5wXBoHzvLAkezIPNZ 0An7EB4EJPSUBiI1O0nsCfA4e2e/imS6/9CixZUXshfx4ouYhhfJYYCICXoRYvQiKnkR1dkRVgBm ALoBxwEJgAHU2RjHJj20IywEVABmAFYCjgMMeneOoyuMLEbIu/i03rFChBWA8TzFXsTD/7kji2Vp mbgsFFEuFDb5qT1AxwcSAVZKXFx5Ox1GXAey7f7B9uMPNmKqNLFb2SZ8oA7iXyqS8aaOnzKDXfTe jvCzwcp0eg8JwO8YpGUkTHMRDyEtenoQ8Rt5fgnxsycRF3X4p+E1e0c4P7iXpvC3dgd/8h8NfuXv YkCP+Z8Nvqd2ibQj+A5yntwdfNu/IfhaYZcROc+FuyiivapOusc/JLhjv066CgVbO4IreLQ7eIN/ dHCBXy9oShZc1oKUZg9OCk8PXoj6qvwzg1oL6twdrPBfFixPUg3i7+wODkAXIkm0Hzrb1683Ggro FU4t7aJztXz5brkW3vfBcpGcL2fJQTlT9slpRqdRMaYYrUaz0Wg0GEUjbhUZ0/i1hwjfUdMMulFg gEDj1qaOK9AwlKsZhLhcZGT4d4FYqlDDaiaPoDWx7lmkZqYaOzU51EXNE6fHpNAIGnPWkJopI2JD IjVdcmJSrDRSE5MnXFrbTumtUeTG2PouilutXTTBs9b4+J1zfJChjjW3+HjcZ80t0SjJcF1VkVHh HO4oG1X1O0GDntlQddYhhTjjPDwzdnfN5NrYE5nRWBFHEpnRmtgd/FL6Hvwz0Ynqqj303zyK1u4R htPvqyfxfGF4VTRa00Wn6XREpf8GHSQGEeiMAaJyOqIaA0m6rUm6XLwPuhwegc5kIrk6Xa7JpNOJ lNO1t+RUV7XnIACNWyUtOk2LW/0tzf5c0OQiAI2rlezXafa7WjlNbLhejd8PkgACkFD8h5JO4qde nUTvebtOUthLsuEcyQa9JSHZG52GB6jGduQsje0IaH7DyP8bbRoBa3bnsOisumpc6G8IVTcBGmI3 XzU3I9Y6U1XbZ0V5Ae7VhxtmzprL48amWDTUVBWbFapS24fp7/1XcR0vHhaqaid11VNq2+u0pqqO Ydqw6lBjVXTn6Aklpee1teFcWyUTfqetCbwyfD9X20fr7/1XW6W8eDRvq5S3VcrbGq2N1tsiuoxP qG03khFRmPx6vJNZzJDXBl9WdIRLaR6uC++wrIwVvr2wVh4jFly0t+JfM2wALtcFlQWVvAhrihel 8P/a6C3KWDEsy7eXPtZbpCDbERpBIsuubLmSZFTPq0r+teCHrGVX8qlIhhGe97s/kFTjHzCqWpYR UhPrN7kmVoF7+O2yjNyGqijyhp7Ns1iqcU5JZvZH5lBOKAjnCHleOc8zmXoJ/7cs6H1CNrizB4bG szupFqDLSEtUiAVqpjCoginTwQbc3t8LW4pvEi1w8S9rwT90tZytjY9Dx3u9WgTDbjkLy67sxXp5 saw31l9oiZBIy1mWnK0uwpmlBzqvluEATv4fgwzecwplbmRzdHJlYW0KZW5kb2JqCjIwIDAgb2Jq CjExMDc1CmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAv QmFzZUZvbnQgL1BHRU9SUitIZWx2ZXRpY2EgL0ZvbnREZXNjcmlwdG9yCjIxIDAgUiAvRW5jb2Rp bmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciA0OSAvTGFzdENoYXIgNDkgL1dpZHRocyBb IDU1NgpdID4+CmVuZG9iagoyMSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnRO YW1lIC9QR0VPUlIrSGVsdmV0aWNhIC9GbGFncyAzMiAvRm9udEJCb3ggWy05NTEgLTQ4MSAxNDQ1 IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAgL0NhcEhlaWdo dCA3MTcgL1N0ZW1WIDAgL1hIZWlnaHQKNTIzIC9BdmdXaWR0aCAtNDQxIC9NYXhXaWR0aCAxNTAw IC9Gb250RmlsZTIgMjIgMCBSID4+CmVuZG9iagoyMiAwIG9iago8PCAvTGVuZ3RoIDIzIDAgUiAv TGVuZ3RoMSA1MzU2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1Ya3AUVRY+p7vn kQc64SGThGFmHCbvCAFBIJgMYSYkJEBIgJ3hoTNJJiaRQArirODCplxwZUBWZYkKlso+WCAinYTF DlkgIpZa6wO1cFfXKmV91paU+wDLFUnv151kllBK5Qdl37p9z+uee+53T/f0GWIiGkGtJFLFslBz HQkUgOQD9JyaplAzmamMiM3grTWRFscj6SWHwDuIxGhd811NX0iPvUMkPUsUb7tr1fq6785fvkB0 w2uw/6A+HKqVss70EN24H/y0egjibzalgP8I/IT6ppZ747awkcgigTevWlMTotVUAj4RvLEpdG+z OZyQB340eMfqUFN4XuRnreBvBX9z85p1LepGCoP3g09rXhtubt+f1gkeNlIjaXvrvywYxqkDlyaK 0Uzwr188YJ9IRtLWzwPPhl6yGI5ThqGVUqSJZMfM99Df18a+JepnhpfJ0tek/kvMx4xurQt9hbOo lx6iPXQYnvaDzqA76HF6lRupm1fQEXqXx9MtwFwihcrpNVbVt6iOfgf7FjpFu6gD62dQE42Bdge7 1Q3gPaCrabP6G5pA0+kBOk4z4HUHnVcPqF3QVtISOkjtmP9ndgkd0ij1OfUTnN4i+NwMzVtquXqY RlIOFVEFpJvpBLvF99V6slI+onuSnqa99AJ9yffzEbVejahn1HPIBiuNoyq0jXyEz4mHpQfUJ9V/ qH1AIoOysGqQdtJv4f8wWi8A8/Hd3MI7eZfgEe4XjkhbDGP7LgOHTJqLVkJr6EEg0E2n6d/0X/5K sIoWsUV8SZ2q/ocSkGvl+k7CFEH7JdoO7KmHjTyJ53AFb+Rf8y5+R8gSlgh+4afCvcJn4gJxhbhe fEdaJ3UathseNyb0XVR71JfVszSWbLSc1tIm7O4UnaEL9C2L8DWO3ZzPRXwHWivvEbp5L3cLFdzL Z4SD/CF/zF/xJcEgJApjhGyhRdgptAunhDfEBnGX+IT4oXhRKjAIhr2GT41u09/6qvu29r2h5qvn 1G/wFJnJiZMpogV0J4Ww22a6lX6OXRxCO4xTO00v0at6+5jH0Xn6BigQj+QUnszz0RbwQq7jBn6K j6Gd0GP5WsBBCHFCkjBWGCdUCdVCk9AqnBVaxVQxS5wnLhMPo70iviteEi9JBmmUNEaaK5XSdqlJ 2o22T9ovdUpvGmYYCgwLDEsNrYathu1ijeEtw7vGTcYdxk7jV8Z/mjJM5aY1pu04nVeRsy/oz8Tg TeIJiH4yns4a9nI1teE09nKIosiuWn4QeDVThrpS3CTOFSYhG07QfcjW3bSRtooraK/6V/Eg/QWZ sgoOW+kPUhHZDI/hdO6nSciiwbYTZ/4MPYunoh0oEWX3LdGfOqfhBKUTeTKzMjPS09wTXDc7Hfbx tnGpKcnWsTeNGT1qZJJlRGJCfJzZZDRIosCU43MVBx1yWlCW0lwlJbka7wpBELpCEJQdEBUPtZEd 2rwQVEMsPbCsu8rS02/piVmyxTGLZuXmOHwuh/y61+VQeNkiP+iHvK6AQz6v0/N1+mGdHgHa6cQE h89a73XIHHT45OJIfdQX9ObmcLcHIMTn5mgvFg8laI5lmhPaWG/FoFn45BSX1ycnu0BDJ7p9oVq5 YpHf5011OgOQQVTpxxq5OQ0y4qRtibWu2m2Kh6qDGhVa4ZfFUEAWgpqvpGx5rMsrj93wqfX/7CDl 236FUhbcxaFwtFj2BLcBXI0NalxoO7iyKgfcClsCfpm3DAShxdiISLVwwy6fFlew0SHHuYpc9dHG IMClSn9niifF5wp5AzJV+DuTPck6k5vTbd2U78Tuu3Nn587WxnyndVP/+Pkv+uVv92qjddPpjzCW VcYAYG0lVynilB01+iIuBDtdu4WnU7RmOnDCFWBsswHxzJEF5Izolg3u0pDcWjUYRr23P7hgo7cz LjlF20OwKAD7YNQyEycFe4vLEb1IOELX+S+HSkIDEqPbcpE0pXbQsVyROTRIR3RgsOt6q6teO9+I fqbgXVbfFQLwGjRazPJoeXJZhd8pOwIQKJSdU6ZQXIW/g3lHQGF1i0JeWzfFkXjnHVDnaKnW4MX6 YHJzIMhygrolx1GMXRdrueKIOqKltVFHsaMeySS59RGKcDQwEQhW+YETLcaKnkBqjAwHAjPhZ6Lm B1NgHg3AQ+OAB4y6aOJlGE3KKcOppFX4F/nlVm+q7PEGcApI394Kv9yLzA0EYJUXixQRb2ywDsQ8 GTHnZUE/pd9LFXzARSAa1XxW+V1OuTcaTY1qz1s/rzBdLfAMCBTSTLBxn8KtFZiLweVM1QQup8uJ sAIaprcipQczSqGp10Z4WixuzLwN0U7TEZ5+nRCeMRyEZw4L4fxYpEMQnoWY8zWEb//xEC4YgnDh tRH2xOJGkLMRrUdHuOg6ITxnOAh7h4WwLxbpEISLEbNPQ3juj4dwyRCES6+N8LxY3AiyDNHO0xEu v04Izx8OwguGhfDCWKRDEK5AzAs1hBf9eAhXDkG46toIL47FjSCXINrFOsJLrxPCPxkOwv5hIRyI RToE4WWIOaAhvDyGsCdVpivfw61XvXbpur+YV1wBOb6U8JFchLrvDOo1kUzUoFBVtkLmiQpJ6GaL QnQGXeMt3STysQvgQJl0SoQ+7gNS+I8+v0I8MbWbmF8swI+oLiBNQHy8INBNEndjKmOqAdSkvClJ zqR09CJph/Ld3w3Hv52jSPMvdaF+PI2gzhoeRVXg6jCzwlM8iZJkSpRMbQaKnxtniZy2nj57eQYV Fl54PW/SqKkFfNuUJFfS6Rd3p+3oFb+Ojgrs+3a1+DX2NlDLzq3t+NWdN866SElaSU705qU5/x8H d0/4vR+sfTEaM/syiRL5m/B35xMeiWn0ebgJhpFUJK3TYkV9thp3ba5Abeh3A0eBLGgriUxfxNtQ s2paRiXZv4IROqqY61tYWZldEl4VCbc01IT0+bihSg5r9fn3XAJkqOq1M+JjwBGPQTafBFmAgikT pcFIGCzPPsk9ONShkj/RzCESOslHaT7dTrehJh2c9jwFaaEuSR1whPctbK503X2VazrGx7HBZdk4 8/6PDoVKkUKF6FPRs7NnW6mV99HD6M+gi9TA22g9+lb0J9ClGHUAXDdv65TMnmO8nlJ4nidBsi8e nWy3xifY31bYeOQp+3vWj3s4GX/AnOPkzhEUNzuen+GnqZbs/Hty8wYcSAbv7spcZQ9CdYCa0VvR Rf3OfKBz/GT7Cc4ht8SYk0bjJT5q/zwv1/5pniJwp/1UuiJheGE8OM+N9l7bU/aTtrvsJ9Db+1UH M2Fx1H7Atsq+c7zCuzvtj9oUxpxH+od7bJh61N6U2WavzdP15W2K0N5pnwH9Uk+Cfdp0p32q7RP7 xHTFzOBzbeX2rLzX7RMwEWYOOHV7kuzjbDvtM6Eab/Olz0Tv4YO8h7J4T6d7nv0YSGy3qzRzepvC 93WVZOS5Fd7gmVaS0ZZZku7OLLe7M4vT00EvfcW02bTcNNs02ZSNmjXN5DSlmkabR5ot5hvMieZ4 s9lsUvjZzkK7sYfbqRCwtHeZjWaDws9BKPXwIV146HmzZBbMZB6tqB8d0VJ6tMLtR5DNjJdA+1Gj ThkVPtTVLzrksUsaJekKCxKY8WxodxLYLNA8fPw/pBhpy02RQmvhyIKkGcXeH7oFdc3gPfuHLyvb 5DZ8fsoHbQF86YNQbYFBc+sg8YNjyz1QhYuys8sq13dFmhvr9MrF5QsHUcDI2yKoJFurHY6OxuaB siwtWF1Tr306h8JysyvslRtdXkdHRJ+nia9Q12nqiMvbQXW+xf6OOk/Y2xnxRHxaBddVXbR25ZC1 tsbWWlv0PWsVac7WamtV6/OuWmulpq7W1lqprbVSW6vaU62vpW3e11BVtK4F2YnqBtVFRpVcumiZ H0V8wKvwPq3kuYfof7zduJoKZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iagoyOTM3CmVuZG9iagox NiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9ITlBB R0orQXJpYWwtQm9sZEl0YWxpY01UIC9Gb250RGVzY3JpcHRvcgoyNCAwIFIgL0VuY29kaW5nIC9N YWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMiAvV2lkdGhzIFsgMjc4 CjAgNDc0IDAgMCAwIDAgMCAwIDAgMCAwIDI3OCAzMzMgMjc4IDAgMCAwIDU1NiAwIDAgMCA1NTYg NTU2IDAgNTU2IDAgMCAwIDAKMCAwIDAgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMjc4 IDAgMCA2MTEgODMzIDcyMiA3NzggNjY3IDAgNzIyIDY2Nwo2MTEgMCAwIDk0NCA2NjcgMCAwIDAg MCAwIDAgMCAwIDU1NiA2MTEgNTU2IDYxMSA1NTYgMzMzIDYxMSA2MTEgMjc4IDAgNTU2CjI3OCA4 ODkgNjExIDYxMSA2MTEgNjExIDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDAgNTU2IDUwMCBdID4+ CmVuZG9iagoyNCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9ITlBB R0orQXJpYWwtQm9sZEl0YWxpY01UIC9GbGFncyA5NiAvRm9udEJCb3gKWy01NjAgLTM3NiAxNDg5 IDEwMDFdIC9JdGFsaWNBbmdsZSAzMTk5NCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBI ZWlnaHQKNzE1IC9TdGVtViAwIC9MZWFkaW5nIDMzIC9YSGVpZ2h0IDUxOSAvQXZnV2lkdGggNDc5 IC9NYXhXaWR0aCAxNDAwIC9Gb250RmlsZTIKMjUgMCBSID4+CmVuZG9iagoyNSAwIG9iago8PCAv TGVuZ3RoIDI2IDAgUiAvTGVuZ3RoMSAyNjEyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAF8fAd8VFXa/im3Tr1TMi1lZtImJIQEUiCI5FISmpCACASJBAuCgiToiiAr2ACxwKqLfWHX hrhKIIABdcm6KKgorA3bt+KKgroRvhVwVTLzf86dYPm+7/efmXPP7XPue97zlud9zyWUEOIgywkn 5iXzZ7Xy/nw59uwX5ZJrr4lNvuzy2YTQ+wlR2me3Xj7/+xc/+pQQbTQh8prL5y2eveh1XzchzvcJ GTNnzmWzLnVfeyCXkKkmrq8WO1w/Sn2wfR228+fMv+a6b18IPI3th7H9zrwFl8zakLH1L4RMa8X2 vPmzrmuV1/GPsP0xtmNXzZp/WX7uZAPbZ7Bd0rrg6muk75XHCGkqwvYdrQsva/1xzuFibG/DQ0zF Poqv+DiIQrpQx8iF1h4mdloffnaFSETGWemP2ltrRMearXfrbGXH/ZzERdzEIB7s9FoHfMRPMkiA BLEVImESsfZmkiyr/uUim+SQKNoSJ7kkj+STAhwsJAlSRPqQYlJC+pJS0o+UkXLSnwzAsQpSKe8i mVZ5gmRKhSSTkNTnZ0vyytTn4lhyXupzdhQPjX8UpfezhLxHEzRETlEv2UyzyWtkG3mfFpOl5A16 qdXeMyyfxKh4+hCZTDaR16hKmkhH6kuykUwl/5Io+R05TPuSKWQ/dYEzLiCPkAk0I/U0+Zqy1GE8 8WDSSNZSv3yt/D69iciUs1tTZcSJK28GVYaSh8nbdKm+PfUuGUhelM5L/Te5n4ZYMWjYSr4gJ9C+ UjaINafmk1lkGfkrVfgI+Z5UX3IVOcNXpB5FS1RyPv53JrmB3Id/HUq72Gb5UtC2lowmY0kzmU+e IM+w2fIJ9C8DNeeh7XvJMfoM/Ygf499LmnSRdIdckKzFf+aCooPwZDPJxeRqcge5n/wFjBKlk+gD 8oCeG0GTGO7QH+csJzeR20gHjrqoh2bQKfQRdgM7wL6RnpLfTx3AWZXkWrTpZvJX8jL5mvybKrQf Lac30Z3074yyxewHHkuR1Avo21FkEplBFpEbyVryANlKXgA1/8rG8xF8EW+XvpZ+TO4BX01Hm64n HeRV8i76zUuzWCH7F4/zW/mjfD8/hSfxSTfj3MN4CsEf5+F7Pp7/arKErCR3kT+Sp8kOsgvtOUj+ Tj4in6PVg+iVdCn9A32enqY/sDjLZUPYAvZ71s52sX/yAJ/IJ/M2vo4/yF/hb0seabg0TnpE2iF9 qJQqx9RZyceTn6UmpKalbkzdnXo+9VLq7dQ3GBdOi3v7krmgdRueaxko+Sz5C777yCHyAfmQfEw+ B9cR6qCZtIqOpefTC+g8upDeRdfQe+n99GX6JrMxD8tgDayRXc5WsH3sAK/h5/BOqUgaINVJ06Ur pWukFfIAfMfLd8gb5U3y0/IJ+YziVTZpRNvfU9zzj+Sc5LXJ/0rZUq5UTqo8NTd1CiM5B703i1wO mjwEmjwG7vgzJMAeSLK/k3fQuo/Jf5F/kE/Qwm/JGeqnARrCN5P2BW9NoFfQ6+iN6MX76UP0UbqD dtIX6N/oG/Qg/Tt9i75PP6X/pF/Rb+gJxlmYRVkeK2Ez2Ry2DN8V7B72AHuQvQY+OcAOsvfYMdbN DZ7Ly/ggfIfwYXw4X82f5gelDCkIajdIv5GWgOJPSF3SX6W/S5/JRDZkn5wv95XHybfLXfJe65ld SkgpVK5SblZuUR5XOlVJDajV6k3qbepD6h/VdzS/lqdt0J7HUxTRME3Ln14hQKfRV8hmfh5toivp ZOqkq2kT8bMS8kepjY2VHmZrWDGDJIZcr5HaRc2fIndxytzSWv47ei/ZTik5h9xCh5JF9G709Cu0 FdzVlzzId/Mkq6cQC/QxOoic5gcgl94FtSppfzqKjGX7pDflvTNWsnx2Ef1AukjRpVfIPex5qUWq kihouxgiehW/k1STb/jV/AhGxXxpLUbkUiqRc9k55CTq98BDBi1g/UgtHcPDtJHPphE8p7j2XUiJ uWwLqyV76L3sSl5Er6cDyCmSJB3y38gD8iTp3dQEaXsqhj1LxJORTbgPnpHewVukPqmpye/oSh5i f+WF7Fz6b2kWm5t8ljbQSvY570+vZtfQH2kHLQIHvcbGs2E0wh4D758i/wIPnSH/TbZK9/A7U//g TycnshdIvjyDvAWJppCJbBf9lrwNefoXcIUGmfuMVE2286vICd7COlkP/Y59R/5AnoUU3swS9CNm km5lpnSYfr7ARXP4bMg0Rh6HVL6Yf0OGpT4lUXpN6kBqN83EeNkFufTf8t/YAnI35MVfIFFugByb BW6eRxx0MUaAC98O8P6/IR+C6B4ZMvQqjNMHIS93QV68C6lxDMc/Jqcxdh8gHzFKGpWH0fIT5CU8 3w9UIzuhfzZD5g8iR1KnpbdAu23kNk7J31SfMlRaQV6Ud6tDyabUQMj1q6C91pEd9ENpI/mLOXyy WTv03CHnDK4ZNLC6qrJiQP/ysn6lfUuK+xQlCgvy83LjsWhOdlZmJBwKBjL8Pq/HcLucDrtN11RF ljga07cur74l1l7Y0i4V5o0eXSq282Zhx6xf7Ghpj2FX/a/PaY+J62bh0K/ONHHm7P9xppk+0/zp TGrEhpAhpX1jdXmx9jdG5sU66fSJ07B+58i8plh7t7U+3lqXCq0NJzbicVwRqwvNGRlrpy2xuvb6 a+esrmsZWdqXbrHbRuSNuMxW2pdssdmxasdaezCvdQsNDqXWCgvWDd7CiObEM7ZH8kbWtYfzcClu wwvqZl3a3jhxWt3IzHi8qbRvOx1xSd7F7SRveLu7xDqFjLD+pl0Z0a5afxOb247HIbfHtvTtWn1H p0EubilxXJp36awZ09r5LNyjrt1Tgv8d2R5cciT08yZu7h0xbeUvj2by1XWhuTFx8urVK2PtXROn /eLazLi4Q1MT7oFrWUF9y+p6/PUd6CoaKkPjRPPFo6Qf6rK8OrGn5YpYu543PG/O6ita0CGR1e1k 0uL41kjE3AlbIlIXWz15Wl68vTYzr2nWyKwtfrJ60uKOsBkL//pIad8thidNzS0ud++Kw/nLlctA 6fQxa806XayNm/QTOaloUd6YdhN8dEkMLZmWhwcZJBaXDSKrLxkEquPTRHFV+6Xohrnt+oiW1cZg sR+kpO1ygZEXW32KoNvzuv/16z2zevcoBcYpIg4K5viJwdrprLPr7SUl7cXFgi/UEehItHGotV1V 2vfaTjYlr9WIoQL5SOM0XNY0uAw0j8dFr97eaZKLsdG+fOK09HaMXJy5lZhlJU3trEUcQa+lj2Rc II4sP3vkp8tb8sC+2yzLOKNdK/zp5zYCvro5g9tp4P9z+LL08XHn542bOH1arG51Sy+rjpv8q630 cUFQ0A3Hetdo+kIQvF0qaFcKxuSB4yZNnyZ24CcX1OfVzW0ZjRGGNrb7RkzjmUyMA6yxTG7dCmw7 Y/rZ+4mNaQ5xL6lAEU+I8cPBttYOGqtvN1pGp5dNtni8d1D972s6Ve0XF3WmToirrOrny3ofuX1w Se9DpR+x/Zxfbf+qdY7VfNxkCCU2bvL01attvzpWD3G3enV9Xqx+dcvqWZ2p5RfnxYy81TthIY5Y 3VoHQZXu/c7Urtsz2+vvaMKjzKGDweOMDN+SR1dN3GLSVedPn7YTLlJs1eRpW2GBjmgZ3tRUSgjk KXw0fKEJVDJkG6PPKWonO2WGiCw9x4lNlZ6jJKwp8nOMt+u7/xEqMU4P6RkywTg5ZHzPEFKLdeMM Fv3L4564pwALCpfpTIx3nTFl8iOJSV34h1SKVvMtkgv+SCH+icCT4HQeDpRuJxRKsA8poVsUNmLy tMwOClXTSe8x3aMTKlelcl6utzqXO5XmkiZcKO7D/oT7yORi85yARCUuSW7VID7q54ZkyDFegGsq pcnSSt7BO6QO+SX+kvS25If24EylVP6QEfUo7eQxE14cHk5571ioBA/UPP7kSVLbU0M93pogFBNt bqa+gXGV02q5ig6omsO3UM9//pM8jnZTkpF8Cfo/A15gi9nndn67utzBbRpdzamm6ooiM2pTXpR1 eSUZY7NRnRLd0JneSSeaho2OsW2MwU5n5Fl7/dWCpM1Huo0jzW2ktvvIEKMbDfDWYFHTv7yZtjX7 4qqiqAOrqwfm3U3j5X22r80a3eC7hWZ8/srj/Fbj/CmiPQ10BdvBHgJ1K808MqaBw9vaCHoZ1KSM XsE3Erilu8lx9M5pqb5v+k97mtuOkLLm7v7lvjiP38ZKB/e8zR5Kfo37TcdN2/F8nBSYQTKG29hG 2FhWs3dj57PS2Yb3HAHR0je4l2YNTh6hGbiBRaOlhEi/k7tgoYw1Z8A3sJG0j+xTFvvpgz7qLXOX GaXBwcEGd4PR4G/IaAhM9d3re9TX4dsV2h7tsnXZu3xv+z4IHfZ9Hvg8eNJ3KnAqGHF73F63z+2X yl2mq8t10CW5OukVpscDL9Yt9rVbe2XsvWiH4XHMxNPsYgtJNs3aKsnGLtZG3GyN6YzMXaOmVDCD oTLwfPGOOJkbo5R2sgUdhod6dtEJJMb9W+6zaHWyuds41dzWfVI87pFmMH7zEHQRNbqb05y73SF5 /JKLYCd+TeCftmbInJ3EmTq8FR3amfrPVk+N3pnqQmVLV/Z05UhXznTlSlc+XLDFUYORUdL7aSKC G2hBdXXFABhHiqpIiop+G8oGVoM7qioL83IVlp08mvv98298NXrSOcmTU4vomeozt7ouufflexP1 lVNHjJzN/7t4/wf/eHrq5paR319Ykfxh3t82Pn9XyYSF/cbOuBwc+UTqC+kh9FkEvmm3OUeLyQlW pVUlhmvDE7O1OYlrtRXaOu2hwBPaae2HyPd5LkWjimoL+lW/VhweGKtXpwVma3O9V+DMW7Tfa49r 7yU+U44Fvkj4iES13MzGAlpwmWFrsDFblNKZdD39hHK6i/4Rh7O2huScTppluj3OMnTF3GVkDTkM dutkbaYvd67bSYnTcAp5cNyZcirOTnqeaRRnzjUzlmcwkmFkrM3gGS+wN0gfuoEdJFbPtXVjfKHj mrubMb5E5y0EyzeLYS46Swx0ArK2UbkQBFQVNU1epuTlFhZWGSQ+IED9gYoBwmAVFFakh5LfaiNq xtRM7N88Z9PHD36x/PqXr6QzaPZjL/VUzRg5ecjE6cMGttZKkwNT6wefv/PcY/vWJz+/6fp/vUJv Y/nbzjx6zVUT5m5ZOP/87WLcvoMx8pb8BFCjbWa927TXEJT/SFR3ByWTmHSUWu+od02XpylT3bOl 2eq18mLnYtdi963y7a7b3A9ID7ifcu9z7nMfUg85InY3deu8k/7JNJg7BhSkAUP+APxZIVIv2sGo pNscHMTsYBGP/gJtJzaMBgriOsS5M8kGiIewsYs+QR8C8SyheORk9wTj9Hiw/RCL6Y0e6hFEa2sm zSUlPiGcGAPV4uBB78B3BvK9JTP+8eKQ8/3J494Rk04/Kz1C9f1jk4eSv3v8yIKruv5FO1+H3iE3 pY5Ki8BnIWiEN83mwdrgggbtSm2xtkp7QLvX/2/2vXYydCru0FWekaVmaUVqYbAmZ7J/rna5Z4l2 m/ag9pT2gfpBxgcFX/Av1S+1L0JfFgRuUJdoTLBZLDwzj+Zd1mqjbhu1dfKM7Y10LeTgWTYLOLME m/Ux5PBc4jN8zBcpis01nY3OFudap+S8UQiCuUJkMhJOvPBtLy26m8FFoEbz+G6LlU42C876JSsJ qvgKAha7DBQcVFVJKgbAjSHx3EIq+EdVMgQ3VVffRJ2CiwZNKm++fNPHNPLlmx8mH01+9uQ+9u7P TEQnBabU15y/c8jRfYfpjOQ7KZL8Tc8/dvNJ18y3mGjydsKAgxH5EuhEldhowJz8iU5NB405Wh0f 8nckqcGxWNrtOOg44ZALebFUpE/hU2z3S/fZVF0njjFknDJWMx0K0XSV2nSdyYqSq+p+VdWhMXOZ 7mdM1ztZ01ZJs3WyfaYLWoXLElNUlXFN6WQ3mfaYukxljeonkKTPQ2nohLMm0xZlZayVHWYS/Nod ppvopt6qH9SltC58Af64nW1lz4HTwlC/baebQ93WSgjUHTLEAL95a8qEhdG9Uu5X8ltjz8p+IVGp xpAhK/cMSctd09BNT7hSL9IdlQ061WXJGtngzbQMbm6jC0kbhZykcWg5TiV/z/Ptydf4ubThm+Q/ p1yQ/AMdmXxB3vVDPcDGCT1bhe7iQOWI/Cxo6gVmVER6zKGxYjrFoBvpk9ENxV3F0qWO+5QnycFi aapvarTFfqJYKrEnHOXF3FcUzbH7E3YtlBONRgn1Y5T7fYJwwcSBIloUK/qkiJUVNRS1F3UVSUXR 7Bwcg+HFYlFxUqmXaJQYoaKYRsu0BRrTXs8vMospcRmumKvc1eJa79rtUl0XtRbT4pxd7G4SZfmm pwvAHisnJhBXTob0IcFdbBObCsoK46Kt54gBTl0IGdjWXWKkzTZhunlqmtvK2rDSS9+zMlGVh8Ci gwHUDHambRU0PiCYw4TKCQjFI+VxwcAQh4nCvDweT6/nxSfRCnrq0WHz1k1YdVfbsnXJ/3x+4IuH Vo00z4nf8NWbNO+5346bd0PyfnmXzT193YVLOvpF1196S/ccfkXfS2sGjXYoZxJl84aMmZm2HV5K fSF/J78NTHur2a8B5o3pMt2SGgwGS/QSW4l/tNzgHuUfG2pi0/l0xzodmiHsanDPdDP3LvoM8bLX TZudl0EGmqCI2BXGrsGSTooW0N2UNViqh9Mb3UWCtMz1uplND2fTWLaZ3Zjdki1lB4pMtVFtUWEZ py2EBzuyagacVSltzQshC042N4NXhT3Qc7JZ6H1LmzRTWSF5MeKp9OZXDJCClmJRQD8x7qUltLwp +fDx5LfJv79O57zzDS2MJD8J3bbwtx/c9NQNv/kbM/p9l/yRjqSVP9D1H6c+zlp+9f3JF//Y3nU/ CMOAwBN5P/jSg1jBQ2burSE6kFR5xwWneqdGd2XsDL6W8VpAj3q9vZzn8wru8hAtx+KuCPgM3BUu IjYDCjhixmksTndjaERfACt5AflTNvJ/slOMBDvZpi14doubjvQcmWA0ty0UYvCX3NTLRGkSpHlG yvAL3aDkJfDk0A+9LNMERrn98X4XrvnNBf223zb3iYv+9sQDT/x+aNOSy8ZW3rpZ3iXrgy67a+dV 3cnfzZtcFPhXn0ETqeu5hx+JeNO8MRk0eBk0sJNjZslUfT1fr663S9W6yUw+VZI0GrPF7AOJJGu6 JOl6LykUWYwvt6qVaQ1au9alSZrOpd7BZ4OE27fDbo09dRcbThTYadVVili1s+HbTVsL6CWGG2fD TV8jqMgMiLdGJq0HTSNOSdBP/7/p50jTb94v6Xe6uXnh+CMnm4+cLDnySyJiSAqR10tL9ew4BDmF qWeVyXSAVFtx5ng9+66iR5/BL0Ac6FSy41Ry4ak0fRpBn1tBH51sN8ManSpN1Q7pkiZL+v+gxnZV 66WBacNT6OnH72TDdxxUaLtC8fgjrAf2r00/cBeQ7UjMThvt1C69AMNJZ03/F8fYLAEE2ffLRxYS 3nrmtt4nToug//24Pz9sI62QWGVP37HslYqewTeJ59xwqmct7KbtqaPKGMiHOJ28k8TQWb6aOAxn s81XE+ZF9ho+hk+zr8y5L+exnA1RfTfryGEqowpTuEENZvBgxMgxokasL0s4++X0iQ5WBrkHGTXR RjrDPcNYT9fn/CG6PvYYeZI9Lb3H3ov+QHM8Gd5YNJrLKDQijcaYnBXbjJEjuMpOY2hTI4o3qxNy Rpf1mV6Kn1dIngyxx8VZbhFlBs4fbmbA2qKNZD1Ms5QwuaKvr4lRgDn52xvJGgxRcU62t8j0UOKh whl5PC9cZOqNeovOez1J9uCOXBZkubaanexZi85DrNEp3BTL3O1pPmnJd0HsEqPLElNttT2CwZp7 vRdvzUpXvxIZKvWsJUzbYAuTkhLoS4j5WKLQUzmwGhbM/xBiAwfG+S1s7S3XJDdvTp743SsXzKbX JZO0YkDyaMHjv7375OqNf5q1f2xpcjV399w+bs71G2nte3v+RaV//TO29Ib7ky+9sHPLwMIPhf07 CkLtSfAqJwd3EjnV1TFiVKWMjuyoNdP1kHPTdUVlui4rt2pzWKK0cq1MNaoxU57KGuUWeZm8Qd7L jrLDiIs4DHmmvF5ulw/KsilTxnmvGACfc4vP2YtspLBTCLoOMi/WigjcBtJOJKFGWwg3CD1MaAv2 MfKp9KshDOG3MHwk0mPxcUgYxj/LvoXQDGmHDWxMR0HSlSbfFNYFwYci1kck8bwy+YPZL6bSAlLA Y1JMribV/FzJlKfw86VGeYHUKrXKT3L3z+2WYLfvM20y0dIyHNJsuOknkoGQyXrpgPSJpEiRRpWq TIxL3iuJHD/ZBMqvbYK0EIcI/8VY/Pkh0kof8maGaH+KfVUh7/rxnFNo//mEqCra72Az0/bXDgJQ xc7tnezGDpvC0MobTY8s2STg9jHdWcnEQu1MHYShFq5kDhW2oyYzO5U0YeXVwosO1oBgwvaoKavo qagoEwBIWUVF//JM858uRVd1rY7U8XrbVdq1yq1kNb1FOaE7hKd/0MXdqu5IsL6OsfCTlqlr1d0O PaxHHFFXISnW+zpiLpXbueML8pV2zHHCpSjETt1Mk3VV0bhNfZkc0PbaXrHvc8j32R5ybCPPa9v1 5xzKKtsdjkcUqBXtAV25Xl/qWKPcqa7RbtOVOY4W12KyTFmmXq8pY7RRjmn6NMcCZZ6q1OiDHA3K earkYLM1VY0TB0w/h26z5dodfrvdIUtSLmd+oFCMcoedccOtRmEwv8huAWc42E0QpiO3uYLBCMzs G82imfZP7GyZPWVnbjs9Lur1drrGTpfhCewLxN6ovQGE30VhstKtZqAWJg18aTddRkHeKMKpKSrR F3EYYR6L1280y9ZIu6WUxMslU2qUFkjLwDuKFHbagzzodEoOh5NpDL2DYSVpg5aESkit+IgOwa/E cgnbxncfEVblwiSUmPi0tS3smVB32cgvxp/sBh4CeWMMEd258pdG+0oJxrsQNbAPri0Ll9Fx7faJ 0zpculMS5zdZ1mb6frA5F7YB2uWWzY5RFKd8ffKfVV8mT9AB9NlSepJ2JN9IdtO49OqPA8GZPRL/ oV7q6h1fSgT8qbO+5uNUjcB5IQxcp+sRmsGCckTVvH3ZpewKdR17UP1GPaGqnzCMwj60COb/KD5G abTPoZfza9kSdQVbpd5HHqDr2P3yg+pG8oT0Z3WjtlF/gexUd2q79L1kH93L90qvya8oH9Kvle/I aXZGLVxupzohuVTzU6op8KEk2S9JsvoIYY/IugYwlcGzokTTqCwZ8My3wr43G6uoOXpMJTWHVK2h B9IdWYYe5WKdEQsnEf3ZSedvg76xWwPN1yUdlFi6M7k0xEaDkmWq3Qy926sNYKZCWmHztNUvZz0r kNxAZ/UO+V7HKj2idxIVilQvSFQyEwuMXWzlxLGFBbY2mLrhrWQtWKSPOVw4hgW2lpteu72SXYqF G9AaS7ETgNia29ISUSzhlZFx7eHzURAYEP/15hY2YNCgJuwtwN7E/9rbD3v79e7dtYXVp88dgL0D fr1XYBIL06CbmjphBu01LOQHROevkVHLMaOGVRs1aOVrW4yaXliNlIDzSHMcLCb4zBeXjiWPJq95 M3kUrBahd75BQ/yDMwl515kS/i40QUfqC6UedodBssk1ZjjgCwXCkWB2kVTomBN4VXrFruuSbGd+ WAFbnXqmMAb6KjxUJLT2YZ3rETPaEt0Q5VEPspMAL2wgVDht0DeHEWFlQLoe7MhJuxkL29oE2gCr KQ03AKbFE/qgkOFWwLvwMykvN58VWG6FMK3zcklHouLvdOjrgH0bPkyu/tcbya+uocWd65Z8es+u tf+V/JrV3rT2rzTr8eSzyS+PJSd8tYv67r5v/x/pqIeeeTl5qfAvIN/lP2D8uEmEbDFLdRaQi3xT 3U2+qZEFWR/4Psn60merihzMYjURauCkCAG8y8DpzGNAQW13ud00HBGqKgpBR6CdqZFRJFyoRvUw chNuLMsys1qyeFZEqCkC9csshwNJFKwcWHUjwMAhmdTi4kt/ZT3+7G7833ZjMyQIuhFwHXxUF9yO vLyBvW4qvFR6Y/ItWsEmr985b8pv1y4Z9be/Dmg+vmFG2QX3vC/vGvfMdQveumGYx/btkFsaqkZG QQfg3/I3oEMAFua55vUaQ/hZD8hRd9TI9qhem+HwOHzFkQ5dLnYWRs6xn+sc5KmJNNjGOMcYU8lU OpVNdUyN36zf4VnjfdD5gPGkc6dtp32nc6fxqv1156vGR84PjQ88n9uO+76MfG/8GMkLBONI/TpL zFAsWB40g2vFeLaMWxDkte0ZgQCNWQanE8QFqdP0dQOdMaPtLuq6P6sopnapB9NO624EUF4382gM WFj8/0Pu3P9FbqNNiA2BmaZ9EwuMEXgBjPWS5rPWTq93QtuAc5tGxPTWhFFCKEEUWJEY7fTnPgF6 EAz44oXcgg16+wYIQpyusvrm9o3PX334s8EVly1NvpBYOLS+5Mrr+234dv30YUW3JrfJu+o6b37+ 2+zKC/6cfGUpVe/qn/3x4KUjG4tCUJ6wS25IHZXnYlwW0zbzt8PVscYYz/jMuc45xnzfguxL+qyl 67X1gfXBtVm/y9mUuTPzNUeXZ1/mS0UZpC+td4yJj8vj9bppn5DTEG2ILe+rKNGwLZiTEa3OHW9v cNbnmNERcTP3sZx9vpcLPsz5MGZoRSTfyGf5pwJFRgbNiPTNKlrgpusBwHZC87iRGYLRHYPmDZe8 CcfZglIt/CUNH4Ky5Ky0daQOm3okuzIewwKxgMNmxBfAFhZ10br4BY7pcSkeTYTtjoQ3sAsZOkAy tnoFZt4Evf76loQubHsgEFC5VtgI2FdJSeZzyLjLWBCggU7aZLo3h3eHD4R5NFwWrg3zcJqpwhBP 273QMIh64CSfbPpqNsBm7pI5ImlyucxhZYo/qO1pay4RKEdJGyDQ3gCHgIaArC0UgGdQQBtVlYnC fGDmlRBPZx2GDH8QB0UyBxDQ/MKbaFTpM3zrvbdUFyaffmQ6dSTh7WS6kp/Yb1r22yv799/YU3c5 VPs3Lya/Xkg/ct9WPuGKccNK4/de8ocrdp7896vOua3TRtT2KR4zf+Slj7yU7F72T9H3pzFW/4yx qtKIeVGrTt3cjVijS/lAPcaUD9hB6aDMO9RX2T6VP8oeVbcxvl5aLz9J+G3sdvV+xheRW8itlJvK 5eRyykfR0axB4rW8VhpFuPrTkMRYUywbHBAjTDhD3ikJKo6s4ulKeC3YUlCZoZFVRDEUFlNalQ0K J0qXclg5gXhNJ7t8WwwoJeR8k5lLpZ0Gp+V8A2eEt/LDnHMTgbsNlKoQhYchCjtZ/TZNp8EVO2lI OHklxhcANGvayqDUj0CBt2GYWt3da8b3/MoXSZtTYknbhGhENDPO3sJgI8lJFdLNFclp0sunBGhA oXuIdjto6KAd5k0OlsWA7ep23cG976kf2tjV6lsqK5PLXFWkite66vhYrcE1hc+UZyoz1Yu0ma45 ZL48X5mv/obfRG7ht2uPyNvJK+Rzflg6KXJdFRjbdo043iIHYRvbmHACYCOn7WECQJlLmsMO5Qnz CPaRA6jydmJvtTP4Fds6bLcLgk3voLczADbTTReXo8r0qLpGZVF4PDCJTIcW5WsEGWdy+CB0/lbt M0A6X2wz4C2t2MmzQTxEfboRZBVQM+zUb4yT+J1cKLBmYYCKb3oNZmuvSxysSY/R7azc5qxE0O5g h24ZPQe3ohYCLo0xI9PxrNlxeKtdRPcOomKdqWNbncLe6K1O7HDU2EOQjMgYQEhQDHVU4JsTO7w1 muGtAScdRnQQx89Wpsuo0WC4aCE3SuCs1SIGeIklYM+aLxwee9wHiJvG5VeSB+I9XyVfHUgTTvod HZVLP6P5UvmPB2EqJyV2RuffiT5PvYR+qUOfZ9BWc3WQBDOYlwTnsDmurqA0l9HbdRoLDGKViKZX yzWeudJs4xpyvf16xzUZq6XV8p3up9jT7k2eTtYe3Ef22PbYX3a85n8tI1LM+rj7eGYGJR9xcsOF hF+3LrkdGOgOhOi5YUTdkt/tlhxOMbYcsB0cTocDyV1uAz63BjMiv0MI0l3wWRxsnRkkiMp0OTlx mgj9HUd4JrI+CEv3BRgPnG6BEbHOzOi1kmuRSbMGtvJmpNyGISzrrJ4X0hdei4hkiYgN1gRsmw4x oNuFEbzyt1Z0AZUbn3S3m+7fs3v1B10P+SRfzIUYg5DNOlZ8JnxaK5SL2uqGZsEIAi2HQBTqcCex p97faog+ft+0GTUZRUYNQbGszrRSRF8JyVg90BenNJ4oTCgqHZ1cwlYm76XnrFEvVNQl5x+l1/fM onOTf75qSlbiT+wL9k6y2/2CzfP7mVQ+c6Zn7H9tPu+cnehLRmYgnjZSqkXmeH/6pDn/uqIVkZsy b81aXSR7Ja7ESAW3e+sjIzPHJFZFbkvsjLwa+SjyUeJ0oT0QpmUV7/FjZcfKD1ecKTlVdqpcyw8P 9jZ553rnhK8P7yTPRT5k74beCx+LfJX4usg1LUz752fxHJcKdCqeyqf5nYg6RbLKYdi1Zh3MOpwl Z8Vdbhsv9ZWyE6W0FAKxY0C41qqL/Ok6z2vVZlaOu7Y04beDEwhzY1GCKOQCBDNOIJrVyfPNPnET 18ZNXBg3cVXcxBXuOE1BnBVLqjoymkONnFgOQxilzow4JnkqCE5gre4uOCBuwx1zl7tTbhlquda0 wWymJN8t9B3ODhWPDJq1VTODVNhaB4KfwNoKDxj+Wlpdt5WATxDdE7yz8GT3mTYhKpAxIYYexEht t1hBLaIoZd1tUL7C5wWYAQcHAheuSJoVTIOathqCQk0dNYq4UkTzfxHKh56MgwXSIUNA5WejzQiu 49sbMhxIjyaPlR9/+Y09noriUPJLj1T72Pm3/PnFb9+o844dM76J0kjJ+8PLRp8z7OqaAPs+dNeG xxeVz/viL+eNPH/w0Ppxz6y6f4fPExqS329obfIFVYkMyD93QF3tJXPBP2PBP5APVlzhkNk2xqCF JN+e64gbcW/cF/PnB4d5pyKL5Bh1HIzTkdIDGgAMZGd6mJHh4lmAVZnX62EsRgkGtEgsyipW1IyE y+5BVBIhh3zdLC6v3Kwf0Nlmnc7U1+ipNJYZ008Al+6k47bF0KcIFca2ehahf+57DhgpuUsEH+jO LePTvgBgK+EQAXEo6TVNEdLv/gl/o6GaMk+NFddHX6zUADe4ADgISwUjE4Ac702eYILSCdWXDsVa vpOqjIXLF7u84baJG1+buX5zy5ErC25YPGn0zVN/c/68CVfKu5KBIRWfHvpd8vjT5+/bTLdcuWLO kWvabrz0Nkt/Xg/63YLxl0l2mIMyM2mxo4k18SuReXw9u54vkVuzV2VuJk+xTfzPkacyt9Lt7DlP e7avxDaIjWachonL64aOyzXt4YRkj7rpbsuUzDVrvQm7SvJpLV2AvGvAOixFaRk2GyxBtxuCzj2S WNFB7opkB/KFrxUDriGpn2f1mWLFq3pj1oj2LVxYlg5YLYTJCBLhZwku5N/LAHxFvFrErAK9Mate xuPwEOqS/976+jdrae4zLxx2JY/bmkafv3b8jLq65XRt6a6X/v3OM7Ryy54N2U2Tl34376LZli+5 GDZ5E3jKDQvgLfO+gswGPsLRgKDd2KzrstRzbINDgzOnZTTmLM95gmwK7CVHyTHXd+Rb/r3NVWwr yljkbc2RMjjGtpNR6nJG7Mwns6CTuyhxu2Mu6ndhjdp8CdkeAZFcbpCBTEKgn8ZoK10uDKl2ipwv OE2YfdFIZZpj5BPN0GLaCcBbn2fTYJ830nzV7a0BjgXilIjo6K95SgCUvWk9K13GEAFgtQlRH48P 7B2vAMiDkOK/YCYmJZInQhPum/n4GzTW/d6VV9PomYFXT56wcuLSiTf86epxwz79OEUf3sQKfjy9 cPmVH1929V3JY5YcXwQ+agUfBUmMvm/+bpV3dZQFo9R7u77KeYurW5d8mqEHbDxLi9ii9pAnnOGL emNNmrbaWBl9Ud/h2q9/pH+mqXbV5k1HOpAVh0jHyGhdzDbFOdu5RL3Oe130NvX3sUf1x50vqLu1 A9oH2kHbh/Yv1ePaD+r32r/9P2adjAZKPKu8bGr08uifbDymhXbHaDpGcRwKGfhCI2WNgtDI1/Nm J3yqvl8Tgr6gqFLUZkY4p7JRow0IZlsEPwiSy1onG2VWeJWEw64t1fdnh+4MsWzMsBhJAkYgFuCB 5bmx/Jtxy/y05D7hltyfx88ysZXI070QxhvksKVjEaQTmkWY3B2lwXQNRWFtQ1eIeivUhRC3JU1C jENy13YLbzWcLdRKtomrsoVuyRa6JVvolvTJInKyEM5u88IhtHeIID0PuCSkuvXXBtK5bOl0LluN eOKzW3p6S08fc1lbW1xpmS+aAcXQTOPpgTUQuRYAbaoA6QC2yPAX9KYYqdKMnnK6eOoaUHjcjw+/ lzy5+HE64G9fJH+gVzQ13Rmmuzz6FTfdW/LQQ9T9yYebvvjvD+bM8NmuvXbFzZYsuooQvge+cIjO Mh9FBoH8hXRYTdETqnJQfV8/TL7g0kHyPjvE35clgV/uk7tUqV3dqXeRfUzaTJ6hTzsQB7lOX+K4 w7E8IhUEqvWqjHqGBNVCOabXy5fzKxzKCKMug+Ub4gA0gdtHZ/poykd9gpK+hAszuXgQ4YsQ4o6S jgSYIEegQwcSqlPFUuIKTSHEmCAWiBjGVXDgVIVLNh2oqEE3GweNwwaHOThqK6Z/7GJjABXlbueT JHU/ApO58H1zzXCtNFNiZRLFjBSJGVJMOo6M0OvDEhIgdrKXz8YfocBPHjF6jmAJBW5lQNS2laB7 sRDWnwuKQmhvkVmCAmCDhODsQiQMqEnDkucCatwCzG6QZfFj/Pd+qIoECB+QJisHD3JABQwHla3y 6r6vb01+unVD3w3BrHDuyvm33D3ocrN/CEpTKnzrzJ/55Lfmrygzx5W/kRf1XzBO2HBmcqL0I8Z+ Aamk48zbY9V0ZfDmMladN8E5LndCsVQYLCrvTyqoFHYXUjYquDfzRDVfXba8+pl+G8ukxupFRa3V t+SsLJIH9xuVWZ8zuu+0kJwoKeo3yDcoXFMil/r6DGAheFlhKhNHyFEa4mF7JDMzZg8jPhHOtPdx RcJKeXGG2ifhsgn0gpFeEGMXz7eCcxgpws01XRgocnHcba8qCtuNyPPojUzAEmPNWOYwYi+zr7Vz tz1m77JzbvdhpdG+wb7bfsKu2jvpy2ZmNQb4XYX5xGN4Yp4THsnzeZU9aK+y3VEupLEVx+w+3W2g exYi1NAbwER/pO0uoe/RVz/FLtFxENAW9HFWPqc7R7hlwvUNyv7ejKzqgb1JWd5qoeQQxXSlld4v ZTfsrRG0LGfE4AsH9okYYdvv1z+8b9Xp5Ve09y+izs7SoY1Lnpj16Rf0gvmTxt05bknj+BuLY4P6 9iuL52cNTdw8YOnH7zxPB21oveyFM7e/u2PemNiDHT4WWrxs4VsXt61esuxi2DRTEAPcBb0YoX3M V2NZNCzTzfom78f6Icch433Pv7yqHzlsTPOEHCE30iUdBe78SDUdxKq1ake1uzpSr9U7ENV3TI0s dixx32p7km7Un3Q86X7K85T3ych22w7HDvdespfuY6/qe52vel71HiLvOw45PzI+9Hzk/cr4ylMm AbhFBMrl8tgdTlsIqd5OZ8zlgUr1cALdY0G68Kf9xarqFHrW5nEB9HBOWuuiMdcB13GE3lxlrlpX yiXFXL9FAk0nG2A6yKQGiO+7Ml1w0ITZBlvaCkQI6Aud+csQxM9Wm4g+nB2BK1179qAX9+xRoWqt JCRA+ggHCfjirPGmYsSlJaWwjVX6m+SnCFNGr5q1seXGdVk3JT+9NWN4zejhU0rDfeRdPafPG3Hv deaKnnvY4suzq8wBw1uq9kBMgrknYfEo+gEZPlQ1V8f00XytvgEZaid0BTP/4JAyN2ewFOSQFJI3 qpv1fdJeZa96SOnG3L1jkjNPypPL9GqlWp0iT1WW6+uUderjyuPqMe5E9yFSz9tZO+9iXfwgO8iP s+McwTVFoRyOC2EyJrRK+GtFiakE+XaErQUS1A4QSOizYLiSd/IC04XpskhlQQa4DZadsIu3KpNg Kd6HVBY4L2tV2oDW36WpQIh3buk1Z9pKYCj3yjmBapwuabPkXK+Ys1DCXlkHGlvmMfQSsDwrUU5k mdBbaLQ6+WkOjf4j+Sls3zNrf7Ti9ePRmK9AMzs9bf5Vk2UlJHEHd9uy9KhN8o5GjvhoaYw2X7pT WmlXR/FR+mXKIn4P/73yBN/GX+bv8g/1D22f8aP6D/oPNkPhuq7bRvCF/Cb+kf6RTcvgD+usgCSU PDVPK3NWK/3V/lq9MkIdpk1F2uJsebZyhTpHW6Esd67jD6gPaE+SjXSj8qTtOd6p7uX71H3aIfIh fZ99wD+QDsnvAgP8QHvPftB5jB7lnysiU/Q7+Tvle+20/p2tEmDStWaToK2OGWY22WaTAUQxTDdD z0gas9vhLyKKiw7jTBoo2/yyjBN1mxZTFfQYcoFxqR1ZNHZikyUFXg9cHW0SQKn16JRONtr0RmW6 Rk7JjGDy5mZ5tywBUq3b0eD8xAmzVnSjzT7JcnSQJbQLE4RH9uoskbNneZ4/5eyJPAOgFUi/BUTk qRF6Szg4qEM/r2AHbNVgjaoN0Yas1Iw92h4aMrp7cSw9Zo+DrQAv2eICuLBQC5g0EJKWVcMBcHgd UINGjYSiGW7U7jRqgUgZGKVZOFFUBMq4yseLYbeBXosReMFnyU/vfmkExptML0/e0DODfv3n5F/F OBN5MYT90Rpn15s+AmB5LRI1DsoiTUNtl6mlUc4dUVUmT+XLQaN0WPV9eogfo99xBMp5by+AvCJ1 w+CT2slhjBZCLcKJ3AyImrOsDylj2fBnGV74N7RkofD+YLRW0JzedAxKxgD/+hb6toSpprdarVdH hTmmDzsxZTYmeQVesXV4lajMVG1VY2lLKSvUnnU8k/FU/GPH++5DfrWsVOztKj1cKhe4C7wFmQXZ hX0KSwaSGhVi2jsws7pPnX2Ue5R3VOaonCn2qe6pmSvZrfbbYstLnyIbHU+4n/A+lfFE5qbYkyWb S7fbO5w73Dsyd+S0l+4jrzr2Gq9mvJL1Svar8b3Fe0vwf8YHvg8zDmV9GPsofqj4GDlqfJlxNOvr 2Jfxo8Xfk/84hq2gB0rZglIK6LZPcTF1AU5zYgalx6/msUQfXkydhhHz+P3Yk5mVFcvO8Wdn59Di 4lgJ8QNNNDyerOzs4hJbsNhmywO2Qoni9+RkkxLDMG2TyjwpDzuAVKRO9qJpz5pUlp3KZgeyafbz 7EWgNpSN3los5NJY019eQltKaEPJ2hJWcldfTzA7WGIJJ0sZWGHphcKPB3dbERFLKaRtsm4EpS0m 70XlBHv3KgeLzXu1BNS9SF2ClvhpoQm3DNreMtJLSixudgN4NWr8An81apzpKiKwV6MmE9V2oyYW +ikQ3GuYW9n/wV6U4FeK5ielA3Gh4AhNUFfmH5697ibvwDcXLLsra1Xy01XhqqorJ59bclny0xXB mgFll47LdGTOTn4qFd744KXTGuetah24smcRu22J0beibeKbyRx204J4cfWgi8fnL0uKQFbaNnge PBmmV5rbbCpm22owJjW35NWUWGajxsOMPmt8rEKSGdIxcsz9lcFfM/YG9oY+MqRtjuec+9S9dumJ jK3aDts2JEUG65UnbE84pYLgQNtAZ7VfKiD5tkInf992yP6Bi29y0z+rT+lPufhi9Xr3YgNZNqOc U22cBUMhuNwOh1u32bUMGtIgCx1uP3bQUCgWJv5wmNgdjlDY5i2WBau4HZg5YJ8k5rKYWaOq1jro cUfKwWKOAw7mdpQ5ah085ljmENA+7ITQpIYwDd8VcQTDFmsIeEdwhmUn9II7vSxh8YMQdr9gBiu7 5KylIHjgbLpyr1UufKxeR02z+tsNHBbdDmRe9D544cTZFICf+l1YhBn+n7u8t5crqZE1e8vFN98X /23y0xuyhg2ufbBvrOhC0amrp41bt3TQwz1PsgtXRgbWXjF16O7kebArlsKHfx196CAR8qxZOSZ8 MOvH8PcR6fXwaxHWhyW0Im8iPMo7JtyYNVu6LrwqfCLLbgh/1BCuqJHg0OVpz1bUZjl2BhO63Zmv CAhNMUdVKWZd1WblgMJmKmuUzUpKkUS4KaY0IsgkK8DSzADsyix/PgB1AkP+BATn55l9QGXQGDOZ BIQmckLgSQPGFMWSkgvbfAbmu2AijZiukJ6voPS6qtVL6Xjq/ppqyR3Jr9cdW8gHLLqoeW3j0ouu bVwItZWgM5M9HyWTyVXXfUzHzb7+6o9mLFxx2RphZ6VOJa+U3gc9DOTS/2jeOd452lsfqMua7ZUr IR0bY7O9rbH7yUPuhwzk2Lh3uDu8r5K9rr3GUbdxh/sOg+Xb8gOYJahzt2+252BMZh6Xm7JM6vI7 XB44nxRokEH8hnhYJRPs6AfAAOg3lL8Z4AbTBNXWaCmNzdTEDugQAQE1aq0CkaDjnovF6PIYjVm2 lTttWwkH9CDwEyNmLIcPGo520nVbAKZZkQQksQrtbOGQJVYA6X8ARr/Ai/ZYrCn8ReH2q2nBYiA5 ITcBEfILxAhmYYIawan3T33y9c3r3nh73tWwaj9ZPGnULVMXTpu0cqxUOH/00C+OJD995amnez7g 05fedvnx2YuW/eYzkBg8tyR5pUzSNKZjdxI3+FyvCWAOmblBr5Fi7ho90CcQi42WpkmXscv4wZiW oAnWR+rj6BPokz3QqAzUxsZI48N4VwVfKi2WlwKgWeq9Ltgau4vdzu+UbpPv1O7Q7/SuCi6PPcIe 4g9L98uPBJ5kT/Ln2HN8L9vLj7I+XqNUShhlgaGGbID8QaQ5EcmvSiGDI1IDcJgT5L8Rxt3+hGrP TLiE4KDPs/uEpwlOD46oOiwYtoV0EW6KzMsrhaKHVrnVLGeTENtDbJeu5bCnOd6dEeNpg1nmsahn JGBmwxaznbBx2+fRPvAkweoLRSqh8DzKROQPaVCGNY/pV5DxWXjPUiUwlyx7GAYRFQE22Axxn4Le EsAoJETw113G/4Px8Gby08vPW3HBU/tXn1rzxeU9u66ZNGbVBUsah982VSr8oY4eH1r1z/efpiM3 dyUTV95wyZG5i1bOSc8hHQ4XTMgJN/nUbC5gBbZKfS//yPEvhzIJ00iJ4gg6Ckihs8wz0DlOnWqf 6Vmgtior6T6y17nXfch51Ol18gB7SL3PJV2grlMZFL/ThRxnXWJO6nLF3ARhNoJQDND1Z03d0ugA 1qwItevcqkaFGgo6AHFqxKXrTE9MpS3qcqQk3rUZet5lafPnGoBD32W4BZ5CA722KWarivkkgqTC X08jpmftLZrG36GfLWJCDousLMH7vegI9CdYP0YdJes2Dx11VaLv2AemFNcLgfrm0ejXrtbnX092 gKcpKYUcvQL06Uu37iR5IvYG2CEUw6JAzKbUa/IEf99hrzH6xfqV9zP7NfaTbS6tT7V9lGNR3kfO dwuOOTU1Ty4I5PkK8gvqbXV5mKymRw7247F+lbnVBXW5owrMfs3kQtfkjMbApODU/MmFM/s29ltU sqLkQdemjA0lG/q293s94/VAV8mevt9HMtPvoojFc/PyCwqd/mLMNQtGQ9QdioZmhhbASxQhK683 q9gPVw3WZgvdQLtE0h7HnEavVFxsD40sC9YGG5Bu2clmbNfyD2IYCiGfsFeRhJGIJcoTZkJO3NUv OtKg+WWEinAYaySbMY9PTN4VIQJHA0Qe0DEWg4TqpI91lA5P4/xW1s5CpPWB9Uus9J2zSKmU1ici Y0EgpVYNtWJlMAjkDbqgpAn9mfYTtkl49w3S9posnNX0ZwnllCXA0iyhobIExJe+BDaccCbFGBIa RGSPAyMVdzs7C04khSTyExg/FsiJwEICCBmUytm8EDG4Smmg4KqZF5/TJyMwK3lm6KyLbqbsjbey kt9llJnTpzcUhVe9NerS5NEvfqR9+k4b0zenJDsYiE0ZMOGGGy5ctm55v8HZiSGJoohRdO455//m vn88Bd55MHWUx+R1sKP2m982IDXgE44fosb0bu1e+0cSv166VbpFuzWMt8241WqJO/kf+D7+ivQB PyIpRXwZ3sWDHCtVksUbsFRFV0IB5MJ5FA+co4DnmHbY+Cp8QvF8knmYHpE+VaRP4Gh+4vkgLO1R 9hhv0/ck6Tltt2cP3StJj2mP60+EHgu30+dVZblneeY90jptnb5BUqaFrtMXh5Yry9XlhpIbrpNG 6dP4NL0pQ8nVCvWYke8pzSgMKZANVpJ4XMFsS91ul0KBAA/zAFE1yU5UWbJj1PMAxTHJZXN5DB8S VUabfSTJLnE7gHXgX1x1I+QPyiQAukK7nQDvJHx2z/52wUTA5Z3KfuRP05RK2+G7Ps9mANLTIBZ0 O92/HtdVIFuozsyw568NtAe6AjyN2XcFTgbkwC52HtCsDOGDgfXauo+cRHbKkSXGfyAhQmUnT2Ka eW23iJUC0hsi5hwIx5WEykQIqqZELETUfaUw74UYFqz080dEU9vaxDQ+2CcAWgt4BUDXXrNEaFLB W74H+96RR8eM39y3vTlcPNB3XunYCfevLmjiE9/d9Epy7bvJEYs98QL1Xfdv5vTfQp+25MtayJeT UiFaPta8jmlGzTn6uf7x+nj/Y7Lss3nsTAvhlW3I3SwKxbJGh1qzNiC8bSNZ1AZdo7k1I8xCRjgC fM4zKDI6coFrsme2c7brUs8i9hvXNZ4Vnj3yPuOV4Hvsk8ChyIksSA+f1+f3urmE/CqfmuFzub2e v6R+IC4UKfUtCSFrdbgHRofbC8ntpZIUCxE/GkHApIbi8drU4gx7KLPI7SUAkhct8x7wsqi31tvg 5Tg95l3mPe7l3k5EjuJSPvD/taENofZQV+hgSI6FykMspHuDoWAo0zYRAgOSG+NUZBLRtNmdhues uSLwwtJ2d+/8kN4EYToIH9FdVjwsiAirCLBa/QU5L8S8NXPECldb09LFewV6IdeBeAda9GZkRhWO nTA00xe4QkBLJ3PaD9y8Llcq7Lm9Lavf8Oxzzhvabw794ccP1z617oaBjwnbhuItRET6N/rJTu07 kVfRhaQZpMjsM5u8NZOgwJwXqRfYgKT5MZU4j5bIFXQMGUGnkMn0Uno1XazdTP9AHqLr2SP8Af0B 2/32tc6nSLvzVds+wEKZxOmj15LF9gfIg3QTeZq+Sj/EmxsELhSh4qVDNgG9AR0FaGe3wS9SEHBE fv5/AOzYa+0z7Txlp8RuAOMWUyDqMDUMySqtTu5kk6IwT9h+5HOJ/fZGpQXJYEgFo8oL9AASW3bT YVCn1oRXSNFQOpcrbU1aMI8VnLWGBMbEkD0YLkY6A1gMBOSRxEXgAfkj1QMRNb/su3dpZFxU0a53 YUpMtVSY7P/CUM+nQdoF+t0DnGMn6Oeg75q7XRBqzAaI2SYrXAXgFtYkL3Gc89NvpEo/Vj7WPtaP 2KTXxFu6lFdtrzg+Zh/L6lP2Da52vPjuOfV5JLOqt0kr1IfJw/LDygP2jYp6hTrXtkxCfFFb5rqF q+PsF6oTtUZ9su1KNperVaRa6i/X2AbZkT5G1CJSJvVVStViLV9M0ijEi76GkzplpDrWbrpus9/s eBuvzYDRaJftCrEFaNiuMllSQfprzSASDIiIEyFZDD4oPB7MYlMZeZ4l8LQO9p8dy+30MLgFuQRm 0EYmLYASPoxsuv2fYDb4QzP1BXgVx1/YaFiWEn2UqIgk/cm0zVQWKMuU41aS3gwziwhLKKaWq6ba Crl4GD7/IcJirBZT4DrZ9x3OiULYnWyGREM2kcilb+621gSsYb3DA5ko1hhKZ5YB0TCQQevtTSnb SWypwx16UCTNH34ONebJBH9OKfspwARQVmhTC8/AFaYtiDwwEahCugn2W95rXCByvAKpX/hJG5P/ rky+kDx9a2osHUflfDqGxthjPTMwxgaxfaKIMeVErOk78ISf/sPcVsjxFshAvXardjiAMG3UbwbY Md9p+aTynV36HG88+1z6wi69Ir+sHGLv8ncleYe8XXmFvcxfluTH+SZ1O9vGt0nyPfxu6T7ld9qj TF7OV8h3+W7138Pka9m1fJG82LeSyU1aI4b9FfoCv1wnjfNNYRP5NFWu4oO0Gr2ejeQyFJ1UqFcx qVZf6VuLxCV0OQMUS/VFhtvr1I8sxxtfFvlFz3fSmWZChXeh4jBM21ziB1LrR1YhTFpvwul2V5jw 3Virpd7ON0N+bdhylaZ7tBE9ugF9ekLVgNLWmn0lMukwPYEUtWukL8v9pn+5f61fMrA46D/sh2gx /DF/i78Lm4p/F/sGU/r2bnkG/S9CVJj6222BWUL1CUX3E2LxEzwrFBsiit1twh8ZQLvPDus9e9IG 104x37TD7kxPcUNSmWWYIedQmFIAaQXw+otPL7ShwMkDK4CBkD8oF8HHw+p2d43/LGQr2MNnCQmR ZOZicDoHBvAmi6dpzuhMPujiJC3vaZ3YfPOMCxeGK/vfcgFY5Pj+SY9up4d+XPi7a4bH3nNbvJIL +VsIXtGpb7sizG+K/zGbRAyQyqxVaVWlu2Ho4p2U52GidgNvkBrUBq1Bn8kaVcymYbPVFqRy3omZ jXex1er96ka2Ud1NdrPdvF3dre8nr/M9Spf6un4Q8elvSB4e6AdTx0xNTDhx1yKL8uD2YA1LIHk2 dfC5YI2SwHjHOV1mAIfVImDdCZ0miE3fH9Vq4e4/z+qIDNiha6sLOZiQF06lQo7Ypf1r+HqRHMpG bSdqowuEwzEYN7UYDmHbE/AY4d23YQ6TGNaY4nw6vWp1KdLeS5AWgpAxamhBYaGgU9rQPxWQv0is hYOT24fVJwvK+LC8nu001f8ldsvhp3vmi7wOyCs0iSy4u3vvTPeQU1pYww5CDvw44qc69VJyIjJw 3yYIG1nniyO4Th2anEBG2Ct+XPHDJPtXmCKgWpecXVRBIRFWIzxJWk2P0mqsZ7BNpAH1dOlqshTl CZR3UG6S96a+BLw+CeUllCYZSlL6DO/3qyHbcf4orM9QNpHzcWwG9nXguFifjvoGHDut3klOyFNS L+FeM7A9FvX1qBejXoT/vArrJsoU3GsS9o1H3ahmkzFiH8pS6bPUKdRLeDYZjuOluOZBbK/F+gP4 v3tQOyWCN4gSUonvNLwh9gje8dgPc9K68IbMf+JdrefJ7yvTla/UGZqpdeoh2xz7/Q7NcYfzUtfF SBZJGke8kvcxXz/fPv9XGa8EdgVvCIXCA8I3RPZlbsoakHUk+y85E6LzYjfEJ8X/nXsm35uffr9Z Fd6HyPHuV7ANMUgZ3ilLpONsJvwtABMgsLe3RxQSJmT0hMZho8aWDFs4d9a80uEL5l065ppZ8+Ze Mn6ywGFI6iRKAu86/b8+Vdgp3rlog88v3hKcgftFkB0l3vb787t++6IF6bf8VhCoTbxFcTDesjmS 1JF6zJcdjbjFWDIOb3idgFnEjWQimYRZO5PR5il4gml4Q8B0zDJt3jK5/Hk+Ee02ecPWmgqzkzd0 GBkDUDd2OLyiHt9RVmHVW4eKw+M76sakNxutza3T09VlFcvFwczM9DVef7q2Owe4h2Xw8WQZynEU TmqxbEBZg5JCkYgbS3Gc8fM6aG605UU+DtvjQCeTj+kYMWLAst18DFmP8gkKt/aWW40a01FVJf5o TEdZ/3SdSKTr3AL8sQOn16IsQzmAIi6Xrct134CyYXE+FofG4n/WYLkb5QDKJyjHUWS0aywpQ2lA aUFZj5LeK84RrRvb0Wew+L+xHekHHtthNwY0DjP4aNx4NC4YjeaKJcVtR+O2wpow+egO3Rjg3Znq Yh9vNYcNSK/UDLFW/tExZNiAd4aF2T9wUTn7mJgojSgtKAdRDqOcQMEIx3ItygaUdtxKGrh2WC57 HdethfpGn1rrprVebq2XW+sxaz3We87jiMo8jjcRr8W7STegMPaYWTDzsHJYZbuV3SrbrGxW2XpM c2UNSoPK3Iq7d597WDMfDgINB4GG4ymHW105HBQfTmaibEbpQkmhKAQZKmQZCtJtsYyiiD21KA0o a1DWo+xG0fBK02o0341lGYo4ZybKMpQUCvxSVoWtKuteVTinCoSpAqXFPoRWsaxFaRD7+Fh8h/Ph bCC+1fhWsSrQff/WeKVF7tfPrrx2duXVsyv7xIqAQuZHhlj1l5EqcQ29cCtWxIGlvfW1vXVLb90v XW8trqzAaVuLK9LVgHTVP12Vp6uydFWcrvqkq6J0FU9XwXQVSFcZ6cqfrnzpypuunOnKka7souoo 7m1MIt2YRLoxiXRjEunGJNKNSaQbk0g3JpFuTCLdmES6MYl0YxLpxiTSjUmkG5NINyaRbkwi3ZhE ujGJdGMSvRSKixq9kF+FN468nq5eS1evpiu8LgEH5+cPiX4pTqIXmlHUS1GuRWlB6YdSjJJAiaN0 8tqtd/VBNbQjlhedOUzn55IFKMtQ1qBIvKYjFo9GIY8GgW0HgVEHgXUHgW3XY7kZZTcK/+kY41U7 cN81tUPw/+EdaMp34m9oh9VC+nS6mpKuLkhXmeYEnPMDylcob6EsQrkKZSrKeSgjUM5FqUIZCKVh WZTe1v9X2vXFxFHE4Zk9ZO/4V7gaPHJe584Dd521RwFbMCjsHXs2zZqIHNBbG3PUSsw+qI131PSl xocmkmiypomJJBZiQkLgZW+puEcT0+gzL40+mvjQF/XBN42+1G/mTooJPrm5mW/mN9/+ZncYmNmb 2Q/sRPXw8AEJQAo1V/KEkIKP90XNu0o/UjFlNXBPou6vAv0t3AG9Q3Rs+WBQF6xI9IkrcYdodAj2 beAi8MuA38Zp6wEfBXwRcDQQXQ70FODNQIecEL0S6GcAlwM9D7gUaLdZPkYvEg27MhmccLoGXAj4 Kornm1AK+AxyrOnhVKDfYvlOSOu5EIJmNEk0iQMEwtAB+0sL22jA/tRCZWeP/cFfYb/wMEr32M/8 OvtBDxVqnmDf5w7Y/cwB+04fZt+6YJqd7J57wL4BvT4oHazxkC7C/DmfYJ9ydIYczMi/j1Ov8R12 Fa5Q3btMst/JhHQNpW9rt9gy/5AtacjvsQrn7GIupEMBm0M1uK6XkVvcYzYqv9Cq+Dw3mIXKZ8R1 BiyvS48mPFAzyV7MPGCTuIbx3F12lk+ykdwDluVF9pQLR1+zhe5Yd2zcC2nWPKd6P6ree6q3oHrP qd6w6hmq97TqDaneKdVLQQ0vjlWmnmhXtCOKx1RsIsIKVhRr0T+Zz4oZxePtvQKwcIcY+x0R92L2 gLkc+gSmfQo2gGGYj/snI7Zilwr+hGGH6sM5f9yw/ejspXId26wcYfXvXSH2G2n/91I2pB2vvuY/ li1QP24Te76Q8JWPQkrmy+jl4oSbSWiL4uUUSgdufpJsoePMlPfxN7qf0KpD+q9NJ6bjU33Pv2Qd Ey1J45Ilnklbh1i5PTzs2esNdJOtXZWdUw3DLiHriawnsomU/5ldKvvbKccfFYmHKcf2V0tpvDCj JJT+otWApAnAKTfadpVEcU7Y23Ytx7HxI5Y8kobdapBBAeD1REla8Ei6Jyp5yk6Th33TgqcLAC+x SZjkscSm5LVRwau76aJVh0iz4GQJcSXHzZIjnAa+hB8EaxCRYG3QimDRSnZDsHxDOtI0UHKIQME/ WtCkI40+KSlnH1EyLUrlkFKRlI8fUXiTEsGvetNLZBuUw0b+H4nlQtEtFag9W65HScHB1woS+3uv Tsme0T0wtZncJ/cjv5JOKAV3QFC6M4uBfxrPui/QYfGWW/ABpa87MvWbSLV3+e2gqQiib01mEjeS +22EbkkPXTB3t4pO50/nRRH6vHDeA/OJVlHixmQmuU+3WkW9MPeh3uPutFqtGdWjBceyjhL+O00S RddqfkRKBLhfkaFWrYmjWrTwqUGdgENxYEJsA1bVIqShLaFYILQJpC0SkbZ6LAa8bDnV1mHUVmqo H+1mjpiYNZiYMph8FGEE4QzC8JiJAdzE6G1i6DYxbpsYtE2M2Bv5Djmf25DzuXWZXseb9WPU5Bxn PgMWEKO5yeNABK4DEXgGIYUZtCajzNi/Gklc29FGcYiBu4YFt7zSatwVg1b/MR9yawb5G02icrcK ZW5kc3RyZWFtCmVuZG9iagoyNiAwIG9iagoxOTY2MQplbmRvYmoKMjcgMCBvYmoKKENvbGxlY3Rp dmUgTmV4dCBTdGVwcykKZW5kb2JqCjI4IDAgb2JqCihpUGhvbmUgT1MgNy4xLjIgUXVhcnR6IFBE RkNvbnRleHQpCmVuZG9iagoyOSAwIG9iagooS2V5bm90ZSkKZW5kb2JqCjMwIDAgb2JqCihEOjIw MTQwNzI4MTczMDI1WjAwJzAwJykKZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIDI3IDAgUiAvUHJv ZHVjZXIgMjggMCBSIC9DcmVhdG9yIDI5IDAgUiAvQ3JlYXRpb25EYXRlIDMwIDAgUiAvTW9kRGF0 ZQozMCAwIFIgPj4KZW5kb2JqCnhyZWYKMCAzMQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNDA3 MjYgMDAwMDAgbiAKMDAwMDAwMDM4NiAwMDAwMCBuIAowMDAwMDA0NTg4IDAwMDAwIG4gCjAwMDAw MDAwMjIgMDAwMDAgbiAKMDAwMDAwMDM2NyAwMDAwMCBuIAowMDAwMDAwNDkxIDAwMDAwIG4gCjAw MDAwMDQ3NzUgMDAwMDAgbiAKMDAwMDAxNjYwMSAwMDAwMCBuIAowMDAwMDAwNTk2IDAwMDAwIG4g CjAwMDAwMDMyNTUgMDAwMDAgbiAKMDAwMDAwMzI3NiAwMDAwMCBuIAowMDAwMDA0NzM2IDAwMDAw IG4gCjAwMDAwMDMzNzMgMDAwMDAgbiAKMDAwMDAwNDUyOCAwMDAwMCBuIAowMDAwMDA0NTQ4IDAw MDAwIG4gCjAwMDAwMjAwNjMgMDAwMDAgbiAKMDAwMDAwNDY3MiAwMDAwMCBuIAowMDAwMDA1MTY0 IDAwMDAwIG4gCjAwMDAwMDU0MTMgMDAwMDAgbiAKMDAwMDAxNjU3OSAwMDAwMCBuIAowMDAwMDE2 Nzc1IDAwMDAwIG4gCjAwMDAwMTcwMTUgMDAwMDAgbiAKMDAwMDAyMDA0MiAwMDAwMCBuIAowMDAw MDIwNTI4IDAwMDAwIG4gCjAwMDAwMjA3OTIgMDAwMDAgbiAKMDAwMDA0MDU0NCAwMDAwMCBuIAow MDAwMDQwNTY2IDAwMDAwIG4gCjAwMDAwNDA2MDYgMDAwMDAgbiAKMDAwMDA0MDY1OCAwMDAwMCBu IAowMDAwMDQwNjg0IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMzEgL1Jvb3QgMTcgMCBSIC9J bmZvIDEgMCBSIC9JRCBbIDxjOTIwYWUzMGQwNTU2NmViOGI1N2Q0ZDU3OWRlMmQwYj4KPGM5MjBh ZTMwZDA1NTY2ZWI4YjU3ZDRkNTc5ZGUyZDBiPiBdID4+CnN0YXJ0eHJlZgo0MDgzMQolJUVPRgo= --Apple-Mail-9F5DB7E5-062A-478D-9083-4BF6877FCED7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sent from my iPad --Apple-Mail-9F5DB7E5-062A-478D-9083-4BF6877FCED7-- From nobody Tue Jul 29 00:44:33 2014 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 963B21B278B for ; Tue, 29 Jul 2014 00:44:31 -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, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 XimsPW8Q6xg4 for ; Tue, 29 Jul 2014 00:44:28 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF751B2788 for ; Tue, 29 Jul 2014 00:44:27 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so8384711wgg.12 for ; Tue, 29 Jul 2014 00:44:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=prVjlKX0TkCXpQ5bCGNPK6rhH5IbBaNwR9hWOf1R60c=; b=nHF4wJFkVwEA/D0sFPNwy3JrugJgRGvfwiLwA68k81DOpjN4N3D2g26O2EIVCOydzC X3tzCbwydq3jWM58RvBKa7a4ZevP+KmspAipKMYetbCKUifg3ZAxH1EUQ5V+4lJtZ7Tg Lj3HRTeaBVNNP/Gm5a4CkXIJnYno8+RrSAV3dVMdy9u3ge2aV82aZs78adCk9BQaCGZF 3lNmO5EQTF2gLng3FSxUOZ848n5I2uvxuOp2AnO55zkLdDtoVOJU27SMu0w9GZGyc8Gr UJpzMnO3QYishgNGa9fC3m/ZU0Z2xI2tspJz2xedZqolofcbZ9TswykWlT9otP35uJcW alLw== X-Gm-Message-State: ALoCoQlkrprnLcQtI2kA/3a1ohVWZaTsze/7LFW7ILoRgVOkiEHHq0VzD5pb/HeCtziiSgCHtMUn X-Received: by 10.194.202.165 with SMTP id kj5mr632490wjc.50.1406619866112; Tue, 29 Jul 2014 00:44:26 -0700 (PDT) Received: from [192.168.178.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id gq4sm40456836wib.8.2014.07.29.00.44.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 00:44:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Teco Boot In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7343048C98@VAUS-MBX03.idirect.net> Date: Tue, 29 Jul 2014 09:44:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D47E790-4E8F-4FDE-8C7E-4B9EB8E7AC01@inf-net.nl> References: <84585478AABBBF4B9DF597FC0F84AF7343045446@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DAD0E@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801148DAF62@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF73430460E7@VAUS-MBX03.idirect.net> , <84585478AABBBF4B9DF597FC0F84AF73430467B5@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB2FB@tss-server1.home.tropicalstormsoftware.com>, <84585478AABBBF4B9DF597FC0F84AF73430469D8@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB328@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343046C4B@VAUS-MBX03.idirect.net> <2CE2F064-1F1D-4D1B-8967-5E7C3C3E94F4@cisco.com>, <84585478AABBBF4B9DF597FC0F84AF7343046CFA@VAUS-MBX03.idirect.net> <38A5475DE83986499AEACD2CFAFC3F9801148DB3D5@tss-server1.home.tropicalstormsoftware.com> <84585478AABBBF4B9DF597FC0F84AF7343048C98@VAUS-MBX03.idirect.net> To: "Snyder, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3hq1PxSJsqNcmuxNz720V4bjpWo Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Request to consider for DLEP 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, 29 Jul 2014 07:44:31 -0000 Brian, What satcom topology do you have in mind? Single hop between MDM1, MDM2 = and MDM3? Relay at layer-2 on SatHUB? Relay at layer-3 on UpRTR? For all these scenario's, DLEP is applicable. DMAC addresses are one IP = hop destination MAC addresses. It is up to the modems to provide link = metrics for path between the IP neighbors. This could be hard for = multi-hop RF paths. Teco Op 28 jul. 2014, om 17:23 heeft Snyder, Brian het = volgende geschreven: > Rick, >=20 > Attached is picture in a binary format. >=20 > Thanks,brian >=20 > -----Original Message----- > From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=20 > Sent: Friday, July 25, 2014 12:59 PM > To: Snyder, Brian; Stan Ratliff (sratliff) > Cc: Henning Rogge; manet@ietf.org > Subject: RE: [manet] Request to consider for DLEP >=20 > Brian, >=20 > I'm getting baffled as you ASCII diagram lost all formatting. Can you = redraw it as a png or something and send it back out? >=20 > Cheers, >=20 > Rick > ________________________________________ > From: Snyder, Brian [bsnyder@idirect.net] > Sent: 25 July 2014 17:37 > To: Stan Ratliff (sratliff) > Cc: Rick Taylor; Henning Rogge; manet@ietf.org > Subject: RE: [manet] Request to consider for DLEP >=20 > embedded.... >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > Sent: Friday, July 25, 2014 12:30 PM > To: Snyder, Brian > Cc: Rick Taylor; Henning Rogge; manet@ietf.org > Subject: Re: [manet] Request to consider for DLEP >=20 >=20 > On Jul 25, 2014, at 12:24 PM, "Snyder, Brian" > wrote: >=20 >> Rick, >>=20 >>> Ah-ha!! The DLEP destination MAC is defined very specifically as the = MAC address of the interface that the router is using for the TCP = session to the local modem. The router may have a billion other MAC = addresses, but only that one is important. In the >spoke case, the same = applies, and if the spokes don't need to know about other spokes, don't = tell them. >>=20 >> Hold on. I thought it was the MAC address of the far side router = (otherwise it would still need to arp). Your comment --- the LOCAL = modem would greatly change the issue in my mind --- but how does knowing = a local MAC help L3 converge any faster - that would mean it still needs = to arp or mcast hello to find far side guys so I don=E2=80=99t = understand then how the 'fast-start' stuff works you were discussing as = the point of this..... >>=20 >> In this diagram below: >>=20 >>=20 >> = |----- MDM1 ---- RTR1 --- NET1 >> = | >> UpRtr ----- SatHUB ------ OUTERSPACE ---------- MDM2 ---- RTR2 = --- NET2 >> = | >> = |----- MDM3 ---- RTR3 --- NET3 >>=20 >>=20 >> Let's say RTR1, RTR2, and RTR3 all want to make a [OSPF|EIGRP|BGP] = neighbor to UpRTR. UPRTR wants 3 neighbors. There are 2 vlans on each. >=20 > *By definition*, UpRtr in this case has 6 neighbors, not 3. Each VLAN = is a neighbor. >=20 > [BSS] - That=E2=80=99s what I expected. >=20 >>=20 >> What does MDMX have to tell RTRX via DLEP? How many MAC Addresses = (Multiple VLANS) and which ones? >=20 > That's the rub. MDM1, for example, can tell RTR1 *only* about UpRtr. = (Specifically, the VLANS on UpRtr). So, while UpRtr has 6 neighbors (but = we've already said the hub isn't the problem), RTR1 only sees 2. >=20 >=20 > [BSS] - Right. that=E2=80=99s what I was expecting the answer to be. = But then it isn=E2=80=99t the local MAC address RTR1 needs, its UPRTR = MAC Address - he is telling him about the REMOTE mac, not local... which = means the MDMs would need to be configured to know what that is (per = VLAN - even though itll most likely always be the same). >=20 > Now if we want NET1 to talk to NET2 - then I'm assuming the RTR2 mac = has to be told to RTR1 as well via DLEP too. Correct? So then, instead = of letting the RTRN find RTRN' naturally the way a bunch of routers on = an IGP would, MDMN would have to tell RTRN about the entire set of RTRs = (that aren't himself). >=20 > That's what I'm hearing from this conversation... you have to tell = them EVERY specific destination. Now all the sudden, in this VPLS = architecture and using DLEP, the MDMs have to maintain a MAC to MDM map = that could be HUGE. I don't think this is the part that scales. >=20 > If I'm in VPWS mode (NET1 can't see NET2) then I agree - it's not that = hard of a problem to solve - though there still needs to be additional = OAM knowledge on the MDM which breaks my transparency design - but I = could maybe live with that if it was a bounded set of say 12 MACs (# of = VLANs expected to getting routing peers on per modem - worst case). >=20 >=20 > Are my extrapolations here correct? >=20 > Thanks,brian >=20 >=20 > Stan >=20 >=20 >>=20 >>=20 >> Now what if while the RF system is not MESH, I am allowing = hairpinning (VPLS mode).... So NET1 can talk to NET2 via SatHUB. Then = what do they all have learn? >>=20 >>=20 >>=20 >> Maybe a concrete example will help this sink in. >>=20 >> Thanks, >> Brian >>=20 >>=20 >> -----Original Message----- >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >> Sent: Friday, July 25, 2014 10:29 AM >> To: Snyder, Brian; Henning Rogge >> Cc: manet@ietf.org >> Subject: RE: [manet] Request to consider for DLEP >>=20 >> Inline comments.... >>=20 >>>> As I see it, your problem is along the lines of "OMG, I have = 10,000's spokes and I can't have a master list of spoke router MACs, and = I don't want to report 10,000's DLEP sessions everywhere when spokes can = really only talk to the hub". And my answer is, "You don't have to = report everything, all the time, and you can learn the MACs at runtime." >>=20 >>> Yes, that is a concern of mine... but not the only one. I = understand I only have to report what I want too but I'm also concerned = with the notion I can auto-learn it. How would I know, in a VPLS = network which mac is the upstream router? I could be inundated with MACs = from all over the network. Maybe some I'd care about and some I = wouldn't. But I certainly couldn't track them individually. I have no = idea of another modems state. I only know MY state in relation to the = hub - IE: am I in network or not. Also recognize that if I have a = hundred thousand MAC addresses and I had to track them all -- well a = common design with our networks is for people to use multiple SVNs = (vlans/qinqs) tags PER modem. Many designs have 12 each. Our namespaces = are kept separately.... so a hundred thousand modems with 12 vlans would = be 1.2 MILLION macs that could potentially be seen. >>=20 >> Ah-ha!! The DLEP destination MAC is defined very specifically as the = MAC address of the interface that the router is using for the TCP = session to the local modem. The router may have a billion other MAC = addresses, but only that one is important. In the spoke case, the same = applies, and if the spokes don't need to know about other spokes, don't = tell them. >>=20 >>> Granted, I don=E2=80=99t think that scale is going to be roll out #1 = of DLEP use case - but we do have customers operating at that scale. If = 'DLEP' feature gets released - they will want to use it. >>=20 >> Absolutely, which is why I and others are spending some cycles to get = this sorted. >>=20 >>> No modem currently tracks any MACs from the hub side for this reason = -- and we don't need too (yet:)). >>=20 >> Hopefully my answer above will have helped? >>=20 >> Rick >>=20 >> -----Original Message----- >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >> Sent: Friday, July 25, 2014 10:05 AM >> To: Snyder, Brian; Henning Rogge >> Cc: manet@ietf.org >> Subject: RE: [manet] Request to consider for DLEP >>=20 >> Top-posted... >>=20 >> Sorry Brian, >>=20 >> I think my understanding of your problem might still be wrong, but = I'll make some suggestions anyway... >>=20 >> You don't need to preconfigure the spoke router MAC that gets sent to = the hub because you can learn it from the endpoints of the spoke DLEP = session. Then when an RF link is established, you send it up to the = hub, and it can report it through it's local DLEP session, and = vice-versa. >>=20 >> You don't need to report all destinations in all sessions, only = relevant destinations. So in the spoke modem, you only need to report = the hub MAC in the common case, unless you have turned on hair-pinning = for some subset of spokes, in which case you only need to report those = addressable MACs as DLEP destinations. >>=20 >> As I see it, your problem is along the lines of "OMG, I have 10,000's = spokes and I can't have a master list of spoke router MACs, and I don't = want to report 10,000's DLEP sessions everywhere when spokes can really = only talk to the hub". And my answer is, "You don't have to report = everything, all the time, and you can learn the MACs at runtime." >>=20 >> Cheers, >> Rick >>=20 >> ________________________________________ >> From: Snyder, Brian [bsnyder@idirect.net] >> Sent: 25 July 2014 14:37 >> To: Henning Rogge >> Cc: Rick Taylor; manet@ietf.org >> Subject: RE: [manet] Request to consider for DLEP >>=20 >> Embedded.... >>=20 >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@gmail.com] >> Sent: Friday, July 25, 2014 2:36 AM >> To: Snyder, Brian >> Cc: Rick Taylor; manet@ietf.org >> Subject: Re: [manet] Request to consider for DLEP >>=20 >> On Fri, Jul 25, 2014 at 12:51 AM, Snyder, Brian = wrote: >>> [BSS] =E2=80=93 And I guess I am looking for something different. = I=E2=80=99m looking for link state notifications (with metrics) to - = and this is a different #2 =E2=80=93 allow a routing protocol to be = tuned for minimum KEEP ALIVE timers to minimize bandwidth usage to = conserve very expensive and limited bandwidth. In a satellite network, = there is no need for fast-starts, L1 convergence can (and in a suitably = sized network will take seconds). However, because modems tend to stay = in network quite stably (trees and buildings don=E2=80=99t get the way = often in the ocean=E2=98=BA), the building of adjacencies does not = happen all that often. It=E2=80=99s way more important to me to conserve = bandwidth and be transparent. >>=20 >> I must admit I still fail to see why a special case is even = necessary. >>=20 >> [BSS] - Perhaps not necessary - but I'm very concerned with trying to = optimize for scale and transparency. >>=20 >> We are talking about a network with hundred thousands clients = connected via satellite to a Hub station. Yes, so we need to make sure = that the clients don't talk more than necessary. >>=20 >> But you said your client satellite modems are able to receive = broadcast traffic... and maybe even unicasts delivered to a different = client. This means pushing information from the Hub to all clients is = reasonable cheap. >> [BSS] - They won't receive unicast for someone else. HDLC addressing = demuxes that. Pushing broadcast is cheap. IE: ARPs can flow freely and = cheaply on the downstream. >>=20 >> This means transferring the Mac address to a client is dirt cheap, = especially if Layer-2 at the Hub is able to tell that a new client = connected to the satellite. >> [BSS] - In this case transferring a mac address is cheap - the arp's = do it through us -- though the modems currently don't track and record = any of the learnt address OTA... we just let the customer devices do = what they should do by all normal conventions. (ARP, timers, etc). = Modems have no notion of weather or not another modem is in or out of = network. No star system would. They just track themselves. So if MAC = addresses are supposed to be stored and managed by the modem for DLEP = management automatically, we a) aren't transparent anymore b) Have a = scale problem managing all those macs c) If there are more mac addresses = (not routers we would care about via dlep) how is a transparent switch = supposed to "KNOW" which mac address is the special one that should be = 'setup' as the dlep target. I think that would require some special = config that then has to be managed (also breaking transparency) and = creating OAM and change management issues. Remember the LAN is not 'our' = equipment, so all the sudden one would have to get and manage mac = addresses for all these sites. We are going L2 in-order to help us and = our clients not worry about each other's equipment and networking. >>=20 >>=20 >> What is the typical uptime of a client? And what percentage of = traffic goes from the Hub to the clients? A rough guess would be great = to better understand your problem. >> [BSS] - Typical uptime would be measured in from hours (Maybe a plane = moving across satellite footprints) to hopefully years - a stationary = modem. Though practically that=E2=80=99s maybe more normally months due = to weather, upgrades, etc. >>=20 >> Henning Rogge >> _______________________________________________ >> 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 Tue Jul 29 05:47:27 2014 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 1925E1A03EF for ; Tue, 29 Jul 2014 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-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 WuzOciAIqIga for ; Tue, 29 Jul 2014 05:47:24 -0700 (PDT) Received: from atcmail.atc.tcs.com (atcmail.atc.tcs.com [203.200.212.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12181A0154 for ; Tue, 29 Jul 2014 05:47:22 -0700 (PDT) Received: from [172.20.94.66] ([172.20.94.66]) (authenticated bits=0) by atcmail.atc.tcs.com (8.14.4/8.14.4) with ESMTP id s6TClHvv003754 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 29 Jul 2014 18:17:18 +0530 Message-ID: <53D797D5.3030306@atc.tcs.com> Date: Tue, 29 Jul 2014 18:17:17 +0530 From: Vigneswaran R User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aYXdnHeDR1j8LAT8-6VCYE1VYZs Subject: [manet] some feedback on dlep-draft05 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, 29 Jul 2014 12:47:26 -0000 Hello, The following seems to be discrepancies in the dlep draft-05. Please have a look. Thanks. section #10 * there is no section 11.1 which is explaining valid DLEP signals (is that 10.1?) * section 10.1 doesn't define identification data item. Btw, what is identification data item? I couldn't find any examples. section #10.1 Missing some signals, * Peer Initialization ACK (explained in section 10.5) * Destination Update ACK (mentioned in section 9.22) section #10.2 * the sentence "There are NO data item TLVs associated with the Peer Discovery message" is contradictory with the information in section 9.1 which says DLEP version TLV is a MANDATORY TLV in Peer Discovery. section #10.6 * as per section 9.9 & 9.10, Current Data Rate (receive & transmit) are mandatory data items [wherever used]. However, section 10.6 says all data items [including those two] for Peer Update are optional data items. section #10.9 * as per section 7, Status is a mandatory data item for Peer Termination ACK message. however section 10.9 says it as optional data item. section #12.3 * Destination Update ACK signal, which is mentioned in section 9.22, is missing. Regards, Vignesh From nobody Tue Jul 29 07:07:24 2014 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 D6B9B1B2889 for ; Tue, 29 Jul 2014 07:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ZJHKQ_UiEaxQ for ; Tue, 29 Jul 2014 07:06:47 -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 D9DF41A01C6 for ; Tue, 29 Jul 2014 07:06:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,757,1400022000"; d="scan'208,217";a="390262927" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 Jul 2014 15:06:44 +0100 X-IronPort-AV: E=Sophos; i="5.01,757,1400022000"; d="scan'208,217"; a="66495189" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 29 Jul 2014 15:06:53 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Tue, 29 Jul 2014 15:06:51 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , manet , "" , manet-ads Thread-Topic: Ready for WGLC: Advancing draft-ietf-manet-ibs Thread-Index: AQHPqmaMr2jXtWmnY0aFPOP7noXFq5u3F+BA Date: Tue, 29 Jul 2014 14:06:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B823GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jJ_CuRrNsmt5Nog_Q9RFinCiUHw Cc: Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 29 Jul 2014 14:06:58 -0000 X-List-Received-Date: Tue, 29 Jul 2014 14:06:58 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B823GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Clausen [mailto:thomas@thomasclausen.org] Sent: 28 July 2014 14:19 To: manet; ; manet-ads Cc: Christopher Dearlove Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Dear WG Chairs, Dear Chris, all, As the author indicated by email recently, he believes that draft-ietf-mane= t-olsrv2-management-snapshot is ready for WGLC. As a reminder, this document aims for publication as a Proposed Standard. I have, therefore, reviewed the document carefully. In my opinion, the auth= or is right - in my opinion this document is ready for WGLC. Moreover, I believe that it is a highly important document for the WG to pr= oduce, as it fills a real need, and does so by relying on already-published= crypto RFCs, rather than by coming up with something esoteric. I have two issues, and handful nits, that I expect the author will consider= along with any other WGLC comments they may receive. Of course, if a new v= ersion is spun before WGLC is requested, then I'll gladly review that, also= . Point being: let's get a call started on this document, none of my nits a= nd issues are of the sort that should be blocking. One of the issues is "need a non-jetlagged ADs advice to be sure we do the = right thing", the other is - I think - a minor mix-up with a trivial editor= ial resolution and zero technical impact on this specification. Either way, for information, I include all issues and nits that I've found = in the below. Issues: o In my opinion, "Updates 7182" is inappropriate. What= this document does is: (i) only things permissible by = RFC7182, and (ii) makes registration from IAN= A registries set up by RFC7182 (noting, of course, that RF= C7181 doesn't "Updates 5444" when making registrations = for TC messages from the repositories set up by RFC5444 as a cas= e of precedent) Consequently, I believe that the abstract, introduc= tion, and document header, needs updates to reflect that this is not a= n update. Caveat Lector: I have bounced this around with the = author, and I think that the conclusion i= s that we need just a friendly ADs opinion - my understand= ing is that the author "wants this out, but wants = it done right, also", something to which I can but adhere. I believe that we should WG= LC the document. If the AD finds the time to address t= his issue during WGLC, great - otherwise, we can reflect t= his in the "Document Writeup" that the AD will consider w= ith the publication request - as this (imo) is procedural/ed= itorial, and certainly not technical. o Introduction, 4th paragraph: Isn't it RFC7183 which does shared-secret-key ICVs?= I just did a quick grep through of "shared" in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that ca= se. And "secret" is not mentioned anywhere in 7182 Nits: o Introduction, 1st paragraph: OLD: This specification extends the TLV defi= nitions therein by defining two new cryptograph= ic function code points that allow the use of an identity-based sign= ature (IBS) as an ICV. NEW: This specification defines two new cryp= tographic function code points from within the registries = set up by [RFC7182], that allow the use of an identity-based= signature (IBS) as an ICV. o Introduction, 2nd paragraph, 1st line: I took a double-take when I saw the parenthesis "(protocol participant)" - that seems a little odd,= and I am on a crusade against redundant and hard-to-parse terminology ;) I think that what is meant is "router, which is run= ning a routing protocol which is based on RFC5444", so could the d= ocument not say that? In any event, I do not see "protocol participant" d= efined or anywhere else, and so it seems unfortunate to *not* be explicit he= re. o Introduction, 3rd paragraph: OLD: Two options for the choice of identity = are supported (the two code points allocated). NEW: Two options for the choice of identity = are supported (as reflected by the two code points allocated). o Introduction, 7th paragraph: Caveating that using this introduces the danger tha= t "if you catch the trusted authority, then you're screwed" is awesome.= I see that this is repeated and reworded in the Security Consi= derations section, and I approve. Now, my question is then, if this should not be sta= ted in the Applicability statement, also? Something to the effect of that th= is applies to networks where all routers can (at some point) be in contact= with the TA (to be keyed), but that this can be off-line - and probabl= y should be off-line since the TA really, really should be protected. It might be argued that the forward-reference to Se= ction 6 captures this - I still think, that a few choice words in th= e applicability statement would help greatly. o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to= quantify the computational load? I asked a crypto-wonk-colleague= , who said something to the effect of "the document is perfect= ly right, on this point, but I do not have a paper just off the top o= f my head with interesting data to offer". For that reason alone, = it'd be interesting if you did ;) o Throw-away comment, I appreciate particularly the la= st paragraph of the introduction. o Section 4.1, first bullet OLD: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined there) uses the hash function w= ithin the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. NEW: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined in [RFC7182]) uses the hash fun= ction within the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. o While we are at it, it it crystal-clear to everybody= that "Section 4.2" in the bullet above is to *this* document, as not RFC7= 182? o Section 4.3, 2nd bullet There's a LOT of information embedded in this bulle= t, and reading it suggests that it, readability-wise, might benefit f= rom embedding a: ... ... o IANA Considerations: Given recent experiences in this WG and with reques= ting IANA registrations, may I suggest that this be modified = to say, more explicitly: 1) IANA is requested to reserve= ECCSI with description ___ and reference "This Specifi= cation" 2) IANA is requested to reserve= ECCSI-ADDR.... (similar) 3) The "Cryptographic Functions= Registry", defined in [RFC7182], with these regis= trations made, will look like Table 1, which replace= s Table 11 of [RFC7182] 4) Obviously, include in Table = 1 the registrations from RFC7182. 5) That this document does not = modify the expert review guidelines as set fo= rth in RFC7182 for future allocations. That's all. Thanks for writing this document, Chris. Respectfully, Thomas ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B823GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

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

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

 <= /p>

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 28 July 2014 14:19
To: manet; <manet-chairs@tools.ietf.org>; manet-ads
Cc: Christopher Dearlove
Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs

 

 

*** WARNING ***=

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

Dear WG Chairs, 

Dear Chris, all,

 

As the author indicated by email recently, he believ= es that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 

 

As a reminder, this document aims for publication as= a Proposed Standard.

 

I have, therefore, reviewed the document carefully. = In my opinion, the author is right — in my opinion this document is ready for WGLC.

 

Moreover, I believe that it is a highly important do= cument for the WG to produce, as it fills a real need, and does so by relyi= ng on already-published crypto RFCs, rather than by coming up with somethin= g esoteric.

 

I have two issues, and handful nits, that I expect t= he author will consider along with any other WGLC comments they may receive= . Of course, if a new version is spun before WGLC is requested, then I̵= 7;ll gladly review that, also. Point being: let’s get a call started on this document, none of my nits and= issues are of the sort that should be blocking.

 

One of the issues is “need a non-jetlagged ADs= advice to be sure we do the right thing”, the other is — I thi= nk — a minor mix-up with a trivial editorial resolution and zero tech= nical impact on this specification.

 

Either way, for information, I include all issues an= d nits that I’ve found in the below.

 

Issues:

 

   &nb= sp;        o          In my opinion, “Updates 7182” is inappropriate. What thi= s document does is:

   &nb= sp;            =             &nb= sp;       (i)      &nb= sp;  only things permissible by RFC7182, and 

   &nb= sp;            =             &nb= sp;       (ii)      &n= bsp; makes registration from IANA registries set up by RFC7182<= /o:p>

   &nb= sp;            =             &nb= sp;            =        (noting, of course, that RFC7181 doesn’t “Updates 5444&#= 8221; 

   &nb= sp;            =             &nb= sp;             &= nbsp;      when making registrations for TC= messages from the repositories 

   &nb= sp;            =             &nb= sp;            =         set up by RFC5444 as a case of precedent)

   &nb= sp;            =         Consequently, I believe that the abstract, introduction, and document =

   &nb= sp;            =         header, needs updates to reflect that this is not an update.

   &nb= sp;            =        

   &nb= sp;            =         Caveat Lector: I have bounced this around with the author, and I =

   &nb= sp;            =             &nb= sp;            =        think that the conclusion is that we need just a friendly =

   &nb= sp;            =             &nb= sp;            =        ADs opinion — my understanding is that the author

   &nb= sp;            =             &nb= sp;            =        “wants this out, but wants it done right, also”, somethi= ng

   &nb= sp;            =             &nb= sp;            =        to which I can but adhere.

   &nb= sp;            =        

   &nb= sp;            =             &nb= sp;            =        I believe that we should WGLC the document. If the AD

   &nb= sp;            =             &nb= sp;            =        finds the time to address this issue during WGLC, great -=

   &nb= sp;            =             &nb= sp;            =        otherwise, we can reflect this in the “Document Writeup”=

   &nb= sp;            =             &nb= sp;            =        that the AD will consider with the publication request — as

   &nb= sp;            =             &nb= sp;            =        this (imo) is procedural/editorial, and certainly not technical.

 

   &nb= sp;        o          Introduction, 4th paragraph:

 

   &nb= sp;            =         Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quic= k

   &nb= sp;            =         grep through of “shared” in 7182, and found just a few mentions= , notably

   &nb= sp;            =         setting a side a value for key-id-length in that case. And “secr= et” is not

   &nb= sp;            =         mentioned anywhere in 7182

 

 

Nits:

   &nb= sp;        o          Introduction, 1st paragraph:

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       This specification extends the TLV definitions

   &nb= sp;            =             &nb= sp;       therein by defining two new cryptographic function code points that<= o:p>

   &nb= sp;            =             &nb= sp;       allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       This specification defines two new cryptographic function =

   &nb= sp;            =             &nb= sp;       code points from within the registries set up by [RFC7182], 

   &nb= sp;            =             &nb= sp;       that allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;        o          Introduction, 2nd paragraph, 1st line:

   &nb= sp;            =         I took a double-take when I saw the parenthesis 

   &nb= sp;            =         “(protocol participant)” — that seems a little odd, and I= am on a crusade

   &nb= sp;            =         against redundant and hard-to-parse terminology ;)

 

   &nb= sp;            =         I think that what is meant is “router, which is running a routing&nbs= p;

   &nb= sp;            =         protocol which is based on RFC5444”, so could the document not say

   &nb= sp;            =         that?

 

   &nb= sp;            =         In any event, I do not see “protocol participant” defined or an= ywhere else,

   &nb= sp;            =         and so it seems unfortunate to *not* be explicit here.

 

   &nb= sp;        o          Introduction, 3rd paragraph:

 

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (the two code

   &nb= sp;            =             &nb= sp;       points allocated).

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (as reflected

   &nb= sp;            =             &nb= sp;       by the two code points allocated).

 

 

   &nb= sp;        o          Introduction, 7th paragraph:

   &nb= sp;            =         Caveating that using this introduces the danger that “if you catch th= e 

   &nb= sp;            =         trusted authority, then you’re screwed” is awesome. I see that&= nbsp;

   &nb= sp;            =         this is repeated and reworded in the Security Considerations section,<= /o:p>

   &nb= sp;            =         and I approve. 

 

   &nb= sp;            =         Now, my question is then, if this should not be stated in the Applicability=  

   &nb= sp;            =         statement, also? Something to the effect of that this applies to networks

   &nb= sp;            =         where all routers can (at some point) be in contact with the TA (to be=

   &nb= sp;            =         keyed), but that this can be off-line — and probably should be off-li= ne

   &nb= sp;            =         since the TA really, really should be protected.

 

   &nb= sp;            =         It might be argued that the forward-reference to Section 6 captures

   &nb= sp;            =         this — I still think, that a few choice words in the applicability st= atement

   &nb= sp;            =         would help greatly.

 

   &nb= sp;        o          Introduction, 9th paragraph:

   &nb= sp;            =         Any [academic? otherwise] work that you can cite to quantify the =

   &nb= sp;            =         computational load? I asked a crypto-wonk-colleague, who said

   &nb= sp;            =         something to the effect of “the document is perfectly right, on this<= o:p>

   &nb= sp;            =         point, but I do not have a paper just off the top of my head with = ;

   &nb= sp;            =         interesting data to offer”. For that reason alone, it’d be inte= resting 

   &nb= sp;            =         if you did ;)

 

   &nb= sp;        o          Throw-away comment, I appreciate particularly the last

   &nb= sp;            =         paragraph of the introduction.

 

   &nb= sp;        o          Section 4.1, first bullet

 

   &nb= sp;            =         OLD:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined there) uses the hash function withi= n the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;            =                length of N octets, as specified in Section 4.2.=

 

   &nb= sp;            =         NEW:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined in [RFC7182]) uses the hash functio= n within the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;             = ;              length of N octets, as specified in Section 4.2.=

 

   &nb= sp;        o          While we are at it, it it crystal-clear to everybody that “Sec= tion 4.2” in

   &nb= sp;            =         the bullet above is to *this* document, as not RFC7182?

 

   &nb= sp;        o          Section 4.3, 2nd bullet

   &nb= sp;            =         There’s a LOT of information embedded in this bullet, and reading it<= o:p>

   &nb= sp;            =         suggests that it, readability-wise, might benefit from embedding a:

   &nb= sp;            =             &nb= sp;       <list style=3D“hanging”>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Packet TLVs”>…</t>=

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Message TLVs”>…</t>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Address Block TLVs”>…</t&g= t;

   &nb= sp;            =             &nb= sp;       </list>

 

   &nb= sp;        o          IANA Considerations:

 

   &nb= sp;            =         Given recent experiences in this WG and with requesting IANA 

   &nb= sp;            =         registrations, may I suggest that this be modified to say, more<= /p>

   &nb= sp;            =         explicitly:

 

   &nb= sp;            =             &nb= sp;       1)      = ;   IANA is requested to reserve ECCSI with description __= _ 

   &nb= sp;            =             &nb= sp;            =        and reference “This Specification”

 

   &nb= sp;            =             &nb= sp;       2)      = ;   IANA is requested to reserve ECCSI-ADDR…. (simil= ar)

 

   &nb= sp;            =             &nb= sp;       3)      = ;   The “Cryptographic Functions Registry”, de= fined in 

   &nb= sp;            =             &nb= sp;            =        [RFC7182], with these registrations made, will look

   &nb= sp;            =             &nb= sp;            =        like Table 1, which replaces Table 11 of [RFC7182]

 

   &nb= sp;            =             &nb= sp;       4)      = ;   Obviously, include in Table 1 the registrations from

   &nb= sp;            =             &nb= sp;            =        RFC7182.

 

   &nb= sp;            =             &nb= sp;       5)      = ;   That this document does not modify the expert

   &nb= sp;            =             &nb= sp;            =        review guidelines as set forth in RFC7182 for

   &nb= sp;            =             &nb= sp;            =        future allocations.

 

That’s all. Thanks for writing this document, = Chris. 

 

 

Respectfully,

 

Thomas

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B823GLKXM0002VGREEN_-- From nobody Tue Jul 29 07:17:18 2014 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 552031B28B5 for ; Tue, 29 Jul 2014 07:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 f0_AN_KScD-R for ; Tue, 29 Jul 2014 07:17:08 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279441B28A8 for ; Tue, 29 Jul 2014 07:17:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,757,1400022000"; d="scan'208,217";a="461921281" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 29 Jul 2014 15:17:04 +0100 X-IronPort-AV: E=Sophos; i="5.01,757,1400022000"; d="scan'208,217"; a="59406335" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 29 Jul 2014 15:17:01 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Tue, 29 Jul 2014 15:17:01 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , manet , "" , manet-ads Thread-Topic: Ready for WGLC: Advancing draft-ietf-manet-ibs Thread-Index: AQHPqmaMr2jXtWmnY0aFPOP7noXFq5u3F+hw Date: Tue, 29 Jul 2014 14:17:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B83FGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MYHGHc1uboVSxiNRk9bXadWmHQk Cc: Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 29 Jul 2014 14:17:15 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B83FGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable (Apologies for the previous accidental empty send.) I'll pick up a separate point this time, namely Isn't it RFC7183 which does shared-secret-key ICVs?= I just did a quick grep through of "shared" in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that ca= se. And "secret" is not mentioned anywhere in 7182 7182 contains both symmetric and asymmetric ciphers, on the one hand DSA, H= MAC, 3DES, AES, on the other hand RSA, ECDSA. How the keys are organised is not discussed in 7182, it is rather implicit.= In the symmetric case we need to share keys, this Could be as simple as a single shared key, but as exemplified by 7183 (whic= h uses one of the symmetric cases) this could Be multiple keys. In the asymmetric case we have pairwise keys, pre-distrib= uted or with public keys certified, and a PKI On top of that. So 7182 implicitly (but not explicitly) offers us these thr= ee options (shared keys, pre-shared pairwise keys, PKI - and the overhead of certificates). As this document is about 7182, not 7183 (which is NHDP/OLSRv2 only) I'd ra= ther stick to just referencing and discussing 7182, But a wording tweak may be in order. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Clausen [mailto:thomas@thomasclausen.org] Sent: 28 July 2014 14:19 To: manet; ; manet-ads Cc: Christopher Dearlove Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Dear WG Chairs, Dear Chris, all, As the author indicated by email recently, he believes that draft-ietf-mane= t-olsrv2-management-snapshot is ready for WGLC. As a reminder, this document aims for publication as a Proposed Standard. I have, therefore, reviewed the document carefully. In my opinion, the auth= or is right - in my opinion this document is ready for WGLC. Moreover, I believe that it is a highly important document for the WG to pr= oduce, as it fills a real need, and does so by relying on already-published= crypto RFCs, rather than by coming up with something esoteric. I have two issues, and handful nits, that I expect the author will consider= along with any other WGLC comments they may receive. Of course, if a new v= ersion is spun before WGLC is requested, then I'll gladly review that, also= . Point being: let's get a call started on this document, none of my nits a= nd issues are of the sort that should be blocking. One of the issues is "need a non-jetlagged ADs advice to be sure we do the = right thing", the other is - I think - a minor mix-up with a trivial editor= ial resolution and zero technical impact on this specification. Either way, for information, I include all issues and nits that I've found = in the below. Issues: o In my opinion, "Updates 7182" is inappropriate. What= this document does is: (i) only things permissible by = RFC7182, and (ii) makes registration from IAN= A registries set up by RFC7182 (noting, of course, that RF= C7181 doesn't "Updates 5444" when making registrations = for TC messages from the repositories set up by RFC5444 as a cas= e of precedent) Consequently, I believe that the abstract, introduc= tion, and document header, needs updates to reflect that this is not a= n update. Caveat Lector: I have bounced this around with the = author, and I think that the conclusion i= s that we need just a friendly ADs opinion - my understand= ing is that the author "wants this out, but wants = it done right, also", something to which I can but adhere. I believe that we should WG= LC the document. If the AD finds the time to address t= his issue during WGLC, great - otherwise, we can reflect t= his in the "Document Writeup" that the AD will consider w= ith the publication request - as this (imo) is procedural/ed= itorial, and certainly not technical. o Introduction, 4th paragraph: Isn't it RFC7183 which does shared-secret-key ICVs?= I just did a quick grep through of "shared" in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that ca= se. And "secret" is not mentioned anywhere in 7182 Nits: o Introduction, 1st paragraph: OLD: This specification extends the TLV defi= nitions therein by defining two new cryptograph= ic function code points that allow the use of an identity-based sign= ature (IBS) as an ICV. NEW: This specification defines two new cryp= tographic function code points from within the registries = set up by [RFC7182], that allow the use of an identity-based= signature (IBS) as an ICV. o Introduction, 2nd paragraph, 1st line: I took a double-take when I saw the parenthesis "(protocol participant)" - that seems a little odd,= and I am on a crusade against redundant and hard-to-parse terminology ;) I think that what is meant is "router, which is run= ning a routing protocol which is based on RFC5444", so could the d= ocument not say that? In any event, I do not see "protocol participant" d= efined or anywhere else, and so it seems unfortunate to *not* be explicit he= re. o Introduction, 3rd paragraph: OLD: Two options for the choice of identity = are supported (the two code points allocated). NEW: Two options for the choice of identity = are supported (as reflected by the two code points allocated). o Introduction, 7th paragraph: Caveating that using this introduces the danger tha= t "if you catch the trusted authority, then you're screwed" is awesome.= I see that this is repeated and reworded in the Security Consi= derations section, and I approve. Now, my question is then, if this should not be sta= ted in the Applicability statement, also? Something to the effect of that th= is applies to networks where all routers can (at some point) be in contact= with the TA (to be keyed), but that this can be off-line - and probabl= y should be off-line since the TA really, really should be protected. It might be argued that the forward-reference to Se= ction 6 captures this - I still think, that a few choice words in th= e applicability statement would help greatly. o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to= quantify the computational load? I asked a crypto-wonk-colleague= , who said something to the effect of "the document is perfect= ly right, on this point, but I do not have a paper just off the top o= f my head with interesting data to offer". For that reason alone, = it'd be interesting if you did ;) o Throw-away comment, I appreciate particularly the la= st paragraph of the introduction. o Section 4.1, first bullet OLD: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined there) uses the hash function w= ithin the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. NEW: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined in [RFC7182]) uses the hash fun= ction within the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. o While we are at it, it it crystal-clear to everybody= that "Section 4.2" in the bullet above is to *this* document, as not RFC7= 182? o Section 4.3, 2nd bullet There's a LOT of information embedded in this bulle= t, and reading it suggests that it, readability-wise, might benefit f= rom embedding a: ... ... o IANA Considerations: Given recent experiences in this WG and with reques= ting IANA registrations, may I suggest that this be modified = to say, more explicitly: 1) IANA is requested to reserve= ECCSI with description ___ and reference "This Specifi= cation" 2) IANA is requested to reserve= ECCSI-ADDR.... (similar) 3) The "Cryptographic Functions= Registry", defined in [RFC7182], with these regis= trations made, will look like Table 1, which replace= s Table 11 of [RFC7182] 4) Obviously, include in Table = 1 the registrations from RFC7182. 5) That this document does not = modify the expert review guidelines as set fo= rth in RFC7182 for future allocations. That's all. Thanks for writing this document, Chris. Respectfully, Thomas ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B83FGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

(Apologies for the previo= us accidental empty send.)

 <= /p>

I’ll pick up a sepa= rate point this time, namely

 <= /p>

   &nb= sp;            =         Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quic= k

   &nb= sp;            =         grep through of “shared” in 7182, and found just a few mentions= , notably

   &nb= sp;            =         setting a side a value for key-id-length in that case. And “secr= et” is not

   &nb= sp;            =         mentioned anywhere in 7182

 <= /p>

7182 contains both symmet= ric and asymmetric ciphers, on the one hand DSA, HMAC, 3DES, AES, on the ot= her hand RSA, ECDSA.

 <= /p>

How the keys are organise= d is not discussed in 7182, it is rather implicit. In the symmetric case we= need to share keys, this

Could be as simple as a s= ingle shared key, but as exemplified by 7183 (which uses one of the symmetr= ic cases) this could

Be multiple keys. In the = asymmetric case we have pairwise keys, pre-distributed or with public keys = certified, and a PKI

On top of that. So 7182 i= mplicitly (but not explicitly) offers us these three options (shared keys, = pre-shared pairwise keys,

PKI – and the overh= ead of certificates).

 <= /p>

As this document is about= 7182, not 7183 (which is NHDP/OLSRv2 only) I’d rather stick to just = referencing and discussing 7182,

But a wording tweak may b= e in order.

 <= /p>

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

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

 <= /p>

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 28 July 2014 14:19
To: manet; <manet-chairs@tools.ietf.org>; manet-ads
Cc: Christopher Dearlove
Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs

 

 

*** WARNING ***=

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

Dear WG Chairs, 

Dear Chris, all,

 

As the author indicated by email recently, he believ= es that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 

 

As a reminder, this document aims for publication as= a Proposed Standard.

 

I have, therefore, reviewed the document carefully. = In my opinion, the author is right — in my opinion this document is ready for WGLC.

 

Moreover, I believe that it is a highly important do= cument for the WG to produce, as it fills a real need, and does so by relyi= ng on already-published crypto RFCs, rather than by coming up with somethin= g esoteric.

 

I have two issues, and handful nits, that I expect t= he author will consider along with any other WGLC comments they may receive= . Of course, if a new version is spun before WGLC is requested, then I̵= 7;ll gladly review that, also. Point being: let’s get a call started on this document, none of my nits and= issues are of the sort that should be blocking.

 

One of the issues is “need a non-jetlagged ADs= advice to be sure we do the right thing”, the other is — I thi= nk — a minor mix-up with a trivial editorial resolution and zero tech= nical impact on this specification.

 

Either way, for information, I include all issues an= d nits that I’ve found in the below.

 

Issues:

 

   &nb= sp;        o          In my opinion, “Updates 7182” is inappropriate. What thi= s document does is:

   &nb= sp;            =             &nb= sp;       (i)      &nb= sp;  only things permissible by RFC7182, and 

   &nb= sp;            =             &nb= sp;       (ii)      &n= bsp; makes registration from IANA registries set up by RFC7182<= /o:p>

   &nb= sp;            =             &nb= sp;            =        (noting, of course, that RFC7181 doesn’t “Updates 5444&#= 8221; 

   &nb= sp;            =             &nb= sp;             &= nbsp;      when making registrations for TC= messages from the repositories 

   &nb= sp;            =             &nb= sp;            =         set up by RFC5444 as a case of precedent)

   &nb= sp;            =         Consequently, I believe that the abstract, introduction, and document =

   &nb= sp;            =         header, needs updates to reflect that this is not an update.

   &nb= sp;            =        

   &nb= sp;            =         Caveat Lector: I have bounced this around with the author, and I =

   &nb= sp;            =             &nb= sp;            =        think that the conclusion is that we need just a friendly =

   &nb= sp;            =             &nb= sp;            =        ADs opinion — my understanding is that the author

   &nb= sp;            =             &nb= sp;            =        “wants this out, but wants it done right, also”, somethi= ng

   &nb= sp;            =             &nb= sp;            =        to which I can but adhere.

   &nb= sp;            =        

   &nb= sp;            =             &nb= sp;            =        I believe that we should WGLC the document. If the AD

   &nb= sp;            =             &nb= sp;            =        finds the time to address this issue during WGLC, great -=

   &nb= sp;            =             &nb= sp;            =        otherwise, we can reflect this in the “Document Writeup”=

   &nb= sp;            =             &nb= sp;            =        that the AD will consider with the publication request — as

   &nb= sp;            =             &nb= sp;            =        this (imo) is procedural/editorial, and certainly not technical.

 

   &nb= sp;        o          Introduction, 4th paragraph:

 

   &nb= sp;            =         Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quic= k

   &nb= sp;            =         grep through of “shared” in 7182, and found just a few mentions= , notably

   &nb= sp;            =         setting a side a value for key-id-length in that case. And “secr= et” is not

   &nb= sp;            =         mentioned anywhere in 7182

 

 

Nits:

   &nb= sp;        o          Introduction, 1st paragraph:

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       This specification extends the TLV definitions

   &nb= sp;            =             &nb= sp;       therein by defining two new cryptographic function code points that<= o:p>

   &nb= sp;            =             &nb= sp;       allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       This specification defines two new cryptographic function =

   &nb= sp;            =             &nb= sp;       code points from within the registries set up by [RFC7182], 

   &nb= sp;            =             &nb= sp;       that allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;        o          Introduction, 2nd paragraph, 1st line:

   &nb= sp;            =         I took a double-take when I saw the parenthesis 

   &nb= sp;            =         “(protocol participant)” — that seems a little odd, and I= am on a crusade

   &nb= sp;            =         against redundant and hard-to-parse terminology ;)

 

   &nb= sp;            =         I think that what is meant is “router, which is running a routing&nbs= p;

   &nb= sp;            =         protocol which is based on RFC5444”, so could the document not say

   &nb= sp;            =         that?

 

   &nb= sp;            =         In any event, I do not see “protocol participant” defined or an= ywhere else,

   &nb= sp;            =         and so it seems unfortunate to *not* be explicit here.

 

   &nb= sp;        o          Introduction, 3rd paragraph:

 

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (the two code

   &nb= sp;            =             &nb= sp;       points allocated).

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (as reflected

   &nb= sp;            =             &nb= sp;       by the two code points allocated).

 

 

   &nb= sp;        o          Introduction, 7th paragraph:

   &nb= sp;            =         Caveating that using this introduces the danger that “if you catch th= e 

   &nb= sp;            =         trusted authority, then you’re screwed” is awesome. I see that&= nbsp;

   &nb= sp;            =         this is repeated and reworded in the Security Considerations section,<= /o:p>

   &nb= sp;            =         and I approve. 

 

   &nb= sp;            =         Now, my question is then, if this should not be stated in the Applicability=  

   &nb= sp;            =         statement, also? Something to the effect of that this applies to networks

   &nb= sp;            =         where all routers can (at some point) be in contact with the TA (to be=

   &nb= sp;            =         keyed), but that this can be off-line — and probably should be off-li= ne

   &nb= sp;            =         since the TA really, really should be protected.

 

   &nb= sp;            =         It might be argued that the forward-reference to Section 6 captures

   &nb= sp;            =         this — I still think, that a few choice words in the applicability st= atement

   &nb= sp;            =         would help greatly.

 

   &nb= sp;        o          Introduction, 9th paragraph:

   &nb= sp;            =         Any [academic? otherwise] work that you can cite to quantify the =

   &nb= sp;            =         computational load? I asked a crypto-wonk-colleague, who said

   &nb= sp;            =         something to the effect of “the document is perfectly right, on this<= o:p>

   &nb= sp;            =         point, but I do not have a paper just off the top of my head with = ;

   &nb= sp;            =         interesting data to offer”. For that reason alone, it’d be inte= resting 

   &nb= sp;            =         if you did ;)

 

   &nb= sp;        o          Throw-away comment, I appreciate particularly the last

   &nb= sp;            =         paragraph of the introduction.

 

   &nb= sp;        o          Section 4.1, first bullet

 

   &nb= sp;            =         OLD:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined there) uses the hash function withi= n the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;            =                length of N octets, as specified in Section 4.2.=

 

   &nb= sp;            =         NEW:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined in [RFC7182]) uses the hash functio= n within the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;             = ;              length of N octets, as specified in Section 4.2.=

 

   &nb= sp;        o          While we are at it, it it crystal-clear to everybody that “Sec= tion 4.2” in

   &nb= sp;            =         the bullet above is to *this* document, as not RFC7182?

 

   &nb= sp;        o          Section 4.3, 2nd bullet

   &nb= sp;            =         There’s a LOT of information embedded in this bullet, and reading it<= o:p>

   &nb= sp;            =         suggests that it, readability-wise, might benefit from embedding a:

   &nb= sp;            =             &nb= sp;       <list style=3D“hanging”>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Packet TLVs”>…</t>=

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Message TLVs”>…</t>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Address Block TLVs”>…</t&g= t;

   &nb= sp;            =             &nb= sp;       </list>

 

   &nb= sp;        o          IANA Considerations:

 

   &nb= sp;            =         Given recent experiences in this WG and with requesting IANA 

   &nb= sp;            =         registrations, may I suggest that this be modified to say, more<= /p>

   &nb= sp;            =         explicitly:

 

   &nb= sp;            =             &nb= sp;       1)      = ;   IANA is requested to reserve ECCSI with description __= _ 

   &nb= sp;            =             &nb= sp;            =        and reference “This Specification”

 

   &nb= sp;            =             &nb= sp;       2)      = ;   IANA is requested to reserve ECCSI-ADDR…. (simil= ar)

 

   &nb= sp;            =             &nb= sp;       3)      = ;   The “Cryptographic Functions Registry”, de= fined in 

   &nb= sp;            =             &nb= sp;            =        [RFC7182], with these registrations made, will look

   &nb= sp;            =             &nb= sp;            =        like Table 1, which replaces Table 11 of [RFC7182]

 

   &nb= sp;            =             &nb= sp;       4)      = ;   Obviously, include in Table 1 the registrations from

   &nb= sp;            =             &nb= sp;            =        RFC7182.

 

   &nb= sp;            =             &nb= sp;       5)      = ;   That this document does not modify the expert

   &nb= sp;            =             &nb= sp;            =        review guidelines as set forth in RFC7182 for

   &nb= sp;            =             &nb= sp;            =        future allocations.

 

That’s all. Thanks for writing this document, = Chris. 

 

 

Respectfully,

 

Thomas

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B83FGLKXM0002VGREEN_-- From nobody Tue Jul 29 07:36:11 2014 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 22B821B28E1 for ; Tue, 29 Jul 2014 07:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 vXhekDfPslna for ; Tue, 29 Jul 2014 07:36:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809741B281E for ; Tue, 29 Jul 2014 07:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7502; q=dns/txt; s=iport; t=1406644567; x=1407854167; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1h9s4L+pqIW/JCfN7s+Ffko05eOhyC8gluhg6p8EeFM=; b=fQsmTzGE+CJkjmTT707SOEr+6Qr9UG8uZzenMbJpiR6NHZ8TgnSkr0+8 zFCEKRtbA3wKf4BkqY3Tr4N1FV+E9VjL94nH5AnaqrnsJm85jMvYCYsxZ EMjPRLUk8gN28WjXaj1FhlZKb0UgEoNm5gEma2DGX20vLr34EsZoNF9uR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAPSv11OtJV2Y/2dsb2JhbABZgw5SVwTLYgEJh0sBgQ4Wd4QEAQEEAQEBGlELEAIBCDsEBycLFBECBA4FiEINvygTBI5qEAIBTwYBgy+BGwWbTJROggOBRmyBRQ X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208,217";a="343678754" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jul 2014 14:36:04 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6TEa4uH007214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 14:36:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 09:36:03 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Clausen Thread-Topic: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis Thread-Index: AQHPqmiIFlWy41WnCkO3ilTYM6Pnupu3c9mA Date: Tue, 29 Jul 2014 14:36:03 +0000 Message-ID: <7918A059-8300-4B24-865E-3C2F7ABB1348@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: multipart/alternative; boundary="_000_7918A05983004B24865E3C2F7ABB1348ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2nznOAjsrJy9iEaxqC6EUli-Lqs Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis 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, 29 Jul 2014 14:36:11 -0000 --_000_7918A05983004B24865E3C2F7ABB1348ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thomas, On Jul 28, 2014, at 9:33 AM, Thomas Clausen > wrote: Dear WG Chairs, co-authors, all, As indicated in Toronto, the authors believe that the remaining issue with = draft-ietf-manet-nhdp-optimization was how to properly do the updates to th= e MIB module of RFC6779. We believe that Toronto confirmed that the way forward was to do an RFC6779= bis document, which reflects the MIB considerations section (Section 6) fro= m draft-ietf-manet-nhdp-optimization, which the WG already adopted, into RF= C6779. As Ulrich indicated in his recent mail, this is what draft-clausen-manet-rf= c6779bis does =97 nothing more, nothing less. I believe that with this issue resolved, draft-ietf-manet-nhdp-optimization= & draft-clausen-manet-rfc6779bis essentially are ready for WGLC. I don't agree with you here, mainly because: 1. draft-clausen-manet-rfc6779bis-00 technically isn't even a WG document, 2. You state the documents are ready for WGLC, then outline a proposal for = updating them. I'd rather see any known edits go into WGLC, instead of eith= er running concurrently with WGLC. Here's what I propose going forward: 1. I'll issue an email calling for WG adoption of draft-clausen-manet-rfc67= 79bis 2. If the WG adopts draft-clausen-rfc6779bis, then you can update draft-iet= f-manet-nhdp-optimization (or, if you feel certain about WG adoption, you a= re free to update nhdp-optimization at any time) 3. If the WG adopts draft-clausen-rfc6779bis, I will then call for WGLC on = both documents, once the update to draft-ietf-manet-nhdp-optimization is do= ne. Regards, Stan As a reminder, both documents aims publication as an Proposed Standard RFCs= . Procedurally, I would like to enter a rapid succession of: 1) Submission of draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6= 779bis-00 2) Submission of draft-ietf-manet-nhdp-optimization-01, with the only diffe= rence to -00 being section 6 removed, and replaced by a reference to draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779bis-00 3) A WGLC being issued for both these documents, concurrently. WG Chairs, would you kindly let us know your thoughts on this matter, at yo= ur earliest convenience, so that we may aim at a WGLC soon, such that the W= G will have visible progress to report at the RTG Area Open Meeting? Respectfully, Thomas _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_7918A05983004B24865E3C2F7ABB1348ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Thomas, 

On Jul 28, 2014, at 9:33 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:

Dear WG Chairs, co-authors, all,

As indicated in Toronto, the authors believe that the remaining issue = with draft-ietf-manet-nhdp-optimization was how to properly do the updates = to the MIB module of RFC6779.

We believe that Toronto confirmed that the way forward was to do an RF= C6779bis document, which reflects the MIB considerations section (Section 6= ) from draft-ietf-manet-nhdp-optimization, which the WG already adopte= d, into RFC6779.

As Ulrich indicated in his recent mail, this is what draft-clause= n-manet-rfc6779bis does =97 nothing more, nothing less.

I believe that with this issue resolved, draft-ietf-manet-nhdp-optimiz= ation & draft-clausen-manet-rfc6779bis essentially are ready for WGLC. 

I don't agree with you here, mainly because:
1. draft-clausen-manet-rfc6779bis-00 technically isn't even a WG docum= ent,
2. You state the documents are ready for WGLC, then outline a proposal= for updating them. I'd rather see any known edits go into WGLC, instead of= either running concurrently with WGLC. 

Here's what I propose going forward: 
1. I'll issue an email calling for WG adoption of draft-clausen-manet-= rfc6779bis
2. If the WG adopts draft-clausen-rfc6779bis, then you can update draf= t-ietf-manet-nhdp-optimization (or, if you feel certain about WG adoption, = you are free to update nhdp-optimization at any time)
3. If the WG adopts draft-clausen-rfc6779bis, I will then call for WGL= C on both documents, once the update to draft-ietf-manet-nhdp-optimization = is done. 

Regards,
Stan


As a reminder, both documents aims publication as an Proposed Standard= RFCs.

Procedurally, I would like to enter a rapid succession of:

1) Submission of draft-clausen-manet-rfc6779bis-00 as draft-ietf-m= anet-rfc6779bis-00

2) Submission of draft-ietf-manet-nhdp-optimization-01, with the o= nly difference to -00
being = section 6 removed, and replaced by a reference to 
draft-= clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779bis-00

3) A WGLC being issued for both these documents, concurrently.

WG Chairs, would you kindly let us know your thoughts on this matter, = at your earliest convenience, so that we may aim at a WGLC soon, such that = the WG will have visible progress to report at the RTG Area Open Meeting?

Respectfully,

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

--_000_7918A05983004B24865E3C2F7ABB1348ciscocom_-- From nobody Tue Jul 29 07:38:59 2014 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 8A93B1B28F2 for ; Tue, 29 Jul 2014 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 MWO4STT0kjrL for ; Tue, 29 Jul 2014 07:38:52 -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 84DFE1B28E1 for ; Tue, 29 Jul 2014 07:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=342; q=dns/txt; s=iport; t=1406644732; x=1407854332; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=o7M5TI6bh28rrLlCiwYSrbTOqZNTaSM+NAqXz226KWI=; b=e5PPHXut0B9CBqXfvxfFyFQI1Hya55HaP0EMhiwq+xHvzPmnZO9JprPH oUi636HbKjoqK/fjCStVumq/lNVdcbOCRjab+0HElbsJWZl55o03UCC2r a4kGTGkmgItHL5NJ1/sYRU/hv1bdkE2AgoYWgp69CP+6dm6OdCvp2bLav g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAOGw11OtJV2Y/2dsb2JhbABZgw6BLdM3AYEOFneEBAEBBIEJAgFOMiUCBIhVvzQXj1ODL4EbBZtMlE6DSYIx X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="64872898" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 29 Jul 2014 14:38:51 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6TEcpe5021089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jul 2014 14:38:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 09:38:51 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Call to adopt draft-clausen-manet-rfc6779bis as a working group document Thread-Index: AQHPqzrPLlz0GX4nOE2x+tvndzz/Xg== Date: Tue, 29 Jul 2014 14:38:50 +0000 Message-ID: <4B6EF2A7-7C89-45FC-9FD7-FF9D3D1561A0@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4024E58B49002745BB40C7B49E82BAA5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ahcCPhb_fcqO9_iNcZd4lHXYnEM Subject: [manet] Call to adopt draft-clausen-manet-rfc6779bis as a working group document 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, 29 Jul 2014 14:38:57 -0000 Working group participants -=20 This is a call to adopt draft-clausen-manet-rfc6779bis as a Working Group d= ocument. If you have issues with the WG accepting this document, please not= e them on the list before close of business on Aug 5, 2014. Lack of a respo= nse will be seen as a vote to accept the document.=20 Regards, Stan From nobody Tue Jul 29 07:41:07 2014 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 0A0A01B2909 for ; Tue, 29 Jul 2014 07:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ZxVKCypltxcm for ; Tue, 29 Jul 2014 07:40:59 -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 EA04C1B2906 for ; Tue, 29 Jul 2014 07:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=242; q=dns/txt; s=iport; t=1406644858; x=1407854458; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7gTJLinO8YpJ7KfqIBRcpzegddEGoQDewbVndxNXVHc=; b=ZIXVIaei9llSxhz8tBXk3u5iMi8t6jJ5ky8yFz7cY0N7RJmcYe8G3bDA g1bsbDAOa/artahl/AK9NDAQW7wr4hdPmUe9LQZC5iNC12C2nMuYVIyq9 mDPUpcMGg58rpC6G5BEhVFahiODnoBn/aAvDCPzC6Cv//u5NPzrhNbZDJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwHACuy11OtJA2J/2dsb2JhbABZgw6BLY0kxhMBgQ4Wd4QEAQEEHR1PAgE+EDIlAgSIVb82F4wtgyaDL4EbBZtMlE6DSYIx X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="64873450" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 29 Jul 2014 14:40:57 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6TEeveB010922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jul 2014 14:40:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 09:40:57 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Working Group Last Call for draft-ietf-manet-olsrv2-management-snapshot Thread-Index: AQHPqzsaIbyhAZV9VUeB2dSL0gOe7g== Date: Tue, 29 Jul 2014 14:40:55 +0000 Message-ID: <72B76A48-18EB-43BC-AA86-A6C90809D47E@cisco.com> References: <139E2EC0-4D23-4590-AE9A-87FBE7165A18@thomasclausen.org> In-Reply-To: <139E2EC0-4D23-4590-AE9A-87FBE7165A18@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <27AD882B1B3B954F8786BAF600442969@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2c5Ao3sMO9H_j0ygfYDG4eawouc Subject: [manet] Working Group Last Call for draft-ietf-manet-olsrv2-management-snapshot 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, 29 Jul 2014 14:41:04 -0000 Working Group participants -=20 This is a working group last call (WGLC) on the above named document. Pleas= e review and raise any issues you may have with the document no later than = August 12, 2014 (2-week WGLC). Regards, Stan= From nobody Tue Jul 29 07:52:50 2014 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 906161A03C1 for ; Tue, 29 Jul 2014 07:52:48 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9co6Hr2z_Vch for ; Tue, 29 Jul 2014 07:52:35 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232C31B293F for ; Tue, 29 Jul 2014 07:52:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F215B2405DC; Tue, 29 Jul 2014 07:52:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.21.24.120] (unknown [37.163.140.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 763C724012D; Tue, 29 Jul 2014 07:52:33 -0700 (PDT) References: <7918A059-8300-4B24-865E-3C2F7ABB1348@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7918A059-8300-4B24-865E-3C2F7ABB1348@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-A1E79468-A900-47BB-BCF0-D071726BC8A6 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12A4331d) From: Thomas Heide Clausen Date: Tue, 29 Jul 2014 16:52:29 +0200 To: "Stan Ratliff (sratliff)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wDEGlL0n-Q-rvn9l-BjvysivfFw Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis 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, 29 Jul 2014 14:52:48 -0000 --Apple-Mail-A1E79468-A900-47BB-BCF0-D071726BC8A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds like something which can offer progress, Stan, so please proceed with= that.=20 Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 > On 29 juil. 2014, at 16:36, Stan Ratliff (sratliff) w= rote: >=20 > Thomas,=20 >=20 >> On Jul 28, 2014, at 9:33 AM, Thomas Clausen wr= ote: >>=20 >> Dear WG Chairs, co-authors, all, >>=20 >> As indicated in Toronto, the authors believe that the remaining issue wit= h draft-ietf-manet-nhdp-optimization was how to properly do the updates to t= he MIB module of RFC6779. >>=20 >> We believe that Toronto confirmed that the way forward was to do an RFC67= 79bis document, which reflects the MIB considerations section (Section 6) fr= om draft-ietf-manet-nhdp-optimization, which the WG already adopted, into RFC= 6779. >>=20 >> As Ulrich indicated in his recent mail, this is what draft-clausen-manet-= rfc6779bis does =E2=80=94 nothing more, nothing less. >>=20 >> I believe that with this issue resolved, draft-ietf-manet-nhdp-optimizati= on & draft-clausen-manet-rfc6779bis essentially are ready for WGLC.=20 >=20 > I don't agree with you here, mainly because: > 1. draft-clausen-manet-rfc6779bis-00 technically isn't even a WG document,= > 2. You state the documents are ready for WGLC, then outline a proposal for= updating them. I'd rather see any known edits go into WGLC, instead of eith= er running concurrently with WGLC.=20 >=20 > Here's what I propose going forward:=20 > 1. I'll issue an email calling for WG adoption of draft-clausen-manet-rfc6= 779bis > 2. If the WG adopts draft-clausen-rfc6779bis, then you can update draft-ie= tf-manet-nhdp-optimization (or, if you feel certain about WG adoption, you a= re free to update nhdp-optimization at any time) > 3. If the WG adopts draft-clausen-rfc6779bis, I will then call for WGLC on= both documents, once the update to draft-ietf-manet-nhdp-optimization is do= ne.=20 >=20 > Regards, > Stan >=20 >>=20 >> As a reminder, both documents aims publication as an Proposed Standard RFC= s. >>=20 >> Procedurally, I would like to enter a rapid succession of: >>=20 >> 1) >> Submission of draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc67= 79bis-00 >>=20 >> 2) >> Submission of draft-ietf-manet-nhdp-optimization-01, with the only differ= ence to -00 >> being section 6 removed, and replaced by a reference to=20 >> draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779bis-00 >>=20 >> 3) >> A WGLC being issued for both these documents, concurrently. >>=20 >> WG Chairs, would you kindly let us know your thoughts on this matter, at y= our earliest convenience, so that we may aim at a WGLC soon, such that the W= G will have visible progress to report at the RTG Area Open Meeting? >>=20 >> Respectfully, >>=20 >> Thomas >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-A1E79468-A900-47BB-BCF0-D071726BC8A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sounds like something which can offer p= rogress, Stan, so please proceed with that. 

T= homas

-- 
Thomas Heide Clausen
"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure&n= bsp;
  which has no relation to reality."
&nbs= p;- Nikola Tesla, 
    Modern Mechanics and In= ventions, July, 1934

On 29 juil. 2014, at 16:36, Stan Ra= tliff (sratliff) <sratliff@cisco.co= m> wrote:

Thomas, 

On Jul 28, 2014, at 9:33 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:

Dear WG Chairs, co-authors, all,

As indicated in Toronto, the authors believe that the remaining issue w= ith draft-ietf-manet-nhdp-optimization was how to properly do the updates to= the MIB module of RFC6779.

We believe that Toronto confirmed that the way forward was to do an RFC= 6779bis document, which reflects the MIB considerations section (Section 6) f= rom draft-ietf-manet-nhdp-optimization, which the WG already adopted, i= nto RFC6779.

As Ulrich indicated in his recent mail, this is what draft-clausen= -manet-rfc6779bis does =E2=80=94 nothing more, nothing less.

I believe that with this issue resolved, draft-ietf-manet-nhdp-optimiza= tion & draft-clausen-manet-rfc6779bis essentially are ready for WGLC. 

I don't agree with you here, mainly because:
1. draft-clausen-manet-rfc6779bis-00 technically isn't even a WG docume= nt,
2. You state the documents are ready for WGLC, then outline a proposal f= or updating them. I'd rather see any known edits go into WGLC, instead of ei= ther running concurrently with WGLC. 

Here's what I propose going forward: 
1. I'll issue an email calling for WG adoption of draft-clausen-manet-r= fc6779bis
2. If the WG adopts draft-clausen-rfc6779bis, then you can update draft= -ietf-manet-nhdp-optimization (or, if you feel certain about WG adoption, yo= u are free to update nhdp-optimization at any time)
3. If the WG adopts draft-clausen-rfc6779bis, I will then call for WGLC= on both documents, once the update to draft-ietf-manet-nhdp-optimization is= done. 

Regards,
Stan


As a reminder, both documents aims publication as an Proposed Standard R= FCs.

Procedurally, I would like to enter a rapid succession of:

1) Submission of draft-clausen-manet-rfc6779bis-00 as draft-ietf-ma= net-rfc6779bis-00

2) Submission of draft-ietf-manet-nhdp-optimization-01, with the on= ly difference to -00
being s= ection 6 removed, and replaced by a reference to 
draft-c= lausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779bis-00

3) A WGLC being issued for both these documents, concurrently.

WG Chairs, would you kindly let us know your thoughts on this matter, a= t your earliest convenience, so that we may aim at a WGLC soon, such that th= e WG will have visible progress to report at the RTG Area Open Meeting?

Respectfully,

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

= --Apple-Mail-A1E79468-A900-47BB-BCF0-D071726BC8A6-- From nobody Tue Jul 29 08:18:22 2014 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 9D7391B2970 for ; Tue, 29 Jul 2014 08:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 rAKjQkYCIiI6 for ; Tue, 29 Jul 2014 08:18:03 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C8E1B290E for ; Tue, 29 Jul 2014 08:16:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,757,1400022000"; d="scan'208,217";a="461947536" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 29 Jul 2014 16:16:41 +0100 X-IronPort-AV: E=Sophos; i="5.01,757,1400022000"; d="scan'208,217"; a="59418150" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 29 Jul 2014 16:16:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 29 Jul 2014 16:16:51 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , manet , "" , manet-ads Thread-Topic: Ready for WGLC: Advancing draft-ietf-manet-ibs Thread-Index: AQHPqmaMr2jXtWmnY0aFPOP7noXFq5u3IjPg Date: Tue, 29 Jul 2014 15:16:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B881GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZQFOR4kXLuDGuziZ88C9en1e8_g Cc: Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 29 Jul 2014 15:18:19 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B881GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Some additional comments inline. I plan to put out a new version shortly, b= ut technically all will be unchanged. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Clausen [mailto:thomas@thomasclausen.org] Sent: 28 July 2014 14:19 To: manet; ; manet-ads Cc: Christopher Dearlove Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Dear WG Chairs, Dear Chris, all, As the author indicated by email recently, he believes that draft-ietf-mane= t-olsrv2-management-snapshot is ready for WGLC. As a reminder, this document aims for publication as a Proposed Standard. I have, therefore, reviewed the document carefully. In my opinion, the auth= or is right - in my opinion this document is ready for WGLC. Moreover, I believe that it is a highly important document for the WG to pr= oduce, as it fills a real need, and does so by relying on already-published= crypto RFCs, rather than by coming up with something esoteric. I have two issues, and handful nits, that I expect the author will consider= along with any other WGLC comments they may receive. Of course, if a new v= ersion is spun before WGLC is requested, then I'll gladly review that, also= . Point being: let's get a call started on this document, none of my nits a= nd issues are of the sort that should be blocking. One of the issues is "need a non-jetlagged ADs advice to be sure we do the = right thing", the other is - I think - a minor mix-up with a trivial editor= ial resolution and zero technical impact on this specification. Either way, for information, I include all issues and nits that I've found = in the below. Issues: o In my opinion, "Updates 7182" is inappropriate. What= this document does is: (i) only things permissible by = RFC7182, and (ii) makes registration from IAN= A registries set up by RFC7182 (noting, of course, that RF= C7181 doesn't "Updates 5444" when making registrations = for TC messages from the repositories set up by RFC5444 as a cas= e of precedent) Consequently, I believe that the abstract, introduc= tion, and document header, needs updates to reflect that this is not a= n update. Caveat Lector: I have bounced this around with the = author, and I think that the conclusion i= s that we need just a friendly ADs opinion - my understand= ing is that the author "wants this out, but wants = it done right, also", something to which I can but adhere. I believe that we should WG= LC the document. If the AD finds the time to address t= his issue during WGLC, great - otherwise, we can reflect t= his in the "Document Writeup" that the AD will consider w= ith the publication request - as this (imo) is procedural/ed= itorial, and certainly not technical. CMD: On the grounds that the biggest wasted effort is taking out, and then = maybe putting back in, I'm going to leave as-is until our AD comments. But = I'd have done the same if it were the other way round, I'm happy whichever = way this is settled. o Introduction, 4th paragraph: Isn't it RFC7183 which does shared-secret-key ICVs?= I just did a quick grep through of "shared" in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that ca= se. And "secret" is not mentioned anywhere in 7182 CMD: I made an earlier post on this. I think that some improvements in word= ing in the Introduction are indicated. Nits: o Introduction, 1st paragraph: OLD: This specification extends the TLV defi= nitions therein by defining two new cryptograph= ic function code points that allow the use of an identity-based sign= ature (IBS) as an ICV. NEW: This specification defines two new cryp= tographic function code points from within the registries = set up by [RFC7182], that allow the use of an identity-based= signature (IBS) as an ICV. CMD: I want to keep some of what's lost by that edit, so will propose a thi= rd wording. o Introduction, 2nd paragraph, 1st line: I took a double-take when I saw the parenthesis "(protocol participant)" - that seems a little odd,= and I am on a crusade against redundant and hard-to-parse terminology ;) I think that what is meant is "router, which is run= ning a routing protocol which is based on RFC5444", so could the d= ocument not say that? In any event, I do not see "protocol participant" d= efined or anywhere else, and so it seems unfortunate to *not* be explicit he= re. CMD: Simply removing the parenthesis removes the intended point, which was = to say that the description assumes that the entities involved are routers - which isn't ac= tually the only possibility using 5444. I'll propose something that borrows from the above to improve i= t. o Introduction, 3rd paragraph: OLD: Two options for the choice of identity = are supported (the two code points allocated). NEW: Two options for the choice of identity = are supported (as reflected by the two code points allocated). CMD: Good. o Introduction, 7th paragraph: Caveating that using this introduces the danger tha= t "if you catch the trusted authority, then you're screwed" is awesome.= I see that this is repeated and reworded in the Security Consi= derations section, and I approve. Now, my question is then, if this should not be sta= ted in the Applicability statement, also? Something to the effect of that th= is applies to networks where all routers can (at some point) be in contact= with the TA (to be keyed), but that this can be off-line - and probabl= y should be off-line since the TA really, really should be protected. It might be argued that the forward-reference to Se= ction 6 captures this - I still think, that a few choice words in th= e applicability statement would help greatly. CMD: I prefer to stick with the forward reference, as I think by the time y= ou've said enough, you've duplicated half of Section 6. But adding some wor= ds to say particularly regarding the role of the TA/KMS makes sense. o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to= quantify the computational load? I asked a crypto-wonk-colleague= , who said something to the effect of "the document is perfect= ly right, on this point, but I do not have a paper just off the top o= f my head with interesting data to offer". For that reason alone, = it'd be interesting if you did ;) CMD: See previous comments. Trying Google Scholar with ECCSI elliptic curve= gets a very small number of hits, none useful here. o Throw-away comment, I appreciate particularly the la= st paragraph of the introduction. o Section 4.1, first bullet OLD: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined there) uses the hash function w= ithin the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. NEW: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined in [RFC7182]) uses the hash fun= ction within the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. CMD: I could live with either, but will make the change. o While we are at it, it it crystal-clear to everybody= that "Section 4.2" in the bullet above is to *this* document, as not RFC7= 182? CMD: I'm going to assume it is. I would always write Section X.Y of [Z] (or= similar) if making an external reference. o Section 4.3, 2nd bullet There's a LOT of information embedded in this bulle= t, and reading it suggests that it, readability-wise, might benefit f= rom embedding a: ... ... CMD: I'm including to be slightly less radical (and I'm not a fan on hangin= g text). But I will create another level. o IANA Considerations: Given recent experiences in this WG and with reques= ting IANA registrations, may I suggest that this be modified = to say, more explicitly: 1) IANA is requested to reserve= ECCSI with description ___ and reference "This Specifi= cation" 2) IANA is requested to reserve= ECCSI-ADDR.... (similar) 3) The "Cryptographic Functions= Registry", defined in [RFC7182], with these regis= trations made, will look like Table 1, which replace= s Table 11 of [RFC7182] 4) Obviously, include in Table = 1 the registrations from RFC7182. 5) That this document does not = modify the expert review guidelines as set fo= rth in RFC7182 for future allocations. CMD: I think this comes under the heading of hand-holding IANA more than I = would feel ought to be necessary. Except sometimes it has been. But this is= a straightforward case, so while I agree that making it more explicit that= this is a request for two new code points, I'm not going to repeat the ful= l table from 7182 unless IANA really show they need hand-holding. Our previ= ous cases where we had to repeat a whole table were a bit messier. But givi= ng the exact name for the table as on IANA's website is advisable. That's all. Thanks for writing this document, Chris. Respectfully, Thomas ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B881GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Some additional comments = inline. I plan to put out a new version shortly, but technically all will b= e unchanged.

 <= /p>

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

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

 <= /p>

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 28 July 2014 14:19
To: manet; <manet-chairs@tools.ietf.org>; manet-ads
Cc: Christopher Dearlove
Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs

 

 

*** WARNING ***=

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

Dear WG Chairs, 

Dear Chris, all,

 

As the author indicated by email recently, he believ= es that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 

 

As a reminder, this document aims for publication as= a Proposed Standard.

 

I have, therefore, reviewed the document carefully. = In my opinion, the author is right — in my opinion this document is ready for WGLC.

 

Moreover, I believe that it is a highly important do= cument for the WG to produce, as it fills a real need, and does so by relyi= ng on already-published crypto RFCs, rather than by coming up with somethin= g esoteric.

 

I have two issues, and handful nits, that I expect t= he author will consider along with any other WGLC comments they may receive= . Of course, if a new version is spun before WGLC is requested, then I̵= 7;ll gladly review that, also. Point being: let’s get a call started on this document, none of my nits and= issues are of the sort that should be blocking.

 

One of the issues is “need a non-jetlagged ADs= advice to be sure we do the right thing”, the other is — I thi= nk — a minor mix-up with a trivial editorial resolution and zero tech= nical impact on this specification.

 

Either way, for information, I include all issues an= d nits that I’ve found in the below.

 

Issues:

 

   &nb= sp;        o          In my opinion, “Updates 7182” is inappropriate. What thi= s document does is:

   &nb= sp;            =             &nb= sp;       (i)      &nb= sp;  only things permissible by RFC7182, and 

   &nb= sp;            =             &nb= sp;       (ii)      &n= bsp; makes registration from IANA registries set up by RFC7182<= /o:p>

   &nb= sp;            =             &nb= sp;            =        (noting, of course, that RFC7181 doesn’t “Updates 5444&#= 8221; 

   &nb= sp;            =             &nb= sp;             &= nbsp;      when making registrations for TC= messages from the repositories 

   &nb= sp;            =             &nb= sp;            =         set up by RFC5444 as a case of precedent)

   &nb= sp;            =         Consequently, I believe that the abstract, introduction, and document =

   &nb= sp;            =         header, needs updates to reflect that this is not an update.

   &nb= sp;            =        

   &nb= sp;            =         Caveat Lector: I have bounced this around with the author, and I =

   &nb= sp;            =             &nb= sp;            =        think that the conclusion is that we need just a friendly =

   &nb= sp;            =             &nb= sp;            =        ADs opinion — my understanding is that the author

   &nb= sp;            =             &nb= sp;            =        “wants this out, but wants it done right, also”, somethi= ng

   &nb= sp;            =             &nb= sp;            =        to which I can but adhere.

   &nb= sp;            =        

   &nb= sp;            =             &nb= sp;            =        I believe that we should WGLC the document. If the AD

   &nb= sp;            =             &nb= sp;            =        finds the time to address this issue during WGLC, great -=

   &nb= sp;            =             &nb= sp;            =        otherwise, we can reflect this in the “Document Writeup”=

   &nb= sp;            =             &nb= sp;            =        that the AD will consider with the publication request — as

   &nb= sp;            =             &nb= sp;            =        this (imo) is procedural/editorial, and certainly not technical.

 <= /p>

CMD: On the grounds that = the biggest wasted effort is taking out, and then maybe putting back in, I&= #8217;m going to leave as-is until our AD comments. But I’d have done the same if it were the other way round, I’m happy whichever wa= y this is settled.

 

   &nb= sp;        o          Introduction, 4th paragraph:

 

   &nb= sp;            =         Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quic= k

   &nb= sp;            =         grep through of “shared” in 7182, and found just a few mentions= , notably

   &nb= sp;            =         setting a side a value for key-id-length in that case. And “secr= et” is not

   &nb= sp;            =         mentioned anywhere in 7182

 

CMD: I made an earlier po= st on this. I think that some improvements in wording in the Introduction a= re indicated.

 <= /p>

 

Nits:

   &nb= sp;        o          Introduction, 1st paragraph:

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       This specification extends the TLV definitions

   &nb= sp;            =             &nb= sp;       therein by defining two new cryptographic function code points that<= o:p>

   &nb= sp;            =             &nb= sp;       allow the use of an identity-based signature (IBS) as an ICV.

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       This specification defines two new cryptographic function =

   &nb= sp;            =             &nb= sp;       code points from within the registries set up by [RFC7182], 

   &nb= sp;            =             &nb= sp;       that allow the use of an identity-based signature (IBS) as an ICV.

 

CMD: I want to keep some = of what’s lost by that edit, so will propose a third wording.

 <= /p>

   &nb= sp;        o          Introduction, 2nd paragraph, 1st line:

   &nb= sp;            =         I took a double-take when I saw the parenthesis 

   &nb= sp;            =         “(protocol participant)” — that seems a little odd, and I= am on a crusade

   &nb= sp;            =         against redundant and hard-to-parse terminology ;)

 

   &nb= sp;            =         I think that what is meant is “router, which is running a routing&nbs= p;

   &nb= sp;            =         protocol which is based on RFC5444”, so could the document not say

   &nb= sp;            =         that?

 

   &nb= sp;            =         In any event, I do not see “protocol participant” defined or an= ywhere else,

   &nb= sp;            =         and so it seems unfortunate to *not* be explicit here.

 

CMD: Simply removing the = parenthesis removes the intended point, which was to say that the

description assumes that = the entities involved are routers – which isn’t actually the on= ly possibility

using 5444. I’ll pr= opose something that borrows from the above to improve it.

 <= /p>

   &nb= sp;        o          Introduction, 3rd paragraph:

 

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (the two code

   &nb= sp;            =             &nb= sp;       points allocated).

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       Two options for the choice of identity are supported (as reflected

   &nb= sp;            =             &nb= sp;       by the two code points allocated).

 

CMD: Good.

 

   &nb= sp;        o          Introduction, 7th paragraph:

   &nb= sp;            =         Caveating that using this introduces the danger that “if you catch th= e 

   &nb= sp;            =         trusted authority, then you’re screwed” is awesome. I see that&= nbsp;

   &nb= sp;            =         this is repeated and reworded in the Security Considerations section,<= /o:p>

   &nb= sp;            =         and I approve. 

 

   &nb= sp;            =         Now, my question is then, if this should not be stated in the Applicability=  

   &nb= sp;            =         statement, also? Something to the effect of that this applies to networks

   &nb= sp;            =         where all routers can (at some point) be in contact with the TA (to be=

   &nb= sp;            =         keyed), but that this can be off-line — and probably should be off-li= ne

   &nb= sp;            =         since the TA really, really should be protected.

 

   &nb= sp;            =         It might be argued that the forward-reference to Section 6 captures

   &nb= sp;            =         this — I still think, that a few choice words in the applicability st= atement

   &nb= sp;            =         would help greatly.

 

CMD: I prefer to stick wi= th the forward reference, as I think by the time you’ve said enough, = you’ve duplicated half of Section 6. But adding some words to say particularly regarding the role of the TA/KMS makes sense.<= /span>

 <= /p>

   &nb= sp;        o          Introduction, 9th paragraph:

   &nb= sp;            =         Any [academic? otherwise] work that you can cite to quantify the =

   &nb= sp;            =         computational load? I asked a crypto-wonk-colleague, who said

   &nb= sp;            =         something to the effect of “the document is perfectly right, on this<= o:p>

   &nb= sp;            =         point, but I do not have a paper just off the top of my head with = ;

   &nb= sp;            =         interesting data to offer”. For that reason alone, it’d be inte= resting 

   &nb= sp;            =         if you did ;)

 <= /p>

CMD: See previous comment= s. Trying Google Scholar with ECCSI elliptic curve gets a very small number= of hits, none useful here.

 

   &nb= sp;        o          Throw-away comment, I appreciate particularly the last

   &nb= sp;            =         paragraph of the introduction.

 

   &nb= sp;        o          Section 4.1, first bullet

 

   &nb= sp;            =         OLD:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined there) uses the hash function withi= n the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;            =                length of N octets, as specified in Section 4.2.=

 

   &nb= sp;            =         NEW:

   &nb= sp;            =            o  The ICV is not calculated as cryptographic-function(ha= sh-

   &nb= sp;            =                function(content)) as defined in [RFC7182], but = (like the HMAC

   &nb= sp;            =                ICVs defined in [RFC7182]) uses the hash functio= n within the

   &nb= sp;            =                cryptographic function.  The option "n= one" is not permitted for

   &nb= sp;            =                hash-function, and the hash function must have a= known fixed

   &nb= sp;             = ;              length of N octets, as specified in Section 4.2.=

 <= /p>

CMD: I could live with ei= ther, but will make the change.

 

   &nb= sp;        o          While we are at it, it it crystal-clear to everybody that “Sec= tion 4.2” in

   &nb= sp;            =         the bullet above is to *this* document, as not RFC7182?

 <= /p>

CMD: I’m going to a= ssume it is. I would always write Section X.Y of [Z] (or similar) if making= an external reference.

 

   &nb= sp;        o          Section 4.3, 2nd bullet

   &nb= sp;            =         There’s a LOT of information embedded in this bullet, and reading it<= o:p>

   &nb= sp;            =         suggests that it, readability-wise, might benefit from embedding a:

   &nb= sp;            =             &nb= sp;       <list style=3D“hanging”>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Packet TLVs”>…</t>=

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Message TLVs”>…</t>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Address Block TLVs”>…</t&g= t;

   &nb= sp;            =             &nb= sp;       </list>

 

CMD: I’m including = to be slightly less radical (and I’m not a fan on hanging text). But = I will create another level.

 <= /p>

   &nb= sp;        o          IANA Considerations:

 

   &nb= sp;            =         Given recent experiences in this WG and with requesting IANA 

   &nb= sp;            =         registrations, may I suggest that this be modified to say, more<= /p>

   &nb= sp;            =         explicitly:

 

   &nb= sp;            =             &nb= sp;       1)      = ;   IANA is requested to reserve ECCSI with description __= _ 

   &nb= sp;            =             &nb= sp;            =        and reference “This Specification”

 

   &nb= sp;            =             &nb= sp;       2)      = ;   IANA is requested to reserve ECCSI-ADDR…. (simil= ar)

 

   &nb= sp;            =             &nb= sp;       3)      = ;   The “Cryptographic Functions Registry”, de= fined in 

   &nb= sp;            =             &nb= sp;            =        [RFC7182], with these registrations made, will look

   &nb= sp;            =             &nb= sp;            =        like Table 1, which replaces Table 11 of [RFC7182]

 

   &nb= sp;            =             &nb= sp;       4)      = ;   Obviously, include in Table 1 the registrations from

   &nb= sp;            =             &nb= sp;            =        RFC7182.

 

   &nb= sp;            =             &nb= sp;       5)      = ;   That this document does not modify the expert

   &nb= sp;            =             &nb= sp;            =        review guidelines as set forth in RFC7182 for

   &nb= sp;            =             &nb= sp;            =        future allocations.

 

CMD: I think this comes u= nder the heading of hand-holding IANA more than I would feel ought to be ne= cessary. Except sometimes it has been. But this is a straightforward case, so while I agree that making it more explicit that this is a request= for two new code points, I’m not going to repeat the full table from= 7182 unless IANA really show they need hand-holding. Our previous cases wh= ere we had to repeat a whole table were a bit messier. But giving the exact name for the table as on IANA’s = website is advisable.

 <= /p>

That’s all. Thanks for writing this document, = Chris. 

 

 

Respectfully,

 

Thomas

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B881GLKXM0002VGREEN_-- From nobody Tue Jul 29 08:23:50 2014 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 016A11B2938 for ; Tue, 29 Jul 2014 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 I29ZV8XA4SpT for ; Tue, 29 Jul 2014 08:23:40 -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 C7D7C1B2956 for ; Tue, 29 Jul 2014 08:21:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,757,1400022000"; d="scan'208,217";a="390292139" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 Jul 2014 16:21:25 +0100 X-IronPort-AV: E=Sophos; i="5.01,757,1400022000"; d="scan'208,217"; a="66510299" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 29 Jul 2014 16:21:35 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 29 Jul 2014 16:21:35 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Thomas Clausen Thread-Topic: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis Thread-Index: AQHPqmiVJqdro54RjEusm27ZJQYvj5u3D0OAgAAcWVA= Date: Tue, 29 Jul 2014 15:21:35 +0000 Message-ID: References: <7918A059-8300-4B24-865E-3C2F7ABB1348@cisco.com> In-Reply-To: <7918A059-8300-4B24-865E-3C2F7ABB1348@cisco.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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B89BGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1f_FkNel_g_BuM5QIpG1LaZYwfk Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis 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, 29 Jul 2014 15:23:48 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B89BGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Much as I want things to go as quickly as possible, I have to agree with St= an that 6779bis should be accepted as a WG document first. WGLC on both (we= 'll have the updated drafts ready) directly thereafter will be good. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 29 July 2014 15:36 To: Thomas Clausen Cc: manet; ; manet-ads; Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimi= zation & draft-clausen-manet-rfc6779bis *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Thomas, On Jul 28, 2014, at 9:33 AM, Thomas Clausen > wrote: Dear WG Chairs, co-authors, all, As indicated in Toronto, the authors believe that the remaining issue with = draft-ietf-manet-nhdp-optimization was how to properly do the updates to th= e MIB module of RFC6779. We believe that Toronto confirmed that the way forward was to do an RFC6779= bis document, which reflects the MIB considerations section (Section 6) fro= m draft-ietf-manet-nhdp-optimization, which the WG already adopted, into RF= C6779. As Ulrich indicated in his recent mail, this is what draft-clausen-manet-rf= c6779bis does - nothing more, nothing less. I believe that with this issue resolved, draft-ietf-manet-nhdp-optimization= & draft-clausen-manet-rfc6779bis essentially are ready for WGLC. I don't agree with you here, mainly because: 1. draft-clausen-manet-rfc6779bis-00 technically isn't even a WG document, 2. You state the documents are ready for WGLC, then outline a proposal for = updating them. I'd rather see any known edits go into WGLC, instead of eith= er running concurrently with WGLC. Here's what I propose going forward: 1. I'll issue an email calling for WG adoption of draft-clausen-manet-rfc67= 79bis 2. If the WG adopts draft-clausen-rfc6779bis, then you can update draft-iet= f-manet-nhdp-optimization (or, if you feel certain about WG adoption, you a= re free to update nhdp-optimization at any time) 3. If the WG adopts draft-clausen-rfc6779bis, I will then call for WGLC on = both documents, once the update to draft-ietf-manet-nhdp-optimization is do= ne. Regards, Stan As a reminder, both documents aims publication as an Proposed Standard RFCs. Procedurally, I would like to enter a rapid succession of: 1) Submission of draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779= bis-00 2) Submission of draft-ietf-manet-nhdp-optimization-01, with the only differen= ce to -00 being section 6 removed, and replaced by a reference to draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779bis-00 3) A WGLC being issued for both these documents, concurrently. WG Chairs, would you kindly let us know your thoughts on this matter, at yo= ur earliest convenience, so that we may aim at a WGLC soon, such that the W= G will have visible progress to report at the RTG Area Open Meeting? Respectfully, Thomas _______________________________________________ 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B89BGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Much as I want things to = go as quickly as possible, I have to agree with Stan that 6779bis should be= accepted as a WG document first. WGLC on both (we’ll have the updated drafts ready) directly thereafter will be good.

 <= /p>

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

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

 <= /p>

From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 29 July 2014 15:36
To: Thomas Clausen
Cc: manet; <manet-chairs@tools.ietf.org>; manet-ads; Christoph= er Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp= -optimization & draft-clausen-manet-rfc6779bis

 

 

*** WARNING ***=

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

Thomas, 

 

On Jul 28, 2014, at 9:33 AM, Thomas Clausen <thomas@thomasclausen.org> wr= ote:



Dear WG Chairs, co-authors, all,

 

As indicated in Toronto, the authors believe that th= e remaining issue with draft-ietf-manet-nhdp-optimization was how to proper= ly do the updates to the MIB module of RFC6779.

 

We believe that Toronto confirmed that the way forwa= rd was to do an RFC6779bis document, which reflects the MIB considerations = section (Section 6) from draft-ietf-manet-nhdp-optimization, which the= WG already adopted, into RFC6779.

 

As Ulrich indicated in his recent mail, this is what=  draft-clausen-manet-rfc6779bis does — nothing more, nothing les= s.

 

I believe that with this issue resolved, draft-ietf-= manet-nhdp-optimization & draft-clausen-manet-rfc6779bis essentially are ready for WGLC. 

 

I don't agree with you here, mainly because:

1. draft-clausen-manet-rfc6779bis-00 technically isn= 't even a WG document,

2. You state the documents are ready for WGLC, then = outline a proposal for updating them. I'd rather see any known edits go int= o WGLC, instead of either running concurrently with WGLC. <= /p>

 

Here's what I propose going forward: 

1. I'll issue an email calling for WG adoption of dr= aft-clausen-manet-rfc6779bis

2. If the WG adopts draft-clausen-rfc6779bis, then y= ou can update draft-ietf-manet-nhdp-optimization (or, if you feel certain a= bout WG adoption, you are free to update nhdp-optimization at any time)

3. If the WG adopts draft-clausen-rfc6779bis, I will= then call for WGLC on both documents, once the update to draft-ietf-manet-= nhdp-optimization is done. 

 

Regards,

Stan



 

As a reminder, both documents aims publication as an= Proposed Standard RFCs.

 

Procedurally, I would like to enter a rapid successi= on of:

 

1)<= /p>

Submission of draft-clausen-manet-rfc6779bis-00 as&n= bsp;draft-ietf-manet-rfc6779bis-00

 

2)<= /p>

Submission of draft-ietf-manet-nhdp-optimizatio= n-01, with the only difference to -00

being section 6 removed, and replaced by a reference= to 

draft-clausen-manet-rfc6779bis-00 as draft-ietf= -manet-rfc6779bis-00

 

3)<= /p>

A WGLC being issued for both these documents, concur= rently.

 

WG Chairs, would you kindly let us know your thought= s on this matter, at your earliest convenience, so that we may aim at a WGL= C soon, such that the WG will have visible progress to report at the RTG Ar= ea Open Meeting?

 

Respectfully,

 

Thomas

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/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.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1B89BGLKXM0002VGREEN_-- From nobody Tue Jul 29 08:45:05 2014 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 B18841B294F for ; Tue, 29 Jul 2014 08:45:03 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xBw9DyvKcP2d for ; Tue, 29 Jul 2014 08:45:01 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EAD1B29AF for ; Tue, 29 Jul 2014 08:42:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id D7552D548F9; Tue, 29 Jul 2014 08:42:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [10.17.29.15] (unknown [37.163.136.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 29432D402DB; Tue, 29 Jul 2014 08:42:19 -0700 (PDT) References: <7918A059-8300-4B24-865E-3C2F7ABB1348@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-0E3AD5EF-91C4-484B-A2F2-32125DE9706E Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12A4331d) From: Thomas Heide Clausen Date: Tue, 29 Jul 2014 17:36:13 +0200 To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/g15rPdpKs7Y08IKJfWkcjuWPb2M Cc: "" , manet , manet-ads , Christopher Dearlove , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optimization & draft-clausen-manet-rfc6779bis 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, 29 Jul 2014 15:45:03 -0000 --Apple-Mail-0E3AD5EF-91C4-484B-A2F2-32125DE9706E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As long as we get the ball rolling, I am more than happy with what Stan prop= oses, and what he already has set in motion. Thank you, Stan.=20 --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 > On 29 juil. 2014, at 17:21, Dearlove, Christopher (UK) wrote: >=20 > Much as I want things to go as quickly as possible, I have to agree with S= tan that 6779bis should be accepted as a WG document first. WGLC on both (we= =E2=80=99ll have the updated drafts ready) directly thereafter will be good.= > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: 29 July 2014 15:36 > To: Thomas Clausen > Cc: manet; ; manet-ads; Christopher Dearlove > Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-optim= ization & draft-clausen-manet-rfc6779bis > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Thomas,=20 > =20 > On Jul 28, 2014, at 9:33 AM, Thomas Clausen wro= te: >=20 >=20 > Dear WG Chairs, co-authors, all, > =20 > As indicated in Toronto, the authors believe that the remaining issue with= draft-ietf-manet-nhdp-optimization was how to properly do the updates to th= e MIB module of RFC6779. > =20 > We believe that Toronto confirmed that the way forward was to do an RFC677= 9bis document, which reflects the MIB considerations section (Section 6) fro= m draft-ietf-manet-nhdp-optimization, which the WG already adopted, into RFC= 6779. > =20 > As Ulrich indicated in his recent mail, this is what draft-clausen-manet-r= fc6779bis does =E2=80=94 nothing more, nothing less. > =20 > I believe that with this issue resolved, draft-ietf-manet-nhdp-optimizatio= n & draft-clausen-manet-rfc6779bis essentially are ready for WGLC.=20 > =20 > I don't agree with you here, mainly because: > 1. draft-clausen-manet-rfc6779bis-00 technically isn't even a WG document,= > 2. You state the documents are ready for WGLC, then outline a proposal for= updating them. I'd rather see any known edits go into WGLC, instead of eith= er running concurrently with WGLC.=20 > =20 > Here's what I propose going forward:=20 > 1. I'll issue an email calling for WG adoption of draft-clausen-manet-rfc6= 779bis > 2. If the WG adopts draft-clausen-rfc6779bis, then you can update draft-ie= tf-manet-nhdp-optimization (or, if you feel certain about WG adoption, you a= re free to update nhdp-optimization at any time) > 3. If the WG adopts draft-clausen-rfc6779bis, I will then call for WGLC on= both documents, once the update to draft-ietf-manet-nhdp-optimization is do= ne.=20 > =20 > Regards, > Stan >=20 >=20 > =20 > As a reminder, both documents aims publication as an Proposed Standard RFC= s. > =20 > Procedurally, I would like to enter a rapid succession of: > =20 > 1) > Submission of draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc677= 9bis-00 > =20 > 2) > Submission of draft-ietf-manet-nhdp-optimization-01, with the only differe= nce to -00 > being section 6 removed, and replaced by a reference to=20 > draft-clausen-manet-rfc6779bis-00 as draft-ietf-manet-rfc6779bis-00 > =20 > 3) > A WGLC being issued for both these documents, concurrently. > =20 > WG Chairs, would you kindly let us know your thoughts on this matter, at y= our earliest convenience, so that we may aim at a WGLC soon, such that the W= G will have visible progress to report at the RTG Area Open Meeting? > =20 > Respectfully, > =20 > Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-0E3AD5EF-91C4-484B-A2F2-32125DE9706E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As long as we get the ball rolling, I a= m more than happy with what Stan proposes, and what he already has set in mo= tion. Thank you, Stan. 

-- 
Thomas Heide Cla= usen

"Today's scientists have substituted m= athematics for 
  experiments, and they wander off t= hrough equation 
  after equation, and eventually &= nbsp;build a structure 
  which has no relation to r= eality."
 - Nikola Tesla, 
    = Modern Mechanics and Inventions, July, 1934

On 29 juil. 2= 014, at 17:21, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

=

Much as I want things to go= as quickly as possible, I have to agree with Stan that 6779bis should be ac= cepted as a WG document first. WGLC on both (we=E2=80=99ll have the updated drafts ready) directly thereafter will be good.

 

= --

= Christopher Dearlove

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

=

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

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

 

From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
Sent: 29 July 2014 15:36
To: Thomas Clausen
Cc: manet; <manet-c= hairs@tools.ietf.org>; manet-ads; Christopher Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-nhdp-= optimization & draft-clausen-manet-rfc6779bis

 

 

*** WARNING ***

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

Thomas, 

 

On Jul 28, 2014, at 9:33 AM, Thomas Clausen <thomas@thomasclausen.org> wrot= e:



Dear WG Chairs, co-authors, all,

 

As indicated in Toronto, the authors believe that the= remaining issue with draft-ietf-manet-nhdp-optimization was how to properly= do the updates to the MIB module of RFC6779.

 

We believe that Toronto confirmed that the way forwar= d was to do an RFC6779bis document, which reflects the MIB considerations se= ction (Section 6) from draft-ietf-manet-nhdp-optimization, which the WG= already adopted, into RFC6779.

 

As Ulrich indicated in his recent mail, this is what&= nbsp;draft-clausen-manet-rfc6779bis does =E2=80=94 nothing more, nothing les= s.

 

I believe that with this issue resolved, draft-ietf-m= anet-nhdp-optimization & draft-clausen-manet-rfc6779bis essentially are ready for WGLC. 

 

I don't agree with you here, mainly because:

1. draft-clausen-manet-rfc6779bis-00 technically isn'= t even a WG document,

2. You state the documents are ready for WGLC, then o= utline a proposal for updating them. I'd rather see any known edits go into W= GLC, instead of either running concurrently with WGLC. 

 

Here's what I propose going forward: =

1. I'll issue an email calling for WG adoption of dra= ft-clausen-manet-rfc6779bis

2. If the WG adopts draft-clausen-rfc6779bis, then yo= u can update draft-ietf-manet-nhdp-optimization (or, if you feel certain abo= ut WG adoption, you are free to update nhdp-optimization at any time)

3. If the WG adopts draft-clausen-rfc6779bis, I will t= hen call for WGLC on both documents, once the update to draft-ietf-manet-nhd= p-optimization is done. 

 

Regards,

Stan



 

As a reminder, both documents aims publication as an P= roposed Standard RFCs.

 

Procedurally, I would like to enter a rapid successio= n of:

 

1)

Submission of draft-clausen-manet-rfc6779bis-00 as&nb= sp;draft-ietf-manet-rfc6779bis-00

 

2)

Submission of draft-ietf-manet-nhdp-optimization= -01, with the only difference to -00

being section 6 removed, and replaced by a reference t= o 

draft-clausen-manet-rfc6779bis-00 as draft-ietf-= manet-rfc6779bis-00

 

3)

A WGLC being issued for both these documents, concurr= ently.

 

WG Chairs, would you kindly let us know your thoughts= on this matter, at your earliest convenience, so that we may aim at a WGLC s= oon, such that the WG will have visible progress to report at the RTG Area O= pen Meeting?

 

Respectfully,

 

Thomas

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

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-0E3AD5EF-91C4-484B-A2F2-32125DE9706E-- From nobody Tue Jul 29 11:42:39 2014 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 886241A0452 for ; Tue, 29 Jul 2014 11:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 4TWgrw063mrp for ; Tue, 29 Jul 2014 11:42:35 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59761A02DD for ; Tue, 29 Jul 2014 11:42:34 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so6257809wib.2 for ; Tue, 29 Jul 2014 11:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=rTWKQVF/CVTTii3gwrw61gcrnliC8zK5ONJsWUuT+XI=; b=CaLjg2ELS+pmtVyArNcyaP3Om617JQu6CTmbn7Om0a7IQWi8qxBieHSlnBmBi9WTPM /Oc1UtSsfrj8CkoBo9dN2bZVto5PJWm0DR/2KdSy2daCer6z/hA/3EDl17DH4pgUICbE Sk5xNNaVUZ4s1uksp/bZ1ZXL/QATBGsFHGoC1qanBLmp/L6RcT5slOX9ZkAad92uD8hj 2lcZq0ZCtdVkEHcCfYdI2ZJfczSbGaaAQclLcPz5jusR2Ts3HsnFqgfNfl8f1SQEQz5l MKPjsn4l/+fKDBRPceIaPTz3xsOJFe7qd+690mcVjlC0wdG5U424v/WhixC4BRQFvaGu o6sg== MIME-Version: 1.0 X-Received: by 10.194.57.45 with SMTP id f13mr6013096wjq.98.1406659353265; Tue, 29 Jul 2014 11:42:33 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Tue, 29 Jul 2014 11:42:33 -0700 (PDT) In-Reply-To: <20140729182934.32230.88415.idtracker@ietfa.amsl.com> References: <20140729182934.32230.88415.idtracker@ietfa.amsl.com> Date: Tue, 29 Jul 2014 20:42:33 +0200 X-Google-Sender-Auth: cXo1DR_wPpVz61zFrXSZAAvXDZY Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=047d7ba976741253b704ff5967a2 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MvWX2rM2hEiEbWnD2j2_Cs6_hOo Subject: [manet] Fwd: New Version Notification for draft-yi-manet-olsrv2-multipath-02.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: Tue, 29 Jul 2014 18:42:37 -0000 --047d7ba976741253b704ff5967a2 Content-Type: text/plain; charset=UTF-8 Dear all, A new revision of the olsrv2-multipath has been submitted. This revision is based on the feedback in the IETF meeting, and comments from the WG (thanks a lot!). More details about the comments/discussions can be found at http://www.ietf.org/mail-archive/web/manet/current/msg16613.html http://www.ietf.org/mail-archive/web/manet/current/msg16740.html regards Jiazi ---------- Forwarded message ---------- From: Date: Tue, Jul 29, 2014 at 8:29 PM Subject: New Version Notification for draft-yi-manet-olsrv2-multipath-02.txt To: Jiazi Yi , Benoit Parrein < benoit.parrein@polytech.univ-nantes.fr>, Benoit Parrein < Benoit.Parrein@polytech.univ-nantes.fr> A new version of I-D, draft-yi-manet-olsrv2-multipath-02.txt has been successfully submitted by Jiazi Yi and posted to the IETF repository. Name: draft-yi-manet-olsrv2-multipath Revision: 02 Title: Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Document date: 2014-07-29 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-02.txt Status: https://datatracker.ietf.org/doc/draft-yi-manet-olsrv2-multipath/ Htmlized: http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-yi-manet-olsrv2-multipath-02 Abstract: This document specifies a multi-path extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7ba976741253b704ff5967a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

A new revision of the o= lsrv2-multipath has been submitted.=C2=A0
This revision is based = on the feedback in the IETF meeting, and comments from the WG (thanks a lot= !).=C2=A0

More details about the comments/discussions can be foun= d at=C2=A0



Jiazi=C2=A0

=
---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Tue, Jul 29, 2014 at 8:29 = PM
Subject: New Version Notification for draft-yi-manet-olsrv2-multipath-02.tx= t
To: Jiazi Yi <jiazi@jiaziyi.co= m>, Benoit Parrein <benoit.parrein@polytech.univ-nantes.fr>, Benoit Parrein= <Benoit.Parre= in@polytech.univ-nantes.fr>



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

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-yi-manet-olsrv2-multipath Revision: =C2=A0 =C2=A0 =C2=A0 02
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Multi-path Extension for the Optim= ized Link State Routing Protocol version 2 (OLSRv2)
Document date: =C2=A02014-07-29
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A017
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-yi-manet-olsrv2-multipath-02.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracke= r.ietf.org/doc/draft-yi-manet-olsrv2-multipath/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/= draft-yi-manet-olsrv2-multipath-02
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-yi-manet-olsrv2-multipath-02

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




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

The IETF Secretariat


--047d7ba976741253b704ff5967a2-- From nobody Tue Jul 29 11:52:51 2014 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 98AC31A02DD for ; Tue, 29 Jul 2014 11:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-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 rAEqon9qTJlT for ; Tue, 29 Jul 2014 11:52:43 -0700 (PDT) Received: from ottsvw089.gdcan.com (smtp2.gdcanada.com [209.29.4.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADEE1A0218 for ; Tue, 29 Jul 2014 11:52:42 -0700 (PDT) Received: from ottsvw100.gdcan.com ([172.16.7.212]) by ottsvw089.gdcan.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 29 Jul 2014 14:52:41 -0400 Received: from CGYSVW100.gdcan.com ([172.31.27.212]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jul 2014 14:52:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CFAB5E.433AAE56" Date: Tue, 29 Jul 2014 12:51:36 -0600 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E68075F0DF4@CGYSVW100.gdcan.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP draft 5 comments Thread-Index: Ac+rXUojKm6TNOTuRqubYFJeaQ7mPA== From: "Viberg, Neil" To: X-OriginalArrivalTime: 29 Jul 2014 18:52:36.0663 (UTC) FILETIME=[439C5C70:01CFAB5E] Disclaimer: gdcanada.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_K8PkEI7J2APuVtqL3bWL4EN0HQ Subject: [manet] DLEP draft 5 comments 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, 29 Jul 2014 18:52:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CFAB5E.433AAE56 Content-Type: text/plain;charset="us-ascii" Content-Transfer-Encoding: quoted-printable Disclaimer: gdcanada.com Folks, I've been working on an implementation of DLEP for a company demonstration. As a result of that work I have a few comments on Draft 5. These are personal views, not company views. My overwhelming impression is very positive. This protocol will work nicely for us and provides great value. Nice job. The demo DLEP uses all of the mandatory messages and recognizes but ignores the optional messages. All of the data items in sections 9.1 to 9.22 except 9.19 are implemented. Only IPv4 sessions are implemented. Section 4 and 10.4 restrictions on including/excluding metrics that were not announced in a Peer Initialization are not implemented. For the wire format I used (and modified) the RFC5444 construction/parsing code from the dlep_tools project that Cisco kindly put on SourceForge. The packets are constructed as RFC5444 packets without a sequence number, including the packet TLV block and containing zero (0) messages. This is a valid RFC5444 packet format and, with the exception of a little extra RFC5444 packet header overhead and an extra flag byte for each TLV, matches the Draft 5 format quite closely. The Signal TLV is implemented as an actual TLV. Editorial comments are as follows: 1. Section 2 in the last paragraph has the phrase "running over the TCP transport, utilizing a well-known TCP Port number." The use of the Peer Offer message negates the need for a "well-known TCP Port number." The only well-known port number needs to be the one used for multicast discovery messages. 2. Section 9 does not list the Identification TLV 3. Section 9 does not list the MAC Address TLV 4. Section 9.18 and 10.4 indicate that the Heartbeat Interval is mandatory for the Peer Initialization message but Section 7 does not. 5. Section 9.18 indicates that the receipt of any DLEP message within two Heartbeat Intervals prevents a timeout but the description of the value (below the figure) indicates that the Interval is the time between heartbeat messages. Maybe "Interval, in seconds, since the last transmitted DLEP message until a heartbeat message is transmitted" would be more accurate. Because the interval is also part of the receive timeout, a phrase about timing out if a DLEP message from the peer is not received within 2 x Interval seconds is appropriate. 6. The Neighbor down ACK timer is mentioned in Section 9 but nowhere else. 7. The Link Characteristics ACK Timer is mentioned in the table of contents, Section 9, Section 9.19 and Section 12.4 but not in the Peer Initialization Message description in Section 10.4. 8. Section 9.15 indicates that the Relative Link Quality (Receive) is a MANDATORY data item and then starts the second sentence with "If supported". 9. Section 9.17 doesn't specify the Status TLV as MANDATORY for Peer Initialization ACK. 10. The Signal "TLV" is not consistent with a standard TLV. Section 8 has the figure labeled "Signal TLV Type," a description that starts "Signal - One of the DLEP Message TLV type values" and a 16-bit length. Section 10 refers to "DLEP Signal Type value," followed by a one byte "DLEP Message length" and a Section 10.1 title of "Signal TLV Values." Neither example has a Type field and the length field is variable length. Maybe the message format could be 2 bytes in network byte order giving the message length followed by a standard TLV for the Signal (i.e., a Type field for the Signal TLV, length of 1 byte and then the Signal value). 11. Section 10 references section 11.1 which does not exist. 12. Section 10.2 references the packet format described in section 11 but section 11 is security. 13. Section 10.2 indicates that there are no data item TLVs associated with the Peer Discovery message but Section 7 and 9.1 indicate that the DLEP Version data item is mandatory. 14. Section 10.3 indicates that Heartbeat Interval is a mandatory data item for a Peer Offer message but Section 7 and 9.18 do not. 15. Section 12.1 indicates 15 signals but Section 12.3 lists 16. 16. Section 12.1 indicates 21 data items but there is at least 22 and possibly more depending on whether Signal, Neighbor down ACK timer and/or Link Characteristics ACK timer are valid data items. Thoughts on the protocol: 1. Section 10.2 indicates that retry heuristics are optional. Since the startup of a router DLEP process and modem DLEP processes are independent it would seem that a retry is not an option but a requirement. Furthermore, the retry should increase in length to reduce processing load following startup. A truncated binary exponential backoff, or something similar, could be suggested. I chose a truncated Fibonacci sequence. 2. If the "server" behaviour was moved from the router to the modem then one session setup step can be removed. For example, the modem multicasts a discovery message that includes the identification, version, IP address(es), port and a heartbeat interval for the modem. The router responds with a TCP connect and the modem sends a Peer Initialization. 3. The timeout for the Peer Initialization message is not clearly stated. If the router sends the heartbeat in the Peer Offer message then it would be appropriate to use 2*that value for a timeout since the modem's choice is not yet available. The timeout for the Peer Initialization ACK should be 2*the modem's timeout choice. 4. The Termination message seems to be redundant when a timeout followed by a TCP close() terminates the connection. 5. The ACK messages for mandatory signals do not seem worthwhile, especially with a reliable transport protocol being used. The Peer Initialization ACK and Termination ACK are not a problem because they must be immediately acknowledged before continuing but all an ACK really does is postpone a heartbeat message. All of the rest of the ACK messages would have to be correlated with the message that they are ACKing to have a purpose. There is no easy way to do the correlation without sequence numbers **unless** it is assumed that all messages that **can** be acknowledged are acknowledged. In that case a stop and wait mechanism works but, again, doesn't seem to provide any value except postponing heartbeats. If optional ACK messages are retained then it would seem to make sense to require them to never be used or always be used. 6. Peer Update and Link Characteristics Requests originating from the router are anomalies to the normal message flow. By and large the DLEP protocol is a modem to router information flow. These two particular messages go against that. Since they are optional it is not a big deal but they feel more appropriate to a management protocol. 7. If RFC5444 construction/parsing code is widely available then simply specifying DLEP messages as RFC5444 packets with a packet level TLV block and zero RFC5444 messages may be less work and more attractive to implementers. 8. It is not clear that the time scale of DLEP messages will match the time scale needed for the use of the credit-windowing scheme. Conceptually the credit window approach seems to be a better match for packet forwarding time scales rather than the DLEP time scales, especially with the use of TCP moving DLEP firmly up to the application layer. 9. The draft does not clearly state the meaning of a MAC address and it appears from traffic on the mailing list that many people assume an Ethernet 48-bit MAC Address. Our understanding is that the MAC address space is the modem's choice though a router clearly must be able to discover its own MAC address. A further constraint is that MAC addresses must be unique for the modem's RF domain that is represented in a single DLEP session. One reason for the assumption of Ethernet MAC addresses may stem from an absence of discussion about how to actually get appropriately addressed packets to the modem. Everybody understands Ethernet frames with MAC addresses but that may not be appropriate in all cases and commenting that the traffic interface to the modem is modem specific may clarify the situation. 10. We assume that a system management interface to the modem is required even though it is not mentioned in the specification. It may reduce pressure to add "management" capabilities like "link characteristic request" if it was mentioned that a system management interface is assumed. 11. If a system management interface is assumed then one thought to help out discovery would be to add some data items to the discovery message like management IP address and port. A protocol indication may also be useful. Hope these comments are useful. Cheers, Neil Viberg The information contained in this e-mail message is PRIVATE. It may contain = confidential information and may be legally privileged. It is intended for t= he exclusive use of the addressee(s). If you are not the intended recipient,= you are hereby notified that any dissemination, distribution or reproductio= n of this communication is strictly prohibited. If the intended recipient(s)= cannot be reached or if a transmission problem has occurred, please notify = the sender immediately by return e-mail and destroy all copies of this messa= ge. =0AThank you. ------_=_NextPart_001_01CFAB5E.433AAE56 Content-Type: text/html;charset="us-ascii" Content-Transfer-Encoding: quoted-printable Disclaimer: gdcanada.com

Folks,

 

I’ve been wor= king on an implementation of DLEP for a company demonstration. As a result o= f that work I have a few comments on Draft 5. These are personal views, not = company views.

 

My overwhelming impression is very positive. This protocol w= ill work nicely for us and provides great value. Nice job.

 

The demo DLEP us= es all of the mandatory messages and recognizes but ignores the optional mes= sages. All of the data items in sections 9.1 to 9.22 except 9.19 are impleme= nted. Only IPv4 sessions are implemented. Section 4 and 10.4 restrictions on= including/excluding metrics that were not announced in a Peer Initializatio= n are not implemented.

 <= /p>

For the wire format I used (and modified) the RFC544= 4 construction/parsing code from the dlep_tools project that Cisco kindly pu= t on SourceForge. The packets are constructed as RFC5444 packets without a s= equence number, including the packet TLV block and containing zero (0) messa= ges. This is a valid RFC5444 packet format and, with the exception of a litt= le extra RFC5444 packet header overhead and an extra flag byte for each TLV,= matches the Draft 5 format quite closely. The Signal TLV is implemented as = an actual TLV.

 

Editorial comments are as follows:

 

1. Section 2 in the last= paragraph has the phrase “running over the TCP transport, utilizing a= well-known TCP Port number.” The use of the Peer Offer message negate= s the need for a “well-known TCP Port number.”  The only we= ll-known port number needs to be the one used for multicast discovery messag= es.

 

2. Section 9 does not list the Identification TLV

 

3. Section 9 does no= t list the MAC Address TLV        &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;      

<= o:p> 

4. Section 9.18 and 10.4 indicate t= hat the Heartbeat Interval is mandatory for the Peer Initialization message = but Section 7 does not.

 =

5. Section 9.18 indicates that the receipt of any D= LEP message within two Heartbeat Intervals prevents a timeout but the descri= ption of the value (below the figure) indicates that the Interval is the tim= e between heartbeat messages. Maybe “Interval, in seconds, since the l= ast transmitted DLEP message until a heartbeat message is transmitted”= would be more accurate. Because the interval is also part of the receive ti= meout, a phrase about timing out if a DLEP message from the peer is not rece= ived within 2 x Interval seconds is appropriate.

 

6. The Neighbor down ACK t= imer is mentioned in Section 9 but nowhere else.

 

7. The Link Characteristic= s ACK Timer is mentioned in the table of contents, Section 9, Section 9.19 a= nd Section 12.4 but not in the Peer Initialization Message description in Se= ction 10.4.

 

8. Section 9.15 indicates that the Relative Link Quality (Recei= ve) is a MANDATORY data item and then starts the second sentence with “= ;If supported”.

 <= /p>

9. Section 9.17 doesn’t specify the Status TLV= as MANDATORY for Peer Initialization ACK.

 

10. The Signal “TLV”= is not consistent with a standard TLV. Section 8 has the figure labeled = 220;Signal TLV Type,” a description that starts “Signal – = One of the DLEP Message TLV type values” and a 16-bit length. Section = 10 refers to “DLEP Signal Type value,” followed by a one byte &#= 8220;DLEP Message length” and a Section 10.1 title of “Signal TL= V Values.” Neither example has a Type field and the length field is va= riable length. Maybe the message format could be 2 bytes in network byte ord= er giving the message length followed by a standard TLV for the Signal (i.e.= , a Type field for the Signal TLV, length of 1 byte and then the Signal valu= e).

 

11. Section 10 references section 11.1 which does not exist.

 

12. Sect= ion 10.2 references the packet format described in section 11 but section 11= is security.

 

13. Section 10.2 indicates that there are no data item TLVs a= ssociated with the Peer Discovery message but Section 7 and 9.1 indicate tha= t the DLEP Version data item is mandatory.

 

14. Section 10.3 indicates that = Heartbeat Interval is a mandatory data item for a Peer Offer message but Sec= tion 7 and 9.18 do not.

 =

15. Section 12.1 indicates 15 signals but Section 1= 2.3 lists 16.

 

16. Section 12.1 indicates 21 data items but there is at leas= t 22 and possibly more depending on whether Signal, Neighbor down ACK timer = and/or Link Characteristics ACK timer are valid data items.

 

Thoughts on the= protocol:

 

1. Section 10.2 indicates that retry heuristics are optional. Sinc= e the startup of a router DLEP process and modem DLEP processes are independ= ent it would seem that a retry is not an option but a requirement. Furthermo= re, the retry should increase in length to reduce processing load following = startup. A truncated binary exponential backoff, or something similar, could= be suggested. I chose a truncated Fibonacci sequence.

 

2. If the “ser= ver” behaviour was moved from the router to the modem then one session= setup step can be removed. For example, the modem multicasts a discovery me= ssage that includes the identification, version, IP address(es), port and a = heartbeat interval for the modem. The router responds with a TCP connect and= the modem sends a Peer Initialization.

<= o:p> 

3. The timeout for the Peer Initial= ization message is not clearly stated. If the router sends the heartbeat in = the Peer Offer message then it would be appropriate to use 2*that value for = a timeout since the modem’s choice is not yet available. The timeout f= or the Peer Initialization ACK should be 2*the modem’s timeout choice.=

 

4. The Termination message seems to be redundant when a timeout followed b= y a TCP close() terminates the connection.

 

5. The ACK messages for mandator= y signals do not seem worthwhile, especially with a reliable transport proto= col being used. The Peer Initialization ACK and Termination ACK are not a pr= oblem because they must be immediately acknowledged before continuing but al= l an ACK really does is postpone a heartbeat message. All of the rest of the= ACK messages would have to be correlated with the message that they are ACK= ing to have a purpose. There is no easy way to do the correlation without se= quence numbers **unless** it is assumed that all messages that **can** be ac= knowledged are acknowledged. In that case a stop and wait mechanism works bu= t, again, doesn’t seem to provide any value except postponing heartbea= ts. If optional ACK messages are retained then it would seem to make sense t= o require them to never be used or always be used.

 

6. Peer Update and Link = Characteristics Requests originating from the router are anomalies to the no= rmal message flow. By and large the DLEP protocol is a modem to router infor= mation flow. These two particular messages go against that. Since they are o= ptional it is not a big deal but they feel more appropriate to a management = protocol.

 

7. If RFC5444 construction/parsing code is widely available then s= imply specifying DLEP messages as RFC5444 packets with a packet level TLV bl= ock and zero RFC5444 messages may be less work and more attractive to implem= enters.

 

8. It is not clear that the time scale of DLEP messages will match = the time scale needed for the use of the credit-windowing scheme. Conceptual= ly the credit window approach seems to be a better match for packet forwardi= ng time scales rather than the DLEP time scales, especially with the use of = TCP moving DLEP firmly up to the application layer.

 

9. The draft does not cl= early state the meaning of a MAC address and it appears from traffic on the = mailing list that many people assume an Ethernet 48-bit MAC Address. Our und= erstanding is that the MAC address space is the modem’s choice though = a router clearly must be able to discover its own MAC address. A further con= straint is that MAC addresses must be unique for the modem’s RF domain= that is represented in a single DLEP session. One reason for the assumption= of Ethernet MAC addresses may stem from an absence of discussion about how = to actually get appropriately addressed packets to the modem. Everybody unde= rstands Ethernet frames with MAC addresses but that may not be appropriate i= n all cases and commenting that the traffic interface to the modem is modem = specific may clarify the situation.

=  

10.  We assume that a system manag= ement interface to the modem is required even though it is not mentioned in = the specification. It may reduce pressure to add “management” ca= pabilities like “link characteristic request” if it was mentione= d that a system management interface is assumed.

 

11. If a system management= interface is assumed then one thought to help out discovery would be to add= some data items to the discovery message like management IP address and por= t. A protocol indication may also be useful.

 

Hope these comments are useful= .

 

Cheers,

Neil Viberg

 

The information contained in this e-mail messag= e is PRIVATE. It may contain confidential information and may be legally pri= vileged. It is intended for the exclusive use of the addressee(s). If you ar= e not the intended recipient, you are hereby notified that any dissemination= , distribution or reproduction of this communication is strictly prohibited.= If the intended recipient(s) cannot be reached or if a transmission problem= has occurred, please notify the sender immediately by return e-mail and des= troy all copies of this message.

=0A

Thank you.

------_=_NextPart_001_01CFAB5E.433AAE56-- From nobody Tue Jul 29 11:57:49 2014 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 E1F3B1A08F8 for ; Tue, 29 Jul 2014 11:57:47 -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 IKanXCfxkYNg for ; Tue, 29 Jul 2014 11:57:46 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DC61A0028 for ; Tue, 29 Jul 2014 11:57:45 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so136958qgd.9 for ; Tue, 29 Jul 2014 11:57:45 -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=gxiRk2UzOx+2fjk2ctzKBQpb2OikGeS/PGm16rdoz6s=; b=T6T1UImVjva4GnT5Jx4J6zBq/THO8eQUuh/iiYqWVYTUb3+AHX010OHzLkqAys7s2z 1PWZYsHSUVsT0+5X44AMYNadjtTajzWcTIkEwAoO5MhAzbakrNOQtdJycqp+289u4Rxf cGZksxBiSYY1JCigxKqAQxi220iU2Bh9JNBSPg3iGp8bwQlvlEzAnJHTwx/ZbInPtYJu OaIwO5yKVjEgwCQ8t40BSGpF7ERMo1qrqQiCs2QGrRM8bWIndacYZB3bV+JOvQg+1Zq0 0zyDPetOEIAS/WV2GYlLcLatDww7jkz4MEi0WjqiJAmfV537lFJClvvgJlnmzg+E8wZp XObQ== MIME-Version: 1.0 X-Received: by 10.224.131.71 with SMTP id w7mr6290022qas.91.1406660265263; Tue, 29 Jul 2014 11:57:45 -0700 (PDT) Received: by 10.96.77.227 with HTTP; Tue, 29 Jul 2014 11:57:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jul 2014 14:57:45 -0400 Message-ID: From: James Nguyen To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a11c281546e4d7504ff599dff Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GR3WRCYqor8myX19yDDUiB61ZIg Cc: "" , manet-ads , manet Subject: Re: [manet] Request for WG Adoption: draft-yi-manet-smf-sec-threats 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, 29 Jul 2014 18:57:48 -0000 --001a11c281546e4d7504ff599dff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas et al., draft-yi-manet-smf-sec-threats nicely describes and analyzes potential threats to SMF. Thus, I support the adoption of this work. On Mon, Jul 28, 2014 at 10:11 AM, Thomas Clausen wrote: > Dear WG chairs, > > As indicated in Toronto, the authors would like to see > draft-yi-manet-smf-sec-threats adopted as a WG document. > > The document is currently an individual document, and can be found here: > http://tools.ietf.org/html/draft-yi-manet-smf-sec-threats-00 > > The presentation that was made in Toronto, including some motivational > material for this document, can be found here: > https://tools.ietf.org/agenda/90/slides/slides-90-manet-11.pdf > > An additional motivating factor for publication is, that with the resurge > in interest in multicast protocols for MANETs, and with the increased > understanding of the expectations to security that std. track MANET > protocols are (and, rightfully so) subject to by the SEC-ADs, we probably > need to =E2=80=9Cthink security from the onset=E2=80=9D for any multicast= efforts that we > take on, if we are to be successful. > > The intent is to publish this document as an Informational RFC, similar t= o > how we did with RFC7186. > > It seems the right time to do so, given that we: > > o by now have had time to acquire some experience with > RFC6121 (SMF), > > o have not yet engaged on moving SMF to standards track, an= d > to do so we > must understand and address security better > > > +1 > o while we not (yet) have committed to a group-oriented > multicast protocol, > discussions and interest has resurged with someone > actively pushing for > that -- and I=E2=80=99d bet that there would be lessons t= o share > into such an activity. > > Developing group-oriented multicast protocol is a great idea. Group-oriented multicast protocol could benefit both communications and network configurations. > > WG Chairs, therefore: would you kindly let us know your thoughts on this > matter, at your earliest convenience, preferably by issuing a call for WG > adoption? > > Working Group in general: we much appreciate feedback, comments, and > sharing of your own analysis of and experiences with SMF, so that we may > fold that into future revisions of this document. > > Respectfully, and for the authors, > > Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a11c281546e4d7504ff599dff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas et al.,

draft-yi-manet-smf-sec-th= reats nicely describes and analyzes potential threats to SMF.=C2=A0 Thus, I= support the adoption of this work.=C2=A0


On Mon, Jul 28, 2014 at 10:11 AM, Thomas Clausen <thomas@thomasclau= sen.org> wrote:
Dear WG chairs,

As indicated in Toronto, the authors would like to see draft-yi-manet-smf-s= ec-threats adopted as a WG document.

The document is currently an individual document, and can be found here: =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draf= t-yi-manet-smf-sec-threats-00

The presentation that was made in Toronto, including some motivational mate= rial for this document, can be found here:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/agenda= /90/slides/slides-90-manet-11.pdf

An additional motivating factor for publication is, that with the resurge i= n interest in multicast protocols for MANETs, and with the increased unders= tanding of the expectations to security that std. track MANET protocols are= (and, rightfully so) subject to by the SEC-ADs, we probably need to =E2=80= =9Cthink security from the onset=E2=80=9D for any multicast efforts that we= take on, if we are to be successful.

The intent is to publish this document as an Informational RFC, similar to = how we did with RFC7186.

It seems the right time to do so, given that we:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0 =C2=A0 =C2=A0 by now have had time to = acquire some experience with RFC6121 (SMF),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0 =C2=A0 =C2=A0 have not yet engaged on = moving SMF to standards track, and to do so we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 must understand and= address security better


> +1
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0 =C2=A0 =C2=A0 while we not (yet) have = committed to a group-oriented multicast protocol,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussions and int= erest has resurged with someone actively pushing for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that -- and I=E2=80= =99d bet that there would be lessons to share into such an activity.

> Developing group-oriented multicast prot= ocol is a great idea.=C2=A0 Group-oriented multicast protocol could benefit= both communications and network configurations.
=C2=A0

WG Chairs, therefore: would you kindly let us know your thoughts on this ma= tter, at your earliest convenience, preferably by issuing a call for WG ado= ption?

Working Group in general: we much appreciate feedback, comments, and sharin= g of your own analysis of and experiences with SMF, so that we may fold tha= t into future revisions of this document.

Respectfully, and for the authors,

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



--
James Nguyen
Email: = james.huy.nguyen@gmail.com
--001a11c281546e4d7504ff599dff-- From nobody Tue Jul 29 12:07:12 2014 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 E162B1A0ACB for ; Tue, 29 Jul 2014 12:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 NHLqEvyooWYB for ; Tue, 29 Jul 2014 12:07:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1298C1A0AC9 for ; Tue, 29 Jul 2014 12:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=465; q=dns/txt; s=iport; t=1406660827; x=1407870427; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i0YEUSeA6aNbtpbNFfcnR7jXAXzj9baoIitOFMub4qk=; b=Za/b1n2+/ZABMLOOCrTdvgVjOabTTa3KBoTTHbVaDv7WZh868ft3K8MV UxGZH0pI7HZs/oouu70RIWTVTeDqyKnNYk6zLGmhfCUAVu1OBqdORD3vA SNZU9oApXXlQ0pJ+bZNd91GWnM9ILgsx7/7soidO/r7d56NQjRQ5Ca6BO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKfw11OtJV2P/2dsb2JhbABZgw6BLdM4AYEQFneEBAEBBB1sAgFOMiUCBIhVv0AXj1ODL4EbBZtPlE6DSYIx X-IronPort-AV: E=Sophos;i="5.01,758,1400025600"; d="scan'208";a="64889291" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 29 Jul 2014 19:07:06 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6TJ76tD022550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jul 2014 19:07:06 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 14:07:06 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Call to adopt draft-yi-manet-smf-sec-threats as a working group document Thread-Index: AQHPq2BJEg628njluUyoGaHiTjfUjA== Date: Tue, 29 Jul 2014 19:07:05 +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: [64.102.40.190] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6A8DA8BDF8294C449093026407E81FD1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZY36LV1U28Lz3_WHxV5IcnyJNUI Subject: [manet] Call to adopt draft-yi-manet-smf-sec-threats as a working group document 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, 29 Jul 2014 19:07:10 -0000 Working group participants -=20 This is a call to adopt draft-yi-manet-smf-sec-threats as a Working Group d= ocument. If you have issues with the WG accepting this document, please not= e them on the list before close of business on Aug 12, 2014. The 2-week cal= l for adoption is due to the number of other documents currently on the wor= king group's queue. Lack of a response will be seen as approval for accepti= ng the document.=20 Regards, Stan= From nobody Tue Jul 29 12:29:54 2014 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 B028F1A04B8 for ; Tue, 29 Jul 2014 12:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 gi6BeULsE8dE for ; Tue, 29 Jul 2014 12:29:51 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3041A0176 for ; Tue, 29 Jul 2014 12:29:50 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so126822wgh.14 for ; Tue, 29 Jul 2014 12:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=EyOgRx4XXcaKMblCsyo2gICr+uvGlPgesZt19Bg03PQ=; b=jeS3KEuyTMrf+oM299BuzSJmds9/nSfNdMA6+YAnuPqFyblJVP8IvRx2UljpiGutZU W/BXvnU4s977lZnrjT1MmtXTfc0wcadllBuZB0hxHDwSr4zjYtf/eZmuCYp1HFMqncR+ cPTCaG72jM9o+jAipnb9pRVe2xdB4kDYkEI45kRpqjrZtWshaQ/YTlDHpCgcPz+OMd3m ovsUDqmSHwEurT+CTJwHd/wBZt8e3xgCge+BzB9W47CfXkKlYmbp9UboFvYFcvO0YWE5 taVjVNJo35rHMciXPZZuFMsFC708CppHMlz9L1s8Yj2FC2d1pYWUm63cNMYk11i8S1bl TVuA== MIME-Version: 1.0 X-Received: by 10.180.19.200 with SMTP id h8mr34680wie.32.1406662189496; Tue, 29 Jul 2014 12:29:49 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Tue, 29 Jul 2014 12:29:49 -0700 (PDT) Date: Tue, 29 Jul 2014 21:29:49 +0200 X-Google-Sender-Auth: dJ6-UMfxFqvV7W3TyImyofjDyk4 Message-ID: From: Jiazi YI To: manet , "" , manet-ads Content-Type: multipart/alternative; boundary=bcaec53d5eb71fc58f04ff5a10c5 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yPeSF4_OJuTxGR0detL6Dl90zs4 Subject: [manet] request for WG adoption: draft-yi-manet-olsrv2-multipath 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, 29 Jul 2014 19:29:52 -0000 --bcaec53d5eb71fc58f04ff5a10c5 Content-Type: text/plain; charset=UTF-8 Dear chairs, The draft draft-yi-manet-olsrv2-multipath has been presented in IETF meeting in Toronto. There are a lot of constructive comments from the WG during & after the meeting, detailed in http://www.ietf.org/mail-archive/web/manet/current/msg16613.html http://www.ietf.org/mail-archive/web/manet/current/msg16740.html The feedback is very helpful and exciting. We thus folded them in the new revision of the draft as soon as possible, which is now available today at http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 This draft aims for publication as an *Experimental* Track RFC. The motivation of being an experimental RFC and experiments points have been illustrated in http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 As a reminder, there are multiple open-source implementations available for this protocol and they are now running and being tested in different networks. The multi-path routing has attracted great interest from both industry and academia. We believe it's time to publish the protocol as an experimental RFC, based on the experiences we obtained in the last decade. It would be great help for the engineers and researchers interested in the multi-path approach for MANET, and push it to a standard track protocol eventually. Therefore, we would like to know your opinion on the draft, and kindly request a call for WG adoption. As always, we are looking forward to further comments on the draft from all the WG participants. regards Jiazi --bcaec53d5eb71fc58f04ff5a10c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear chairs,=C2=A0

The draft= draft-yi-manet-olsrv2-multipath has been presented in IETF meeting in Toro= nto.=C2=A0
There are a lot of constructive comments from the WG d= uring & after the meeting, detailed in=C2=A0

The feedback is very helpful and exciting. We thus fold= ed them in the new revision of the draft as soon as possible, which is now = available today at=C2=A0


This draft aims for publication as an *Experimental* Tr= ack RFC. The motivation of being an experimental RFC and experiments points= have been illustrated in=C2=A0

http://= tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1

As a reminder, there are multiple open-source implement= ations available for this protocol and they are now running and being teste= d in different networks. The multi-path routing has attracted great interes= t from both industry and academia.=C2=A0

We believe it's time to publish the protocol as an = experimental RFC, based on the experiences we obtained in the last decade. = It would be great help for the engineers and researchers interested in the = multi-path approach for MANET, and push it to a standard track protocol eve= ntually.=C2=A0

Therefore, we would like to know your opinion on the dr= aft, and kindly request a call for WG adoption.=C2=A0

<= div>As always, we are looking forward to further comments on the draft from= all the WG participants.=C2=A0

regards

Jiazi
--bcaec53d5eb71fc58f04ff5a10c5-- From nobody Tue Jul 29 16:01:17 2014 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 0439D1B29AB for ; Tue, 29 Jul 2014 16:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 y2k3BczsvkLk for ; Tue, 29 Jul 2014 16:01:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16EC1B28B5 for ; Tue, 29 Jul 2014 16:01:10 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6TN18m6019968; Wed, 30 Jul 2014 00:01:08 +0100 Received: from 950129200 (webserver100.static.gvt.net.br [177.99.206.100] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6TN14CG019929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 00:01:06 +0100 From: "Adrian Farrel" To: "'Jiazi YI'" , "'manet'" , , "'manet-ads'" References: In-Reply-To: Date: Wed, 30 Jul 2014 00:01:08 +0100 Message-ID: <019801cfab80$fdf81010$f9e83030$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0199_01CFAB89.5FBEC200" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1nDTybAspUhytuKlMAcgWp+0fepvryJ1g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20848.002 X-TM-AS-Result: No--12.009-10.0-31-10 X-imss-scan-details: No--12.009-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHW/bDrA6VrLRMMmcrjEONdSg85P8ZMy4adI/DikZ1UPOnS UbQfyRyYsRDWvA+bghO25lRDMSiBz5Yeam+R4okHb8JTZf0kEzs6En2bnefhoDRT+LTxhur6THB hhRXBeAv+SkxPwt4b9IwtxAJDa2S87K35r0y1/57Kl4yJoI+fG0XS8dV/QVZAInzOyTDR1uuXf+ 3rM6tuNVlMjfsm5iOHDwC3TuY01vEyZi98qxHMyOw8wbnnSw8bwx0jRRxcQfOP915sGC+sFwMjG 2kpSK/0Pd0AEdkCu0z9YPPN/FvQMk9PXwvU8eutaDCzqDR7DPZljQOFhTiX2R6njTSt2k4LM+B6 N7ohdHDTUpZXCMF6iRAHcMeOkul1g6aq72hSyKhbKUNQk650HdZKsq3DGpal3Hl0OqtoIEoJLoh SbEKjkY544c68DTJIczVqmQFagAJHW+94FA8JF8G0UNgaZpYqbv16+gil4jfSlkoRLCKfE56QVn lXMIygXrfYosn++oqhIBgkfoHq9iIdmtkBwO3DlwOGeK/WrXNT4DtiSkMnWCgMxnfFXjiIdXDbH Fxm2F+dv7RrSohAJCkm8kuls98/aEoHA+Yew8UAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH6 RuK0zz8NRz8HpCmSZEZKdSp4I705BGX7329oyQwfhKwa9GwDWq9ln3+CkiGPaLJ/Ca3ST2ji04E zOjY4PDcFKiUcob7XoUgqgJGOVTWBtSWZ+bE6b/5HBZ6dvRh/r8x3wtvaXyejSyZ3UYtkAMf5Jk UGtGokg8WaoMOWypJTzjwz+GzoSLzBQxkvS++eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIr9/tGI bC7i4cdC2/KBbO0J+mD57ueiE+pueatlIchITU8va4RK/oajMKAuuYcLXW5Ql1R6GFV1KIrX51h AsidiYMb+Seohe2hzXsXbpRsdMdcuK0Ft9hgXwjihSrlWBo= Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0xnROzLpw8YZpRT41IYohdwCsXE Subject: Re: [manet] request for WG adoption: draft-yi-manet-olsrv2-multipath X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 23:01:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0199_01CFAB89.5FBEC200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jiazi, =20 I want to thank you for the responsible approach of labelling this = Experimental. =20 Authors, I would welcome it if you formally asked the PIM working group = to provide multicast review of this work. =20 Chairs as/when you poll for adoption, please make sure that that = cross-WG review has taken place and that any feedback is considered. =20 Thanks! Adrian =20 From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI Sent: 29 July 2014 20:30 To: manet; ; manet-ads Subject: request for WG adoption: draft-yi-manet-olsrv2-multipath =20 Dear chairs,=20 =20 The draft draft-yi-manet-olsrv2-multipath has been presented in IETF = meeting in Toronto.=20 There are a lot of constructive comments from the WG during & after the = meeting, detailed in=20 =20 http://www.ietf.org/mail-archive/web/manet/current/msg16613.html http://www.ietf.org/mail-archive/web/manet/current/msg16740.html =20 The feedback is very helpful and exciting. We thus folded them in the = new revision of the draft as soon as possible, which is now available = today at=20 =20 http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 =20 This draft aims for publication as an *Experimental* Track RFC. The = motivation of being an experimental RFC and experiments points have been = illustrated in=20 =20 http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1= =20 As a reminder, there are multiple open-source implementations available = for this protocol and they are now running and being tested in different = networks. The multi-path routing has attracted great interest from both = industry and academia.=20 =20 We believe it's time to publish the protocol as an experimental RFC, = based on the experiences we obtained in the last decade. It would be = great help for the engineers and researchers interested in the = multi-path approach for MANET, and push it to a standard track protocol = eventually.=20 =20 Therefore, we would like to know your opinion on the draft, and kindly = request a call for WG adoption.=20 =20 As always, we are looking forward to further comments on the draft from = all the WG participants.=20 =20 regards =20 Jiazi ------=_NextPart_000_0199_01CFAB89.5FBEC200 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Jiazi,

 

I want to thank you for the = responsible approach of labelling this = Experimental.

 

Authors, I would welcome it if = you formally asked the PIM working group to provide multicast review of = this work.

 

Chairs as/when you poll for = adoption, please make sure that that cross-WG review has taken place and = that any feedback is considered.

 

Thanks!

Adrian

 

From: = yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI
Sent: 29 July 2014 20:30
To: manet; = <manet-chairs@tools.ietf.org>; manet-ads
Subject: = request for WG adoption: = draft-yi-manet-olsrv2-multipath

 

Dear chairs, 

 

The draft draft-yi-manet-olsrv2-multipath has been = presented in IETF meeting in Toronto. 

There are a lot of constructive comments from the WG = during & after the meeting, detailed = in 

 

 

The feedback is very helpful and exciting. We thus = folded them in the new revision of the draft as soon as possible, which = is now available today at 

 

 

This draft aims for publication as an *Experimental* = Track RFC. The motivation of being an experimental RFC and experiments = points have been illustrated in 

 

 

As a reminder, there are multiple open-source = implementations available for this protocol and they are now running and = being tested in different networks. The multi-path routing has attracted = great interest from both industry and = academia. 

 

We believe it's time to publish the protocol as an = experimental RFC, based on the experiences we obtained in the last = decade. It would be great help for the engineers and researchers = interested in the multi-path approach for MANET, and push it to a = standard track protocol eventually. 

 

Therefore, we would like to know your opinion on the = draft, and kindly request a call for WG = adoption. 

 

As always, we are looking forward to further comments = on the draft from all the WG = participants. 

 

regards

 

Jiazi

------=_NextPart_000_0199_01CFAB89.5FBEC200-- From nobody Wed Jul 30 06:30:57 2014 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 B157F1A007A for ; Wed, 30 Jul 2014 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LRfN-alps0Lo for ; Wed, 30 Jul 2014 06:30:39 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B2A1A007E for ; Wed, 30 Jul 2014 06:30:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6UDG7JT026705; Wed, 30 Jul 2014 14:16:07 +0100 Received: from 950129200 ([200.130.255.1]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6UDG2O4026599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 14:16:05 +0100 From: "Adrian Farrel" To: "'Jiazi YI'" , "'manet'" , , "'manet-ads'" Date: Wed, 30 Jul 2014 14:30:35 +0100 Message-ID: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E6_01CFAC02.D6033440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+r+m9MJZdu0G70QECUyUdW9NnIYg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20848.007 X-TM-AS-Result: No--13.715-10.0-31-10 X-imss-scan-details: No--13.715-10.0-31-10 X-TMASE-MatchedRID: Cv0SBntuihA/7VLjTceIZmzBijri5+RVe/HhT3nTPSuo+b+yOP0oGGSU zEhtalIVOpratWEV5hN34EaNoQAMFTIMh0gavIxoUSn3o+eoUmxlu8AJBkPNMC9+vUEmYLuGDNm /UizetOKynA1Qrbn733tZ9zssQPmJqq672oHxsvZWjqaf7FeZ1QbB3zBRj24zRfmFzyKgHb6VBo 0Fcim+v8T7GckoYtTEtgf5gQoxUXtju8fVtWLoH6wOh3D3JSTGh8Ytn75ClDOvS5tkE2ZFMhEXW gyXQw/xPIlzf2jZSu5xgizGi89MHCfe85/SXo4WuIwLnB3Aqp3VZZGH8PRgAPMUKRQ+25z+FkzB +NuZzgh7lO/ik6Y/Q8DegOGWH69s7BM/cnFsGwpNEMH4f8YUIY19AQoYrNi92xl8IuR5BwiEx7a av+W1F96wqq8MQ6K9X0rc2h4qpXLUbgNMppOAc5mug812qIbzaBTWjXFXXd/FJnEpmt9OE6ZETt /s5jFS3SqeYDfY38tJpV9rHFX3jzblc6Gei4nlcFEiuPxHjsW0X0Yw27VuouQ45nVtPqmxrsFU8 Uw5BC6ytmB2/5InT/zxIC9LasqudG57tpB6osSzLD5kmcW6ZBOySJ0+MHXaE435Dt6W/lg9JrCI Esrp9x/2e9RyQzWhWnMoQfS9Wq/fj2avmfimM5HXKSSl+ScK/AZW18vjv1pyri/EgufZd2AqMCk r6SPveUM3rWqzLMRIBerroh0O+vWfKuqzviIemHJeAYKlcpN3Bf9JIqsoeA8YwboCQc88CE7sep EW6CvzbeV2VN8Li3ZBE86uj+Htoi8K/V7jzhmeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIr9/tGI bC7i4cdC2/KBbO0mquRAzjuFgQ31GKC/gzZqVbq97udU176n/co5tllBVZ+MVy8ucuZo8519UWw F+t6+VsUIcPwS8qsdg3l/o+1x1cdTEjiTd+lSwwcGKLTYEc= Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QkCjxmUhlypavI4kEVdcm4r2bBQ Subject: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 13:30:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E6_01CFAC02.D6033440 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In an attempt to prove that I am human I have just screwed up :-) =20 Thanks to the anonymous benefactor who pointed out that "multi-path" is = not "multi-cast". =20 Feeling a bit stupid. =20 Please ignore that part of my previous email that requested PIM WG = review. =20 =20 Adrian =20 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 30 July 2014 00:01 To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; 'manet-ads' Subject: Re: [manet] request for WG adoption: = draft-yi-manet-olsrv2-multipath =20 Jiazi, =20 I want to thank you for the responsible approach of labelling this = Experimental. =20 Authors, I would welcome it if you formally asked the PIM working group = to provide multicast review of this work. =20 Chairs as/when you poll for adoption, please make sure that that = cross-WG review has taken place and that any feedback is considered. =20 Thanks! Adrian =20 From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI Sent: 29 July 2014 20:30 To: manet; ; manet-ads Subject: request for WG adoption: draft-yi-manet-olsrv2-multipath =20 Dear chairs,=20 =20 The draft draft-yi-manet-olsrv2-multipath has been presented in IETF = meeting in Toronto.=20 There are a lot of constructive comments from the WG during & after the = meeting, detailed in=20 =20 http://www.ietf.org/mail-archive/web/manet/current/msg16613.html http://www.ietf.org/mail-archive/web/manet/current/msg16740.html =20 The feedback is very helpful and exciting. We thus folded them in the = new revision of the draft as soon as possible, which is now available = today at=20 =20 http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 =20 This draft aims for publication as an *Experimental* Track RFC. The = motivation of being an experimental RFC and experiments points have been = illustrated in=20 =20 http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1= =20 As a reminder, there are multiple open-source implementations available = for this protocol and they are now running and being tested in different = networks. The multi-path routing has attracted great interest from both = industry and academia.=20 =20 We believe it's time to publish the protocol as an experimental RFC, = based on the experiences we obtained in the last decade. It would be = great help for the engineers and researchers interested in the = multi-path approach for MANET, and push it to a standard track protocol = eventually.=20 =20 Therefore, we would like to know your opinion on the draft, and kindly = request a call for WG adoption.=20 =20 As always, we are looking forward to further comments on the draft from = all the WG participants.=20 =20 regards =20 Jiazi ------=_NextPart_000_02E6_01CFAC02.D6033440 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

In an attempt to prove that I am human I have just = screwed up :-)

 

Thanks to the anonymous benefactor who pointed out = that "multi-path" is not = "multi-cast".

 

Feeling a bit stupid.

 

Please ignore that part of my previous email that = requested PIM WG review.

 

<sigh>

 

Adrian

 

From: manet = [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: 30 July 2014 00:01
To: 'Jiazi YI'; = 'manet'; manet-chairs@tools.ietf.org; 'manet-ads'
Subject: Re: = [manet] request for WG adoption: = draft-yi-manet-olsrv2-multipath

 

Jiazi,

 

I want to thank you for the responsible approach of labelling this = Experimental.

 

Authors, I would welcome it if you formally asked the PIM working = group to provide multicast review of this work.

 

Chairs as/when you poll for adoption, please make sure that that = cross-WG review has taken place and that any feedback is = considered.

 

Thanks!

Adrian

 

From: = yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI
Sent: 29 July 2014 20:30
To: manet; = <manet-chairs@tools.ietf.org>; manet-ads
Subject: = request for WG adoption: = draft-yi-manet-olsrv2-multipath

 

Dear chairs, 

 

The draft draft-yi-manet-olsrv2-multipath has been = presented in IETF meeting in Toronto. 

There are a lot of constructive comments from the WG = during & after the meeting, detailed = in 

 

 

The feedback is very helpful and exciting. We thus = folded them in the new revision of the draft as soon as possible, which = is now available today at 

 

 

This draft aims for publication as an *Experimental* = Track RFC. The motivation of being an experimental RFC and experiments = points have been illustrated in 

 

 

As a reminder, there are multiple open-source = implementations available for this protocol and they are now running and = being tested in different networks. The multi-path routing has attracted = great interest from both industry and = academia. 

 

We believe it's time to publish the protocol as an = experimental RFC, based on the experiences we obtained in the last = decade. It would be great help for the engineers and researchers = interested in the multi-path approach for MANET, and push it to a = standard track protocol eventually. 

 

Therefore, we would like to know your opinion on the = draft, and kindly request a call for WG = adoption. 

 

As always, we are looking forward to further comments = on the draft from all the WG = participants. 

 

regards

 

Jiazi

------=_NextPart_000_02E6_01CFAC02.D6033440-- From nobody Wed Jul 30 07:22:44 2014 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 A1CDC1A0039 for ; Wed, 30 Jul 2014 07:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7PhbBaDZLbyU for ; Wed, 30 Jul 2014 07:22:24 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9151A004E for ; Wed, 30 Jul 2014 07:22:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5EB891BDA0D2; Wed, 30 Jul 2014 07:22:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 634791BDA0CB; Wed, 30 Jul 2014 07:22:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E440EFF7-46AD-49D5-9DBD-2C1B8A8F279F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Wed, 30 Jul 2014 16:22:15 +0200 Message-Id: References: To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IO0spwwVYI1_xygXYSfoIZsm_aw Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 30 Jul 2014 14:22:30 -0000 --Apple-Mail=_E440EFF7-46AD-49D5-9DBD-2C1B8A8F279F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chris, On Jul 29, 2014, at 16:17, Dearlove, Christopher (UK) = wrote: > (Apologies for the previous accidental empty send.) > =20 > I=92ll pick up a separate point this time, namely > =20 > Isn=92t it RFC7183 which does = shared-secret-key ICVs? I just did a quick > grep through of =93shared=94 in 7182, and = found just a few mentions, notably > setting a side a value for key-id-length in = that case. And =93secret=94 is not > mentioned anywhere in 7182 > =20 > 7182 contains both symmetric and asymmetric ciphers, on the one hand = DSA, HMAC, 3DES, AES, on the other hand RSA, ECDSA. > =20 > How the keys are organised is not discussed in 7182, it is rather = implicit. In the symmetric case we need to share keys, this > Could be as simple as a single shared key, but as exemplified by 7183 = (which uses one of the symmetric cases) this could > Be multiple keys. In the asymmetric case we have pairwise keys, = pre-distributed or with public keys certified, and a PKI > On top of that. So 7182 implicitly (but not explicitly) offers us = these three options (shared keys, pre-shared pairwise keys, > PKI =96 and the overhead of certificates). > =20 > As this document is about 7182, not 7183 (which is NHDP/OLSRv2 only) = I=92d rather stick to just referencing and discussing 7182, > But a wording tweak may be in order. > =20 Alright, so I see that there=92re two things that can happen: reference = 7183, and keep the text unchanged =97 or word-tweak so that the citation = to 7182 can remain. Either can work for me, seems you prefer the latter, = so I am looking forward to seeing an update. Thomas > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 28 July 2014 14:19 > To: manet; ; manet-ads > Cc: Christopher Dearlove > Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, clickhere. > If you feel the email is suspicious, please follow this process. >=20 > Dear WG Chairs,=20 > Dear Chris, all, > =20 > As the author indicated by email recently, he believes that = draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC.=20 > =20 > As a reminder, this document aims for publication as a Proposed = Standard. > =20 > I have, therefore, reviewed the document carefully. In my opinion, the = author is right =97in my opinion this document is ready for WGLC. > =20 > Moreover, I believe that it is a highly important document for the WG = to produce, as it fills a real need, and does so by relying on = already-published crypto RFCs, rather than by coming up with something = esoteric. > =20 > I have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none of my nits and issues are of the sort that should be = blocking. > =20 > One of the issues is =93need a non-jetlagged ADs advice to be sure we = do the right thing=94, the other is =97 I think =97 a minor mix-up with = a trivial editorial resolution and zero technical impact on this = specification. > =20 > Either way, for information, I include all issues and nits that I=92ve = found in the below. > =20 > Issues: > =20 > o In my opinion, =93Updates 7182=94 is = inappropriate. What this document does is: > (i) only things = permissible by RFC7182, and=20 > (ii) makes registration = from IANA registries set up by RFC7182 > (noting, of course, = that RFC7181 doesn=92t =93Updates 5444=94=20 > when making = registrations for TC messages from the repositories=20 > set up by RFC5444 as = a case of precedent) > Consequently, I believe that the abstract, = introduction, and document=20 > header, needs updates to reflect that this is = not an update. > =20 > Caveat Lector: I have bounced this around with = the author, and I=20 > think that the = conclusion is that we need just a friendly=20 > ADs opinion =97 my = understanding is that the author > =93wants this out, but = wants it done right, also=94, something > to which I can but = adhere. > =20 > I believe that we = should WGLC the document. If the AD > finds the time to = address this issue during WGLC, great - > otherwise, we can = reflect this in the =93Document Writeup=94 > that the AD will = consider with the publication request =97 as > this (imo) is = procedural/editorial, and certainly not technical. > =20 > o Introduction, 4th paragraph: > =20 > Isn=92t it RFC7183 which does = shared-secret-key ICVs? I just did a quick > grep through of =93shared=94 in 7182, and = found just a few mentions, notably > setting a side a value for key-id-length in = that case. And =93secret=94 is not > mentioned anywhere in 7182 > =20 > =20 > Nits: > o Introduction, 1st paragraph: > OLD: > This specification extends the TLV = definitions > therein by defining two new = cryptographic function code points that > allow the use of an identity-based = signature (IBS) as an ICV. > =20 > NEW: > This specification defines two new = cryptographic function=20 > code points from within the = registries set up by [RFC7182],=20 > that allow the use of an = identity-based signature (IBS) as an ICV. > =20 > o Introduction, 2nd paragraph, 1st line: > I took a double-take when I saw the = parenthesis=20 > =93(protocol participant)=94 =97 that seems a = little odd, and I am on a crusade > against redundant and hard-to-parse = terminology ;) > =20 > I think that what is meant is =93router, which = is running a routing=20 > protocol which is based on RFC5444=94, so = could the document not say > that? > =20 > In any event, I do not see =93protocol = participant=94 defined or anywhere else, > and so it seems unfortunate to *not* be = explicit here. > =20 > o Introduction, 3rd paragraph: > =20 > OLD: > Two options for the choice of = identity are supported (the two code > points allocated). > =20 > NEW: > Two options for the choice of = identity are supported (as reflected > by the two code points allocated). > =20 > =20 > o Introduction, 7th paragraph: > Caveating that using this introduces the = danger that =93if you catch the=20 > trusted authority, then you=92re screwed=94 is = awesome. I see that=20 > this is repeated and reworded in the Security = Considerations section, > and I approve.=20 > =20 > Now, my question is then, if this should not = be stated in the Applicability=20 > statement, also? Something to the effect of = that this applies to networks > where all routers can (at some point) be in = contact with the TA (to be > keyed), but that this can be off-line =97 and = probably should be off-line > since the TA really, really should be = protected. > =20 > It might be argued that the forward-reference = to Section 6 captures > this =97 I still think, that a few choice = words in the applicability statement > would help greatly. > =20 > o Introduction, 9th paragraph: > Any [academic? otherwise] work that you can = cite to quantify the=20 > computational load? I asked a = crypto-wonk-colleague, who said > something to the effect of =93the document is = perfectly right, on this > point, but I do not have a paper just off the = top of my head with=20 > interesting data to offer=94. For that reason = alone, it=92d be interesting=20 > if you did ;) > =20 > o Throw-away comment, I appreciate particularly = the last > paragraph of the introduction. > =20 > o Section 4.1, first bullet > =20 > OLD: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in = [RFC7182], but (like the HMAC > ICVs defined there) uses the hash = function within the > cryptographic function. The option = "none" is not permitted for > hash-function, and the hash function = must have a known fixed > length of N octets, as specified in = Section 4.2. > =20 > NEW: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in = [RFC7182], but (like the HMAC > ICVs defined in [RFC7182]) uses the = hash function within the > cryptographic function. The option = "none" is not permitted for > hash-function, and the hash function = must have a known fixed > length of N octets, as specified in = Section 4.2. > =20 > o While we are at it, it it crystal-clear to = everybody that =93Section 4.2=94 in > the bullet above is to *this* document, as not = RFC7182? > =20 > o Section 4.3, 2nd bullet > There=92s a LOT of information embedded in = this bullet, and reading it > suggests that it, readability-wise, might = benefit from embedding a: > > =85 > =85 > =85 > > =20 > o IANA Considerations: > =20 > Given recent experiences in this WG and with = requesting IANA=20 > registrations, may I suggest that this be = modified to say, more > explicitly: > =20 > 1) IANA is requested to = reserve ECCSI with description ___=20 > and reference =93This = Specification=94 > =20 > 2) IANA is requested to = reserve ECCSI-ADDR=85. (similar) > =20 > 3) The =93Cryptographic = Functions Registry=94, defined in=20 > [RFC7182], with these = registrations made, will look > like Table 1, which = replaces Table 11 of [RFC7182] > =20 > 4) Obviously, include in = Table 1 the registrations from > RFC7182. > =20 > 5) That this document does = not modify the expert > review guidelines as = set forth in RFC7182 for > future allocations. > =20 > That=92s all. Thanks for writing this document, Chris.=20 > =20 > =20 > Respectfully, > =20 > Thomas > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_E440EFF7-46AD-49D5-9DBD-2C1B8A8F279F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Chris,

On Jul 29, 2014, at 16:17, = Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

(Apologies for the previous accidental empty = send.)
 
I=92ll pick up a separate point this time, = namely
 
        &= nbsp;           &nb= sp;   Isn=92t it RFC7183 = which does shared-secret-key ICVs? I just did a = quick
        &= nbsp;           &nb= sp;   grep through of = =93shared=94 in 7182, and found just a few mentions, = notably
        &= nbsp;           &nb= sp;   setting a side a = value for key-id-length in that case. And =93secret=94 is = not
        &= nbsp;           &nb= sp;   mentioned anywhere = in 7182
 
7182 contains both symmetric and asymmetric ciphers, = on the one hand DSA, HMAC, 3DES, AES, on the other hand RSA, = ECDSA.
 
How the keys are organised is not discussed in 7182, = it is rather implicit. In the symmetric case we need to share keys, = this
Could be as simple as a single shared key, but as = exemplified by 7183 (which uses one of the symmetric cases) this = could
Be multiple keys. In the asymmetric case we have = pairwise keys, pre-distributed or with public keys certified, and a = PKI
On top of that. So 7182 implicitly (but not = explicitly) offers us these three options (shared keys, pre-shared = pairwise keys,
PKI =96 and the overhead of = certificates).
 
As this document is about 7182, not 7183 (which is = NHDP/OLSRv2 only) I=92d rather stick to just referencing and discussing = 7182,
But a wording tweak may be in = order.
 

Alright,= so I see that there=92re two things that can happen: reference 7183, = and keep the text unchanged =97 or word-tweak so that the citation to = 7182 can remain. Either can work for me, seems you prefer the latter, so = I am looking forward to seeing an = update.

Thomas


--
Christopher = Dearlove
Senior Principal Engineer, Information Assurance = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: Thomas Clausen [mailto:thomas@thomasclausen.org] 
Sent: 28 July 2014 = 14:19
To: manet; <manet-chairs@tools.ietf.org>; = manet-ads
Cc: Christopher = Dearlove
Subject: Ready for WGLC: Advancing = draft-ietf-manet-ibs
 
 
*** = WARNING ***

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

Dear = WG Chairs, 
Dear = Chris, all,
 
As = the author indicated by email recently, he believes = that draft-ietf-manet-olsrv2-management-snapshot is ready for = WGLC. 
 
As a = reminder, this document aims for publication as a Proposed = Standard.
 
I = have, therefore, reviewed the document carefully. In my opinion, the = author is right =97in my opinion this document is ready for = WGLC.
 
Moreover, I believe that it is a highly important document for = the WG to produce, as it fills a real need, and does so by relying on = already-published crypto RFCs, rather than by coming up with something = esoteric.
 
I = have two issues, and handful nits, that I expect the author will = consider along with any other WGLC comments they may receive. Of course, = if a new version is spun before WGLC is requested, then I=92ll gladly = review that, also. Point being: let=92s get a call started on this = document, none = of my nits and issues are of the sort that should be = blocking.
 
One = of the issues is =93need a non-jetlagged ADs advice to be sure we do the = right thing=94, the other is =97 I think =97 a minor mix-up with a = trivial editorial resolution and zero technical impact on this = specification.
 
Either way, for information, I include all issues and nits that = I=92ve found in the below.
 
Issues:
 
        &= nbsp;   o        &= nbsp; In my = opinion, =93Updates 7182=94 is inappropriate. What this document does = is:
        &= nbsp;           &nb= sp;            = ;   (i)         only things = permissible by RFC7182, and 
        &= nbsp;           &nb= sp;            = ;   (ii)        makes registration = from IANA registries set up by RFC7182
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  (noting, of course, = that RFC7181 doesn=92t =93Updates = 5444=94 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;   when making = registrations for TC messages from the = repositories 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;   set up by = RFC5444 as a case of precedent)
        &= nbsp;           &nb= sp;   Consequently, I = believe that the abstract, introduction, and = document 
        &= nbsp;           &nb= sp;   header, needs = updates to reflect that this is not an = update.
        &= nbsp;           &nb= sp;  
        &= nbsp;           &nb= sp;   Caveat Lector: I = have bounced this around with the author, and = I 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  think= that the conclusion is that we need just a = friendly 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  ADs = opinion =97 my understanding is that the = author
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  =93wants this out, = but wants it done right, also=94, = something
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  to = which I can but adhere.
        &= nbsp;           &nb= sp;  
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  I = believe that we should WGLC the document. If the = AD
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  finds= the time to address this issue during WGLC, great = -
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  otherwise, we can = reflect this in the =93Document Writeup=94
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  that = the AD will consider with the publication request =97 = as
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  this = (imo) is procedural/editorial, and certainly not = technical.
 
        &= nbsp;   o        &= nbsp; Introduction, 4th = paragraph:
 
        &= nbsp;           &nb= sp;   Isn=92t it RFC7183 = which does shared-secret-key ICVs? I just did a = quick
        &= nbsp;           &nb= sp;   grep through of = =93shared=94 in 7182, and found just a few mentions, = notably
        &= nbsp;           &nb= sp;   setting a side a = value for key-id-length in that case. And =93secret=94 is = not
        &= nbsp;           &nb= sp;   mentioned anywhere = in 7182
 
 
Nits:
        &= nbsp;   o        &= nbsp; Introduction, 1st = paragraph:
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;            = ;   This specification = extends the TLV definitions
        &= nbsp;           &nb= sp;            = ;   therein by defining = two new cryptographic function code points = that
        &= nbsp;           &nb= sp;            = ;   allow the use of an = identity-based signature (IBS) as an = ICV.
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;            = ;   This specification = defines two new cryptographic = function 
        &= nbsp;           &nb= sp;            = ;   code points from = within the registries set up by = [RFC7182], 
        &= nbsp;           &nb= sp;            = ;   that allow the use = of an identity-based signature (IBS) as an = ICV.
 
        &= nbsp;   o        &= nbsp; Introduction, 2nd = paragraph, 1st line:
        &= nbsp;           &nb= sp;   I= took a double-take when I saw the = parenthesis 
        &= nbsp;           &nb= sp;   =93(protocol = participant)=94 =97 that seems a little odd, and I am on a = crusade
        &= nbsp;           &nb= sp;   against redundant = and hard-to-parse terminology ;)
 
        &= nbsp;           &nb= sp;   I= think that what is meant is =93router, which is running a = routing 
        &= nbsp;           &nb= sp;   protocol which is = based on RFC5444=94, so could the document not = say
        &= nbsp;           &nb= sp;   that?
=
 
        &= nbsp;           &nb= sp;   In any event, I do = not see =93protocol participant=94 defined or anywhere = else,
        &= nbsp;           &nb= sp;   and so it seems = unfortunate to *not* be explicit here.
 
        &= nbsp;   o        &= nbsp; Introduction, 3rd = paragraph:
 
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;            = ;   Two= options for the choice of identity are supported (the two = code
        &= nbsp;           &nb= sp;            = ;   points = allocated).
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;            = ;   Two= options for the choice of identity are supported (as = reflected
        &= nbsp;           &nb= sp;            = ;   by = the two code points allocated).
 
 
        &= nbsp;   o        &= nbsp; Introduction, 7th = paragraph:
        &= nbsp;           &nb= sp;   Caveating that using = this introduces the danger that =93if you catch = the 
        &= nbsp;           &nb= sp;   trusted authority, = then you=92re screwed=94 is awesome. I see = that 
        &= nbsp;           &nb= sp;   this is repeated and = reworded in the Security Considerations = section,
        &= nbsp;           &nb= sp;   and I = approve. 
 
        &= nbsp;           &nb= sp;   Now, my question is = then, if this should not be stated in the = Applicability 
        &= nbsp;           &nb= sp;   statement, also? = Something to the effect of that this applies to = networks
        &= nbsp;           &nb= sp;   where all routers = can (at some point) be in contact with the TA (to = be
        &= nbsp;           &nb= sp;   keyed), but that = this can be off-line =97 and probably should be = off-line
        &= nbsp;           &nb= sp;   since the TA really, = really should be protected.
 
        &= nbsp;           &nb= sp;   It might be argued = that the forward-reference to Section 6 = captures
        &= nbsp;           &nb= sp;   this =97 I still = think, that a few choice words in the applicability = statement
        &= nbsp;           &nb= sp;   would help = greatly.
 
        &= nbsp;   o        &= nbsp; Introduction, 9th = paragraph:
        &= nbsp;           &nb= sp;   Any [academic? = otherwise] work that you can cite to quantify = the 
        &= nbsp;           &nb= sp;   computational load? = I asked a crypto-wonk-colleague, who = said
        &= nbsp;           &nb= sp;   something to the = effect of =93the document is perfectly right, on = this
        &= nbsp;           &nb= sp;   point, but I do = not have a paper just off the top of my head = with 
        &= nbsp;           &nb= sp;   interesting data to = offer=94. For that reason alone, it=92d be = interesting 
        &= nbsp;           &nb= sp;   if you did = ;)
 
        &= nbsp;   o        &= nbsp; Throw-away = comment, I appreciate particularly the = last
        &= nbsp;           &nb= sp;   paragraph of the = introduction.
 
        &= nbsp;   o        &= nbsp; Section = 4.1, first bullet
 
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;      o =  The ICV is not calculated as = cryptographic-function(hash-
        &= nbsp;           &nb= sp;         =  function(content)) as defined in [RFC7182], but (like the = HMAC
        &= nbsp;           &nb= sp;        =   ICVs defined there) uses the hash function within = the
        &= nbsp;           &nb= sp;        =   cryptographic function.  The option "none" is not permitted = for
        &= nbsp;           &nb= sp;        =   hash-function, and the hash function must have a known = fixed
        &= nbsp;           &nb= sp;        =   length of N octets, as specified in Section = 4.2.
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;      o =  The ICV is not calculated as = cryptographic-function(hash-
        &= nbsp;           &nb= sp;         =  function(content)) as defined in [RFC7182], but (like the = HMAC
        &= nbsp;           &nb= sp;        =   ICVs defined in [RFC7182]) uses the hash function within = the
        &= nbsp;           &nb= sp;        =   cryptographic function.  The option "none" is not permitted = for
        &= nbsp;           &nb= sp;        =   hash-function, and the hash function must have a known = fixed
        &= nbsp;   =                  =   length of N octets, as specified in Section = 4.2.
 
        &= nbsp;   o        &= nbsp; While we = are at it, it it crystal-clear to everybody that =93Section 4.2=94 = in
        &= nbsp;           &nb= sp;   the bullet above is = to *this* document, as not RFC7182?
 
        &= nbsp;   o        &= nbsp; Section = 4.3, 2nd bullet
        &= nbsp;           &nb= sp;   There=92s a LOT of = information embedded in this bullet, and reading = it
        &= nbsp;           &nb= sp;   suggests that it, = readability-wise, might benefit from embedding = a:
        &= nbsp;           &nb= sp;            = ;   <list = style=3D=93hanging=94>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Packet = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Message = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Address Block = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;   </list>
 
        &= nbsp;   o        &= nbsp; IANA = Considerations:
 
        &= nbsp;           &nb= sp;   Given recent = experiences in this WG and with requesting = IANA 
        &= nbsp;           &nb= sp;   registrations, may I = suggest that this be modified to say, = more
        &= nbsp;           &nb= sp;   explicitly:=
 
        &= nbsp;           &nb= sp;            = ;   1)        <= span class=3D"Apple-converted-space"> IANA is = requested to reserve ECCSI with description = ___ 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  and = reference =93This Specification=94
 
        &= nbsp;           &nb= sp;            = ;   2)        <= span class=3D"Apple-converted-space"> IANA is = requested to reserve ECCSI-ADDR=85. = (similar)
 
        &= nbsp;           &nb= sp;            = ;   3)        <= span class=3D"Apple-converted-space"> The = =93Cryptographic Functions Registry=94, defined = in 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  [RFC7182], with = these registrations made, will look
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  like = Table 1, which replaces Table 11 of = [RFC7182]
 
        &= nbsp;           &nb= sp;            = ;   4)        <= span class=3D"Apple-converted-space"> Obviously, = include in Table 1 the registrations = from
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  RFC7182.
 
        &= nbsp;           &nb= sp;            = ;   5)        <= span class=3D"Apple-converted-space"> That this = document does not modify the expert
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  review guidelines as = set forth in RFC7182 for
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  future = allocations.
 
That=92s all. Thanks for writing this document, Chris. 
 
 
Respectfully,
 
Thomas

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

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

= --Apple-Mail=_E440EFF7-46AD-49D5-9DBD-2C1B8A8F279F-- From nobody Wed Jul 30 07:32:47 2014 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 962451A00A7 for ; Wed, 30 Jul 2014 07:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uCVKg1crQFA2 for ; Wed, 30 Jul 2014 07:32:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF751A0039 for ; Wed, 30 Jul 2014 07:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B56361D8B2C; Wed, 30 Jul 2014 07:32:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7058F1C023A; Wed, 30 Jul 2014 07:32:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF125B43-65EB-40CA-9001-37D43A3ABEB0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Wed, 30 Jul 2014 16:32:28 +0200 Message-Id: References: To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/to-y6lDnuQ7SiLmR5peETvUX7UI Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 30 Jul 2014 14:32:43 -0000 --Apple-Mail=_CF125B43-65EB-40CA-9001-37D43A3ABEB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chris, On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK) = wrote: > Some additional comments inline. I plan to put out a new version = shortly, but technically all will be unchanged. Comments below, but yes, what I suggest are in the =93nits=94 category, = which is why I would have been happy to see the current version WGLCed. = If you have a new version that addresses my nits, then the WGLC will be = even easier for me, though.... Below (snipping out the parts where we agree and stuff). >=20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 28 July 2014 14:19 > To: manet; ; manet-ads > Cc: Christopher Dearlove > Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs >=20 > I have, therefore, reviewed the document carefully. In my opinion, the = author is right =97in my opinion this document is ready for WGLC. > Issues: > =20 > o In my opinion, =93Updates 7182=94 is = inappropriate. What this document does is: > (i) only things = permissible by RFC7182, and=20 > (ii) makes registration = from IANA registries set up by RFC7182 > (noting, of course, = that RFC7181 doesn=92t =93Updates 5444=94=20 > when making = registrations for TC messages from the repositories=20 > set up by RFC5444 as = a case of precedent) > Consequently, I believe that the abstract, = introduction, and document=20 > header, needs updates to reflect that this is = not an update. > =20 > Caveat Lector: I have bounced this around with = the author, and I=20 > think that the = conclusion is that we need just a friendly=20 > ADs opinion =97 my = understanding is that the author > =93wants this out, but = wants it done right, also=94, something > to which I can but = adhere. > =20 > I believe that we = should WGLC the document. If the AD > finds the time to = address this issue during WGLC, great - > otherwise, we can = reflect this in the =93Document Writeup=94 > that the AD will = consider with the publication request =97 as > this (imo) is = procedural/editorial, and certainly not technical. > =20 > CMD: On the grounds that the biggest wasted effort is taking out, and = then maybe putting back in, I=92m going to leave as-is until our AD = comments. But I=92d have done the same if it were the other way round, = I=92m happy whichever way this is settled.=20 I=92m entirely aligned with you on this point. If we do not get an ADs = input before, we just need to make sure that this will be included in = the document write-up and dealt with then. > o Introduction, 4th paragraph: > =20 > Isn=92t it RFC7183 which does = shared-secret-key ICVs? I just did a quick > grep through of =93shared=94 in 7182, and = found just a few mentions, notably > setting a side a value for key-id-length in = that case. And =93secret=94 is not > mentioned anywhere in 7182 > =20 > CMD: I made an earlier post on this. I think that some improvements in = wording in the Introduction are indicated. > =20 Acknowledged, and that=92s quite satisfactory. > =20 > Nits: > o Introduction, 1st paragraph: > OLD: > This specification extends the TLV = definitions > therein by defining two new = cryptographic function code points that > allow the use of an identity-based = signature (IBS) as an ICV. > =20 > NEW: > This specification defines two new = cryptographic function=20 > code points from within the = registries set up by [RFC7182],=20 > that allow the use of an = identity-based signature (IBS) as an ICV. > =20 > CMD: I want to keep some of what=92s lost by that edit, so will = propose a third wording. Looking forward to seeing that. > =20 > o Introduction, 2nd paragraph, 1st line: > I took a double-take when I saw the = parenthesis=20 > =93(protocol participant)=94 =97 that seems a = little odd, and I am on a crusade > against redundant and hard-to-parse = terminology ;) > =20 > I think that what is meant is =93router, which = is running a routing=20 > protocol which is based on RFC5444=94, so = could the document not say > that? > =20 > In any event, I do not see =93protocol = participant=94 defined or anywhere else, > and so it seems unfortunate to *not* be = explicit here. > =20 > CMD: Simply removing the parenthesis removes the intended point, which = was to say that the > description assumes that the entities involved are routers =96 which = isn=92t actually the only possibility > using 5444. I=92ll propose something that borrows from the above to = improve it. OK, looking forward to seeing that, too. > =20 > o Introduction, 7th paragraph: > Caveating that using this introduces the = danger that =93if you catch the=20 > trusted authority, then you=92re screwed=94 is = awesome. I see that=20 > this is repeated and reworded in the Security = Considerations section, > and I approve.=20 > =20 > Now, my question is then, if this should not = be stated in the Applicability=20 > statement, also? Something to the effect of = that this applies to networks > where all routers can (at some point) be in = contact with the TA (to be > keyed), but that this can be off-line =97 and = probably should be off-line > since the TA really, really should be = protected. > =20 > It might be argued that the forward-reference = to Section 6 captures > this =97 I still think, that a few choice = words in the applicability statement > would help greatly. > =20 > CMD: I prefer to stick with the forward reference, as I think by the = time you=92ve said enough, you=92ve duplicated half of Section 6. But = adding some words to say particularly regarding the role of the TA/KMS = makes sense. I think that we are aligned, that that=92s what the last sentence in my = comment seeks to capture. So, I look forward to seeing your proposal to = this, too. > =20 > o Introduction, 9th paragraph: > Any [academic? otherwise] work that you can = cite to quantify the=20 > computational load? I asked a = crypto-wonk-colleague, who said > something to the effect of =93the document is = perfectly right, on this > point, but I do not have a paper just off the = top of my head with=20 > interesting data to offer=94. For that reason = alone, it=92d be interesting=20 > if you did ;) > =20 > CMD: See previous comments. Trying Google Scholar with ECCSI elliptic = curve gets a very small number of hits, none useful here. I=92ve asked around, but I am not hopeful. Will let you know if I get = something citable =97 most I spoke to said =93this aligns with my = intuition/experience/*=94 though. > OLD: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in = [RFC7182], but (like the HMAC > ICVs defined there) uses the hash = function within the > cryptographic function. The option = "none" is not permitted for > hash-function, and the hash function = must have a known fixed > length of N octets, as specified in = Section 4.2. > =20 > NEW: > o The ICV is not calculated as = cryptographic-function(hash- > function(content)) as defined in = [RFC7182], but (like the HMAC > ICVs defined in [RFC7182]) uses the = hash function within the > cryptographic function. The option = "none" is not permitted for > hash-function, and the hash function = must have a known fixed > length of N octets, as specified in = Section 4.2. > =20 > CMD: I could live with either, but will make the change. I think it makes it clearer, so thank you for that. > =20 > o While we are at it, it it crystal-clear to = everybody that =93Section 4.2=94 in > the bullet above is to *this* document, as not = RFC7182? > =20 > CMD: I=92m going to assume it is. I would always write Section X.Y of = [Z] (or similar) if making an external reference. OK, this was a throw-away comment, not important =20 > o Section 4.3, 2nd bullet > There=92s a LOT of information embedded in = this bullet, and reading it > suggests that it, readability-wise, might = benefit from embedding a: > > =85 > =85 > =85 > > =20 > CMD: I=92m including to be slightly less radical (and I=92m not a fan = on hanging text). But I will create another level. Thank you, that will work nicely. > =20 > o IANA Considerations: > =20 > Given recent experiences in this WG and with = requesting IANA=20 > registrations, may I suggest that this be = modified to say, more > explicitly: > =20 > 1) IANA is requested to = reserve ECCSI with description ___=20 > and reference =93This = Specification=94 > =20 > 2) IANA is requested to = reserve ECCSI-ADDR=85. (similar) > =20 > 3) The =93Cryptographic = Functions Registry=94, defined in=20 > [RFC7182], with these = registrations made, will look > like Table 1, which = replaces Table 11 of [RFC7182] > =20 > 4) Obviously, include in = Table 1 the registrations from > RFC7182. > =20 > 5) That this document does = not modify the expert > review guidelines as = set forth in RFC7182 for > future allocations. > =20 > CMD: I think this comes under the heading of hand-holding IANA more = than I would feel ought to be necessary. Except sometimes it has been. = But this is a straightforward case, so while I agree that making it more = explicit that this is a request for two new code points, I=92m not going = to repeat the full table from 7182 unless IANA really show they need = hand-holding. Our previous cases where we had to repeat a whole table = were a bit messier. But giving the exact name for the table as on IANA=92s= website is advisable. > =20 True, but=85there=92s perhaps something to be said for =93the table = being as complete as possible=94 for the reader, also? Well, your call, = of course. Once a new version hits the servers, I=92ll let you know if I see any = pending nits. Cheers, Thomas --Apple-Mail=_CF125B43-65EB-40CA-9001-37D43A3ABEB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Chris,


On = Jul 29, 2014, at 17:16, Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

Some additional comments inline. I plan to put out a = new version shortly, but technically all will be = unchanged.

Comments below, = but yes, what I suggest are in the =93nits=94 category, which is why I = would have been happy to see the current version WGLCed. If you have a = new version that addresses my nits, then the WGLC will be even easier = for me, though....

Below (snipping out the = parts where we agree and stuff).

From: Thomas Clausen [mailto:thomas@thomasclausen.org] 
Sent: 28 July 2014 = 14:19
To: manet; <manet-chairs@tools.ietf.org>; = manet-ads
Cc: Christopher = Dearlove
Subject: Ready for WGLC: Advancing = draft-ietf-manet-ibs


<SNIP>

I have, therefore, reviewed the document carefully. = In my opinion, the author is right =97in my opinion this = document is ready for = WGLC.

<SNIP&= gt;

Issues:
 
        &= nbsp;   o        &= nbsp; In my = opinion, =93Updates 7182=94 is inappropriate. What this document does = is:
        &= nbsp;           &nb= sp;            = ;   (i)         only things = permissible by RFC7182, and 
        &= nbsp;           &nb= sp;            = ;   (ii)        makes registration = from IANA registries set up by RFC7182
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  (noting, of course, = that RFC7181 doesn=92t =93Updates = 5444=94 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;   when making = registrations for TC messages from the = repositories 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;   set up by = RFC5444 as a case of precedent)
        &= nbsp;           &nb= sp;   Consequently, I = believe that the abstract, introduction, and = document 
        &= nbsp;           &nb= sp;   header, needs = updates to reflect that this is not an = update.
        &= nbsp;           &nb= sp;  
        &= nbsp;           &nb= sp;   Caveat Lector: I = have bounced this around with the author, and = I 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  think= that the conclusion is that we need just a = friendly 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  ADs = opinion =97 my understanding is that the = author
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  =93wants this out, = but wants it done right, also=94, = something
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  to = which I can but adhere.
        &= nbsp;           &nb= sp;  
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  I = believe that we should WGLC the document. If the = AD
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  finds= the time to address this issue during WGLC, great = -
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  otherwise, we can = reflect this in the =93Document Writeup=94
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  that = the AD will consider with the publication request =97 = as
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  this = (imo) is procedural/editorial, and certainly not = technical.
 
CMD: On the grounds that the biggest wasted effort is = taking out, and then maybe putting back in, I=92m going to leave as-is = until our AD comments. But I=92d have done the same if it were the other = way round, I=92m happy whichever way this is settled. 

I=92m entirely aligned with you on this point. If we do not get an = ADs input before, we just need to make sure that this will be included = in the document write-up and dealt with = then.


        &= nbsp;   o        &= nbsp; Introduction, 4th = paragraph:
 
        &= nbsp;           &nb= sp;   Isn=92t it RFC7183 = which does shared-secret-key ICVs? I just did a = quick
        &= nbsp;           &nb= sp;   grep through of = =93shared=94 in 7182, and found just a few mentions, = notably
        &= nbsp;           &nb= sp;   setting a side a = value for key-id-length in that case. And =93secret=94 is = not
        &= nbsp;           &nb= sp;   mentioned anywhere = in 7182
 
CMD: I made an earlier = post on this. I think that some improvements in wording in the = Introduction are indicated.
 

Acknowledged, and that=92s quite = satisfactory.

 
Nits:
        &= nbsp;   o        &= nbsp; Introduction, 1st = paragraph:
        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;            = ;   This specification = extends the TLV definitions
        &= nbsp;           &nb= sp;            = ;   therein by defining = two new cryptographic function code points = that
        &= nbsp;           &nb= sp;            = ;   allow the use of an = identity-based signature (IBS) as an = ICV.
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;            = ;   This specification = defines two new cryptographic = function 
        &= nbsp;           &nb= sp;            = ;   code points from = within the registries set up by = [RFC7182], 
        &= nbsp;           &nb= sp;            = ;   that allow the use = of an identity-based signature (IBS) as an = ICV.
 
CMD: I want to keep some = of what=92s lost by that edit, so will propose a third = wording.

Looking = forward to seeing that.

 
        &= nbsp;   o        &= nbsp; Introduction, 2nd = paragraph, 1st line:
        &= nbsp;           &nb= sp;   I= took a double-take when I saw the = parenthesis 
        &= nbsp;           &nb= sp;   =93(protocol = participant)=94 =97 that seems a little odd, and I am on a = crusade
        &= nbsp;           &nb= sp;   against redundant = and hard-to-parse terminology ;)
 
        &= nbsp;           &nb= sp;   I= think that what is meant is =93router, which is running a = routing 
        &= nbsp;           &nb= sp;   protocol which is = based on RFC5444=94, so could the document not = say
        &= nbsp;           &nb= sp;   that?
=
 
        &= nbsp;           &nb= sp;   In any event, I do = not see =93protocol participant=94 defined or anywhere = else,
        &= nbsp;           &nb= sp;   and so it seems = unfortunate to *not* be explicit here.
 
CMD: Simply removing the parenthesis removes the = intended point, which was to say that the
description assumes that = the entities involved are routers =96 which isn=92t actually the only = possibility
using 5444. I=92ll propose something that borrows = from the above to improve it.

OK,= looking forward to seeing that, = too.

<SNIP>

 
        &= nbsp;   o        &= nbsp; Introduction, 7th = paragraph:
        &= nbsp;           &nb= sp;   Caveating that using = this introduces the danger that =93if you catch = the 
        &= nbsp;           &nb= sp;   trusted authority, = then you=92re screwed=94 is awesome. I see = that 
        &= nbsp;           &nb= sp;   this is repeated and = reworded in the Security Considerations = section,
        &= nbsp;           &nb= sp;   and I = approve. 
 
        &= nbsp;           &nb= sp;   Now, my question is = then, if this should not be stated in the = Applicability 
        &= nbsp;           &nb= sp;   statement, also? = Something to the effect of that this applies to = networks
        &= nbsp;           &nb= sp;   where all routers = can (at some point) be in contact with the TA (to = be
        &= nbsp;           &nb= sp;   keyed), but that = this can be off-line =97 and probably should be = off-line
        &= nbsp;           &nb= sp;   since the TA really, = really should be protected.
 
        &= nbsp;           &nb= sp;   It might be argued = that the forward-reference to Section 6 = captures
        &= nbsp;           &nb= sp;   this =97 I still = think, that a few choice words in the applicability = statement
        &= nbsp;           &nb= sp;   would help = greatly.
 
CMD: I prefer to stick = with the forward reference, as I think by the time you=92ve said enough, = you=92ve duplicated half of Section 6. But adding some words to say = particularly regarding the role of the TA/KMS makes = sense.

I = think that we are aligned, that that=92s what the last sentence in my = comment seeks to capture. So, I look forward to seeing your proposal to = this, too.

 
        &= nbsp;   o        &= nbsp; Introduction, 9th = paragraph:
        &= nbsp;           &nb= sp;   Any [academic? = otherwise] work that you can cite to quantify = the 
        &= nbsp;           &nb= sp;   computational load? = I asked a crypto-wonk-colleague, who = said
        &= nbsp;           &nb= sp;   something to the = effect of =93the document is perfectly right, on = this
        &= nbsp;           &nb= sp;   point, but I do = not have a paper just off the top of my head = with 
        &= nbsp;           &nb= sp;   interesting data to = offer=94. For that reason alone, it=92d be = interesting 
        &= nbsp;           &nb= sp;   if you did = ;)
 
CMD: See previous comments. Trying Google Scholar = with ECCSI elliptic curve gets a very small number of hits, none useful = here.

I=92= ve asked around, but I am not hopeful. Will let you know if I get = something citable =97 most I spoke to said =93this aligns with my = intuition/experience/*=94 = though.

<SNIP>

        &= nbsp;           &nb= sp;   OLD:
<= /div>
        &= nbsp;           &nb= sp;      o =  The ICV is not calculated as = cryptographic-function(hash-
        &= nbsp;           &nb= sp;         =  function(content)) as defined in [RFC7182], but (like the = HMAC
        &= nbsp;           &nb= sp;        =   ICVs defined there) uses the hash function within = the
        &= nbsp;           &nb= sp;        =   cryptographic function.  The option "none" is not permitted = for
        &= nbsp;           &nb= sp;        =   hash-function, and the hash function must have a known = fixed
        &= nbsp;           &nb= sp;        =   length of N octets, as specified in Section = 4.2.
 
        &= nbsp;           &nb= sp;   NEW:
<= /div>
        &= nbsp;           &nb= sp;      o =  The ICV is not calculated as = cryptographic-function(hash-
        &= nbsp;           &nb= sp;         =  function(content)) as defined in [RFC7182], but (like the = HMAC
        &= nbsp;           &nb= sp;        =   ICVs defined in [RFC7182]) uses the hash function within = the
        &= nbsp;           &nb= sp;        =   cryptographic function.  The option "none" is not permitted = for
        &= nbsp;           &nb= sp;        =   hash-function, and the hash function must have a known = fixed
        &= nbsp;   =                  =   length of N octets, as specified in Section = 4.2.
 
CMD: I could live with either, but will make the = change.

I = think it makes it clearer, so thank you for = that.

 
        &= nbsp;   o        &= nbsp; While we = are at it, it it crystal-clear to everybody that =93Section 4.2=94 = in
        &= nbsp;           &nb= sp;   the bullet above is = to *this* document, as not RFC7182?
 
CMD: I=92m going to = assume it is. I would always write Section X.Y of [Z] (or similar) if = making an external = reference.

OK, = this was a throw-away comment, not important
 
        &= nbsp;   o        &= nbsp; Section = 4.3, 2nd bullet
        &= nbsp;           &nb= sp;   There=92s a LOT of = information embedded in this bullet, and reading = it
        &= nbsp;           &nb= sp;   suggests that it, = readability-wise, might benefit from embedding = a:
        &= nbsp;           &nb= sp;            = ;   <list = style=3D=93hanging=94>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Packet = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Message = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  <t= hangText=3D=93Address Block = TLVs=94>=85</t>
        &= nbsp;           &nb= sp;            = ;   </list>
 
CMD: I=92m including to be slightly less radical (and = I=92m not a fan on hanging text). But I will create another = level.

Thank = you, that will work nicely.

 
        &= nbsp;   o        &= nbsp; IANA = Considerations:
 
        &= nbsp;           &nb= sp;   Given recent = experiences in this WG and with requesting = IANA 
        &= nbsp;           &nb= sp;   registrations, may I = suggest that this be modified to say, = more
        &= nbsp;           &nb= sp;   explicitly:=
 
        &= nbsp;           &nb= sp;            = ;   1)        <= span class=3D"Apple-converted-space"> IANA is = requested to reserve ECCSI with description = ___ 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  and = reference =93This Specification=94
 
        &= nbsp;           &nb= sp;            = ;   2)        <= span class=3D"Apple-converted-space"> IANA is = requested to reserve ECCSI-ADDR=85. = (similar)
 
        &= nbsp;           &nb= sp;            = ;   3)        <= span class=3D"Apple-converted-space"> The = =93Cryptographic Functions Registry=94, defined = in 
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  [RFC7182], with = these registrations made, will look
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  like = Table 1, which replaces Table 11 of = [RFC7182]
 
        &= nbsp;           &nb= sp;            = ;   4)        <= span class=3D"Apple-converted-space"> Obviously, = include in Table 1 the registrations = from
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  RFC7182.
 
        &= nbsp;           &nb= sp;            = ;   5)        <= span class=3D"Apple-converted-space"> That this = document does not modify the expert
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  review guidelines as = set forth in RFC7182 for
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  future = allocations.
 
CMD: I think this comes = under the heading of hand-holding IANA more than I would feel ought to = be necessary. Except sometimes it has been. But this is a = straightforward case, so while I agree that making it more explicit that = this is a request for two new code points, I=92m not going to repeat the = full table from 7182 unless IANA really show they need hand-holding. Our = previous cases where we had to repeat a whole table were a bit messier. = But giving the exact name for the table as on IANA=92s website is = advisable.
 

Tr= ue, but=85there=92s perhaps something to be said for =93the table being = as complete as possible=94 for the reader, also? Well, your call, of = course.

Once a new version hits the servers, = I=92ll let you know if I see any pending = nits.

Cheers,

Thomas

= --Apple-Mail=_CF125B43-65EB-40CA-9001-37D43A3ABEB0-- From nobody Wed Jul 30 07:37:17 2014 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 46B551A00AA for ; Wed, 30 Jul 2014 07:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 qyv9ClQ5nj8x for ; Wed, 30 Jul 2014 07:37:08 -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 E4F351A005D for ; Wed, 30 Jul 2014 07:37:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,764,1400022000"; d="scan'208,217";a="390575270" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jul 2014 15:37:06 +0100 X-IronPort-AV: E=Sophos; i="5.01,764,1400022000"; d="scan'208,217"; a="66649862" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 30 Jul 2014 15:37:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 15:37:16 +0100 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , 'Jiazi YI' , 'manet' , "manet-chairs@tools.ietf.org" , 'manet-ads' Thread-Topic: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] Thread-Index: Ac+r+m9MJZdu0G70QECUyUdW9NnIYgACTicw Date: Wed, 30 Jul 2014 14:37:16 +0000 Message-ID: References: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> In-Reply-To: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CAB7GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yxtnbQQd4HRrUhHU9DOcVE47gMM Subject: Re: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] 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, 30 Jul 2014 14:37:13 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CAB7GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SnVzdCB0byBhZGQgdG8gdGhlIGNvbmZ1c2lvbiwgd2UgaGF2ZSBtdWx0aS10b3BvbG9neSwgbXVs dGlwYXRoIGFuZCBtdWx0aWNhc3QsIGFsbCBkaWZmZXJlbnQuDQoNCi0tDQpDaHJpc3RvcGhlciBE ZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNl IEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFi aWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5p bmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6 ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0 ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3Jv dWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQpGcm9tOiBtYW5ldCBb bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVs DQpTZW50OiAzMCBKdWx5IDIwMTQgMTQ6MzENClRvOiAnSmlhemkgWUknOyAnbWFuZXQnOyBtYW5l dC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7ICdtYW5ldC1hZHMnDQpTdWJqZWN0OiBbbWFuZXRdIER1 aC1vaCBbV2FzOiByZXF1ZXN0IGZvciBXRyBhZG9wdGlvbjogZHJhZnQteWktbWFuZXQtb2xzcnYy LW11bHRpcGF0aF0NCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBw YXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBz aG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4N CkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91 dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5l bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz L1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywg cGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdp dGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpJbiBhbiBhdHRlbXB0IHRvIHByb3ZlIHRo YXQgSSBhbSBodW1hbiBJIGhhdmUganVzdCBzY3Jld2VkIHVwIDotKQ0KDQpUaGFua3MgdG8gdGhl IGFub255bW91cyBiZW5lZmFjdG9yIHdobyBwb2ludGVkIG91dCB0aGF0ICJtdWx0aS1wYXRoIiBp cyBub3QgIm11bHRpLWNhc3QiLg0KDQpGZWVsaW5nIGEgYml0IHN0dXBpZC4NCg0KUGxlYXNlIGln bm9yZSB0aGF0IHBhcnQgb2YgbXkgcHJldmlvdXMgZW1haWwgdGhhdCByZXF1ZXN0ZWQgUElNIFdH IHJldmlldy4NCg0KPHNpZ2g+DQoNCkFkcmlhbg0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQpTZW50OiAzMCBK dWx5IDIwMTQgMDA6MDENClRvOiAnSmlhemkgWUknOyAnbWFuZXQnOyBtYW5ldC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWNoYWlyc0B0b29scy5pZXRmLm9yZz47ICdtYW5ldC1h ZHMnDQpTdWJqZWN0OiBSZTogW21hbmV0XSByZXF1ZXN0IGZvciBXRyBhZG9wdGlvbjogZHJhZnQt eWktbWFuZXQtb2xzcnYyLW11bHRpcGF0aA0KDQpKaWF6aSwNCg0KSSB3YW50IHRvIHRoYW5rIHlv dSBmb3IgdGhlIHJlc3BvbnNpYmxlIGFwcHJvYWNoIG9mIGxhYmVsbGluZyB0aGlzIEV4cGVyaW1l bnRhbC4NCg0KQXV0aG9ycywgSSB3b3VsZCB3ZWxjb21lIGl0IGlmIHlvdSBmb3JtYWxseSBhc2tl ZCB0aGUgUElNIHdvcmtpbmcgZ3JvdXAgdG8gcHJvdmlkZSBtdWx0aWNhc3QgcmV2aWV3IG9mIHRo aXMgd29yay4NCg0KQ2hhaXJzIGFzL3doZW4geW91IHBvbGwgZm9yIGFkb3B0aW9uLCBwbGVhc2Ug bWFrZSBzdXJlIHRoYXQgdGhhdCBjcm9zcy1XRyByZXZpZXcgaGFzIHRha2VuIHBsYWNlIGFuZCB0 aGF0IGFueSBmZWVkYmFjayBpcyBjb25zaWRlcmVkLg0KDQpUaGFua3MhDQpBZHJpYW4NCg0KRnJv bTogeWkuamlhemlAZ21haWwuY29tPG1haWx0bzp5aS5qaWF6aUBnbWFpbC5jb20+IFttYWlsdG86 eWkuamlhemlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgSmlhemkgWUkNClNlbnQ6IDI5IEp1bHkg MjAxNCAyMDozMA0KVG86IG1hbmV0OyA8bWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0 bzptYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+PjsgbWFuZXQtYWRzDQpTdWJqZWN0OiByZXF1 ZXN0IGZvciBXRyBhZG9wdGlvbjogZHJhZnQteWktbWFuZXQtb2xzcnYyLW11bHRpcGF0aA0KDQpE ZWFyIGNoYWlycywNCg0KVGhlIGRyYWZ0IGRyYWZ0LXlpLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgg aGFzIGJlZW4gcHJlc2VudGVkIGluIElFVEYgbWVldGluZyBpbiBUb3JvbnRvLg0KVGhlcmUgYXJl IGEgbG90IG9mIGNvbnN0cnVjdGl2ZSBjb21tZW50cyBmcm9tIHRoZSBXRyBkdXJpbmcgJiBhZnRl ciB0aGUgbWVldGluZywgZGV0YWlsZWQgaW4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTY2MTMuaHRtbA0KaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTY3NDAuaHRtbA0KDQpUaGUgZmVl ZGJhY2sgaXMgdmVyeSBoZWxwZnVsIGFuZCBleGNpdGluZy4gV2UgdGh1cyBmb2xkZWQgdGhlbSBp biB0aGUgbmV3IHJldmlzaW9uIG9mIHRoZSBkcmFmdCBhcyBzb29uIGFzIHBvc3NpYmxlLCB3aGlj aCBpcyBub3cgYXZhaWxhYmxlIHRvZGF5IGF0DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXlpLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDINCg0KVGhpcyBkcmFmdCBhaW1zIGZv ciBwdWJsaWNhdGlvbiBhcyBhbiAqRXhwZXJpbWVudGFsKiBUcmFjayBSRkMuIFRoZSBtb3RpdmF0 aW9uIG9mIGJlaW5nIGFuIGV4cGVyaW1lbnRhbCBSRkMgYW5kIGV4cGVyaW1lbnRzIHBvaW50cyBo YXZlIGJlZW4gaWxsdXN0cmF0ZWQgaW4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteWktbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wMiNzZWN0aW9uLTEuMQ0KDQpBcyBhIHJlbWlu ZGVyLCB0aGVyZSBhcmUgbXVsdGlwbGUgb3Blbi1zb3VyY2UgaW1wbGVtZW50YXRpb25zIGF2YWls YWJsZSBmb3IgdGhpcyBwcm90b2NvbCBhbmQgdGhleSBhcmUgbm93IHJ1bm5pbmcgYW5kIGJlaW5n IHRlc3RlZCBpbiBkaWZmZXJlbnQgbmV0d29ya3MuIFRoZSBtdWx0aS1wYXRoIHJvdXRpbmcgaGFz IGF0dHJhY3RlZCBncmVhdCBpbnRlcmVzdCBmcm9tIGJvdGggaW5kdXN0cnkgYW5kIGFjYWRlbWlh Lg0KDQpXZSBiZWxpZXZlIGl0J3MgdGltZSB0byBwdWJsaXNoIHRoZSBwcm90b2NvbCBhcyBhbiBl eHBlcmltZW50YWwgUkZDLCBiYXNlZCBvbiB0aGUgZXhwZXJpZW5jZXMgd2Ugb2J0YWluZWQgaW4g dGhlIGxhc3QgZGVjYWRlLiBJdCB3b3VsZCBiZSBncmVhdCBoZWxwIGZvciB0aGUgZW5naW5lZXJz IGFuZCByZXNlYXJjaGVycyBpbnRlcmVzdGVkIGluIHRoZSBtdWx0aS1wYXRoIGFwcHJvYWNoIGZv ciBNQU5FVCwgYW5kIHB1c2ggaXQgdG8gYSBzdGFuZGFyZCB0cmFjayBwcm90b2NvbCBldmVudHVh bGx5Lg0KDQpUaGVyZWZvcmUsIHdlIHdvdWxkIGxpa2UgdG8ga25vdyB5b3VyIG9waW5pb24gb24g dGhlIGRyYWZ0LCBhbmQga2luZGx5IHJlcXVlc3QgYSBjYWxsIGZvciBXRyBhZG9wdGlvbi4NCg0K QXMgYWx3YXlzLCB3ZSBhcmUgbG9va2luZyBmb3J3YXJkIHRvIGZ1cnRoZXIgY29tbWVudHMgb24g dGhlIGRyYWZ0IGZyb20gYWxsIHRoZSBXRyBwYXJ0aWNpcGFudHMuDQoNCnJlZ2FyZHMNCg0KSmlh emkNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBp dCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3Qg Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmli dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CAB7GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkp1c3QgdG8gYWRkIHRvIHRoZSBjb25mdXNpb24sIHdlIGhhdmUgbXVsdGkt dG9wb2xvZ3ksIG11bHRpcGF0aCBhbmQgbXVsdGljYXN0LCBhbGwgZGlmZmVyZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RvcGhlciBEZWFybG92ZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5T ZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXA8YnI+ DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHk8 YnI+DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZTxicj4NCldlc3QgSGFu bmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUs8YnI+ DQpUZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7IEZheDogJiM0Mzs0NCAxMjQ1 IDI0MjEyNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj5jaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+DQogfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMu Y29tPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CQUUgU3lzdGVtcyAoT3BlcmF0aW9u cykgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3gg ODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1Ux NCA2WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAxOTk2 Njg3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+QWRyaWFuIEZhcnJlbDxicj4NCjxiPlNlbnQ6PC9iPiAzMCBKdWx5 IDIwMTQgMTQ6MzE8YnI+DQo8Yj5Ubzo8L2I+ICdKaWF6aSBZSSc7ICdtYW5ldCc7IG1hbmV0LWNo YWlyc0B0b29scy5pZXRmLm9yZzsgJ21hbmV0LWFkcyc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21h bmV0XSBEdWgtb2ggW1dhczogcmVxdWVzdCBmb3IgV0cgYWRvcHRpb246IGRyYWZ0LXlpLW1hbmV0 LW9sc3J2Mi1tdWx0aXBhdGhdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxh Y2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhp cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVt PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFu PjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQg RmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVj ZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYi Pg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBz dXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJh ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFs aW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4u PC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4g YW4gYXR0ZW1wdCB0byBwcm92ZSB0aGF0IEkgYW0gaHVtYW4gSSBoYXZlIGp1c3Qgc2NyZXdlZCB1 cCA6LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyB0byB0aGUgYW5vbnltb3VzIGJlbmVmYWN0b3Igd2hvIHBv aW50ZWQgb3V0IHRoYXQgJnF1b3Q7bXVsdGktcGF0aCZxdW90OyBpcyBub3QgJnF1b3Q7bXVsdGkt Y2FzdCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZlZWxpbmcgYSBiaXQgc3R1cGlkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxl YXNlIGlnbm9yZSB0aGF0IHBhcnQgb2YgbXkgcHJldmlvdXMgZW1haWwgdGhhdCByZXF1ZXN0ZWQg UElNIFdHIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtzaWdoJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRyaWFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gbWFuZXQgWzxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkFkcmlhbiBGYXJyZWw8YnI+DQo8Yj5TZW50OjwvYj4gMzAgSnVseSAyMDE0IDAwOjAxPGJyPg0K PGI+VG86PC9iPiAnSmlhemkgWUknOyAnbWFuZXQnOyA8YSBocmVmPSJtYWlsdG86bWFuZXQtY2hh aXJzQHRvb2xzLmlldGYub3JnIj5tYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+OyAnbWFu ZXQtYWRzJzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSByZXF1ZXN0IGZvciBXRyBh ZG9wdGlvbjogZHJhZnQteWktbWFuZXQtb2xzcnYyLW11bHRpcGF0aDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5KaWF6aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2FudCB0byB0aGFuayB5b3UgZm9y IHRoZSByZXNwb25zaWJsZSBhcHByb2FjaCBvZiBsYWJlbGxpbmcgdGhpcyBFeHBlcmltZW50YWwu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BdXRob3JzLCBJIHdvdWxkIHdlbGNvbWUgaXQgaWYgeW91IGZvcm1hbGx5IGFz a2VkIHRoZSBQSU0gd29ya2luZyBncm91cCB0byBwcm92aWRlIG11bHRpY2FzdCByZXZpZXcgb2Yg dGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hhaXJzIGFzL3doZW4geW91IHBvbGwgZm9yIGFkb3B0aW9u LCBwbGVhc2UgbWFrZSBzdXJlIHRoYXQgdGhhdCBjcm9zcy1XRyByZXZpZXcgaGFzIHRha2VuIHBs YWNlIGFuZCB0aGF0IGFueSBmZWVkYmFjayBpcyBjb25zaWRlcmVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtz ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZHJpYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEg aHJlZj0ibWFpbHRvOnlpLmppYXppQGdtYWlsLmNvbSI+eWkuamlhemlAZ21haWwuY29tPC9hPiBb PGEgaHJlZj0ibWFpbHRvOnlpLmppYXppQGdtYWlsLmNvbSI+bWFpbHRvOnlpLmppYXppQGdtYWls LmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppYXppIFlJPGJyPg0KPGI+U2VudDo8L2I+ IDI5IEp1bHkgMjAxNCAyMDozMDxicj4NCjxiPlRvOjwvYj4gbWFuZXQ7ICZsdDs8YSBocmVmPSJt YWlsdG86bWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5tYW5ldC1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0OzsgbWFuZXQtYWRzPGJyPg0KPGI+U3ViamVjdDo8L2I+IHJlcXVlc3QgZm9y IFdHIGFkb3B0aW9uOiBkcmFmdC15aS1tYW5ldC1vbHNydjItbXVsdGlwYXRoPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGNo YWlycywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGRyYWZ0IGRyYWZ0LXlpLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGggaGFzIGJl ZW4gcHJlc2VudGVkIGluIElFVEYgbWVldGluZyBpbiBUb3JvbnRvLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIGEgbG90 IG9mIGNvbnN0cnVjdGl2ZSBjb21tZW50cyBmcm9tIHRoZSBXRyBkdXJpbmcgJmFtcDsgYWZ0ZXIg dGhlIG1lZXRpbmcsIGRldGFpbGVkIGluJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE2NjEzLmh0bWwiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE2NjEzLmh0bWw8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9t c2cxNjc0MC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQv Y3VycmVudC9tc2cxNjc0MC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmVlZGJhY2sgaXMgdmVyeSBoZWxwZnVsIGFuZCBl eGNpdGluZy4gV2UgdGh1cyBmb2xkZWQgdGhlbSBpbiB0aGUgbmV3IHJldmlzaW9uIG9mIHRoZSBk cmFmdCBhcyBzb29uIGFzIHBvc3NpYmxlLCB3aGljaCBpcyBub3cgYXZhaWxhYmxlIHRvZGF5IGF0 Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlpLW1hbmV0LW9s c3J2Mi1tdWx0aXBhdGgtMDIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlpLW1h bmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgYWltcyBmb3IgcHVibGljYXRpb24g YXMgYW4gKkV4cGVyaW1lbnRhbCogVHJhY2sgUkZDLiBUaGUgbW90aXZhdGlvbiBvZiBiZWluZyBh biBleHBlcmltZW50YWwgUkZDIGFuZCBleHBlcmltZW50cyBwb2ludHMgaGF2ZSBiZWVuIGlsbHVz dHJhdGVkIGluJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlp LW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDIjc2VjdGlvbi0xLjEiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXlpLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDIjc2VjdGlvbi0xLjE8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIGEgcmVtaW5kZXIsIHRoZXJlIGFyZSBtdWx0aXBsZSBvcGVuLXNvdXJjZSBpbXBsZW1lbnRh dGlvbnMgYXZhaWxhYmxlIGZvciB0aGlzIHByb3RvY29sIGFuZCB0aGV5IGFyZSBub3cgcnVubmlu ZyBhbmQgYmVpbmcgdGVzdGVkIGluIGRpZmZlcmVudCBuZXR3b3Jrcy4gVGhlIG11bHRpLXBhdGgg cm91dGluZyBoYXMgYXR0cmFjdGVkIGdyZWF0IGludGVyZXN0IGZyb20gYm90aCBpbmR1c3RyeSBh bmQgYWNhZGVtaWEuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldlIGJlbGlldmUgaXQncyB0aW1lIHRvIHB1Ymxpc2ggdGhlIHByb3Rv Y29sIGFzIGFuIGV4cGVyaW1lbnRhbCBSRkMsIGJhc2VkIG9uIHRoZSBleHBlcmllbmNlcyB3ZSBv YnRhaW5lZCBpbiB0aGUgbGFzdCBkZWNhZGUuIEl0IHdvdWxkIGJlIGdyZWF0IGhlbHAgZm9yIHRo ZSBlbmdpbmVlcnMgYW5kIHJlc2VhcmNoZXJzIGludGVyZXN0ZWQgaW4gdGhlIG11bHRpLXBhdGgg YXBwcm9hY2ggZm9yIE1BTkVULCBhbmQNCiBwdXNoIGl0IHRvIGEgc3RhbmRhcmQgdHJhY2sgcHJv dG9jb2wgZXZlbnR1YWxseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmVmb3JlLCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgeW91 ciBvcGluaW9uIG9uIHRoZSBkcmFmdCwgYW5kIGtpbmRseSByZXF1ZXN0IGEgY2FsbCBmb3IgV0cg YWRvcHRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFzIGFsd2F5cywgd2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byBmdXJ0aGVy IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBmcm9tIGFsbCB0aGUgV0cgcGFydGljaXBhbnRzLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5y ZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkppYXppPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8YnI+ClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lw aWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2Vu ZGVyLjxicj4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl IG5vciBkaXNjbG9zZSBvcjxicj4KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbi48YnI+CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqPC9wPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CAB7GLKXM0002VGREEN_-- From nobody Wed Jul 30 07:38:35 2014 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 A21741A0115 for ; Wed, 30 Jul 2014 07:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jx-g2W8L5xNF for ; Wed, 30 Jul 2014 07:38:26 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92101A0087 for ; Wed, 30 Jul 2014 07:38:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8EDA61BDA5C2; Wed, 30 Jul 2014 07:38:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 92C6F1BDA5BB; Wed, 30 Jul 2014 07:38:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B4196951-56F0-4F76-9A94-482053CAB9C1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Wed, 30 Jul 2014 16:38:18 +0200 Message-Id: <8CF1E618-3420-4636-A1E2-3440D350163C@thomasclausen.org> References: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gtFHyQIq-q36OHXvordHhIDAwGc Cc: manet , "manet-chairs@tools.ietf.org" , manet-ads Subject: Re: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] 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, 30 Jul 2014 14:38:29 -0000 --Apple-Mail=_B4196951-56F0-4F76-9A94-482053CAB9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2014, at 16:37, Dearlove, Christopher (UK) = wrote: > Just to add to the confusion, we have multi-topology, multipath and = multicast, all different. So are you saying that we need multi-personalitydisorder to properly = follow them all? :) Thomas =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 30 July 2014 14:31 > To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; 'manet-ads' > Subject: [manet] Duh-oh [Was: request for WG adoption: = draft-yi-manet-olsrv2-multipath] > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, clickhere. > If you feel the email is suspicious, please follow this process. >=20 > In an attempt to prove that I am human I have just screwed up :-) > =20 > Thanks to the anonymous benefactor who pointed out that "multi-path" = is not "multi-cast". > =20 > Feeling a bit stupid. > =20 > Please ignore that part of my previous email that requested PIM WG = review. > =20 > > =20 > Adrian > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 30 July 2014 00:01 > To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; 'manet-ads' > Subject: Re: [manet] request for WG adoption: = draft-yi-manet-olsrv2-multipath > =20 > Jiazi, > =20 > I want to thank you for the responsible approach of labelling this = Experimental. > =20 > Authors, I would welcome it if you formally asked the PIM working = group to provide multicast review of this work. > =20 > Chairs as/when you poll for adoption, please make sure that that = cross-WG review has taken place and that any feedback is considered. > =20 > Thanks! > Adrian > =20 > From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of = Jiazi YI > Sent: 29 July 2014 20:30 > To: manet; ; manet-ads > Subject: request for WG adoption: draft-yi-manet-olsrv2-multipath > =20 > Dear chairs,=20 > =20 > The draft draft-yi-manet-olsrv2-multipath has been presented in IETF = meeting in Toronto.=20 > There are a lot of constructive comments from the WG during & after = the meeting, detailed in=20 > =20 > http://www.ietf.org/mail-archive/web/manet/current/msg16613.html > http://www.ietf.org/mail-archive/web/manet/current/msg16740.html > =20 > The feedback is very helpful and exciting. We thus folded them in the = new revision of the draft as soon as possible, which is now available = today at=20 > =20 > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 > =20 > This draft aims for publication as an *Experimental* Track RFC. The = motivation of being an experimental RFC and experiments points have been = illustrated in=20 > =20 > = http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 > =20 > As a reminder, there are multiple open-source implementations = available for this protocol and they are now running and being tested in = different networks. The multi-path routing has attracted great interest = from both industry and academia.=20 > =20 > We believe it's time to publish the protocol as an experimental RFC, = based on the experiences we obtained in the last decade. It would be = great help for the engineers and researchers interested in the = multi-path approach for MANET, and push it to a standard track protocol = eventually.=20 > =20 > Therefore, we would like to know your opinion on the draft, and kindly = request a call for WG adoption.=20 > =20 > As always, we are looking forward to further comments on the draft = from all the WG participants.=20 > =20 > regards > =20 > Jiazi > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_B4196951-56F0-4F76-9A94-482053CAB9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 30, 2014, at 16:37, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

Just to add to the confusion, we have multi-topology, = multipath and multicast, all different.

So are = you saying that we need multi-personalitydisorder to properly follow = them all? :)

Thomas
 
--
Christopher = Dearlove
Senior Principal Engineer, Information Assurance = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: 30 July 2014 = 14:31
To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; = 'manet-ads'
Subject: [manet] Duh-oh [Was: = request for WG adoption: = draft-yi-manet-olsrv2-multipath]
 
 
*** = WARNING ***

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

In an attempt to prove that I am human I have just = screwed up :-)
 
Thanks to the anonymous benefactor who pointed out = that "multi-path" is not "multi-cast".
 
Feeling a bit = stupid.
 
Please ignore that part of my previous email that = requested PIM WG review.
 
<sigh>
 
Adrian
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: 30 July 2014 = 00:01
To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; = 'manet-ads'
Subject: Re: [manet] request for WG = adoption: = draft-yi-manet-olsrv2-multipath
 
Jiazi,
 
I want to thank you for = the responsible approach of labelling this = Experimental.
 
Authors, I would welcome it if you formally asked the = PIM working group to provide multicast review of this = work.
 
Chairs as/when you poll for adoption, please make = sure that that cross-WG review has taken place and that any feedback is = considered.
 
Thanks!
Adrian
 
From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI
Sent: 29 = July 2014 20:30
To: manet; <manet-chairs@tools.ietf.org>; = manet-ads
Subject: request for WG adoption: = draft-yi-manet-olsrv2-multipath
 
Dear chairs, 
 
The draft draft-yi-manet-olsrv2-multipath has been = presented in IETF meeting in = Toronto. 
There = are a lot of constructive comments from the WG during & after the = meeting, detailed in 
 
 
The = feedback is very helpful and exciting. We thus folded them in the new = revision of the draft as soon as possible, which is now available today = at 
 
 
As a = reminder, there are multiple open-source implementations available for = this protocol and they are now running and being tested in different = networks. The multi-path routing has attracted great interest from both = industry and academia. 
 
We believe it's time to publish the protocol as an = experimental RFC, based on the experiences we obtained in the last = decade. It would be great help for the engineers and researchers = interested in the multi-path approach for MANET, and push it to a = standard track protocol = eventually. 
 
Therefore, we would like to know your opinion on the draft, and = kindly request a call for WG = adoption. 
 
As = always, we are looking forward to further comments on the draft from all = the WG participants. 
 
regards
 
Jiazi

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

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

= --Apple-Mail=_B4196951-56F0-4F76-9A94-482053CAB9C1-- From nobody Wed Jul 30 07:40:42 2014 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 869761A0115 for ; Wed, 30 Jul 2014 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 527bHVn8lJqU for ; Wed, 30 Jul 2014 07:40:36 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0FB1A00A3 for ; Wed, 30 Jul 2014 07:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 114B31C0873; Wed, 30 Jul 2014 07:40:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1D4361C023A; Wed, 30 Jul 2014 07:40:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_188DE98D-DA9A-4301-A85F-FCD8CA875582" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: <8CF1E618-3420-4636-A1E2-3440D350163C@thomasclausen.org> Date: Wed, 30 Jul 2014 16:40:29 +0200 Message-Id: References: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> <8CF1E618-3420-4636-A1E2-3440D350163C@thomasclausen.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/opaktTeGc-ZtE3DzB-YEpD1xVYo Cc: "manet-chairs@tools.ietf.org" , manet-ads , manet Subject: Re: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] 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, 30 Jul 2014 14:40:39 -0000 --Apple-Mail=_188DE98D-DA9A-4301-A85F-FCD8CA875582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 30, 2014, at 16:38, Thomas Clausen = wrote: >=20 > On Jul 30, 2014, at 16:37, Dearlove, Christopher (UK) = wrote: >=20 >> Just to add to the confusion, we have multi-topology, multipath and = multicast, all different. >=20 > So are you saying that we need multi-personalitydisorder to properly = follow them all? :) Oh, and you forgot multipoint-relays, abbreviated MPR, not to be = confused by MRP from ODMRP (which means something else)=85. ;) > Thomas > =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Information Assurance Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel >> Sent: 30 July 2014 14:31 >> To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; 'manet-ads' >> Subject: [manet] Duh-oh [Was: request for WG adoption: = draft-yi-manet-olsrv2-multipath] >> =20 >> =20 >> *** WARNING *** >> This message originates from outside our organisation, either from an = external partner or the internet. >> Consider carefully whether you should click on any links, open any = attachments or reply. >> For information regarding Red Flags that you can look out for in = emails you receive, clickhere. >> If you feel the email is suspicious, please follow this process. >>=20 >> In an attempt to prove that I am human I have just screwed up :-) >> =20 >> Thanks to the anonymous benefactor who pointed out that "multi-path" = is not "multi-cast". >> =20 >> Feeling a bit stupid. >> =20 >> Please ignore that part of my previous email that requested PIM WG = review. >> =20 >> >> =20 >> Adrian >> =20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel >> Sent: 30 July 2014 00:01 >> To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; 'manet-ads' >> Subject: Re: [manet] request for WG adoption: = draft-yi-manet-olsrv2-multipath >> =20 >> Jiazi, >> =20 >> I want to thank you for the responsible approach of labelling this = Experimental. >> =20 >> Authors, I would welcome it if you formally asked the PIM working = group to provide multicast review of this work. >> =20 >> Chairs as/when you poll for adoption, please make sure that that = cross-WG review has taken place and that any feedback is considered. >> =20 >> Thanks! >> Adrian >> =20 >> From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of = Jiazi YI >> Sent: 29 July 2014 20:30 >> To: manet; ; manet-ads >> Subject: request for WG adoption: draft-yi-manet-olsrv2-multipath >> =20 >> Dear chairs,=20 >> =20 >> The draft draft-yi-manet-olsrv2-multipath has been presented in IETF = meeting in Toronto.=20 >> There are a lot of constructive comments from the WG during & after = the meeting, detailed in=20 >> =20 >> http://www.ietf.org/mail-archive/web/manet/current/msg16613.html >> http://www.ietf.org/mail-archive/web/manet/current/msg16740.html >> =20 >> The feedback is very helpful and exciting. We thus folded them in the = new revision of the draft as soon as possible, which is now available = today at=20 >> =20 >> http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 >> =20 >> This draft aims for publication as an *Experimental* Track RFC. The = motivation of being an experimental RFC and experiments points have been = illustrated in=20 >> =20 >> = http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 >> =20 >> As a reminder, there are multiple open-source implementations = available for this protocol and they are now running and being tested in = different networks. The multi-path routing has attracted great interest = from both industry and academia.=20 >> =20 >> We believe it's time to publish the protocol as an experimental RFC, = based on the experiences we obtained in the last decade. It would be = great help for the engineers and researchers interested in the = multi-path approach for MANET, and push it to a standard track protocol = eventually.=20 >> =20 >> Therefore, we would like to know your opinion on the draft, and = kindly request a call for WG adoption.=20 >> =20 >> As always, we are looking forward to further comments on the draft = from all the WG participants.=20 >> =20 >> regards >> =20 >> Jiazi >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_188DE98D-DA9A-4301-A85F-FCD8CA875582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 30, 2014, at 16:38, Thomas = Clausen <thomas@thomasclausen.org> = wrote:


On Jul 30, 2014, at 16:37, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.co= m> wrote:

Just to add to the confusion, we have multi-topology, = multipath and multicast, all different.

So are = you saying that we need multi-personalitydisorder to properly follow = them all? :)

Oh, and you forgot = multipoint-relays, abbreviated MPR, not to be confused by MRP from ODMRP = (which means something else)=85. = ;)



Thomas
 
--
Christopher Dearlove
Senior Principal = Engineer, Information Assurance Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales = No: 1996687
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: 30 July 2014 = 14:31
To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; = 'manet-ads'
Subject: [manet] Duh-oh [Was: = request for WG adoption: = draft-yi-manet-olsrv2-multipath]
 
 
*** = WARNING ***

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

In an attempt to prove that I am human I have just = screwed up :-)
 
Thanks to the anonymous benefactor who pointed out = that "multi-path" is not "multi-cast".
 
Feeling a bit = stupid.
 
Please ignore that part of my previous email that = requested PIM WG review.
 
<sigh>
 
Adrian
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: 30 July 2014 = 00:01
To: 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; = 'manet-ads'
Subject: Re: [manet] request for WG = adoption: = draft-yi-manet-olsrv2-multipath
 
Jiazi,
 
I want to thank you for = the responsible approach of labelling this = Experimental.
 
Authors, I would welcome it if you formally asked the = PIM working group to provide multicast review of this = work.
 
Chairs as/when you poll for adoption, please make = sure that that cross-WG review has taken place and that any feedback is = considered.
 
Thanks!
Adrian
 
From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI
Sent: 29 = July 2014 20:30
To: manet; <manet-chairs@tools.ietf.org>; = manet-ads
Subject: request for WG adoption: = draft-yi-manet-olsrv2-multipath
 
Dear chairs, 
 
The draft draft-yi-manet-olsrv2-multipath has been = presented in IETF meeting in = Toronto. 
There = are a lot of constructive comments from the WG during & after the = meeting, detailed in 
 
 
The = feedback is very helpful and exciting. We thus folded them in the new = revision of the draft as soon as possible, which is now available today = at 
 
 
As a = reminder, there are multiple open-source implementations available for = this protocol and they are now running and being tested in different = networks. The multi-path routing has attracted great interest from both = industry and academia. 
 
We believe it's time to publish the protocol as an = experimental RFC, based on the experiences we obtained in the last = decade. It would be great help for the engineers and researchers = interested in the multi-path approach for MANET, and push it to a = standard track protocol = eventually. 
 
Therefore, we would like to know your opinion on the draft, and = kindly request a call for WG = adoption. 
 
As = always, we are looking forward to further comments on the draft from all = the WG participants. 
 
regards
 
Jiazi

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

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

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

= --Apple-Mail=_188DE98D-DA9A-4301-A85F-FCD8CA875582-- From nobody Wed Jul 30 07:50:41 2014 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 5BA6D1A0161 for ; Wed, 30 Jul 2014 07:50: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 codKif3N7a-1 for ; Wed, 30 Jul 2014 07:50:34 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998851A0163 for ; Wed, 30 Jul 2014 07:50:34 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id k15so1435909qaq.27 for ; Wed, 30 Jul 2014 07:50: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=l2BGqZVShoZ6hHaW6HVJJhfv7ZnII4YDyY2lFCncB1o=; b=suteSwV13g12f60bU+P8fLb/CA6ntBi0Kf2KCg6liBNsE3Iw9GgxOsnb/NdafoIw+X 4hNDYPpjugiLt8qXbNERu77yFmqXue5cU5cRgxsXO8fA/gRG0Qg9K7psjGxCd++Npj5R XAi9G2Fs1fZnY+WYAPgx9LmWcrc3dhCd47SDuv5/PgF9Srw0DI2g5uutPWwOCHxOjbYs QuimedACrgRbud7ie6SA6TjbySIi40zY1mw+Z46LuUXnqaiXwg0xSGcWoVN8zg5rJG/H N6jYpyarmI34eYcGnXGRzuBG7YSBht6XKQzzgmDXjyShiKvoKPUzhlK1gYrfnZqJh3Fl tFFg== X-Received: by 10.140.80.165 with SMTP id c34mr6954039qgd.79.1406731833839; Wed, 30 Jul 2014 07:50:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Wed, 30 Jul 2014 07:50:12 -0700 (PDT) In-Reply-To: References: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> <8CF1E618-3420-4636-A1E2-3440D350163C@thomasclausen.org> From: Henning Rogge Date: Wed, 30 Jul 2014 16:50:12 +0200 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BbIh9knX9getH4AcXwC9FNvAiFk Cc: "manet-chairs@tools.ietf.org" , Christopher Dearlove , manet , manet-ads Subject: Re: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] 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, 30 Jul 2014 14:50:36 -0000 On Wed, Jul 30, 2014 at 4:40 PM, Thomas Clausen wrote: > Oh, and you forgot multipoint-relays, abbreviated MPR, not to be confused= by > MRP from ODMRP (which means something else)=E2=80=A6. ;) We also had the discussion if multi-topology is just multi-metric or if it also contains "multiple sub-topologies"... Henning Rogge From nobody Wed Jul 30 07:56:24 2014 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 A74761A0172 for ; Wed, 30 Jul 2014 07:56:12 -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 ja_5q7lMLEqc for ; Wed, 30 Jul 2014 07:56:11 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3777F1A016D for ; Wed, 30 Jul 2014 07:56:11 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so1939325vcb.26 for ; Wed, 30 Jul 2014 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ad44qPZQV83nyrskmLRpUdr90aNnbTRIMlHnqevczMY=; b=2WA+RDJ52lQD2/5Bo8DoQSk9HH3DyolockBBJQQ+E+AP41rnATGCMPsEWnVTt0ubhZ cB6mpw1BDPFJ2L5qRnjxqGvoVGbzjRmWmJi1GpqMsXaSRlf0ywh0xJcvB4lpkh7b4Eo5 SBk0rKz2XwbgdfowSiQBSI5PJbXYd44/raCio= 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 :content-transfer-encoding; bh=ad44qPZQV83nyrskmLRpUdr90aNnbTRIMlHnqevczMY=; b=A1OO5sWRQBBVrK4GorPbaKUI5BEjEXT1uIkQQNsuIeFyDOkCKPO7eRg1fzxKKwMHE3 z7CUaG+WwheqyqXuCSY9H6djbIjkcF78kp4On8yiX4Bsh7nY+oSAr3D6GOo5EDB640hL b2u5QiqE2ZRgqBUdHS8gFziWaL+NKskM3bNzCGbPT+vwceJNIb/1aw9wysSwb2Vg0VGC MauB8EZ5rSYR0mHwZI+Pose2xytSo3RTrCjcduxyHI7vtR68u9+yTyL/qZVavEoI3RyF 9XnM2H5dGtyEFyzHA42Et6RDrm2Hl7tEy9keGM2lAmLm4HEmar2BT33x4OqlSxxYRQfo vyKA== X-Gm-Message-State: ALoCoQlwxEZ7RG+rI5L537zH44BqxmwYgkoHul0sQIkpXXgGsHeuUZpKTnd1eraMjyUIxkfxe328 MIME-Version: 1.0 X-Received: by 10.220.164.198 with SMTP id f6mr5122715vcy.51.1406732170308; Wed, 30 Jul 2014 07:56:10 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 30 Jul 2014 07:56:10 -0700 (PDT) In-Reply-To: References: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> <8CF1E618-3420-4636-A1E2-3440D350163C@thomasclausen.org> Date: Wed, 30 Jul 2014 07:56:10 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/sqC5-p1MId8K2swm7DvBofNJAB4 Cc: "manet-chairs@tools.ietf.org" , Christopher Dearlove , manet , Thomas Clausen , manet-ads Subject: Re: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] 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, 30 Jul 2014 14:56:13 -0000 I think we have enough material for the MULTI-* BoF. ;-) On Wed, Jul 30, 2014 at 7:50 AM, Henning Rogge wrote: > On Wed, Jul 30, 2014 at 4:40 PM, Thomas Clausen > wrote: >> Oh, and you forgot multipoint-relays, abbreviated MPR, not to be confuse= d by >> MRP from ODMRP (which means something else)=E2=80=A6. ;) > > > We also had the discussion if multi-topology is just multi-metric or > if it also contains "multiple sub-topologies"... > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 30 08:25:24 2014 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 BFC5C1A01E4; Wed, 30 Jul 2014 08:25:16 -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 1Vlk6WkhZL8b; Wed, 30 Jul 2014 08:25:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B741A026A; Wed, 30 Jul 2014 08:24:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140730152410.15391.14651.idtracker@ietfa.amsl.com> Date: Wed, 30 Jul 2014 08:24:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W7NI205hburUK-Nx0VFuMmVmhCw Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-ibs-02.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, 30 Jul 2014 15:25:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Identity-Based Signatures for MANET Routing Protocols Author : Christopher Dearlove Filename : draft-ietf-manet-ibs-02.txt Pages : 16 Date : 2014-07-30 Abstract: This document extends [RFC7182], which specifies a framework for, and specific examples of, integrity check values (ICVs) for packets and messages using the generalized packet/message format specified in [RFC5444]. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an identity-based signature, defined according to the ECCSI (Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption) algorithm specified in [RFC6507]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-ibs-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-ibs-02 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 Wed Jul 30 08:31:53 2014 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 AC44B1A0251 for ; Wed, 30 Jul 2014 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 zJIeoH3cV6lX for ; Wed, 30 Jul 2014 08:31:15 -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 CFA6A1A0048 for ; Wed, 30 Jul 2014 08:29:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,764,1400022000"; d="scan'208,217";a="390595710" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jul 2014 16:29:45 +0100 X-IronPort-AV: E=Sophos; i="5.01,764,1400022000"; d="scan'208,217"; a="66660597" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 30 Jul 2014 16:29:56 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 16:29:55 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen Thread-Topic: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs Thread-Index: AQHPqmaMr2jXtWmnY0aFPOP7noXFq5u3IjPggAF+aQCAACA88A== Date: Wed, 30 Jul 2014 15:29:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CB44GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_e4eIIHDNiENRwiJ7aMIRbRQS8k Cc: "" , manet-ads , manet , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 30 Jul 2014 15:31:33 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CB44GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I have submitted an -02 based on Thomas's comments, as I proposed addressin= g them. Any further comments welcome. Technically, nothing has changed. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Clausen [mailto:thomas@thomasclausen.org] Sent: 30 July 2014 15:32 To: Dearlove, Christopher (UK) Cc: manet; ; manet-ads; Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Chris, On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK) > wrote: Some additional comments inline. I plan to put out a new version shortly, b= ut technically all will be unchanged. Comments below, but yes, what I suggest are in the "nits" category, which i= s why I would have been happy to see the current version WGLCed. If you hav= e a new version that addresses my nits, then the WGLC will be even easier f= or me, though.... Below (snipping out the parts where we agree and stuff). From: Thomas Clausen [mailto:thomas@thomasclausen.org] Sent: 28 July 2014 14:19 To: manet; = >; manet-ads Cc: Christopher Dearlove Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs I have, therefore, reviewed the document carefully. In my opinion, the auth= or is right -in my opinion this document is ready for WGLC. Issues: o In my opinion, "Updates 7182" is inappropriate. What= this document does is: (i) only things permissible by = RFC7182, and (ii) makes registration from IAN= A registries set up by RFC7182 (noting, of course, that RF= C7181 doesn't "Updates 5444" when making registrations = for TC messages from the repositories set up by RFC5444 as a cas= e of precedent) Consequently, I believe that the abstract, introduc= tion, and document header, needs updates to reflect that this is not a= n update. Caveat Lector: I have bounced this around with the = author, and I think that the conclusion i= s that we need just a friendly ADs opinion - my understand= ing is that the author "wants this out, but wants = it done right, also", something to which I can but adhere. I believe that we should WG= LC the document. If the AD finds the time to address t= his issue during WGLC, great - otherwise, we can reflect t= his in the "Document Writeup" that the AD will consider w= ith the publication request - as this (imo) is procedural/ed= itorial, and certainly not technical. CMD: On the grounds that the biggest wasted effort is taking out, and then = maybe putting back in, I'm going to leave as-is until our AD comments. But = I'd have done the same if it were the other way round, I'm happy whichever = way this is settled. I'm entirely aligned with you on this point. If we do not get an ADs input = before, we just need to make sure that this will be included in the documen= t write-up and dealt with then. o Introduction, 4th paragraph: Isn't it RFC7183 which does shared-secret-key ICVs?= I just did a quick grep through of "shared" in 7182, and found just a = few mentions, notably setting a side a value for key-id-length in that ca= se. And "secret" is not mentioned anywhere in 7182 CMD: I made an earlier post on this. I think that some improvements in word= ing in the Introduction are indicated. Acknowledged, and that's quite satisfactory. Nits: o Introduction, 1st paragraph: OLD: This specification extends the TLV defi= nitions therein by defining two new cryptograph= ic function code points that allow the use of an identity-based sign= ature (IBS) as an ICV. NEW: This specification defines two new cryp= tographic function code points from within the registries = set up by [RFC7182], that allow the use of an identity-based= signature (IBS) as an ICV. CMD: I want to keep some of what's lost by that edit, so will propose a thi= rd wording. Looking forward to seeing that. o Introduction, 2nd paragraph, 1st line: I took a double-take when I saw the parenthesis "(protocol participant)" - that seems a little odd,= and I am on a crusade against redundant and hard-to-parse terminology ;) I think that what is meant is "router, which is run= ning a routing protocol which is based on RFC5444", so could the d= ocument not say that? In any event, I do not see "protocol participant" d= efined or anywhere else, and so it seems unfortunate to *not* be explicit he= re. CMD: Simply removing the parenthesis removes the intended point, which was = to say that the description assumes that the entities involved are routers - which isn't ac= tually the only possibility using 5444. I'll propose something that borrows from the above to improve i= t. OK, looking forward to seeing that, too. o Introduction, 7th paragraph: Caveating that using this introduces the danger tha= t "if you catch the trusted authority, then you're screwed" is awesome.= I see that this is repeated and reworded in the Security Consi= derations section, and I approve. Now, my question is then, if this should not be sta= ted in the Applicability statement, also? Something to the effect of that th= is applies to networks where all routers can (at some point) be in contact= with the TA (to be keyed), but that this can be off-line - and probabl= y should be off-line since the TA really, really should be protected. It might be argued that the forward-reference to Se= ction 6 captures this - I still think, that a few choice words in th= e applicability statement would help greatly. CMD: I prefer to stick with the forward reference, as I think by the time y= ou've said enough, you've duplicated half of Section 6. But adding some wor= ds to say particularly regarding the role of the TA/KMS makes sense. I think that we are aligned, that that's what the last sentence in my comme= nt seeks to capture. So, I look forward to seeing your proposal to this, to= o. o Introduction, 9th paragraph: Any [academic? otherwise] work that you can cite to= quantify the computational load? I asked a crypto-wonk-colleague= , who said something to the effect of "the document is perfect= ly right, on this point, but I do not have a paper just off the top o= f my head with interesting data to offer". For that reason alone, = it'd be interesting if you did ;) CMD: See previous comments. Trying Google Scholar with ECCSI elliptic curve= gets a very small number of hits, none useful here. I've asked around, but I am not hopeful. Will let you know if I get somethi= ng citable - most I spoke to said "this aligns with my intuition/experience= /*" though. OLD: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined there) uses the hash function w= ithin the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. NEW: o The ICV is not calculated as cryptographic-fu= nction(hash- function(content)) as defined in [RFC7182], = but (like the HMAC ICVs defined in [RFC7182]) uses the hash fun= ction within the cryptographic function. The option "none" i= s not permitted for hash-function, and the hash function must ha= ve a known fixed length of N octets, as specified in Section = 4.2. CMD: I could live with either, but will make the change. I think it makes it clearer, so thank you for that. o While we are at it, it it crystal-clear to everybody= that "Section 4.2" in the bullet above is to *this* document, as not RFC7= 182? CMD: I'm going to assume it is. I would always write Section X.Y of [Z] (or= similar) if making an external reference. OK, this was a throw-away comment, not important o Section 4.3, 2nd bullet There's a LOT of information embedded in this bulle= t, and reading it suggests that it, readability-wise, might benefit f= rom embedding a: ... ... CMD: I'm including to be slightly less radical (and I'm not a fan on hangin= g text). But I will create another level. Thank you, that will work nicely. o IANA Considerations: Given recent experiences in this WG and with reques= ting IANA registrations, may I suggest that this be modified = to say, more explicitly: 1) IANA is requested to reserve= ECCSI with description ___ and reference "This Specifi= cation" 2) IANA is requested to reserve= ECCSI-ADDR.... (similar) 3) The "Cryptographic Functions= Registry", defined in [RFC7182], with these regis= trations made, will look like Table 1, which replace= s Table 11 of [RFC7182] 4) Obviously, include in Table = 1 the registrations from RFC7182. 5) That this document does not = modify the expert review guidelines as set fo= rth in RFC7182 for future allocations. CMD: I think this comes under the heading of hand-holding IANA more than I = would feel ought to be necessary. Except sometimes it has been. But this is= a straightforward case, so while I agree that making it more explicit that= this is a request for two new code points, I'm not going to repeat the ful= l table from 7182 unless IANA really show they need hand-holding. Our previ= ous cases where we had to repeat a whole table were a bit messier. But givi= ng the exact name for the table as on IANA's website is advisable. True, but...there's perhaps something to be said for "the table being as co= mplete as possible" for the reader, also? Well, your call, of course. Once a new version hits the servers, I'll let you know if I see any pending= nits. Cheers, Thomas ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CB44GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I have submitted an -02 b= ased on Thomas’s comments, as I proposed addressing them. Any further= comments welcome.

 <= /p>

Technically, nothing has = changed.

 <= /p>

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

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

 <= /p>

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 30 July 2014 15:32
To: Dearlove, Christopher (UK)
Cc: manet; <manet-chairs@tools.ietf.org>; manet-ads; Christoph= er Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs<= o:p>

 

 

*** WARNING ***=

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

Chris,

 

 

On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK= ) <chris.dearlove@baesy= stems.com> wrote:



Some additional comments = inline. I plan to put out a new version shortly, but technically all will b= e unchanged.

 

Comments below, but yes, what I suggest are in the &= #8220;nits” category, which is why I would have been happy to see the= current version WGLCed. If you have a new version that addresses my nits, = then the WGLC will be even easier for me, though....

 

Below (snipping out the parts where we agree and stu= ff).

 

From: Thomas Clausen [mailto:thomas@thomasclausen.org] 
Sent: 28 July 2014= 14:19
To: manet; <ma= net-chairs@tools.ietf.org>; manet-ads
Cc: Christopher De= arlove
Subject: Ready for= WGLC: Advancing draft-ietf-manet-ibs

 

 

<SNIP>



I have, therefore, reviewed the document carefully. = In my opinion, the author is right —in my opinion this doc= ument is ready for WGLC.

 

<SNIP>



Issues:

 

   &nb= sp;        o  &nb= sp;       In my opinion, “Updates 7182” is inapprop= riate. What this document does is:

   &nb= sp;            =             &nb= sp;       (i)        <= /span> only things permissible by RFC7182, and 

   &nb= sp;            =             &nb= sp;       (ii)        makes registration from IANA registries set up by RFC7182

   &nb= sp;            =             &nb= sp;            =        (noting, of course, that RFC7181 doesn’t “Up= dates 5444” 

   &nb= sp;            =             &nb= sp;          &nbs= p;         when making registrations for TC messages from the repositories 

   &nb= sp;            =             &nb= sp;            =         set up by RFC5444 as a case of precedent)

   &nb= sp;            =         Consequently, I believe that the abstract, introdu= ction, and document 

   &nb= sp;            =         header, needs updates to reflect that this is not = an update.

   &nb= sp;            =        

   &nb= sp;            =         Caveat Lector: I have bounced this around with the= author, and I 

   &nb= sp;            =             &nb= sp;            =        think that the conclusion is that we need just a friendl= y 

   &nb= sp;            =             &nb= sp;            =        ADs opinion — my understanding is that the author<= o:p>

   &nb= sp;            =             &nb= sp;            =        “wants this out, but wants it done right, alsoR= 21;, something

   &nb= sp;            =             &nb= sp;            =        to which I can but adhere.

   &nb= sp;            =        

   &nb= sp;            =             &nb= sp;            =        I believe that we should WGLC the document. If the AD

   &nb= sp;            =             &nb= sp;            =        finds the time to address this issue during WGLC, great = -

   &nb= sp;            =             &nb= sp;            =        otherwise, we can reflect this in the “Document Wr= iteup”

   &nb= sp;            =             &nb= sp;            =        that the AD will consider with the publication request &= #8212; as

   &nb= sp;            =             &nb= sp;            =        this (imo) is procedural/editorial, and certainly not te= chnical.

 <= /p>

CMD: On the grounds that = the biggest wasted effort is taking out, and then maybe putting back in, I&= #8217;m going to leave as-is until our AD comments. But I’d have done the same if it were the other way round, I’m happy whichever wa= y this is settled. 

 

I’m entirely aligned with you on this point. I= f we do not get an ADs input before, we just need to make sure that this wi= ll be included in the document write-up and dealt with then.

 



   &nb= sp;        o  &nb= sp;       Introduction, 4th paragraph:

 

   &nb= sp;            =         Isn’t it RFC7183 which does shared-secret-ke= y ICVs? I just did a quick

   &nb= sp;            =         grep through of “shared” in 7182, and = found just a few mentions, notably

   &nb= sp;            =         setting a side a value for key-id-length in t= hat case. And “secret” is not

   &nb= sp;            =         mentioned anywhere in 7182

 

CMD: I made an earlier po= st on this. I think that some improvements in wording in the Introduction a= re indicated.

 <= /p>

 

Acknowledged, and that’s quite satisfactory.



 

Nits:

   &nb= sp;        o  &nb= sp;       Introduction, 1st paragraph:

   &nb= sp;            =         OLD:

   &nb= sp;            =             &nb= sp;       This specification extends the TLV definitions

   &nb= sp;            =             &nb= sp;       therein by defining two new cryptographic function co= de points that

   &nb= sp;            =             &nb= sp;       allow the use of an identity-based signature (IBS) as= an ICV.

 

   &nb= sp;            =         NEW:

   &nb= sp;            =             &nb= sp;       This specification defines two new cryptographic func= tion 

   &nb= sp;            =             &nb= sp;       code points from within the registries set up by [RFC= 7182], 

   &nb= sp;            =             &nb= sp;       that allow the use of an identity-based signature (IB= S) as an ICV.

 

CMD: I want to keep some = of what’s lost by that edit, so will propose a third wording.<= o:p>

 

Looking forward to seeing that.



 <= /p>

   &nb= sp;        o  &nb= sp;       Introduction, 2nd paragraph, 1st line:

   &nb= sp;            =         I took a double-take when I saw the parenthesis&nb= sp;

   &nb= sp;            =         “(protocol participant)” — that = seems a little odd, and I am on a crusade

   &nb= sp;            =         against redundant and hard-to-parse terminology ;)=

 

   &nb= sp;            =         I think that what is meant is “router, which= is running a routing 

   &nb= sp;            =         protocol which is based on RFC5444”, so coul= d the document not say

   &nb= sp;            =         that?

 

   &nb= sp;            =         In any event, I do not see “protocol partici= pant” defined or anywhere else,

   &nb= sp;            =         and so it seems unfortunate to *not* be explicit h= ere.

 

CMD: Simply removing the = parenthesis removes the intended point, which was to say that the

description assumes that = the entities involved are routers – which isn’t actually the on= ly possibility

using 5444. I’ll pr= opose something that borrows from the above to improve it.

 

OK, looking forward to seeing that, too.<= /p>

 

<SNIP>

 

 

   &nb= sp;        o  &nb= sp;       Introduction, 7th paragraph:

   &nb= sp;            =         Caveating that using this introduces the danger th= at “if you catch the 

   &nb= sp;            =         trusted authority, then you’re screwed”= ; is awesome. I see that 

   &nb= sp;            =         this is repeated and reworded in the Security Cons= iderations section,

   &nb= sp;            =         and I approve. 

 

   &nb= sp;            =         Now, my question is then, if this should not be st= ated in the Applicability 

   &nb= sp;            =         statement, also? Something to the effect of that t= his applies to networks

   &nb= sp;            =         where all routers can (at some point) be in contac= t with the TA (to be

   &nb= sp;            =         keyed), but that this can be off-line — and = probably should be off-line

   &nb= sp;            =         since the TA really, really should be protected.

 

   &nb= sp;            =         It might be argued that the forward-reference to S= ection 6 captures

   &nb= sp;            =         this — I still think, that a few choice word= s in the applicability statement

   &nb= sp;            =         would help greatly.

 

CMD: I prefer to stick wi= th the forward reference, as I think by the time you’ve said enough, = you’ve duplicated half of Section 6. But adding some words to say particularly regarding the role of the TA/KMS makes sense.=

 

I think that we are aligned, that that’s what = the last sentence in my comment seeks to capture. So, I look forward to see= ing your proposal to this, too.



 <= /p>

   &nb= sp;        o  &nb= sp;       Introduction, 9th paragraph:

   &nb= sp;            =         Any [academic? otherwise] work that you can cite t= o quantify the 

   &nb= sp;            =         computational load? I asked a crypto-wonk-colleagu= e, who said

   &nb= sp;            =         something to the effect of “the document is = perfectly right, on this

   &nb= sp;            =         point, but I do not have a paper just off the= top of my head with 

   &nb= sp;            =         interesting data to offer”. For that reason = alone, it’d be interesting 

   &nb= sp;            =         if you did ;)

 <= /p>

CMD: See previous comment= s. Trying Google Scholar with ECCSI elliptic curve gets a very small number= of hits, none useful here.

 

I’ve asked around, but I am not hopeful. Will = let you know if I get something citable — most I spoke to said “= ;this aligns with my intuition/experience/*” though.

 

<SNIP>



   &nb= sp;            =         OLD:

   &nb= sp;            =            o  The ICV is not calculated as = cryptographic-function(hash-

   &nb= sp;            =                function(content)) as d= efined in [RFC7182], but (like the HMAC

   &nb= sp;            =                ICVs defined there) use= s the hash function within the

   &nb= sp;            =                cryptographic function.=  The option "none" is not permitted for

   &nb= sp;            =                hash-function, and the = hash function must have a known fixed

   &nb= sp;            =                length of N octets, as = specified in Section 4.2.

 

   &nb= sp;            =         NEW:

   &nb= sp;            =            o  The ICV is not calculated as = cryptographic-function(hash-

   &nb= sp;            =                function(content)) as d= efined in [RFC7182], but (like the HMAC

   &nb= sp;            =                ICVs defined in [RFC718= 2]) uses the hash function within the

   &nb= sp;            =                cryptographic function.=  The option "none" is not permitted for

   &nb= sp;            =                hash-function, and the = hash function must have a known fixed

   &nb= sp;             = ;              length of N octets, as speci= fied in Section 4.2.

 <= /p>

CMD: I could live with ei= ther, but will make the change.

 

I think it makes it clearer, so thank you for that.<= o:p>



 

   &nb= sp;        o  &nb= sp;       While we are at it, it it crystal-clear to everybody = that “Section 4.2” in

   &nb= sp;            =         the bullet above is to *this* document, as not RFC= 7182?

 <= /p>

CMD: I’m going to a= ssume it is. I would always write Section X.Y of [Z] (or similar) if making= an external reference.

 

OK, this was a throw-away comment, not important

 

   &nb= sp;        o  &nb= sp;       Section 4.3, 2nd bullet

   &nb= sp;            =         There’s a LOT of information embedded in thi= s bullet, and reading it

   &nb= sp;            =         suggests that it, readability-wise, might benefit = from embedding a:

   &nb= sp;            =             &nb= sp;       <list style=3D“hanging”>=

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Packet TLVs”>…<= ;/t>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Message TLVs”>…&l= t;/t>

   &nb= sp;            =             &nb= sp;            =        <t hangText=3D“Address Block TLVs”>= 230;</t>

   &nb= sp;            =             &nb= sp;       </list>

 

CMD: I’m including = to be slightly less radical (and I’m not a fan on hanging text). But = I will create another level.

 

Thank you, that will work nicely.

 

 <= /p>

   &nb= sp;        o  &nb= sp;       IANA Considerations:

 

   &nb= sp;            =         Given recent experiences in this WG and with reque= sting IANA 

   &nb= sp;            =         registrations, may I suggest that this be modified= to say, more

   &nb= sp;            =         explicitly:

 

   &nb= sp;            =             &nb= sp;       1)   &n= bsp;    &n= bsp;IANA is requested to reserve ECCSI with description ___ 

   &nb= sp;            =             &nb= sp;            =        and reference “This Specification”

 

   &nb= sp;            =             &nb= sp;       2)   &n= bsp;    &n= bsp;IANA is requested to reserve ECCSI-ADDR…. (similar)

 

   &nb= sp;            =             &nb= sp;       3)   &n= bsp;    &n= bsp;The “Cryptographic Functions Registry”, defined in 

   &nb= sp;            =             &nb= sp;            =        [RFC7182], with these registrations made, will look=

   &nb= sp;            =             &nb= sp;            =        like Table 1, which replaces Table 11 of [RFC7182]<= /o:p>

 

   &nb= sp;            =             &nb= sp;       4)   &n= bsp;    &n= bsp;Obviously, include in Table 1 the registrations from

   &nb= sp;            =             &nb= sp;            =        RFC7182.

 

   &nb= sp;            =             &nb= sp;       5)   &n= bsp;    &n= bsp;That this document does not modify the expert

   &nb= sp;            =             &nb= sp;            =        review guidelines as set forth in RFC7182 for=

   &nb= sp;            =             &nb= sp;            =        future allocations.

 

CMD: I think this comes u= nder the heading of hand-holding IANA more than I would feel ought to be ne= cessary. Except sometimes it has been. But this is a straightforward case, so while I agree that making it more explicit that this is a request= for two new code points, I’m not going to repeat the full table from= 7182 unless IANA really show they need hand-holding. Our previous cases wh= ere we had to repeat a whole table were a bit messier. But giving the exact name for the table as on IANA’s = website is advisable.

 <= /p>

 

True, but…there’s perhaps something to b= e said for “the table being as complete as possible” for the re= ader, also? Well, your call, of course.

 

Once a new version hits the servers, I’ll let = you know if I see any pending nits.

 

Cheers,

 

Thomas

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1CB44GLKXM0002VGREEN_-- From nobody Wed Jul 30 09:28:17 2014 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 440CE1A027C for ; Wed, 30 Jul 2014 09:28:15 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 d2qwZu-IURIQ for ; Wed, 30 Jul 2014 09:28:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3B21A0267 for ; Wed, 30 Jul 2014 09:28:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AC7E324753B; Wed, 30 Jul 2014 09:28:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B885B24027E; Wed, 30 Jul 2014 09:28:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-BC0F39AA-D9A9-4342-BBC5-3A58B44F880A Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Wed, 30 Jul 2014 18:27:58 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: "Dearlove, Christopher (UK)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FFducUCtC_EdVoQeuUn8o-n9-Do Cc: "" , manet , manet-ads , Christopher Dearlove Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs 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, 30 Jul 2014 16:28:15 -0000 --Apple-Mail-BC0F39AA-D9A9-4342-BBC5-3A58B44F880A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris, Wow, you're quick ;) Thanks for addressing my comments. I am perfectly happy with this -02, and h= ave no new comments, nits, and issues to raise.=20 I recommend that this I-D be WGLCed promptly Outstanding, for me, is only the Updates/not-Updates issue -- which is a tri= vial fix once an AD has provided due guidance as to what is "the right thing= to do". Best, Thomas Sent from my iPad > On 30 Jul 2014, at 17:29, "Dearlove, Christopher (UK)" wrote: >=20 > I have submitted an -02 based on Thomas=E2=80=99s comments, as I proposed a= ddressing them. Any further comments welcome. > =20 > Technically, nothing has changed. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 30 July 2014 15:32 > To: Dearlove, Christopher (UK) > Cc: manet; ; manet-ads; Christopher Dearlove > Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Consider carefully whether you should click on any links, open any attachm= ents or reply. > For information regarding Red Flags that you can look out for in emails yo= u receive, click here. > If you feel the email is suspicious, please follow this process. >=20 > Chris, > =20 > =20 > On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK) wrote: >=20 >=20 > Some additional comments inline. I plan to put out a new version shortly, b= ut technically all will be unchanged. > =20 > Comments below, but yes, what I suggest are in the =E2=80=9Cnits=E2=80=9D c= ategory, which is why I would have been happy to see the current version WGL= Ced. If you have a new version that addresses my nits, then the WGLC will be= even easier for me, though.... > =20 > Below (snipping out the parts where we agree and stuff). > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 28 July 2014 14:19 > To: manet; ; manet-ads > Cc: Christopher Dearlove > Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs > =20 > =20 > >=20 >=20 > I have, therefore, reviewed the document carefully. In my opinion, the aut= hor is right =E2=80=94in my opinion this document is ready for WGLC. > =20 > >=20 >=20 > Issues: > =20 > o In my opinion, =E2=80=9CUpdates 7182=E2=80=9D is in= appropriate. What this document does is: > (i) only things permissible by= RFC7182, and=20 > (ii) makes registration from IA= NA registries set up by RFC7182 > (noting, of course, that R= FC7181 doesn=E2=80=99t =E2=80=9CUpdates 5444=E2=80=9D=20 > when making registrations= for TC messages from the repositories=20 > set up by RFC5444 as a ca= se of precedent) > Consequently, I believe that the abstract, introdu= ction, and document=20 > header, needs updates to reflect that this is not a= n update. > =20 > Caveat Lector: I have bounced this around with the= author, and I=20 > think that the conclusion i= s that we need just a friendly=20 > ADs opinion =E2=80=94 my u= nderstanding is that the author > =E2=80=9Cwants this out, b= ut wants it done right, also=E2=80=9D, something > to which I can but adhere.= > =20 > I believe that we should W= GLC the document. If the AD > finds the time to address t= his issue during WGLC, great - > otherwise, we can reflect t= his in the =E2=80=9CDocument Writeup=E2=80=9D > that the AD will consider w= ith the publication request =E2=80=94 as > this (imo) is procedural/e= ditorial, and certainly not technical. > =20 > CMD: On the grounds that the biggest wasted effort is taking out, and then= maybe putting back in, I=E2=80=99m going to leave as-is until our AD commen= ts. But I=E2=80=99d have done the same if it were the other way round, I=E2=80= =99m happy whichever way this is settled.=20 > =20 > I=E2=80=99m entirely aligned with you on this point. If we do not get an A= Ds input before, we just need to make sure that this will be included in the= document write-up and dealt with then. > =20 >=20 >=20 > o Introduction, 4th paragraph: > =20 > Isn=E2=80=99t it RFC7183 which does shared-secret-= key ICVs? I just did a quick > grep through of =E2=80=9Cshared=E2=80=9D in 7182, a= nd found just a few mentions, notably > setting a side a value for key-id-length in that c= ase. And =E2=80=9Csecret=E2=80=9D is not > mentioned anywhere in 7182 > =20 > CMD: I made an earlier post on this. I think that some improvements in wor= ding in the Introduction are indicated. > =20 > =20 > Acknowledged, and that=E2=80=99s quite satisfactory. >=20 >=20 > =20 > Nits: > o Introduction, 1st paragraph: > OLD: > This specification extends the TLV def= initions > therein by defining two new cryptograp= hic function code points that > allow the use of an identity-based sig= nature (IBS) as an ICV. > =20 > NEW: > This specification defines two new cry= ptographic function=20 > code points from within the registries= set up by [RFC7182],=20 > that allow the use of an identity-base= d signature (IBS) as an ICV. > =20 > CMD: I want to keep some of what=E2=80=99s lost by that edit, so will prop= ose a third wording. > =20 > Looking forward to seeing that. >=20 >=20 > =20 > o Introduction, 2nd paragraph, 1st line: > I took a double-take when I saw the parenthesis=20= > =E2=80=9C(protocol participant)=E2=80=9D =E2=80=94= that seems a little odd, and I am on a crusade > against redundant and hard-to-parse terminology ;)= > =20 > I think that what is meant is =E2=80=9Crouter, whi= ch is running a routing=20 > protocol which is based on RFC5444=E2=80=9D, so co= uld the document not say > that? > =20 > In any event, I do not see =E2=80=9Cprotocol parti= cipant=E2=80=9D defined or anywhere else, > and so it seems unfortunate to *not* be explicit h= ere. > =20 > CMD: Simply removing the parenthesis removes the intended point, which was= to say that the > description assumes that the entities involved are routers =E2=80=93 which= isn=E2=80=99t actually the only possibility > using 5444. I=E2=80=99ll propose something that borrows from the above to i= mprove it. > =20 > OK, looking forward to seeing that, too. > =20 > > =20 > =20 > o Introduction, 7th paragraph: > Caveating that using this introduces the danger th= at =E2=80=9Cif you catch the=20 > trusted authority, then you=E2=80=99re screwed=E2=80= =9D is awesome. I see that=20 > this is repeated and reworded in the Security Cons= iderations section, > and I approve.=20 > =20 > Now, my question is then, if this should not be st= ated in the Applicability=20 > statement, also? Something to the effect of that t= his applies to networks > where all routers can (at some point) be in contac= t with the TA (to be > keyed), but that this can be off-line =E2=80=94 an= d probably should be off-line > since the TA really, really should be protected. > =20 > It might be argued that the forward-reference to S= ection 6 captures > this =E2=80=94 I still think, that a few choice wo= rds in the applicability statement > would help greatly. > =20 > CMD: I prefer to stick with the forward reference, as I think by the time y= ou=E2=80=99ve said enough, you=E2=80=99ve duplicated half of Section 6. But a= dding some words to say particularly regarding the role of the TA/KMS makes s= ense. > =20 > I think that we are aligned, that that=E2=80=99s what the last sentence in= my comment seeks to capture. So, I look forward to seeing your proposal to t= his, too. >=20 >=20 > =20 > o Introduction, 9th paragraph: > Any [academic? otherwise] work that you can cite t= o quantify the=20 > computational load? I asked a crypto-wonk-colleagu= e, who said > something to the effect of =E2=80=9Cthe document i= s perfectly right, on this > point, but I do not have a paper just off the top o= f my head with=20 > interesting data to offer=E2=80=9D. For that reaso= n alone, it=E2=80=99d be interesting=20 > if you did ;) > =20 > CMD: See previous comments. Trying Google Scholar with ECCSI elliptic curv= e gets a very small number of hits, none useful here. > =20 > I=E2=80=99ve asked around, but I am not hopeful. Will let you know if I ge= t something citable =E2=80=94 most I spoke to said =E2=80=9Cthis aligns with= my intuition/experience/*=E2=80=9D though. > =20 > >=20 >=20 > OLD: > o The ICV is not calculated as cryptographic-f= unction(hash- > function(content)) as defined in [RFC7182],= but (like the HMAC > ICVs defined there) uses the hash function w= ithin the > cryptographic function. The option "none" i= s not permitted for > hash-function, and the hash function must h= ave a known fixed > length of N octets, as specified in Section= 4.2. > =20 > NEW: > o The ICV is not calculated as cryptographic-f= unction(hash- > function(content)) as defined in [RFC7182],= but (like the HMAC > ICVs defined in [RFC7182]) uses the hash fu= nction within the > cryptographic function. The option "none" i= s not permitted for > hash-function, and the hash function must h= ave a known fixed > length of N octets, as specified in Section= 4.2. > =20 > CMD: I could live with either, but will make the change. > =20 > I think it makes it clearer, so thank you for that. >=20 >=20 > =20 > o While we are at it, it it crystal-clear to everybod= y that =E2=80=9CSection 4.2=E2=80=9D in > the bullet above is to *this* document, as not RFC= 7182? > =20 > CMD: I=E2=80=99m going to assume it is. I would always write Section X.Y o= f [Z] (or similar) if making an external reference. > =20 > OK, this was a throw-away comment, not important > =20 >=20 > o Section 4.3, 2nd bullet > There=E2=80=99s a LOT of information embedded in t= his bullet, and reading it > suggests that it, readability-wise, might benefit f= rom embedding a: > > =E2=80=A6 > =E2=80=A6 > =E2=80=A6 > > =20 > CMD: I=E2=80=99m including to be slightly less radical (and I=E2=80=99m no= t a fan on hanging text). But I will create another level. > =20 > Thank you, that will work nicely. > =20 > =20 > o IANA Considerations: > =20 > Given recent experiences in this WG and with reque= sting IANA=20 > registrations, may I suggest that this be modified= to say, more > explicitly: > =20 > 1) IANA is requested to reserv= e ECCSI with description ___=20 > and reference =E2=80=9CThi= s Specification=E2=80=9D > =20 > 2) IANA is requested to reserv= e ECCSI-ADDR=E2=80=A6. (similar) > =20 > 3) The =E2=80=9CCryptographic = Functions Registry=E2=80=9D, defined in=20 > [RFC7182], with these regi= strations made, will look > like Table 1, which replac= es Table 11 of [RFC7182] > =20 > 4) Obviously, include in Table= 1 the registrations from > RFC7182. > =20 > 5) That this document does not= modify the expert > review guidelines as set f= orth in RFC7182 for > future allocations. > =20 > CMD: I think this comes under the heading of hand-holding IANA more than I= would feel ought to be necessary. Except sometimes it has been. But this is= a straightforward case, so while I agree that making it more explicit that t= his is a request for two new code points, I=E2=80=99m not going to repeat th= e full table from 7182 unless IANA really show they need hand-holding. Our p= revious cases where we had to repeat a whole table were a bit messier. But g= iving the exact name for the table as on IANA=E2=80=99s website is advisable= . > =20 > =20 > True, but=E2=80=A6there=E2=80=99s perhaps something to be said for =E2=80=9C= the table being as complete as possible=E2=80=9D for the reader, also? Well,= your call, of course. > =20 > Once a new version hits the servers, I=E2=80=99ll let you know if I see an= y pending nits. > =20 > Cheers, > =20 > Thomas > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-BC0F39AA-D9A9-4342-BBC5-3A58B44F880A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Chris,

Wow, y= ou're quick ;)

Thanks for addressing my comments. I= am perfectly happy with this -02, and have no new comments, nits, and issue= s to raise. 

I recommend that this I-D b= e WGLCed promptly

Outstanding= , for me, is only the Updates/not-Updates issue -- which is a trivial fix on= ce an AD has provided due guidance as to what is "the right thing to do".

Best,

Thomas

<= /div>
Sent from my iPad

On 30 Jul 2014, at 17:29, "Dearlov= e, Christopher (UK)" <ch= ris.dearlove@baesystems.com> wrote:

=

I have submitted an -02 bas= ed on Thomas=E2=80=99s comments, as I proposed addressing them. Any further c= omments welcome.

 

Technically, nothing has ch= anged.

 

= --

= Christopher Dearlove

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

=

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

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

 

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 30 July 2014 15:32
To: Dearlove, Christopher (UK)
Cc: manet; <manet-c= hairs@tools.ietf.org>; manet-ads; Christopher Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs

 

 

*** WARNING ***

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

Chris,

 

 

On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK)= <chris.dearlove@baesyst= ems.com> wrote:



Some additional comments in= line. I plan to put out a new version shortly, but technically all will be u= nchanged.

 

Comments below, but yes, what I suggest are in the =E2= =80=9Cnits=E2=80=9D category, which is why I would have been happy to see th= e current version WGLCed. If you have a new version that addresses my nits, t= hen the WGLC will be even easier for me, though....

 

Below (snipping out the parts where we agree and stuf= f).

 

From: = Thomas Clausen [mailto:thomas@thomasclausen.org] 
Sent: 28 July 2014 1= 4:19
To: manet; <mane= t-chairs@tools.ietf.org>; manet-ads
Cc: Christopher Dea= rlove
Subject: Ready for W= GLC: Advancing draft-ietf-manet-ibs

 

 

<SNIP>



I have, therefore, reviewed the document carefully. I= n my opinion, the author is right =E2=80=94in my opinion this doc= ument is ready for WGLC.

 

<SNIP>



Issues:

 

   &nbs= p;        o   =        In my opinion, =E2=80=9CUpdates 7182=E2=80=9D is inappropr= iate. What this document does is:

   &nbs= p;            &n= bsp;            =        (i)        =  only things permissible by RFC7182, and 

   &nbs= p;            &n= bsp;            =        (ii)        makes registration from IANA registries set up by RFC7182

   &nbs= p;            &n= bsp;            =             &nbs= p;      (noting, of course, that RFC7181 doesn=E2=80=99t =E2=80=9CUpda= tes 5444=E2=80=9D 

   &nbs= p;            &n= bsp;            =            &nb= sp;        when making registrations for TC messages from the repositories 

   &nbs= p;            &n= bsp;            =             &nbs= p;       set up by RFC5444 as a case of precedent)

=

   &nbs= p;            &n= bsp;       Consequently, I believe that the abstract, introductio= n, and document 

   &nbs= p;            &n= bsp;       header, needs updates to reflect that this is not an u= pdate.

   &nbs= p;            &n= bsp;      

   &nbs= p;            &n= bsp;       Caveat Lector: I have bounced this around with the aut= hor, and I 

   &nbs= p;            &n= bsp;            =             &nbs= p;      think that the conclusion is that we need just a friendly = ;

   &nbs= p;            &n= bsp;            =             &nbs= p;      ADs opinion =E2=80=94 my understanding is that the author=

   &nbs= p;            &n= bsp;            =             &nbs= p;      =E2=80=9Cwants this out, but wants it done right, also=E2=80=9D= , something

   &nbs= p;            &n= bsp;            =             &nbs= p;      to which I can but adhere.

   &nbs= p;            &n= bsp;      

   &nbs= p;            &n= bsp;            =             &nbs= p;      I believe that we should WGLC the document. If the AD

   &nbs= p;            &n= bsp;            =             &nbs= p;      finds the time to address this issue during WGLC, great -=

   &nbs= p;            &n= bsp;            =             &nbs= p;      otherwise, we can reflect this in the =E2=80=9CDocument Writeu= p=E2=80=9D

   &nbs= p;            &n= bsp;            =             &nbs= p;      that the AD will consider with the publication request =E2=80=94= as

   &nbs= p;            &n= bsp;            =             &nbs= p;      this (imo) is procedural/editorial, and certainly not technica= l.

 

CMD: On the grounds that th= e biggest wasted effort is taking out, and then maybe putting back in, I=E2=80= =99m going to leave as-is until our AD comments. But I=E2=80=99d have done the same if it were the other way round, I=E2=80=99m happy whichever w= ay this is settled. 

 

I=E2=80=99m entirely aligned with you on this point. I= f we do not get an ADs input before, we just need to make sure that this wil= l be included in the document write-up and dealt with then.

 



   &nbs= p;        o   =        Introduction, 4th paragraph:

 

   &nbs= p;            &n= bsp;       Isn=E2=80=99t it RFC7183 which does shared-secret-key I= CVs? I just did a quick

   &nbs= p;            &n= bsp;       grep through of =E2=80=9Cshared=E2=80=9D in 7182, and f= ound just a few mentions, notably

   &nbs= p;            &n= bsp;       setting a side a value for key-id-length in that c= ase. And =E2=80=9Csecret=E2=80=9D is not

   &nbs= p;            &n= bsp;       mentioned anywhere in 7182

 

CMD: I made an earlier post= on this. I think that some improvements in wording in the Introduction are i= ndicated.

 

 

Acknowledged, and that=E2=80=99s quite satisfactory.<= o:p>



 

Nits:

   &nbs= p;        o   =        Introduction, 1st paragraph:

   &nbs= p;            &n= bsp;       OLD:

   &nbs= p;            &n= bsp;            =        This specification extends the TLV definitions<= /p>

   &nbs= p;            &n= bsp;            =        therein by defining two new cryptographic function code po= ints that

   &nbs= p;            &n= bsp;            =        allow the use of an identity-based signature (IBS) as an I= CV.

 

   &nbs= p;            &n= bsp;       NEW:

   &nbs= p;            &n= bsp;            =        This specification defines two new cryptographic function&= nbsp;

   &nbs= p;            &n= bsp;            =        code points from within the registries set up by [RFC7182]= , 

   &nbs= p;            &n= bsp;            =        that allow the use of an identity-based signature (IBS) as= an ICV.

 

CMD: I want to keep some of= what=E2=80=99s lost by that edit, so will propose a third wording.

 

Looking forward to seeing that.



 

   &nbs= p;        o   =        Introduction, 2nd paragraph, 1st line:

   &nbs= p;            &n= bsp;       I took a double-take when I saw the parenthesis <= o:p>

   &nbs= p;            &n= bsp;       =E2=80=9C(protocol participant)=E2=80=9D =E2=80=94 tha= t seems a little odd, and I am on a crusade

   &nbs= p;            &n= bsp;       against redundant and hard-to-parse terminology ;)

 

   &nbs= p;            &n= bsp;       I think that what is meant is =E2=80=9Crouter, which i= s running a routing 

   &nbs= p;            &n= bsp;       protocol which is based on RFC5444=E2=80=9D, so could t= he document not say

   &nbs= p;            &n= bsp;       that?

 

   &nbs= p;            &n= bsp;       In any event, I do not see =E2=80=9Cprotocol participa= nt=E2=80=9D defined or anywhere else,

   &nbs= p;            &n= bsp;       and so it seems unfortunate to *not* be explicit here.=

 

CMD: Simply removing the pa= renthesis removes the intended point, which was to say that the<= /o:p>

description assumes that th= e entities involved are routers =E2=80=93 which isn=E2=80=99t actually the o= nly possibility

using 5444. I=E2=80=99ll pr= opose something that borrows from the above to improve it.=

 

OK, looking forward to seeing that, too.

 

<SNIP>

 

 

   &nbs= p;        o   =        Introduction, 7th paragraph:

   &nbs= p;            &n= bsp;       Caveating that using this introduces the danger that =E2= =80=9Cif you catch the 

   &nbs= p;            &n= bsp;       trusted authority, then you=E2=80=99re screwed=E2=80=9D= is awesome. I see that 

   &nbs= p;            &n= bsp;       this is repeated and reworded in the Security Consider= ations section,

   &nbs= p;            &n= bsp;       and I approve. 

 

   &nbs= p;            &n= bsp;       Now, my question is then, if this should not be stated= in the Applicability 

   &nbs= p;            &n= bsp;       statement, also? Something to the effect of that this a= pplies to networks

   &nbs= p;            &n= bsp;       where all routers can (at some point) be in contact wi= th the TA (to be

   &nbs= p;            &n= bsp;       keyed), but that this can be off-line =E2=80=94 and pr= obably should be off-line

   &nbs= p;            &n= bsp;       since the TA really, really should be protected.<= /o:p>

 

   &nbs= p;            &n= bsp;       It might be argued that the forward-reference to Secti= on 6 captures

   &nbs= p;            &n= bsp;       this =E2=80=94 I still think, that a few choice words i= n the applicability statement

   &nbs= p;            &n= bsp;       would help greatly.

 

CMD: I prefer to stick with= the forward reference, as I think by the time you=E2=80=99ve said enough, y= ou=E2=80=99ve duplicated half of Section 6. But adding some words to say particularly regarding the role of the TA/KMS makes sense.<= /o:p>

 

I think that we are aligned, that that=E2=80=99s what= the last sentence in my comment seeks to capture. So, I look forward to see= ing your proposal to this, too.



 

   &nbs= p;        o   =        Introduction, 9th paragraph:

   &nbs= p;            &n= bsp;       Any [academic? otherwise] work that you can cite to qu= antify the 

   &nbs= p;            &n= bsp;       computational load? I asked a crypto-wonk-colleague, w= ho said

   &nbs= p;            &n= bsp;       something to the effect of =E2=80=9Cthe document is pe= rfectly right, on this

   &nbs= p;            &n= bsp;       point, but I do not have a paper just off the top= of my head with 

   &nbs= p;            &n= bsp;       interesting data to offer=E2=80=9D. For that reason al= one, it=E2=80=99d be interesting 

   &nbs= p;            &n= bsp;       if you did ;)

 

CMD: See previous comments.= Trying Google Scholar with ECCSI elliptic curve gets a very small number of= hits, none useful here.

 

I=E2=80=99ve asked around, but I am not hopeful. Will= let you know if I get something citable =E2=80=94 most I spoke to said =E2=80= =9Cthis aligns with my intuition/experience/*=E2=80=9D though.

 

<SNIP>



   &nbs= p;            &n= bsp;       OLD:

   &nbs= p;            &n= bsp;          o  The ICV is not calculated as cryp= tographic-function(hash-

   &nbs= p;            &n= bsp;              function(content)) as defin= ed in [RFC7182], but (like the HMAC

   &nbs= p;            &n= bsp;              ICVs defined there) uses th= e hash function within the

   &nbs= p;            &n= bsp;              cryptographic function. &nb= sp;The option "none" is not permitted for

   &nbs= p;            &n= bsp;              hash-function, and the hash= function must have a known fixed

   &nbs= p;            &n= bsp;              length of N octets, as spec= ified in Section 4.2.

 

   &nbs= p;            &n= bsp;       NEW:

   &nbs= p;            &n= bsp;          o  The ICV is not calculated as cryp= tographic-function(hash-

   &nbs= p;            &n= bsp;              function(content)) as defin= ed in [RFC7182], but (like the HMAC

   &nbs= p;            &n= bsp;              ICVs defined in [RFC7182]) u= ses the hash function within the

   &nbs= p;            &n= bsp;              cryptographic function. &nb= sp;The option "none" is not permitted for

   &nbs= p;            &n= bsp;              hash-function, and the hash= function must have a known fixed

   &nbs= p;             &= nbsp;             length of N octets, as specified= in Section 4.2.

 

CMD: I could live with eith= er, but will make the change.

 

I think it makes it clearer, so thank you for that.



 

   &nbs= p;        o   =        While we are at it, it it crystal-clear to everybody that =E2=80=9CSection 4.2=E2=80=9D in

   &nbs= p;            &n= bsp;       the bullet above is to *this* document, as not RFC7182= ?

 

CMD: I=E2=80=99m going to a= ssume it is. I would always write Section X.Y of [Z] (or similar) if making a= n external reference.

 

OK, this was a throw-away comment, not important=

 

   &nbs= p;        o   =        Section 4.3, 2nd bullet

   &nbs= p;            &n= bsp;       There=E2=80=99s a LOT of information embedded in this b= ullet, and reading it

   &nbs= p;            &n= bsp;       suggests that it, readability-wise, might benefit from= embedding a:

   &nbs= p;            &n= bsp;            =        <list style=3D=E2=80=9Changing=E2=80=9D><= /p>

   &nbs= p;            &n= bsp;            =             &nbs= p;      <t hangText=3D=E2=80=9CPacket TLVs=E2=80=9D>=E2=80=A6<= ;/t>

   &nbs= p;            &n= bsp;            =             &nbs= p;      <t hangText=3D=E2=80=9CMessage TLVs=E2=80=9D>=E2=80=A6&l= t;/t>

   &nbs= p;            &n= bsp;            =             &nbs= p;      <t hangText=3D=E2=80=9CAddress Block TLVs=E2=80=9D>=E2=80= =A6</t>

   &nbs= p;            &n= bsp;            =        </list>

 

CMD: I=E2=80=99m including t= o be slightly less radical (and I=E2=80=99m not a fan on hanging text). But I= will create another level.

 

Thank you, that will work nicely.

 

 

   &nbs= p;        o   =        IANA Considerations:

 

   &nbs= p;            &n= bsp;       Given recent experiences in this WG and with requestin= g IANA 

   &nbs= p;            &n= bsp;       registrations, may I suggest that this be modified to s= ay, more

   &nbs= p;            &n= bsp;       explicitly:

 

   &nbs= p;            &n= bsp;            =        1)    &= nbsp;    IANA is requested to reserve ECCSI with description ___ 

   &nbs= p;            &n= bsp;            =             &nbs= p;      and reference =E2=80=9CThis Specification=E2=80=9D<= /p>

 

   &nbs= p;            &n= bsp;            =        2)    &= nbsp;    IANA is requested to reserve ECCSI-ADDR=E2=80=A6. (similar)

 

   &nbs= p;            &n= bsp;            =        3)    &= nbsp;    The =E2=80=9CCryptographic Functions Registry=E2=80=9D, defined in 

   &nbs= p;            &n= bsp;            =             &nbs= p;      [RFC7182], with these registrations made, will look=

   &nbs= p;            &n= bsp;            =             &nbs= p;      like Table 1, which replaces Table 11 of [RFC7182]<= /p>

 

   &nbs= p;            &n= bsp;            =        4)    &= nbsp;    Obviously, include in Table 1 the registrations from

   &nbs= p;            &n= bsp;            =             &nbs= p;      RFC7182.

 

   &nbs= p;            &n= bsp;            =        5)    &= nbsp;    That this document does not modify the expert

   &nbs= p;            &n= bsp;            =             &nbs= p;      review guidelines as set forth in RFC7182 for

   &nbs= p;            &n= bsp;            =             &nbs= p;      future allocations.

 

CMD: I think this comes und= er the heading of hand-holding IANA more than I would feel ought to be neces= sary. Except sometimes it has been. But this is a straightforward case, so while I agree that making it more explicit that this is a request f= or two new code points, I=E2=80=99m not going to repeat the full table from 7= 182 unless IANA really show they need hand-holding. Our previous cases where= we had to repeat a whole table were a bit messier. But giving the exact name for the table as on IANA=E2=80=99s= website is advisable.

 

 

True, but=E2=80=A6there=E2=80=99s perhaps something t= o be said for =E2=80=9Cthe table being as complete as possible=E2=80=9D for t= he reader, also? Well, your call, of course.

 

Once a new version hits the servers, I=E2=80=99ll let= you know if I see any pending nits.

 

Cheers,

 

Thomas

 

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

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-BC0F39AA-D9A9-4342-BBC5-3A58B44F880A-- From nobody Wed Jul 30 15:25:22 2014 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 358A61A0111 for ; Wed, 30 Jul 2014 15:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.818 X-Spam-Level: ** X-Spam-Status: No, score=2.818 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 C4ySBKpl8vKe for ; Wed, 30 Jul 2014 15:25:19 -0700 (PDT) Received: from m15-59.126.com (m15-59.126.com [220.181.15.59]) by ietfa.amsl.com (Postfix) with ESMTP id 86F391A0064 for ; Wed, 30 Jul 2014 15:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=lYs6m M95xelZ5xirzkZn9PVnJTJNMK/ttMAkDmKf0HY=; b=Y85zXdz/rXIhCiTepYBFL 5AKVeIXLEK5jZ5yv2Z8djKKKOsorwFW+4sxyi5WmP5q3kq7JGen4ka/GvVRSv+Yz ji7nzkR6oLOG2UqrvMg55A7RM3nLbluMcoK+hY/3YIH9IHIaO1OlBbyWS2wx4ds7 qAEhyJ6j3N8iTVJTGnmvxU= Received: from huixiangren$126.com ( [95.130.9.129, 54.217.235.157, 119.9.64.5] ) by ajax-webmail-wmsvr59 (Coremail) ; Thu, 31 Jul 2014 06:25:15 +0800 (CST) X-Originating-IP: [95.130.9.129, 54.217.235.157, 119.9.64.5] Date: Thu, 31 Jul 2014 06:25:15 +0800 (CST) From: "Xiangren Hui" To: ietf@jiaziyi.com X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140422(26738.6344) Copyright (c) 2002-2014 www.mailtech.cn 126com X-CM-CTRLDATA: GX6bfmZvb3Rlcl9odG09NjQ1Ojgx Content-Type: multipart/alternative; boundary="----=_Part_5484_669105934.1406759115687" MIME-Version: 1.0 Message-ID: <4bc0ffd8.4ff.14789609ba8.Coremail.huixiangren@126.com> X-CM-TRANSID: O8qowABHT4PMcNlTikAJAA--.16913W X-CM-SenderInfo: xkxl5xxdqj2vbq6rjloofrz/1tbiTgXYgk3mIUzxbQABsK X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HLsCxtHrkRr8zDs-tsavp-79H04 Cc: manet@ietf.org Subject: Re: [manet] request for WG adoption: draft-yi-manet-olsrv2-multipath 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, 30 Jul 2014 22:25:20 -0000 ------=_Part_5484_669105934.1406759115687 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sCgpPdXIgdGVhbSBoYXMgZG9uZSBzb21lIHdvcmsgYmFzZWQgb24gdGhlIHJlZmVyZW5j ZSB5b3UgcHJvdmlkZWQsIGFuZCBJIHRoaW5rIGl0J3MgaW50ZXJlc3RpbmcgdG8gaGF2ZSBpdCBz cGVjaWZpZWQgYXMgUkZDLgpTb21lIHF1ZXN0aW9ucyB0byB0aGUgYXV0aG9yczoKCjEuIFRoaXMg ZHJhZnQgaXMgYWN0dWFsbHkgYSBiaXQgZGlmZmVyZW50IGZyb20gdGhlIHBhcGVycyB5b3UgcHVi bGlzaGVkLiBTb21lIGZ1bmN0aW9ucyBhcmUgcmVtb3ZlZC4gQ291bGQgeW91IHBsZWFzZSBleHBs YWluIHdoYXQncyB5b3VyIGNvbnNpZGVyYXRpb24/CgoyLiBJbiB0aGUgaW50ZXJuZXQgZHJhZnQs IGl0IHNlZW1zIHRoYXQgdGhlIHByb3RvY29sIG9ubHkgYWxsb3dzIHRoZSBPTFNSLW1wIHJvdXRl cnMgZG8gc291cmNlIHJvdXRpbmcuIEluIGZhY3QsIHNvbWUgcm91dGVycyBoYXZlIHNvdXJjZSBy b3V0aW5nIG9wdGlvbiwgc28gdGhleSBjYW4gYmUgdXNlZCBhbHNvPwoKY2hlZXJzCgpYaWFuZ3Jl bgo= ------=_Part_5484_669105934.1406759115687 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGVsbG8sPGJyPjxicj5PdXIgdGVhbSBoYXMgZG9uZSBz b21lIHdvcmsgYmFzZWQgb24gdGhlIHJlZmVyZW5jZSB5b3UgcHJvdmlkZWQsIGFuZCBJIHRoaW5r IGl0J3MgaW50ZXJlc3RpbmcgdG8gaGF2ZSBpdCBzcGVjaWZpZWQgYXMgUkZDLiA8YnI+U29tZSBx dWVzdGlvbnMgdG8gdGhlIGF1dGhvcnM6PGJyPjxicj4xLiBUaGlzIGRyYWZ0IGlzIGFjdHVhbGx5 IGEgYml0IGRpZmZlcmVudCBmcm9tIHRoZSBwYXBlcnMgeW91IHB1Ymxpc2hlZC4gU29tZSBmdW5j dGlvbnMgYXJlIHJlbW92ZWQuIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB3aGF0J3MgeW91ciBj b25zaWRlcmF0aW9uPzxicj48YnI+Mi4gSW4gdGhlIGludGVybmV0IGRyYWZ0LCBpdCBzZWVtcyB0 aGF0IHRoZSBwcm90b2NvbCBvbmx5IGFsbG93cyB0aGUgT0xTUi1tcCByb3V0ZXJzIGRvIHNvdXJj ZSByb3V0aW5nLiBJbiBmYWN0LCBzb21lIHJvdXRlcnMgaGF2ZSBzb3VyY2Ugcm91dGluZyBvcHRp b24sIHNvIHRoZXkgY2FuIGJlIHVzZWQgYWxzbz88YnI+PGJyPmNoZWVyczxicj48YnI+WGlhbmdy ZW48YnI+PC9kaXY+PC9kaXY+PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHNw YW4gaWQ9Im5ldGVhc2VfbWFpbF9mb290ZXIiPjwvc3Bhbj48L3NwYW4+ ------=_Part_5484_669105934.1406759115687-- From nobody Wed Jul 30 18:00:49 2014 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 9E4AF1A01D9; Wed, 30 Jul 2014 18:00:43 -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 O08Ik-L-bTCE; Wed, 30 Jul 2014 18:00:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCFC1A014E; Wed, 30 Jul 2014 18:00:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731010034.24406.32346.idtracker@ietfa.amsl.com> Date: Wed, 30 Jul 2014 18:00:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LGNT3nyGrJisiLuB1sfWYIGfka4 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-12.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, 31 Jul 2014 01:00:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process Authors : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-12.txt Pages : 65 Date : 2014-07-30 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-12 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 Thu Jul 31 01:54:56 2014 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 CC85B1A0495 for ; Thu, 31 Jul 2014 01:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 QDDfsi60P59U for ; Thu, 31 Jul 2014 01:54:53 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF911A0439 for ; Thu, 31 Jul 2014 01:54:52 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so2409608wes.22 for ; Thu, 31 Jul 2014 01:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cjMzvwZkLaV93IkM3y8kCwCOrJSOvIlcslvxYoR7VVI=; b=uhrI2P30m96XGwY9EU2qNXyJfsa/bSFRGSqgybPkaS+bOc2DteuQgnxOdnli9fagZb 0NGWKRM6ET3g9kk8aGCjp9UsbNz8s6mdAUqDwWRcoHP7PkzDae3OC/qXmIGs/zHx+ZAH UR0E9yo26MHa2k6yecguQYTHkfICa8spV6vyPNIW5qNUQgHRf+sUdCoXXffJTPkB1Oje 7IE4rxoGrcQ/7oGqyZxaM+YHDoorMZhs6yobO7ZL0JNYruB1N642QVMibVWhkr/Dx6ia k0fAflgAyHa7/ojHaDrHUbOB1odyxGMBsffQ298jQlchetB+OjbsH4tNj+qmYkhnBaiW saRg== MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr13791441wib.32.1406796889566; Thu, 31 Jul 2014 01:54:49 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Thu, 31 Jul 2014 01:54:49 -0700 (PDT) In-Reply-To: <4bc0ffd8.4ff.14789609ba8.Coremail.huixiangren@126.com> References: <4bc0ffd8.4ff.14789609ba8.Coremail.huixiangren@126.com> Date: Thu, 31 Jul 2014 10:54:49 +0200 X-Google-Sender-Auth: kpZxIBjmfi8lrgkPRVhm194krRE Message-ID: From: Jiazi YI To: Xiangren Hui Content-Type: multipart/alternative; boundary=001a11c37e56dfb25104ff796cf3 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-mTedYLNeTYFhc3YVpW6ngLKW4w Cc: manet Subject: Re: [manet] request for WG adoption: draft-yi-manet-olsrv2-multipath 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, 31 Jul 2014 08:54:55 -0000 --001a11c37e56dfb25104ff796cf3 Content-Type: text/plain; charset=UTF-8 Hi, Glad to see your comments on the mailing list. Please check inline: On Thu, Jul 31, 2014 at 12:25 AM, Xiangren Hui wrote: > hello, > > Our team has done some work based on the reference you provided, and I > think it's interesting to have it specified as RFC. > Some questions to the authors: > > 1. This draft is actually a bit different from the papers you published. > Some functions are removed. Could you please explain what's your > consideration? > The papers in the reference were mainly finished before 2010, and published in 2011. After that, there are continuous improvement of the protocol, especially "engineering" improvements. The research papers are mainly introducing ideas, and provide performance analyses. It's hard to produce interoperable implementations (for example, it won't specify what a TLV looks like, and its code point). Before we bring the draft to IETF, we eliminated some "research" functions, mainly for simplicity, efficiency and interoperability (especially the interoperability with OLSRv2). However, the idea and algorithm are not changed. Therefore, the results in the references are still valid. > > 2. In the internet draft, it seems that the protocol only allows the > OLSR-mp routers do source routing. In fact, some routers have source > routing option, so they can be used also? > Geoff proposed similar concern on this off the list a few days ago. So please just allow me to copy the reply directly :) On Tue, Jul 29, 2014 at 4:20 PM, Geoff Ladwig wrote: > Hi Jiazi, > > > > Is there an assumption that only MP-OLSR routers can do source routing? > > Source routing is a fairly common dataplane feature on commercial routers. > > > It's true that a lot of commercial routers support source routing. But at least, based on our experience, it's probably not the case for MANET routers. For example, in IPv6, the original source routing header Type 0 is deprecated (RFC 5095). For some routers that support source routing, it's possible that the source routing function is turned off by default. The source routing header for IPv6 used by MP-OLSR is RFC 6554 -- we don't know if an OLSRv2 router will support it or not. By default, it's not supported. Therefore, a safe assumption is that only let MP-OLSR routers take care of the source routing header. best Jiazi --001a11c37e56dfb25104ff796cf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Glad to see your comments on = the mailing list. Please check inline:

On Thu, Jul 31, 2014 at 12:25 AM, Xiangren Hui <hui= xiangren@126.com> wrote:
hello,

Our team has done some work based on the reference you p= rovided, and I think it's interesting to have it specified as RFC.
= Some questions to the authors:

1. This draft is actually a bit diffe= rent from the papers you published. Some functions are removed. Could you p= lease explain what's your consideration?


The papers in t= he reference were mainly finished before 2010, and published in 2011. After= that, there are continuous improvement of the protocol, especially "e= ngineering" improvements.=C2=A0
The research papers are mainly introducing ideas, and provide performa= nce analyses. It's hard to produce interoperable implementations (for e= xample, it won't specify what a TLV looks like, and its code point).=C2= =A0
Before we bring the draft to IETF, we eliminated some "research&q= uot; functions, mainly for simplicity, efficiency and interoperability (esp= ecially the interoperability with OLSRv2).=C2=A0
However, the ide= a and algorithm are not changed. Therefore, the results in the references a= re still valid.=C2=A0

=C2=A0

2. In the internet draft, it seems that the protocol only allows the OL= SR-mp routers do source routing. In fact, some routers have source routing = option, so they can be used also?


Geoff proposed similar concern on this off the li= st a few days ago. So please just allow me to copy the reply directly :)

On Tue, Jul 29, 2014 at 4:20 PM, Geoff Ladwig=C2=A0<= span dir=3D"ltr"><gladwig@verdantnetworks.com>=C2=A0wrote:

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">Hi Jiazi,

= =C2=A0

Is there an assumption that only MP-OLSR rou= ters can do source routing?

= Source routing is a fairly common dataplane feature on commercial r= outers.



It's true that a= lot of commercial routers support source routing. But at least, based on o= ur experience, it's probably not the case for MANET routers.=C2=A0

For example, in IPv6, = the original source routing header Type 0 is deprecated (RFC 5095). For som= e routers that support source routing, it's possible that the source ro= uting function is turned off by default.=C2=A0
The source routi= ng header for IPv6 used by MP-OLSR is RFC 6554 -- we don't know if an O= LSRv2 router will support it or not. By default, it's not supported.=C2= =A0

Therefore, a safe assu= mption is that only let MP-OLSR routers take care of the source routing hea= der.=C2=A0

best

Jiazi
--001a11c37e56dfb25104ff796cf3-- From nobody Thu Jul 31 06:38:11 2014 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 2BA8B1B2810 for ; Thu, 31 Jul 2014 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 XoBN3vJz7pVm for ; Thu, 31 Jul 2014 06:38:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1026A1B280A for ; Thu, 31 Jul 2014 06:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6295; q=dns/txt; s=iport; t=1406813884; x=1408023484; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=H0SCoKMbYa41BQbsIvAapBp7NqHALmQ8pv5Sb9skFjc=; b=CNIslaIZM+0YR6OqRB+EA6C9k1UcyMgp9+QgHuRtJn38tInymIIULIrQ PQns9Q0mNPjszur/YlkGEgaZdhC0XmXmUJ5RXmGXH+zF8vcfi5u3I9s/9 8bmX0JKvAWJ1oC6J5yNkSDJc2vttse9++/NiHHH2e2pIqrc5Wj4CZFAvd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisTAJ1F2lOtJA2M/2dsb2JhbABZgw5SVwSEEMU6gTwcAQuHSQGBBhZ3hAQBAQEDAQEBGlEbAgFHBycLFBECBBMJiDkNvCAXjnsBAVaCOFMkgRsFm2SBUpMBg0lsAYELOQ X-IronPort-AV: E=Sophos; i="5.01,772,1400025600"; d="scan'208,217"; a="65473376" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 31 Jul 2014 13:38:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6VDc37a020352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Jul 2014 13:38:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 08:38:03 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Call to adopt draft-yi-manet-olsrv2-multipath as a working group document Thread-Index: AQHPrMSmV9Ut+2NJtkqVUUWqOrBYwA== Date: Thu, 31 Jul 2014 13:38:02 +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: [64.102.40.190] Content-Type: multipart/alternative; boundary="_000_E5BE164A7F8340A2975E19AFBEEF5F4Aciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0J9Uo6rVI24TgQUdqLFiGWMm_Rk Subject: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 31 Jul 2014 13:38:10 -0000 --_000_E5BE164A7F8340A2975E19AFBEEF5F4Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group Participants - This is a call to adopt draft-yi-manet-olsrv2-multipath as a working group = document. If you have issues with the WG accepting this document, please no= te them on the list before close of business on Aug 14, 2014. To properly g= auge the overall WG interest in this draft, I ask that WG participants in f= avor of adoption please state so, on the list, prior to the Aug 14 deadline= . Regards, Stan On Jul 29, 2014, at 3:29 PM, Jiazi YI > wrote: Dear chairs, The draft draft-yi-manet-olsrv2-multipath has been presented in IETF meetin= g in Toronto. There are a lot of constructive comments from the WG during & after the mee= ting, detailed in http://www.ietf.org/mail-archive/web/manet/current/msg16613.html http://www.ietf.org/mail-archive/web/manet/current/msg16740.html The feedback is very helpful and exciting. We thus folded them in the new r= evision of the draft as soon as possible, which is now available today at http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 This draft aims for publication as an *Experimental* Track RFC. The motivat= ion of being an experimental RFC and experiments points have been illustrat= ed in http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 As a reminder, there are multiple open-source implementations available for= this protocol and they are now running and being tested in different netwo= rks. The multi-path routing has attracted great interest from both industry= and academia. We believe it's time to publish the protocol as an experimental RFC, based = on the experiences we obtained in the last decade. It would be great help f= or the engineers and researchers interested in the multi-path approach for = MANET, and push it to a standard track protocol eventually. Therefore, we would like to know your opinion on the draft, and kindly requ= est a call for WG adoption. As always, we are looking forward to further comments on the draft from all= the WG participants. regards Jiazi _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_E5BE164A7F8340A2975E19AFBEEF5F4Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0628466839FCCE4ABED4CF5625A62C4D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Working Group Participants - 

This is a call to adopt draft-yi-manet-olsrv2-multipath as a working g= roup document. If you have issues with the WG accepting this document,= please note them on the list before close of business on Aug 14, 2014= . To properly gauge the overall WG interest in this draft, I ask that WG participants in favor of adoption please stat= e so, on the list, prior to the Aug 14 deadline. 

Regards,
Stan


On Jul 29, 2014, at 3:29 PM, Jiazi YI <ietf@jiaziyi.com> wrote:

Dear chairs, 

The draft draft-yi-manet-olsrv2-multipath has been presented in IETF m= eeting in Toronto. 
There are a lot of constructive comments from the WG during & afte= r the meeting, detailed in 


The feedback is very helpful and exciting. We thus folded them in the = new revision of the draft as soon as possible, which is now available today= at 


This draft aims for publication as an *Experimental* Track RFC. The mo= tivation of being an experimental RFC and experiments points have been illu= strated in 


As a reminder, there are multiple open-source implementations availabl= e for this protocol and they are now running and being tested in different = networks. The multi-path routing has attracted great interest from both ind= ustry and academia. 

We believe it's time to publish the protocol as an experimental RFC, b= ased on the experiences we obtained in the last decade. It would be great h= elp for the engineers and researchers interested in the multi-path approach= for MANET, and push it to a standard track protocol eventually. 

Therefore, we would like to know your opinion on the draft, and kindly= request a call for WG adoption. 

As always, we are looking forward to further comments on the draft fro= m all the WG participants. 

regards

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

--_000_E5BE164A7F8340A2975E19AFBEEF5F4Aciscocom_-- From nobody Thu Jul 31 07:46:21 2014 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 211EA1A014C for ; Thu, 31 Jul 2014 07:46:20 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4AYmuxBraRzR for ; Thu, 31 Jul 2014 07:46:13 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033931A005B for ; Thu, 31 Jul 2014 07:46:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 91E301C08AB; Thu, 31 Jul 2014 07:46:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.103.136.36] (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D5BE41C0873; Thu, 31 Jul 2014 07:46:11 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-47AA6525-AE7E-4513-9EBE-16C93A133831 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Thu, 31 Jul 2014 16:46:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <837124A3-36EC-4829-9F51-20AB809B2A1D@thomasclausen.org> References: To: "Stan Ratliff (sratliff)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MpQY3KJJn_HYONr6I3j82uWU4QE Cc: manet IETF Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 31 Jul 2014 14:46:20 -0000 --Apple-Mail-47AA6525-AE7E-4513-9EBE-16C93A133831 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Stan, I'm in favor ; I believe that this is a worthy experiment for the WG to be u= ndertaking, as an extension to OLSRv2. Thomas Sent from my iPad > On 31 Jul 2014, at 15:38, "Stan Ratliff (sratliff)" w= rote: >=20 > Working Group Participants -=20 >=20 > This is a call to adopt draft-yi-manet-olsrv2-multipath as a working group= document. If you have issues with the WG accepting this document, please no= te them on the list before close of business on Aug 14, 2014. To properly ga= uge the overall WG interest in this draft, I ask that WG participants in fav= or of adoption please state so, on the list, prior to the Aug 14 deadline.=20= >=20 > Regards, > Stan >=20 >=20 >> On Jul 29, 2014, at 3:29 PM, Jiazi YI wrote: >>=20 >> Dear chairs,=20 >>=20 >> The draft draft-yi-manet-olsrv2-multipath has been presented in IETF meet= ing in Toronto.=20 >> There are a lot of constructive comments from the WG during & after the m= eeting, detailed in=20 >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg16613.html >> http://www.ietf.org/mail-archive/web/manet/current/msg16740.html >>=20 >> The feedback is very helpful and exciting. We thus folded them in the new= revision of the draft as soon as possible, which is now available today at=20= >>=20 >> http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 >>=20 >> This draft aims for publication as an *Experimental* Track RFC. The motiv= ation of being an experimental RFC and experiments points have been illustra= ted in=20 >>=20 >> http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1= >>=20 >> As a reminder, there are multiple open-source implementations available f= or this protocol and they are now running and being tested in different netw= orks. The multi-path routing has attracted great interest from both industry= and academia.=20 >>=20 >> We believe it's time to publish the protocol as an experimental RFC, base= d on the experiences we obtained in the last decade. It would be great help f= or the engineers and researchers interested in the multi-path approach for M= ANET, and push it to a standard track protocol eventually.=20 >>=20 >> Therefore, we would like to know your opinion on the draft, and kindly re= quest a call for WG adoption.=20 >>=20 >> As always, we are looking forward to further comments on the draft from a= ll the WG participants.=20 >>=20 >> regards >>=20 >> Jiazi >> _______________________________________________ >> 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 --Apple-Mail-47AA6525-AE7E-4513-9EBE-16C93A133831 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Stan,

I'm in favor ; I believe that this is a worthy experiment for the WG to be undertaking, as an extension to OLSRv2.

Thomas

Sent from my iPad

On 31 Jul 2014, at 15:38, "Stan Ratliff (sratliff)" <sratliff@cisco.com> wrote:

Working Group Participants - 

This is a call to adopt draft-yi-manet-olsrv2-multipath as a working group document. If you have issues with the WG accepting this document, please note them on the list before close of business on Aug 14, 2014. To properly gauge the overall WG interest in this draft, I ask that WG participants in favor of adoption please state so, on the list, prior to the Aug 14 deadline. 

Regards,
Stan


On Jul 29, 2014, at 3:29 PM, Jiazi YI <ietf@jiaziyi.com> wrote:

Dear chairs, 

The draft draft-yi-manet-olsrv2-multipath has been presented in IETF meeting in Toronto. 
There are a lot of constructive comments from the WG during & after the meeting, detailed in 


The feedback is very helpful and exciting. We thus folded them in the new revision of the draft as soon as possible, which is now available today at 


This draft aims for publication as an *Experimental* Track RFC. The motivation of being an experimental RFC and experiments points have been illustrated in 


As a reminder, there are multiple open-source implementations available for this protocol and they are now running and being tested in different networks. The multi-path routing has attracted great interest from both industry and academia. 

We believe it's time to publish the protocol as an experimental RFC, based on the experiences we obtained in the last decade. It would be great help for the engineers and researchers interested in the multi-path approach for MANET, and push it to a standard track protocol eventually. 

Therefore, we would like to know your opinion on the draft, and kindly request a call for WG adoption. 

As always, we are looking forward to further comments on the draft from all the WG participants. 

regards

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

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-47AA6525-AE7E-4513-9EBE-16C93A133831-- From nobody Thu Jul 31 08:26:37 2014 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 7DFA51B2936 for ; Thu, 31 Jul 2014 08:26:35 -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 ubKVONT_AV15 for ; Thu, 31 Jul 2014 08:26:33 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5C31A00E2 for ; Thu, 31 Jul 2014 08:26:33 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so4492015vcb.30 for ; Thu, 31 Jul 2014 08:26:32 -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=cqMRa0J7A1oxpho7GYYcKaPAGcnXHoA3HJpjRD9Dqms=; b=J268/Tnw/MptB65dvQ+4pc72bhqOFWkSSsu7JX5sFiIc2rgFsprkMG/bsGtUL2Krwd ELgcGzwiAWUG9ZJrjh0Rz8ljVY7MJz0kPddevgeXqIW9AhC3ZJYxj6BJ031Vp1hpSPwc ++9BQ9zP7z2c9QbdlA5zLkcwqaTiXi19eP/VM= 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=cqMRa0J7A1oxpho7GYYcKaPAGcnXHoA3HJpjRD9Dqms=; b=au3xtgBzmAfD/DeH6QJm/cshMcWuTCEgsJiGpQ73t/N5iesu5kd/QioCXl+GofwcCY B+8KTVmpY5cOZI2NdYQPSMjZ7ipFCqUvWhpdtyXFEn2pXcuwg/NGP7bAwEFA1k1xNhNe Hljpqg8pb7/nri0wwhPMtQUdVn0ZwxCVop0+yij1cQugVvEY66i5QggwzT7nZZmfgQjq JtIFWdLksdKSF4RtZsymLa/eJfe5+IOn6FkfuYaX1/B5GXXHjb2KdfyPoivHBiC28AaM saQj171ub30nVzBoq317+pXBYHG1GPz6fwBquqTqcudsbzpZp5g54Y0p9tpg/lVWcMn9 28fQ== X-Gm-Message-State: ALoCoQmsSDmYBdc7e188RJaQ0Qu0mNwybjkSy/srC+RCCxM0Z4m6hk2lze1yTWpwMHB5WggrPUIg MIME-Version: 1.0 X-Received: by 10.52.148.2 with SMTP id to2mr15613929vdb.38.1406820392497; Thu, 31 Jul 2014 08:26:32 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Thu, 31 Jul 2014 08:26:32 -0700 (PDT) In-Reply-To: <837124A3-36EC-4829-9F51-20AB809B2A1D@thomasclausen.org> References: <837124A3-36EC-4829-9F51-20AB809B2A1D@thomasclausen.org> Date: Thu, 31 Jul 2014 08:26:32 -0700 Message-ID: From: Ulrich Herberg To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jOSQOMHGAhMBqKHSM_Pxv4Qrekg Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 31 Jul 2014 15:26:35 -0000 +1 in favor of adoption. (btw, type 128 for MP_OLSRv2 in Table 1/Section 12.1 is already taken by SMF_TYPE): http://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#message-tlv-hello On Thu, Jul 31, 2014 at 7:46 AM, Thomas Clausen wrote: > Stan, > > I'm in favor ; I believe that this is a worthy experiment for the WG to be > undertaking, as an extension to OLSRv2. > > Thomas > > Sent from my iPad > > On 31 Jul 2014, at 15:38, "Stan Ratliff (sratliff)" > wrote: > > Working Group Participants - > > This is a call to adopt draft-yi-manet-olsrv2-multipath as a working group > document. If you have issues with the WG accepting this document, please > note them on the list before close of business on Aug 14, 2014. To properly > gauge the overall WG interest in this draft, I ask that WG participants in > favor of adoption please state so, on the list, prior to the Aug 14 > deadline. > > Regards, > Stan > > > On Jul 29, 2014, at 3:29 PM, Jiazi YI wrote: > > Dear chairs, > > The draft draft-yi-manet-olsrv2-multipath has been presented in IETF meeting > in Toronto. > There are a lot of constructive comments from the WG during & after the > meeting, detailed in > > http://www.ietf.org/mail-archive/web/manet/current/msg16613.html > http://www.ietf.org/mail-archive/web/manet/current/msg16740.html > > The feedback is very helpful and exciting. We thus folded them in the new > revision of the draft as soon as possible, which is now available today at > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 > > This draft aims for publication as an *Experimental* Track RFC. The > motivation of being an experimental RFC and experiments points have been > illustrated in > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 > > As a reminder, there are multiple open-source implementations available for > this protocol and they are now running and being tested in different > networks. The multi-path routing has attracted great interest from both > industry and academia. > > We believe it's time to publish the protocol as an experimental RFC, based > on the experiences we obtained in the last decade. It would be great help > for the engineers and researchers interested in the multi-path approach for > MANET, and push it to a standard track protocol eventually. > > Therefore, we would like to know your opinion on the draft, and kindly > request a call for WG adoption. > > As always, we are looking forward to further comments on the draft from all > the WG participants. > > regards > > Jiazi > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Thu Jul 31 14:56:15 2014 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 91BE51A0141 for ; Thu, 31 Jul 2014 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 w_W9LzwZyZkq for ; Thu, 31 Jul 2014 14:56:07 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BFF1A0183 for ; Thu, 31 Jul 2014 14:56:06 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so3402992wes.7 for ; Thu, 31 Jul 2014 14:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9xxgQHabMdRo3GgsetIxYNGojajyNNIMEsch8AU11mA=; b=HQf5DydDyutBxw6g+Tq4CByp6bM1x85TD4KCHp7cKffTjuvieOikvxsxKvMvQkHdvG BT4PR7oJ9y5tNL7/USuUoTQxHMk/clLdI3wEX7hjqS5yVAehXZo19iux/1PSRlmXa009 cpMnoRYXGVb2m5w2RSV7CKIX0owutZam709zcsZxT3WI2wQQM1csasNLuRq/1zydhVXo ePjBmzJvCjhr0kJGvO3dtfghEWVUTj2gNy9fAoxEf7vqRl0WMlpniMLdYLBLA13gFnED PVOZ1YpsIymUeJ613Sb8FJh6b8kNUVYlL4yc7UUj4CdnjcznFLnLZ9K9rkJ+4E2B1b3Q V86A== MIME-Version: 1.0 X-Received: by 10.194.57.45 with SMTP id f13mr1519613wjq.98.1406843765082; Thu, 31 Jul 2014 14:56:05 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Thu, 31 Jul 2014 14:56:05 -0700 (PDT) In-Reply-To: References: <837124A3-36EC-4829-9F51-20AB809B2A1D@thomasclausen.org> Date: Thu, 31 Jul 2014 23:56:05 +0200 X-Google-Sender-Auth: VIN-HlJrsKCWEogklgcQh2_bWr8 Message-ID: From: Jiazi YI To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7ba97674df521d04ff8456ae Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uibNSW6uibj2Vw2uapAR9bycytc Cc: manet IETF , Thomas Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 31 Jul 2014 21:56:14 -0000 --047d7ba97674df521d04ff8456ae Content-Type: text/plain; charset=UTF-8 Oops... yes. Thanks for pointing it out. Will fix in the next revision. best Jiazi On Thu, Jul 31, 2014 at 5:26 PM, Ulrich Herberg wrote: > +1 in favor of adoption. > > (btw, type 128 for MP_OLSRv2 in Table 1/Section 12.1 is already taken > by SMF_TYPE): > > http://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#message-tlv-hello > > On Thu, Jul 31, 2014 at 7:46 AM, Thomas Clausen > wrote: > > Stan, > > > > I'm in favor ; I believe that this is a worthy experiment for the WG to > be > > undertaking, as an extension to OLSRv2. > > > > Thomas > > > > Sent from my iPad > > > > On 31 Jul 2014, at 15:38, "Stan Ratliff (sratliff)" > > wrote: > > > > Working Group Participants - > > > > This is a call to adopt draft-yi-manet-olsrv2-multipath as a working > group > > document. If you have issues with the WG accepting this document, please > > note them on the list before close of business on Aug 14, 2014. To > properly > > gauge the overall WG interest in this draft, I ask that WG participants > in > > favor of adoption please state so, on the list, prior to the Aug 14 > > deadline. > > > > Regards, > > Stan > > > > > > On Jul 29, 2014, at 3:29 PM, Jiazi YI wrote: > > > > Dear chairs, > > > > The draft draft-yi-manet-olsrv2-multipath has been presented in IETF > meeting > > in Toronto. > > There are a lot of constructive comments from the WG during & after the > > meeting, detailed in > > > > http://www.ietf.org/mail-archive/web/manet/current/msg16613.html > > http://www.ietf.org/mail-archive/web/manet/current/msg16740.html > > > > The feedback is very helpful and exciting. We thus folded them in the new > > revision of the draft as soon as possible, which is now available today > at > > > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 > > > > This draft aims for publication as an *Experimental* Track RFC. The > > motivation of being an experimental RFC and experiments points have been > > illustrated in > > > > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 > > > > As a reminder, there are multiple open-source implementations available > for > > this protocol and they are now running and being tested in different > > networks. The multi-path routing has attracted great interest from both > > industry and academia. > > > > We believe it's time to publish the protocol as an experimental RFC, > based > > on the experiences we obtained in the last decade. It would be great help > > for the engineers and researchers interested in the multi-path approach > for > > MANET, and push it to a standard track protocol eventually. > > > > Therefore, we would like to know your opinion on the draft, and kindly > > request a call for WG adoption. > > > > As always, we are looking forward to further comments on the draft from > all > > the WG participants. > > > > regards > > > > Jiazi > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7ba97674df521d04ff8456ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oops... yes. Thanks for pointing it out.=C2=A0
Will fi= x in the next revision.=C2=A0

best

<= /div>
Jiazi


On Thu, Jul 31, 2014 at 5:26 PM, Ulrich Herberg <ulrich@herberg.name= > wrote:
+1 in favor of adoption.

(btw, type 128 for MP_OLSRv2 in Table 1/Section 12.1 =C2=A0is already taken=
by SMF_TYPE):
http://www.iana.org/assignment= s/manet-parameters/manet-parameters.xhtml#message-tlv-hello

On Thu, Jul 31, 2014 at 7:46 AM, Thomas Clausen
<thomas@thomasclausen.org> wrote:
> Stan,
>
> I'm in favor ; I believe that this is a worthy experiment for the = WG to be
> undertaking, as an extension to OLSRv2.
>
> Thomas
>
> Sent from my iPad
>
> On 31 Jul 2014, at 15:38, "Stan Ratliff (sratliff)" <sratliff@cisco.com>
> wrote:
>
> Working Group Participants -
>
> This is a call to adopt draft-yi-manet-olsrv2-multipath as a working g= roup
> document. If you have issues with the WG accepting this document, plea= se
> note them on the list before close of business on Aug 14, 2014. To pro= perly
> gauge the overall WG interest in this draft, I ask that WG participant= s in
> favor of adoption please state so, on the list, prior to the Aug 14 > deadline.
>
> Regards,
> Stan
>
>
> On Jul 29, 2014, at 3:29 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
>
> Dear chairs,
>
> The draft draft-yi-manet-olsrv2-multipath has been presented in IETF m= eeting
> in Toronto.
> There are a lot of constructive comments from the WG during & afte= r the
> meeting, detailed in
>
> http://www.ietf.org/mail-archive/web/manet/current= /msg16613.html
> http://www.ietf.org/mail-archive/web/manet/current= /msg16740.html
>
> The feedback is very helpful and exciting. We thus folded them in the = new
> revision of the draft as soon as possible, which is now available toda= y at
>
> http://tools.ietf.org/html/draft-yi-manet-olsrv2-mult= ipath-02
>
> This draft aims for publication as an *Experimental* Track RFC. The > motivation of being an experimental RFC and experiments points have be= en
> illustrated in
>
> http://tools.ietf.org/html/draft-yi-manet= -olsrv2-multipath-02#section-1.1
>
> As a reminder, there are multiple open-source implementations availabl= e for
> this protocol and they are now running and being tested in different > networks. The multi-path routing has attracted great interest from bot= h
> industry and academia.
>
> We believe it's time to publish the protocol as an experimental RF= C, based
> on the experiences we obtained in the last decade. It would be great h= elp
> for the engineers and researchers interested in the multi-path approac= h for
> MANET, and push it to a standard track protocol eventually.
>
> Therefore, we would like to know your opinion on the draft, and kindly=
> request a call for WG adoption.
>
> As always, we are looking forward to further comments on the draft fro= m all
> the WG participants.
>
> regards
>
> Jiazi
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

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

--047d7ba97674df521d04ff8456ae--