From nobody Sat Nov 1 11:33: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 63F241A0081 for ; Sat, 1 Nov 2014 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U3MTELXzyJo for ; Sat, 1 Nov 2014 11:33:29 -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 879321A0030 for ; Sat, 1 Nov 2014 11:33:29 -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 <1XkdUL-000rsy-G2>; Sat, 01 Nov 2014 19:33:25 +0100 Received: from p5b03dc8b.dip0.t-ipconnect.de ([91.3.220.139] helo=[10.0.3.125]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XkdUL-001hzK-E3>; Sat, 01 Nov 2014 19:33:25 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: Date: Sat, 1 Nov 2014 19:33:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <123FAF8A-C36F-48F2-9554-177B0DE89E90@fu-berlin.de> References: To: manet@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 91.3.220.139 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-7gzJf8_wJEoPUBdF-QDsFcRaxc Cc: John Dowdell , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] AODVv2 Review from an implementation perspective X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 01 Nov 2014 18:33:32 -0000 Hello, as announced earlier, a tiny update of my review concerning the changes = made in v05: AckReq vs. RREP_ACK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D v05 states that AckReq and RREP_ACK are not, as I had assumed, two = mechanisms trying to serve the same purpose. I'm glad this has been clarified. However, I am still unsure about how to properly implement a = RREP_ACK message, as detailed in [1]. Additionally, RREP_ACKs are listed as an optional feature in section = 13.5., while section 5.2. mandates that a RREP_ACK MUST be sent in reply to = each AckReq. I'm not sure if that adds up, maybe RREP_ACKs should be marked as = required as well? Route vs Routing table =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under =93Style and consistency=94, I noted that the draft sometimes = refers to the route table as a routing table. This doesn't apply anymore, since it = has been corrected in v05. Correction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I wrote that letting the implementor choose the Next-hop Router = Adjacency Monitoring mechanism would lead to interoperability problems. This = isn't true, as those mechanisms currently have no influence on the = blacklists and thus cannot prevent a route from being established. The scenario I = described can, of course, still impact performance: Alice's and Bob's devices = may be able to talk to each other, but they cannot detect when a link = connecting a device running Alice's implementation to a device running Bob's = implementation breaks before they run into timeouts. [1] http://www.ietf.org/mail-archive/web/manet/current/msg16355.html= From nobody Tue Nov 4 01:54: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 E3CC81A1AF6 for ; Tue, 4 Nov 2014 01:54:39 -0800 (PST) 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 rRFPCPkLAtGU for ; Tue, 4 Nov 2014 01:54:38 -0800 (PST) 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 BC5971A1A0B for ; Tue, 4 Nov 2014 01:54:37 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id x12so13182486wgg.18 for ; Tue, 04 Nov 2014 01:54:36 -0800 (PST) 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=DaR2xkI/0xgHACpNXZLJGoifDINftzF0ZcQnuhr5n/A=; b=Y1/pNR9yBK2ts8VWbyGpBTmIPHqGapWg99vL2FOeDiNekWzUvHSn5HoMdqvT5zqrYJ w4XM7jxTdDYXkcCrp9UDj1JYO782cg+aK+cJdmKm4XZ5Yn2aOcpGA0NnBAe2QBqrh0IF efcymbYa4bb5Cxd1pyeFLC3EwDTU5CBSVvzl3E5Hgq/9uy0AFOtFsRL0T8ddsufBX/zu 4yhVYvI4fSJVy4wAurhWL9AEuyZgXe4zuF3BLM3M+dGH0KD9bi7rojtse+zImX6luN9N WCJSJc7aGhZxFT2ydRcpbgCr5+34J5CC6WFIoFFSviC5YfKfX6lCU4sjV//sKpqQV7zb rvvQ== X-Received: by 10.180.88.162 with SMTP id bh2mr22626600wib.77.1415094876417; Tue, 04 Nov 2014 01:54:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.216.65 with HTTP; Tue, 4 Nov 2014 01:54:16 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801429411F7@tss-server1.home.tropicalstormsoftware.com> References: <20141024143758.16624.11599.idtracker@ietfa.amsl.com> <4e633e09-ee66-48f6-b563-70e9729890c0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <38A5475DE83986499AEACD2CFAFC3F9801429411F7@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 4 Nov 2014 10:54:16 +0100 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Y72KBUuuxuf2CiZX4JFEUKZMxx0 Cc: MANET IETF Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-07.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, 04 Nov 2014 09:54:40 -0000 On Wed, Oct 29, 2014 at 3:56 PM, Rick Taylor wrote: > All, > > For those who are interested, the source for a sample DLEP-07 'router' > is now available at: https://github.com/ricktaylor/dlep_router > > The code does not actually route, but acts as a protocol validator by > taking on the role of a DLEP router. The license is MIT. > > It has been successfully used to implement and validate a DLEP modem > implementation, and hopefully will be of use to others. Great that you managed to get the legal problems out of the way Rick! I just was on our yearly CONFINE review meeting last week, where we demonstrated two DLEP router nodes, each with two DLEP radios based on OpenWRT and Wifi. I pushed the sourcecode of my implementation into the Olsr.org Network Framework repository into the src-plugins/dlep directory. (see http://olsr.org/git/?p=oonf_api.git;a=tree;f=src-plugins/dlep;h=0ec0a15a5dbe1717d786122ee5e4b433fb4550bc;hb=master ) The implementation has a few more metric TLVs, but I am planning to add a "draft-07" compile or runtime switch later. Henning Rogge From nobody Wed Nov 5 17:48: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 96D341A0010 for ; Wed, 5 Nov 2014 17:48:18 -0800 (PST) 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 C_i3TL2ErTtj for ; Wed, 5 Nov 2014 17:48:16 -0800 (PST) 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 1D3961A000C for ; Wed, 5 Nov 2014 17:48:16 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so95067lbv.38 for ; Wed, 05 Nov 2014 17:48:14 -0800 (PST) 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=UsNAT8on4uNbQJHxEPTVMeB17hDIEIbMZGObSOXxJVI=; b=Xw82L3n5D3exJEhR+MEkbZfnFxBbEsljeu3YqFx2KluqwxH0qP2tUyE7fTlGUv3gQI FHiTttytoV8sX1zpEhynNaXdhHTaCGm6H9gGxEihckf/N6Ns7sWV/FLkeK1z0BrS/+f5 bVZ/T6uJl93clSFs871ElVhPJkn5Ju1jFRwZTrrzXw7ayIaV3iJcM845DJpeIHTge1yX S8wIM6piR/eqQbwWcv/WCCogNbOkCJB2Lpot6xNNTOBPt4zo9Qr6qbFRzNPWLujxwrTT kL7aoQcw86KotMLjlZUPexyMUYDjgQvXfbdrCeo89Jrh+zEbHJa/I2yKmitlDLRAJ8WF uN1g== MIME-Version: 1.0 X-Received: by 10.152.234.163 with SMTP id uf3mr1043136lac.45.1415238494569; Wed, 05 Nov 2014 17:48:14 -0800 (PST) Received: by 10.25.14.213 with HTTP; Wed, 5 Nov 2014 17:48:14 -0800 (PST) In-Reply-To: References: <20141024143758.16624.11599.idtracker@ietfa.amsl.com> <4e633e09-ee66-48f6-b563-70e9729890c0@SUCNPTEXC01.COM.AD.UK.DS.CORP> <38A5475DE83986499AEACD2CFAFC3F9801429411F7@tss-server1.home.tropicalstormsoftware.com> Date: Wed, 5 Nov 2014 20:48:14 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a1134948ebdc827050726e3b4 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-hm4IOy0Tm-dBuFDW1nD8Ort4QM Cc: MANET IETF Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-07.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: Thu, 06 Nov 2014 01:48:18 -0000 --001a1134948ebdc827050726e3b4 Content-Type: text/plain; charset=UTF-8 Rick/Henning - CONGRATULATIONS! Two different open source implementations of DLEP. Amazing. Regards, Stan On Tue, Nov 4, 2014 at 4:54 AM, Henning Rogge wrote: > On Wed, Oct 29, 2014 at 3:56 PM, Rick Taylor > wrote: > > All, > > > > For those who are interested, the source for a sample DLEP-07 'router' > > is now available at: https://github.com/ricktaylor/dlep_router > > > > The code does not actually route, but acts as a protocol validator by > > taking on the role of a DLEP router. The license is MIT. > > > > It has been successfully used to implement and validate a DLEP modem > > implementation, and hopefully will be of use to others. > > Great that you managed to get the legal problems out of the way Rick! > > I just was on our yearly CONFINE review meeting last week, where we > demonstrated two DLEP router nodes, each with two DLEP radios based on > OpenWRT and Wifi. > > I pushed the sourcecode of my implementation into the Olsr.org Network > Framework repository into the src-plugins/dlep directory. > > (see > http://olsr.org/git/?p=oonf_api.git;a=tree;f=src-plugins/dlep;h=0ec0a15a5dbe1717d786122ee5e4b433fb4550bc;hb=master > ) > > The implementation has a few more metric TLVs, but I am planning to > add a "draft-07" compile or runtime switch later. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1134948ebdc827050726e3b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rick/Henning -=C2=A0

CONGRATULATIONS!= =C2=A0 Two different open source implementations of DLEP. Amazing.=C2=A0

Regards,
Stan

On Tue, Nov 4, 2014 at 4:54 AM, He= nning Rogge <hrogge@gmail.com> wrote:
On Wed, Oct 29, 2014 at 3:56 PM, Rick Taylor
<rick@tropicalstormsof= tware.com> wrote:
> All,
>
> For those who are interested, the source for a sample DLEP-07 'rou= ter'
> is now available at: https://github.com/ricktaylor/dlep_router
>
> The code does not actually route, but acts as a protocol validator by<= br> > taking on the role of a DLEP router.=C2=A0 The license is MIT.
>
> It has been successfully used to implement and validate a DLEP modem > implementation, and hopefully will be of use to others.

Great that you managed to get the legal problems out of the way Rick!

I just was on our yearly CONFINE review meeting last week, where we
demonstrated two DLEP router nodes, each with two DLEP radios based on
OpenWRT and Wifi.

I pushed the sourcecode of my implementation into the Olsr.org Network
Framework repository into the src-plugins/dlep directory.

(see http://olsr.org/git/?p=3Doonf_api.git;a=3Dtree;f=3Dsrc-plugins/= dlep;h=3D0ec0a15a5dbe1717d786122ee5e4b433fb4550bc;hb=3Dmaster
)

The implementation has a few more metric TLVs, but I am planning to
add a "draft-07" compile or runtime switch later.

Henning Rogge

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

--001a1134948ebdc827050726e3b4-- From nobody Fri Nov 7 11:24: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 135391A01E7 for ; Fri, 7 Nov 2014 11:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 OtjVxwpwKSiq for ; Fri, 7 Nov 2014 11:24:12 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010: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 BA28C1A0173 for ; Fri, 7 Nov 2014 11:24:11 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id z12so3201893lbi.15 for ; Fri, 07 Nov 2014 11:24:10 -0800 (PST) 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=rdi49cSyMWP+zy31QlrYW1lKRkz3y1V7SIMd8Y7G7cM=; b=y8QpMGEQBqitxI0zQN0im4qn2UYjHPfALCKnMFvwZunV3fhH5gBJbewADIzD5c/rPm yGaWT+lNKqPN1VASi/z0HdVKTdvDkvd4XlYkzqZT0mYbJYZYGxRcRPe/HFLrhVV5pVXf XYFxffN5VJxkd9NMA9dxuGl1iW3E5MhTWnXr3ezMfrTgIYppTzYt597REP7VDamuQCyr 2tmpJsRwu/aNSmL5n5t4DQxz/XFjTGxP3UqyLUPujnZxPTSwg/fqi2f2LY2ZeaCHnvH+ feqcpxqnaEiOVeKIZb/K2tKJlt2HjGqL2wgjDR5b9sF/EGe/kYVRptKCstmTsVikfpbp DjUA== MIME-Version: 1.0 X-Received: by 10.112.41.168 with SMTP id g8mr12781724lbl.59.1415388250035; Fri, 07 Nov 2014 11:24:10 -0800 (PST) Received: by 10.25.14.213 with HTTP; Fri, 7 Nov 2014 11:24:10 -0800 (PST) Date: Fri, 7 Nov 2014 14:24:10 -0500 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=001a11345d76dcde36050749c176 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9tjfVZruorgvWHrxLUUhI8mdpb4 Subject: [manet] Honolulu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 07 Nov 2014 19:24:13 -0000 --001a11345d76dcde36050749c176 Content-Type: text/plain; charset=UTF-8 Working group, Once again, I'm in the unfortunate situation of not being able to attend the IETF. FYI, Justin Dean from NRL has graciously volunteered to proxy for me in Honolulu. I will be on the jabber session, and I also plan on being in Dallas at the next IETF. Rick Taylor will be presenting for DLEP-07. Regards, Stan --001a11345d76dcde36050749c176 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Working group,=C2=A0

Once again, I'= m in the unfortunate situation of not being able to attend the IETF. FYI, J= ustin Dean from NRL has graciously volunteered to proxy for me in Honolulu.= I will be on the jabber session, and I also plan on being in Dallas at the= next IETF.=C2=A0

Rick Taylor will be presenting f= or DLEP-07.=C2=A0

Regards,
Stan
--001a11345d76dcde36050749c176-- From nobody Fri Nov 7 21:39: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 950021A037A for ; Fri, 7 Nov 2014 21:39:55 -0800 (PST) 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 uU1hYZrbaOuy for ; Fri, 7 Nov 2014 21:39:54 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6082A1A017A for ; Fri, 7 Nov 2014 21:39:54 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 10so857163ykt.3 for ; Fri, 07 Nov 2014 21:39:53 -0800 (PST) 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=UxtDu/agHG0iUMIA+/LuZEba6/hW1Ou9Y0C8QUHPaqs=; b=I53SZwPSJEL2ZEOdJE+j1AEmNVNg4jnOH0yP3Seioqd/tVVwBtsje+HDobPBQfX3d+ eiLjujvh2+wH459cXoOl3KMxWaoUq0JQUn0WqIpFdLq7//SeiZ4Be5f9VKs+wBKe5Ots nXW0K38qqDWvY6MvJRrpBfOvJJ2/ZQAAeXhVkt+FE9d0y0+x453oNF1Ee1HiLL38pVZe spsDFmnakVg9r00/LJwjanIqcMyMc4cAAR7CikvMLh5IK0EjSOw+/Z3O8TX5mUH3dV+e 23CXPq9n9PZlIt4d44m/72FwcGwEt2f27RozSmY3wcNdxy5sMphEmKLrk2se983UWhIl 3Yeg== MIME-Version: 1.0 X-Received: by 10.236.105.172 with SMTP id k32mr15528116yhg.30.1415425193678; Fri, 07 Nov 2014 21:39:53 -0800 (PST) Received: by 10.170.194.88 with HTTP; Fri, 7 Nov 2014 21:39:53 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Nov 2014 21:39:53 -0800 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GPBnxUWmawu9XttKy4Cejv0t-BU Cc: MANET IETF Subject: Re: [manet] Honolulu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 08 Nov 2014 05:39:55 -0000 Hi Stan, I wish you all the best, I have a difficulty situation as well to join or jabber-participate for the session but this is life, so I will read the minutes in future. However, do I understand that the co-chair (Mr.Macker) is available to attend, and only you are not able to attend? Thanks, AB On 11/7/14, Stan Ratliff wrote: > Working group, > > Once again, I'm in the unfortunate situation of not being able to attend > the IETF. FYI, Justin Dean from NRL has graciously volunteered to proxy for > me in Honolulu. I will be on the jabber session, and I also plan on being > in Dallas at the next IETF. > > Rick Taylor will be presenting for DLEP-07. > > Regards, > Stan > From nobody Sat Nov 8 08:56: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 A1B4C1A3BA0 for ; Sat, 8 Nov 2014 08:56:36 -0800 (PST) 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 5ASzh-rUp390 for ; Sat, 8 Nov 2014 08:56:34 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d: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 C10D81A0068 for ; Sat, 8 Nov 2014 08:56:34 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id m20so4081646qcx.30 for ; Sat, 08 Nov 2014 08:56:34 -0800 (PST) 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=zhJPHYsHlzx5jmZZiyr2gTDY8uCPFnUiQbB1FLDtgog=; b=YSUmcRVqcpuQT9jJfEDP7fO+GMWKhKelahLzOExagF6t0Vo2Qqo+Z6Uca2nQ9aIAZN s6hpxbdl66g0pmTrTWnLXw9oW6t4lrCSEHu2wngRhaQfNAVy3N/n/K7slN60FkhSqFzA KbuQ/ahNp+Ex18/jwK7gMgDdgs6fVqZwb7OrsIeIO9SELeKBmrVIbdIlV/VExQ1DEslj ChAqQTvlCi/64BElv7Vt5FLPU/wVEVjMP2cT4fNce4SglG0uVAiXMgrjIeQLfZxKOBE0 xMiV8kc2eOZhS1+o4zUP++ZL0bVzSJ3HQ96dLGb0X/bA6DIEm5m4R+F/C+pT8rSTLeOu ozSQ== MIME-Version: 1.0 X-Received: by 10.140.100.199 with SMTP id s65mr27300442qge.44.1415465793929; Sat, 08 Nov 2014 08:56:33 -0800 (PST) Received: by 10.140.34.199 with HTTP; Sat, 8 Nov 2014 08:56:33 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Nov 2014 11:56:33 -0500 Message-ID: From: Joseph Macker To: Stan Ratliff Content-Type: multipart/alternative; boundary=001a1134f606d6c6b005075bcf38 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kI8LGv3HLSZ3lYYrDw2IvtFMKqQ Cc: MANET IETF Subject: Re: [manet] Honolulu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 08 Nov 2014 16:56:36 -0000 --001a1134f606d6c6b005075bcf38 Content-Type: text/plain; charset=UTF-8 MANET WG: Several weeks back I discussed with Stan and the ADs that I intended to step down soon from the WG co-chair position as my new work responsibilities were not allowing me to dedicate the time needed to effectively fulfill chair duties. Its been great pleasure working with my co-chairs, the WG, the ADs, and other IETFers over the years in my role as co-chair. Although I feel it is time to step aside from the chair duties, I will stay interested and active as am IETF and WG member relating to various documents, discussions, and developments. As well, Justin Dean and Brian Adamson from our technical group will both be in Honolulu. Regards, Joe On Fri, Nov 7, 2014 at 2:24 PM, Stan Ratliff wrote: > Working group, > > Once again, I'm in the unfortunate situation of not being able to attend > the IETF. FYI, Justin Dean from NRL has graciously volunteered to proxy for > me in Honolulu. I will be on the jabber session, and I also plan on being > in Dallas at the next IETF. > > Rick Taylor will be presenting for DLEP-07. > > Regards, > Stan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1134f606d6c6b005075bcf38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
MANET WG:

Several weeks back I disc= ussed with Stan and the ADs that I intended to=20 step down soon from the WG co-chair position as my new work responsibilitie= s were not allowing me to dedicate the time needed to effectively fulfill c= hair duties.=C2=A0 Its been great pleasure working with my co-chairs, the W= G, the ADs, and other IETFers over the years in my role as co-chair. Althou= gh I feel it is time to step aside from the chair duties, I will stay inter= ested and active as am IETF and WG member relating to various documents, di= scussions, and developments.

As well, Justin Dean and Brian Adamson = from our technical group will both be in Honolulu.

Regards,Joe

On F= ri, Nov 7, 2014 at 2:24 PM, Stan Ratliff <ratliffstan@gmail.com>= ; wrote:
Working group,=C2=A0

Once again, I'm in t= he unfortunate situation of not being able to attend the IETF. FYI, Justin = Dean from NRL has graciously volunteered to proxy for me in Honolulu. I wil= l be on the jabber session, and I also plan on being in Dallas at the next = IETF.=C2=A0

Rick Taylor will be presenting for DLE= P-07.=C2=A0

Regards,
Stan

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


--001a1134f606d6c6b005075bcf38-- From nobody Sun Nov 9 02:18: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 66DD21A1A7B for ; Sun, 9 Nov 2014 02:18:08 -0800 (PST) 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 Glvizo23OGvv for ; Sun, 9 Nov 2014 02:18:01 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A141A1A75 for ; Sun, 9 Nov 2014 02:18:01 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sA9AHvm2002977; Sun, 9 Nov 2014 10:17:57 GMT Received: from 950129200 (dhcp-93ef.meeting.ietf.org [31.133.147.239]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sA9AHseb002902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Nov 2014 10:17:56 GMT From: "Adrian Farrel" To: "'Ulrich Herberg'" , "'Abdussalam Baryun'" References: In-Reply-To: Date: Sun, 9 Nov 2014 10:17:52 -0000 Message-ID: <009801cffc06$6db53830$491fa890$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJ/eaz0gH/MBmH3vHMQx6tc57fa5QHMBZF4AbM1hyYAvd5FwgIaehEMAaWIiQCauS7cQA== X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21086.006 X-TM-AS-Result: No--50.077-10.0-31-10 X-imss-scan-details: No--50.077-10.0-31-10 X-TMASE-MatchedRID: 0+daXaNUWRWnykMun0J1wovtmwtVGLEkxQ7dj5rD+RsM74Nf6tTB9lN5 viVwMlbwtxZcFma2HaOuOBfUARccg6da3lkmOSXHTQh9A4m9EtGqz79O2UwfU2rhyhOS2sZfEvU KU/XaDaFmrB5cuCmatpKzuAhMjt7A/7R+FCWVAJnx5KZMlKYS/VHewY36PuY06hZU4NcBZ9zS7l 9oY/zO1AtWythcaF3JjwJHQNUNYSum3t4b0+rBhRi14cCd2FejeMJNs2i8tlG1YUw9VHYKvFYWw xB9tw0TBoYTDMh1ioFb8uIpsgPIHflXbaRPf/X2ypeMiaCPnxt3gvNDlwkK8z/oq2Q2zZnDmUsp xG5jCj5toADCxM15sfumyOC/eNMcGbTnRO3CTh1jiC4p+/AIFovOGTCbVKU4cBu9rPc/2X94Tof g6Z0lvklzFJ+vo5FAnKN1xDr3u6GwQEC6hpSor4fCei5tLsNheAMrU+Up6DRjDwvnuleh3lPWus 3yxQNWxiZAAiQig4T80wK+80FbY4+zYsfILtVlALBxQHkJtWpEkrrs6EaaQ+MHX2e+FnuNMRHh9 wgoOpZKHVOvUDMU6Hk6K9zBlCiCYmchNlDsuBzSskv4lWM+JdtXpuklx0A9j+iqd2Odj/BaIwff ERDGg7CnJvwPUiLhiSBtKT/MiwZNfs8n85Te8v7E6GNqs6ceXqkpjF9F0ilftWAjZJtE1Hyef22 ep6XYkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/manet/51Axo9-3u-DM8Np5h826ZAurKeY Cc: manet@ietf.org Subject: Re: [manet] Agenda 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: Sun, 09 Nov 2014 10:18:09 -0000 All, Thanks for this conversation. As AD I would like to take 15 or 20 minutes at the end of the meeting to discuss the future of the WG and the next steps. Ulrich, can you please put me at the end of the published agenda. Please understand that no decisions will be made during the meeting. I will share some ideas with you, ask some questions, and seed a discussion that will take place on the mailing list. I will, of course, talk to Stan first as seated chair, and I'll be taking input from Joe and Ulrich as outgoing chair and secretary. Thanks, Adrian > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 31 October 2014 17:44 > To: Abdussalam Baryun > Cc: manet@ietf.org > Subject: Re: [manet] Agenda > > AB, > > I had requested 2 hours, but we have been assigned a 2.5 hours slot. > This happens since the scheduling is difficult. Better to have a > longer slot and end early than having too little time. It's not > possible to reschedule the MANET meeting. Also, I think it's good to > have some extra time in case some of the slots go a little over time > (so the chairs don't have to cut short a discussion immediately). > Having 40 minutes open discussion without agenda is a bad use of the > time in my opinion. > > Regards > Ulrich > > On Thu, Oct 30, 2014 at 10:30 PM, Abdussalam Baryun > wrote: > > Hi Ulrich, > > > > The meeting session (I) below is 2.5 hours long, but the time used in > > agenda is 2 hours. Either we may request only 2 hours only and amend > > the session time to 9-11, or amend open-discussion time as 40 minutes. > > > > AB > > > > ------- > > Mobile Ad hoc Networks (MANET) Agenda > > > > Meeting : IETF 91 Thursday November 13, 2014 > > Time : 0900-1130 Morning Session I > > Location : Lehua Suite > > Chairs : Joseph Macker > > Stan Ratliff > > Secretary : Ulrich Herberg > > Jabber : xmpp:manet@jabber.ietf.org > > Scribe : > > Minutes : > > Audiocast : > > URLs : http://www.ietf.org/html.charters/manet-charter.html > > http://tools.ietf.org/wg/manet/ > > ========================================================= > > AGENDA > > > > o Administrivia > > > > - Mailing list: manet@ietf.org > > - Scribe(s) > > - Blue Sheets > > - State your name at the microphone > > - IPR > > > > o Bash the Agenda [5] > > > > o WG Status/Overview [10] > > - Recap of Documents/Status > > - Announcements > > > > o draft-ietf-manet-dlep: Taylor [15] > > > > o draft-ietf-manet-aodvv2: Perkins [20] > > > > o draft-ietf-manet-olsrv2-multipath: Yi [20] > > > > o draft-ietf-manet-smf-sec-threats: Yi [10] > > > > o draft-clausen-manet-olsrv2-sec-threats: Yi [10] > > > > o draft-gerla-manet-odmrp: Clausen (proxying Colin de Verdiere) [20] > > > > o Open Microphone - Discussion, Related Work & Announcements [10] > > - Interops, Implementations, Other Items > > > > > > On 10/30/14, Ulrich Herberg wrote: > >> Thanks. I have updated the agenda accordingly. > >> http://www.ietf.org/proceedings/91/agenda/agenda-91-manet > >> > >> On Thu, Oct 30, 2014 at 4:46 AM, Taylor, Rick > >> wrote: > >>> Hi Ulrich, > >>> > >>> I believe I (Rick) will be covering the DLEP topics for Stan and the > >>> team. > >>> > >>> Cheers, > >>> > >>> Rick > >>> > >>>> -----Original Message----- > >>>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas > >>>> Clausen > >>>> Sent: 30 October 2014 07:35 > >>>> To: Ulrich Herberg > >>>> Cc: manet@ietf.org > >>>> Subject: Re: [manet] Agenda > >>>> > >>>> While we're at it, I believe that smf-sec-threats and olsrv2-sec-threats > >>>> will, > >>>> also, be Yi and not Clausen... > >>>> > >>>> Thomas > >>>> > >>>> Sent from my iPad > >>>> > >>>> > On 30 Oct 2014, at 06:34, Ulrich Herberg wrote: > >>>> > > >>>> > Hi, > >>>> > > >>>> > Please verify the preliminary agenda: > >>>> > https://tools.ietf.org/wg/manet/agenda > >>>> > > >>>> > Regards > >>>> > Ulrich > >>>> > > >>>> > > >>>> > Sent from my iPhone > >>>> > > >>>> > _______________________________________________ > >>>> > 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 > >>> The information contained within this e-mail and any files attached to > >>> this e-mail is private and in addition may include commercially sensitive > >>> information. The contents of this e-mail are for the intended recipient > >>> only and therefore if you wish to disclose the information contained > >>> within this e-mail or attached files, please contact the sender prior to > >>> any such disclosure. > >>> > >>> If you are not the intended recipient, any disclosure, copying or > >>> distribution is prohibited. Please also contact the sender and inform them > >>> of the error and delete the e-mail, including any attached files from your > >>> system. > >>> > >>> Emails to Airbus DS Limited may be processed, recorded and monitored > >>> anywhere in the European Community. > >>> > >>> > >>> Airbus DS Limited > >>> > >>> Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , > >>> NP10 8FZ. > >>> Registered in England and Wales under company number 04191036 > >> > >> _______________________________________________ > >> 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 Sun Nov 9 16:59: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 E6DCD1A87D2 for ; Sun, 9 Nov 2014 16:59:17 -0800 (PST) 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 b9RcX9lEKM1r for ; Sun, 9 Nov 2014 16:59:16 -0800 (PST) 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 B53371A87DB for ; Sun, 9 Nov 2014 16:59:16 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq12so901686vcb.37 for ; Sun, 09 Nov 2014 16:59:15 -0800 (PST) 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=PUmhHjzxNTgz5WHnFOOohjC6f99HsLx13IqrJIVx4Tw=; b=0eFYM9RaVgy0dM3o450omT4KvgarBvhVvcW2TiPzaGFt9hQLFT4kK3+mOVF85CGc5a baBq85TAsCXysaxdB+8HRpnEGgkV4Hgiveeo0XX5AZQnABqX2pIXOqh2KMf6aFp7nv9I x7/PZQBr8ErAkZdTMCGib8VWXxIm8luOEoXiw= 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=PUmhHjzxNTgz5WHnFOOohjC6f99HsLx13IqrJIVx4Tw=; b=OcaWKxdgEq6QxvP6m0ALej2/wodswuMzl+T+wceTe3C5KVQ2SwiiFtdnfP0SuVKNCb acjiix2m+1gWLNAjIEvBDHw40r7UJ1vbRc0qrXMslb2bCYiWDB4eQw3ty886SLqDngto 27kOOWU1N9Rk93YJ5DWGTdynUsSbsHc6ZchXe5mbAJm4u/aRH2tDCQJyvC7EaZv3SQUW ZCY8SV4WKm94DvDjNPu71BsQFMISclQf7eUKFkaIWonwwafwUr3Q0vazJBJYGxAF0FDK YWqehGUIAGF7NeRr8v11kgypYUDoDqIa1E+AZ8Uvzag6rEP6V7Wkx3Y1CrMBwq4ppnpP 4THA== X-Gm-Message-State: ALoCoQnS0An+QtvRdu/p+RERgmTBN1cqd2jz4sWPzEMaDsq/K1APine1SlXEzGd4HsSycHBb782g MIME-Version: 1.0 X-Received: by 10.220.11.68 with SMTP id s4mr9229958vcs.15.1415581155848; Sun, 09 Nov 2014 16:59:15 -0800 (PST) Received: by 10.220.96.13 with HTTP; Sun, 9 Nov 2014 16:59:15 -0800 (PST) Date: Sun, 9 Nov 2014 16:59:15 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org, Justin Dean Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-rYhq-AoG49gUMlt3XQg75jaRvU Subject: [manet] Slides + jabber/scribe request X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 10 Nov 2014 00:59:18 -0000 Hi, please send your slides to Justin (in CC) and to me by Tuesday evening. Justin will proxy-chair the WG session. We also need volunteers for jabber and minutes takers. Thanks! Ulrich From nobody Sun Nov 9 18:37: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 3020E1A889C; Sun, 9 Nov 2014 18:37:20 -0800 (PST) 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 ErllOva_r2a7; Sun, 9 Nov 2014 18:37:18 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3BA1A8832; Sun, 9 Nov 2014 18:37:18 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so3058414ykr.37 for ; Sun, 09 Nov 2014 18:37:17 -0800 (PST) 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=zFkaJSnXNqMn6yIFYJDWHXarAYixGMJ/10hWoXuB16Y=; b=AyxYbm56sruvwImw7ek7FmRHrEHuCuhn58NE6Wn64zPe/yuQerklayJE26obTgf+5x CPIBuEYkBuuzoXyaVg302MbhoJHm/u3NcieFZeIMXOx3ikf+sy/nxNYhGboiCNWvyqnQ FFR+SZGfRCmFOpukCt2PZBBCH7kdcMymmbQuZEn4KO1TS4juX6QeRnoF1wCfWyGyzrpj 7clyaTD+Ks63ai31rhRArPUDKZA9eoMScNCK9IgF4YhWfcK9mNCjNlsenjvwnflRz43S OOF0YtwquBgd47cP5tAIImEx9HB3o/w3cGeu6cJ/f55SIXPp6eTI0BXoW6R/m5CJpncF PIuw== MIME-Version: 1.0 X-Received: by 10.236.199.78 with SMTP id w54mr27069568yhn.148.1415587037387; Sun, 09 Nov 2014 18:37:17 -0800 (PST) Received: by 10.170.194.88 with HTTP; Sun, 9 Nov 2014 18:37:17 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Nov 2014 18:37:17 -0800 Message-ID: From: Abdussalam Baryun To: "manet-ads@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9Kdz46wOA9zE2tVcaldmNwZTbMc Cc: IETF Chair , MANET IETF , "iesg@ietf.org" Subject: Re: [manet] Honolulu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 10 Nov 2014 02:37:20 -0000 Dear ADs responsible for MANET WG, CC: IETF Chair and IESG I notice that in one of previous IETF meeting of the MANET WG had been meeting without a full power co-chair, and that was IMHO not a good practice but I thought it can happen once within a year or two. I am not accepting having IETF MANET WG (I as a participant in the MANET WG) running without active full role of assigned management, any lack of management representation/activity can be a lack of performance. However, IMHO having this shortage of chair power within IETF WG meeting can affect WG performance, its activities within this meeting and can give a bad reaction from the new participants. IMHO each IETF WG MUST have a full powered chair attended so that IDs/participants become active and progressed.IMHO, the ADs cannot take over this role of WG chair within meeting-week, because usually ADs are more bussy with other problems and they have many WGs per area. If I understand the IETF procedure right the assignement of co-chair powers is the responsibility of ADs. I request that the ADs assign temporarly a full powered and responsible chair at least for this meeting session. So that the community/people can talk directly to the assigned WG Chair. I suggest as supporting what was mentioned below by Joe and Stan that: Justin or Brian or both chair the session but also I will suggest that one of them or they become assigned as co-chair for at least this Honolulu week-meeting (there is another option that you can assign an active WG chair from another WG to attend and chair the MANET activities). I hope the IESG takes this problem into consideration and make sure it does not happen in any IETF WG. Please note that not assigning a presented WG chair with full procedure powers for a IETF WG meeting-week may mean that the IETF does not care of the WG activities or the attendance participants needs. This problem should also be discussed by community for procedure/practical considerations within the IETF General Area to be solved Best Regards AB IETF Participant from Africa On 11/8/14, Joseph Macker wrote: > MANET WG: > > Several weeks back I discussed with Stan and the ADs that I intended to > step down soon from the WG co-chair position as my new work > responsibilities were not allowing me to dedicate the time needed to > effectively fulfill chair duties. Its been great pleasure working with my > co-chairs, the WG, the ADs, and other IETFers over the years in my role as > co-chair. Although I feel it is time to step aside from the chair duties, I > will stay interested and active as am IETF and WG member relating to > various documents, discussions, and developments. > > As well, Justin Dean and Brian Adamson from our technical group will both > be in Honolulu. > > Regards, > Joe > > On Fri, Nov 7, 2014 at 2:24 PM, Stan Ratliff wrote: > >> Working group, >> >> Once again, I'm in the unfortunate situation of not being able to attend >> the IETF. FYI, Justin Dean from NRL has graciously volunteered to proxy >> for >> me in Honolulu. I will be on the jabber session, and I also plan on being >> in Dallas at the next IETF. >> >> Rick Taylor will be presenting for DLEP-07. >> >> Regards, >> Stan >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > From nobody Mon Nov 10 12:25: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 1934B1ACE4B for ; Mon, 10 Nov 2014 12:25:43 -0800 (PST) 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 nHNsb4RlOd6A for ; Mon, 10 Nov 2014 12:25:40 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010: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 84BE71ACE52 for ; Mon, 10 Nov 2014 12:24:30 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gq15so8467087lab.29 for ; Mon, 10 Nov 2014 12:24:27 -0800 (PST) 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=0jqdgR7WTpMUOPIgE6P6AFpTqfgkJYM+qn9sSDgL/fw=; b=WfP4KtsjstxVCJ7sQkDdx3gqiHIcuOL/6ByXS6RbUDnHSKFUerJ8kmklMpFvk2yW/d w/5YtJIuXufVIzQxUzGQFI+/q9cGYHj+IAsU8LR2YF6SJAoeuUDNvKhh78TwpuawW/vL LgCbBkDaD7dB6H6L70Su8ZO4arWgw2sWUF+fKY2AFfJN+AI5+9NyjL/EPzAoEezStp01 7TM5h3uugI2JmkmI74W/VN7bZkdHhTx/JWIrvodQ2obTVuBA3LJfS0kxkwmGh0F/zmeT EL5D2ZaTbrb7hHttQ9KWyykqxni80SdKU92bCw7svawdA1dA+Lt4qHFLakwmbB00+EaF auzA== MIME-Version: 1.0 X-Received: by 10.152.37.69 with SMTP id w5mr5084475laj.84.1415651067700; Mon, 10 Nov 2014 12:24:27 -0800 (PST) Received: by 10.152.10.209 with HTTP; Mon, 10 Nov 2014 12:24:27 -0800 (PST) In-Reply-To: <20141027220338.24511.50657.idtracker@ietfa.amsl.com> References: <20141027220338.24511.50657.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 15:24:27 -0500 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=089e0160ac88042916050786f3f3 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wtubjxjpR0M48wLG4Fk5L6S_BYg Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:25:43 -0000 --089e0160ac88042916050786f3f3 Content-Type: text/plain; charset=UTF-8 Having briefly looked over the updated draft, I've a few comments. This is not meant to be a comprehensive review of the draft. In no particular order. The definition of Originating Node (OrigNode) (and TargNode) are self referencing and incomplete. They should at least reference AODVv2 Router. Also the terms OrigNode and TargNode are later used as what seems like addresses in an AODVv2 message. I suggest separating the definition of a node (an AODVv2 Router?) from an address of that node/router (suggest OrigNodeAddr) The term "invalid" is used a few times when a more specific reference to the defined term "broken" and/or "expired" should be used. In the "RteMsg Structure" section the list says that the OrigNode should be included in the message header, the packet diagram doesn't include this information as it doesn't expand the message header. This would be fine but then the OrigNode is then included again the address block which is confusing. Later it's described that OrigNode should indeed be included in the address block but it happens after the diagram. Also, is there a reason the OrigNode is included twice? It's not clear to me the difference between the states "broken" and "expired" (other than how they reached that state) They are both invalid states and regardless of how the state was obtained the routes shouldn't be used. The only difference I could find is that "expired" routes MAY be expunged while there is no such text regarding "broken" routes. Broken is also used in reference to broken link and later BrokenRoute without the terms being defined in the document definitions. It may make sense to unify these states regardless of how they are obtained into a single term and reduce the number of states a route can have (unless there is something operationally different that should be done that I'm missing) The addition of the "timed" state requires updating in a few other places in the document when route state is referenced. The "Route Table Entry Timeouts" section for example may need to be updated. Orig.Tail and Targ.Tail should be Orig.Mid and Targ.Mid as the tail term is used for common bits of an address among the addresses listed. Justin On Mon, Oct 27, 2014 at 6:03 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Authors : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-aodvv2-05.txt > Pages : 67 > Date : 2014-10-27 > > 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-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0160ac88042916050786f3f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Having briefly looked over the = updated draft, I've a few comments. This is not meant to be a comprehen= sive review of the draft.

In no particular order.

The definition of=C2=A0Originating Node (OrigNode) (and TargNode) are self referencing a= nd incomplete.=C2=A0 They should at least reference AODVv2 Router.=C2=A0 Al= so the terms OrigNode and TargNode are later used as what seems like addres= ses in an AODVv2 message.=C2=A0 I suggest=C2=A0separating=C2=A0the definiti= on of a node (an AODVv2 Router?) from an address of that node/router (sugge= st OrigNodeAddr)

Th= e term "invalid" is used a few times when a more specific referen= ce to the defined term "broken" and/or "expired" should= be used.
In the &q= uot;RteMsg Structure" section = the list says that the OrigNode should be included in the message header, t= he packet diagram doesn't include this information as it doesn't ex= pand the message header.=C2=A0 This would be fine but then the OrigNode is = then included again the address block which is confusing.=C2=A0 Later it= 9;s described that OrigNode should indeed be included in the address block = but it happens after the diagram.=C2=A0 Also, is there a reason the OrigNod= e is included twice?

It's not clear to me the difference between= the states "broken" and "expired" (other than how they= reached that state) =C2=A0They are both invalid states and regardless of h= ow the state was obtained the routes shouldn't be used.=C2=A0 The only = difference I could find is that "expired" routes MAY be expunged = while there is no such text regarding "broken" routes.=C2=A0 Brok= en is also used in reference to broken link and later BrokenRoute without t= he terms being defined in the document definitions.=C2=A0 It may make sense= to unify these states regardless of how they are obtained into a single te= rm and reduce the number of states a route can have (unless there is someth= ing operationally different that should be done that I'm missing)

The ad= dition of the "timed" state requires updating in a few other plac= es in the document when route state is referenced.=C2=A0 The "Route Ta= ble Entry Timeouts" section for example may need to be updated.=

Orig.Ta= il and Targ.Tail should be Orig.Mid and Targ.Mid as the tail term is used f= or common bits of an address among the addresses listed.=C2=A0

Justin

On Mon, Oct 27, 2014 at 6:03 PM, <internet-drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Dynamic MANET On-demand (AODVv2) Routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Char= les E. Perkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Stan Ratliff
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Dowdell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-aodvv2-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 67
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-27

Abstract:
=C2=A0 =C2=A0The revised Ad Hoc On-demand Distance Vector (AODVv2) routing<= br> =C2=A0 =C2=A0protocol is intended for use by mobile routers in wireless, mu= ltihop
=C2=A0 =C2=A0networks.=C2=A0 AODVv2 determines unicast routes among AODVv2 = routers
=C2=A0 =C2=A0within the network in an on-demand fashion, offering rapid
=C2=A0 =C2=A0convergence in dynamic topologies.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-aodvv2-05

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


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

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

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

--089e0160ac88042916050786f3f3-- From nobody Mon Nov 10 17:58: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 44E3B1AD403; Mon, 10 Nov 2014 17:58:49 -0800 (PST) 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 G1csMcPLTXAS; Mon, 10 Nov 2014 17:58:46 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83011AD3FD; Mon, 10 Nov 2014 17:58:45 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAB1whl9011783; Tue, 11 Nov 2014 01:58:43 GMT Received: from 950129200 (dhcp-b3f6.meeting.ietf.org [31.133.179.246]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAB1wciU011769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 01:58:40 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , References: In-Reply-To: Date: Tue, 11 Nov 2014 01:58:35 -0000 Message-ID: <05f601cffd53$043a3470$0cae9d50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI5b0qwpCK6Tc2HQwR6szPeYg8UdAHP3hhwAzSk66ObX5D3QA== X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21090.004 X-TM-AS-Result: No--23.727-10.0-31-10 X-imss-scan-details: No--23.727-10.0-31-10 X-TMASE-MatchedRID: 0+daXaNUWRV5X0FJZbmEppmug812qIbzDYBVKmbeeQOHt85FHJrJdl61 yIFuQn6kfwL0BDxoclII5Lh+LXfcQlcotqvUhZyqq1ZJZ2z+SbaSiza26cvwNDhZSwDkDbchEk4 ISZkkpSgAjD7lyj7yydBIrO2CTPUrfbes11l7cYymQhbcat5/fUsBGM5Y1AXMxa4NdQLA8l5cfd b7nucZ+UU2lnQpsjtcBEcGcZ/BA3Lz50g+jp9gnkNTnAhL0/m3BdebOqawiLtjPrlNB+gMqxTBD 7OX80sLkeeMO2v/dO7rMXUhak92cLrHY8Lbk0RmzNY33yIEF4Z3gvNDlwkK8y9+vUEmYLuGJMJX DJjkqdQ8kwWJvEthdM+fDGyEtUiKwQSURGcMkcKtsIbr5F2ZLbNYRMFA9XfyfyxIhnjLMSkvJzn hGcyqKm2oA6gKi0G35rN2YLM0p4Q/tAk1apUmVC1Hx9UxMGjdQa2sDHLkQ07Z7ve0lygT2CITlW s6BAHi66in67Vz+4oeSpAsIzcd63iNsp9EKWtTJrUxoq6hvw9+Mk6ACsw4JuOxOq7LQlGLxYjkM gBz90e+1n1voNDiOnxv1u/GlUCJSr6L0atbOCxqBuOKdbjXytJ178I1tpkl5WzwM2rTaELeQ0ny 4xLfM5Rg+a1Bbv8FliXG6TWiBAD7OgBbxHXmXxzwnpmtY/+rfS0Ip2eEHnzUHQeTVDUrItRnEQC UU+jzjoczmuoPCq2UTGVAhB5EbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HETrzbkexPNfclhiVty8XUSrb4Y Cc: 'IETF Chair' , 'MANET IETF' , iesg@ietf.org Subject: Re: [manet] Honolulu 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, 11 Nov 2014 01:58:49 -0000 Abdussalam, Thank you for your email. Sometimes events arise that make it impossible for people to travel to = IETF meetings. Sometimes those events are last minute and unavoidable. = Sometimes the reasons are personal and it would be inappropriate to go = into them on a public list. In general, if a chair finds that she is repeatedly unable to attend = then she might consider her position. But attendance at meetings is not = a prerequisite especially when the co-chair can travel. The chair at a working group meeting is a meeting facilitator: they = cause the meeting to happen according to the agenda and try to stop = people hitting each other. The "proxy chair" is the person sitting at = the front of the room doing that. Justin has full powers and authority = to fill that role. But WG chairs do not "make decisions" at working group meetings, so = there is no lack in this respect and Stan remains in place as WG chair = filling that role. I will be looking to replace Joe as Stan's co-chair = soon, and this meeting offers me a good chance to talk to some people = about that. So, it is my contention that Justin will serve as a fully functional = chair for this meeting. Now, there is one other point you are making which is that it is = important for the community to be able to talk to the chair. I agree. It = is highly desirable for the chairs to travel. But sometimes it is not = possible. Obviously (?) we could have cancelled the meeting, but that = doesn't seem optimal. So we are as we are. Beyond this, I don't understand your issue. Sorry. Can you give me an = example of a question that needs to be answered, face-to-face, during = the meeting that you think Justin is not allowed to answer, that cannot = be handled by email with the absent chair, but that a "fully empowered" = WG chair could answer? Or maybe there is some action you think a chair = might need to take during the meeting that Justin is not be allowed to = handle? Adrian > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 10 November 2014 02:37 > To: manet-ads@tools.ietf.org > Cc: Stan Ratliff; MANET IETF; IETF Chair; iesg@ietf.org > Subject: Re: [manet] Honolulu >=20 > Dear ADs responsible for MANET WG, > > CC: IETF Chair and IESG >=20 > I notice that in one of previous IETF meeting of the MANET WG had been > meeting without a full power co-chair, and that was IMHO not a good > practice but I thought it can happen once within a year or two. I am > not accepting having IETF MANET WG (I as a participant in the MANET > WG) running without active full role of assigned management, any lack > of management representation/activity can be a lack of performance. > However, IMHO having this shortage of chair power within IETF WG > meeting can affect WG performance, its activities within this meeting > and can give a bad reaction from the new participants. IMHO each IETF > WG MUST have a full powered chair attended so that IDs/participants > become active and progressed.IMHO, the ADs cannot take over this role > of WG chair within meeting-week, because usually ADs are more bussy > with other problems and they have many WGs per area. If I understand > the IETF procedure right the assignement of co-chair powers is the > responsibility of ADs. >=20 > I request that the ADs assign temporarly a full powered and > responsible chair at least for this meeting session. So that the > community/people can talk directly to the assigned WG Chair. I suggest > as supporting what was mentioned below by Joe and Stan that: Justin or > Brian or both chair the session but also I will suggest that one of > them or they become assigned as co-chair for at least this Honolulu > week-meeting (there is another option that you can assign an active WG > chair from another WG to attend and chair the MANET activities). I > hope the IESG takes this problem into consideration and make sure it > does not happen in any IETF WG. >=20 > Please note that not assigning a presented WG chair with full > procedure powers for a IETF WG meeting-week may mean that the IETF > does not care of the WG activities or the attendance participants > needs. This problem should also be discussed by community for > procedure/practical considerations within the IETF General Area to be > solved >=20 > Best Regards >=20 > AB >=20 > IETF Participant from Africa >=20 > On 11/8/14, Joseph Macker wrote: > > MANET WG: > > > > Several weeks back I discussed with Stan and the ADs that I intended = to > > step down soon from the WG co-chair position as my new work > > responsibilities were not allowing me to dedicate the time needed to > > effectively fulfill chair duties. Its been great pleasure working = with my > > co-chairs, the WG, the ADs, and other IETFers over the years in my = role as > > co-chair. Although I feel it is time to step aside from the chair = duties, I > > will stay interested and active as am IETF and WG member relating to > > various documents, discussions, and developments. > > > > As well, Justin Dean and Brian Adamson from our technical group will = both > > be in Honolulu. > > > > Regards, > > Joe > > > > On Fri, Nov 7, 2014 at 2:24 PM, Stan Ratliff = wrote: > > > >> Working group, > >> > >> Once again, I'm in the unfortunate situation of not being able to = attend > >> the IETF. FYI, Justin Dean from NRL has graciously volunteered to = proxy > >> for > >> me in Honolulu. I will be on the jabber session, and I also plan on = being > >> in Dallas at the next IETF. > >> > >> Rick Taylor will be presenting for DLEP-07. > >> > >> Regards, > >> Stan > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > >> > >> > > From nobody Mon Nov 10 18:53: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 A8DFA1A8849; Mon, 10 Nov 2014 18:53:14 -0800 (PST) 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 iti_2n3C4EAQ; Mon, 10 Nov 2014 18:53:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A54001AD4BE; Mon, 10 Nov 2014 18:53:10 -0800 (PST) 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.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141111025310.32495.73915.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 18:53:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qKnZfp0hX0WOpk5pbdhE1XLGYkA Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6779bis-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, 11 Nov 2014 02:53:15 -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 Neighborhood Discovery Protocol Authors : Ulrich Herberg Robert G. Cole Ian D Chakeres Thomas Heide Clausen Filename : draft-ietf-manet-rfc6779bis-01.txt Pages : 70 Date : 2014-11-10 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6779bis-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 Mon Nov 10 18:57: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 1D7801A887C for ; Mon, 10 Nov 2014 18:57:10 -0800 (PST) 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 LCDeafUDt_ua for ; Mon, 10 Nov 2014 18:57:08 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E321A00EB for ; Mon, 10 Nov 2014 18:57:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3D0541C02DA for ; Mon, 10 Nov 2014 18:57:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.5.29] (unknown [64.129.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BAC5B1C01AC for ; Mon, 10 Nov 2014 18:57:07 -0800 (PST) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_F4B10381-40ED-48D0-AB94-E522814BED5F" Message-Id: <0BB502C5-1CF0-4D2B-8CB8-D70582E8807F@thomasclausen.org> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Date: Tue, 11 Nov 2014 03:57:06 +0100 References: <20141111025310.32495.73915.idtracker@ietfa.amsl.com> To: manet In-Reply-To: <20141111025310.32495.73915.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ctd0mHMYqYIROpxcL4lIIQUqq_s Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc6779bis-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, 11 Nov 2014 02:57:10 -0000 --Apple-Mail=_F4B10381-40ED-48D0-AB94-E522814BED5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, This is just a =E2=80=9Cmaintenance revision=E2=80=9D that removes a = editorial artefact that made IDNITS whine =E2=80=94 and which, = therefore, would make the shepherd whine also. http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6779bis-01 = Cheers, Thomas > On 11 Nov 2014, at 03:53 , internet-drafts@ietf.org wrote: >=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 : Definition of Managed Objects for the = Neighborhood Discovery Protocol > Authors : Ulrich Herberg > Robert G. Cole > Ian D Chakeres > Thomas Heide Clausen > Filename : draft-ietf-manet-rfc6779bis-01.txt > Pages : 70 > Date : 2014-11-10 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6779bis-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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_F4B10381-40ED-48D0-AB94-E522814BED5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

This = is just a =E2=80=9Cmaintenance revision=E2=80=9D that removes a = editorial artefact that made IDNITS whine =E2=80=94 and which, = therefore, would make the shepherd whine also.

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6779bis-= 01

Cheers,

Thomas


On 11 Nov 2014, at 03:53 , internet-drafts@ietf.org wrote:


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Mobile = Ad-hoc Networks Working Group of the IETF.

=        Title =           : Definition = of Managed Objects for the Neighborhood Discovery Protocol
=        Authors =         : Ulrich Herberg
=             &n= bsp;           &nbs= p;Robert G. Cole
=             &n= bsp;           &nbs= p;Ian D Chakeres
=             &n= bsp;           &nbs= p;Thomas Heide Clausen
Filename =        : = draft-ietf-manet-rfc6779bis-01.txt
Pages =           : 70
= Date =            : = 2014-11-10

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.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/

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

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6779bis-= 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/

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

= --Apple-Mail=_F4B10381-40ED-48D0-AB94-E522814BED5F-- From nobody Mon Nov 10 19:32: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 307BA1AD47A for ; Mon, 10 Nov 2014 19:32:19 -0800 (PST) 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 YVftJ0fxTgM4 for ; Mon, 10 Nov 2014 19:32:16 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0761AD507 for ; Mon, 10 Nov 2014 19:32:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C6CAC1C0677; Mon, 10 Nov 2014 19:32:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.5.29] (unknown [64.129.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 208201C02DA; Mon, 10 Nov 2014 19:32:11 -0800 (PST) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_F9F4D0C0-D4E8-47FB-BD9C-0C56E8F8C314" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Date: Tue, 11 Nov 2014 04:32:08 +0100 References: <20141111005114.27018.49670.idtracker@ietfa.amsl.com> To: manet X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SI7zmaCRqWjyDCkU74SR7qLPBh0 Subject: [manet] draft-ietf-manet-olsrv2-multitopology and draft-dearlove-manet-tlv-naming-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, 11 Nov 2014 03:32:19 -0000 --Apple-Mail=_F9F4D0C0-D4E8-47FB-BD9C-0C56E8F8C314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since, of course, all y=E2=80=99all are compulsively reading the = ID-announce mailing list ;) you=E2=80=99ll have seen = draft-dearlove-manet-tlv-naming-00.txt document appear just today. This is in response to the review from our AD on = draft-ietf-manet-olsrv2-multitopology = (http://www.ietf.org/mail-archive/web/manet/current/msg16875.html = ), in = which he indicates that we probably should re-think the way we name TLV = types.=20 As our AD requested, the authors did re-think, discuss a bit also with = our AD and chairs, and came to a conclusion ... and that conclusion is = in this I-D. I think that it is safe to say that our AD is going to sit on, and = therefore block progress for, draft-ietf-manet-olsrv2-multitopology =E2=80= =94 and that, until we see draft-dearlove-manet-tlv-naming move ahead = (or, until we propose an alternative way forward, of course). Given that, and in case there is time on the meeting agenda, then =E2=80=94= if the WG is interested and the WG chairs believe that it will be = helpful in order to see progress =E2=80=94 I=E2=80=99d be happy to say a = few words on this topic, and try to answer any questions there might be. Either way, I believe that we=E2=80=99ll very soon be soliciting the WG = chairs to issue a call-for-WG-adoption (with a suitable lead period to = read the document), followed by a WGLC, such that this document may make = progress and =E2=80=9Cunblock=E2=80=9D = draft-ietf-manet-olsrv2-multitopology also. Best, Thomas > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: Thomas Heide Clausen , "Christopher = Dearlove" , "Thomas H. Clausen" = , Christopher Dearlove = > Subject: New Version Notification for = draft-dearlove-manet-tlv-naming-00.txt > Date: 11 Nov 2014 01:51:14 CET >=20 >=20 > A new version of I-D, draft-dearlove-manet-tlv-naming-00.txt > has been successfully submitted by Thomas Heide Clausen and posted to = the > IETF repository. >=20 > Name: draft-dearlove-manet-tlv-naming > Revision: 00 > Title: TLV Naming in the MANET Generalized = Packet/Message Format > Document date: 2014-11-10 > Group: Individual Submission > Pages: 16 > URL: = http://www.ietf.org/internet-drafts/draft-dearlove-manet-tlv-naming-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-dearlove-manet-tlv-naming/ > Htmlized: = http://tools.ietf.org/html/draft-dearlove-manet-tlv-naming-00 >=20 >=20 > Abstract: > TLVs (type-length-value structures) as defined by RFC5444 have both = a > type (one octet) and a type extension (one octet), together forming = a > full type (of two octets). RFC5444 sets up IANA registries for TLV > types, specifying that an allocation of a TLV type entails creation > of an IANA registry for the corresponding type extensions. >=20 > In some cases, reserving all 256 type extensions for use for a = common > purpose for a given TLV is meaningful, and thus it makes sense to > record a common name for such a TLV type (and all of its type > extensions) in the corresponding IANA registries. An example of = such > is a LINK_METRIC TLV Type, with its type extensions reserved for use > to be indicating the "kind" of metric expressed by the value of the > TLV. >=20 > In some other cases, there may not be 256 full types that share a > common purpose and, as such, it is not meaningful to record a common > name for all the type extensions for a TLV type in the corresponding > IANA registries. Rather, it is appropriate to record an individual > name per full type. >=20 > This document reorganizes the naming of already allocated TLV types > and type extensions in those registries to use names appropriately. > It has no consequences in terms of any protocol implementation. >=20 > This document also updates the Expert Review guidelines from = RFC5444, > so as to establish a policy for consistent naming of future TLV type > and type extension allocations. >=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=_F9F4D0C0-D4E8-47FB-BD9C-0C56E8F8C314 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since, of course, all y=E2=80=99all are compulsively reading = the ID-announce mailing list ;) you=E2=80=99ll have seen = draft-dearlove-manet-tlv-naming-00.txt document appear just today.

This is in response to = the review from our AD on draft-ietf-manet-olsrv2-multitopology (http://www.ietf.org/mail-archive/web/manet/current/msg16875.htm= l), in which he indicates that we probably should re-think the way = we name TLV types. 

As our AD requested, the authors did re-think, discuss a bit = also with our AD and chairs, and came to a conclusion ... and that = conclusion is in this I-D.

I think that it is safe to say that our AD is going to sit = on, and therefore block progress for, = draft-ietf-manet-olsrv2-multitopology =E2=80=94 and that, until we = see draft-dearlove-manet-tlv-naming move ahead (or, until we = propose an alternative way forward, of course).

Given that, and in case there is time = on the meeting agenda, then =E2=80=94 if the WG is interested  and = the WG chairs believe that it will be helpful in order to see progress = =E2=80=94 I=E2=80=99d be happy to say a few words on this topic, and try = to answer any questions there might be.

Either way, I believe that we=E2=80=99ll = very soon be soliciting the WG chairs to issue a call-for-WG-adoption = (with a suitable lead period to read the document), followed by a WGLC, = such that this document may make progress and =E2=80=9Cunblock=E2=80=9D = draft-ietf-manet-olsrv2-multitopology also.

Best,

Thomas




Begin forwarded message:

From: = internet-drafts@ietf.org
To: Thomas Heide Clausen <t.clausen@computer.org>, "Christopher Dearlove" <chris.dearlove@baesystems.com>, "Thomas H. Clausen" = <T.Clausen@computer.org>, Christopher Dearlove <chris.dearlove@baesystems.com>
Subject: = New Version = Notification for draft-dearlove-manet-tlv-naming-00.txt
Date: = 11 Nov 2014 01:51:14 CET


A = new version of I-D, draft-dearlove-manet-tlv-naming-00.txt
has been successfully submitted by Thomas Heide Clausen and = posted to the
IETF repository.

Name: = = draft-dearlove-manet-tlv-naming
Revision: 00
Title:= = TLV Naming in the MANET Generalized Packet/Message Format
Document date: 2014-11-10
Group:= = Individual Submission
Pages: 16
URL: =            http://www.ietf.org/internet-drafts/draft-dearlove-manet-tlv-na= ming-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-dearlove-manet-tlv-namin= g/
Htmlized:       http://tools.ietf.org/html/draft-dearlove-manet-tlv-naming-00


Abstract:
=   TLVs (type-length-value structures) as defined by RFC5444 = have both a
  type (one octet) and a type = extension (one octet), together forming a
=   full type (of two octets).  RFC5444 sets up IANA = registries for TLV
  types, specifying that an = allocation of a TLV type entails creation
  of = an IANA registry for the corresponding type extensions.

  In some cases, reserving all 256 type extensions = for use for a common
  purpose for a given TLV = is meaningful, and thus it makes sense to
=   record a common name for such a TLV type (and all of its = type
  extensions) in the corresponding IANA = registries.  An example of such
  is a = LINK_METRIC TLV Type, with its type extensions reserved for use
  to be indicating the "kind" of metric expressed = by the value of the
  TLV.

  In some other cases, there may not be 256 full = types that share a
  common purpose and, as = such, it is not meaningful to record a common
=   name for all the type extensions for a TLV type in the = corresponding
  IANA registries.  Rather, = it is appropriate to record an individual
=   name per full type.

=   This document reorganizes the naming of already allocated = TLV types
  and type extensions in those = registries to use names appropriately.
  It has = no consequences in terms of any protocol implementation.
  This document also updates the Expert Review = guidelines from RFC5444,
  so as to establish a = policy for consistent naming of future TLV type
=   and type extension allocations.




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=_F9F4D0C0-D4E8-47FB-BD9C-0C56E8F8C314-- From nobody Mon Nov 10 21: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 0C8511A8902 for ; Mon, 10 Nov 2014 21:16:43 -0800 (PST) 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 JSNfKsb57LJK for ; Mon, 10 Nov 2014 21:16:39 -0800 (PST) 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 C809A1A6FDD for ; Mon, 10 Nov 2014 21:16:38 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAB5Ga9L029245; Tue, 11 Nov 2014 05:16:36 GMT Received: from 950129200 (dhcp-b3f6.meeting.ietf.org [31.133.179.246]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAB5GTKT029211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 05:16:33 GMT From: "Adrian Farrel" To: "'Thomas Heide Clausen'" , "'manet'" References: <20141111005114.27018.49670.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 11 Nov 2014 05:16:26 -0000 Message-ID: <06d701cffd6e$a7e2c400$f7a84c00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D8_01CFFD6E.A7E90590" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQLhTieDAtU9PM7C7Yk1r033UGyh+QHupVkvmijKBxA= X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21090.004 X-TM-AS-Result: No--23.101-10.0-31-10 X-imss-scan-details: No--23.101-10.0-31-10 X-TMASE-MatchedRID: vWvnoyq7eMw7iuZ/mdYYtqq9wgXVNwtgaza5eRS5azT/5/8APS51IHQp 8BZ5yX4ACiwghyPO0y7HQ8MHM33wrhLXa2P1m93zut/GVGOoEneznMVe2LsE4bRbVy8AMD0Kmea 15mW1PaXD5Q7f7wyexPwkPWPMnLcwj0hFbSgsWhy1eX0jEQ9c6hWMB5o7Iv3SkEHhMDx4cljup8 ZyurINgkoNmUsFJ/yrQr2qXCJMSV9CdUZFvvy+kOouc5Rcf1B02Uta6fWK3dDJxgT0axXSzUn/S P4Y+XhM3VPZaKwV/X0JaI5LQFWiSMBZPOJYZoM8/Z2SSD7R8hSRqMDQ3aJjVYokgznjy6z3BkQr R0pCNf4m3t0yuLgV/lWeeIqHthMLFP62w4g2GqOpFqY8JHz7ML6pQeH6jDekjX12o0fS8F/2eTM y2w8sjm1yv+64My/eGFMYlDUzwr0QC81tuAfPvif6nnnZywjVqgpT1Ht6sYSQm6BojE/Wzy5ShD QVR9yTj56IjTnLR+nBVprK8rvWX6CjvIRDW3XLVfOB6z8Qn2wBPILbnBTY1U81IZd8RDSf9wpdg znfr+cq/+hVvEi1CzGfHCHX/mgUIfyQNHR2naaNC3ENm/V8D0tU4/pKr/obDsbtrO33TVeLFgnz +hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEozraubH2nx6gF+AN4QjuBe5QR mIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBeP7GAQSe5/nfbBROhn2OIGPC7j/m zpDFqfL6D8TtOZrM87s4OnYGuCwXotg6ps9+GbKItl61J/yZUdXE/WGn0FSlnU38LCY8sDhOhcz dO0btbkrsq6X+UeRRgndEtDQrK9GFANVya02RKD08lowvFK3ob5ZYbt4i0X1GrrurGFPUsMHBii 02BH Archived-At: http://mailarchive.ietf.org/arch/msg/manet/eSa-gEZX1XszPTxQhA2xnrdl-cc Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology and draft-dearlove-manet-tlv-naming-00.txt 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, 11 Nov 2014 05:16:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06D8_01CFFD6E.A7E90590 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I think that it is safe to say that our AD is going to sit on, and = therefore block > progress for, draft-ietf-manet-olsrv2-multitopology =20 Oh! Harsh use of language. But basically true. =20 So thanks to Thomas and Christopher for writing this document. I would = love for this to move fast partly because it unblocks the other draft, = and partly because it will set the WG up so that future work can be = aligned. =20 If there is time on the agenda then it would be cool to spend some time = explaining the plan f2f. =20 Adrian =20 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 Sent: 11 November 2014 03:32 To: manet Cc: Adrian Farrel Subject: draft-ietf-manet-olsrv2-multitopology and = draft-dearlove-manet-tlv-naming-00.txt =20 Since, of course, all y=E2=80=99all are compulsively reading the = ID-announce mailing list ;) you=E2=80=99ll have seen = draft-dearlove-manet-tlv-naming-00.txt document appear just today. =20 This is in response to the review from our AD on = draft-ietf-manet-olsrv2-multitopology = (http://www.ietf.org/mail-archive/web/manet/current/msg16875.html), in = which he indicates that we probably should re-think the way we name TLV = types.=20 =20 As our AD requested, the authors did re-think, discuss a bit also with = our AD and chairs, and came to a conclusion ... and that conclusion is = in this I-D. =20 I think that it is safe to say that our AD is going to sit on, and = therefore block progress for, draft-ietf-manet-olsrv2-multitopology = =E2=80=94 and that, until we see draft-dearlove-manet-tlv-naming move = ahead (or, until we propose an alternative way forward, of course). =20 Given that, and in case there is time on the meeting agenda, then = =E2=80=94 if the WG is interested and the WG chairs believe that it = will be helpful in order to see progress =E2=80=94 I=E2=80=99d be happy = to say a few words on this topic, and try to answer any questions there = might be. =20 Either way, I believe that we=E2=80=99ll very soon be soliciting the WG = chairs to issue a call-for-WG-adoption (with a suitable lead period to = read the document), followed by a WGLC, such that this document may make = progress and =E2=80=9Cunblock=E2=80=9D = draft-ietf-manet-olsrv2-multitopology also. =20 Best, =20 Thomas Begin forwarded message: =20 From: internet-drafts@ietf.org To: Thomas Heide Clausen , "Christopher = Dearlove" , "Thomas H. Clausen" = , Christopher Dearlove = Subject: New Version Notification for = draft-dearlove-manet-tlv-naming-00.txt Date: 11 Nov 2014 01:51:14 CET =20 A new version of I-D, draft-dearlove-manet-tlv-naming-00.txt has been successfully submitted by Thomas Heide Clausen and posted to = the IETF repository. Name: draft-dearlove-manet-tlv-naming Revision: 00 Title: TLV Naming in the MANET Generalized Packet/Message = Format Document date: 2014-11-10 Group: Individual Submission Pages: 16 URL: = http://www.ietf.org/internet-drafts/draft-dearlove-manet-tlv-naming-00.tx= t Status: = https://datatracker.ietf.org/doc/draft-dearlove-manet-tlv-naming/ Htmlized: = http://tools.ietf.org/html/draft-dearlove-manet-tlv-naming-00 Abstract: TLVs (type-length-value structures) as defined by RFC5444 have both a type (one octet) and a type extension (one octet), together forming a full type (of two octets). RFC5444 sets up IANA registries for TLV types, specifying that an allocation of a TLV type entails creation of an IANA registry for the corresponding type extensions. In some cases, reserving all 256 type extensions for use for a common purpose for a given TLV is meaningful, and thus it makes sense to record a common name for such a TLV type (and all of its type extensions) in the corresponding IANA registries. An example of such is a LINK_METRIC TLV Type, with its type extensions reserved for use to be indicating the "kind" of metric expressed by the value of the TLV. In some other cases, there may not be 256 full types that share a common purpose and, as such, it is not meaningful to record a common name for all the type extensions for a TLV type in the corresponding IANA registries. Rather, it is appropriate to record an individual name per full type. This document reorganizes the naming of already allocated TLV types and type extensions in those registries to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. 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 =20 ------=_NextPart_000_06D8_01CFFD6E.A7E90590 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> I think that it is safe = to say that our AD is going to sit on, and therefore = block

> progress for, = draft-ietf-manet-olsrv2-multitopology

 

Oh! Harsh use of = language.

But basically = true.

 

So thanks to Thomas and = Christopher for writing this document. I would love for this to move = fast partly because it unblocks the other draft, and partly because it = will set the WG up so that future work can be = aligned.

 

If there is time on the agenda = then it would be cool to spend some time explaining the plan = f2f.

 

Adrian

 

From: Thomas Heide = Clausen [mailto:thomas@thomasclausen.org]
Sent: 11 November = 2014 03:32
To: manet
Cc: Adrian = Farrel
Subject: draft-ietf-manet-olsrv2-multitopology and = draft-dearlove-manet-tlv-naming-00.txt

<= p class=3DMsoNormal> 

Since, of course, = all y=E2=80=99all are compulsively reading the ID-announce mailing list = ;) you=E2=80=99ll have seen draft-dearlove-manet-tlv-naming-00.txt = document appear just today.

 

This is in response to the review from our AD on = draft-ietf-manet-olsrv2-multitopology (http://www.ietf.org/mail-archive/web/manet/current/msg16875.html), = in which he indicates that we probably should re-think the way we name = TLV types. 

 

As our AD requested, the authors did re-think, discuss a bit = also with our AD and chairs, and came to a conclusion ... and that = conclusion is in this I-D.

 

I think that it is safe to say that our AD is going to sit on, = and therefore block progress for, draft-ietf-manet-olsrv2-multitopology = =E2=80=94 and that, until we see draft-dearlove-manet-tlv-naming = move ahead (or, until we propose an alternative way forward, of = course).

 

Given that, and in case there is time on the meeting agenda, = then =E2=80=94 if the WG is interested  and the WG chairs believe = that it will be helpful in order to see progress =E2=80=94 I=E2=80=99d = be happy to say a few words on this topic, and try to answer any = questions there might be.

 

Either way, I believe that we=E2=80=99ll very soon be soliciting = the WG chairs to issue a call-for-WG-adoption (with a suitable lead = period to read the document), followed by a WGLC, such that this = document may make progress and =E2=80=9Cunblock=E2=80=9D = draft-ietf-manet-olsrv2-multitopology = also.

 

Best,

 

Thomas



Begin forwarded = message:

 

To: Thomas Heide Clausen <t.clausen@computer.org>, = "Christopher Dearlove" <chris.dearlove@baesystems.c= om>, "Thomas H. Clausen" <T.Clausen@computer.org>, = Christopher Dearlove <chris.dearlove@baesystems.c= om>

Subject: New Version Notification for = draft-dearlove-manet-tlv-naming-00.txt

Date: 11 Nov 2014 01:51:14 CET

 


A new version of = I-D, draft-dearlove-manet-tlv-naming-00.txt
has been successfully = submitted by Thomas Heide Clausen and posted to the
IETF = repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 = draft-dearlove-manet-tlv-naming
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLV Naming in the MANET = Generalized Packet/Message Format
Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 2014-11-10
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Individual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 16
URL: =            http://www.ietf.org/internet-drafts/draft-dearlove-manet-tlv-n= aming-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-dearlove-manet-tlv-naming/Htmlized:       ht= tp://tools.ietf.org/html/draft-dearlove-manet-tlv-naming-00

Abstract:
  TLVs (type-length-value structures) as = defined by RFC5444 have both a
  type (one octet) and a = type extension (one octet), together forming a
  full type = (of two octets).  RFC5444 sets up IANA registries for = TLV
  types, specifying that an allocation of a TLV type = entails creation
  of an IANA registry for the = corresponding type extensions.

  In some cases, = reserving all 256 type extensions for use for a = common
  purpose for a given TLV is meaningful, and thus it = makes sense to
  record a common name for such a TLV type = (and all of its type
  extensions) in the corresponding = IANA registries.  An example of such
  is a = LINK_METRIC TLV Type, with its type extensions reserved for = use
  to be indicating the "kind" of metric = expressed by the value of the
  TLV.

  In = some other cases, there may not be 256 full types that share = a
  common purpose and, as such, it is not meaningful to = record a common
  name for all the type extensions for a = TLV type in the corresponding
  IANA registries. =  Rather, it is appropriate to record an = individual
  name per full type.

  This = document reorganizes the naming of already allocated TLV = types
  and type extensions in those registries to use = names appropriately.
  It has no consequences in terms of = any protocol implementation.

  This document also = updates the Expert Review guidelines from RFC5444,
  so as = to establish a policy for consistent naming of future TLV = type
  and type extension = allocations.




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

 

------=_NextPart_000_06D8_01CFFD6E.A7E90590-- From nobody Wed Nov 12 19:38: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 EEFB51A1B44 for ; Wed, 12 Nov 2014 19:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qTL34RgOVHA for ; Wed, 12 Nov 2014 19:38:36 -0800 (PST) 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 0587D1A1B07 for ; Wed, 12 Nov 2014 19:38:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=caFJ1rHoCi/pQSDL2dSLFfJKAj/SS4Q8iTl/ussQC6fAcApOqur7vC96owVxNBSw; 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.166.39] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XolEv-0004qX-VN; Wed, 12 Nov 2014 22:38:34 -0500 Message-ID: <5464278D.3080202@earthlink.net> Date: Wed, 12 Nov 2014 19:37:49 -0800 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: Justin Dean References: <20141027220338.24511.50657.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060901070409040602010608" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7349a574582da535f82956fa69132dd11350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.166.39 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PNB5uWoWAjzb6ml4SdcVJVqaXuw Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] Answers to Justin: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Nov 2014 03:38:43 -0000 This is a multi-part message in MIME format. --------------060901070409040602010608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Justin, Here are some answers to your questions... On 11/10/2014 12:24 PM, Justin Dean wrote: > > > The definition of Originating Node (OrigNode) (and TargNode) are self > referencing and incomplete. They should at least reference AODVv2 > Router. Also the terms OrigNode and TargNode are later used as what > seems like addresses in an AODVv2 message. I suggest separating the > definition of a node (an AODVv2 Router?) from an address of that > node/router (suggest OrigNodeAddr) A node can be a host or a router, and is a fundamental networking object that can be used to define other objects. There are many instances where the two terms OrigNode and TargNode are used, and I am sure that you are right that OrigNodeAddr and TargNodeAddr is more accurate. Maybe, for brevity, should we use OrigAddr and TargAddr? We have tried as much as possible to avoid using names that are too long and distracting. If this is O.K. we will make new terminology definitions, and review whether OrigNode and TargNode are still needed. I did not see which definitions were circular. > > The term "invalid" is used a few times when a more specific reference > to the defined term "broken" and/or "expired" should be used. There are four instances of the word in the draft. But, see (*) below... > > In the "RteMsg Structure" section the list says that the OrigNode > should be included in the message header, the packet diagram doesn't > include this information as it doesn't expand the message header. > This would be fine but then the OrigNode is then included again the > address block which is confusing. Later it's described that OrigNode > should indeed be included in the address block but it happens after > the diagram. Also, is there a reason the OrigNode is included twice? That mistake has been there a very long time (since the time when it was not a mistake, in fact). That's the only instance of the term in the draft, and once the requirement was placed to include OrigNode in the AddrBlk, it no longer needed to be put in as the . > > It's not clear to me the difference between the states "broken" and > "expired" (other than how they reached that state) They are both > invalid states and regardless of how the state was obtained the routes > shouldn't be used. The only difference I could find is that "expired" > routes MAY be expunged while there is no such text regarding "broken" > routes. Broken is also used in reference to broken link and later > BrokenRoute without the terms being defined in the document > definitions. It may make sense to unify these states regardless of > how they are obtained into a single term and reduce the number of > states a route can have (unless there is something operationally > different that should be done that I'm missing) Thanks for this observation. After thinking about it for a while, I have not remembered any significant differences between the actual use of an expired route versus a broken route. How about if we combine the two states into a new state called "invalid"? An implementer or a network operator might want to know why a route entered such a state for diagnostic purposes, whether because of lack of traffic, a link breaking somewhere or because the router was administratively configured to forcibly make the route so, and I would recommend to implementers that the reason for the route becoming this state be logged. We could put in some text recommending the logging of route table entry history for such purposes. > > The addition of the "timed" state requires updating in a few other > places in the document when route state is referenced. The "Route > Table Entry Timeouts" section for example may need to be updated. O.K. I'll re-read the section with that in mind and make appropriate modifications. If you notice other places please point them out. > > Orig.Tail and Targ.Tail should be Orig.Mid and Targ.Mid as the tail > term is used for common bits of an address among the addresses listed. So I guess it's O.K. to have addresses with a Head and a Mid without a Tail? Regards, Charlie P. --------------060901070409040602010608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Justin,

Here are some answers to your questions... 

On 11/10/2014 12:24 PM, Justin Dean wrote:


The definition of Originating Node (OrigNode) (and TargNode) are self referencing and incomplete.  They should at least reference AODVv2 Router.  Also the terms OrigNode and TargNode are later used as what seems like addresses in an AODVv2 message.  I suggest separating the definition of a node (an AODVv2 Router?) from an address of that node/router (suggest OrigNodeAddr)

A node can be a host or a router, and is a fundamental
networking object that can be used to define other
objects.  There are many instances where the two terms
OrigNode and TargNode are used, and I am sure that you
are right that OrigNodeAddr and TargNodeAddr is more
accurate.  Maybe, for brevity, should we use OrigAddr and
TargAddr?  We have tried as much as possible to avoid
using names that are too long and distracting.  If this is O.K.
we will make new terminology definitions, and review
whether OrigNode and TargNode are still needed.

I did not see which definitions were circular.




The term "invalid" is used a few times when a more specific reference to the defined term "broken" and/or "expired" should be used.

There are four instances of the word in the draft.
But, see (*) below...


In the "RteMsg Structure" section the list says that the OrigNode should be included in the message header, the packet diagram doesn't include this information as it doesn't expand the message header.  This would be fine but then the OrigNode is then included again the address block which is confusing.  Later it's described that OrigNode should indeed be included in the address block but it happens after the diagram.  Also, is there a reason the OrigNode is included twice?

That mistake has been there a very long time (since the time when
it was not a mistake, in fact).  That's the only instance of the term
<msg-orig-addr> in the draft, and once the requirement was placed
to include OrigNode in the AddrBlk, it no longer needed to be put
in as the <msg-orig-addr>.


It's not clear to me the difference between the states "broken" and "expired" (other than how they reached that state)  They are both invalid states and regardless of how the state was obtained the routes shouldn't be used.  The only difference I could find is that "expired" routes MAY be expunged while there is no such text regarding "broken" routes.  Broken is also used in reference to broken link and later BrokenRoute without the terms being defined in the document definitions.  It may make sense to unify these states regardless of how they are obtained into a single term and reduce the number of states a route can have (unless there is something operationally different that should be done that I'm missing)

Thanks for this observation.  After thinking about it for a
while, I have not remembered any significant differences
between the actual use of an expired route versus a broken
route.  How about if we combine the two states into a new
state called "invalid"?

An implementer or a network operator might want to know
why a route entered such a state for diagnostic purposes,
whether because of lack of traffic, a link breaking somewhere
or because the router was administratively configured to
forcibly make the route so, and I would recommend to
implementers that the reason for the route becoming this
state be logged.  We could put in some text recommending
the logging of route table entry history for such purposes.


The addition of the "timed" state requires updating in a few other places in the document when route state is referenced.  The "Route Table Entry Timeouts" section for example may need to be updated.

O.K. I'll re-read the section with that in mind and make
appropriate modifications.  If you notice other places please
point them out.


Orig.Tail and Targ.Tail should be Orig.Mid and Targ.Mid as the tail term is used for common bits of an address among the addresses listed.

So I guess it's O.K. to have addresses with a Head and a Mid
without a Tail?

Regards,
Charlie P.


--------------060901070409040602010608-- From nobody Thu Nov 13 11:06: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 0CEB81ACD85 for ; Thu, 13 Nov 2014 11:06:22 -0800 (PST) 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 mTHp7vgWH0al for ; Thu, 13 Nov 2014 11:06:16 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010: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 F096C1AC443 for ; Thu, 13 Nov 2014 11:04:35 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id gm9so13974120lab.33 for ; Thu, 13 Nov 2014 11:04:34 -0800 (PST) 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=mrT24N+xVjiKXnjFBOnN6aDPPm90eY29h/84Knmb3ow=; b=twLoEUBcIf/wHV2lz04YFFGx/XodeOtkoxD2B9274OjIc+HcOd3YQ/giKo8AFzHVZz 7SI5x4OE/ARE+oWjn33w5KTUyTjdtqReUnz7bCW1ZeVnYV58+DQXWloSYTsEgN0hAQa0 m9dnk6Da2wLaqmWJDwoutB7GtITn7aJbCe7EaXsAyeOtyXsh8tkyOhwceFcKyEmMfiqX xg+FNuOug5GTKPifr7w+FwyV5/XcqJv/peEjCA9F6twoskxqrHqDn5OJlaE9BJN0Jz6v 0BcEOjPznKS7W0XnFgobEk6CGxkmaOR6CAn2b0MP6FpbLzmcq+uMQBFBXQxysdnkxsp2 523g== MIME-Version: 1.0 X-Received: by 10.112.199.40 with SMTP id jh8mr4093290lbc.5.1415905473295; Thu, 13 Nov 2014 11:04:33 -0800 (PST) Received: by 10.112.40.204 with HTTP; Thu, 13 Nov 2014 11:04:33 -0800 (PST) Date: Thu, 13 Nov 2014 14:04:33 -0500 Message-ID: From: James Nguyen To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c34576c57ad60507c22ea9 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Jsl2ghdDknYzDEgXkr5wAag_84s Subject: [manet] Skype? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Nov 2014 19:06:23 -0000 --001a11c34576c57ad60507c22ea9 Content-Type: text/plain; charset=UTF-8 Hi, Is there any Skype that we could call in? Thanks, James --001a11c34576c57ad60507c22ea9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Is th= ere any Skype that we could call in?

Thanks,

=
James
--001a11c34576c57ad60507c22ea9-- From nobody Thu Nov 13 11:22: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 792CD1ACDD7 for ; Thu, 13 Nov 2014 11:22:01 -0800 (PST) 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 LlWWcnbM6-Qq for ; Thu, 13 Nov 2014 11:22:00 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A081ACCF9 for ; Thu, 13 Nov 2014 11:17:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45C9C1C05E8; Thu, 13 Nov 2014 11:17:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.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 ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E51441C014E; Thu, 13 Nov 2014 11:17:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1E97406E-59E3-4AB6-9E29-A085429AED99" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= In-Reply-To: Date: Thu, 13 Nov 2014 20:17:54 +0100 Message-Id: <2F60C2A1-B79E-4DF0-888B-14D7A04CA032@axelcdv.com> References: To: James Nguyen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/X3XKRgnpSiABwlZxMkHHhkNpawk Cc: manet@ietf.org Subject: Re: [manet] Skype? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Nov 2014 19:22:01 -0000 --Apple-Mail=_1E97406E-59E3-4AB6-9E29-A085429AED99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi James, I don't think there is a way of using skype, but there are audio and = jabber links there: https://tools.ietf.org/wg/manet/agenda Axel Le 13 nov. 2014 =E0 20:04, James Nguyen a = =E9crit : > Hi, >=20 > Is there any Skype that we could call in? >=20 > Thanks, >=20 > James > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_1E97406E-59E3-4AB6-9E29-A085429AED99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = James,

I don't think there is a way of using skype, = but there are audio and jabber links there: https://tools.ietf.org/wg/= manet/agenda

Axel

Le = 13 nov. 2014 =E0 20:04, James Nguyen <james.huy.nguyen@gmail.com&= gt; a =E9crit :

Hi,

Is = there any Skype that we could call in?

Thanks,

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

= --Apple-Mail=_1E97406E-59E3-4AB6-9E29-A085429AED99-- From nobody Thu Nov 13 14:43: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 BBBB61AE11D for ; Thu, 13 Nov 2014 14:43:44 -0800 (PST) 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 4dCNCS6Ozy2X for ; Thu, 13 Nov 2014 14:43:43 -0800 (PST) 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 22C661AE115 for ; Thu, 13 Nov 2014 14:43:42 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sADMdHRO009551; Thu, 13 Nov 2014 22:39:17 GMT Received: from 950129200 (dhcp-b3f6.meeting.ietf.org [31.133.179.246]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sADMdE7D009542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Nov 2014 22:39:16 GMT From: "Adrian Farrel" To: Date: Thu, 13 Nov 2014 22:43:34 -0000 Message-ID: <0a4e01cfff93$437d8a50$ca789ef0$@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//kzuHS9sVJ9YORzu8TpZozGTEtA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21102.001 X-TM-AS-Result: No--5.384-10.0-31-10 X-imss-scan-details: No--5.384-10.0-31-10 X-TMASE-MatchedRID: V2R7yBee3+e4mqWVDqxbtAPZZctd3P4BZa7LkubQvj/vmIIuT2MkFV8U bSn1RTfDYkx0TzdeKVVvqsiY6GstuMLk3xw1Sf9e5gCHftmwEMJ9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASAHAopEd76v4pXJqoJoPzRXORtKR8XEWBpKt0yTztwdQ4s63v+R2kQRR4 gY7rx9bw== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/X8DzL6cqJEgE_5BCtGQnqCgwnmA Cc: akatlas@gmail.com Subject: [manet] MANET co-chair 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, 13 Nov 2014 22:43:45 -0000 Hi, To confirm what I said in the meeting this morning... Joe is stepping down. Thank you Joe for all you've done for the working group. The ADs have asked Justin to step in as co-chair to work with Stan. Fortunately Justin thinks this is a good idea! I've asked the Secretariat to make this change as soon as possible. Thanks, Adrian From nobody Thu Nov 13 15:28: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 1E0A51AD3DC for ; Thu, 13 Nov 2014 15:28:30 -0800 (PST) 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 aX6kINH7zB9u for ; Thu, 13 Nov 2014 15:28:28 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010: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 ED69A1AD482 for ; Thu, 13 Nov 2014 15:28:27 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so13185591lbj.13 for ; Thu, 13 Nov 2014 15:28:26 -0800 (PST) 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=8jMqYRFpzJ1tSfQHxhMRwYD9ax6IAAHCzdS7n6t2edY=; b=NoB20qA1hJXpaV4P/rqLTxMfSg8PyjVP97neDXxQzT8mbhW/CblDNhRDP3MZIz/079 K4t5LjLwxAnt3f6iIzZKO+0PzBve9jMaVC4pPkh/GXhJ1HLg4toze07FeQwS86pJSMRq MVc8xUeArG5YmV1Tz06y9QEklsdbF68z9BQXXWgImFlW2QYqcyw/EJQWE6F42qstFevC 8Gtfw+dLLQKvV4Wb/+XHz4MEyRuJ2dOr7cppKw/xcxyMSb3H4J3TJFd2o9/fg2f+PzYw DqMFF+4ChsGSeVrbAOEBzj01HwKV8Yz/5CddJrDgSSXwDMggLmP2J40bQvD/LRDV+gWu xcOQ== MIME-Version: 1.0 X-Received: by 10.112.142.33 with SMTP id rt1mr4956566lbb.85.1415921306366; Thu, 13 Nov 2014 15:28:26 -0800 (PST) Received: by 10.112.40.204 with HTTP; Thu, 13 Nov 2014 15:28:26 -0800 (PST) In-Reply-To: <0a4e01cfff93$437d8a50$ca789ef0$@olddog.co.uk> References: <0a4e01cfff93$437d8a50$ca789ef0$@olddog.co.uk> Date: Thu, 13 Nov 2014 18:28:26 -0500 Message-ID: From: James Nguyen To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a11c36b727ef9c50507c5de83 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FiYspF6I6GTNFZpIOoLFL7AwXx0 Cc: manet@ietf.org, akatlas@gmail.com Subject: Re: [manet] MANET co-chair X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Nov 2014 23:28:30 -0000 --001a11c36b727ef9c50507c5de83 Content-Type: text/plain; charset=UTF-8 By having known Justin for his passion in MANET, Justin is a good choice. Congratulations, Justin. James On Thu, Nov 13, 2014 at 5:43 PM, Adrian Farrel wrote: > Hi, > > To confirm what I said in the meeting this morning... > > Joe is stepping down. > Thank you Joe for all you've done for the working group. > > The ADs have asked Justin to step in as co-chair to work with Stan. > Fortunately > Justin thinks this is a good idea! > > I've asked the Secretariat to make this change as soon as possible. > > Thanks, > Adrian > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- James Nguyen Email: james.huy.nguyen@gmail.com --001a11c36b727ef9c50507c5de83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By having known Justin for his passion in MANET, Justin is= a good choice.=C2=A0 Congratulations, Justin.

James

On Thu, N= ov 13, 2014 at 5:43 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

To confirm what I said in the meeting this morning...

Joe is stepping down.
Thank you Joe for all you've done for the working group.

The ADs have asked Justin to step in as co-chair to work with Stan. Fortuna= tely
Justin thinks this is a good idea!

I've asked the Secretariat to make this change as soon as possible.

Thanks,
Adrian

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



--
James Nguyen
Email: james.huy.nguyen@gmail.com
--001a11c36b727ef9c50507c5de83-- From nobody Thu Nov 13 18:28: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 1B3C41A1B46 for ; Thu, 13 Nov 2014 18:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 rT2eZowUb2Fd for ; Thu, 13 Nov 2014 18:24:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9478A1A1AB5 for ; Thu, 13 Nov 2014 18:24:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9669B181C70; Thu, 13 Nov 2014 18:23:37 -0800 (PST) To: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr, akatlas@gmail.com, adrian@olddog.co.uk, ratliffstan@gmail.com, macker@itd.nrl.navy.mil X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141114022337.9669B181C70@rfc-editor.org> Date: Thu, 13 Nov 2014 18:23:37 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gIBBshdlkEkGtxJwEfJQ8UnVmgM X-Mailman-Approved-At: Thu, 13 Nov 2014 18:28:21 -0800 Cc: manet@ietf.org, Ronald.intVelt@tno.nl, rfc-editor@rfc-editor.org Subject: [manet] [Editorial Errata Reported] RFC5444 (4178) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 14 Nov 2014 02:24:15 -0000 The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=4178 -------------------------------------- Type: Editorial Reported by: Ronald in 't Velt Section: 6.5.1 Original Text ------------- When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26]. Corrected Text -------------- When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines an Address Block TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26]. Notes ----- 'Message TLV Type' should read 'Address Block TLV Type'. This is likely a 'Copy-Paste' error from section 6.4.1, which stipulates a similar requirement for Message TLV Type Extension Registry creation. Instructions: ------------- This erratum 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. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Nov 13 23:42: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 D32881A8545; Thu, 13 Nov 2014 23:42:42 -0800 (PST) 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 dId4fyDVrDMo; Thu, 13 Nov 2014 23:42:41 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d: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 421441A86E1; Thu, 13 Nov 2014 23:42:41 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id n8so11007805qaq.19 for ; Thu, 13 Nov 2014 23:42:40 -0800 (PST) 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=HJdTtvACaPTl1NNFW1pgGXb1lNSlsR0pYdaTCayampE=; b=E3ZuLBaiFWYxMG8ayFtITolMl6WAPMwF8RiOV+xXiIz82asHu4tI4uKjJDu3T67U9Z xR0tZf3V0F7vJRxswU46iao/V7GpPkHI38GgPMIJ+5KN+q/XMX7i2a2ldlJsd3RVzVgj 4bhFgvInaFw7wuOBWU0+k/1o263cHQy2P0B6TSjDkmmiVuFUwTS9uu+R9wgLngMdMT0j /ffQ3mcTK/rHVSI76sIuI27AdbIdZAOyKI49MKQtanxR5IIwmuL/UY6OOuWUAykQa4l6 M9bn4qzDA9pkBHJo7J4ULSuhnc6Uu3Uiq8XBPyz3uF27I+7vpDKRwbDwa9yT/nVmsEb3 DBpQ== MIME-Version: 1.0 X-Received: by 10.224.69.202 with SMTP id a10mr8598257qaj.62.1415950960490; Thu, 13 Nov 2014 23:42:40 -0800 (PST) Received: by 10.140.98.212 with HTTP; Thu, 13 Nov 2014 23:42:40 -0800 (PST) In-Reply-To: <05f601cffd53$043a3470$0cae9d50$@olddog.co.uk> References: <05f601cffd53$043a3470$0cae9d50$@olddog.co.uk> Date: Thu, 13 Nov 2014 23:42:40 -0800 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/N3-EkWbumZhOX5pFZGkuJc_Kp2M Cc: MANET IETF , manet-ads@tools.ietf.org, iesg@ietf.org Subject: Re: [manet] Honolulu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 14 Nov 2014 07:42:43 -0000 Hi Adrian, On 11/10/14, Adrian Farrel wrote: > > Beyond this, I don't understand your issue. Sorry. Can you give me an > example of a question that needs to be answered, face-to-face, during the > meeting that you think Justin is not allowed to answer, that cannot be > handled by email with the absent chair, but that a "fully empowered" WG > chair could answer? Or maybe there is some action you think a chair might > need to take during the meeting that Justin is not be allowed to handle? > I did not mean questions and answers of technical issues, but IETF interactitions/works with community through its WG-chairs and ADs are important. We are only allowed to do work which the IETF procedures allows us to do. IMHO, the Co-Chair has many things he/she can do, other than chairing the session. Overall, If a new participant is paying to travel-to/meet IETF in face to face way, then IMHO he/she should see some IETF-participants attended having the bash as WG-Chair during the week meeting, so all WGs attended in IETF meetings must have a chair. I hope in future the IESG consider the issue as an IETF issue not a participant issue. Regards AB From nobody Fri Nov 14 00:40: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 24E081A8732; Fri, 14 Nov 2014 00:40:32 -0800 (PST) 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 5OuJIFaNdaG0; Fri, 14 Nov 2014 00:40:30 -0800 (PST) Received: from mail.tropicalstormsoftware.com (unknown [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE5E1A1A2A; Fri, 14 Nov 2014 00:40:30 -0800 (PST) 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, 14 Nov 2014 08:40:03 +0000 From: Rick Taylor To: Abdussalam Baryun , "adrian@olddog.co.uk" Thread-Topic: [manet] Honolulu Thread-Index: AQHP+sBnle+PikS+k0K680lpo2ehxg== Date: Fri, 14 Nov 2014 08:40:01 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801429798AF@tss-server1.home.tropicalstormsoftware.com> References: <05f601cffd53$043a3470$0cae9d50$@olddog.co.uk> 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/5po8k2MY9PYEHav5wp54g87HGew Cc: "manet-ads@tools.ietf.org" , MANET IETF , "iesg@ietf.org" Subject: Re: [manet] Honolulu X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 14 Nov 2014 08:40:32 -0000 I must say that my chair was very comfortable, and Justin did a great=0A= job of steering the mildly hazardous meeting.=0A= =0A= Rick=0A= =0A= =0A= On 13/11/14 21:42, Abdussalam Baryun wrote:=0A= > Hi Adrian,=0A= >=0A= > On 11/10/14, Adrian Farrel wrote:=0A= >> Beyond this, I don't understand your issue. Sorry. Can you give me an=0A= >> example of a question that needs to be answered, face-to-face, during th= e=0A= >> meeting that you think Justin is not allowed to answer, that cannot be= =0A= >> handled by email with the absent chair, but that a "fully empowered" WG= =0A= >> chair could answer? Or maybe there is some action you think a chair migh= t=0A= >> need to take during the meeting that Justin is not be allowed to handle?= =0A= >>=0A= > I did not mean questions and answers of technical issues, but IETF=0A= > interactitions/works with community through its WG-chairs and ADs are=0A= > important. We are only allowed to do work which the IETF procedures=0A= > allows us to do. IMHO, the Co-Chair has many things he/she can do,=0A= > other than chairing the session.=0A= >=0A= > Overall, If a new participant is paying to travel-to/meet IETF in face=0A= > to face way, then IMHO he/she should see some IETF-participants=0A= > attended having the bash as WG-Chair during the week meeting, so all=0A= > WGs attended in IETF meetings must have a chair. I hope in future the=0A= > IESG consider the issue as an IETF issue not a participant issue.=0A= >=0A= > Regards=0A= >=0A= > AB=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Sun Nov 16 10:53: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 145E91A1A2E for ; Sun, 16 Nov 2014 10:53:42 -0800 (PST) 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 z5kHvnaA6-He for ; Sun, 16 Nov 2014 10:53:40 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537411A19E7 for ; Sun, 16 Nov 2014 10:53:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2DD171BC1BAC for ; Sun, 16 Nov 2014 10:53:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.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 ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 383BA1BC194E for ; Sun, 16 Nov 2014 10:53:38 -0800 (PST) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Content-Type: multipart/alternative; boundary="Apple-Mail=_8B2ECEF8-D60F-4606-8BFF-CC8315260EF0" Date: Sun, 16 Nov 2014 19:53:35 +0100 References: <20141116183702.6503.58267.idtracker@ietfa.amsl.com> To: "" Message-Id: 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/l5xkHzvusz6VpQTimR3d77HdYYE Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-asym-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: Sun, 16 Nov 2014 18:53:42 -0000 --Apple-Mail=_8B2ECEF8-D60F-4606-8BFF-CC8315260EF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear WG, As announced during this week's meeting, we updated the draft for = ODMRP-ASYM (the extension to ODMRP which handles routing through = unidirectional links). The main changes in this draft are: - The spec now correctly accounts for routers with multiple = interfaces and multiple addresses. - Since ODMRP no longer requires that Join Query messages carry = a hop count field, the addition of this field is specified in = ODMRP-ASYM. Having a hop-count field is necessary to be able to build = Loops (as a reminder, the Loop is the main construct of this draft, = which allows to find an alternative reverse path for Join Replies). - Moved the RFC5444 encoding part from an appendix to a section = and clarified the separation between message content and encoding - Some clarifications and consistency fixes between the two = drafts. Best, Axel D=E9but du message r=E9exp=E9di=E9 : > De: internet-drafts@ietf.org > Objet: New Version Notification for = draft-gerla-manet-odmrp-asym-01.txt > Date: 16 novembre 2014 19:37:02 UTC+1 > =C0: "Soon Young Oh" , Soon Young Oh = , "Axel Coli Verdiere" , = Mario Gerla , "Professor Mario Gerla" = , Axel Colin de Verdiere >=20 >=20 > A new version of I-D, draft-gerla-manet-odmrp-asym-01.txt > has been successfully submitted by Axel Colin de Verdiere and posted = to the > IETF repository. >=20 > Name: draft-gerla-manet-odmrp-asym > Revision: 01 > Title: ODMRP-ASYM > Document date: 2014-11-16 > Group: Individual Submission > Pages: 27 > URL: = http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-asym-01.txt > Status: = https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/ > Htmlized: = http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-asym-01 >=20 > Abstract: > This document describes ODMRP-ASYM, an extension for the On Demand > Multicast Routing Protocol [ODMRP], which enables routers to use > unidirectional links to route multicast messages. >=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=_8B2ECEF8-D60F-4606-8BFF-CC8315260EF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = WG,

As announced during this week's meeting, we = updated the draft for ODMRP-ASYM (the extension to ODMRP which handles = routing through unidirectional links).
The main changes in = this draft are:
- The spec now correctly accounts = for routers with multiple interfaces and multiple = addresses.
- Since ODMRP no longer requires = that Join Query messages carry a hop count field, the addition of this = field is specified in ODMRP-ASYM. Having a hop-count field is necessary = to be able to build Loops (as a reminder, the Loop is the main construct = of this draft, which allows to find an alternative reverse path for Join = Replies).
- Moved the RFC5444 encoding part = from an appendix to a section and clarified the separation between = message content and encoding
- Some clarifications and = consistency fixes between the two = drafts.

Best,

Axel
=

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

De: internet-drafts@ietf.org
<= /span>
Objet: = New Version = Notification for = draft-gerla-manet-odmrp-asym-01.txt
Date: 16 novembre 2014 19:37:02 = UTC+1
=C0: = "Soon Young Oh" = <soon@utopiacompression.com&= gt;, Soon Young Oh <soon@utopiacompression.com&= gt;, "Axel Coli Verdiere" <axel@axelcdv.com>, Mario Gerla = <gerla@cs.ucla.edu>, = "Professor Mario Gerla" <gerla@cs.ucla.edu>, Axel Colin = de Verdiere <axel@axelcdv.com>
=

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

Name: = draft-gerla-manet-odmrp-asym
Revision: = 01
Title: ODMRP-ASYM
Document date: = 2014-11-16
Group: Individual = Submission
Pages: 27
URL: =            http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-asym-01= .txt
Status:         ht= tps://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/
Htmliz= ed:       http:/= /tools.ietf.org/html/draft-gerla-manet-odmrp-asym-01
Diff: =           http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-asym-01
Abstract:
  This document describes ODMRP-ASYM, an = extension for the On Demand
  Multicast Routing Protocol = [ODMRP], which enables routers to use
  unidirectional = links to route multicast messages.




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=_8B2ECEF8-D60F-4606-8BFF-CC8315260EF0-- From nobody Sun Nov 16 11:04: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 8DDEC1A1A72 for ; Sun, 16 Nov 2014 11:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 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, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgOm4b0HAqF7 for ; Sun, 16 Nov 2014 11:04:04 -0800 (PST) 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 19DBE1A1A03 for ; Sun, 16 Nov 2014 11:04:03 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so3810126vcb.40 for ; Sun, 16 Nov 2014 11:04:03 -0800 (PST) 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=MG1ErkHj5N2rJv0QR+gYOlr26pkLnHhP+qqaBFwFec4=; b=1ULzSjwJqguP95npU6cPvPDsU/cHzoXp92xtXsOO9LCj7zGTKjOeR8PbA7k2y/s+ll 0MRXUARctX/OFMgMocOmHHgD7Sy/ago2SHFek1zTKTDbnUzc1bVFdrumCwGl+BLM7Z01 vzP4dTHClehtS5NF0BJ7NtZdLoCWesRMjRQcE= 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=MG1ErkHj5N2rJv0QR+gYOlr26pkLnHhP+qqaBFwFec4=; b=TgoqGCylyWhomjucwBSrl/dVaLVLw4r3bl2NP7e/5G0R9uhxYw9CIGxE4e4s2AnjzI 0mUbNyz0PtAuyUxOQahpHnU/OgFACt/4bgyFNEtnb9KEo56s/xNgQPNjX2rpzQGI/72f ZlrY/jAqTuI8ehIRiyqQfb0kzK6Y9Q2T4r0V1vDJgC56AP+E7cz345Ok/8K1qq85ZXX8 jPCMh8fQiz5T9GqHpCTVUIXqwxCiwj0dtkMjK55WhqbL13hPsB3QbOuPBTR0VVFcLIBF 64/BKWjj/bt2ckxhswO0G7/Kx6X0WMGnFIRt6+7TB6CVZ5Pkgy4/jStJEtWm/ZQ1d9nb wR1Q== X-Gm-Message-State: ALoCoQlfTxpxrw7YMc6snh+WqAPGGXNGMJXEeSUP8iXKdXfG3QKglflmnVkYglm5+WTotk/rY6mJ MIME-Version: 1.0 X-Received: by 10.220.168.193 with SMTP id v1mr9625438vcy.39.1416164643068; Sun, 16 Nov 2014 11:04:03 -0800 (PST) Received: by 10.220.96.13 with HTTP; Sun, 16 Nov 2014 11:04:03 -0800 (PST) In-Reply-To: References: <20141116183702.6503.58267.idtracker@ietfa.amsl.com> Date: Sun, 16 Nov 2014 11:04:03 -0800 Message-ID: From: Ulrich Herberg To: =?UTF-8?Q?Axel_Colin_de_Verdi=C3=A8re?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aaYhh__y6uCbBWqLp6qM4JMLVvQ Cc: "" Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-asym-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: Sun, 16 Nov 2014 19:04:06 -0000 Thanks Axel for this new revision! What are the intended next steps? You asked the chairs to call for WG adoption of draft-gerla-manet-odmrp. What about draft-gerla-manet-odmrp-asym? Are there implementations of both drafts? Regards Ulrich On Sun, Nov 16, 2014 at 10:53 AM, Axel Colin de Verdi=C3=A8re wrote: > Dear WG, > > As announced during this week's meeting, we updated the draft for ODMRP-A= SYM > (the extension to ODMRP which handles routing through unidirectional link= s). > The main changes in this draft are: > - The spec now correctly accounts for routers with multiple interfaces an= d > multiple addresses. > - Since ODMRP no longer requires that Join Query messages carry a hop cou= nt > field, the addition of this field is specified in ODMRP-ASYM. Having a > hop-count field is necessary to be able to build Loops (as a reminder, th= e > Loop is the main construct of this draft, which allows to find an > alternative reverse path for Join Replies). > - Moved the RFC5444 encoding part from an appendix to a section and > clarified the separation between message content and encoding > - Some clarifications and consistency fixes between the two drafts. > > Best, > > Axel > > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : > > De: internet-drafts@ietf.org > Objet: New Version Notification for draft-gerla-manet-odmrp-asym-01.txt > Date: 16 novembre 2014 19:37:02 UTC+1 > =C3=80: "Soon Young Oh" , Soon Young Oh > , "Axel Coli Verdiere" , Ma= rio > Gerla , "Professor Mario Gerla" , A= xel > Colin de Verdiere > > > A new version of I-D, draft-gerla-manet-odmrp-asym-01.txt > has been successfully submitted by Axel Colin de Verdiere and posted to t= he > IETF repository. > > Name: draft-gerla-manet-odmrp-asym > Revision: 01 > Title: ODMRP-ASYM > Document date: 2014-11-16 > Group: Individual Submission > Pages: 27 > URL: > http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-asym-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/ > Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-0= 1 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-asym-01 > > Abstract: > This document describes ODMRP-ASYM, an extension for the On Demand > Multicast Routing Protocol [ODMRP], which enables routers to use > unidirectional links to route multicast messages. > > > > > 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 > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Sun Nov 16 11:04: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 6807E1A8896 for ; Fri, 14 Nov 2014 02:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOrWoQcoFlen for ; Fri, 14 Nov 2014 02:13:01 -0800 (PST) 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 72F241A8891 for ; Fri, 14 Nov 2014 02:13:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,384,1413241200"; d="scan'208";a="419534300" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Nov 2014 10:12:58 +0000 X-IronPort-AV: E=Sophos;i="5.07,384,1413241200"; d="scan'208";a="80544100" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 14 Nov 2014 10:12:58 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Fri, 14 Nov 2014 10:12:58 +0000 From: "Dearlove, Christopher (UK)" To: RFC Errata System , "T.Clausen@computer.org" , "jdean@itd.nrl.navy.mil" , "Cedric.Adjih@inria.fr" , "akatlas@gmail.com" , "adrian@olddog.co.uk" , "ratliffstan@gmail.com" , "macker@itd.nrl.navy.mil" Thread-Topic: [Editorial Errata Reported] RFC5444 (4178) Thread-Index: AQHP/7IWN259UrM810u9tgt1ps/5a5xf52hA Date: Fri, 14 Nov 2014 10:12:57 +0000 Message-ID: References: <20141114022337.9669B181C70@rfc-editor.org> In-Reply-To: <20141114022337.9669B181C70@rfc-editor.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/ySG9TXy8sifId-uhzjxr7aYBvds X-Mailman-Approved-At: Sun, 16 Nov 2014 11:04:48 -0800 Cc: "manet@ietf.org" , "Ronald.intVelt@tno.nl" Subject: Re: [manet] [Editorial Errata Reported] RFC5444 (4178) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 14 Nov 2014 10:13:06 -0000 As an author of this document, I agree with this erratum. -- = 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: RFC Errata System [mailto:rfc-editor@rfc-editor.org] = Sent: 14 November 2014 02:24 To: T.Clausen@computer.org; Dearlove, Christopher (UK); jdean@itd.nrl.navy.= mil; Cedric.Adjih@inria.fr; akatlas@gmail.com; adrian@olddog.co.uk; ratliff= stan@gmail.com; macker@itd.nrl.navy.mil Cc: Ronald.intVelt@tno.nl; manet@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC5444 (4178) ----------------------! 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 following errata report has been submitted for RFC5444, "Generalized Mo= bile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5444&eid=3D4178 -------------------------------------- Type: Editorial Reported by: Ronald in 't Velt Section: 6.5.1 Original Text ------------- When an Address Block TLV Type is registered, then a new registry for type = extensions of that type must be created. A document that defines a Message= TLV Type MUST also specify the mechanism by which its type extensions are = allocated, from among those in [BCP26]. Corrected Text -------------- When an Address Block TLV Type is registered, then a new registry for type = extensions of that type must be created. A document that defines an Addres= s Block TLV Type MUST also specify the mechanism by which its type extensio= ns are allocated, from among those in [BCP26]. Notes ----- 'Message TLV Type' should read 'Address Block TLV Type'. This is likely a '= Copy-Paste' error from section 6.4.1, which stipulates a similar requiremen= t for Message TLV Type Extension Registry creation. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party (IESG) can log in to change the status= and edit the report, if necessary. = -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Mess= age Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG ******************************************************************** 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 Sun Nov 16 12:12: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 0AD1C1A1AE4 for ; Sun, 16 Nov 2014 12:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jxNmOczZ2V67 for ; Sun, 16 Nov 2014 12:12:12 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561431A1ADF for ; Sun, 16 Nov 2014 12:12:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2465B240D50; Sun, 16 Nov 2014 12:12:12 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.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 ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 59368240B6D; Sun, 16 Nov 2014 12:12:03 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= In-Reply-To: Date: Sun, 16 Nov 2014 21:12:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141116183702.6503.58267.idtracker@ietfa.amsl.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nm99a_dDNwIEtti0B2Uedm-c1RU Cc: "" Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-asym-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: Sun, 16 Nov 2014 20:12:14 -0000 Hi Ulrich, Ultimately we'd like to ask the WG for adoption for this draft as well, = if there's interest in that, but it'd have to come after = draft-gerla-manet-odmrp. There is an ongoing implementation for = draft-gerla-manet-odmrp, but it's not completely up-to-date, and none = for the -asym draft for the moment. I'm working on that though, so there = should be progress on both sides within a month or two. Best, Axel Le 16 nov. 2014 =E0 20:04, Ulrich Herberg a =E9crit = : > Thanks Axel for this new revision! >=20 > What are the intended next steps? You asked the chairs to call for WG > adoption of draft-gerla-manet-odmrp. What about > draft-gerla-manet-odmrp-asym? >=20 > Are there implementations of both drafts? >=20 > Regards > Ulrich >=20 > On Sun, Nov 16, 2014 at 10:53 AM, Axel Colin de Verdi=E8re > wrote: >> Dear WG, >>=20 >> As announced during this week's meeting, we updated the draft for = ODMRP-ASYM >> (the extension to ODMRP which handles routing through unidirectional = links). >> The main changes in this draft are: >> - The spec now correctly accounts for routers with multiple = interfaces and >> multiple addresses. >> - Since ODMRP no longer requires that Join Query messages carry a hop = count >> field, the addition of this field is specified in ODMRP-ASYM. Having = a >> hop-count field is necessary to be able to build Loops (as a = reminder, the >> Loop is the main construct of this draft, which allows to find an >> alternative reverse path for Join Replies). >> - Moved the RFC5444 encoding part from an appendix to a section and >> clarified the separation between message content and encoding >> - Some clarifications and consistency fixes between the two drafts. >>=20 >> Best, >>=20 >> Axel >>=20 >> D=E9but du message r=E9exp=E9di=E9 : >>=20 >> De: internet-drafts@ietf.org >> Objet: New Version Notification for = draft-gerla-manet-odmrp-asym-01.txt >> Date: 16 novembre 2014 19:37:02 UTC+1 >> =C0: "Soon Young Oh" , Soon Young Oh >> , "Axel Coli Verdiere" = , Mario >> Gerla , "Professor Mario Gerla" = , Axel >> Colin de Verdiere >>=20 >>=20 >> A new version of I-D, draft-gerla-manet-odmrp-asym-01.txt >> has been successfully submitted by Axel Colin de Verdiere and posted = to the >> IETF repository. >>=20 >> Name: draft-gerla-manet-odmrp-asym >> Revision: 01 >> Title: ODMRP-ASYM >> Document date: 2014-11-16 >> Group: Individual Submission >> Pages: 27 >> URL: >> = http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-asym-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/ >> Htmlized: = http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-asym-01 >>=20 >> Abstract: >> This document describes ODMRP-ASYM, an extension for the On Demand >> Multicast Routing Protocol [ODMRP], which enables routers to use >> unidirectional links to route multicast messages. >>=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 >> _______________________________________________ >> 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 Sun Nov 16 12:26: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 6B45C1A1AE1 for ; Sun, 16 Nov 2014 12:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 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, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19Bv-afLGSAq for ; Sun, 16 Nov 2014 12:26:06 -0800 (PST) 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 61D631A1AC6 for ; Sun, 16 Nov 2014 12:26:06 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id im17so6502384vcb.13 for ; Sun, 16 Nov 2014 12:26:04 -0800 (PST) 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=g7RfDfAHhSvBlAjRVZaa0DvItlqm/gBDEixVkP3STbQ=; b=CcgG/2QUqQT3VXUEFAPEDB7qlbXbW4/gjNwMxJ6MxN7rslTvEybz4weVjaqVaPLOQ5 W/Ev9UQJX0flz/THrAhvIj2He95ftd7ZoQB2bVqVqRELumQGF8K4xLJwpQ7R2dD1Daa1 OdhK7DHPbbkFK5M+RSSqQ3P73jU9t77wZbNUY= 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=g7RfDfAHhSvBlAjRVZaa0DvItlqm/gBDEixVkP3STbQ=; b=EzF2BOEOpr1crByOjZdgzfhgEvm4+jRAvfFOWwIwylebwqq7KJt0MXgnpdL9XbyrH2 eNwxMVM1DS3Yohj+/+cXKWdfjYjBNMO5jm5x+35nS5VzjbWPkIsNWoHnUUFpWO9Jnnb/ 1RMpYiRHBsy2EorwPryVwMcF8uSfbLX/O/RoF5y5COKj+rDDSyIEEeAtrh3sZWKZC2Uy jwNXPFPaK/B8RJ7/4eOAgvEBMAmEtW4d37O+ZvW3JKovx9m4qByiI60+3QpiG48tcP1A 096GBN9q8xVOv0TxmHEjrJr9emEjiEuZO5nmqAEzZ7jPh0qd8TcBCFEY6/c+zZmU0K4P /urA== X-Gm-Message-State: ALoCoQkceF437wrYJbUiEF7lVNB8pO/R5iHqorqK4iNoqgJF7wv9KlD43BOBrQRNd4wqfGbMKdBh MIME-Version: 1.0 X-Received: by 10.52.116.240 with SMTP id jz16mr17704929vdb.26.1416169564081; Sun, 16 Nov 2014 12:26:04 -0800 (PST) Received: by 10.220.96.13 with HTTP; Sun, 16 Nov 2014 12:26:04 -0800 (PST) In-Reply-To: References: <20141116183702.6503.58267.idtracker@ietfa.amsl.com> Date: Sun, 16 Nov 2014 12:26:04 -0800 Message-ID: From: Ulrich Herberg To: =?UTF-8?Q?Axel_Colin_de_Verdi=C3=A8re?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Ql-VquwYb0WeSjWKED05_x1h-JU Cc: "" Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-asym-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: Sun, 16 Nov 2014 20:26:08 -0000 Thanks! On Sun, Nov 16, 2014 at 12:12 PM, Axel Colin de Verdi=C3=A8re wrote: > Hi Ulrich, > > Ultimately we'd like to ask the WG for adoption for this draft as well, i= f there's interest in that, but it'd have to come after draft-gerla-manet-o= dmrp. There is an ongoing implementation for draft-gerla-manet-odmrp, but i= t's not completely up-to-date, and none for the -asym draft for the moment.= I'm working on that though, so there should be progress on both sides with= in a month or two. > > Best, > > Axel > > Le 16 nov. 2014 =C3=A0 20:04, Ulrich Herberg a =C3= =A9crit : > >> Thanks Axel for this new revision! >> >> What are the intended next steps? You asked the chairs to call for WG >> adoption of draft-gerla-manet-odmrp. What about >> draft-gerla-manet-odmrp-asym? >> >> Are there implementations of both drafts? >> >> Regards >> Ulrich >> >> On Sun, Nov 16, 2014 at 10:53 AM, Axel Colin de Verdi=C3=A8re >> wrote: >>> Dear WG, >>> >>> As announced during this week's meeting, we updated the draft for ODMRP= -ASYM >>> (the extension to ODMRP which handles routing through unidirectional li= nks). >>> The main changes in this draft are: >>> - The spec now correctly accounts for routers with multiple interfaces = and >>> multiple addresses. >>> - Since ODMRP no longer requires that Join Query messages carry a hop c= ount >>> field, the addition of this field is specified in ODMRP-ASYM. Having a >>> hop-count field is necessary to be able to build Loops (as a reminder, = the >>> Loop is the main construct of this draft, which allows to find an >>> alternative reverse path for Join Replies). >>> - Moved the RFC5444 encoding part from an appendix to a section and >>> clarified the separation between message content and encoding >>> - Some clarifications and consistency fixes between the two drafts. >>> >>> Best, >>> >>> Axel >>> >>> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >>> >>> De: internet-drafts@ietf.org >>> Objet: New Version Notification for draft-gerla-manet-odmrp-asym-01.txt >>> Date: 16 novembre 2014 19:37:02 UTC+1 >>> =C3=80: "Soon Young Oh" , Soon Young Oh >>> , "Axel Coli Verdiere" , = Mario >>> Gerla , "Professor Mario Gerla" ,= Axel >>> Colin de Verdiere >>> >>> >>> A new version of I-D, draft-gerla-manet-odmrp-asym-01.txt >>> has been successfully submitted by Axel Colin de Verdiere and posted to= the >>> IETF repository. >>> >>> Name: draft-gerla-manet-odmrp-asym >>> Revision: 01 >>> Title: ODMRP-ASYM >>> Document date: 2014-11-16 >>> Group: Individual Submission >>> Pages: 27 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-asym-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/ >>> Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym= -01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-asym-01 >>> >>> Abstract: >>> This document describes ODMRP-ASYM, an extension for the On Demand >>> Multicast Routing Protocol [ODMRP], which enables routers to use >>> unidirectional links to route multicast messages. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> 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 Sun Nov 16 14:07: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 E1D601A1B5C for ; Sun, 16 Nov 2014 14:07:09 -0800 (PST) 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 fQKubkVZaOOJ for ; Sun, 16 Nov 2014 14:07:06 -0800 (PST) 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 7DCB11A1B63 for ; Sun, 16 Nov 2014 14:06:52 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAGM6o01005560 for ; Sun, 16 Nov 2014 22:06:50 GMT Received: from 950129200 ([65.114.129.62]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAGM6mnB005506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 16 Nov 2014 22:06:49 GMT From: "Adrian Farrel" To: References: <20141116183702.6503.67463.idtracker@ietfa.amsl.com> In-Reply-To: <20141116183702.6503.67463.idtracker@ietfa.amsl.com> Date: Sun, 16 Nov 2014 22:06:48 -0000 Message-ID: <007b01d001e9$9f27fc70$dd77f550$@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: AQKz1l9TfXMmNAVB8uYyfFHlrLcrXpqcJKJg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21108.003 X-TM-AS-Result: No--12.461-10.0-31-10 X-imss-scan-details: No--12.461-10.0-31-10 X-TMASE-MatchedRID: eVEkOcJu0F4R9y8WJPyXEAlojktAVaJISg85P8ZMy4ZkPYxFX2FJyU+z yRCAu91ic8GePPemtNNCFtKy3P7onnpfkdT5lXmtxqZyCOmsQ/MZKp0SZ4P+dUklF5L0lQHcf/b TCoZRptJNYvDaO9t+nPE/T9QKeKEblRDjOOc8zGqVUcz8XpiS9HJrB0Cu3DDnRjHvrQ40NxZpu1 5EU/MkoGEnlnKqfWhLEbTaN9t6T45uOt28pPRUYlVCBNP48QP9JNtuyL6mpIUR34ro7k23nREXW gyXQw/xnK6NH0kJeVpPgpGv/PbptzB7AhAesYcjqUSkXJTN1/MLitYSIrUiB4NDCN4yZuhAhjmc VAGfBaKY1Z5D4Mt0UJGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPIfiAqrjYtFiSgeJq YFsQEO+Htq8UFpl9g3cPNL+BJhmtoVWVqHK+I5n7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/manet/N01pWquwqeojSFzosKHWC5fX9Fg Subject: Re: [manet] I-D Action: draft-gerla-manet-odmrp-asym-01.txt 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: Sun, 16 Nov 2014 22:07:10 -0000 I just want to thank the authors of this I-D and of draft-gerla-manet-odmrp for having the courage to propose them as experimental. The inclusion of section 1.1. Motivation and Experiments in draft-gerla-manet-odmrp is particularly helpful. To some extent, draft-gerla-manet-odmrp-asym, being an extension of draft-gerla-manet-odmrp, is automatically also experimental, but a similar section in the asym draft might also be nice since it would explain that "promotion" of draft-gerla-manet-odmrp to standards track (or the successful completion of the experiment) would not necessarily also advance the asym work - additional experimentation would be needed. Thanks for the work, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 16 November 2014 18:37 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-gerla-manet-odmrp-asym-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : ODMRP-ASYM > Authors : Mario Gerla > Soon Young Oh > Axel Colin de Verdiere > Filename : draft-gerla-manet-odmrp-asym-01.txt > Pages : 27 > Date : 2014-11-16 > > Abstract: > This document describes ODMRP-ASYM, an extension for the On Demand > Multicast Routing Protocol [ODMRP], which enables routers to use > unidirectional links to route multicast messages. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-gerla-manet-odmrp-asym-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 From nobody Tue Nov 18 02: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 7FE971A008C for ; Tue, 18 Nov 2014 02:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LUMY8vh-YU_B for ; Tue, 18 Nov 2014 02:07:11 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9AF1A0073 for ; Tue, 18 Nov 2014 02:07:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9BD461C0244; Tue, 18 Nov 2014 02:07:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.1.145] (APuteaux-655-1-230-116.w92-151.abo.wanadoo.fr [92.151.77.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 568681C01DA; Tue, 18 Nov 2014 02:07:09 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?windows-1252?Q?Axel_Colin_de_Verdi=E8re?= In-Reply-To: <007b01d001e9$9f27fc70$dd77f550$@olddog.co.uk> Date: Tue, 18 Nov 2014 11:07:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <951FE130-1428-4168-8F0D-A1B103AAFBB9@axelcdv.com> References: <20141116183702.6503.67463.idtracker@ietfa.amsl.com> <007b01d001e9$9f27fc70$dd77f550$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/c2ts08ZAht3C9wrUxYzHWLW32Ro Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-gerla-manet-odmrp-asym-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, 18 Nov 2014 10:07:13 -0000 Hi Adrian, Thank you, we=92ll add that to the next revision. Best, Axel Le 16 nov. 2014 =E0 23:06, Adrian Farrel a =E9crit = : > I just want to thank the authors of this I-D and of = draft-gerla-manet-odmrp for > having the courage to propose them as experimental. The inclusion of=20= > section 1.1. Motivation and Experiments in draft-gerla-manet-odmrp is > particularly helpful. >=20 > To some extent, draft-gerla-manet-odmrp-asym, being an extension of > draft-gerla-manet-odmrp, is automatically also experimental, but a = similar > section in the asym draft might also be nice since it would explain = that > "promotion" of draft-gerla-manet-odmrp to standards track (or the = successful > completion of the experiment) would not necessarily also advance the = asym work - > additional experimentation would be needed. >=20 > Thanks for the work, > Adrian >=20 >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf = Of >> internet-drafts@ietf.org >> Sent: 16 November 2014 18:37 >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-gerla-manet-odmrp-asym-01.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >>=20 >>=20 >> Title : ODMRP-ASYM >> Authors : Mario Gerla >> Soon Young Oh >> Axel Colin de Verdiere >> Filename : draft-gerla-manet-odmrp-asym-01.txt >> Pages : 27 >> Date : 2014-11-16 >>=20 >> Abstract: >> This document describes ODMRP-ASYM, an extension for the On Demand >> Multicast Routing Protocol [ODMRP], which enables routers to use >> unidirectional links to route multicast messages. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp-asym/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-01 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-asym-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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Nov 18 10:43: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 3DA011A6F14; Tue, 18 Nov 2014 10:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 abcxUb7ExXQM; Tue, 18 Nov 2014 10:43:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 516E81A6F05; Tue, 18 Nov 2014 10:43:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D77C0181C75; Tue, 18 Nov 2014 10:42:31 -0800 (PST) To: jpmacker@gmail.com, macker@itd.nrl.navy.mil X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141118184231.D77C0181C75@rfc-editor.org> Date: Tue, 18 Nov 2014 10:42:31 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/XtN23XvsRRgYaul1YYzxOlWUtiE Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Verified] RFC6621 (4098) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 18 Nov 2014 18:43:45 -0000 The following errata report has been verified for RFC6621, "Simplified Multicast Forwarding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=4098 -------------------------------------- Status: Verified Type: Editorial Reported by: Joe Macker Date Reported: 2014-09-04 Verified by: Adrian Farrel (IESG) Section: Appendix B Original Text ------------- This distributed relay set selection technique has been shown to approximate a minimal connected dominating set (MCDS) in [JLMV02]. Corrected Text -------------- This distributed relay set selection technique has been shown to approximate a minimum connected dominating set (MCDS) in [JLMV02]. Notes ----- Minimum connected dominating set [1] is the established terminology and minimal was an editorial error. [1] Sampathkumar, E.; Walikar, HB (1979), "The connected domination number of a graph", J. Math. Phys. Sci 13 (6): 607–613. -------------------------------------- RFC6621 (draft-ietf-manet-smf-14) -------------------------------------- Title : Simplified Multicast Forwarding Publication Date : May 2012 Author(s) : J. Macker, Ed. Category : EXPERIMENTAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 18 10:57: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 70E0E1A6F2E; Tue, 18 Nov 2014 10:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 yCuIb7Ld7bw4; Tue, 18 Nov 2014 10:57:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 558481A064C; Tue, 18 Nov 2014 10:57:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D3454181C75; Tue, 18 Nov 2014 10:56:48 -0800 (PST) To: Ronald.intVelt@tno.nl, T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141118185648.D3454181C75@rfc-editor.org> Date: Tue, 18 Nov 2014 10:56:48 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/L5TgHBNugwMi7Jy5oYwBNQ0wzhI Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Verified] RFC5444 (4178) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 18 Nov 2014 18:57:41 -0000 The following errata report has been verified for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=4178 -------------------------------------- Status: Verified Type: Editorial Reported by: Ronald in 't Velt Date Reported: 2014-11-13 Verified by: Adrian Farrel (IESG) Section: 6.5.1 Original Text ------------- When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26]. Corrected Text -------------- When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines an Address Block TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26]. Notes ----- 'Message TLV Type' should read 'Address Block TLV Type'. This is likely a 'Copy-Paste' error from section 6.4.1, which stipulates a similar requirement for Message TLV Type Extension Registry creation. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Nov 19 05: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 A5C1F1A3BA1 for ; Wed, 19 Nov 2014 05:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 F7cPzZUqhDi2 for ; Wed, 19 Nov 2014 05:53:12 -0800 (PST) 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 E06BF1A6F38 for ; Wed, 19 Nov 2014 05:53:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,417,1413241200"; d="scan'208,217";a="498256960" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Nov 2014 13:53:10 +0000 X-IronPort-AV: E=Sophos; i="5.07,417,1413241200"; d="scan'208,217"; a="72804364" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 19 Nov 2014 13:53:10 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Wed, 19 Nov 2014 13:53:10 +0000 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (ratliffstan@gmail.com)" , "Justin Dean (jdean@itd.nrl.navy.mil)" Thread-Topic: TLV naming draft Thread-Index: AdAD/1lMUmr+LWMgTlSqmHp4Z5GQpQ== Date: Wed, 19 Nov 2014 13:53:09 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DC38FBGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wQuqcVOjOSm5k2aknuRzcQanZGY Cc: "manet@ietf.org" Subject: [manet] TLV naming 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: Wed, 19 Nov 2014 13:53:15 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DC38FBGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable We would, as was said in Honolulu, like to request that draft-dearlove-mane= t-tlv-naming be adopted as a WG draft, and for the chairs to start this pro= cess. As also indicated, we will shortly thereafter be wanting to go to WGLC and = onwards, but one step at a time. For those who may have missed it, this draft just tidies up some details of= TLV naming, it has no actual impact on any protocol. However our AD has in= dicated that multitopology OLSRv2 (with the IESG for experimental status) w= on't be able to proceed to RFC without this. Of course comments welcome on any points arising. -- 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DC38FBGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

We would, as was said in Honolulu, like to request t= hat draft-dearlove-manet-tlv-naming be adopted as a WG draft, and for the c= hairs to start this process.

 

As also indicated, we will shortly thereafter be wan= ting to go to WGLC and onwards, but one step at a time.

 

For those who may have missed it, this draft just ti= dies up some details of TLV naming, it has no actual impact on any protocol= . However our AD has indicated that multitopology OLSRv2 (with the IESG for= experimental status) won’t be able to proceed to RFC without this.

 

Of course comments welcome on any points arising.

 

-- <= /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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DC38FBGLKXM0002VGREEN_-- From nobody Thu Nov 20 18:06: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 D31AC1A8A56 for ; Thu, 20 Nov 2014 18:06:46 -0800 (PST) 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 k9coIilAb24n for ; Thu, 20 Nov 2014 18:06:30 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A153A1A86E4 for ; Thu, 20 Nov 2014 18:05:23 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id k15so2770495qaq.24 for ; Thu, 20 Nov 2014 18:05:22 -0800 (PST) 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=iQpLSpxA902ZLbp65HjjPdbTpeNIIzcpqUKlmzUm3Ic=; b=P0jIpDPJv5Fn/1uXapzDa0LdHYMIfH2ZPfCsUGDqfcPuAG2iOt/D+XgTclzlsQZn/+ uKNf77Q71CfiQVGKLwOuMvFYHQUvgA875BR3DkJWp/2SC924E/Ryz66vvpOSuMYdNk0V x5tArUwMIjvSZGIXV8h/hZekzM0AJzs8D24X6RUPocIW07mT5Jv5zuY09yubY6At6ZNR K5TLrITtcv7i55eLwcfVpQ7JKY9vZG5P/QSeepcQ9Bsb/UonfQj5ZAeTM34MTW+FOJHh vKhp32nVCPWu5gU9XP8OeaOLyUKs0dvEX+EuPNr195//nxD7xm/Yg6pVkHbPOTwMhvvo jOfA== MIME-Version: 1.0 X-Received: by 10.224.39.10 with SMTP id d10mr2415554qae.29.1416535522786; Thu, 20 Nov 2014 18:05:22 -0800 (PST) Received: by 10.140.98.212 with HTTP; Thu, 20 Nov 2014 18:05:22 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Nov 2014 18:05:22 -0800 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NZ3QzfthWjBrxpth-FMcmwT7Jkg Cc: "manet@ietf.org" , "Justin Dean \(jdean@itd.nrl.navy.mil\)" Subject: Re: [manet] TLV naming 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: Fri, 21 Nov 2014 02:06:47 -0000 On 11/19/14, Dearlove, Christopher (UK) wrote: > > For those who may have missed it, this draft just tidies up some details of > TLV naming, it has no actual impact on any protocol. However our AD has > indicated that multitopology OLSRv2 (with the IESG for experimental status) > won't be able to proceed to RFC without this. I think that such indication of requesting a new draft and stoping one should be clear on the list but I did not see it. However, I understand from your message that this TLV naming draft is not updating any of our standards, but it is updating RFC5444 so this draft has impact on RFC5444. AB From nobody Thu Nov 20 18:21: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 EC35B1A8A71 for ; Thu, 20 Nov 2014 18:21:09 -0800 (PST) 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 KKrwumTRam3O for ; Thu, 20 Nov 2014 18:21:08 -0800 (PST) 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 C6AD11A8A69 for ; Thu, 20 Nov 2014 18:21:07 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id a108so3024700qge.39 for ; Thu, 20 Nov 2014 18:21:07 -0800 (PST) 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:content-transfer-encoding; bh=Wfo5R4KiXGvF7Iy6TSaE5bn27HqOSovNvUzXFz67x54=; b=TjSRplm008wu1fZhHnC12qCLUYCl53yVHZE/5Ul/95J3HZ7ueEWKHlkE8dlDqyg5Ql EHBhbF/MECCbTquZymE91HHIZYhfS2mm9asUxvfPVLdK0vfkWxVD+ojscnET32H3AYmL 8nYQTeFrQ6Emh8Q4ltaW91QDsOhl18vfsGQjnEeCqeE84ZtawAbORxQXbU0G6x3QLLlu kRT2f2xDhf3xXRL0xaSNwNs1Y0f+CXLq05leRvRTFJjctI5YXAkJedPhZB9cMeKypbdX DKUsZCz/tPpWHR79iAqEsZiTD/BxOWtUlYXOHfFwAx3jajMRxwgYPNcLn6xfCVypxHo/ qLEw== MIME-Version: 1.0 X-Received: by 10.224.39.10 with SMTP id d10mr2513067qae.29.1416536466974; Thu, 20 Nov 2014 18:21:06 -0800 (PST) Received: by 10.140.98.212 with HTTP; Thu, 20 Nov 2014 18:21:06 -0800 (PST) In-Reply-To: References: <20141111005114.27018.49670.idtracker@ietfa.amsl.com> Date: Thu, 20 Nov 2014 18:21:06 -0800 Message-ID: From: Abdussalam Baryun 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/n9-Nhmrnr8eVpG61xknbAAs5uLw Cc: manet Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology and draft-dearlove-manet-tlv-naming-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, 21 Nov 2014 02:21:10 -0000 Hi All, I don't know why we have to move things fast. Moving things fast adds possible errors, and may confuse the community. We need to consider that participants need to give a decision on when to move things fast and when not to move things fast. I don't agree to move this draft fast nor agreed to move the multitopology draft fast. We could have done fast process if the draft was discussed before published, so that the WG can decide if fast is required. Just my opinion how things go fast in organisation that involve all. On 11/10/14, Thomas Heide Clausen wrote: > Since, of course, all y=E2=80=99all are compulsively reading the ID-annou= nce mailing > list ;) you=E2=80=99ll have seen draft-dearlove-manet-tlv-naming-00.txt d= ocument > appear just today. > > This is in response to the review from our AD on > draft-ietf-manet-olsrv2-multitopology > (http://www.ietf.org/mail-archive/web/manet/current/msg16875.html > ), in > which he indicates that we probably should re-think the way we name TLV > types. > > As our AD requested, the authors did re-think, discuss a bit also with ou= r > AD and chairs, and came to a conclusion ... and that conclusion is in thi= s > I-D. I request that our discussions related to adopted work and future discussions to be done on the list or within minutes. I think the WG should be able to be included in discussion between AD and authors, why WG was excluded? Best Regards, AB From nobody Thu Nov 20 18:39: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 635D51A8A94 for ; Thu, 20 Nov 2014 18:39:39 -0800 (PST) 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 o3nP8acHaXSm for ; Thu, 20 Nov 2014 18:39:36 -0800 (PST) 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 AA3351A8A81 for ; Thu, 20 Nov 2014 18:39:35 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id q107so3111235qgd.13 for ; Thu, 20 Nov 2014 18:39:34 -0800 (PST) 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=luAMxw5ZX4A5VUe4ffH2WQFwUvr3584mPf413q2QD30=; b=pcRim6FjIig3pzcgOrG1K3tBF0z12lFhUHV+JsLogdgDKuUt1nlzPDTMl7Uv0rAqtf lvIP/xTqONh13i9seEE0FzcS/+1jtXrZk7EoiTEvFghmfrueRqwzVMghPhmqFQPsICw+ T93yseLZP+x3NMQJThB6qTjw6bbf5hbAIKl07U31viWVhYphy0UaYvS9+F3BMD1+cyIG tr03eGTD2X8Llmq9Pbu0zklRFs5e/5ntcRBRTx1ZNSl9SOTm1nW4un5Ogo/DTE4jqh18 YCV+w7yRgiNCIThjwRemdAVEqseu7DDhQnZpHQCO9foSHByRg3MZZe7/0q5ThkwaU/Et 7X1A== MIME-Version: 1.0 X-Received: by 10.140.32.136 with SMTP id h8mr2631698qgh.13.1416537574834; Thu, 20 Nov 2014 18:39:34 -0800 (PST) Received: by 10.140.98.212 with HTTP; Thu, 20 Nov 2014 18:39:34 -0800 (PST) In-Reply-To: References: <00f701cfbae2$9dbf5110$d93df330$@olddog.co.uk> Date: Thu, 20 Nov 2014 18:39:34 -0800 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/C0pFZ8jpVFa7ItaR3FCwKl65Cj8 Cc: "manet@ietf.org" , "draft-ietf-manet-olsrv2-multitopology.all@tools.ietf.org" Subject: Re: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 02:39:39 -0000 Dear Authors, I did not discuss this subject because waiting for the full respond from the authors, but still waiting for the full respond to the AD. I now see a decision [1] of blocking this multitopology-draft and writing another draft which has been indicated indirectly on the list. I recommend that the update draft TLV naming to be only for multitopology and not in general. [1] http://www.ietf.org/mail-archive/web/manet/current/msg17111.html On 8/18/14, Dearlove, Christopher (UK) wrote: > Just an acknowledgement of this. No time today at least to get to most of > it. And what follows is the problem, without any proposed solution. > Please help to answer all comments of the AD, so we need to discuss them to get to a best decision/conclusion. > I will just note that we have a n issue as to whether names should be > assigned to TLV types, or extended types. Sometimes a type naturally takes a > whole set of type and type extension, such as link metric. But sometimes > just a single extended type is required, and there's no reason for the other > extended types with the same type to have the same name. In fact it would be > quite confusing to have to do so. There should be a clear standard of how and when to do this naming, as you mentioned below that there should be a policy for RFC5444. > > So here we have an extended type that's related, but quite confusing to use > the same name for. Really here we want to name extended types. Simply using > the same name across all the extended types is not going to work longer term > (such as if we run out of types with extension zero). > > Of course this is a problem in that 5444 didn't describe a policy here, and > usage just evolved. Do you suggest writing a policy to solve the problem? > > With hindsight, I think I'd give types a name, and allow extended types to > have a name. We need to know when and for which reason that we do such naming with both types. > So in this case the type might be MPR related, type extension 0 > would be MPR_WILLING, then this would be proposing (just for the moment > let's ignore the experimental issue) that type extension 1 was MPR_TYPES > etc. Even that might be too restrictive (type name MPR is a rather narrow). > But several of our existing TLVs have no reason to have a block of 256 all > with same name (I do not see 256 variants of LINK_STATUS). > > -- > 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 Adrian Farrel > Sent: 18 August 2014 13:48 > To: draft-ietf-manet-olsrv2-multitopology.all@tools.ietf.org > Cc: manet@ietf.org > Subject: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology > > ----------------------! 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. > -------------------------------------------------------- > > Hi, > > I have started my AD review of your draft having received the publication > request. before I get too far into the document, I want to discuss the IANA > Considerations section which, I think, needs a little work. > > - - - > > The IANA Considerations section of the document does not give IANA clear > instructions about what they should do. They need to hear: > - go to registry named foo > - go to sub-registry named bar > - make the following change to the registry... > > Everything else is a distraction to them and needs to come out of the > document completely or be moved to another section. > > - - - > > But first, two meta questions: > > 1. In some of the sub-registries where you are assigning new Type > Extensions, there is already scope for "Experimental Use." Why do > you feel the need to have Expert Review assignments rather than using > experimental values (the latter would not have their values recorded > against this RFC nor have the values recorded in this RFC)? > > I should add here that you *are* allowed to have Expert Review > assignments for Experimental RFCs (if the experts so agree). > > 2. I am fixing (on this week's IESG telechat) the fact that many of > these sub-registries are missing their Designated Experts. That's a > formality, and the WG chairs can stand in these roles. > > However, I suspect that the DEs have not explicitly made clear that > they are OK with the assignments in this document. That's OK, but I > just need to know (normally in the Shepherd write-up) and to let you > know that IANA will ping the DEs at some point to get them to sign > off, so making sure that they are happy in advance is a good way to > avoid surprises. > > (The guidance to DEs in 5444/6.1 seems very clear.) > > - - - > > Section 13.1 as far as I can tell does not change the guidelines to the > Designated Experts that have already been established. So I think you can > safely delete this section. In particular, this section does not give IANA > any information. > > - - - > > Section 13.2 > >> This specification replaces Table 11 of [RFC7181]. > > This reads like you are Updating 7181 (i.e. changing that specification). > I don't believe that is your intention > > >> That specified a >> Message MPR Type described as MPR_WILLING, for which only Type >> Extension 0 was defined. This specification reserves that name >> MPR_WILLING for Type Extension 0, > > I think you mean "retains". "Reserve" has a specific IANA meaning of "not > available for use". > > However, it appears that you are updating the text for the MPR_WILLING/0 > value in the "MPR_WILLING Message Type Extensions" sub-registry found at > https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#mpr-wil > ling-message-type-extension > > This you observe in the next sentence where you say: > >> It also changes the Value field >> specification of the MPR_WILLING TLV. > > You need to show IANA the old text and the new text. I think that the text > in your Table 2 may be useful to retain in this document (in another > section) but is too much text for IANA to include in their registry. > >> defines a new Type Extension 1, with a new name MPR_TYPES, > > I don't think you can do this! > Type 7 is already entirely known as MPR_WILLING (see the "Message TLV Types" > sub-registry). > > So your choice here is to use a new Message TLV or to retain the same name > for the new Type Extension. > > As far as IANA is concerned, you need to tell them: > - in which sub-registry to include Type Extension 1 > - what text to include with it > >> and leaves the remaining Type Extensions of this TLV Type unnamed. > > "Unnamed"? Maybe you mean "Unassigned"? > >> Specifications of these TLVs are in Table 2. Each of these TLVs MUST >> NOT be included more than once in a Message TLV Block. > > I don't think that IANA needs to see this table, and certainly doesn't need > to know about the protocol rules. > > - - - > > Section 13.3 > >> Table 16 of [RFC7181] is replaced by Table 3. Note that the only >> change is to the description of the Value field. > > If you are replacing a table in 7181 then you are updating 7181. But is that > what this draft is doing? > > Anyway, I don't think IANA is interested in this point. They want to know > what changes to make to the "GATEWAY Address Block TLV Type Extensions" > sub-registry at > https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#gateway > -address-block-tlv-type-extension > > Again, just old and new text. > > If you want to include Table 3 in this document, then please put it outside > this section. > >> Table 13 of [RFC7181] is replaced by Table 4. Note that the only >> change is to allocate 8 Type Extensions as assigned by administrative >> action, in order to support administratively determined multi- >> topologies. > > Pretty much exactly the same considerations. > > - - - > > If you can answer all this quickly, I can go ahead with the rest of my > review. I suspect that the answers will need a revised I-D, but we can batch > that with the rest of my review once I know what the answers are. > > Thanks, > Adrian > IMHO, the WG should discuss the respond from the AD. Best Regards AB From nobody Fri Nov 21 01:46: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 34A081AD2EE for ; Fri, 21 Nov 2014 01:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIpFW3cZpATS for ; Fri, 21 Nov 2014 01:46:23 -0800 (PST) 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 2ED871A0120 for ; Fri, 21 Nov 2014 01:46:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,429,1413241200"; d="scan'208";a="421465781" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 21 Nov 2014 09:46:21 +0000 X-IronPort-AV: E=Sophos;i="5.07,429,1413241200"; d="scan'208";a="81420782" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 21 Nov 2014 09:46:22 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 09:46:20 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] TLV naming draft Thread-Index: AdAD/1lMUmr+LWMgTlSqmHp4Z5GQpQBMEHwAAA//VAA= Date: Fri, 21 Nov 2014 09:46:18 +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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MnKMkqns-GZoktvF5HhRX1Tr8hY Cc: "manet@ietf.org" , "Justin Dean \(jdean@itd.nrl.navy.mil\)" Subject: Re: [manet] TLV naming 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: Fri, 21 Nov 2014 09:46:27 -0000 VGhlIGltcGFjdCBvbiA1NDQ0IGlzIGxpbWl0ZWQgdG8gYWRkaW5nIGFkdmljZSB0byB0aGUgZGVz aWduYXRlZCBleHBlcnRzIHdobyBhcmUgcmVzcG9uc2libGUgZm9yIFRMViBhbGxvY2F0aW9ucyB0 byBlbnN1cmUgbmFtaW5nIG9mIG5ldyBUTFZzIGZvbGxvd3MgdGhpcyBwYXR0ZXJuLiBJdCBoYXMg bm8gaW1wYWN0IG9uIGFueSBhY3R1YWwgcHJvdG9jb2wsIGFzIGlzIG5vdGVkLiBUaGUgYXV0aG9y cyBoYXZlIG1hcmtlZCBpdCBhcyB1cGRhdGluZyA1NDQ0IGZvciB0aGF0IHRlY2huaWNhbCByZWFz b24sIGJ1dCBhcmVuJ3Qgd2VkZGluZyB0byB0aGF0IGRlc2NyaXB0aW9uLg0KDQotLSANCkNocmlz dG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBB c3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlz aXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldl c3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwg VUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJB RSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2lj ayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9y b3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMg Tm86IDE5OTY2ODcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFiZHVzc2Fs YW0gQmFyeXVuIFttYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb21dIA0KU2VudDogMjEg Tm92ZW1iZXIgMjAxNCAwMjowNQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzog U3RhbiBSYXRsaWZmIChyYXRsaWZmc3RhbkBnbWFpbC5jb20pOyBKdXN0aW4gRGVhbiAoamRlYW5A aXRkLm5ybC5uYXZ5Lm1pbCk7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBU TFYgbmFtaW5nIGRyYWZ0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20g dGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGlj ayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRo ZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3Ry dWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9uIDEx LzE5LzE0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20+IHdyb3RlOg0KPg0KPiBGb3IgdGhvc2Ugd2hvIG1heSBoYXZlIG1pc3NlZCBpdCwg dGhpcyBkcmFmdCBqdXN0IHRpZGllcyB1cCBzb21lIA0KPiBkZXRhaWxzIG9mIFRMViBuYW1pbmcs IGl0IGhhcyBubyBhY3R1YWwgaW1wYWN0IG9uIGFueSBwcm90b2NvbC4gDQo+IEhvd2V2ZXIgb3Vy IEFEIGhhcyBpbmRpY2F0ZWQgdGhhdCBtdWx0aXRvcG9sb2d5IE9MU1J2MiAod2l0aCB0aGUgSUVT RyANCj4gZm9yIGV4cGVyaW1lbnRhbCBzdGF0dXMpIHdvbid0IGJlIGFibGUgdG8gcHJvY2VlZCB0 byBSRkMgd2l0aG91dCB0aGlzLg0KDQpJIHRoaW5rIHRoYXQgc3VjaCBpbmRpY2F0aW9uIG9mIHJl cXVlc3RpbmcgYSBuZXcgZHJhZnQgYW5kIHN0b3Bpbmcgb25lIHNob3VsZCBiZSBjbGVhciBvbiB0 aGUgbGlzdCBidXQgSSBkaWQgbm90IHNlZSBpdC4gSG93ZXZlciwgSSB1bmRlcnN0YW5kIGZyb20g eW91ciBtZXNzYWdlIHRoYXQgdGhpcyBUTFYgbmFtaW5nIGRyYWZ0IGlzIG5vdCB1cGRhdGluZyBh bnkgb2Ygb3VyIHN0YW5kYXJkcywgYnV0IGl0IGlzIHVwZGF0aW5nIFJGQzU0NDQgc28gdGhpcyBk cmFmdCBoYXMgaW1wYWN0IG9uIFJGQzU0NDQuDQoNCkFCDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVj aXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90 aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkg cHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioK From nobody Fri Nov 21 01:50: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 4AFBA1AD2EE for ; Fri, 21 Nov 2014 01:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.894 X-Spam-Level: X-Spam-Status: No, score=-6.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43it8YqxuuRo for ; Fri, 21 Nov 2014 01:50:04 -0800 (PST) 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 68D991A0120 for ; Fri, 21 Nov 2014 01:49:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,429,1413241200"; d="scan'208";a="421467120" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 21 Nov 2014 09:49:58 +0000 X-IronPort-AV: E=Sophos;i="5.07,429,1413241200"; d="scan'208";a="81421507" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 21 Nov 2014 09:49:59 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 09:49:57 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology Thread-Index: Ac+64mvEANyRLPOUQ8yCPW+VZPQnvgACzbegEpGv7QAADu/lEA== Date: Fri, 21 Nov 2014 09:49:56 +0000 Message-ID: References: <00f701cfbae2$9dbf5110$d93df330$@olddog.co.uk> 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/XrjeQonHpPBhppD0OC4nn1GLhk4 Cc: "manet@ietf.org" , "draft-ietf-manet-olsrv2-multitopology.all@tools.ietf.org" Subject: Re: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 09:50:10 -0000 VGhhdCdzIG5vdCByZWFsbHkgc2Vuc2libGUuIFdoaWxlIHdlIGhhdmUgYSBzaG9ydC10ZXJtIG5l ZWQgb25seSB0byByZW9yZ2FuaXNlIHRoZSBuYW1pbmcgb2Ygc29tZSBvZiB0aGUgYWxsb2NhdGVk IFRMVnMsIHRoZSBpZGVhIG9mIGV4cGxhaW5pbmcgYSBwcmluY2lwbGUsIHRoZW4ganVzdCBkb2lu ZyBzb21lIG9mIHRoZW0sIGxlYXZpbmcgb3RoZXJzIG5lZWRpbmcgdG8gYmUgZG9uZSBsYXRlciwg aXMgbm90IGEgZ29vZCBwbGFuLiBHZXQgaXQgYWxsIGRvbmUsIGluY2x1ZGluZyBhZHZpY2UgZm9y IHRoZSBmdXR1cmUsIGlzIHdoYXQgd2Ugc2hvdWxkIGRvLCBhbmQgaGF2ZSBkb25lLg0KDQotLSAN CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1h dGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2Ug QW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50 cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00y IDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0K Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t DQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTog V2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBG YXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYg V2FsZXMgTm86IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0gDQpT ZW50OiAyMSBOb3ZlbWJlciAyMDE0IDAyOjQwDQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChV SykNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0 aXRvcG9sb2d5LmFsbEB0b29scy5pZXRmLm9yZzsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbWFuZXRdIElBTkEgc2VjdGlvbiBvZiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXRv cG9sb2d5DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVy bmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkg bGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0 IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBv biByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkRlYXIgQXV0aG9ycywN Cg0KSSBkaWQgbm90IGRpc2N1c3MgdGhpcyBzdWJqZWN0IGJlY2F1c2Ugd2FpdGluZyBmb3IgdGhl IGZ1bGwgcmVzcG9uZCBmcm9tIHRoZSBhdXRob3JzLCBidXQgc3RpbGwgd2FpdGluZyBmb3IgdGhl IGZ1bGwgcmVzcG9uZCB0byB0aGUgQUQuIEkgbm93IHNlZSBhIGRlY2lzaW9uIFsxXSBvZiBibG9j a2luZyB0aGlzIG11bHRpdG9wb2xvZ3ktZHJhZnQgYW5kIHdyaXRpbmcgYW5vdGhlciBkcmFmdCB3 aGljaCBoYXMgYmVlbiBpbmRpY2F0ZWQgaW5kaXJlY3RseSBvbiB0aGUgbGlzdC4NCkkgcmVjb21t ZW5kIHRoYXQgdGhlIHVwZGF0ZSBkcmFmdCBUTFYgbmFtaW5nIHRvIGJlIG9ubHkgZm9yIG11bHRp dG9wb2xvZ3kgYW5kIG5vdCBpbiBnZW5lcmFsLg0KDQpbMV0gaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTcxMTEuaHRtbA0KDQpPbiA4LzE4LzE0 LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20+IHdyb3RlOg0KPiBKdXN0IGFuIGFja25vd2xlZGdlbWVudCBvZiB0aGlzLiBObyB0aW1lIHRv ZGF5IGF0IGxlYXN0IHRvIGdldCB0byBtb3N0IA0KPiBvZiBpdC4gQW5kIHdoYXQgZm9sbG93cyBp cyB0aGUgcHJvYmxlbSwgd2l0aG91dCBhbnkgcHJvcG9zZWQgc29sdXRpb24uDQo+DQoNClBsZWFz ZSBoZWxwIHRvIGFuc3dlciBhbGwgY29tbWVudHMgb2YgdGhlIEFELCBzbyB3ZSBuZWVkIHRvIGRp c2N1c3MgdGhlbSB0byBnZXQgdG8gYSBiZXN0IGRlY2lzaW9uL2NvbmNsdXNpb24uDQoNCg0KPiBJ IHdpbGwganVzdCBub3RlIHRoYXQgd2UgaGF2ZSBhIG4gaXNzdWUgYXMgdG8gd2hldGhlciBuYW1l cyBzaG91bGQgYmUgDQo+IGFzc2lnbmVkIHRvIFRMViB0eXBlcywgb3IgZXh0ZW5kZWQgdHlwZXMu IFNvbWV0aW1lcyBhIHR5cGUgbmF0dXJhbGx5IA0KPiB0YWtlcyBhIHdob2xlIHNldCBvZiB0eXBl IGFuZCB0eXBlIGV4dGVuc2lvbiwgc3VjaCBhcyBsaW5rIG1ldHJpYy4gQnV0IA0KPiBzb21ldGlt ZXMganVzdCBhIHNpbmdsZSBleHRlbmRlZCB0eXBlIGlzIHJlcXVpcmVkLCBhbmQgdGhlcmUncyBu byANCj4gcmVhc29uIGZvciB0aGUgb3RoZXIgZXh0ZW5kZWQgdHlwZXMgd2l0aCB0aGUgc2FtZSB0 eXBlIHRvIGhhdmUgdGhlIA0KPiBzYW1lIG5hbWUuIEluIGZhY3QgaXQgd291bGQgYmUgcXVpdGUg Y29uZnVzaW5nIHRvIGhhdmUgdG8gZG8gc28uDQoNClRoZXJlIHNob3VsZCBiZSBhIGNsZWFyIHN0 YW5kYXJkIG9mIGhvdyBhbmQgd2hlbiB0byBkbyB0aGlzIG5hbWluZywgYXMgeW91IG1lbnRpb25l ZCBiZWxvdyB0aGF0IHRoZXJlIHNob3VsZCBiZSBhIHBvbGljeSBmb3IgUkZDNTQ0NC4NCg0KPg0K PiBTbyBoZXJlIHdlIGhhdmUgYW4gZXh0ZW5kZWQgdHlwZSB0aGF0J3MgcmVsYXRlZCwgYnV0IHF1 aXRlIGNvbmZ1c2luZyANCj4gdG8gdXNlIHRoZSBzYW1lIG5hbWUgZm9yLiBSZWFsbHkgaGVyZSB3 ZSB3YW50IHRvIG5hbWUgZXh0ZW5kZWQgdHlwZXMuIA0KPiBTaW1wbHkgdXNpbmcgdGhlIHNhbWUg bmFtZSBhY3Jvc3MgYWxsIHRoZSBleHRlbmRlZCB0eXBlcyBpcyBub3QgZ29pbmcgDQo+IHRvIHdv cmsgbG9uZ2VyIHRlcm0gKHN1Y2ggYXMgaWYgd2UgcnVuIG91dCBvZiB0eXBlcyB3aXRoIGV4dGVu c2lvbiB6ZXJvKS4NCj4NCj4gT2YgY291cnNlIHRoaXMgaXMgYSBwcm9ibGVtIGluIHRoYXQgNTQ0 NCBkaWRuJ3QgZGVzY3JpYmUgYSBwb2xpY3kgDQo+IGhlcmUsIGFuZCB1c2FnZSBqdXN0IGV2b2x2 ZWQuDQoNCkRvIHlvdSBzdWdnZXN0IHdyaXRpbmcgYSBwb2xpY3kgdG8gc29sdmUgdGhlIHByb2Js ZW0/DQoNCj4NCj4gV2l0aCBoaW5kc2lnaHQsIEkgdGhpbmsgSSdkIGdpdmUgdHlwZXMgYSBuYW1l LCBhbmQgYWxsb3cgZXh0ZW5kZWQgDQo+IHR5cGVzIHRvIGhhdmUgYSBuYW1lLg0KDQpXZSBuZWVk IHRvIGtub3cgd2hlbiBhbmQgZm9yIHdoaWNoIHJlYXNvbiB0aGF0IHdlIGRvIHN1Y2ggbmFtaW5n IHdpdGggYm90aCB0eXBlcy4NCg0KPiBTbyBpbiB0aGlzIGNhc2UgdGhlIHR5cGUgbWlnaHQgYmUg TVBSIHJlbGF0ZWQsIHR5cGUgZXh0ZW5zaW9uIDAgd291bGQgDQo+IGJlIE1QUl9XSUxMSU5HLCB0 aGVuIHRoaXMgd291bGQgYmUgcHJvcG9zaW5nIChqdXN0IGZvciB0aGUgbW9tZW50IA0KPiBsZXQn cyBpZ25vcmUgdGhlIGV4cGVyaW1lbnRhbCBpc3N1ZSkgdGhhdCB0eXBlIGV4dGVuc2lvbiAxIHdh cyANCj4gTVBSX1RZUEVTIGV0Yy4gRXZlbiB0aGF0IG1pZ2h0IGJlIHRvbyByZXN0cmljdGl2ZSAo dHlwZSBuYW1lIE1QUiBpcyBhIHJhdGhlciBuYXJyb3cpLg0KPiBCdXQgc2V2ZXJhbCBvZiBvdXIg ZXhpc3RpbmcgVExWcyBoYXZlIG5vIHJlYXNvbiB0byBoYXZlIGEgYmxvY2sgb2YgMjU2IA0KPiBh bGwgd2l0aCBzYW1lIG5hbWUgKEkgZG8gbm90IHNlZSAyNTYgdmFyaWFudHMgb2YgTElOS19TVEFU VVMpLg0KPg0KPiAtLQ0KPiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KPiBTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXAgQ29tbXVuaWNhdGlvbnMsIA0K PiBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eSBCQUUgU3lzdGVtcyBBZHZh bmNlZCBUZWNobm9sb2d5IA0KPiBDZW50cmUgV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQg QmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KPiBUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8 ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNCANCj4gY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20g fCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQo+DQo+IEJBRSBTeXN0ZW1zIChPcGVyYXRpb25z KSBMaW1pdGVkDQo+IFJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcs IEZhcm5ib3JvdWdoIEFlcm9zcGFjZSANCj4gQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdV MTQgNllVLCBVSyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyANCj4gTm86IDE5OTY2ODcN Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWFuZXQgW21haWx0bzpt YW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiBTZW50 OiAxOCBBdWd1c3QgMjAxNCAxMzo0OA0KPiBUbzogZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVs dGl0b3BvbG9neS5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IG1hbmV0QGlldGYub3JnDQo+IFN1 YmplY3Q6IFttYW5ldF0gSUFOQSBzZWN0aW9uIG9mIGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11 bHRpdG9wb2xvZ3kNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIA0KPiBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCANCj4gcGFydG5lciBv ciBmcm9tIHRoZSBpbnRlcm5ldC4NCj4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNo b3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IA0KPiBhdHRhY2htZW50cyBvciByZXBs eS4NCj4gRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1h dHRlcnMgZm9yIA0KPiBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwg bWVzc2FnZXMuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+DQo+IEhpLA0KPg0KPiBJIGhhdmUgc3RhcnRlZCBteSBBRCByZXZpZXcg b2YgeW91ciBkcmFmdCBoYXZpbmcgcmVjZWl2ZWQgdGhlIA0KPiBwdWJsaWNhdGlvbiByZXF1ZXN0 LiBiZWZvcmUgSSBnZXQgdG9vIGZhciBpbnRvIHRoZSBkb2N1bWVudCwgSSB3YW50IHRvIA0KPiBk aXNjdXNzIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2hpY2gsIEkgdGhpbmssIG5l ZWRzIGEgbGl0dGxlIHdvcmsuDQo+DQo+IC0gLSAtDQo+DQo+IFRoZSBJQU5BIENvbnNpZGVyYXRp b25zIHNlY3Rpb24gb2YgdGhlIGRvY3VtZW50IGRvZXMgbm90IGdpdmUgSUFOQSANCj4gY2xlYXIg aW5zdHJ1Y3Rpb25zIGFib3V0IHdoYXQgdGhleSBzaG91bGQgZG8uIFRoZXkgbmVlZCB0byBoZWFy Og0KPiAtIGdvIHRvIHJlZ2lzdHJ5IG5hbWVkIGZvbw0KPiAtIGdvIHRvIHN1Yi1yZWdpc3RyeSBu YW1lZCBiYXINCj4gLSBtYWtlIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHRoZSByZWdpc3RyeS4u Lg0KPg0KPiBFdmVyeXRoaW5nIGVsc2UgaXMgYSBkaXN0cmFjdGlvbiB0byB0aGVtIGFuZCBuZWVk cyB0byBjb21lIG91dCBvZiB0aGUgDQo+IGRvY3VtZW50IGNvbXBsZXRlbHkgb3IgYmUgbW92ZWQg dG8gYW5vdGhlciBzZWN0aW9uLg0KPg0KPiAtIC0gLQ0KPg0KPiBCdXQgZmlyc3QsIHR3byBtZXRh IHF1ZXN0aW9uczoNCj4NCj4gMS4gSW4gc29tZSBvZiB0aGUgc3ViLXJlZ2lzdHJpZXMgd2hlcmUg eW91IGFyZSBhc3NpZ25pbmcgbmV3IFR5cGUNCj4gICAgRXh0ZW5zaW9ucywgdGhlcmUgaXMgYWxy ZWFkeSBzY29wZSBmb3IgIkV4cGVyaW1lbnRhbCBVc2UuIiAgV2h5IGRvDQo+ICAgIHlvdSBmZWVs IHRoZSBuZWVkIHRvIGhhdmUgRXhwZXJ0IFJldmlldyBhc3NpZ25tZW50cyByYXRoZXIgdGhhbiB1 c2luZw0KPiAgICBleHBlcmltZW50YWwgdmFsdWVzICh0aGUgbGF0dGVyIHdvdWxkIG5vdCBoYXZl IHRoZWlyIHZhbHVlcyByZWNvcmRlZA0KPiAgICBhZ2FpbnN0IHRoaXMgUkZDIG5vciBoYXZlIHRo ZSB2YWx1ZXMgcmVjb3JkZWQgaW4gdGhpcyBSRkMpPw0KPg0KPiAgICBJIHNob3VsZCBhZGQgaGVy ZSB0aGF0IHlvdSAqYXJlKiBhbGxvd2VkIHRvIGhhdmUgRXhwZXJ0IFJldmlldw0KPiAgICBhc3Np Z25tZW50cyBmb3IgRXhwZXJpbWVudGFsIFJGQ3MgKGlmIHRoZSBleHBlcnRzIHNvIGFncmVlKS4N Cj4NCj4gMi4gSSBhbSBmaXhpbmcgKG9uIHRoaXMgd2VlaydzIElFU0cgdGVsZWNoYXQpIHRoZSBm YWN0IHRoYXQgbWFueSBvZg0KPiAgICB0aGVzZSBzdWItcmVnaXN0cmllcyBhcmUgbWlzc2luZyB0 aGVpciBEZXNpZ25hdGVkIEV4cGVydHMuIFRoYXQncyBhDQo+ICAgIGZvcm1hbGl0eSwgYW5kIHRo ZSBXRyBjaGFpcnMgY2FuIHN0YW5kIGluIHRoZXNlIHJvbGVzLg0KPg0KPiAgICBIb3dldmVyLCBJ IHN1c3BlY3QgdGhhdCB0aGUgREVzIGhhdmUgbm90IGV4cGxpY2l0bHkgbWFkZSBjbGVhciB0aGF0 DQo+ICAgIHRoZXkgYXJlIE9LIHdpdGggdGhlIGFzc2lnbm1lbnRzIGluIHRoaXMgZG9jdW1lbnQu IFRoYXQncyBPSywgYnV0IEkNCj4gICAganVzdCBuZWVkIHRvIGtub3cgKG5vcm1hbGx5IGluIHRo ZSBTaGVwaGVyZCB3cml0ZS11cCkgYW5kIHRvIGxldCB5b3UNCj4gICAga25vdyB0aGF0IElBTkEg d2lsbCBwaW5nIHRoZSBERXMgYXQgc29tZSBwb2ludCB0byBnZXQgdGhlbSB0byBzaWduDQo+ICAg IG9mZiwgc28gbWFraW5nIHN1cmUgdGhhdCB0aGV5IGFyZSBoYXBweSBpbiBhZHZhbmNlIGlzIGEg Z29vZCB3YXkgdG8NCj4gICAgYXZvaWQgc3VycHJpc2VzLg0KPg0KPiAgICAoVGhlIGd1aWRhbmNl IHRvIERFcyBpbiA1NDQ0LzYuMSBzZWVtcyB2ZXJ5IGNsZWFyLikNCj4NCj4gLSAtIC0NCj4NCj4g U2VjdGlvbiAxMy4xIGFzIGZhciBhcyBJIGNhbiB0ZWxsIGRvZXMgbm90IGNoYW5nZSB0aGUgZ3Vp ZGVsaW5lcyB0byANCj4gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0cyB0aGF0IGhhdmUgYWxyZWFkeSBi ZWVuIGVzdGFibGlzaGVkLiBTbyBJIHRoaW5rIA0KPiB5b3UgY2FuIHNhZmVseSBkZWxldGUgdGhp cyBzZWN0aW9uLiBJbiBwYXJ0aWN1bGFyLCB0aGlzIHNlY3Rpb24gZG9lcyANCj4gbm90IGdpdmUg SUFOQSBhbnkgaW5mb3JtYXRpb24uDQo+DQo+IC0gLSAtDQo+DQo+IFNlY3Rpb24gMTMuMg0KPg0K Pj4gIFRoaXMgc3BlY2lmaWNhdGlvbiByZXBsYWNlcyBUYWJsZSAxMSBvZiBbUkZDNzE4MV0uDQo+ DQo+IFRoaXMgcmVhZHMgbGlrZSB5b3UgYXJlIFVwZGF0aW5nIDcxODEgKGkuZS4gY2hhbmdpbmcg dGhhdCBzcGVjaWZpY2F0aW9uKS4NCj4gSSBkb24ndCBiZWxpZXZlIHRoYXQgaXMgeW91ciBpbnRl bnRpb24NCj4NCj4NCj4+ICBUaGF0IHNwZWNpZmllZCBhDQo+PiAgTWVzc2FnZSBNUFIgVHlwZSBk ZXNjcmliZWQgYXMgTVBSX1dJTExJTkcsIGZvciB3aGljaCBvbmx5IFR5cGUgDQo+PiBFeHRlbnNp b24gMCB3YXMgZGVmaW5lZC4gIFRoaXMgc3BlY2lmaWNhdGlvbiByZXNlcnZlcyB0aGF0IG5hbWUg DQo+PiBNUFJfV0lMTElORyBmb3IgVHlwZSBFeHRlbnNpb24gMCwNCj4NCj4gSSB0aGluayB5b3Ug bWVhbiAicmV0YWlucyIuICJSZXNlcnZlIiBoYXMgYSBzcGVjaWZpYyBJQU5BIG1lYW5pbmcgb2Yg DQo+ICJub3QgYXZhaWxhYmxlIGZvciB1c2UiLg0KPg0KPiBIb3dldmVyLCBpdCBhcHBlYXJzIHRo YXQgeW91IGFyZSB1cGRhdGluZyB0aGUgdGV4dCBmb3IgdGhlIA0KPiBNUFJfV0lMTElORy8wIHZh bHVlIGluIHRoZSAiTVBSX1dJTExJTkcgTWVzc2FnZSBUeXBlIEV4dGVuc2lvbnMiIA0KPiBzdWIt cmVnaXN0cnkgZm91bmQgYXQgDQo+IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL21h bmV0LXBhcmFtZXRlcnMvbWFuZXQtcGFyYW1ldGVycy54aHQNCj4gbWwjbXByLXdpbA0KPiBsaW5n LW1lc3NhZ2UtdHlwZS1leHRlbnNpb24NCj4NCj4gVGhpcyB5b3Ugb2JzZXJ2ZSBpbiB0aGUgbmV4 dCBzZW50ZW5jZSB3aGVyZSB5b3Ugc2F5Og0KPg0KPj4gIEl0IGFsc28gY2hhbmdlcyB0aGUgVmFs dWUgZmllbGQNCj4+ICBzcGVjaWZpY2F0aW9uIG9mIHRoZSBNUFJfV0lMTElORyBUTFYuDQo+DQo+ IFlvdSBuZWVkIHRvIHNob3cgSUFOQSB0aGUgb2xkIHRleHQgYW5kIHRoZSBuZXcgdGV4dC4gSSB0 aGluayB0aGF0IHRoZSANCj4gdGV4dCBpbiB5b3VyIFRhYmxlIDIgbWF5IGJlIHVzZWZ1bCB0byBy ZXRhaW4gaW4gdGhpcyBkb2N1bWVudCAoaW4gDQo+IGFub3RoZXINCj4gc2VjdGlvbikgYnV0IGlz IHRvbyBtdWNoIHRleHQgZm9yIElBTkEgdG8gaW5jbHVkZSBpbiB0aGVpciByZWdpc3RyeS4NCj4N Cj4+ICBkZWZpbmVzIGEgbmV3IFR5cGUgRXh0ZW5zaW9uIDEsIHdpdGggYSBuZXcgbmFtZSBNUFJf VFlQRVMsDQo+DQo+IEkgZG9uJ3QgdGhpbmsgeW91IGNhbiBkbyB0aGlzIQ0KPiBUeXBlIDcgaXMg YWxyZWFkeSBlbnRpcmVseSBrbm93biBhcyBNUFJfV0lMTElORyAoc2VlIHRoZSAiTWVzc2FnZSBU TFYgVHlwZXMiDQo+IHN1Yi1yZWdpc3RyeSkuDQo+DQo+IFNvIHlvdXIgY2hvaWNlIGhlcmUgaXMg dG8gdXNlIGEgbmV3IE1lc3NhZ2UgVExWIG9yIHRvIHJldGFpbiB0aGUgc2FtZSANCj4gbmFtZSBm b3IgdGhlIG5ldyBUeXBlIEV4dGVuc2lvbi4NCj4NCj4gQXMgZmFyIGFzIElBTkEgaXMgY29uY2Vy bmVkLCB5b3UgbmVlZCB0byB0ZWxsIHRoZW06DQo+IC0gaW4gd2hpY2ggc3ViLXJlZ2lzdHJ5IHRv IGluY2x1ZGUgVHlwZSBFeHRlbnNpb24gMQ0KPiAtIHdoYXQgdGV4dCB0byBpbmNsdWRlIHdpdGgg aXQNCj4NCj4+ICBhbmQgbGVhdmVzIHRoZSByZW1haW5pbmcgVHlwZSBFeHRlbnNpb25zICBvZiB0 aGlzIFRMViBUeXBlIHVubmFtZWQuDQo+DQo+ICJVbm5hbWVkIj8gTWF5YmUgeW91IG1lYW4gIlVu YXNzaWduZWQiPw0KPg0KPj4gIFNwZWNpZmljYXRpb25zIG9mIHRoZXNlIFRMVnMgYXJlIGluIFRh YmxlIDIuICBFYWNoIG9mIHRoZXNlIFRMVnMgDQo+PiBNVVNUIE5PVCBiZSBpbmNsdWRlZCBtb3Jl IHRoYW4gb25jZSBpbiBhIE1lc3NhZ2UgVExWIEJsb2NrLg0KPg0KPiBJIGRvbid0IHRoaW5rIHRo YXQgSUFOQSBuZWVkcyB0byBzZWUgdGhpcyB0YWJsZSwgYW5kIGNlcnRhaW5seSBkb2Vzbid0IA0K PiBuZWVkIHRvIGtub3cgYWJvdXQgdGhlIHByb3RvY29sIHJ1bGVzLg0KPg0KPiAtIC0gLQ0KPg0K PiBTZWN0aW9uIDEzLjMNCj4NCj4+ICBUYWJsZSAxNiBvZiBbUkZDNzE4MV0gaXMgcmVwbGFjZWQg YnkgVGFibGUgMy4gIE5vdGUgdGhhdCB0aGUgb25seSANCj4+IGNoYW5nZSBpcyB0byB0aGUgZGVz Y3JpcHRpb24gb2YgdGhlIFZhbHVlIGZpZWxkLg0KPg0KPiBJZiB5b3UgYXJlIHJlcGxhY2luZyBh IHRhYmxlIGluIDcxODEgdGhlbiB5b3UgYXJlIHVwZGF0aW5nIDcxODEuIEJ1dCANCj4gaXMgdGhh dCB3aGF0IHRoaXMgZHJhZnQgaXMgZG9pbmc/DQo+DQo+IEFueXdheSwgSSBkb24ndCB0aGluayBJ QU5BIGlzIGludGVyZXN0ZWQgaW4gdGhpcyBwb2ludC4gVGhleSB3YW50IHRvIA0KPiBrbm93IHdo YXQgY2hhbmdlcyB0byBtYWtlIHRvIHRoZSAiR0FURVdBWSBBZGRyZXNzIEJsb2NrIFRMViBUeXBl IEV4dGVuc2lvbnMiDQo+IHN1Yi1yZWdpc3RyeSBhdA0KPiBodHRwczovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy9tYW5ldC1wYXJhbWV0ZXJzL21hbmV0LXBhcmFtZXRlcnMueGh0DQo+IG1sI2dh dGV3YXkNCj4gLWFkZHJlc3MtYmxvY2stdGx2LXR5cGUtZXh0ZW5zaW9uDQo+DQo+IEFnYWluLCBq dXN0IG9sZCBhbmQgbmV3IHRleHQuDQo+DQo+IElmIHlvdSB3YW50IHRvIGluY2x1ZGUgVGFibGUg MyBpbiB0aGlzIGRvY3VtZW50LCB0aGVuIHBsZWFzZSBwdXQgaXQgDQo+IG91dHNpZGUgdGhpcyBz ZWN0aW9uLg0KPg0KPj4gIFRhYmxlIDEzIG9mIFtSRkM3MTgxXSBpcyByZXBsYWNlZCBieSBUYWJs ZSA0LiAgTm90ZSB0aGF0IHRoZSBvbmx5IA0KPj4gY2hhbmdlIGlzIHRvIGFsbG9jYXRlIDggVHlw ZSBFeHRlbnNpb25zIGFzIGFzc2lnbmVkIGJ5IGFkbWluaXN0cmF0aXZlIA0KPj4gYWN0aW9uLCBp biBvcmRlciB0byBzdXBwb3J0IGFkbWluaXN0cmF0aXZlbHkgZGV0ZXJtaW5lZCBtdWx0aS0gDQo+ PiB0b3BvbG9naWVzLg0KPg0KPiBQcmV0dHkgbXVjaCBleGFjdGx5IHRoZSBzYW1lIGNvbnNpZGVy YXRpb25zLg0KPg0KPiAtIC0gLQ0KPg0KPiBJZiB5b3UgY2FuIGFuc3dlciBhbGwgdGhpcyBxdWlj a2x5LCBJIGNhbiBnbyBhaGVhZCB3aXRoIHRoZSByZXN0IG9mIG15IA0KPiByZXZpZXcuIEkgc3Vz cGVjdCB0aGF0IHRoZSBhbnN3ZXJzIHdpbGwgbmVlZCBhIHJldmlzZWQgSS1ELCBidXQgd2UgY2Fu IA0KPiBiYXRjaCB0aGF0IHdpdGggdGhlIHJlc3Qgb2YgbXkgcmV2aWV3IG9uY2UgSSBrbm93IHdo YXQgdGhlIGFuc3dlcnMgYXJlLg0KPg0KPiBUaGFua3MsDQo+IEFkcmlhbg0KPg0KDQpJTUhPLCB0 aGUgV0cgc2hvdWxkIGRpc2N1c3MgdGhlIHJlc3BvbmQgZnJvbSB0aGUgQUQuDQoNCkJlc3QgUmVn YXJkcw0KDQpBQg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2Ug ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hv dWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9y CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Cg== From nobody Fri Nov 21 02: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 791571AD364 for ; Fri, 21 Nov 2014 02:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy1zKbw2GBii for ; Fri, 21 Nov 2014 02:00:00 -0800 (PST) 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 D88371AD36B for ; Fri, 21 Nov 2014 01:59:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,429,1413241200"; d="scan'208";a="421470376" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 21 Nov 2014 09:59:10 +0000 X-IronPort-AV: E=Sophos;i="5.07,429,1413241200"; d="scan'208";a="81423266" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 21 Nov 2014 09:59:10 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 09:59:10 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Thomas Heide Clausen Thread-Topic: [manet] draft-ietf-manet-olsrv2-multitopology and draft-dearlove-manet-tlv-naming-00.txt Thread-Index: AQHP/WAdjaHKgR8U9k25B55K4X+9npxqaNsAgAB9fXA= Date: Fri, 21 Nov 2014 09:59:09 +0000 Message-ID: References: <20141111005114.27018.49670.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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1lBedoZtidqN6xvu99jEbF3TmiM Cc: manet Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology and draft-dearlove-manet-tlv-naming-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, 21 Nov 2014 10:00:03 -0000 SSB3b3VsZCBmaW5kIGl0IGhhcmQgdG8gZGVzY3JpYmUgdGhpcyBhcyBmYXN0LiBGYXN0IHdvdWxk IGJlIGdvb2QsIGJ1dCBpbnN0ZWFkIHdlIGhhdmUgcHJvY2Vzc2VzIHRvIGZvbGxvdy4gQXMgaXQg aXMsIGZyb20gdGhpcyBwb2ludCAobmV2ZXIgbWluZCB0aGUgdGltZSBsb3N0IHNvIGZhciwgaW4g cGFydCBiZWNhdXNlIHRoZSBhdXRob3JzIGhhZCB0byBtYWtlIHRpbWUgdG8gd3JpdGUgdGhlIGRy YWZ0KSB0aGVyZSB3aWxsIGJlIChhdCBiZXN0LCBhbmQgdGhlcmVmb3JlIEkgaG9wZSkgYSBmZXcg d2Vla3MgZGVsYXkgYmVmb3JlIHdlIGNhbiBtYWtlIHByb2dyZXNzIG9uIE1ULU9MU1J2MiAodW5s ZXNzIG91ciBBRCByZWdhcmRzIFdHIGFjY2VwdGFuY2UgYXMgZW5vdWdoIHRvIG1vdmUgdGhhdCBv biwgcmF0aGVyIHRoYW4gV0dMQywgYW5vdGhlciBzdGFnZSB0byBnbyB0aHJvdWdoIGFmdGVyIHRo aXMpLg0KDQpUaGUgb2JzZXJ2YXRpb24gYnkgdGhlIEFEIGhhcyBiZWVuIG9uIGZpbGUgZm9yIGEg d2hpbGUsIGFuZCBkaXNjdXNzaW9uIG9uIHRoZSBuZWVkIGZvciBhIGRyYWZ0IGhhcyBiZWVuIGhl bGQuIEluIGl0cyBjdXJyZW50IHN0YXRlIGFzIGFuIGF1dGhvciBkcmFmdCwgdGhpcyBkaXNjdXNz aW9uIGFib3V0IFdHIGFjY2VwdGFuY2UgaXMgZXhhY3RseSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUg Zm9ybSBvZiB0aGUgZHJhZnQuDQoNCkFuZCBJJ20gc29ycnksIHlvdSBtYXkgbm90IGhhdmUgYWdy ZWVkIHRvIG1vdmUgdGhlIE1UIGRyYWZ0IGZhc3QuIEJ1dCB0aGUgV0cgYWNjZXB0ZWQgYSBXR0xD LCBhdCBhIHJhdGUgSSdkIGNhbGwgbW9kZXJhdGUsIG5vdCBmYXN0Lg0KDQotLSANCkNocmlzdG9w aGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1 cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMg Q2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3Qg SGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsN ClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBT eXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBI b3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3Vn aCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86 IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWFuZXQgW21h aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWJkdXNzYWxhbSBCYXJ5 dW4NClNlbnQ6IDIxIE5vdmVtYmVyIDIwMTQgMDI6MjENClRvOiBUaG9tYXMgSGVpZGUgQ2xhdXNl bg0KQ2M6IG1hbmV0DQpTdWJqZWN0OiBSZTogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2 Mi1tdWx0aXRvcG9sb2d5IGFuZCBkcmFmdC1kZWFybG92ZS1tYW5ldC10bHYtbmFtaW5nLTAwLnR4 dA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4N CkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNw aWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVw b3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIaSBBbGwsDQoNCkkgZG9uJ3Qg a25vdyB3aHkgd2UgaGF2ZSB0byBtb3ZlIHRoaW5ncyBmYXN0LiBNb3ZpbmcgdGhpbmdzIGZhc3Qg YWRkcyBwb3NzaWJsZSBlcnJvcnMsIGFuZCBtYXkgY29uZnVzZSB0aGUgY29tbXVuaXR5LiBXZSBu ZWVkIHRvIGNvbnNpZGVyIHRoYXQgcGFydGljaXBhbnRzIG5lZWQgdG8gZ2l2ZSBhIGRlY2lzaW9u IG9uIHdoZW4gdG8gbW92ZSB0aGluZ3MgZmFzdCBhbmQgd2hlbiBub3QgdG8gbW92ZSB0aGluZ3Mg ZmFzdC4gSSBkb24ndCBhZ3JlZSB0byBtb3ZlIHRoaXMgZHJhZnQgZmFzdCBub3IgYWdyZWVkIHRv IG1vdmUgdGhlIG11bHRpdG9wb2xvZ3kgZHJhZnQgZmFzdC4gV2UgY291bGQgaGF2ZSBkb25lIGZh c3QgcHJvY2VzcyBpZiB0aGUgZHJhZnQgd2FzIGRpc2N1c3NlZCBiZWZvcmUgcHVibGlzaGVkLCBz byB0aGF0IHRoZSBXRyBjYW4gZGVjaWRlIGlmIGZhc3QgaXMgcmVxdWlyZWQuIEp1c3QgbXkgb3Bp bmlvbiBob3cgdGhpbmdzIGdvIGZhc3QgaW4gb3JnYW5pc2F0aW9uIHRoYXQgaW52b2x2ZSBhbGwu DQoNCk9uIDExLzEwLzE0LCBUaG9tYXMgSGVpZGUgQ2xhdXNlbiA8dGhvbWFzQHRob21hc2NsYXVz ZW4ub3JnPiB3cm90ZToNCj4gU2luY2UsIG9mIGNvdXJzZSwgYWxsIHnigJlhbGwgYXJlIGNvbXB1 bHNpdmVseSByZWFkaW5nIHRoZSBJRC1hbm5vdW5jZSANCj4gbWFpbGluZyBsaXN0IDspIHlvdeKA mWxsIGhhdmUgc2VlbiANCj4gZHJhZnQtZGVhcmxvdmUtbWFuZXQtdGx2LW5hbWluZy0wMC50eHQg ZG9jdW1lbnQgYXBwZWFyIGp1c3QgdG9kYXkuDQo+DQo+IFRoaXMgaXMgaW4gcmVzcG9uc2UgdG8g dGhlIHJldmlldyBmcm9tIG91ciBBRCBvbiANCj4gZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVs dGl0b3BvbG9neQ0KPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0 L2N1cnJlbnQvbXNnMTY4NzUuaHRtbA0KPiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTY4NzUuaHRtbD4pLCANCj4gaW4gd2hpY2ggaGUgaW5k aWNhdGVzIHRoYXQgd2UgcHJvYmFibHkgc2hvdWxkIHJlLXRoaW5rIHRoZSB3YXkgd2UgbmFtZSAN Cj4gVExWIHR5cGVzLg0KPg0KPiBBcyBvdXIgQUQgcmVxdWVzdGVkLCB0aGUgYXV0aG9ycyBkaWQg cmUtdGhpbmssIGRpc2N1c3MgYSBiaXQgYWxzbyB3aXRoIA0KPiBvdXIgQUQgYW5kIGNoYWlycywg YW5kIGNhbWUgdG8gYSBjb25jbHVzaW9uIC4uLiBhbmQgdGhhdCBjb25jbHVzaW9uIGlzIA0KPiBp biB0aGlzIEktRC4NCg0KSSByZXF1ZXN0IHRoYXQgb3VyIGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8g YWRvcHRlZCB3b3JrIGFuZCBmdXR1cmUgZGlzY3Vzc2lvbnMgdG8gYmUgZG9uZSBvbiB0aGUgbGlz dCBvciB3aXRoaW4gbWludXRlcy4gSSB0aGluayB0aGUgV0cgc2hvdWxkIGJlIGFibGUgdG8gYmUg aW5jbHVkZWQgaW4gZGlzY3Vzc2lvbiBiZXR3ZWVuIEFEIGFuZCBhdXRob3JzLCB3aHkgV0cgd2Fz IGV4Y2x1ZGVkPw0KDQoNCkJlc3QgUmVnYXJkcywNCg0KQUINCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBp dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0 cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Fri Nov 21 12: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 17ABD1A6F3F for ; Fri, 21 Nov 2014 12:02:44 -0800 (PST) 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 dZT32Fbe408V for ; Fri, 21 Nov 2014 12:02:41 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010: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 1EF181A6FCF for ; Fri, 21 Nov 2014 12:00:42 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id q1so4791328lam.39 for ; Fri, 21 Nov 2014 12:00:40 -0800 (PST) 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=06f43cP+m/oj+I+qNAU4Q2quCSX/YUExP/EB3UxRA1w=; b=lY3qjS489ce7HcBKmz6qLEiYPDJc3/JktYlpxF8apo5BHDv2xS+PDg/u8y1VbyjdE+ 4tPdoIP1a/TMn2gGzmuPajs9py47wdJ/hFzAAhjb4tRsZt0nOMHeqHrnPb1p5SbYN23H HW4ZP0pgSBWkQPx0aX6bXPfuVj+2M5OvBa3z/mx9neIgV8m8VC7RSGAHuPt3yUJ0sB8q MphrWfxsjkxrsthO++8MbK39bHfDvutkQeuWu+yM7QlbLi3psfxzoNmTuv/wPr59VXdb mOnU6pK65GbNfEHiwoFFtWqviOJWA1WP0McteiGnKGKrDY7hHlqbvLFQ46Dpk2C3MA1Z jIdg== MIME-Version: 1.0 X-Received: by 10.112.63.133 with SMTP id g5mr7319772lbs.33.1416600040248; Fri, 21 Nov 2014 12:00:40 -0800 (PST) Received: by 10.25.85.201 with HTTP; Fri, 21 Nov 2014 12:00:40 -0800 (PST) In-Reply-To: References: <20141111005114.27018.49670.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 15:00:40 -0500 Message-ID: From: Stan Ratliff To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001a11c3d830301ef4050863e602 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/keU7NlSoLTBdHhUljPUAsuwqmXs Cc: manet , Thomas Heide Clausen Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology and draft-dearlove-manet-tlv-naming-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, 21 Nov 2014 20:02:44 -0000 --001a11c3d830301ef4050863e602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AB, I don't believe the WG has been excluded, primarily because there is an I-D posted for the WG's consideration and approval. Regards, Stan On Thu, Nov 20, 2014 at 9:21 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi All, > > I don't know why we have to move things fast. Moving things fast adds > possible errors, and may confuse the community. We need to consider > that participants need to give a decision on when to move things fast > and when not to move things fast. I don't agree to move this draft > fast nor agreed to move the multitopology draft fast. We could have > done fast process if the draft was discussed before published, so that > the WG can decide if fast is required. Just my opinion how things go > fast in organisation that involve all. > > On 11/10/14, Thomas Heide Clausen wrote: > > Since, of course, all y=E2=80=99all are compulsively reading the ID-ann= ounce > mailing > > list ;) you=E2=80=99ll have seen draft-dearlove-manet-tlv-naming-00.txt= document > > appear just today. > > > > This is in response to the review from our AD on > > draft-ietf-manet-olsrv2-multitopology > > (http://www.ietf.org/mail-archive/web/manet/current/msg16875.html > > ), in > > which he indicates that we probably should re-think the way we name TLV > > types. > > > > As our AD requested, the authors did re-think, discuss a bit also with > our > > AD and chairs, and came to a conclusion ... and that conclusion is in > this > > I-D. > > I request that our discussions related to adopted work and future > discussions to be done on the list or within minutes. I think the WG > should be able to be included in discussion between AD and authors, > why WG was excluded? > > > Best Regards, > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c3d830301ef4050863e602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AB,=C2=A0

I don't believe the WG ha= s been excluded, primarily because there is an I-D posted for the WG's = consideration and approval.=C2=A0

Regards,
Stan

On Thu, Nov 20, 2014 at 9:21 PM, Abdussalam Baryun <= abdussalamb= aryun@gmail.com> wrote:
Hi = All,

I don't know why we have to move things fast. Moving things fast adds possible errors, and may confuse the community. We need to consider
that participants need to give a decision on when to move things fast
and when not to move things fast. I don't agree to move this draft
fast nor agreed to move the multitopology draft fast. We could have
done fast process if the draft was discussed before published, so that
the WG can decide if fast is required. Just my opinion how things go
fast in organisation that involve all.

On 11/10/14, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
> Since, of course, all y=E2=80=99all are compulsively reading the ID-an= nounce mailing
> list ;) you=E2=80=99ll have seen draft-dearlove-manet-tlv-naming-00.tx= t document
> appear just today.
>
> This is in response to the review from our AD on
> draft-ietf-manet-olsrv2-multitopology
> (http://www.ietf.org/mail-archive/web/manet/curren= t/msg16875.html
> <http://www.ietf.org/mail-archive/web/manet/cur= rent/msg16875.html>), in
> which he indicates that we probably should re-think the way we name TL= V
> types.
>
> As our AD requested, the authors did re-think, discuss a bit also with= our
> AD and chairs, and came to a conclusion ... and that conclusion is in = this
> I-D.

I request that our discussions related to adopted work and future
discussions to be done on the list or within minutes. I think the WG
should be able to be included in discussion between AD and authors,
why WG was excluded?


Best Regards,

AB

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

--001a11c3d830301ef4050863e602-- From nobody Sat Nov 22 06:43: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 4BCB61AC3C3; Sat, 22 Nov 2014 06:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC7PZ_ZMBrVt; Sat, 22 Nov 2014 06:43:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70461AC3EE; Sat, 22 Nov 2014 06:43:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141122144340.20902.88145.idtracker@ietfa.amsl.com> Date: Sat, 22 Nov 2014 06:43:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Q7xhFrFihCeTRND28WXzFQFIMdo Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: [manet] Adrian Farrel's Yes on draft-ietf-manet-ibs-03: (with COMMENT) 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: Sat, 22 Nov 2014 14:43:42 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-manet-ibs-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have cleared my Discuss. I am satisfied that the author has engaged properly in discussion with the SecDir reviewer and that the document itself is sound. The only addition I can see arising from this debate is some text to further explain the trust model in using IBS: it may not be suitable for everyone, but it's offered as an option for those for whom it is suitable. From nobody Mon Nov 24 01:28: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 5D0081A1EE8; Mon, 24 Nov 2014 01:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nANX1-SUrkDm; Mon, 24 Nov 2014 01:28:05 -0800 (PST) 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 8A0661A1EB7; Mon, 24 Nov 2014 01:28:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,447,1413241200"; d="scan'208";a="421954512" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Nov 2014 09:26:03 +0000 X-IronPort-AV: E=Sophos;i="5.07,447,1413241200"; d="scan'208";a="81623051" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 24 Nov 2014 09:26:03 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 09:26:03 +0000 From: "Dearlove, Christopher (UK)" To: Adrian Farrel , The IESG Thread-Topic: [manet] Adrian Farrel's Yes on draft-ietf-manet-ibs-03: (with COMMENT) Thread-Index: AQHQBmK8RE4kOUZxrEeIkdEfmFJMH5xvg66g Date: Mon, 24 Nov 2014 09:26:02 +0000 Message-ID: References: <20141122144340.20902.88145.idtracker@ietfa.amsl.com> In-Reply-To: <20141122144340.20902.88145.idtracker@ietfa.amsl.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/qsR6T0aKj7UD9BOYApG8r8oFNkU Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Adrian Farrel's Yes on draft-ietf-manet-ibs-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 09:28:07 -0000 There is already some text to this effect, from the Introduction The disadvantage referred to is that the trusted authority has complete authority, even more so than a conventional certificate authority. Routers cannot generate their own private keys, only the trusted authority can do that. Through the master secret held by the trusted authority, it could impersonate any router (existing or not). When used for identity-based encryption (not part of this specification) the trusted authority can decrypt anything. However, note that the shared secret key options described in [RFC7182] also have this limitation. And from the Security Considerations In common with other forms of IBS, a feature of the form of IBS (known as ECCSI) used in this specification is that it requires a trusted authority (KMS) that issues all private keys, and has complete cryptographic information about all possible private keys. However to set against that, the solution is scalable, as all routers can be independently keyed, and does not need the KMS in the network. If no future keys will be required, then the KMS's master secret can be destroyed. As routers are individually keyed, key revocation (by blacklist and time expiry of keys) is possible, but is beyond the scope of this specification. However it doesn't explicitly call out that this is an option for those who= are prepared to accept this limitation. (I guess I was assuming that was i= mplied by the above and that RFC 7182 is, of its nature, a set of options.) I will see what else is produced as comments before creating an updated dra= ft. -- = 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 Adrian Farrel Sent: 22 November 2014 14:44 To: The IESG Cc: manet-chairs@tools.ietf.org; draft-ietf-manet-ibs.all@tools.ietf.org; m= anet@ietf.org; T.Clausen@computer.org Subject: [manet] Adrian Farrel's Yes on draft-ietf-manet-ibs-03: (with COMM= ENT) ----------------------! 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. -------------------------------------------------------- Adrian Farrel has entered the following ballot position for draft-ietf-manet-ibs-03: Yes When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have cleared my Discuss. I am satisfied that the author has engaged prope= rly in discussion with the SecDir reviewer and that the document itself is = sound. The only addition I can see arising from this debate is some text to furthe= r explain the trust model in using IBS: it may not be suitable for everyone= , but it's offered as an option for those for whom it is suitable. _______________________________________________ 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 Nov 24 03: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 DF1371A3BA9; Mon, 24 Nov 2014 03:47:42 -0800 (PST) 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 DgSi8BZ0m6hS; Mon, 24 Nov 2014 03:47:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE91A212A; Mon, 24 Nov 2014 03:47:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 03:47:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/is2Tsvh-uSVRbZp-CSvNlZNGQPo Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) 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, 24 Nov 2014 11:47:43 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-manet-ibs-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I am concerned that RFC6507 may not be ready for use in standards-track RFCs. So far it has not been and I have found no peer reviewed security or cryptographic analysis that indicates that it is has been studied to see if it is good enough for that. I've also not seen any MANET list discussion of that aspect (and indeed the MANET list discussion I did see seems to involve very few people). I asked on the CFRG list about RFC6507 and it seems [1] to be the case that no-one has so far really evaluated its security, other than folks associated with the author's institution. (Which applies to both 6507 and this I think.) I also didn't find any references to 6507 in Google scholar. Lastly, I think we should be, and be seen to be, more careful than usual with this draft - given the situation with DUAL-EC-DRBG, and that this is a new signature scheme that allows the KMS to fake anyone's signature and the author involved. Note that that last is not any imputation of misbehaviour, but the IETF would not be doing due-dilligence if we didn't explicitly consider that aspect. [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html (2) How does a router get its private key? Why is it ok to not specify that? Seems like an interop fail if that is not done. (3) I think this is the first asymmetric scheme the WG have adopted. If that's wrong then this discuss point is fairly moot:-) When did the WG discuss whether to adopt IBS as its first asymmetric appraoch and not traditional signature schemes that don't have spoofing by the KG/KMS as an inherent property? That might be a reasonable decision, but I don't see where that decision was made, nor why. (That could be just that I've not looked far enough back in the WG list archives, in which case this is easy.) (4) 4.1: The usual revocation trick of including a time value in the name is referred to at the end of this section but without sufficient detail to allow interop. Why is that ok? (5) RFC6507 isn't compatible with e.g. Curve25519 or perhaps other "rigid" curves. Given that CFRG are in the process of picking new curves, with better properties, wouldn't it be better for the WG to wait and have the choice of using those as well or instead? From nobody Mon Nov 24 04:07: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 946FC1A6EEF; Mon, 24 Nov 2014 04:07:10 -0800 (PST) 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 fwM65Jm2tufB; Mon, 24 Nov 2014 04:07:06 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A295B1A6EE0; Mon, 24 Nov 2014 04:06:56 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAOC6rfY006423; Mon, 24 Nov 2014 12:06:53 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAOC6qwv006407 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 12:06:52 GMT From: "Adrian Farrel" To: "'Stephen Farrell'" , "'The IESG'" References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> In-Reply-To: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 12:06:51 -0000 Message-ID: <06a201d007df$21fdb180$65f91480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF//pMjcVEDaJB7j0gNSGYnM7f+V50PvfSw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21124.006 X-TM-AS-Result: No--18.163-10.0-31-10 X-imss-scan-details: No--18.163-10.0-31-10 X-TMASE-MatchedRID: cxtZ8fwm3r+nykMun0J1wgRH1Nr7oERdPz+fM/byAtlXPwnnY5XL5Jxa k1lKPxhN0RqRBtIOxJy3nyFHqIEZjdmE3fy7hciUCFaAixm5eU8sCc2iFTIxrWQz1xeIBOQYwua niM9QXy1EWyqmHrvq4BcRpPm6GTDMFqZ3OX31m31CnGIuUMP0VWlOPrrbBmagDO+DX+rUwfYsdh 2ZEFy7YUNoVDYC2mKV9jjbGUN5dRScYwc8xKphVe9VsdrlGzy3QZXZg2I8JaaJ1jCZ8wjy4EsIx i34LbJSXJXmxxIn9CIvFXo536J1gsQBTGBDM3kdY1bQMCMvmn4fXzVgO0hVqkiO8DX9hL7Rcy4s qUzwBjtXLWhg63ZdjwszukfLgYhRBb95QfAlOsh7sw7yO+Y9LO5kCf9MfJautSff1vK0HDw1xdx ekc1EISK3M8RH4oqwbPIh3dmDfQob+BGg6rnrds87s4OnYGuCSNmpTpsmB/cR34ro7k23nb4SvJ zMZUQWBwW+OXVaL6MhvK8NgsBP4api1mhIp0HhHjsQaSkZ4D2n/jR8PqMWfsj0QMA/92m2RE9xQ BYdJhOKd1b+vIG9JF+24nCsUSFNt7DW3B48kkHdB/CxWTRRuyUIayx+Skid Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OnJoYjd7hei6kJ54PMFpcTrl6AI Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) 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: Mon, 24 Nov 2014 12:07:11 -0000 Thanks Stephen, Some good and bad questions here, I think. Wrt 1, is IBS sufficiently bad and unknown that using it is worse than = having no security? Wrt 2, I suspect that the key distribution being contemplated is = physical, but we can certainly talk about it. Wrt 5, do you think that waiting for the output of a research group is = right? Firstly, this doesn't bring us anything closer to something we = can include in a standards track RFC, and secondly it doesn't give us = any security we can implement today. A > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: 24 November 2014 11:48 > To: The IESG > Cc: manet-chairs@tools.ietf.org; = draft-ietf-manet-ibs.all@tools.ietf.org; > manet@ietf.org; T.Clausen@computer.org > Subject: Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with = DISCUSS) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-manet-ibs-03: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > (1) I am concerned that RFC6507 may not be ready for use in > standards-track RFCs. So far it has not been and I have found > no peer reviewed security or cryptographic analysis that > indicates that it is has been studied to see if it is good > enough for that. I've also not seen any MANET list discussion > of that aspect (and indeed the MANET list discussion I did > see seems to involve very few people). I asked on the CFRG > list about RFC6507 and it seems [1] to be the case that > no-one has so far really evaluated its security, other than > folks associated with the author's institution. (Which > applies to both 6507 and this I think.) I also didn't find > any references to 6507 in Google scholar. Lastly, I think we > should be, and be seen to be, more careful than usual with > this draft - given the situation with DUAL-EC-DRBG, and that > this is a new signature scheme that allows the KMS to fake > anyone's signature and the author involved. Note that that > last is not any imputation of misbehaviour, but the IETF > would not be doing due-dilligence if we didn't explicitly > consider that aspect. >=20 > [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html >=20 > (2) How does a router get its private key? Why is it ok to > not specify that? Seems like an interop fail if that is not > done. >=20 > (3) I think this is the first asymmetric scheme the WG have > adopted. If that's wrong then this discuss point is fairly > moot:-) When did the WG discuss whether to adopt IBS as its > first asymmetric appraoch and not traditional signature > schemes that don't have spoofing by the KG/KMS as an inherent > property? That might be a reasonable decision, but I don't > see where that decision was made, nor why. (That could be > just that I've not looked far enough back in the WG list > archives, in which case this is easy.) >=20 > (4) 4.1: The usual revocation trick of including a time value > in the name is referred to at the end of this section but > without sufficient detail to allow interop. Why is that ok? >=20 > (5) RFC6507 isn't compatible with e.g. Curve25519 or perhaps > other "rigid" curves. Given that CFRG are in the process of > picking new curves, with better properties, wouldn't it be > better for the WG to wait and have the choice of using those > as well or instead? >=20 >=20 From nobody Mon Nov 24 04:20: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 E7E471A1B36; Mon, 24 Nov 2014 04:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRpuU5mtXXET; Mon, 24 Nov 2014 04:20:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 16FE41A0195; Mon, 24 Nov 2014 04:20:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B05DBE7D; Mon, 24 Nov 2014 12:20:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u84r1bQ_Qk38; Mon, 24 Nov 2014 12:20:29 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.20.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B82CBE7C; Mon, 24 Nov 2014 12:20:29 +0000 (GMT) Message-ID: <5473228C.6030907@cs.tcd.ie> Date: Mon, 24 Nov 2014 12:20:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'The IESG' References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> In-Reply-To: <06a201d007df$21fdb180$65f91480$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/E_5CmsUoI6wEkmSUEAXCvRLwUHo Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 12:20:37 -0000 On 24/11/14 12:06, Adrian Farrel wrote: > Thanks Stephen, > > Some good and bad questions here, I think. > > Wrt 1, is IBS sufficiently bad and unknown that using it is worse > than having no security? Given that there are far better known asymmetric schemes my question#1 is valid I think. This draft seems to be picking the cryptographically unknown over the known and is the first standards-track document to do so. > Wrt 2, I suspect that the key distribution being contemplated is > physical, but we can certainly talk about it. Right. I don't know how to get interop between router and KMS without at least e.g. defining a format or some kind of interface. > Wrt 5, do you think that waiting for the output of a research group > is right? Firstly, this doesn't bring us anything closer to something > we can include in a standards track RFC, and secondly it doesn't give > us any security we can implement today. Not waiting is quite arguable yes. However, the TLS wg are waiting for this, albeit without that currently blocking progress, so it'll be relatively quick (as in weeks, is the plan). I wasn't clear if the MANET WG were aware of that, since CFRG have only been working on that since earlier this year. The new curves are being picked because they have both CPU and side-channel resistance advantages that could be relevant here and I saw no sign that the work had been factored into this at all. (It may well have of course, as I said, I only went back a little into the MANET list archive.) S. > > A > >> -----Original Message----- From: iesg >> [mailto:iesg-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >> 24 November 2014 11:48 To: The IESG Cc: >> manet-chairs@tools.ietf.org; >> draft-ietf-manet-ibs.all@tools.ietf.org; manet@ietf.org; >> T.Clausen@computer.org Subject: Stephen Farrell's Discuss on >> draft-ietf-manet-ibs-03: (with DISCUSS) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-manet-ibs-03: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> (1) I am concerned that RFC6507 may not be ready for use in >> standards-track RFCs. So far it has not been and I have found no >> peer reviewed security or cryptographic analysis that indicates >> that it is has been studied to see if it is good enough for that. >> I've also not seen any MANET list discussion of that aspect (and >> indeed the MANET list discussion I did see seems to involve very >> few people). I asked on the CFRG list about RFC6507 and it seems >> [1] to be the case that no-one has so far really evaluated its >> security, other than folks associated with the author's >> institution. (Which applies to both 6507 and this I think.) I also >> didn't find any references to 6507 in Google scholar. Lastly, I >> think we should be, and be seen to be, more careful than usual >> with this draft - given the situation with DUAL-EC-DRBG, and that >> this is a new signature scheme that allows the KMS to fake anyone's >> signature and the author involved. Note that that last is not any >> imputation of misbehaviour, but the IETF would not be doing >> due-dilligence if we didn't explicitly consider that aspect. >> >> [1] >> https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html >> >> (2) How does a router get its private key? Why is it ok to not >> specify that? Seems like an interop fail if that is not done. >> >> (3) I think this is the first asymmetric scheme the WG have >> adopted. If that's wrong then this discuss point is fairly moot:-) >> When did the WG discuss whether to adopt IBS as its first >> asymmetric appraoch and not traditional signature schemes that >> don't have spoofing by the KG/KMS as an inherent property? That >> might be a reasonable decision, but I don't see where that decision >> was made, nor why. (That could be just that I've not looked far >> enough back in the WG list archives, in which case this is easy.) >> >> (4) 4.1: The usual revocation trick of including a time value in >> the name is referred to at the end of this section but without >> sufficient detail to allow interop. Why is that ok? >> >> (5) RFC6507 isn't compatible with e.g. Curve25519 or perhaps other >> "rigid" curves. Given that CFRG are in the process of picking new >> curves, with better properties, wouldn't it be better for the WG to >> wait and have the choice of using those as well or instead? >> >> > > From nobody Mon Nov 24 04: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 B2DF01A6EF8; Mon, 24 Nov 2014 04:56:54 -0800 (PST) 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 UxOCKEOvHC0D; Mon, 24 Nov 2014 04:56:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C40A91A6F05; Mon, 24 Nov 2014 04:56:51 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 04:56:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YL8Gips0ssRF6ouzCG_aBmAdMSI Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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: Mon, 24 Nov 2014 12:56:54 -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-03.txt Pages : 16 Date : 2014-11-24 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-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 Mon Nov 24 05:05: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 901B61A6F28 for ; Mon, 24 Nov 2014 05:05:15 -0800 (PST) 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 VRMsq6k9eZ5M for ; Mon, 24 Nov 2014 05:05:14 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c: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 C0AF61A6F27 for ; Mon, 24 Nov 2014 05:05:13 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so1668793wgh.27 for ; Mon, 24 Nov 2014 05:05:12 -0800 (PST) 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 :content-type; bh=hQ7Vv0rKvH0VGDqlZpfmFkY+Qvtp8bZo+YRe7eFBOtg=; b=l1QhUYeduacEqGXkyXuqMcPzQu60/XxwMeGzpWpR91/l6I6NvBv8AU5ncAnKLlylQX kHo1t1ysplIw2VnM19NVwbzBApmNk04Aw1B5RAR+SSHSU7E6q7xNITg7jTNMSSELWDlV +Bh98SOwdLSEVi6Qn073iCBxAGbH7UIcPArxi2hD801lB7oQYxGmAdFwpKA2E2HWhoVc yERML5eP/QXJBBY8S5thUkBPT/oQstCGMB9KDzFWl1iAUmOHrB/BUKyMrzpPTWp6H833 YX06idKHjAwhamknAmxYMVu/EYnel+sbhefFbBo/ef+YgDqrkpRFpA6oEGDlwQ/42eTN X11g== X-Received: by 10.195.17.231 with SMTP id gh7mr33744033wjd.21.1416834312567; Mon, 24 Nov 2014 05:05:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.8.75 with HTTP; Mon, 24 Nov 2014 05:04:52 -0800 (PST) In-Reply-To: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> References: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Mon, 24 Nov 2014 14:04:52 +0100 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MtqEWotSwPDfgBIywZ6h3Uc-lZs Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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: Mon, 24 Nov 2014 13:05:15 -0000 Hi, I hope this new revision of the DAT metric resolves the trouble with interoperability between nodes that can send/process RFC5444 packet sequence numbers and nodes that can not. The draft became a little bit shorter in the process because there is no "mode A" and "mode B" (plus optional "mode C") anymore, MANET routers should gracefully fall back to Hello timeout loss measurements when the neighbor cannot deliver packet sequence numbers or the local router cannot process them. Henning Rogge On Mon, Nov 24, 2014 at 1:56 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 : Packet Sequence Number based directional airtime metric for OLSRv2 > Authors : Henning Rogge > Emmanuel Baccelli > Filename : draft-ietf-manet-olsrv2-dat-metric-03.txt > Pages : 16 > Date : 2014-11-24 > > 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-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-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/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Nov 24 05:39: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 222C91A6F61; Mon, 24 Nov 2014 05:39:33 -0800 (PST) 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 ZMK4tCK6Tctn; Mon, 24 Nov 2014 05:39:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDCA1A6F5B; Mon, 24 Nov 2014 05:39:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124133932.30535.29016.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 05:39:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hXdQKG_mehJQNTnyvTkPNtZwB3s Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: [manet] Brian Haberman's No Objection on draft-ietf-manet-ibs-03: (with COMMENT) 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, 24 Nov 2014 13:39:33 -0000 Brian Haberman has entered the following ballot position for draft-ietf-manet-ibs-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am quite interested in how the discussion goes with Stephen's concerns. From nobody Mon Nov 24 05:58: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 7E34F1A6F7F; Mon, 24 Nov 2014 05:58:11 -0800 (PST) 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 CGKf5US6n3ET; Mon, 24 Nov 2014 05:58:06 -0800 (PST) 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 A1BE91A02BE; Mon, 24 Nov 2014 05:58:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="499696303" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Nov 2014 13:58:03 +0000 X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="73300745" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 24 Nov 2014 13:58:03 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 13:58:03 +0000 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , 'Stephen Farrell' , 'The IESG' Thread-Topic: Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) Thread-Index: AQHQB98v/hptP4rV3kiJzDsZOYRRXpxvx5Zg Date: Mon, 24 Nov 2014 13:58:03 +0000 Message-ID: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> In-Reply-To: <06a201d007df$21fdb180$65f91480$@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: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/d_w6-PQIj93stlfnMQxz1I7vqPc Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 13:58:12 -0000 VGhhbmtzIEFkcmlhbiBhbmQgU3RlcGhlbi4NCg0KV2l0aCByZWdhcmQgdG8gcG9pbnQgMSwgSSBh bSBhdHRlbXB0aW5nIHRvIG9idGFpbiBzb21lIGFkZGl0aW9uYWwgbWF0ZXJpYWwuIEluIHRoZSBt ZWFudGltZSwgeW91IG1heSB3YW50IHRvIG5vdGUgaHR0cDovL3d3dy5jZXNnLmdvdi51ay9wb2xp Y3lndWlkYW5jZS9Eb2N1bWVudHMvd2hpdGVfcGFwZXItdXNpbmdfTUlLRVktU0FLS0UucGRmIHRo b3VnaCBJIGFtIG5vdCBjbGFpbWluZyBpdCBhZGRyZXNzZXMgeW91ciBjb21wbGV0ZSBwb2ludC4g SXQgaXMgYWxzbyBwb3NzaWJsZSB0byBpZGVudGlmeSB0aGF0IENFU0cgYXJlIHdvcmtpbmcgd2l0 aCB2YXJpb3VzIG90aGVyIHBhcnRpZXMgb24gTUlLRVktU0FLS0UgKHdlIGFyZSBqdXN0IHVzaW5n IEVDQ1NJIGZyb20gdGhhdCBvZiBjb3Vyc2UpLCBteSBHb29nbGluZyBpZGVudGlmaWVzIENlbGxj cnlwdCAod2hvIEkgYW0gbm90IGZhbWlsaWFyIHdpdGgpIGFzIG9uZSBzdWNoLiBUaGF0IG5vdGUg ZG9lcyBob3dldmVyIGluZGljYXRlZCB0aGF0IEVDQ1NJIGlzLCBmdW5kYW1lbnRhbGx5LCBhIG1v ZGlmaWNhdGlvbiBvZiBFQ0RTQS4gSG93ZXZlciBJIGFtIG5vdCBhIGNyeXB0b2dyYXBoZXIgdG8g bWFrZSBhIGRldGFpbGVkIGNvbW1lbnQgdGhlcmUuIFdpdGggcmVnYXJkIHRvIHRoZSB0cnVzdGVk IGF1dGhvcml0eSBpc3N1ZSwgYXMgaGFzIGJlZW4gc2FpZCwgdGhpcyBpcyBhbiBvcHRpb24uIEl0 J3MgYWN0dWFsbHkgYSBzYWZlciBvcHRpb24gdGhhbiB0aGUgc2hhcmVkIHNlY3JldCBrZXkgb3B0 aW9ucyB0aGF0IG1ha2UgdXAgbW9zdCBvZiBSRkMgNzE4MidzIGV4aXN0aW5nIG9wdGlvbnMuDQoN CldpdGggcmVnYXJkIHRvIDIsIHRoaXMgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyBhbnkgb3RoZXIg UkZDIDcxODIgYWxnb3JpdGhtLiBXZSB3ZW50IHRocm91Z2ggYSBsb25nIGRpc2N1c3Npb24gYXMg dG8gdGhpcyBmb3IgdGhhdCBwcm90b2NvbCwgYWxsIHRoZSBzYW1lIGFyZ3VtZW50cyBhcHBseSB1 bmNoYW5nZWQuDQoNCldpdGggcmVnYXJkIHRvIDMsIGFjdHVhbGx5IFJGQyA3MTgyIGxpc3RzIFJT QSBhcyBhbiBhbHJlYWR5IHN1cHBvcnRlZCBhbGdvcml0aG0uIFRoYXQgZGF0ZXMgYmFjayB0byBp dHMgcHJlZGVjZXNzb3IgUkZDIDY2MjIgKHdoaWNoIEkgd2Fzbid0IGFuIGF1dGhvciBvZiwgc28g ZG9uJ3QgcmVjYWxsIGFueSBkaXNjdXNzaW9uIHRoZXJlKS4NCg0KV2l0aCByZWdhcmQgdG8gNCwg cHJpbWFyaWx5IEkgd291bGQgcmVnYXJkIHNwZWNpZnlpbmcgdGhpcyBhcyBhIHBvc3NpYmxlIGZ1 dHVyZSBleHRlbnNpb24gKHdoaWNoIGNvdWxkIGJlIGRvbmUgbm93IGluIGFuIGFkbWluaXN0cmF0 aXZlbHkgY29uZmlndXJlZCBtYW5uZXIpIGJlY2F1c2UgZGlmZmVyZW50IHVzZXMgb2YgdGhpcyBt aWdodCBoYXZlIGRpZmZlcmVudCByZXF1aXJlbWVudHMgKGdyYW51bGFyaXR5LCBkdXJhdGlvbiku IEFuIG9wdGlvbiBjb3VsZCBiZSBzZWxlY3RlZCwgYnV0IHNpbmNlIHRoaXMgd291bGQgYmUgaW4g c3VwcG9ydCBvZiBhbiBhbHNvIGFkbWluaXN0cmF0aXZlbHkgY29uZmlndXJlZCBwb2xpY3ksIHRo aXMgc2VlbWVkIG5vdCB3b3J0aHdoaWxlLg0KDQpJIGRvIG5vdCBiZWxpZXZlIHRoYXQgcG9pbnQg NSBpcyBhcHByb3ByaWF0ZS4gVGhlIENGUkcgaXMgYWltZWQgYXQgYSBkaWZmZXJlbnQgaXNzdWUs IHN1cHBvcnQgb2YgVExTLCB3aXRoIGRpZmZlcmVudCByZXF1aXJlbWVudHMsIGFuZCBub3QgZm9y IGFuIGlkZW50aXR5IGJhc2VkIHNjaGVtZS4NCg0KV2l0aCByZWdhcmQgdG8gdGhlIHJlbGF0ZWQg Q0ZSRyBwb2ludCBpbiBjb21tZW50IDEsIEkgZm9sbG93ZWQgdGhhdCBkaXNjdXNzaW9uLCBpdCB3 YXMgdmVyeSBzaG9ydCwgaGFyZGx5IGFueW9uZSBjb250cmlidXRlZCwgYW5kIHRoZSBvbmx5IGNv bmNsdXNpb24gSSdkIGRyYXcgZnJvbSBpdCBpcyB0aGF0IGEgY291cGxlIG9mIHBlb3BsZSBleHBy ZXNzZWQgdGhleSBkaWRuJ3Qga25vdywgdGhhdCB3YXMgaXQuIChUaGVyZSB3ZXJlIGFsc28gSVBS IHBvaW50cyBtYWRlLCBidXQgc2VlIHRoZSBDRVNHIGRvY3VtZW50IGxpbmtlZCBhYm92ZS4pDQoN CkNocmlzdG9waGVyDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lw YWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMs IE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZh bmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTTCoHwgIEZh eDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSB8IGh0dHA6 Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQN ClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdo IEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5j by51a10gDQpTZW50OiAyNCBOb3ZlbWJlciAyMDE0IDEyOjA3DQpUbzogJ1N0ZXBoZW4gRmFycmVs bCc7ICdUaGUgSUVTRycNCkNjOiBtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWll dGYtbWFuZXQtaWJzLmFsbEB0b29scy5pZXRmLm9yZzsgbWFuZXRAaWV0Zi5vcmc7IFQuQ2xhdXNl bkBjb21wdXRlci5vcmcNClN1YmplY3Q6IFJFOiBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9u IGRyYWZ0LWlldGYtbWFuZXQtaWJzLTAzOiAod2l0aCBESVNDVVNTKQ0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ug b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g ZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxs eSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2ht ZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGlu ayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMg ZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFua3MgU3RlcGhlbiwNCg0KU29tZSBnb29kIGFuZCBiYWQg cXVlc3Rpb25zIGhlcmUsIEkgdGhpbmsuDQoNCldydCAxLCBpcyBJQlMgc3VmZmljaWVudGx5IGJh ZCBhbmQgdW5rbm93biB0aGF0IHVzaW5nIGl0IGlzIHdvcnNlIHRoYW4gaGF2aW5nIG5vIHNlY3Vy aXR5Pw0KDQpXcnQgMiwgSSBzdXNwZWN0IHRoYXQgdGhlIGtleSBkaXN0cmlidXRpb24gYmVpbmcg Y29udGVtcGxhdGVkIGlzIHBoeXNpY2FsLCBidXQgd2UgY2FuIGNlcnRhaW5seSB0YWxrIGFib3V0 IGl0Lg0KDQpXcnQgNSwgZG8geW91IHRoaW5rIHRoYXQgd2FpdGluZyBmb3IgdGhlIG91dHB1dCBv ZiBhIHJlc2VhcmNoIGdyb3VwIGlzIHJpZ2h0PyBGaXJzdGx5LCB0aGlzIGRvZXNuJ3QgYnJpbmcg dXMgYW55dGhpbmcgY2xvc2VyIHRvIHNvbWV0aGluZyB3ZSBjYW4gaW5jbHVkZSBpbiBhIHN0YW5k YXJkcyB0cmFjayBSRkMsIGFuZCBzZWNvbmRseSBpdCBkb2Vzbid0IGdpdmUgdXMgYW55IHNlY3Vy aXR5IHdlIGNhbiBpbXBsZW1lbnQgdG9kYXkuDQoNCkENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBpZXNnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3RlcGhlbiBGYXJyZWxsDQo+IFNlbnQ6IDI0IE5vdmVtYmVyIDIwMTQgMTE6NDgN Cj4gVG86IFRoZSBJRVNHDQo+IENjOiBtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IA0KPiBk cmFmdC1pZXRmLW1hbmV0LWlicy5hbGxAdG9vbHMuaWV0Zi5vcmc7DQo+IG1hbmV0QGlldGYub3Jn OyBULkNsYXVzZW5AY29tcHV0ZXIub3JnDQo+IFN1YmplY3Q6IFN0ZXBoZW4gRmFycmVsbCdzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi1tYW5ldC1pYnMtMDM6ICh3aXRoIA0KPiBESVNDVVNTKQ0KPiAN Cj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW1hbmV0LWlicy0wMzogRGlzY3Vzcw0KPiANCj4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0byBjdXQgDQo+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIA0KPiBodHRwOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+ IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW1hbmV0LWlicy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gKDEpIEkgYW0gY29uY2VybmVkIHRoYXQgUkZDNjUwNyBt YXkgbm90IGJlIHJlYWR5IGZvciB1c2UgaW4gDQo+IHN0YW5kYXJkcy10cmFjayBSRkNzLiBTbyBm YXIgaXQgaGFzIG5vdCBiZWVuIGFuZCBJIGhhdmUgZm91bmQgbm8gcGVlciANCj4gcmV2aWV3ZWQg c2VjdXJpdHkgb3IgY3J5cHRvZ3JhcGhpYyBhbmFseXNpcyB0aGF0IGluZGljYXRlcyB0aGF0IGl0 IGlzIA0KPiBoYXMgYmVlbiBzdHVkaWVkIHRvIHNlZSBpZiBpdCBpcyBnb29kIGVub3VnaCBmb3Ig dGhhdC4gSSd2ZSBhbHNvIG5vdCANCj4gc2VlbiBhbnkgTUFORVQgbGlzdCBkaXNjdXNzaW9uIG9m IHRoYXQgYXNwZWN0IChhbmQgaW5kZWVkIHRoZSBNQU5FVCANCj4gbGlzdCBkaXNjdXNzaW9uIEkg ZGlkIHNlZSBzZWVtcyB0byBpbnZvbHZlIHZlcnkgZmV3IHBlb3BsZSkuICBJIGFza2VkIA0KPiBv biB0aGUgQ0ZSRyBsaXN0IGFib3V0IFJGQzY1MDcgYW5kIGl0IHNlZW1zIFsxXSB0byBiZSB0aGUg Y2FzZSB0aGF0IA0KPiBuby1vbmUgaGFzIHNvIGZhciByZWFsbHkgZXZhbHVhdGVkIGl0cyBzZWN1 cml0eSwgb3RoZXIgdGhhbiBmb2xrcyANCj4gYXNzb2NpYXRlZCB3aXRoIHRoZSBhdXRob3IncyBp bnN0aXR1dGlvbi4gKFdoaWNoIGFwcGxpZXMgdG8gYm90aCA2NTA3IA0KPiBhbmQgdGhpcyBJIHRo aW5rLikgSSBhbHNvIGRpZG4ndCBmaW5kIGFueSByZWZlcmVuY2VzIHRvIDY1MDcgaW4gR29vZ2xl IA0KPiBzY2hvbGFyLiAgTGFzdGx5LCBJIHRoaW5rIHdlIHNob3VsZCBiZSwgYW5kIGJlIHNlZW4g dG8gYmUsIG1vcmUgDQo+IGNhcmVmdWwgdGhhbiB1c3VhbCB3aXRoIHRoaXMgZHJhZnQgLSBnaXZl biB0aGUgc2l0dWF0aW9uIHdpdGggDQo+IERVQUwtRUMtRFJCRywgYW5kIHRoYXQgdGhpcyBpcyBh IG5ldyBzaWduYXR1cmUgc2NoZW1lIHRoYXQgYWxsb3dzIHRoZSANCj4gS01TIHRvIGZha2UgYW55 b25lJ3Mgc2lnbmF0dXJlIGFuZCB0aGUgYXV0aG9yIGludm9sdmVkLiAgTm90ZSB0aGF0IA0KPiB0 aGF0IGxhc3QgaXMgbm90IGFueSBpbXB1dGF0aW9uIG9mIG1pc2JlaGF2aW91ciwgYnV0IHRoZSBJ RVRGIHdvdWxkIA0KPiBub3QgYmUgIGRvaW5nIGR1ZS1kaWxsaWdlbmNlIGlmIHdlIGRpZG4ndCBl eHBsaWNpdGx5IGNvbnNpZGVyIHRoYXQgDQo+IGFzcGVjdC4NCj4gDQo+ICAgWzFdIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2ZyZy9jdXJyZW50L21zZzA1NTQwLmh0bWwN Cj4gDQo+ICgyKSBIb3cgZG9lcyBhIHJvdXRlciBnZXQgaXRzIHByaXZhdGUga2V5PyBXaHkgaXMg aXQgb2sgdG8gbm90IHNwZWNpZnkgDQo+IHRoYXQ/IFNlZW1zIGxpa2UgYW4gaW50ZXJvcCBmYWls IGlmIHRoYXQgaXMgbm90IGRvbmUuDQo+IA0KPiAoMykgSSB0aGluayB0aGlzIGlzIHRoZSBmaXJz dCBhc3ltbWV0cmljIHNjaGVtZSB0aGUgV0cgaGF2ZSBhZG9wdGVkLiANCj4gSWYgdGhhdCdzIHdy b25nIHRoZW4gdGhpcyBkaXNjdXNzIHBvaW50IGlzIGZhaXJseQ0KPiBtb290Oi0pIFdoZW4gZGlk IHRoZSBXRyBkaXNjdXNzIHdoZXRoZXIgdG8gYWRvcHQgSUJTIGFzIGl0cyBmaXJzdCANCj4gYXN5 bW1ldHJpYyBhcHByYW9jaCBhbmQgbm90IHRyYWRpdGlvbmFsIHNpZ25hdHVyZSBzY2hlbWVzIHRo YXQgZG9uJ3QgDQo+IGhhdmUgc3Bvb2ZpbmcgYnkgdGhlIEtHL0tNUyBhcyBhbiBpbmhlcmVudCBw cm9wZXJ0eT8gVGhhdCBtaWdodCBiZSBhIA0KPiByZWFzb25hYmxlIGRlY2lzaW9uLCBidXQgSSBk b24ndCBzZWUgd2hlcmUgdGhhdCBkZWNpc2lvbiB3YXMgbWFkZSwgbm9yIA0KPiB3aHkuIChUaGF0 IGNvdWxkIGJlIGp1c3QgdGhhdCBJJ3ZlIG5vdCBsb29rZWQgZmFyIGVub3VnaCBiYWNrIGluIHRo ZSANCj4gV0cgbGlzdCBhcmNoaXZlcywgaW4gd2hpY2ggY2FzZSB0aGlzIGlzIGVhc3kuKQ0KPiAN Cj4gKDQpIDQuMTogVGhlIHVzdWFsIHJldm9jYXRpb24gdHJpY2sgb2YgaW5jbHVkaW5nIGEgdGlt ZSB2YWx1ZSBpbiB0aGUgDQo+IG5hbWUgaXMgcmVmZXJyZWQgdG8gYXQgdGhlIGVuZCBvZiB0aGlz IHNlY3Rpb24gYnV0IHdpdGhvdXQgc3VmZmljaWVudCANCj4gZGV0YWlsIHRvIGFsbG93IGludGVy b3AuIFdoeSBpcyB0aGF0IG9rPw0KPiANCj4gKDUpIFJGQzY1MDcgaXNuJ3QgY29tcGF0aWJsZSB3 aXRoIGUuZy4gQ3VydmUyNTUxOSBvciBwZXJoYXBzIG90aGVyIA0KPiAicmlnaWQiIGN1cnZlcy4g R2l2ZW4gdGhhdCBDRlJHIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiBwaWNraW5nIG5ldyANCj4gY3Vy dmVzLCB3aXRoIGJldHRlciBwcm9wZXJ0aWVzLCB3b3VsZG4ndCBpdCBiZSBiZXR0ZXIgZm9yIHRo ZSBXRyB0byANCj4gd2FpdCBhbmQgaGF2ZSB0aGUgY2hvaWNlIG9mIHVzaW5nIHRob3NlIGFzIHdl bGwgb3IgaW5zdGVhZD8NCj4gDQo+IA0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApy ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl IHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl IG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKgo= From nobody Mon Nov 24 07:53: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 6DFB31A6FD5; Mon, 24 Nov 2014 07:53:19 -0800 (PST) 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 TW7XXF0l6mIM; Mon, 24 Nov 2014 07:53:16 -0800 (PST) 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 14AA31A6F84; Mon, 24 Nov 2014 07:53:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="499752940" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Nov 2014 15:53:14 +0000 X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="73325534" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 24 Nov 2014 15:53:14 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 15:53:14 +0000 From: "Dearlove, Christopher (UK)" To: Stephen Farrell , "adrian@olddog.co.uk" , 'The IESG' Thread-Topic: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) Thread-Index: AQHQB98v/hptP4rV3kiJzDsZOYRRXpxvslEAgAA36cA= Date: Mon, 24 Nov 2014 15:53:13 +0000 Message-ID: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> <5473228C.6030907@cs.tcd.ie> In-Reply-To: <5473228C.6030907@cs.tcd.ie> 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/FAKrfPBLMaUygdrP8q2mWxfaDM4 Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 15:53:19 -0000 I just want to pick up on " far better known asymmetric schemes". Better kn= own, yes. Better? Or even equally good for some requirements (those this is= for)? Note that there are important different properties of IBS (whether = ECCSI, or other IBS schemes) that aren't shared by other asymmetric schemes= I'm aware of. Specifically, with this, or other, IBS schemes you can do the following: Router A receives private key from KMS. In the systems of interest to us, t= his would be in a secure location, but that's not the only possibility. Rou= ter A is not given any information about B.C,D, ..., indeed some of those m= ight not even exist at this point. Routers A,B,C,D, ... are sent into the field. The KMS is not. When router A= receives a message (or packet, as appropriate) from router B it needs noth= ing specific from B except its identity. (And that's zero overhead when the= identity is an IP address.) In particular no certificates. Note that who could claim precedence for first suggesting IBE/IBS (not spec= ifically ECCSI, that's a realisation of the concept) for ad hoc networks co= uld be debated. But I'm aware of published work dating back at least as far= as 2005. -- = 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 Stephen Farrell Sent: 24 November 2014 12:20 To: adrian@olddog.co.uk; 'The IESG' Cc: manet-chairs@tools.ietf.org; draft-ietf-manet-ibs.all@tools.ietf.org; m= anet@ietf.org; T.Clausen@computer.org Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: = (with DISCUSS) ----------------------! 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 24/11/14 12:06, Adrian Farrel wrote: > Thanks Stephen, > = > Some good and bad questions here, I think. > = > Wrt 1, is IBS sufficiently bad and unknown that using it is worse > than having no security? Given that there are far better known asymmetric schemes my question#1 is valid I think. This draft seems to be picking the cryptographically unknown over the known and is the first standards-track document to do so. > Wrt 2, I suspect that the key distribution being contemplated is > physical, but we can certainly talk about it. Right. I don't know how to get interop between router and KMS without at least e.g. defining a format or some kind of interface. > Wrt 5, do you think that waiting for the output of a research group > is right? Firstly, this doesn't bring us anything closer to something > we can include in a standards track RFC, and secondly it doesn't give > us any security we can implement today. Not waiting is quite arguable yes. However, the TLS wg are waiting for this, albeit without that currently blocking progress, so it'll be relatively quick (as in weeks, is the plan). I wasn't clear if the MANET WG were aware of that, since CFRG have only been working on that since earlier this year. The new curves are being picked because they have both CPU and side-channel resistance advantages that could be relevant here and I saw no sign that the work had been factored into this at all. (It may well have of course, as I said, I only went back a little into the MANET list archive.) S. > = > A > = >> -----Original Message----- From: iesg >> [mailto:iesg-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >> 24 November 2014 11:48 To: The IESG Cc: >> manet-chairs@tools.ietf.org; >> draft-ietf-manet-ibs.all@tools.ietf.org; manet@ietf.org; >> T.Clausen@computer.org Subject: Stephen Farrell's Discuss on >> draft-ietf-manet-ibs-03: (with DISCUSS) >> = >> Stephen Farrell has entered the following ballot position for = >> draft-ietf-manet-ibs-03: Discuss >> = >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> = >> = >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> = >> = >> The document, along with other ballot positions, can be found >> here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ >> = >> = >> = >> ---------------------------------------------------------------------- >> >> = DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> = (1) I am concerned that RFC6507 may not be ready for use in >> standards-track RFCs. So far it has not been and I have found no >> peer reviewed security or cryptographic analysis that indicates >> that it is has been studied to see if it is good enough for that. >> I've also not seen any MANET list discussion of that aspect (and >> indeed the MANET list discussion I did see seems to involve very >> few people). I asked on the CFRG list about RFC6507 and it seems >> [1] to be the case that no-one has so far really evaluated its >> security, other than folks associated with the author's >> institution. (Which applies to both 6507 and this I think.) I also >> didn't find any references to 6507 in Google scholar. Lastly, I >> think we should be, and be seen to be, more careful than usual >> with this draft - given the situation with DUAL-EC-DRBG, and that = >> this is a new signature scheme that allows the KMS to fake anyone's >> signature and the author involved. Note that that last is not any >> imputation of misbehaviour, but the IETF would not be doing >> due-dilligence if we didn't explicitly consider that aspect. >> = >> [1] >> https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html >> = >> (2) How does a router get its private key? Why is it ok to not >> specify that? Seems like an interop fail if that is not done. >> = >> (3) I think this is the first asymmetric scheme the WG have = >> adopted. If that's wrong then this discuss point is fairly moot:-) >> When did the WG discuss whether to adopt IBS as its first >> asymmetric appraoch and not traditional signature schemes that >> don't have spoofing by the KG/KMS as an inherent property? That >> might be a reasonable decision, but I don't see where that decision >> was made, nor why. (That could be just that I've not looked far >> enough back in the WG list archives, in which case this is easy.) >> = >> (4) 4.1: The usual revocation trick of including a time value in >> the name is referred to at the end of this section but without >> sufficient detail to allow interop. Why is that ok? >> = >> (5) RFC6507 isn't compatible with e.g. Curve25519 or perhaps other >> "rigid" curves. Given that CFRG are in the process of picking new >> curves, with better properties, wouldn't it be better for the WG to >> wait and have the choice of using those as well or instead? >> = >> = > = > = _______________________________________________ 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 Nov 24 08:08: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 24B431A6F21; Mon, 24 Nov 2014 08:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP6l-0-XtAEU; Mon, 24 Nov 2014 08:08:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 278801A7004; Mon, 24 Nov 2014 08:08:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BF058BE87; Mon, 24 Nov 2014 16:08:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 254J_ZKuAOHD; Mon, 24 Nov 2014 16:08:01 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.20.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B5A0BE79; Mon, 24 Nov 2014 16:08:01 +0000 (GMT) Message-ID: <547357E0.4060901@cs.tcd.ie> Date: Mon, 24 Nov 2014 16:08:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" , "adrian@olddog.co.uk" , 'The IESG' References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> <5473228C.6030907@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LYIc0HKoJdoXG_yiX7XIZllIgSE Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 16:08:12 -0000 Hiya, On 24/11/14 15:53, Dearlove, Christopher (UK) wrote: > I just want to pick up on " far better known asymmetric schemes". > Better known, yes. That is my main point. Well-known and well-studied are important properties for standards-track crypto mechanisms, I'm sure you'll agree. That ECCSI is nowhere near as well-studied as say ECDSA or RSA is a real issue. For example, its not unlikely that once one standards-track RFC uses it, others will follow, so we need to take care with this stuff. > Better? Or even equally good for some requirements > (those this is for)? Note that there are important different > properties of IBS (whether ECCSI, or other IBS schemes) that aren't > shared by other asymmetric schemes I'm aware of. > > Specifically, with this, or other, IBS schemes you can do the > following: > > Router A receives private key from KMS. In the systems of interest to > us, this would be in a secure location, but that's not the only > possibility. Router A is not given any information about B.C,D, ..., > indeed some of those might not even exist at this point. Well, all routers need the same domain parameters but sure. > Routers A,B,C,D, ... are sent into the field. The KMS is not. When > router A receives a message (or packet, as appropriate) from router B > it needs nothing specific from B except its identity. (And that's > zero overhead when the identity is an IP address.) In particular no > certificates. No certificates is grand, and as per above the verifier needs to know the same domain parameters and not only the IP address, but certs are not at issue in the discuss. > Note that who could claim precedence for first suggesting IBE/IBS > (not specifically ECCSI, that's a realisation of the concept) for ad > hoc networks could be debated. But I'm aware of published work dating > back at least as far as 2005. Yes, but not afaik based on this particular scheme. S. > From nobody Mon Nov 24 08:21: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 9CB9A1A7D83; Mon, 24 Nov 2014 08:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lAjbRGXl6TF; Mon, 24 Nov 2014 08:21:27 -0800 (PST) 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 413511A7014; Mon, 24 Nov 2014 08:21:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="499767050" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Nov 2014 16:21:25 +0000 X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="73330857" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 24 Nov 2014 16:21:24 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 16:21:24 +0000 From: "Dearlove, Christopher (UK)" To: Stephen Farrell , "adrian@olddog.co.uk" , 'The IESG' Thread-Topic: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) Thread-Index: AQHQB98v/hptP4rV3kiJzDsZOYRRXpxvslEAgAA36cCAAAeqAIAAAJRA Date: Mon, 24 Nov 2014 16:21:24 +0000 Message-ID: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> <5473228C.6030907@cs.tcd.ie> <547357E0.4060901@cs.tcd.ie> In-Reply-To: <547357E0.4060901@cs.tcd.ie> 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/D_uoKuxNhjPo3ChgrhraWEgmJT0 Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 16:21:30 -0000 QWdyZWVkLCBFQ0NTSSBmb3IgYWQgaG9jIG5ldHdvcmtzIGRvZXMgbm90IGRhdGUgYmFjayB0byAy MDA1LiBCdXQgb2JzZXJ2YXRpb24gb2YgdGhlIGRlc2lyYWJpbGl0eSBvZiB0aGUgY2hhcmFjdGVy aXN0aWNzIG9mIElCUyAoaW5jbHVkaW5nIEVDQ1NJKSBpbiBzb21lIGFkIGhvYyBuZXR3b3JrcyBk YXRlcyBiYWNrIGF0IGxlYXN0IHRoYXQgZmFyLg0KDQpXZWxsIGtub3duIGlzIGdvb2QuIEJ1dCB3 aGF0IGlzIHdlbGwga25vd24gYW5kIGhhcyB0aGUgcmVxdWlyZWQgcHJvcGVydGllcz8NCg0KSSdt IG5vdCBhd2FyZSBvZiBhbiBJQlMgbWV0aG9kIHRoYXQgd291bGQgaGF2ZSBsZXNzIHJlc2lzdGFu Y2UgdGhhbiBFQ0NTSSAoSSBhbSBhd2FyZSBvZiBhdCBsZWFzdCB0d28gb3RoZXIgSUJTIG1ldGhv ZHMpLiBXZSBkbyBhdCBsZWFzdCBoYXZlIGFuIFJGQyBmb3IgRUNDU0kuIChBbHNvIHRoZSBvdGhl cnMgSSdtIGF3YXJlIG9mIGFyZSBoYXJkZXIgYW5kIHNsb3dlciB0byBpbXBsZW1lbnQsIHRob3Vn aCB0aGV5IGNhbiBwcm9kdWNlIHNtYWxsZXIgc2lnbmF0dXJlcy4pDQoNCkFzIEkgc2FpZCwgSSdt IGhvcGluZyB0byBnZXQgc29tZSBtb3JlIGlucHV0IG9uIHRoZSBzdWJqZWN0LiBOb3QgdGhhdCwg YnV0IHlvdSBtaWdodCBhbHNvIHNwZWFrIHRvIEtlbm55IFBhdGVyc29uIChDRlJHIGNvLWNoYWly KSBvbiB0aGUgc3ViamVjdC4gSSBkbyBub3Qga25vdyBoaXMgdmlld3Mgb24gRUNDU0kgc3BlY2lm aWNhbGx5IChzbyBJJ20gb2ZmZXJpbmcgYSBob3N0YWdlIHRvIGZvcnR1bmUpIGFuZCBoZSBtaWdo dCBkZWNsaW5lIHRvIGNvbW1lbnQuIEJ1dCBoZSBoYXMgdGhlIGV4cGVydGlzZS4NCg0KKFllcywg YWxsIHJvdXRlcnMgIG5lZWQgc2FtZSBkb21haW4gcGFyYW1ldGVycywgd2hpY2ggY2FuIGJlIHBh c3NlZCBhdCBzYW1lIHRpbWUgYXMgcHJpdmF0ZSBrZXkuIFRoZSBwb2ludCBpcyB0aGF0IHRoZXkg YXJlbid0IHJvdXRlciBzcGVjaWZpYy4gUGFyZW50aGVzaXNlZCBjb21tZW50IGFzIEkgZG9uJ3Qg dGhpbmsgdGhpcyBpcyBhIHBvaW50IGF0IGlzc3VlLikNCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFy bG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdy b3VwDQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxp dHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdm aWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0 NCAxMjQ1IDI0MjE5NMKgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAo T3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBP IEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRz LCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3 DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBb bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KU2VudDogMjQgTm92ZW1iZXIgMjAx NCAxNjowOA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBhZHJpYW5Ab2xkZG9nLmNv LnVrOyAnVGhlIElFU0cnDQpDYzogbWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1p ZXRmLW1hbmV0LWlicy5hbGxAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0QGlldGYub3JnOyBULkNsYXVz ZW5AY29tcHV0ZXIub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBTdGVwaGVuIEZhcnJlbGwncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtbWFuZXQtaWJzLTAzOiAod2l0aCBESVNDVVNTKQ0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVy IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu eSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVt YWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1 c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIaXlhLA0KDQpPbiAyNC8xMS8xNCAxNTo1Mywg RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgd3JvdGU6DQo+IEkganVzdCB3YW50IHRvIHBpY2sg dXAgb24gIiBmYXIgYmV0dGVyIGtub3duIGFzeW1tZXRyaWMgc2NoZW1lcyIuDQo+IEJldHRlciBr bm93biwgeWVzLiANCg0KVGhhdCBpcyBteSBtYWluIHBvaW50LiBXZWxsLWtub3duIGFuZCB3ZWxs LXN0dWRpZWQgYXJlIGltcG9ydGFudCBwcm9wZXJ0aWVzIGZvciBzdGFuZGFyZHMtdHJhY2sgY3J5 cHRvIG1lY2hhbmlzbXMsIEknbSBzdXJlIHlvdSdsbCBhZ3JlZS4gVGhhdCBFQ0NTSSBpcyBub3do ZXJlIG5lYXIgYXMgd2VsbC1zdHVkaWVkIGFzIHNheSBFQ0RTQSBvciBSU0EgaXMgYSByZWFsIGlz c3VlLiBGb3IgZXhhbXBsZSwgaXRzIG5vdCB1bmxpa2VseSB0aGF0IG9uY2Ugb25lIHN0YW5kYXJk cy10cmFjayBSRkMgdXNlcyBpdCwgb3RoZXJzIHdpbGwgZm9sbG93LCBzbyB3ZSBuZWVkIHRvIHRh a2UgY2FyZSB3aXRoIHRoaXMgc3R1ZmYuDQoNCj4gQmV0dGVyPyBPciBldmVuIGVxdWFsbHkgZ29v ZCBmb3Igc29tZSByZXF1aXJlbWVudHMgKHRob3NlIHRoaXMgaXMgDQo+IGZvcik/ICBOb3RlIHRo YXQgdGhlcmUgYXJlIGltcG9ydGFudCBkaWZmZXJlbnQgcHJvcGVydGllcyBvZiBJQlMgDQo+ICh3 aGV0aGVyIEVDQ1NJLCBvciBvdGhlciBJQlMgc2NoZW1lcykgdGhhdCBhcmVuJ3Qgc2hhcmVkIGJ5 IG90aGVyIA0KPiBhc3ltbWV0cmljIHNjaGVtZXMgSSdtIGF3YXJlIG9mLg0KPiANCj4gU3BlY2lm aWNhbGx5LCB3aXRoIHRoaXMsIG9yIG90aGVyLCBJQlMgc2NoZW1lcyB5b3UgY2FuIGRvIHRoZQ0K PiBmb2xsb3dpbmc6DQo+IA0KPiBSb3V0ZXIgQSByZWNlaXZlcyBwcml2YXRlIGtleSBmcm9tIEtN Uy4gSW4gdGhlIHN5c3RlbXMgb2YgaW50ZXJlc3QgdG8gDQo+IHVzLCB0aGlzIHdvdWxkIGJlIGlu IGEgc2VjdXJlIGxvY2F0aW9uLCBidXQgdGhhdCdzIG5vdCB0aGUgb25seSANCj4gcG9zc2liaWxp dHkuIFJvdXRlciBBIGlzIG5vdCBnaXZlbiBhbnkgaW5mb3JtYXRpb24gYWJvdXQgQi5DLEQsIC4u LiwgDQo+IGluZGVlZCBzb21lIG9mIHRob3NlIG1pZ2h0IG5vdCBldmVuIGV4aXN0IGF0IHRoaXMg cG9pbnQuDQoNCldlbGwsIGFsbCByb3V0ZXJzIG5lZWQgdGhlIHNhbWUgZG9tYWluIHBhcmFtZXRl cnMgYnV0IHN1cmUuDQoNCj4gUm91dGVycyBBLEIsQyxELCAuLi4gYXJlIHNlbnQgaW50byB0aGUg ZmllbGQuIFRoZSBLTVMgaXMgbm90LiBXaGVuIA0KPiByb3V0ZXIgQSByZWNlaXZlcyBhIG1lc3Nh Z2UgKG9yIHBhY2tldCwgYXMgYXBwcm9wcmlhdGUpIGZyb20gcm91dGVyIEIgDQo+IGl0IG5lZWRz IG5vdGhpbmcgc3BlY2lmaWMgZnJvbSBCIGV4Y2VwdCBpdHMgaWRlbnRpdHkuIChBbmQgdGhhdCdz IHplcm8gDQo+IG92ZXJoZWFkIHdoZW4gdGhlIGlkZW50aXR5IGlzIGFuIElQIGFkZHJlc3MuKSBJ biBwYXJ0aWN1bGFyIG5vIA0KPiBjZXJ0aWZpY2F0ZXMuDQoNCk5vIGNlcnRpZmljYXRlcyBpcyBn cmFuZCwgYW5kIGFzIHBlciBhYm92ZSB0aGUgdmVyaWZpZXIgbmVlZHMgdG8ga25vdyB0aGUgc2Ft ZSBkb21haW4gcGFyYW1ldGVycyBhbmQgbm90IG9ubHkgdGhlIElQIGFkZHJlc3MsIGJ1dCBjZXJ0 cyBhcmUgbm90IGF0IGlzc3VlIGluIHRoZSBkaXNjdXNzLg0KDQo+IE5vdGUgdGhhdCB3aG8gY291 bGQgY2xhaW0gcHJlY2VkZW5jZSBmb3IgZmlyc3Qgc3VnZ2VzdGluZyBJQkUvSUJTIChub3QgDQo+ IHNwZWNpZmljYWxseSBFQ0NTSSwgdGhhdCdzIGEgcmVhbGlzYXRpb24gb2YgdGhlIGNvbmNlcHQp IGZvciBhZCBob2MgDQo+IG5ldHdvcmtzIGNvdWxkIGJlIGRlYmF0ZWQuIEJ1dCBJJ20gYXdhcmUg b2YgcHVibGlzaGVkIHdvcmsgZGF0aW5nIGJhY2sgDQo+IGF0IGxlYXN0IGFzIGZhciBhcyAyMDA1 Lg0KDQpZZXMsIGJ1dCBub3QgYWZhaWsgYmFzZWQgb24gdGhpcyBwYXJ0aWN1bGFyIHNjaGVtZS4N Cg0KUy4NCg0KDQo+IA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVh c2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ug c2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3Nl IG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqCg== From nobody Mon Nov 24 08:26: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 B01C81A854D; Mon, 24 Nov 2014 08:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBs40psnYw4H; Mon, 24 Nov 2014 08:25:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF59B1A86E9; Mon, 24 Nov 2014 08:25:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 580E7BE97; Mon, 24 Nov 2014 16:25:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l7DEHbutBtW; Mon, 24 Nov 2014 16:25:52 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.20.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0CDF1BE8A; Mon, 24 Nov 2014 16:25:52 +0000 (GMT) Message-ID: <54735C0F.5020902@cs.tcd.ie> Date: Mon, 24 Nov 2014 16:25:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" , "adrian@olddog.co.uk" , 'The IESG' References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> <5473228C.6030907@cs.tcd.ie> <547357E0.4060901@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8YqZVSpIy3afXTKkJjbLApaboKM Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 16:25:56 -0000 Hiya, On 24/11/14 16:21, Dearlove, Christopher (UK) wrote: > Agreed, ECCSI for ad hoc networks does not date back to 2005. But > observation of the desirability of the characteristics of IBS > (including ECCSI) in some ad hoc networks dates back at least that > far. > > Well known is good. But what is well known and has the required > properties? So perhaps that suggests addressing that part of the discuss first then. (part 3) Why do the WG (not your specific deployments) need IBS? When was that discussed? S. > > I'm not aware of an IBS method that would have less resistance than > ECCSI (I am aware of at least two other IBS methods). We do at least > have an RFC for ECCSI. (Also the others I'm aware of are harder and > slower to implement, though they can produce smaller signatures.) > > As I said, I'm hoping to get some more input on the subject. Not > that, but you might also speak to Kenny Paterson (CFRG co-chair) on > the subject. I do not know his views on ECCSI specifically (so I'm > offering a hostage to fortune) and he might decline to comment. But > he has the expertise. > > (Yes, all routers need same domain parameters, which can be passed > at same time as private key. The point is that they aren't router > specific. Parenthesised comment as I don't think this is a point at > issue.) > From nobody Mon Nov 24 08: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 8048F1A6EEF; Mon, 24 Nov 2014 08:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6g-PU1sG88c; Mon, 24 Nov 2014 08:32:34 -0800 (PST) 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 5F7DD1A3B9F; Mon, 24 Nov 2014 08:32:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="422150718" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Nov 2014 16:32:33 +0000 X-IronPort-AV: E=Sophos;i="5.07,449,1413241200"; d="scan'208";a="81723742" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 24 Nov 2014 16:32:31 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 16:32:31 +0000 From: "Dearlove, Christopher (UK)" To: Stephen Farrell , "adrian@olddog.co.uk" , 'The IESG' Thread-Topic: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) Thread-Index: AQHQB98v/hptP4rV3kiJzDsZOYRRXpxvslEAgAA36cCAAAeqAIAAAJRAgAAEaYCAAAAesA== Date: Mon, 24 Nov 2014 16:32:31 +0000 Message-ID: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <06a201d007df$21fdb180$65f91480$@olddog.co.uk> <5473228C.6030907@cs.tcd.ie> <547357E0.4060901@cs.tcd.ie> <54735C0F.5020902@cs.tcd.ie> In-Reply-To: <54735C0F.5020902@cs.tcd.ie> 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/OUDi3JIw7mLxl9k1cC59JnsQmW4 Cc: "manet-chairs@tools.ietf.org" , "draft-ietf-manet-ibs.all@tools.ietf.org" , "manet@ietf.org" , "T.Clausen@computer.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Nov 2014 16:32:36 -0000 RXNzZW50aWFsbHkgSSB3b3VsZCBzYXkgdGhhdCB0aGUga25vd2xlZGdlIHRoYXQgSUJTIGlzIGEg Z29vZCBmaXQgdG8gc29tZSBhZCBob2MgbmV0d29ya3MgaXMgd2VsbC1rbm93biB0byBtYW55IGlu IHRoYXQgY29tbXVuaXR5LiBJIG1hZGUgYSBwcm9wb3NhbCB0byBzdGFuZGFyZGlzZSBhIHZlcnNp b24gdGhlcmVvZiB0byBleHRlbmQgdGhlIHJhbmdlIG9mIG9wdGlvbnMgaW4gUkZDIDcxODIsIHdo aWNoIGFscmVhZHkgaGFzIHRoZSBtYWluIGNvbXBldGl0b3JzIChzZXZlcmFsIHNoYXJlZCBrZXkg dmFyaWFudHMsIFJTQSkgaW4gaXQuIFdlIGhhZCBubyBvbmUgc2F5aW5nIGl0IHdhcyBhIGJhZCBp ZGVhLCBhbmQgc29tZSBwZW9wbGUgc2F5aW5nIGl0J3Mgd2hhdCB0aGV5IHdhbnRlZC4gU29tZSBw ZW9wbGUgaW4gdGhlIGxhdHRlciBjYW1wIHByb2JhYmx5IGFyZW4ndCBtaW5kZWQgdG8gZGlzY3Vz cyB0aGVpciBzcGVjaWZpY3MgaWYgdGhleSBkb24ndCBuZWVkIHRvLCBmb3IgcmVhc29ucyBsb29r IGF0IHRoZSBhZmZpbGlhdGlvbnMgb2Ygc2V2ZXJhbCBwZW9wbGUgaW4gdGhlIGdyb3VwLiBBcyBz dWNoLCBJIHRoaW5rIHRoZSByZXF1aXJlbWVudCB0byBoYXZlIGFuIElCUyBzY2hlbWUgKEknbSBu b3QgYWRkcmVzc2luZyB0aGUgY2hvaWNlIG9mIElCUyBzY2hlbWUgaGVyZSkgYXMgYW4gb3B0aW9u IHdhc24ndCByZWFsbHkgdmVyeSBjb250ZW50aW91cywgYmVjYXVzZSBubyBvbmUgY29udGVuZGVk Lg0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVy LCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBh bmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5v bG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1 IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5 c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVk IE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2Ug Q2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBF bmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZV0gDQpTZW50OiAyNCBOb3ZlbWJlciAyMDE0IDE2OjI2DQpUbzogRGVhcmxvdmUsIENocmlzdG9w aGVyIChVSyk7IGFkcmlhbkBvbGRkb2cuY28udWs7ICdUaGUgSUVTRycNCkNjOiBtYW5ldC1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWFuZXQtaWJzLmFsbEB0b29scy5pZXRmLm9y ZzsgbWFuZXRAaWV0Zi5vcmc7IFQuQ2xhdXNlbkBjb21wdXRlci5vcmcNClN1YmplY3Q6IFJlOiBb bWFuZXRdIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tYW5ldC1pYnMt MDM6ICh3aXRoIERJU0NVU1MpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZy b20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93 IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGlu c3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkhp eWEsDQoNCk9uIDI0LzExLzE0IDE2OjIxLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90 ZToNCj4gQWdyZWVkLCBFQ0NTSSBmb3IgYWQgaG9jIG5ldHdvcmtzIGRvZXMgbm90IGRhdGUgYmFj ayB0byAyMDA1LiBCdXQgDQo+IG9ic2VydmF0aW9uIG9mIHRoZSBkZXNpcmFiaWxpdHkgb2YgdGhl IGNoYXJhY3RlcmlzdGljcyBvZiBJQlMgDQo+IChpbmNsdWRpbmcgRUNDU0kpIGluIHNvbWUgYWQg aG9jIG5ldHdvcmtzIGRhdGVzIGJhY2sgYXQgbGVhc3QgdGhhdCANCj4gZmFyLg0KPiANCj4gV2Vs bCBrbm93biBpcyBnb29kLiBCdXQgd2hhdCBpcyB3ZWxsIGtub3duIGFuZCBoYXMgdGhlIHJlcXVp cmVkIA0KPiBwcm9wZXJ0aWVzPw0KDQpTbyBwZXJoYXBzIHRoYXQgc3VnZ2VzdHMgYWRkcmVzc2lu ZyB0aGF0IHBhcnQgb2YgdGhlIGRpc2N1c3MgZmlyc3QgdGhlbi4gKHBhcnQgMykgV2h5IGRvIHRo ZSBXRyAobm90IHlvdXIgc3BlY2lmaWMgZGVwbG95bWVudHMpIG5lZWQgSUJTPyBXaGVuIHdhcyB0 aGF0IGRpc2N1c3NlZD8NCg0KUy4NCg0KPiANCj4gSSdtIG5vdCBhd2FyZSBvZiBhbiBJQlMgbWV0 aG9kIHRoYXQgd291bGQgaGF2ZSBsZXNzIHJlc2lzdGFuY2UgdGhhbiANCj4gRUNDU0kgKEkgYW0g YXdhcmUgb2YgYXQgbGVhc3QgdHdvIG90aGVyIElCUyBtZXRob2RzKS4gV2UgZG8gYXQgbGVhc3Qg DQo+IGhhdmUgYW4gUkZDIGZvciBFQ0NTSS4gKEFsc28gdGhlIG90aGVycyBJJ20gYXdhcmUgb2Yg YXJlIGhhcmRlciBhbmQgDQo+IHNsb3dlciB0byBpbXBsZW1lbnQsIHRob3VnaCB0aGV5IGNhbiBw cm9kdWNlIHNtYWxsZXIgc2lnbmF0dXJlcy4pDQo+IA0KPiBBcyBJIHNhaWQsIEknbSBob3Bpbmcg dG8gZ2V0IHNvbWUgbW9yZSBpbnB1dCBvbiB0aGUgc3ViamVjdC4gTm90IHRoYXQsIA0KPiBidXQg eW91IG1pZ2h0IGFsc28gc3BlYWsgdG8gS2VubnkgUGF0ZXJzb24gKENGUkcgY28tY2hhaXIpIG9u IHRoZSANCj4gc3ViamVjdC4gSSBkbyBub3Qga25vdyBoaXMgdmlld3Mgb24gRUNDU0kgc3BlY2lm aWNhbGx5IChzbyBJJ20gDQo+IG9mZmVyaW5nIGEgaG9zdGFnZSB0byBmb3J0dW5lKSBhbmQgaGUg bWlnaHQgZGVjbGluZSB0byBjb21tZW50LiBCdXQgaGUgDQo+IGhhcyB0aGUgZXhwZXJ0aXNlLg0K PiANCj4gKFllcywgYWxsIHJvdXRlcnMgIG5lZWQgc2FtZSBkb21haW4gcGFyYW1ldGVycywgd2hp Y2ggY2FuIGJlIHBhc3NlZCBhdCANCj4gc2FtZSB0aW1lIGFzIHByaXZhdGUga2V5LiBUaGUgcG9p bnQgaXMgdGhhdCB0aGV5IGFyZW4ndCByb3V0ZXIgDQo+IHNwZWNpZmljLiBQYXJlbnRoZXNpc2Vk IGNvbW1lbnQgYXMgSSBkb24ndCB0aGluayB0aGlzIGlzIGEgcG9pbnQgYXQNCj4gaXNzdWUuKQ0K PiANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBp dCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3Qg Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmli dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Mon Nov 24 09:49: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 7C5351A878A for ; Mon, 24 Nov 2014 09:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 KnBEFgZCAvri for ; Mon, 24 Nov 2014 09:49:33 -0800 (PST) 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 DA9841A8789 for ; Mon, 24 Nov 2014 09:49:31 -0800 (PST) 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 sAOHnTbW021102; Mon, 24 Nov 2014 18:49:29 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1FF48CEA7; Mon, 24 Nov 2014 18:49:29 +0100 (CET) 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 gCrJ0umVVxoY; Mon, 24 Nov 2014 18:49:27 +0100 (CET) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 89B09CE9D; Mon, 24 Nov 2014 18:49:27 +0100 (CET) Date: Mon, 24 Nov 2014 18:49:27 +0100 Message-ID: <87ppcco5eg.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> References: <20141124125651.10916.18205.idtracker@ietfa.amsl.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]); Mon, 24 Nov 2014 18:49:29 +0100 (CET) X-Miltered: at korolev with ID 54736FA9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 54736FA9.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 : 54736FA9.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/Jmy2bur5a2tQ5vjLC-p_Bjh4qmE Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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: Mon, 24 Nov 2014 17:49:34 -0000 I strongly support publication of this document as an Experimental RFC. Minor nits follow. 1. Introduction The introduction seems to imply that DAT is preferable to ETX ("less efficient than in the past, which is one reason to move to a different metric"). I don't understand that -- it is my feeling that DAT is just a variant of ETX that's easier to implement. If you stand by your claim, then that deserves more discussion. 3. Applicability Statement Please clarify what happens when 8 packets in a row are lost. Is the link dropped, or will it be used as the least-preferred link? (The latter, judging from 10.2.5.2.) (FWIW, experimental data indicate that 802.11 remains useful when 7/8 packets are lost, pre-ARQ -- so your "7 or 8" is a little close for comfort.) 4. Rationale "The Directional Airtime Metric measures the incoming loss rate". This is the loss rate in the "wrong" direction -- it's the loss rate in the outgoing direction that we're interested in. I agree with you that this approximation gives reasonable results when combined with bidirectional reachability detection (or whatever it is called in NHDP), but this deserves some more discussion. 5. Metric Functioning & Overview You're speaking about "packet loss", it is not clear that you measure packet loss for protocol packets only. It may be worth restating that that protocol packets are always sent over multicast (is that correct?). 6. Protocol Paremeters "Two routers with different values..." The consequences of this are not clear. What happens if routers are configured with different parameters? Will the network collapse, or will you merely end up with sub-optimal routing choices? (I understand it's the latter, correct?) "DAT_HELLO_TIMEOUT_FACTOR = 1.2". I'm using 1.5 in Babel, which gives more margin for late packets while still reliably avoiding mistaking the next hello for the previous one. 8. Data structures I don't think that citing DLEP is useful here, it only adds confusion by implying that this specification is dependent on DLEP. Why are you using L_DAT_rx_bitrate instead of the tx bitrate? (Given that you only have packet loss in the "wrong" direction, it's not clear to me whether you should be using link speed in the "right" or in the "wrong" direction; more discussion would be welcome.) 9.2 Should a router using this metric ensure that there is a Hello in each packet it sends? Or would the cost be prohibitive? (FWIW, Babel doesn't make that requirement, but it only measures packet loss for packets containing a Hello.) 9.3 Link Loss Gathering "SHOULD be carried out". Why SHOULD? "packets without packet sequence number MUST NOT be processed". Why not? I'd say that if you have either INTERVAL_TIME or seqno, than you can manage. If you have neither, then you're out of luck, of course. At any rate, this MUST NOT seems to contradict the stand you're taking in 9.2. More discussion would be welcome Step 2.3. What happens when L_DAT_last_pkt_seqno = pkt_seqno? Should you be dealing with this case specially? Especially if you take into account my suggestion in 10.1 below. (FWIW, in Babel we treat specially the case where pkg_seqno is between L_DAT_last_pkt_seqno - 15 and L_DAT_last_pkt_seqno -- we "undo history" in that case.) Step 2.3. This case deserves further comments. It implies that the neighbouring router has rebooted (since an extended outage would have caused your various timers to trigger); is it justified to keep the statistics, or should the whole state for this neighbour be reset? (No objection to keeping the current behaviour, just make it clear what's going on here.) 10.1 Shouldn't you be incrementing L_DAT_last_pkt_seqno? (It doesn't matter much, since you'll reset the value the next time you receive a Hello, but you've concluded that you've lost a packet, so you might as well reflect it. Doing this, however, implies further complexity in step 2.3 of 9.3.) From nobody Mon Nov 24 10:01: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 9F4411A879E for ; Mon, 24 Nov 2014 10:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 NscaTwTwxOO2 for ; Mon, 24 Nov 2014 10:01:03 -0800 (PST) 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 7E1BD1A879D for ; Mon, 24 Nov 2014 10:01:02 -0800 (PST) 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 sAOI0x8W028010; Mon, 24 Nov 2014 19:00:59 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4D62CCEAB; Mon, 24 Nov 2014 19:00:59 +0100 (CET) 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 y3JKJqk1JJsz; Mon, 24 Nov 2014 19:00:58 +0100 (CET) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 65F94CEAA; Mon, 24 Nov 2014 19:00:58 +0100 (CET) Date: Mon, 24 Nov 2014 19:00:58 +0100 Message-ID: <87mw7go4v9.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: <87ppcco5eg.wl-jch@pps.univ-paris-diderot.fr> References: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> <87ppcco5eg.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]); Mon, 24 Nov 2014 19:00:59 +0100 (CET) X-Miltered: at korolev with ID 5473725B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5473725B.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 : 5473725B.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/fY8k83RExoThvdwrYVdJ5nRANvs Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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: Mon, 24 Nov 2014 18:01:03 -0000 > I strongly support publication of this document as an Experimental RFC. However, my previous caveat still stands: as far as I'm aware, you haven't published any experimental data that shows that this metric doesn't behave significantly worse than ETX. While this should not prevent publication as an *Experimental* RFC, it seriously reduces the interest of your work. -- Juliusz From nobody Mon Nov 24 22:16: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 180E71A7016; Mon, 24 Nov 2014 22:16:48 -0800 (PST) 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 hAbtReTOio8i; Mon, 24 Nov 2014 22:16:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 954D01A1B94; Mon, 24 Nov 2014 22:16:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125061646.15602.98469.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 22:16:46 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ew7uHJJku4bVZ3MZYtjBzaox7dA Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: [manet] Pete Resnick's No Record on draft-ietf-manet-ibs-03: (with COMMENT) 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, 25 Nov 2014 06:16:48 -0000 Pete Resnick has entered the following ballot position for draft-ietf-manet-ibs-03: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm going to hang back until the telechat. Having read the thread on Stephen's DISCUSS, I don't have enough information to determine what I should ballot. From nobody Mon Nov 24 23:34: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 8B51F1A0025 for ; Mon, 24 Nov 2014 23:34:26 -0800 (PST) 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 z9dnicLFHrxw for ; Mon, 24 Nov 2014 23:34:24 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c: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 A931E1A0006 for ; Mon, 24 Nov 2014 23:34:23 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so31240wgh.27 for ; Mon, 24 Nov 2014 23:34:22 -0800 (PST) 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=5AK6sLvBbqw8Xs1zm6f5K3ISWKg+EpMF/wBenle3UM8=; b=HMKJudXlWLxvFOIu4VCnA2yawaBUpZtQcQ9k2lkTP2blKtW0qYKBQUjohziFov1+Ty ijaWIEVjPDo23R4YSPSSXSP1pTHZpSNi9wnBlUDPpMikeYIqOT+ojKo1jhm8C+0LXaVr q7Pjr8a78EOMh7NcK61f1+SJ5+lLlVhh2+aobQNZQUpTiwDAY3l5EAEfHZSmixALarfo /Vkcq2qTjKOTRlV8MFnfmZm7t5Wo0vk8XRna90xYGkMpCrWOA7hfPYt1S2At6n2J0dqq U8ZUZXPWxShsd+qPNVWLOBQPwMlPvRCuWOFJDTl/Z0+GewnXoOvv3e2p1dgwMnN5/uMM MAaw== X-Received: by 10.180.187.234 with SMTP id fv10mr29378970wic.25.1416900862519; Mon, 24 Nov 2014 23:34:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.8.75 with HTTP; Mon, 24 Nov 2014 23:34:02 -0800 (PST) In-Reply-To: <87ppcco5eg.wl-jch@pps.univ-paris-diderot.fr> References: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> <87ppcco5eg.wl-jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Tue, 25 Nov 2014 08:34:02 +0100 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bdlhcTRwtRsyCCFRFYqwHZvXRNU Cc: MANET IETF Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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, 25 Nov 2014 07:34:26 -0000 Hi Juliusz, thank you for the quick review! On Mon, Nov 24, 2014 at 6:49 PM, Juliusz Chroboczek wrote: > I strongly support publication of this document as an Experimental RFC. > > Minor nits follow. > > > 1. Introduction > > The introduction seems to imply that DAT is preferable to ETX ("less > efficient than in the past, which is one reason to move to a different > metric"). I don't understand that -- it is my feeling that DAT is just > a variant of ETX that's easier to implement. If you stand by your claim, > then that deserves more discussion. Are you talking about ETT? Because ETX doesn't include the link speed. We already had the situation in a few of community mesh networks where they had to cut a few long range links... they were low speed (2 MBit/s in the example I remember) but had no packet loss. And ETX was concentrating traffic on these links instead of going through a series of high-speed links (also without packet loss). So I think there is no question that a link-speed based metric is better than ETX. > 3. Applicability Statement > > Please clarify what happens when 8 packets in a row are lost. Is the link > dropped, or will it be used as the least-preferred link? (The latter, > judging from 10.2.5.2.) 8 packets in a row get lost? The packet loss algorithm described does only care about the total number of received/lost packets in the measurement period. If you loose more than 7/8 of them (regardless of the number), the "packet loss" part of the metric will go to the highest value. Dropping links is not the job of the metric, its the job of the validity timeout and the link hysteresis. > (FWIW, experimental data indicate that 802.11 remains useful when 7/8 > packets are lost, pre-ARQ -- so your "7 or 8" is a little close for > comfort.) I think the change to 7/8 came from a discussion with you. With 7/8 packet loss you will loose ~ 50% of your packets even after ARQ, which should nearly kill every TCP connection. I don't think it makes much sense to measure how much worse than 7/8 loss you are. Its just "worst link packet loss while still alive". > 4. Rationale > > "The Directional Airtime Metric measures the incoming loss rate". This is > the loss rate in the "wrong" direction -- it's the loss rate in the > outgoing direction that we're interested in. Please have a look at http://tools.ietf.org/html/rfc7181#section-8.1 " L_in_metric will be specified by a process that is external to this specification..." The job of the metric is to calculate the cost of the incoming links. > I agree with you that this > approximation gives reasonable results when combined with bidirectional > reachability detection (or whatever it is called in NHDP), but this > deserves some more discussion. OLSRv2 use directional metrics, it doesn't combine incoming and outgoing metric. > 5. Metric Functioning & Overview > > You're speaking about "packet loss", it is not clear that you measure > packet loss for protocol packets only. I will adapt the text in chapter 3 now that the "option A, B, C" for packet loss gathering is gone. Thank you for finding this. > It may be worth restating that > that protocol packets are always sent over multicast (is that correct?). OLSRv2/NHDP control traffic is normally done over multicast, but I know that people have used unicast for OLSRv1 directional point to point links. Not sure if we need to mention this. > 6. Protocol Paremeters > > "Two routers with different values..." The consequences of this are not > clear. What happens if routers are configured with different parameters? > Will the network collapse, or will you merely end up with sub-optimal > routing choices? (I understand it's the latter, correct?) > > "DAT_HELLO_TIMEOUT_FACTOR = 1.2". I'm using 1.5 in Babel, which gives > more margin for late packets while still reliably avoiding mistaking the > next hello for the previous one. I have no really strong opinion on this... I think the value was 1.5 in an earlier document but got reduced later. 1.5 might be too large if you use a 25% jitter... Jitter always decrease the interval between messages, so you could get two Hellos within 1.5 Hello-intervals. > 8. Data structures > > I don't think that citing DLEP is useful here, it only adds confusion by > implying that this specification is dependent on DLEP. DLEP is one potential source for the incoming bitrate, so I think its worth mentioning here. > Why are you using L_DAT_rx_bitrate instead of the tx bitrate? (Given that > you only have packet loss in the "wrong" direction, it's not clear to me > whether you should be using link speed in the "right" or in the "wrong" > direction; more discussion would be welcome.) Because I calculate incoming link metric. > 9.2 > > Should a router using this metric ensure that there is a Hello in each > packet it sends? Or would the cost be prohibitive? > > (FWIW, Babel doesn't make that requirement, but it only measures packet > loss for packets containing a Hello.) Not necessary, because every RFC5444 packet can contain a packet sequence number. > 9.3 Link Loss Gathering > > "SHOULD be carried out". Why SHOULD? Yes, if the packet does not contain a packet sequence number of you are unable to get the packet sequence number, you don't need to do it. The algorithm will automatically fall back to a "hello timeout based" packet loss estimation. Maybe we could say it like "If the packet contains a packet sequence number, it MUST be processed this way" ? > "packets without packet sequence number MUST NOT be processed". Why not? > I'd say that if you have either INTERVAL_TIME or seqno, than you can > manage. If you have neither, then you're out of luck, of course. At any > rate, this MUST NOT seems to contradict the stand you're taking in 9.2. > More discussion would be welcome You are mixing up Hello (message) processing with packet sequence number processing. The packet header does not contain INTERVAL_TIME or VALIDITY_TIME TVLs. > Step 2.3. What happens when L_DAT_last_pkt_seqno = pkt_seqno? Should you > be dealing with this case specially? Especially if you take into account > my suggestion in 10.1 below. Normally this would be an implementation bug, because the packet sequence number should be increased for every sent packet. We could add a check for this, but I am not sure it would really help. > (FWIW, in Babel we treat specially the case where pkg_seqno is between > L_DAT_last_pkt_seqno - 15 and L_DAT_last_pkt_seqno -- we "undo history" > in that case.) The algorithm does not store which sequence numbers were received and which not, so it could not undo the history. Sequence number going backward for a few numbers would be considered a jump of 6553x forward. > Step 2.3. This case deserves further comments. It implies that the > neighbouring router has rebooted (since an extended outage would have > caused your various timers to trigger); is it justified to keep the > statistics, or should the whole state for this neighbour be reset? (No > objection to keeping the current behaviour, just make it clear what's > going on here.) I think its worth keeping the statistic... the whole thing happened within a Hello Validity time (otherwise the link tuple would have been removed), so the data is still valid. > 10.1 > > Shouldn't you be incrementing L_DAT_last_pkt_seqno? (It doesn't matter > much, since you'll reset the value the next time you receive a Hello, but > you've concluded that you've lost a packet, so you might as well reflect > it. Doing this, however, implies further complexity in step 2.3 of 9.3.) No. This function does two jobs... if you have a neighbor that does not deliver packet sequence numbers (or you just cannot receive them), it will count a Hello-timeout as a packet loss. if you have a neighbor that DOES deliver packet sequence numbers, you count the Hello-timeout events since the last received packet. It is used to estimate the loss, but this estimation is instantly removed when you receive the next packet. Henning Rogge From nobody Tue Nov 25 08:56: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 6C3001ACD23; Tue, 25 Nov 2014 08:56:30 -0800 (PST) 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 AN600usSWw1S; Tue, 25 Nov 2014 08:56:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 097511A8035; Tue, 25 Nov 2014 08:56:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125165628.21623.63509.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 08:56:28 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NS8kPwwoP3P8ZfYAHWqOZZX4D9g Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org Subject: [manet] Pete Resnick's No Objection on draft-ietf-manet-ibs-03: (with COMMENT) 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, 25 Nov 2014 16:56:30 -0000 Pete Resnick has entered the following ballot position for draft-ietf-manet-ibs-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sounds like there is a path forward for Stephen's DISCUSS, so I will not object and let him handle the resolution. From nobody Tue Nov 25 11:02: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 23CC81ACEDE for ; Tue, 25 Nov 2014 11:00:14 -0800 (PST) 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 dQUPe8nyTpH7; Tue, 25 Nov 2014 11:00:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7F91ACEE3; Tue, 25 Nov 2014 11:00:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, T.Clausen@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125190005.14878.25269.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:00:05 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aJl9lfoM2uUDGo2I2t_14RKEkgI Subject: [manet] ID Tracker State Update Notice: 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, 25 Nov 2014 19:00:14 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ From nobody Tue Nov 25 12:48: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 2A9581A1A33 for ; Tue, 25 Nov 2014 12:46:41 -0800 (PST) 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 J8vt2j66DiAE for ; Tue, 25 Nov 2014 12:46:39 -0800 (PST) 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 BA8D31A88D3 for ; Tue, 25 Nov 2014 12:46:21 -0800 (PST) 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 sAPKkJpx031842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Nov 2014 21:46:19 +0100 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 sAPKkJ9W003377; Tue, 25 Nov 2014 21:46:19 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E45ECD8D4; Tue, 25 Nov 2014 21:46:18 +0100 (CET) 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 JI9_FxzFDeby; Tue, 25 Nov 2014 21:46:17 +0100 (CET) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 671F4D8CF; Tue, 25 Nov 2014 21:46:17 +0100 (CET) Date: Tue, 25 Nov 2014 21:46:17 +0100 Message-ID: <871torovom.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: References: <20141124125651.10916.18205.idtracker@ietfa.amsl.com> <87ppcco5eg.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]); Tue, 25 Nov 2014 21:46:19 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 25 Nov 2014 21:46:19 +0100 (CET) X-Miltered: at korolev with ID 5474EA9B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5474EA9B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5474EA9B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5474EA9B.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 : 5474EA9B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5474EA9B.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/_5gb6HoF_k7zhRg-LHBR9mgcAbU Cc: MANET IETF Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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, 25 Nov 2014 20:46:41 -0000 >> The introduction seems to imply that DAT is preferable to ETX ("less >> efficient than in the past, which is one reason to move to a different >> metric"). I don't understand that -- it is my feeling that DAT is just >> a variant of ETX that's easier to implement. If you stand by your claim, >> then that deserves more discussion. > > Are you talking about ETT? Because ETX doesn't include the link speed. Yes, I meant ETT. I think you should rewrite this section to state that DAT is a simplified version of ETT, which is itself a significant improvement on ETX (at least for the 802.11 MAC). (Assuming you agree with this assessment, of course.) > You are mixing up Hello (message) processing with packet sequence > number processing. Yes, I am. Sorry for that. Henning, I've looked through all of my comments in light of your clarifications -- your answers are very helpful. I think that all of them should be part of the draft. In particular, I believe you need to clarify: - how the incoming metric is the right thing due to 7181; - that you rely on only measuring loss over multicast; - that it's not the metric's job to drop associations; - how you "automatically" fall back to timeout-based computation; - how seqno resets don't require discarding all statistics. -- Juliusz From nobody Wed Nov 26 17:37: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 3707F1A6FD2; Wed, 26 Nov 2014 17:37:48 -0800 (PST) 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 ho0KvcwO0f0D; Wed, 26 Nov 2014 17:37:47 -0800 (PST) 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 E288A1A00A2; Wed, 26 Nov 2014 17:37:46 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id w8so2699730qac.37 for ; Wed, 26 Nov 2014 17:37:45 -0800 (PST) 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=K1txkOHNTYyw/v8MDDcIy2viig/PnrUj6oWcLHAq02s=; b=bZymAbloXuc/9X5woJZfoFeE54iDYosGOldW1BfKiIT47damgVXEwXqsVOM30Fpc85 Mszwzd5kPRaF1kY2ynz53YZ8pKGYVdIMrGGkSBIdWvvLCaPuFLBFHbBRCvePzaWHE7HT 9mV1VKjDJJ4RplhFfhwxjfgRJkG6NfGsqLQYmnRoCrxvmIETLfg/Kn5n9ln9mqokRpI4 jyLCRZVoj2XpYV1PPsscQn/d8ahlv5MjKNn3Q5EWTC0JjhYfPgEndNORgiUvmeyPGJXy 8n713fq+Cx9DtKjK5xf8SjxESPscGvR4uaIdfHepOlCVbDNIrNAI1P18eT2F3b1atd8x /tPA== MIME-Version: 1.0 X-Received: by 10.224.53.132 with SMTP id m4mr49978365qag.85.1417052265885; Wed, 26 Nov 2014 17:37:45 -0800 (PST) Received: by 10.140.98.212 with HTTP; Wed, 26 Nov 2014 17:37:45 -0800 (PST) In-Reply-To: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 17:37:45 -0800 Message-ID: From: Abdussalam Baryun To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cw4OGy_vacS0mlKMilYYBNQGHN0 Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-ibs.all@tools.ietf.org, manet@ietf.org, The IESG , T.Clausen@computer.org Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 01:37:48 -0000 On 11/24/14, Stephen Farrell wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > (2) How does a router get its private key? Why is it ok to > not specify that? Seems like an interop fail if that is not > done. > Agree, that is important in the dynamic MANET, however, in MANET our routers are able to be moving very fast so joining groups and leaving in essential. The problem with our MANETs in this group is the management, our draft regarding management is still slow in its process. I rememebr asking Robert the author of the management draft but still did not get a respond. The protocol management issue was discussed in this WG, but was not taked forward (or even followed up) by the WG managers. I suggest that IETF WGs managers/Chairs look into open issues-discussed and link them into our drafts. We repeat our questions many times in our WGs and sometimes we will get IESG mention what we discussed but we still did not solve. I suggest we start to solve this protocol management issue in this draft, so we need to discuss how each router can get the key or even when the key can be changed. Our we make up the conditions that makes a router get the key and when it can change it to another. AB From nobody Thu Nov 27 05:54: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 9EB951A8924; Thu, 27 Nov 2014 05:54:27 -0800 (PST) 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 VRfycwdigDNA; Thu, 27 Nov 2014 05:54:26 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD9C1A891A; Thu, 27 Nov 2014 05:54:25 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so15834851wid.9 for ; Thu, 27 Nov 2014 05:54:24 -0800 (PST) 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=Rl7ey9RWhYLUdw+IDH45577a9EFMYJi6TZjjufNr7jE=; b=Y4C9rCRtkQ9pjCBH0Zk/NFXWF1W3iuAFfHW5pbLzqoDrNrmowoHWYT7Jr9HUsY7mAF 2a/oCoS+hqyQwpoFMOGUKbahEJcFT6/HFVePzj8WGs/0OT8AdoOSrI4qT7AHBlESrUJq ROcpKfN1+m3TIx3ObEQwmLE8/0huesVeGYKQHridghIBKKBwj7eEmgSEOTDVFuC0Msmr Yem0K5vWxyXfdS7VejzJIwp4jKEuIkl99QQ0+BQaZWhXgYFGHoDNn60Y+ZekSA0sTg+g NPdkWeTAItGkb8zpz0GAzq3hXHoC5j0gCK8JbHed5gHtgFZxiQBAlmyUSmkz5bROpNJi /eJA== MIME-Version: 1.0 X-Received: by 10.180.78.225 with SMTP id e1mr30930327wix.32.1417096464674; Thu, 27 Nov 2014 05:54:24 -0800 (PST) Sender: yi.jiazi@gmail.com Received: by 10.194.54.74 with HTTP; Thu, 27 Nov 2014 05:54:24 -0800 (PST) In-Reply-To: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> Date: Thu, 27 Nov 2014 14:54:24 +0100 X-Google-Sender-Auth: wd_X4cTafV90haMTIdqzihbeFn0 Message-ID: From: Jiazi YI To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=f46d043c086463b6200508d77b21 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0GrrcYfSpz3oTqgGQfu-lv-f7iw Cc: Thomas Clausen , manet , draft-ietf-manet-ibs.all@tools.ietf.org, The IESG , "" , Stephen Farrell Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 13:54:27 -0000 --f46d043c086463b6200508d77b21 Content-Type: text/plain; charset=UTF-8 I think the key distribution is an important (and hard, especially if there is no centralised CA) issue for MANET. I believe it's better to have it discussed in a separate document, rather than in this draft. Solving the management issue is even out of the scope. best Jiazi On Thu, Nov 27, 2014 at 2:37 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > On 11/24/14, Stephen Farrell wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > > (2) How does a router get its private key? Why is it ok to > > not specify that? Seems like an interop fail if that is not > > done. > > > > Agree, that is important in the dynamic MANET, however, in MANET our > routers are able to be moving very fast so joining groups and leaving > in essential. The problem with our MANETs in this group is the > management, our draft regarding management is still slow in its > process. I rememebr asking Robert the author of the management draft > but still did not get a respond. The protocol management issue was > discussed in this WG, but was not taked forward (or even followed up) > by the WG managers. I suggest that IETF WGs managers/Chairs look into > open issues-discussed and link them into our drafts. We repeat our > questions many times in our WGs and sometimes we will get IESG mention > what we discussed but we still did not solve. > > I suggest we start to solve this protocol management issue in this > draft, so we need to discuss how each router can get the key or even > when the key can be changed. Our we make up the conditions that makes > a router get the key and when it can change it to another. > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d043c086463b6200508d77b21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the key distribution is an important (and hard, es= pecially if there is no centralised CA) issue for MANET.=C2=A0
I believ= e it's better to have it discussed in a separate document, rather than = in this draft.=C2=A0
Solving the management issue is even out of = the scope.=C2=A0

best

Jia= zi

On T= hu, Nov 27, 2014 at 2:37 AM, Abdussalam Baryun <abdussalambaryun@= gmail.com> wrote:
On 11/24= /14, Stephen Farrell <steph= en.farrell@cs.tcd.ie> wrote:
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
>
> (2) How does a router get its private key? Why is it ok to
> not specify that? Seems like an interop fail if that is not
> done.
>

Agree, that is important in the dynamic MANET, however, in MANET our=
routers are able to be moving very fast so joining groups and leaving
in essential. The problem with our MANETs in this group is the
management, our draft regarding management is still slow in its
process. I rememebr asking Robert the author of the management draft
but still did not get a respond. The protocol management issue was
discussed in this WG, but was not taked forward (or even followed up)
by the WG managers. I suggest that IETF WGs managers/Chairs look into
open issues-discussed and link them into our drafts. We repeat our
questions many times in our WGs and sometimes we will get IESG mention
what we discussed but we still did not solve.

I suggest we start to solve this protocol management issue in this
draft, so we need to discuss how each router can get the key or even
when the key can be changed. Our we make up the conditions that makes
a router get the key and when it can change it to another.

AB

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

--f46d043c086463b6200508d77b21-- From nobody Thu Nov 27 07:25: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 706851A002A; Thu, 27 Nov 2014 07:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8MzguRTp8Ks; Thu, 27 Nov 2014 07:24:50 -0800 (PST) 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 8734D1A0027; Thu, 27 Nov 2014 07:24:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,470,1413241200"; d="scan'208,217";a="500973295" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Nov 2014 15:24:37 +0000 X-IronPort-AV: E=Sophos; i="5.07,470,1413241200"; d="scan'208,217"; a="73793566" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 27 Nov 2014 15:24:36 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Thu, 27 Nov 2014 15:24:35 +0000 From: "Dearlove, Christopher (UK)" To: Jiazi YI , Abdussalam Baryun Thread-Topic: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) Thread-Index: AQHQCeLInYKKBNdqeUuFkuMkT/P2HZx0f4cAgAAY/uA= Date: Thu, 27 Nov 2014 15:24:35 +0000 Message-ID: References: <20141124114741.21325.47396.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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA2EFGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8jG62TaP1LhlA1fMuCkJDHLEh3k Cc: Thomas Clausen , manet , "draft-ietf-manet-ibs.all@tools.ietf.org" , The IESG , "" , Stephen Farrell Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 15:24:53 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA2EFGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SW4gcGFydGljdWxhciwgYWxsIHRoZSBhcmd1bWVudHMgdGhhdCBrZXB0IGtleSBtYW5hZ2VtZW50 IG91dCBvZiBSRkMgNzE4MiBhcHBseSBlcXVhbGx5IHdlbGwgaGVyZS4NCg0KLS0NCkNocmlzdG9w aGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1 cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMg Q2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3Qg SGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsN ClRlbDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+ IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykg TGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFy bmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwg VUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZyb206IG1h bmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppYXppIFlJ DQpTZW50OiAyNyBOb3ZlbWJlciAyMDE0IDEzOjU0DQpUbzogQWJkdXNzYWxhbSBCYXJ5dW4NCkNj OiBUaG9tYXMgQ2xhdXNlbjsgbWFuZXQ7IGRyYWZ0LWlldGYtbWFuZXQtaWJzLmFsbEB0b29scy5p ZXRmLm9yZzsgVGhlIElFU0c7IDxtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBTdGVwaGVu IEZhcnJlbGwNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1tYW5ldC1pYnMtMDM6ICh3aXRoIERJU0NVU1MpDQoNCg0KKioqIFdBUk5J TkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNh dGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpD b25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywg b3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5n IFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2 ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91 IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNz PGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nw b3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5w ZGY+Lg0KSSB0aGluayB0aGUga2V5IGRpc3RyaWJ1dGlvbiBpcyBhbiBpbXBvcnRhbnQgKGFuZCBo YXJkLCBlc3BlY2lhbGx5IGlmIHRoZXJlIGlzIG5vIGNlbnRyYWxpc2VkIENBKSBpc3N1ZSBmb3Ig TUFORVQuDQpJIGJlbGlldmUgaXQncyBiZXR0ZXIgdG8gaGF2ZSBpdCBkaXNjdXNzZWQgaW4gYSBz ZXBhcmF0ZSBkb2N1bWVudCwgcmF0aGVyIHRoYW4gaW4gdGhpcyBkcmFmdC4NClNvbHZpbmcgdGhl IG1hbmFnZW1lbnQgaXNzdWUgaXMgZXZlbiBvdXQgb2YgdGhlIHNjb3BlLg0KDQpiZXN0DQoNCkpp YXppDQoNCk9uIFRodSwgTm92IDI3LCAyMDE0IGF0IDI6MzcgQU0sIEFiZHVzc2FsYW0gQmFyeXVu IDxhYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbTxtYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFp bC5jb20+PiB3cm90ZToNCk9uIDExLzI0LzE0LCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+PiB3cm90ZToN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+ICgy KSBIb3cgZG9lcyBhIHJvdXRlciBnZXQgaXRzIHByaXZhdGUga2V5PyBXaHkgaXMgaXQgb2sgdG8N Cj4gbm90IHNwZWNpZnkgdGhhdD8gU2VlbXMgbGlrZSBhbiBpbnRlcm9wIGZhaWwgaWYgdGhhdCBp cyBub3QNCj4gZG9uZS4NCj4NCg0KQWdyZWUsIHRoYXQgaXMgaW1wb3J0YW50IGluIHRoZSBkeW5h bWljIE1BTkVULCBob3dldmVyLCBpbiBNQU5FVCBvdXINCnJvdXRlcnMgYXJlIGFibGUgdG8gYmUg bW92aW5nIHZlcnkgZmFzdCBzbyBqb2luaW5nIGdyb3VwcyBhbmQgbGVhdmluZw0KaW4gZXNzZW50 aWFsLiBUaGUgcHJvYmxlbSB3aXRoIG91ciBNQU5FVHMgaW4gdGhpcyBncm91cCBpcyB0aGUNCm1h bmFnZW1lbnQsIG91ciBkcmFmdCByZWdhcmRpbmcgbWFuYWdlbWVudCBpcyBzdGlsbCBzbG93IGlu IGl0cw0KcHJvY2Vzcy4gSSByZW1lbWViciBhc2tpbmcgUm9iZXJ0IHRoZSBhdXRob3Igb2YgdGhl IG1hbmFnZW1lbnQgZHJhZnQNCmJ1dCBzdGlsbCBkaWQgbm90IGdldCBhIHJlc3BvbmQuIFRoZSBw cm90b2NvbCBtYW5hZ2VtZW50IGlzc3VlIHdhcw0KZGlzY3Vzc2VkIGluIHRoaXMgV0csIGJ1dCB3 YXMgbm90IHRha2VkIGZvcndhcmQgKG9yIGV2ZW4gZm9sbG93ZWQgdXApDQpieSB0aGUgV0cgbWFu YWdlcnMuIEkgc3VnZ2VzdCB0aGF0IElFVEYgV0dzIG1hbmFnZXJzL0NoYWlycyBsb29rIGludG8N Cm9wZW4gaXNzdWVzLWRpc2N1c3NlZCBhbmQgbGluayB0aGVtIGludG8gb3VyIGRyYWZ0cy4gV2Ug cmVwZWF0IG91cg0KcXVlc3Rpb25zIG1hbnkgdGltZXMgaW4gb3VyIFdHcyBhbmQgc29tZXRpbWVz IHdlIHdpbGwgZ2V0IElFU0cgbWVudGlvbg0Kd2hhdCB3ZSBkaXNjdXNzZWQgYnV0IHdlIHN0aWxs IGRpZCBub3Qgc29sdmUuDQoNCkkgc3VnZ2VzdCB3ZSBzdGFydCB0byBzb2x2ZSB0aGlzIHByb3Rv Y29sIG1hbmFnZW1lbnQgaXNzdWUgaW4gdGhpcw0KZHJhZnQsIHNvIHdlIG5lZWQgdG8gZGlzY3Vz cyBob3cgZWFjaCByb3V0ZXIgY2FuIGdldCB0aGUga2V5IG9yIGV2ZW4NCndoZW4gdGhlIGtleSBj YW4gYmUgY2hhbmdlZC4gT3VyIHdlIG1ha2UgdXAgdGhlIGNvbmRpdGlvbnMgdGhhdCBtYWtlcw0K YSByb3V0ZXIgZ2V0IHRoZSBrZXkgYW5kIHdoZW4gaXQgY2FuIGNoYW5nZSBpdCB0byBhbm90aGVy Lg0KDQpBQg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBv ciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA2EFGLKXM0002VGREEN_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JbiBwYXJ0aWN1bGFyLCBhbGwgdGhlIGFyZ3VtZW50cyB0aGF0IGtlcHQga2V5IG1hbmFn ZW1lbnQgb3V0IG9mIFJGQyA3MTgyIGFwcGx5IGVxdWFsbHkgd2VsbCBoZXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RvcGhlciBEZWFybG92ZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXA8YnI+DQpD b21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHk8YnI+ DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZTxicj4NCldlc3QgSGFubmlu Z2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUs8YnI+DQpU ZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7IEZheDogJiM0Mzs0NCAxMjQ1IDI0 MjEyNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj5jaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+DQogfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykg TGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcs IEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2 WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAxOTk2Njg3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+SmlhemkgWUk8YnI+DQo8Yj5TZW50OjwvYj4gMjcgTm92ZW1iZXIgMjAx NCAxMzo1NDxicj4NCjxiPlRvOjwvYj4gQWJkdXNzYWxhbSBCYXJ5dW48YnI+DQo8Yj5DYzo8L2I+ IFRob21hcyBDbGF1c2VuOyBtYW5ldDsgZHJhZnQtaWV0Zi1tYW5ldC1pYnMuYWxsQHRvb2xzLmll dGYub3JnOyBUaGUgSUVTRzsgJmx0O21hbmV0LWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDs7IFN0 ZXBoZW4gRmFycmVsbDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBTdGVwaGVuIEZh cnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbWFuZXQtaWJzLTAzOiAod2l0aCBESVNDVVNT KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6 Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+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+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgdGhlIGtleSBkaXN0cmlidXRpb24gaXMgYW4gaW1wb3J0YW50IChhbmQgaGFyZCwg ZXNwZWNpYWxseSBpZiB0aGVyZSBpcyBubyBjZW50cmFsaXNlZCBDQSkgaXNzdWUgZm9yIE1BTkVU LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVs aWV2ZSBpdCdzIGJldHRlciB0byBoYXZlIGl0IGRpc2N1c3NlZCBpbiBhIHNlcGFyYXRlIGRvY3Vt ZW50LCByYXRoZXIgdGhhbiBpbiB0aGlzIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29sdmluZyB0aGUgbWFuYWdlbWVudCBp c3N1ZSBpcyBldmVuIG91dCBvZiB0aGUgc2NvcGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlc3Q8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Smlhemk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiAyNywgMjAx NCBhdCAyOjM3IEFNLCBBYmR1c3NhbGFtIEJhcnl1biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFiZHVz c2FsYW1iYXJ5dW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWJkdXNzYWxhbWJhcnl1bkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDExLzI0LzE0LCBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBESVNDVVNTOjxicj4NCiZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAoMikgSG93IGRv ZXMgYSByb3V0ZXIgZ2V0IGl0cyBwcml2YXRlIGtleT8gV2h5IGlzIGl0IG9rIHRvPGJyPg0KJmd0 OyBub3Qgc3BlY2lmeSB0aGF0PyBTZWVtcyBsaWtlIGFuIGludGVyb3AgZmFpbCBpZiB0aGF0IGlz IG5vdDxicj4NCiZndDsgZG9uZS48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KQWdyZWUsIHRoYXQgaXMg aW1wb3J0YW50IGluIHRoZSBkeW5hbWljIE1BTkVULCBob3dldmVyLCBpbiBNQU5FVCBvdXI8YnI+ DQpyb3V0ZXJzIGFyZSBhYmxlIHRvIGJlIG1vdmluZyB2ZXJ5IGZhc3Qgc28gam9pbmluZyBncm91 cHMgYW5kIGxlYXZpbmc8YnI+DQppbiBlc3NlbnRpYWwuIFRoZSBwcm9ibGVtIHdpdGggb3VyIE1B TkVUcyBpbiB0aGlzIGdyb3VwIGlzIHRoZTxicj4NCm1hbmFnZW1lbnQsIG91ciBkcmFmdCByZWdh cmRpbmcgbWFuYWdlbWVudCBpcyBzdGlsbCBzbG93IGluIGl0czxicj4NCnByb2Nlc3MuIEkgcmVt ZW1lYnIgYXNraW5nIFJvYmVydCB0aGUgYXV0aG9yIG9mIHRoZSBtYW5hZ2VtZW50IGRyYWZ0PGJy Pg0KYnV0IHN0aWxsIGRpZCBub3QgZ2V0IGEgcmVzcG9uZC4gVGhlIHByb3RvY29sIG1hbmFnZW1l bnQgaXNzdWUgd2FzPGJyPg0KZGlzY3Vzc2VkIGluIHRoaXMgV0csIGJ1dCB3YXMgbm90IHRha2Vk IGZvcndhcmQgKG9yIGV2ZW4gZm9sbG93ZWQgdXApPGJyPg0KYnkgdGhlIFdHIG1hbmFnZXJzLiBJ IHN1Z2dlc3QgdGhhdCBJRVRGIFdHcyBtYW5hZ2Vycy9DaGFpcnMgbG9vayBpbnRvPGJyPg0Kb3Bl biBpc3N1ZXMtZGlzY3Vzc2VkIGFuZCBsaW5rIHRoZW0gaW50byBvdXIgZHJhZnRzLiBXZSByZXBl YXQgb3VyPGJyPg0KcXVlc3Rpb25zIG1hbnkgdGltZXMgaW4gb3VyIFdHcyBhbmQgc29tZXRpbWVz IHdlIHdpbGwgZ2V0IElFU0cgbWVudGlvbjxicj4NCndoYXQgd2UgZGlzY3Vzc2VkIGJ1dCB3ZSBz dGlsbCBkaWQgbm90IHNvbHZlLjxicj4NCjxicj4NCkkgc3VnZ2VzdCB3ZSBzdGFydCB0byBzb2x2 ZSB0aGlzIHByb3RvY29sIG1hbmFnZW1lbnQgaXNzdWUgaW4gdGhpczxicj4NCmRyYWZ0LCBzbyB3 ZSBuZWVkIHRvIGRpc2N1c3MgaG93IGVhY2ggcm91dGVyIGNhbiBnZXQgdGhlIGtleSBvciBldmVu PGJyPg0Kd2hlbiB0aGUga2V5IGNhbiBiZSBjaGFuZ2VkLiBPdXIgd2UgbWFrZSB1cCB0aGUgY29u ZGl0aW9ucyB0aGF0IG1ha2VzPGJyPg0KYSByb3V0ZXIgZ2V0IHRoZSBrZXkgYW5kIHdoZW4gaXQg Y2FuIGNoYW5nZSBpdCB0byBhbm90aGVyLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5BQjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4K cmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRo ZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLjxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA2EFGLKXM0002VGREEN_-- From nobody Thu Nov 27 07:28: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 DAF941A004B; Thu, 27 Nov 2014 07:28:01 -0800 (PST) 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 8zE7oHc_cEhY; Thu, 27 Nov 2014 07:27:59 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c: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 9761B1A0025; Thu, 27 Nov 2014 07:27:58 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so6739879wgh.9 for ; Thu, 27 Nov 2014 07:27:57 -0800 (PST) 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=Oz07x0GSplyVzyBLfcD9HxDQ9g4aAO0+TQMQHEZ6B8k=; b=Hli7ecC7FrBmbFTMvtvsdy4Wmdxf3Il6p1AaRfsyadMlxNYuf4xgMA2oIASGA2OlI0 So+qD1Pnnt8rxLV+ICzW+e/svEl11M7lRXrW4lOfNqnz48wAKkwFZraFl5Bi4kneohGD h09DO4NkttO5Q8G6m6btxwR6BiwP0Vo3v8yhpNq6DoHqRxWql5kILIbncFro6XErnIa5 wYemjZk2tEbeWPf5DZSeWMPnkmzEl+9qixhtHqka9rS80CTl8laQHI7BXbNyWgRzaoh3 XPmzBTWtG+MblozzZ7uq+lM8b21WTsQVPmPE9VlPPdDp5xUAFQnQMGGgWvPyzmssz1GS QZyw== X-Received: by 10.194.191.227 with SMTP id hb3mr61412255wjc.79.1417102077081; Thu, 27 Nov 2014 07:27:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.8.75 with HTTP; Thu, 27 Nov 2014 07:27:36 -0800 (PST) In-Reply-To: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Thu, 27 Nov 2014 16:27:36 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/M9DpQhVFJU9xBL1ejvFEiZEIRuU Cc: Thomas Clausen , manet , "draft-ietf-manet-ibs.all@tools.ietf.org" , "" , The IESG , Stephen Farrell Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 15:28:02 -0000 And lets not forget the type of key-management you need is highly dependent on the organization of your deployment, independently from the security mechanism (shared key/ibs) you use. If you just produce a bunch of nodes together and use them without touching them again, setting up static keys might be fine. If you want to add/remove nodes later, you will most likely need some complicated certificate based system. Deploy a community mesh without a central authority? Maybe you will need some "web of trust" style key management. Henning Rogge On Thu, Nov 27, 2014 at 4:24 PM, Dearlove, Christopher (UK) wrote: > In particular, all the arguments that kept key management out of RFC 7182 > apply equally well 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 > > > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi YI > Sent: 27 November 2014 13:54 > To: Abdussalam Baryun > Cc: Thomas Clausen; manet; draft-ietf-manet-ibs.all@tools.ietf.org; The > IESG; ; Stephen Farrell > Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: > (with DISCUSS) > > > > > > *** 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 think the key distribution is an important (and hard, especially if there > is no centralised CA) issue for MANET. > > I believe it's better to have it discussed in a separate document, rather > than in this draft. > > Solving the management issue is even out of the scope. > > > > best > > > > Jiazi > > > > On Thu, Nov 27, 2014 at 2:37 AM, Abdussalam Baryun > wrote: > > On 11/24/14, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> (2) How does a router get its private key? Why is it ok to >> not specify that? Seems like an interop fail if that is not >> done. >> > > Agree, that is important in the dynamic MANET, however, in MANET our > routers are able to be moving very fast so joining groups and leaving > in essential. The problem with our MANETs in this group is the > management, our draft regarding management is still slow in its > process. I rememebr asking Robert the author of the management draft > but still did not get a respond. The protocol management issue was > discussed in this WG, but was not taked forward (or even followed up) > by the WG managers. I suggest that IETF WGs managers/Chairs look into > open issues-discussed and link them into our drafts. We repeat our > questions many times in our WGs and sometimes we will get IESG mention > what we discussed but we still did not solve. > > I suggest we start to solve this protocol management issue in this > draft, so we need to discuss how each router can get the key or even > when the key can be changed. Our we make up the conditions that makes > a router get the key and when it can change it to another. > > AB > > > _______________________________________________ > 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 > From nobody Thu Nov 27 07:35: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 1042B1A006B for ; Thu, 27 Nov 2014 07:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqPpTCb0csz0 for ; Thu, 27 Nov 2014 07:34:58 -0800 (PST) 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 1B3821A002A for ; Thu, 27 Nov 2014 07:34:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,470,1413241200"; d="scan'208,217";a="500977452" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Nov 2014 15:34:47 +0000 X-IronPort-AV: E=Sophos; i="5.07,470,1413241200"; d="scan'208,217"; a="73795504" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 27 Nov 2014 15:34:47 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Thu, 27 Nov 2014 15:34:46 +0000 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: draft-ietf-manet-ibs-03 Thread-Index: AdAKV5SMp/UUudq6QlSi7SeVkquUQw== Date: Thu, 27 Nov 2014 15:34:45 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA318GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/skWVixtG_6_5gL7ZG9tSLnkkRxc Subject: [manet] draft-ietf-manet-ibs-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: Thu, 27 Nov 2014 15:35:01 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA318GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable draft-ietf-manet-ibs-03 has reached the IESG. It is, unfortunately, the subject of a DISCUSS by one of the SEC ADs. A DIS= CUSS that is going to be anywhere from hard to impossible to move. However = the rights and wrong of that are not what I'm discussing here. One route would be to go Experimental. Not my first choice, obviously, but = an option. What I'd like to know is who wants this (some people said so in the past, b= ut please say so again) and who cares about the Experimental/Proposed Stand= ard distinction. I know we have some issues over that some people here have customers who ma= y want this, but can't identify those customers, and other matters. But wha= t you can say would be useful. Oh, and if anyone happens to be able to show (as I'm told on good authority= is possible) that ECCSI security is a simple variation on ECDSA security, = that would be helpful. -- 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA318GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

draft-ietf-manet-ibs-03 has reached the IESG.

 

It is, unfortunately, the subject of a DISCUSS by on= e of the SEC ADs. A DISCUSS that is going to be anywhere from hard to impos= sible to move. However the rights and wrong of that are not what I’m = discussing here.

 

One route would be to go Experimental. Not my first = choice, obviously, but an option.

 

What I’d like to know is who wants this (some = people said so in the past, but please say so again) and who cares about th= e Experimental/Proposed Standard distinction.

 

I know we have some issues over that some people her= e have customers who may want this, but can’t identify those customer= s, and other matters. But what you can say would be useful.

 

Oh, and if anyone happens to be able to show (as I&#= 8217;m told on good authority is possible) that ECCSI security is a simple = variation on ECDSA security, that would be helpful.

 

-- <= /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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40DCA318GLKXM0002VGREEN_-- From nobody Thu Nov 27 07:46: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 DFD371A006D; Thu, 27 Nov 2014 07:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGB-UfkuNMps; Thu, 27 Nov 2014 07:46:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 50B721A0056; Thu, 27 Nov 2014 07:46:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3B752BED7; Thu, 27 Nov 2014 15:46:14 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2EwMwW4EDew; Thu, 27 Nov 2014 15:46:12 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.42.22.226]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 079AABED5; Thu, 27 Nov 2014 15:46:12 +0000 (GMT) Message-ID: <54774743.3070907@cs.tcd.ie> Date: Thu, 27 Nov 2014 15:46:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" , Jiazi YI , Abdussalam Baryun References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/sFMIV3hom2FQorl09olqALu7vCI Cc: "draft-ietf-manet-ibs.all@tools.ietf.org" , "" , manet , The IESG , Thomas Clausen Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 15:46:20 -0000 Actually that discuss point is about interop and not about security as in BCP107. If an IBS scheme is to be used then there is a need for different node/router vendors to work with the same KG/KMS and that needs to be specified for each IBS scheme and is missing here. Perhaps it is in some other or planned document? Absent that this scheme can only be used for homogeneous manets where the same vendor produces all the routers/nodes and the KG/KMS. For other cryptographic schemes, e.g. those using shared secrets or certs, we do have a number of ways of handling this, but IBS schemes are new and are handling new kinds of structed data (the private key and KG parameters) therefore ISTM he lack of that bit of specification will prevent interop. S. On 27/11/14 15:24, Dearlove, Christopher (UK) wrote: > In particular, all the arguments that kept key management out of RFC > 7182 apply equally well 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 > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi YI > Sent: 27 November 2014 13:54 To: Abdussalam Baryun Cc: Thomas > Clausen; manet; draft-ietf-manet-ibs.all@tools.ietf.org; The IESG; > ; Stephen Farrell Subject: Re: [manet] > Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) > > > *** 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 think the key distribution is an important (and hard, especially if > there is no centralised CA) issue for MANET. I believe it's better to > have it discussed in a separate document, rather than in this draft. > Solving the management issue is even out of the scope. > > best > > Jiazi > > On Thu, Nov 27, 2014 at 2:37 AM, Abdussalam Baryun > > > wrote: On 11/24/14, Stephen Farrell > > wrote: >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> (2) How does a router get its private key? Why is it ok to >> not specify that? Seems like an interop fail if that is not done. >> > > Agree, that is important in the dynamic MANET, however, in MANET our > routers are able to be moving very fast so joining groups and > leaving in essential. The problem with our MANETs in this group is > the management, our draft regarding management is still slow in its > process. I rememebr asking Robert the author of the management draft > but still did not get a respond. The protocol management issue was > discussed in this WG, but was not taked forward (or even followed > up) by the WG managers. I suggest that IETF WGs managers/Chairs look > into open issues-discussed and link them into our drafts. We repeat > our questions many times in our WGs and sometimes we will get IESG > mention what we discussed but we still did not solve. > > I suggest we start to solve this protocol management issue in this > draft, so we need to discuss how each router can get the key or even > when the key can be changed. Our we make up the conditions that > makes a router get the key and when it can change it to another. > > AB > > _______________________________________________ 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 Nov 27 07:53: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 BBF611A006D; Thu, 27 Nov 2014 07:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sYxDPR0NRl8; Thu, 27 Nov 2014 07:53:29 -0800 (PST) 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 8ABB61A0067; Thu, 27 Nov 2014 07:53:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,470,1413241200"; d="scan'208";a="423171413" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Nov 2014 15:53:26 +0000 X-IronPort-AV: E=Sophos;i="5.07,470,1413241200"; d="scan'208";a="82210151" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 27 Nov 2014 15:53:26 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.237]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Thu, 27 Nov 2014 15:53:25 +0000 From: "Dearlove, Christopher (UK)" To: Stephen Farrell , Jiazi YI , Abdussalam Baryun Thread-Topic: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) Thread-Index: AQHQCeLInYKKBNdqeUuFkuMkT/P2HZx0f4cAgAAY/uCAAAY+gIAAAHWw Date: Thu, 27 Nov 2014 15:53:24 +0000 Message-ID: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <54774743.3070907@cs.tcd.ie> In-Reply-To: <54774743.3070907@cs.tcd.ie> 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" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Xj0JQI0tkavFOh2ddMhQfPEr7HU Cc: "draft-ietf-manet-ibs.all@tools.ietf.org" , "" , manet , The IESG , Thomas Clausen Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 15:53:32 -0000 QWdhaW4sIEkgc2VlIG5vIGRpZmZlcmVuY2UgaGVyZSBmcm9tIHRoZSByZXN0IG9mIFJGQyA3MTgy LiBBcmd1bWVudHMgd2hpY2ggdGhlIElFU0cgaW5jbHVkaW5nIFN0ZXBoZW4gYWNjZXB0ZWQuDQoN CkkgYW0gYXdhcmUgb2YgYSBNSUtFWS1TQUtLRSBiYXNlZCBjZXJ0aWZpY2F0ZSBmb3JtYXQgdGhh dCBpbmNsdWRlcyBhbiBFQ0NTSSBrZXkgKGFuZCBvdGhlciBtYXRlcmlhbCksIGJ1dCBJIGRvbid0 IGtub3cgaWYgcHVibGlzaGVkIG9yIG5vdC4NCg0KQnV0IHNpbmNlIHRoaXMgdGhlIGxlYXN0IG9m IFN0ZXBoZW4ncyBvYmplY3Rpb25zLCBJJ20gbm90IGdvaW5nIHRvIHNwZW5kIGN5Y2xlcyBvbiB0 aGlzIG9uZSBhdCB0aGlzIHRpbWUuDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVu aWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lz dGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIx OTTCoHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMp IExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZh cm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUs IFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllXSANClNlbnQ6IDI3IE5vdmVtYmVyIDIwMTQgMTU6NDYNClRv OiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgSmlhemkgWUk7IEFiZHVzc2FsYW0gQmFyeXVu DQpDYzogVGhvbWFzIENsYXVzZW47IG1hbmV0OyBkcmFmdC1pZXRmLW1hbmV0LWlicy5hbGxAdG9v bHMuaWV0Zi5vcmc7IFRoZSBJRVNHOyA8bWFuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU3Vi amVjdDogUmU6IFttYW5ldF0gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LW1hbmV0LWlicy0wMzogKHdpdGggRElTQ1VTUykNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEg V0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg ZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBh cnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5 b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw bHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0 dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3Nh Z2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KQWN0dWFsbHkgdGhhdCBkaXNjdXNzIHBvaW50IGlzIGFib3V0IGludGVyb3AgYW5k IG5vdCBhYm91dCBzZWN1cml0eSBhcyBpbiBCQ1AxMDcuIElmIGFuIElCUyBzY2hlbWUgaXMgdG8g YmUgdXNlZCB0aGVuIHRoZXJlIGlzIGEgbmVlZCBmb3IgZGlmZmVyZW50IG5vZGUvcm91dGVyIHZl bmRvcnMgdG8gd29yayB3aXRoIHRoZSBzYW1lIEtHL0tNUyBhbmQgdGhhdCBuZWVkcyB0byBiZSBz cGVjaWZpZWQgZm9yIGVhY2ggSUJTIHNjaGVtZSBhbmQgaXMgbWlzc2luZyBoZXJlLiBQZXJoYXBz IGl0IGlzIGluIHNvbWUgb3RoZXIgb3IgcGxhbm5lZCBkb2N1bWVudD8gQWJzZW50IHRoYXQgdGhp cyBzY2hlbWUgY2FuIG9ubHkgYmUgdXNlZCBmb3IgaG9tb2dlbmVvdXMgbWFuZXRzIHdoZXJlIHRo ZSBzYW1lIHZlbmRvciBwcm9kdWNlcyBhbGwgdGhlIHJvdXRlcnMvbm9kZXMgYW5kIHRoZSBLRy9L TVMuDQoNCkZvciBvdGhlciBjcnlwdG9ncmFwaGljIHNjaGVtZXMsIGUuZy4gdGhvc2UgdXNpbmcg c2hhcmVkIHNlY3JldHMgb3IgY2VydHMsIHdlIGRvIGhhdmUgYSBudW1iZXIgb2Ygd2F5cyBvZiBo YW5kbGluZyB0aGlzLCBidXQgSUJTIHNjaGVtZXMgYXJlIG5ldyBhbmQgYXJlIGhhbmRsaW5nIG5l dyBraW5kcyBvZiBzdHJ1Y3RlZCBkYXRhICh0aGUgcHJpdmF0ZSBrZXkgYW5kIEtHIHBhcmFtZXRl cnMpIHRoZXJlZm9yZSBJU1RNIGhlIGxhY2sgb2YgdGhhdCBiaXQgb2Ygc3BlY2lmaWNhdGlvbiB3 aWxsIHByZXZlbnQgaW50ZXJvcC4NCg0KUy4NCg0KT24gMjcvMTEvMTQgMTU6MjQsIERlYXJsb3Zl LCBDaHJpc3RvcGhlciAoVUspIHdyb3RlOg0KPiBJbiBwYXJ0aWN1bGFyLCBhbGwgdGhlIGFyZ3Vt ZW50cyB0aGF0IGtlcHQga2V5IG1hbmFnZW1lbnQgb3V0IG9mIFJGQw0KPiA3MTgyIGFwcGx5IGVx dWFsbHkgd2VsbCBoZXJlLg0KPiANCj4gLS0gQ2hyaXN0b3BoZXIgRGVhcmxvdmUgU2VuaW9yIFBy aW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gDQo+IEFzc3VyYW5jZSBHcm91cCBDb21tdW5p Y2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkgDQo+IEJBRSBT eXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlIFdlc3QgSGFubmluZ2ZpZWxkIFJvYWQs IEdyZWF0IA0KPiBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLIFRlbDogKzQ0IDEyNDUg MjQyMTk0IHwNCj4gRmF4OiArNDQgMTI0NSAyNDIxMjQNCj4gY2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IA0KPiBodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tDQo+IA0KPiBCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGlt aXRlZCBSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gDQo+IEJveCA4NywgRmFy bmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwg VUsgDQo+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQo+IA0KPiBG cm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK aWF6aSBZSQ0KPiBTZW50OiAyNyBOb3ZlbWJlciAyMDE0IDEzOjU0IFRvOiBBYmR1c3NhbGFtIEJh cnl1biBDYzogVGhvbWFzIENsYXVzZW47IA0KPiBtYW5ldDsgZHJhZnQtaWV0Zi1tYW5ldC1pYnMu YWxsQHRvb2xzLmlldGYub3JnOyBUaGUgSUVTRzsgDQo+IDxtYW5ldC1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc+OyBTdGVwaGVuIEZhcnJlbGwgU3ViamVjdDogUmU6IFttYW5ldF0gDQo+IFN0ZXBoZW4g RmFycmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tYW5ldC1pYnMtMDM6ICh3aXRoIERJU0NV U1MpDQo+IA0KPiANCj4gKioqIFdBUk5JTkcgKioqIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZy b20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCANCj4gZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwg cGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQo+IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlv dSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSANCj4gYXR0YWNobWVudHMgb3Ig cmVwbHkuIEZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiAN Cj4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgDQo+IGhlcmU8aHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCj4NCj4gDQpJZiB5b3UgZmVlbCB0aGUg ZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQo+IEkg dGhpbmsgdGhlIGtleSBkaXN0cmlidXRpb24gaXMgYW4gaW1wb3J0YW50IChhbmQgaGFyZCwgZXNw ZWNpYWxseSBpZiANCj4gdGhlcmUgaXMgbm8gY2VudHJhbGlzZWQgQ0EpIGlzc3VlIGZvciBNQU5F VC4gSSBiZWxpZXZlIGl0J3MgYmV0dGVyIHRvIA0KPiBoYXZlIGl0IGRpc2N1c3NlZCBpbiBhIHNl cGFyYXRlIGRvY3VtZW50LCByYXRoZXIgdGhhbiBpbiB0aGlzIGRyYWZ0Lg0KPiBTb2x2aW5nIHRo ZSBtYW5hZ2VtZW50IGlzc3VlIGlzIGV2ZW4gb3V0IG9mIHRoZSBzY29wZS4NCj4gDQo+IGJlc3QN Cj4gDQo+IEppYXppDQo+IA0KPiBPbiBUaHUsIE5vdiAyNywgMjAxNCBhdCAyOjM3IEFNLCBBYmR1 c3NhbGFtIEJhcnl1biANCj4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPG1haWx0bzphYmR1 c3NhbGFtYmFyeXVuQGdtYWlsLmNvbT4+DQo+IHdyb3RlOiBPbiAxMS8yNC8xNCwgU3RlcGhlbiBG YXJyZWxsDQo+IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPj4gd3JvdGU6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+PiANCkRJ U0NVU1M6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+Pg0KPj4NCj4+IA0KKDIpIEhvdyBk b2VzIGEgcm91dGVyIGdldCBpdHMgcHJpdmF0ZSBrZXk/IFdoeSBpcyBpdCBvayB0bw0KPj4gbm90 IHNwZWNpZnkgdGhhdD8gU2VlbXMgbGlrZSBhbiBpbnRlcm9wIGZhaWwgaWYgdGhhdCBpcyBub3Qg ZG9uZS4NCj4+IA0KPiANCj4gQWdyZWUsIHRoYXQgaXMgaW1wb3J0YW50IGluIHRoZSBkeW5hbWlj IE1BTkVULCBob3dldmVyLCBpbiBNQU5FVCBvdXIgDQo+IHJvdXRlcnMgYXJlIGFibGUgdG8gYmUg bW92aW5nIHZlcnkgZmFzdCBzbyBqb2luaW5nIGdyb3VwcyBhbmQgbGVhdmluZyANCj4gaW4gZXNz ZW50aWFsLiBUaGUgcHJvYmxlbSB3aXRoIG91ciBNQU5FVHMgaW4gdGhpcyBncm91cCBpcyB0aGUg DQo+IG1hbmFnZW1lbnQsIG91ciBkcmFmdCByZWdhcmRpbmcgbWFuYWdlbWVudCBpcyBzdGlsbCBz bG93IGluIGl0cyANCj4gcHJvY2Vzcy4gSSByZW1lbWViciBhc2tpbmcgUm9iZXJ0IHRoZSBhdXRo b3Igb2YgdGhlIG1hbmFnZW1lbnQgZHJhZnQgDQo+IGJ1dCBzdGlsbCBkaWQgbm90IGdldCBhIHJl c3BvbmQuIFRoZSBwcm90b2NvbCBtYW5hZ2VtZW50IGlzc3VlIHdhcyANCj4gZGlzY3Vzc2VkIGlu IHRoaXMgV0csIGJ1dCB3YXMgbm90IHRha2VkIGZvcndhcmQgKG9yIGV2ZW4gZm9sbG93ZWQNCj4g dXApIGJ5IHRoZSBXRyBtYW5hZ2Vycy4gSSBzdWdnZXN0IHRoYXQgSUVURiBXR3MgbWFuYWdlcnMv Q2hhaXJzIGxvb2sgDQo+IGludG8gb3BlbiBpc3N1ZXMtZGlzY3Vzc2VkIGFuZCBsaW5rIHRoZW0g aW50byBvdXIgZHJhZnRzLiBXZSByZXBlYXQgDQo+IG91ciBxdWVzdGlvbnMgbWFueSB0aW1lcyBp biBvdXIgV0dzIGFuZCBzb21ldGltZXMgd2Ugd2lsbCBnZXQgSUVTRyANCj4gbWVudGlvbiB3aGF0 IHdlIGRpc2N1c3NlZCBidXQgd2Ugc3RpbGwgZGlkIG5vdCBzb2x2ZS4NCj4gDQo+IEkgc3VnZ2Vz dCB3ZSBzdGFydCB0byBzb2x2ZSB0aGlzIHByb3RvY29sIG1hbmFnZW1lbnQgaXNzdWUgaW4gdGhp cyANCj4gZHJhZnQsIHNvIHdlIG5lZWQgdG8gZGlzY3VzcyBob3cgZWFjaCByb3V0ZXIgY2FuIGdl dCB0aGUga2V5IG9yIGV2ZW4gDQo+IHdoZW4gdGhlIGtleSBjYW4gYmUgY2hhbmdlZC4gT3VyIHdl IG1ha2UgdXAgdGhlIGNvbmRpdGlvbnMgdGhhdCBtYWtlcyANCj4gYSByb3V0ZXIgZ2V0IHRoZSBr ZXkgYW5kIHdoZW4gaXQgY2FuIGNoYW5nZSBpdCB0byBhbm90aGVyLg0KPiANCj4gQUINCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIG1hbmV0IG1h aWxpbmcgbGlzdCANCj4gbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+IA0KPiAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0 byB0aGUgaW50ZW5kZWQgDQo+IHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIA0KPiByZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBp dCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCj4gWW91IHNob3VsZCBu b3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvciANCj4g ZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCj4gKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCj4gDQo= From nobody Thu Nov 27 07:55: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 3DCF31A00A7; Thu, 27 Nov 2014 07:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fJ4BmMY1DRC; Thu, 27 Nov 2014 07:55:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F13F11A009E; Thu, 27 Nov 2014 07:55:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20AACBEBF; Thu, 27 Nov 2014 15:55:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qau_sd6pTFSQ; Thu, 27 Nov 2014 15:55:05 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.42.22.226]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CF26ABEB3; Thu, 27 Nov 2014 15:55:04 +0000 (GMT) Message-ID: <54774958.3060308@cs.tcd.ie> Date: Thu, 27 Nov 2014 15:55:04 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" , Jiazi YI , Abdussalam Baryun References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> <54774743.3070907@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xViK6V4gS03BaaZgpiOEgVKY-fc Cc: "draft-ietf-manet-ibs.all@tools.ietf.org" , "" , manet , The IESG , Thomas Clausen Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 27 Nov 2014 15:55:08 -0000 On 27/11/14 15:53, Dearlove, Christopher (UK) wrote: > Again, I see no difference here from the rest of RFC 7182. Arguments > which the IESG including Stephen accepted. > > I am aware of a MIKEY-SAKKE based certificate format that includes an > ECCSI key (and other material), but I don't know if published or > not. > > But since this the least of Stephen's objections, I'm not going to > spend cycles on this one at this time. Fair enough. I do however see a difference vs. 7182 but maybe I'm not explaining it well. We can get to it when you're ready. S. > From nobody Thu Nov 27 17:29: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 4D69E1A0387 for ; Thu, 27 Nov 2014 17:29:16 -0800 (PST) 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 YwYDKUzNzkEi for ; Thu, 27 Nov 2014 17:29:14 -0800 (PST) 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 8CE991A0270 for ; Thu, 27 Nov 2014 17:29:14 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so4316989qcx.27 for ; Thu, 27 Nov 2014 17:29:13 -0800 (PST) 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=H36XpkFAIgPAirpl7M8yH0zE7rKp6GYYMOK8Ws5Owmk=; b=xrDvvxv5y50JaL61iJXEXVBWJbPoKA0kjFLw7FcAVT8gzYlQGX09vD8xAm9au+TZBc IUOKj7GJGsFVfncc2vFktHrRv3sWQDeqPtCCK4+cF7bNaYpxlQtOPXJQvtjxJPqpSad4 HOUnHXs15pYlNuRXsNtASwcDrNcDNrDHj/9xWHN2LK/023Bfk4t/tRRUU7dr4H83Yloz 51kRwfxzFGN8HHUdZrfprq1iP+/fpZmYZfR8PGTN8psalHWYq6Z07OiVdD72iTnRqJ5J 85GN4FR/DI+olp/EZw3alwmI9cEaispWl1GTK7xA5WqYxKfV4w5s91xCzgZta+K7T4rx wJqw== MIME-Version: 1.0 X-Received: by 10.229.224.201 with SMTP id ip9mr57779312qcb.5.1417138153715; Thu, 27 Nov 2014 17:29:13 -0800 (PST) Received: by 10.140.98.212 with HTTP; Thu, 27 Nov 2014 17:29:13 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Nov 2014 17:29:13 -0800 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1135ef1e3fff070508e13022 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JfjHE1MwotJ5Ut5Izv4w8yTzq2c Cc: "manet@ietf.org" Subject: Re: [manet] draft-ietf-manet-ibs-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: Fri, 28 Nov 2014 01:29:16 -0000 --001a1135ef1e3fff070508e13022 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, November 27, 2014, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > draft-ietf-manet-ibs-03 has reached the IESG. > > > > It is, unfortunately, the subject of a DISCUSS by one of the SEC ADs. A > DISCUSS that is going to be anywhere from hard to impossible to move. > However the rights and wrong of that are not what I=E2=80=99m discussing = here. > We need to follow the IETF process, but the editors should consider the AD discuss to update the draft, we want better draft output. I agree with AD discuss for this draft, and not sure why the editors see impossible move to update draft. On Thursday, November 27, 2014, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > > What I=E2=80=99d like to know is who wants this (some people said so in t= he past, > but please say so again) and who cares about the Experimental/Proposed > Standard distinction. > I think we all should care. It is important to have experimental when the draft is not ready. > > > I know we have some issues over that some people here have customers who > may want this, but can=E2=80=99t identify those customers, and other matt= ers. But > what you can say would be useful. > IMHO, IETF is not about publishing what some customers want, but publishing what WG-engineers want to fulfil all world customers or all internet community users. Some customers should not drive the IETF or its WGs. AB --001a1135ef1e3fff070508e13022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, November 27, 2014, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com<= /a>> wrote:

draft-ietf-manet-ibs-03 has reached the IESG.=

=C2=A0

It is, unfortunately, the subject of a DISCUSS by on= e of the SEC ADs. A DISCUSS that is going to be anywhere from hard to impos= sible to move. However the rights and wrong of that are not what I=E2=80=99= m discussing here.

We need t= o follow the IETF process, but the editors should consider the AD discuss t= o update the draft, we want better draft output.=C2=A0=C2=A0I agree with AD= discuss for this draft, and=C2=A0not sure why the editors see impossible m= ove to update draft.=C2=A0=C2=A0



On Thursday, November 27,= 2014, Dearlove, Christopher (UK) <chris.dearlove@b= aesystems.com> wrote:

What I=E2=80=99d like to know is = who wants this (some people said so in the past, but please say so again) a= nd who cares about the Experimental/Proposed Standard distinction.

I think we all should care. It is important = to have experimental when the draft=C2=A0is not ready.=C2=A0<= /div>
=C2=A0

I know we have some issue= s over that some people here have customers who may want this, but can=E2= =80=99t identify those customers, and other matters. But what you can say w= ould be useful.

IMHO,=C2=A0IETF is n= ot about publishing what some=C2=A0customers=C2=A0want,=C2=A0but publishing= what WG-engineers want to fulfil all world customers or all internet commu= nity users. Some customers should not drive the IETF or its WGs.=C2=A0

AB
--001a1135ef1e3fff070508e13022-- From nobody Fri Nov 28 19:36: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 E72CB1A0636; Fri, 28 Nov 2014 19:36:35 -0800 (PST) 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 5CJ7jC9SYEuc; Fri, 28 Nov 2014 19:36:34 -0800 (PST) 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 3489C1A0469; Fri, 28 Nov 2014 19:36:34 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so5518473qcv.36 for ; Fri, 28 Nov 2014 19:36:33 -0800 (PST) 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=5tt5lOED3KAjPt6H3Hz118Z33XEQtlTEmpsY0s8nbrs=; b=wUzowH5P5fLElb4/VGF4Moqnc2pCIt48BskCD6np56OfbT0Q3XdzuuJJGJYjvS5efa GXBNmXMWGsO5gp5NR6sSilCwnB8o91G4GTZnWyfrkw+Zb06t5Jx5Ty7eCyhQk9G1HUAM xcYbcIJaemoeZ5tcXgkqChedtupj2AbFHB5om0XYbgSHGtK2J6XQFf3Q20nPqlEtiPcW HXWw0FUge3CaLmHI7fdw6e/nzGH+fIg+ISYl03fRfFbTv2jE4mdy5JQ3IeiqciXxb3L3 6lWK+SgCpML73hdx34ib7B57HLZqLDwHRYW5/kG8+fmHRu+p+M0ycZm95ZWy2Rx74Toj QPTg== MIME-Version: 1.0 X-Received: by 10.224.39.10 with SMTP id d10mr66344678qae.29.1417232193470; Fri, 28 Nov 2014 19:36:33 -0800 (PST) Received: by 10.140.98.212 with HTTP; Fri, 28 Nov 2014 19:36:33 -0800 (PST) In-Reply-To: References: <20141124114741.21325.47396.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 19:36:33 -0800 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Uh_fZ5jQx584hUd3xdkrcMS5K5U Cc: Thomas Clausen , manet , draft-ietf-manet-ibs.all@tools.ietf.org, The IESG , "" , Stephen Farrell Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 29 Nov 2014 03:36:36 -0000 On 11/27/14, Jiazi YI wrote: > I think the key distribution is an important (and hard, especially if there > is no centralised CA) issue for MANET. > I believe it's better to have it discussed in a separate document, rather > than in this draft. > Solving the management issue is even out of the scope. I think the/any adopted-draft should discuss what is related to draft/protocol purpose and use. In MANET use it is important to answer the questions related to the mobile/node self-organisation, which is important in this related to this protocol. What is out or in scope should be decided within a use case, so what use case did you think of for this protocol to have no management while using keys? Best, AB From nobody Sat Nov 29 12:22: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 A451E1A1EEB for ; Sat, 29 Nov 2014 12:22:39 -0800 (PST) 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 rb1zmE0etHTx for ; Sat, 29 Nov 2014 12:22:38 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138D41A00D7 for ; Sat, 29 Nov 2014 12:22:37 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id v10so3109077pde.12 for ; Sat, 29 Nov 2014 12:22:37 -0800 (PST) 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=x+ZQD6GCi4uIkJfK7ihUKEjdlDrRCTgDsP8FQDE14dM=; b=PtXGCi8G8eQ9nd1YjDGDXw14DnKMv/UVl3v1fEmGQDwrOixK3QRqxvKgOYzBQuJKPD fNaePYhu/VzN41TWvAxsNUg+KJEO9E3sW/MHX2mUac9Kyx+mHrv5TuZ9LVM9pfX0zS0k vGKm4LlfnVLi/UMrtUcSzjpPqpwjEZp5NdRRI= 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=x+ZQD6GCi4uIkJfK7ihUKEjdlDrRCTgDsP8FQDE14dM=; b=AMw6OxtfOu6lX3d0rIAwHIsdqPdgPoBnb4z0bT86pgpC4EhP4WOnFRab19aLwsMOry PfZMSBMa1zVGvEvJ73SNoC+AN5i8jdNg1nDhogJdiqnJ/UtDysdvflZsGymZBqy9a+Zq VuqgXVMeyjVefZPMacAMsUgFkbpspd7op9J54KnM1ArPO9+5Qla+OMFSxPE0A1tUU3E/ qop2XOKb9V5iB6vEjLP5rBtrY8awcHfGsnUFxmtsq06F4a4Qytu9I44fgFmFHQdDDhGz uqYE98PVfq3Q47nr7PCY7D+sfeFInmhEE9cNG/EvuPT2sPZX0kKArILzryfdq3kQNaYE JSdg== X-Gm-Message-State: ALoCoQnLUH86lyEMWKLw4x7QBtCMH55Sh/ka2CZ3GqQfH8lPa983MbxOGKMPurY1HqvRKi2gc6D9 MIME-Version: 1.0 X-Received: by 10.68.195.41 with SMTP id ib9mr84481695pbc.15.1417292556923; Sat, 29 Nov 2014 12:22:36 -0800 (PST) Received: by 10.70.95.226 with HTTP; Sat, 29 Nov 2014 12:22:36 -0800 (PST) Date: Sat, 29 Nov 2014 12:22:36 -0800 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/RrUSTvoHqTR6_m7-sxNSBCZehcE Subject: [manet] Preliminary minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 29 Nov 2014 20:22:39 -0000 Hi all, the preliminary minutes of the MANET meeting in Hawaii have been posted: http://www.ietf.org/proceedings/91/minutes/minutes-91-manet Please inform the chairs or me about objections or other improvements. Best regards Ulrich