From jpmacker@gmail.com Fri Nov 1 12:23:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8871211E80DE for ; Fri, 1 Nov 2013 12:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFlPW8rN0P2O for ; Fri, 1 Nov 2013 12:23:08 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B911E8123 for ; Fri, 1 Nov 2013 12:23:07 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c9so2719510qcz.3 for ; Fri, 01 Nov 2013 12:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=d1DNtYrYmKzqW8Sk7hS5nv8YCM1kmdR5MliF2MC0HT4=; b=ZUXeroLSk4BwyIXekfbV5ifokBJy+6PAGgZ0/AkT1fgADZPAKfLFGNA8yQ+pyZmwgG mJLCVBKkZZG4WaNmAXQwVyHWlr7MakBly5Cn2PwwlJ3kJONxIlVFC59iO34a6RYgi5Yu WCU3FTY9JhRvmDUkL55ehuZ5d+KOC30tI4mG3M1AiO4YythHWUpJNn4KaQVBC3UHTokI rBdWCYXmjsPt0LAE2YjcXco2Vc43xv0cKNuMMGmMFuCzZ4C/9IUWe0OjWtKd7dJdn4T1 AFpPM4V5wx1JHY0jj8ICrh9X6n7olE9A7DxqmqSGLqWqeJSuCd25eb3qt0HfuX7b3Bsk rXhg== X-Received: by 10.224.54.209 with SMTP id r17mr6176300qag.16.1383333787495; Fri, 01 Nov 2013 12:23:07 -0700 (PDT) Received: from [192.168.1.118] (c-69-140-151-4.hsd1.md.comcast.net. [69.140.151.4]) by mx.google.com with ESMTPSA id h9sm24173341qaq.9.2013.11.01.12.23.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 12:23:06 -0700 (PDT) From: Joe Macker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 1 Nov 2013 15:23:04 -0400 To: "manet@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [manet] WGLC: draft-ietf-manet-nhdp-olsrv2-tlv-extension X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:23:08 -0000 The WG chairs announce a WG Last Call for the nhdp-olsrv2-tlv document. The WG Last Call will last three weeks from today until Friday, Nov 22. -Joe Macker From jpmacker@gmail.com Fri Nov 1 12:24:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DB611E8123 for ; Fri, 1 Nov 2013 12:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylrm8HBPBXVk for ; Fri, 1 Nov 2013 12:24:48 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9711E8179 for ; Fri, 1 Nov 2013 12:24:45 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so2676592qcx.20 for ; Fri, 01 Nov 2013 12:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=QqF+I4M35PcKbLsDRcsKxlqvqpHi5cYPCp5i3KozsJ0=; b=xA++ULyOnw4/qwIrhd3QuVphcEFofVwB7mrE1ynDuMa0KF3hTtkyt14fDFonIqcpZ9 gGCt+j+oaCdLO7rY1kBkEJtabY+GVAY77amWsfJ49ydmr+nxdJXTIVShYPKjo6YGGb51 q9l+hBVxdMgcQ6zV1DL6CR0wLhxK+3oE5CxHk2BQFWNgwTgIt/y0h6jFdKy+RDmswJJg kkQK5pnlilZDPyKJGaRRyRCgt1N9/wD1wv1JMGXPyFJ/uVO1f+m57B90VC+SOQUPOdeV xw4H5KfqT9XvBluIEQLHbESzvRvyto+EWSx/h/R+TKaEXFXK35Eb87V1M8OyrgGEKzZn LJ7Q== X-Received: by 10.49.30.66 with SMTP id q2mr6173914qeh.38.1383333885129; Fri, 01 Nov 2013 12:24:45 -0700 (PDT) Received: from [192.168.1.118] (c-69-140-151-4.hsd1.md.comcast.net. [69.140.151.4]) by mx.google.com with ESMTPSA id jw9sm20422981qeb.2.2013.11.01.12.24.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 12:24:44 -0700 (PDT) From: Joe Macker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <62FB9FFA-8878-4E83-9C0C-EF2D7C982FAA@gmail.com> Date: Fri, 1 Nov 2013 15:24:42 -0400 To: "manet@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [manet] WGLC: manet-olsrv2-rmpr-optimization X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:24:49 -0000 The WG chairs announce a WG Last Call for the olsrv2-rmpr-optimization = document. The WG Last Call will last three weeks from today until Friday, Nov 22. -Joe Macker= From lotte.steenbrink@fu-berlin.de Sun Nov 3 12:15:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C0E11E822B for ; Sun, 3 Nov 2013 12:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.97 X-Spam-Level: X-Spam-Status: No, score=-3.97 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FRT_LOLITA1=1.865, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPaCtOd9itTg for ; Sun, 3 Nov 2013 12:14:57 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by ietfa.amsl.com (Postfix) with ESMTP id 743BF11E8174 for ; Sun, 3 Nov 2013 12:14:57 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for manet@ietf.org with esmtp (envelope-from ) id <1Vd44W-002wUh-DH>; Sun, 03 Nov 2013 21:14:56 +0100 Received: from dslb-188-103-112-086.pools.arcor-ip.net ([188.103.112.86] helo=frankenbook-pro.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for manet@ietf.org with esmtpsa (envelope-from ) id <1Vd44W-0047b1-5z>; Sun, 03 Nov 2013 21:14:56 +0100 From: Lotte Steenbrink Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Nov 2013 21:14:55 +0100 Message-Id: <249D2894-8F20-4F73-BDA7-243B4990E6D7@fu-berlin.de> To: manet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: 188.103.112.86 Subject: [manet] AODVv2 RREQ / RREP Message Format X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 20:15:04 -0000 Hi, working my way through the AODVv2 RFC5444 format for RREQ and RREP messages, I've stumbled across some things that were unclear to me. Any input would be greatly appreciated.=20 - The AddrBlk flags state that ahasfulltail =3D ahaszerotail =3D 0. = According to=20 RFC5444, page 12, neither a tail-length nor a tail should be included. = The RREQ=20 Message Format specification does, however, include Orig.Tail and = Target.Tail.=20 To me, that doesn't quite add up, what did I miss? - The capitalization seems inconsistent to me. Is there any reason why = the draft doesn't stick to either capitalizing every first letter (like the OLSRv2 = draft=20 does) or keeping it all in lowercase (like RFC5444)?=20 - The naming seems a bit off to me as well. In some places, the terms = don't=20 quite match the ones used in RFC5444, causing unnecessary confusion.=20 I'd like to suggest the following changes, which include some renaming = and=20 missing closing parentheses: A.1. RREQ Message Format=20 Figure 4 illustrates a packet format for an example RREQ message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PV=3D0 | PF=3D0 | msg-type=3DRREQ | MF=3D4 | MAL=3D3 | = msg-size=3D28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-size=3D28 | msg-hop-limit | msg.tlvs-length=3D0 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | num-addr=3D2 |1|0|0|0|0| Rsv | head-length=3D3 = |Head(Orig&Targ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | head (bytes for Orig & Target)| Orig.Tail | Target.Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=3D11 |tlv-type=3DSeqNum|0|1|0|1|0|0|Rsv|= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=3D0 | length=3D2 | Orig.Node SeqNum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |tlv-type=3DMetric|0|1|0|1|0|0|Rsv| Index-start=3D0 | length=3D1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OrigNodeHopCt | +-+-+-+-+-+-+-+-+ Figure 4: Example IPv4 RREQ, with SeqNum and Metric AddrTLVs The fields in Figure 4 are to be interpreted as follows: o PV=3D0 (Packet Header Version =3D 0) o PF=3D0 (Packet Flags =3D 0) o msg-type=3DRREQ (first [and only] message is of type RREQ) o MF=3D4 (Message Flags =3D 4 [only msg-hop-limit field is present]) o MAL=3D3 (Message Address Length indicator [3 for IPv4, 15 for = IPv6]) o msg-size=3D28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) o msg-hop-limit (initially MAX_HOPCOUNT by default) o msg.tlvs-length=3D0 (no Message TLVs) o num-addr=3D2 (OrigNode and TargNode addresses in RteMsg AddrBlock) o addr-flags: * bit 0 (ahashead): 1 * bit 1 (ahasfulltail): 0 * bit 2 (ahaszerotail): 0 * bit 3 (ahassingleprelen): 0 * bit 4 (ahasmultiprelen): 0 * bits 5-7: RESERVED o head-length=3D3 (length of head part of each address is 3 octets) o head (3 initial bytes for both Originating & Target addresses) o Orig.Tail (4th byte of Originating Node IP address) o Target.Tail (4th byte of Target Node IP address) o addr.tlvs-length=3D11 (length in bytes for SeqNum and Metric TLVs) o tlv-type=3DSeqNum (AddrTLV type of first AddrBlk TLV, values 2 = octets) o AddrTLV flags for SeqNum TLV: * bit 0 (thastypeext): 0 * bit 1 (thassingleindex): 1 * bit 2 (thasmultiindex): 0 * bit 3 (thasvalue): 1 * bit 4 (thasextlen): 0 * bit 5 (tismultivalue): 0 * bits 6-7: RESERVED o Index-start=3D0 (SeqNum TLV values start at index 0) o length=3D2 (so there is only one TLV value, [1 =3D 2/2]) o Orig.Node SeqNum (first [and only] TLV value for SeqNum TLVs) o tlv-type=3DMetric (AddrTLV type of second AddrBlk TLV, values 1 = octet) o AddrTLV flags for Metric TLV: * bit 0 (thastypeext): 0 * bit 1 (thassingleindex): 1 * bit 2 (thasmultiindex): 0 * bit 3 (thasvalue): 1 * bit 4 (thasextlen): 0 * bit 5 (tismultivalue): 0 * bits 6-7: RESERVED o Index-start=3D0 (Metric TLV values start at index 0) o length=3D1 (so there is only one TLV value, [1 =3D 1/1]) o OrigNodeHopCt (first [and only] TLV value for Metric TLVs) A.2. RREP Message Format Figure 5 illustrates a packet format for an example RREP message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PV=3D0 | PF=3D0 | msg-type=3DRREP | MF=3D4 | MAL=3D3 | = msg-size=3D30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-size=3D30 | msg-hop-limit | msg.tlvs-length=3D0 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | num-addr=3D2 |1|0|0|0|0| Rsv | head-length=3D3 = |Head(Orig&Targ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr.tlvs-length=3D13 = |tlv-type=3DSeqNum|0|1|0|1|0|0|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=3D0 | tlv-length=3D2 | Orig.Node SeqNum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target.Node SeqNum |tlv-type=3DMetric|0|1|0|1|0|0|Rsv|= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=3D1 | tlv-length=3D1 | TargNodeHopCt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Example IPv4 RREP, with 2 SeqNums and 1 Metric The fields in Figure 5 are to be interpreted as follows: o PV=3D0 (Packet Header Version =3D 0) o PF=3D0 (Packet Flags =3D 0) o msg-type=3DRREP (first [and only] message is of type RREP) o MF=3D4 (Message Flags =3D 4 [only msg-hop-limit field is present]) o MAL=3D3 (Message Address Length indicator [3 for IPv4, 15 for = IPv6]) o msg-size=3D28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) o msg-hop-limit (initially MAX_HOPCOUNT by default) o msg.tlvs-length=3D0 (no Message TLVs) o num-addr=3D2 (OrigNode and TargNode addresses in RteMsg AddrBlock) o addr-flags: * bit 0 (ahashead): 1 * bit 1 (ahasfulltail): 0 * bit 2 (ahaszerotail): 0 * bit 3 (ahassingleprelen): 0 * bit 4 (ahasmultiprelen): 0 * bits 5-7: RESERVED o head-length=3D3 (length of head part of each address is 3 octets) o Head (3 initial bytes for both Originating & Target addresses) o Orig.Tail (4th byte of Originating Node IP address) o Target.Tail (4th byte of Target Node IP address) o addr.tlvs-length=3D13 (length in bytes for SeqNum and Metric TLVs) o tlv-type=3DSeqNum (AddrTLV type of first AddrBlk TLV, values 2 = octets) o AddrTLV flags for SeqNum TLV: * bit 0 (thastypeext): 0 * bit 1 (thassingleindex): 1 * bit 2 (thasmultiindex): 0 * bit 3 (thasvalue): 1 * bit 4 (thasextlen): 0 * bit 5 (tismultivalue): 0 * bits 6-7: RESERVED o Index-start=3D0 (SeqNum TLV values start at index 0) o tlv-length=3D4 (so there is are two TLV values, [2 =3D 4/2]) o Orig.Node SeqNum (first of two TLV values for SeqNum TLVs) o Targ.Node SeqNum (second of two TLV values for SeqNum TLVs) o tlv-type=3DMetric (AddrTLV type of second AddrBlk TLV, values 1 = octet) o AddrTLV flags for Metric TLV: * bit 0 (thastypeext): 0 * bit 1 (thassingleindex): 1 * bit 2 (thasmultiindex): 0 * bit 3 (thasvalue): 1 * bit 4 (thasextlen): 0 * bit 5 (tismultivalue): 0 * bits 6-7: RESERVED o Index-start=3D1 (Metric TLV values start at index 1) o tlv-length=3D1 (so there is only one TLV value, [1 =3D 1/1]) o TargNodeHopCt (first [and only] TLV value for Metric TLVs) With kind regards, Lotte Steenbrink From geoff.ietf@mulligan.com Sun Nov 3 22:04:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8030421E812E for ; Sun, 3 Nov 2013 22:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMWC8PdvozOY for ; Sun, 3 Nov 2013 22:04:09 -0800 (PST) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8F011E8171 for ; Sun, 3 Nov 2013 22:04:09 -0800 (PST) Received: from [31.133.136.162] (dhcp-88a2.meeting.ietf.org [31.133.136.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id AA3485F74F for ; Sun, 3 Nov 2013 23:04:08 -0700 (MST) Message-ID: <527738D7.1000405@mulligan.com> Date: Sun, 03 Nov 2013 23:04:07 -0700 From: Geoff Mulligan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: manet@ietf.org Content-Type: multipart/alternative; boundary="------------000004070205070808040503" Subject: [manet] SmartAmerica Challenge briefing/meeting X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 06:04:11 -0000 This is a multi-part message in MIME format. --------------000004070205070808040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, We've arranged to be able to use the IAB conference room for our meeting. Again we are going to be meeting to talk about the PIF CPS Smart America Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate. Place: IAB Conference Room Date: Monday November 4 Time: 7:30pm to 9pm US/Pacific time *Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 301.975.6283 * --------------000004070205070808040503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,
  We've arranged to be able to use the IAB conference room for our meeting.

Again we are going to be meeting to talk about the PIF CPS Smart America Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate.

Place: IAB Conference Room
Date: Monday November 4
Time: 7:30pm to 9pm US/Pacific time
 
Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 301.975.6283

--------------000004070205070808040503-- From aliimaani@gmail.com Mon Nov 4 04:29:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B389021F9DBA for ; Mon, 4 Nov 2013 04:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM3uD3d1MF25 for ; Mon, 4 Nov 2013 04:29:46 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1F16911E8102 for ; Mon, 4 Nov 2013 04:29:45 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id uy5so6913301obc.7 for ; Mon, 04 Nov 2013 04:29:44 -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=k00N0AoWWdyy2FMOl+buwHoG5HyfpaXforsb33WsCCQ=; b=PBAZEFycfunXTurA0KIVTynRn9VOF6aj5p70BR2wMeO2vy3ziT2FuYiJ/RNKRUPVoI P0K9VNxFClBtzRvapsx4BKB6w9w5daHUHXkqOBTfcHOi1CzgMNrUUeoXinJa+xciWlu+ qHxjxiJOewtnfxLkKQY9jXA445E8WBoapNGIrqP7XepM4Evynp1kPIExIv9AKEqg0+9d 15m4ZPflSXA+X0BsVnV2uJKShMBQh4MhIWTah/xw/D7vl3oj+1AcCsc7Oj7lrOXxFrmt mR/tq+cqiq0fuMSmB06V0m4TvDT28DIFGBdt3TOJaWfPZx215bcgx3zIJPGd7UI3UMoA 3rig== MIME-Version: 1.0 X-Received: by 10.60.40.70 with SMTP id v6mr68968oek.69.1383568184589; Mon, 04 Nov 2013 04:29:44 -0800 (PST) Received: by 10.182.138.6 with HTTP; Mon, 4 Nov 2013 04:29:44 -0800 (PST) In-Reply-To: <62FB9FFA-8878-4E83-9C0C-EF2D7C982FAA@gmail.com> References: <62FB9FFA-8878-4E83-9C0C-EF2D7C982FAA@gmail.com> Date: Mon, 4 Nov 2013 15:59:44 +0330 Message-ID: From: Ali Imani To: Joe Macker Content-Type: multipart/alternative; boundary=089e0139ffc22a444b04ea591238 Cc: "manet@ietf.org List" Subject: Re: [manet] WGLC: manet-olsrv2-rmpr-optimization X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 12:29:46 -0000 --089e0139ffc22a444b04ea591238 Content-Type: text/plain; charset=ISO-8859-1 remove me On Fri, Nov 1, 2013 at 10:54 PM, Joe Macker wrote: > > The WG chairs announce a WG Last Call for the olsrv2-rmpr-optimization > document. > > The WG Last Call will last three weeks from today until Friday, Nov 22. > > -Joe Macker > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0139ffc22a444b04ea591238 Content-Type: text/html; charset=ISO-8859-1
remove me


On Fri, Nov 1, 2013 at 10:54 PM, Joe Macker <jpmacker@gmail.com> wrote:

The WG chairs announce a WG Last Call for the olsrv2-rmpr-optimization document.

The WG Last Call will last three weeks from today until Friday, Nov 22.

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

--089e0139ffc22a444b04ea591238-- From abdussalambaryun@gmail.com Mon Nov 4 05:50:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF2611E8158 for ; Mon, 4 Nov 2013 05:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYEfL1dY3jra for ; Mon, 4 Nov 2013 05:50:31 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A805B11E81C3 for ; Mon, 4 Nov 2013 05:50:28 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so6886418pab.5 for ; Mon, 04 Nov 2013 05:50:28 -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=Eeiu2rhsoagwfgXfTQOKm62MIEyiTibuTlrchoYRBqQ=; b=vbJHd/78plEf6zBHWTtPG6RtkpLWUvGOAjwwG8poJRv5BdyGnmD0GsUQ2bIrsmQ64O 607cftWlcZwaEgHI2WiiEhm23pOvWKLpJVaXIpQTauY5GP64AVYO4ORWlStV/fpEZsK5 7Yq4/zSPp+OAaLoJbLIpXqlVlR2PEQsTJUfChPs6CmnL322qLNJB+8CZlZYKQPAS8jCQ HBl9c0fRYuHBmb0pso+orARYqRfBdcCZ96deU0/Zm85ATgtJ3a7xmpvpGsQLblqJZhH3 hHz2UoG3vcGE7M2P7xhpEwoScnAQ5P5QOFAuWtr/UwHaaLoPJYmXvMyQKlRnIsmzee52 5l1w== MIME-Version: 1.0 X-Received: by 10.68.215.38 with SMTP id of6mr17745587pbc.14.1383573028215; Mon, 04 Nov 2013 05:50:28 -0800 (PST) Received: by 10.69.8.5 with HTTP; Mon, 4 Nov 2013 05:50:28 -0800 (PST) In-Reply-To: <527738D7.1000405@mulligan.com> References: <527738D7.1000405@mulligan.com> Date: Mon, 4 Nov 2013 13:50:28 +0000 Message-ID: From: Abdussalam Baryun To: Geoff Mulligan Content-Type: multipart/alternative; boundary=001a11346638de207004ea5a324c Cc: manet Subject: Re: [manet] SmartAmerica Challenge briefing/meeting X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:50:33 -0000 --001a11346638de207004ea5a324c Content-Type: text/plain; charset=ISO-8859-1 Hi Geoff, >From the webpage you provided it states some how that it is only for USA participants that can be involved, not sure why will IETF make efforts for one country while it is for all smart countries. Please explain what you mean by *meeting to talk about how we might be able to participate*, AB On Mon, Nov 4, 2013 at 6:04 AM, Geoff Mulligan wrote: > Folks, > We've arranged to be able to use the IAB conference room for our meeting. > > Again we are going to be meeting to talk about the PIF CPS Smart America > Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be > able to participate. > > Place: IAB Conference Room > Date: Monday November 4 > Time: 7:30pm to 9pm US/Pacific time > > > *Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | > 301.975.6283 <301.975.6283> * > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11346638de207004ea5a324c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Geoff,
=A0
From the webpage yo= u provided it states some how that=A0it is only for USA=A0participants that= can be involved, not sure why=A0will IETF=A0make efforts for one=A0country= while it is for=A0all smart countries. Please explain what you mean by *me= eting to talk about how we might be able to participate*,
=A0
AB


On Mon, Nov 4, 2013 at 6:04 AM, Geoff Mulligan <= geoff.ietf@mulligan.com> wrote:
=20 =20 =20
Folks,
=A0 We've arranged to be able to use the IAB conference room for ou= r meeting.

Again we are going to be meeting to talk about the PIF CPS Smart America Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate.

Place: IAB Conference Room
Date: Monday November 4
Time: 7:30pm to 9pm US/Pacific time
=A0
Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 301.975.6283


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


--001a11346638de207004ea5a324c-- From geoff@proto6.com Sun Nov 3 22:01:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA34721E8132 for ; Sun, 3 Nov 2013 22:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cii1Ky-jhh4V for ; Sun, 3 Nov 2013 22:01:35 -0800 (PST) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) by ietfa.amsl.com (Postfix) with ESMTP id 381F221E80CB for ; Sun, 3 Nov 2013 22:01:34 -0800 (PST) Received: from [31.133.136.162] (dhcp-88a2.meeting.ietf.org [31.133.136.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id E9AA15F71F for ; Sun, 3 Nov 2013 23:01:33 -0700 (MST) Message-ID: <5277383C.3010500@proto6.com> Date: Sun, 03 Nov 2013 23:01:32 -0700 From: Geoff Mulligan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: manet@ietf.org Content-Type: multipart/alternative; boundary="------------020806030005070806050206" X-Mailman-Approved-At: Mon, 04 Nov 2013 09:16:46 -0800 Subject: [manet] SmartAmerica meeting/briefing location X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 06:01:50 -0000 This is a multi-part message in MIME format. --------------020806030005070806050206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, We've arranged to be able to use the IAB conference room for our meeting. Again we are going to be meeting to talk about the PIF CPS Smart America Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate. Place: IAB Conference Room Date: Monday November 4 Time: 7:30pm to 9pm US/Pacific time *Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 301.975.6283 * --------------020806030005070806050206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,
  We've arranged to be able to use the IAB conference room for our meeting.

Again we are going to be meeting to talk about the PIF CPS Smart America Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate.

Place: IAB Conference Room
Date: Monday November 4
Time: 7:30pm to 9pm US/Pacific time
 
Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 301.975.6283

--------------020806030005070806050206-- From rgcole01@comcast.net Mon Nov 4 11:43:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979F721E821C for ; Mon, 4 Nov 2013 11:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swIAHMK9TRC9 for ; Mon, 4 Nov 2013 11:43:13 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 2172021E8100 for ; Mon, 4 Nov 2013 11:42:57 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta15.emeryville.ca.mail.comcast.net with comcast id lXLY1m0051afHeLAFXirJG; Mon, 04 Nov 2013 19:42:51 +0000 Received: from [128.47.159.216] ([128.47.159.216]) by omta17.emeryville.ca.mail.comcast.net with comcast id lXif1m00P4gRWqg8dXii4f; Mon, 04 Nov 2013 19:42:54 +0000 Message-ID: <5277F8AF.4080901@comcast.net> Date: Mon, 04 Nov 2013 14:42:39 -0500 From: Cole User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Joe Macker , "adamson@itd.nrl.navy.mil" , manet@ietf.org, "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383594171; bh=3dLTpxIkPdo/hE6HGEu2G+de098bzntXudukaPs0Zsc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=A1UXBw7Pu/3GjNpwQ56Vbjayy4hEcKaW3r93+kKbKhEL8Ty5b52ixW3ICaObDoktL W/u3synYHA8HWTzGIPHy80JX5CMAt/fn23rtLsarWZCpJEOCDpuE/hgm0YW2i32UDa jRYOvFMKEsFFCXnVJwoc/ucLsJvv/l6g6BYAQ86rROEg+5Mqmbt12oF4dshsMpo9IU WAPXAqW1ac+gOPAzk1YYElWGDTejG7Pt5vdtcje2QhMJJ2VjObIGR57TBxNkAKj18P 2/Y8HOPnf3SRw7GRMyciRdz4vnyBedkgBjWKxlNADF7QWCbbIdofCICSWWmN91xq4X 5DuAXURByqpCw== Subject: [manet] Question #6: SMF-MIB draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:43:35 -0000 Joe, Brian, We got this question from Dan Romascanu, the SMF-MIB MIB-DOCTOR reviewer, on the SMF-MIB draft-09: "6. This document is Experimental and the SMF-MIB is routed under the Experimental subtree. Will the TCs defined here be used only in Experimental MIB modules? If there are any chances that they will be needed in Standards Track MIB modules better take these out and define them in a separate document that defines a separate MIB module under mib-2, otherwise they risk to create downrefs in the future, as RFCs that define IMPORTed TCs must be Normative References." Three TCs are defined within the MIB module, i.e., SmfStatus, SmfOpModeID and SmfRssaID. Of the three, I would say that SmfRssaID should be moved to a separate IANA administered TC module as it is identifying approximate min-CDS algorithm definitions. New algorithms would be expected to be defined and this would allow IANA to maintain their IDs. I do not have a strong opinion regarding the other two: + If you all and the WG believe that the SmfOpModeID would continue to add new Op Modes, then perhaps it needs IANA management as well. + SmfStatus merely indicates the operational (up/down) status of the SMF process on given MANET router interfaces. Please advise? Thanks, Bob From rfarley@qti.qualcomm.com Mon Nov 4 15:09:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCF211E811D for ; Mon, 4 Nov 2013 15:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxzNj608WaCi for ; Mon, 4 Nov 2013 15:09:28 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4359521E8266 for ; Mon, 4 Nov 2013 15:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1383606565; x=1415142565; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0V1VtZXZiRhI8VXn6OBEeVaMjj6D1urXPZF55jRS3C0=; b=af3wxHl6KKYt+hlnzHcyTkX4JP1nv5kT8n6FDmYnRvDpj7bPWA3sRYQv bPhdHQlo36cEeC8OpLIm2eQm2p2YY47z6Bbh69KqSTICBHas9L1ZP5kwW NZxGkx+dB3jqfPlyv7+VtlkpVuY5iF0+T042QidnOjncH+6ug3QtKZQci 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7249"; a="54955729" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 04 Nov 2013 15:09:24 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7249"; a="579098842" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Nov 2013 15:09:22 -0800 Received: from NASANEXD01D.na.qualcomm.com ([169.254.3.190]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 15:09:22 -0800 From: "Farley, Rick" To: Geoff Mulligan , "manet@ietf.org" Thread-Topic: [manet] SmartAmerica meeting/briefing location Thread-Index: AQHO2YHYF85HE/jzVEGRZi3xsjYf65oVsqr7 Date: Mon, 4 Nov 2013 23:09:22 +0000 Message-ID: References: <5277383C.3010500@proto6.com> In-Reply-To: <5277383C.3010500@proto6.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] SmartAmerica meeting/briefing location X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:09:33 -0000 Where is the IAB Conference room ? --Richard ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] on behalf of Geoff Mu= lligan [geoff@proto6.com] Sent: Sunday, November 03, 2013 10:01 PM To: manet@ietf.org Subject: [manet] SmartAmerica meeting/briefing location Folks, We've arranged to be able to use the IAB conference room for our meeting. Again we are going to be meeting to talk about the PIF CPS Smart America Ch= allenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate. Place: IAB Conference Room Date: Monday November 4 Time: 7:30pm to 9pm US/Pacific time Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 3= 01.975.6283 From geoff.ietf@mulligan.com Mon Nov 4 15:16:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632E121E826E for ; Mon, 4 Nov 2013 15:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi5BfhUyiPSl for ; Mon, 4 Nov 2013 15:16:43 -0800 (PST) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3421E8280 for ; Mon, 4 Nov 2013 15:16:40 -0800 (PST) Received: from [31.133.160.178] (dhcp-a0b2.meeting.ietf.org [31.133.160.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id 5B3E55F74F; Mon, 4 Nov 2013 16:16:39 -0700 (MST) Message-ID: <52782AD5.5040902@mulligan.com> Date: Mon, 04 Nov 2013 16:16:37 -0700 From: Geoff Mulligan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Farley, Rick" , "manet@ietf.org" References: <5277383C.3010500@proto6.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] SmartAmerica meeting/briefing location X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:16:48 -0000 It is the room "constable" on the 4th floor. geoff On 11/04/2013 04:09 PM, Farley, Rick wrote: > Where is the IAB Conference room ? > > --Richard > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] on behalf of Geoff Mulligan [geoff@proto6.com] > Sent: Sunday, November 03, 2013 10:01 PM > To: manet@ietf.org > Subject: [manet] SmartAmerica meeting/briefing location > > Folks, > We've arranged to be able to use the IAB conference room for our meeting. > > Again we are going to be meeting to talk about the PIF CPS Smart America Challenge project (www.nist.gov/el/smartamerica.cfm) and how you might be able to participate. > > Place: IAB Conference Room > Date: Monday November 4 > Time: 7:30pm to 9pm US/Pacific time > > Geoff Mulligan | Presidential Innovation Fellow | Cyber Physical System | 301.975.6283 > From ietf@thomasclausen.org Mon Nov 4 15:44:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2670121E82ED for ; Mon, 4 Nov 2013 15:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-hU6rEsJOQn for ; Mon, 4 Nov 2013 15:44:05 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id B77BA21E82E2 for ; Mon, 4 Nov 2013 15:43:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 794411C81B47 for ; Mon, 4 Nov 2013 15:43:39 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [31.133.151.236] (dhcp-97ec.meeting.ietf.org [31.133.151.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 278631C81B3C for ; Mon, 4 Nov 2013 15:43:39 -0800 (PST) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) Message-Id: Date: Mon, 4 Nov 2013 15:43:37 -0800 To: List List Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [manet] Looking at the MANET agenda...rechartering? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:44:12 -0000 All, I was looking at the agenda for this coming meeting, trying to prepare a lit= tle in advance for the meeting.=20 An agenda item "WG rechartering" appears on the agenda, but I do not recall h= aving seen any discussions as to what the WG should recharter to work on, an= d a quick search through my mail archive doesn't reveal anything on recharte= ring from within this decade.=20 I imagine that I'm not alone in needing a little time to prepare and identif= y what (if any) tasks are logical next steps from where the WG is, currently= , so having a discussion in advance of the physical meeting seems preferenti= al. Have I missed an email on this topic and, if so, can anyone resend it, pleas= e? Thanks in advance for your kind assistance on this matter. Respectfully, Thomas Sent from my iPad= From jpmacker@gmail.com Mon Nov 4 22:37:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37E21E80E8 for ; Mon, 4 Nov 2013 22:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EznMbv2RNtg for ; Mon, 4 Nov 2013 22:37:34 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0522A21E8115 for ; Mon, 4 Nov 2013 22:37:27 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so14267766iet.18 for ; Mon, 04 Nov 2013 22:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XP82YKRiYE6XSc4yW5drFjew8njKtTEevu8BJ2g6pPA=; b=0IIFVx62FGdh4lzQSDzx8rU8F0xV9EGDkYLGmAotYc5OdS3nTqYEnbUDRlK+GqTiAw C5mjVp87jBrtxHeMKoPega9cm4M4h+Mans5nhs/c29BvD/xDyhKTAo4J7YJggh90lmVI jK+7wHKFY7qPhIbKi3yW9z19w381trMNvQOOpz44CWkDT2FwpYzP23B/0JqVnlKPitX6 qZKnOqt2SfPrcX2EJbWR5Ciz5EH1IjyWBw0Uzy2L24cMpq9HPqpDUTFBzkUqLi2UjL4f sqJtQKGasYuiZua29fLb5N+hSEhulWq05DxTvl5ZJYU7Yb6TbKo4EyxVkG25iH/v79KK LbuQ== X-Received: by 10.50.164.165 with SMTP id yr5mr14616872igb.38.1383633443224; Mon, 04 Nov 2013 22:37:23 -0800 (PST) Received: from dhcp-905b.meeting.ietf.org (dhcp-905b.meeting.ietf.org. [31.133.144.91]) by mx.google.com with ESMTPSA id x6sm7100056igb.3.2013.11.04.22.37.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 22:37:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Macker In-Reply-To: Date: Tue, 5 Nov 2013 01:37:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <90F6F203-C278-45BF-82C7-202B24F543E8@gmail.com> References: To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1510) Cc: List List Subject: Re: [manet] Looking at the MANET agenda...rechartering? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:37:51 -0000 I also feel this is not a well formulated discussion at this time so I = am hearing a bash. Better to bash the agenda before the meeting. -joe On Nov 4, 2013, at 6:43 PM, Thomas Heide Clausen = wrote: > All, >=20 > I was looking at the agenda for this coming meeting, trying to prepare = a little in advance for the meeting.=20 >=20 > An agenda item "WG rechartering" appears on the agenda, but I do not = recall having seen any discussions as to what the WG should recharter to = work on, and a quick search through my mail archive doesn't reveal = anything on rechartering from within this decade.=20 >=20 > I imagine that I'm not alone in needing a little time to prepare and = identify what (if any) tasks are logical next steps from where the WG = is, currently, so having a discussion in advance of the physical meeting = seems preferential. >=20 > Have I missed an email on this topic and, if so, can anyone resend it, = please? >=20 > Thanks in advance for your kind assistance on this matter. >=20 > Respectfully, >=20 > Thomas >=20 > Sent from my iPad > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Mon Nov 4 22:51:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2595821E809E for ; Mon, 4 Nov 2013 22:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji-VNmiQjC1v for ; Mon, 4 Nov 2013 22:51:34 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8A411E8176 for ; Mon, 4 Nov 2013 22:51:34 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id x13so14691637ief.9 for ; Mon, 04 Nov 2013 22:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iV+uAkVRTIBhNocdEF1FTf5XL5dJgrgpIJBqNjwr1I4=; b=OkfhLMSUF/t4oCGozcXxc63gnb/b/xJQuJ4v27P2eNPWsXovO+XrpNNi/03taFyqpc hRSEsIdZduCmN8zGHg6oyfAzTx16M2UPNgLCasjWcLZZ8vyW0bisA9SyJcAGm6YpV6Ad ptvq3xpb1BNFf4K9AZn6gVKmgdnULI6dGtaiPBVcH8TZKLH3RYv6pW8yHVyLt2KonB3+ ddq71gPDKxwuFC/seLpiXrypqt2Z5cD3aRRCr8SRV6aEwHrcpP1lNQ3MZ/7H9asv/cnT ecjKybC3pWFL2gc/XIeMQVvjI1VjQvd8p5a14RJgwfHXVeFhsT5nPv2JjWK0Wur5PEUx Ya0w== X-Received: by 10.43.80.6 with SMTP id zs6mr5939674icb.33.1383634293913; Mon, 04 Nov 2013 22:51:33 -0800 (PST) Received: from dhcp-905b.meeting.ietf.org (dhcp-905b.meeting.ietf.org. [31.133.144.91]) by mx.google.com with ESMTPSA id f5sm7147580igc.4.2013.11.04.22.51.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 22:51:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Macker In-Reply-To: <90F6F203-C278-45BF-82C7-202B24F543E8@gmail.com> Date: Tue, 5 Nov 2013 01:51:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72289766-D766-4EFB-A359-E0F7DCFC8E12@gmail.com> References: <90F6F203-C278-45BF-82C7-202B24F543E8@gmail.com> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1510) Cc: List List Subject: Re: [manet] Looking at the MANET agenda...rechartering? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:51:35 -0000 I had actually changed that a few nights back but it slipped back in = when Ulrich edited. We will fix tonight. On Nov 5, 2013, at 1:37 AM, Joe Macker wrote: > I also feel this is not a well formulated discussion at this time so I = am hearing a bash. > Better to bash the agenda before the meeting. >=20 > -joe >=20 > On Nov 4, 2013, at 6:43 PM, Thomas Heide Clausen = wrote: >=20 >> All, >>=20 >> I was looking at the agenda for this coming meeting, trying to = prepare a little in advance for the meeting.=20 >>=20 >> An agenda item "WG rechartering" appears on the agenda, but I do not = recall having seen any discussions as to what the WG should recharter to = work on, and a quick search through my mail archive doesn't reveal = anything on rechartering from within this decade.=20 >>=20 >> I imagine that I'm not alone in needing a little time to prepare and = identify what (if any) tasks are logical next steps from where the WG = is, currently, so having a discussion in advance of the physical meeting = seems preferential. >>=20 >> Have I missed an email on this topic and, if so, can anyone resend = it, please? >>=20 >> Thanks in advance for your kind assistance on this matter. >>=20 >> Respectfully, >>=20 >> Thomas >>=20 >> Sent from my iPad >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From ulrich@herberg.name Tue Nov 5 08:00:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE411E82AA for ; Tue, 5 Nov 2013 08:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0zUMNAFZIrO for ; Tue, 5 Nov 2013 08:00:31 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9987211E816B for ; Tue, 5 Nov 2013 08:00:23 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id hz11so5701685vcb.38 for ; Tue, 05 Nov 2013 08:00:23 -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=w/4Jro9A6yX3zqdir2pGxyfCnbyXI9iFNweR76zDqyM=; b=MYOG66qx+7O4WPQFTeN18lbWPsSwa2HtYsM8YwvdKzJnx3/IiUWiZo9/L5koev8cyY PA55eTGJGi2BpBQHafDrvuuiHPfSvrgW5pKaAESEXt0Qy5d8OnpTxUga4rgmThK64Wue 2TDrBtxq3Ccv9CXWU9r73aJTyYPALxsEzkFaw= 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=w/4Jro9A6yX3zqdir2pGxyfCnbyXI9iFNweR76zDqyM=; b=W5nsEfIgqxsmpiMGV7GQShC87IvIHiXBID3IOVlPyr4jy2vT9tth5lkhaFKQAr1REE vECFpuBcQ8QGADdIQgLTVYu5KH3GGADNi+w6xmlchM0yJlYh32/VYd9E9yIV4iaXpRN5 2vBgmHJHSpAlgpyQIUzbGO+U93apMOV1W/vknHo6i9bfrov8jt2hfELxqq82ZRQiOipk 9axuPyFwgbiU8GW5GpTVYH3IbbrbuMUgEeOHVkU4EbnTaNuqo4N61y9B0Yqh37GLCtR6 eBVhYQX/VdusWZMXA+ses29cQcZGCbKkWtdwGEjkFgXLtbANHakJ7WeKUWLVnvtoMDXk MH3g== X-Gm-Message-State: ALoCoQmBWe3975xJQJy7mga6dJAfjuDPRRSA/DeUI+dZjg8l7kmOUigN2npvVDld69PMAdIBdaaU MIME-Version: 1.0 X-Received: by 10.58.181.230 with SMTP id dz6mr407084vec.35.1383667222906; Tue, 05 Nov 2013 08:00:22 -0800 (PST) Received: by 10.220.253.68 with HTTP; Tue, 5 Nov 2013 08:00:22 -0800 (PST) Date: Tue, 5 Nov 2013 08:00:22 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Minutes taker and scribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:00:32 -0000 We need two minutes takers and a jabber scribe for the MANET meeting on Thursday. I would greatly appreciate if I can get some volunteers. Just shoot me an email. Thanks Ulrich From brian.adamson@nrl.navy.mil Tue Nov 5 10:58:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B5021E8085 for ; Tue, 5 Nov 2013 10:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbiWTXkDjhAh for ; Tue, 5 Nov 2013 10:58:02 -0800 (PST) Received: from mail4.nrl.navy.mil (scmail.nrl.navy.mil [IPv6:2001:480:20:421::587:27]) by ietfa.amsl.com (Postfix) with ESMTP id 43A3021E809F for ; Tue, 5 Nov 2013 10:58:00 -0800 (PST) Received: from hotel-v6.meeting.ietf.org (hotel-v6.meeting.ietf.org [IPv6:2001:67c:370:136:b090:93ce:93a8:4d3e] (may be forged)) (authenticated bits=0) by mail4.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id rA5Ivu9M011784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 13:57:57 -0500 From: Brian Adamson Content-Type: multipart/alternative; boundary="Apple-Mail=_BA194F43-2276-4E18-A36B-F2C0DBF1CEE2" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Tue, 5 Nov 2013 13:57:58 -0500 References: <20131105032628.10115.86084.idtracker@ietfa.amsl.com> To: "manet@ietf.org" X-Mailer: Apple Mail (2.1510) X-Scanned-By: MIMEDefang 2.72 Subject: [manet] Fwd: New Version Notification for draft-adamson-elasticmcast-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:58:03 -0000 --Apple-Mail=_BA194F43-2276-4E18-A36B-F2C0DBF1CEE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I submitted an Internet Draft for the Elastic Multicast group-specific = extension to SMF and will be providing a short overview at the MANET WG = meeting on Thursday. The draft is available at: http://www.ietf.org/internet-drafts/draft-adamson-elasticmcast-00.txt=20= and an easier-to-read PDF version is also posted as: http://www.ietf.org/internet-drafts/draft-adamson-elasticmcast-00.pdf The abstract is as follows: Abstract: This document describes an Internet Protocol (IP) multicast routing protocol suitable for dynamic network environments including mobile wireless. To handle high dynamics, this routing mechanism uses redundant forwarding, based upon the Simplified Multicast Forwarding (SMF) approach of [RFC6621], while converging to regular multicast distribution trees where or when the network becomes relatively stable. The rationale is that intermittent connectivity directly affects the ability of routers to synchronize on their view of the network, thus making it difficult to converge on efficient distribution trees, while network wide broadcast may be prohibitively expensive for relatively sparse groups. A hybrid approach, called Elastic Multicast, is specified which dynamically switches between limited scope broadcast and tree path forwarding independently at each node. The trees created during stable periods and portions of the network are pruned from the SMF efficient flooding mesh. --Apple-Mail=_BA194F43-2276-4E18-A36B-F2C0DBF1CEE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/internet-drafts/draft-adamson-elasticmcast-00.txt=  

and an easier-to-read PDF version is = also posted as:


The abstract is as = follows:

Abstract:
  This document = describes an Internet Protocol (IP) multicast routing
=   protocol suitable for dynamic network environments including = mobile
  wireless.  To handle high dynamics, this = routing mechanism uses
  redundant forwarding, based upon = the Simplified Multicast Forwarding
  (SMF) approach of = [RFC6621], while converging to regular multicast
=   distribution trees where or when the network becomes = relatively
  stable.  The rationale is that = intermittent connectivity directly
  affects the ability = of routers to synchronize on their view of the
  network, = thus making it difficult to converge on efficient
=   distribution trees, while network wide broadcast may be = prohibitively
  expensive for relatively sparse groups. =  A hybrid approach, called
  Elastic Multicast, is = specified which dynamically switches between
  limited = scope broadcast and tree path forwarding independently at
=   each node.  The trees created during stable periods and = portions of
  the network are pruned from the SMF = efficient flooding mesh.


= --Apple-Mail=_BA194F43-2276-4E18-A36B-F2C0DBF1CEE2-- From ietf@thomasclausen.org Tue Nov 5 13:17:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E891811E818F for ; Tue, 5 Nov 2013 13:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ3ar7vMOnML for ; Tue, 5 Nov 2013 13:17:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 3089811E8156 for ; Tue, 5 Nov 2013 13:17:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2A3B44012A6 for ; Tue, 5 Nov 2013 13:17:33 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [31.133.151.236] (dhcp-97ec.meeting.ietf.org [31.133.151.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CDE2A4012A5 for ; Tue, 5 Nov 2013 13:17:32 -0800 (PST) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) Message-Id: <7906D9E3-0269-4F15-B8CE-1154D4CF00D2@thomasclausen.org> Date: Tue, 5 Nov 2013 13:17:32 -0800 To: List List Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [manet] Looking at the MANET agenda again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:17:39 -0000 All, I was looking at the MANET agenda again, now that the deadline for submittin= g slides (Monday evening) has past, with the intend of preparing well for a p= roductive meeting. I notice that there's been no update to the reactive protocol draft since be= fore the Berlin IETF, and also that there are no slides uploaded for this co= ming WG meeting.=20 The logical conclusion to that is, that there has been, and is, no progress o= n this item - despite what was promised (in Orlando and in Berlin). Given that there's no progress to report on, and no new materials that the W= G can consult in preparation of Thursday's meeting, I believe that the corre= sponding agenda item is superfluous.=20 Respectfully, Thomas Sent from my iPad= From charliep@computer.org Tue Nov 5 13:25:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648AB21F967A for ; Tue, 5 Nov 2013 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlHQvchMfSqO for ; Tue, 5 Nov 2013 13:25:54 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0659A11E8156 for ; Tue, 5 Nov 2013 13:25:46 -0800 (PST) Received: from [31.133.164.223] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Vdo88-00017H-SS for manet@ietf.org; Tue, 05 Nov 2013 16:25:45 -0500 Message-ID: <52796252.8020906@computer.org> Date: Tue, 05 Nov 2013 13:25:38 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks References: <7906D9E3-0269-4F15-B8CE-1154D4CF00D2@thomasclausen.org> In-Reply-To: <7906D9E3-0269-4F15-B8CE-1154D4CF00D2@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86be657c1a44c5bdb6e3f545f4aa5d8694350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.164.223 Subject: Re: [manet] Looking at the MANET agenda again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:25:59 -0000 Hello folks, We do have progress to report, and slides. I hope we have a productive conversation. There will be an updated draft quite soon after IETF 88. Regards, Charlie P. On 11/5/2013 1:17 PM, Thomas Heide Clausen wrote: > All, > > I was looking at the MANET agenda again, now that the deadline for submitting slides (Monday evening) has past, with the intend of preparing well for a productive meeting. > > I notice that there's been no update to the reactive protocol draft since before the Berlin IETF, and also that there are no slides uploaded for this coming WG meeting. > > The logical conclusion to that is, that there has been, and is, no progress on this item - despite what was promised (in Orlando and in Berlin). > > Given that there's no progress to report on, and no new materials that the WG can consult in preparation of Thursday's meeting, I believe that the corresponding agenda item is superfluous. > > Respectfully, > > Thomas > > Sent from my iPad > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From ietf@thomasclausen.org Tue Nov 5 14:02:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E59921E8097 for ; Tue, 5 Nov 2013 14:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4unqVBePUQA for ; Tue, 5 Nov 2013 14:02:03 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D181421E80C4 for ; Tue, 5 Nov 2013 14:02:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CEE29401792 for ; Tue, 5 Nov 2013 14:02:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [31.133.151.236] (dhcp-97ec.meeting.ietf.org [31.133.151.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 93BF8401790 for ; Tue, 5 Nov 2013 14:02:03 -0800 (PST) References: <7906D9E3-0269-4F15-B8CE-1154D4CF00D2@thomasclausen.org> <52796252.8020906@computer.org> From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) In-Reply-To: <52796252.8020906@computer.org> Message-Id: Date: Tue, 5 Nov 2013 14:02:02 -0800 To: List List Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [manet] Looking at the MANET agenda again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:02:08 -0000 > On 5 nov. 2013, at 13:25, "Charles E. Perkins" wro= te: >=20 >=20 > Hello folks, >=20 > We do have progress to report, and slides. I hope we have a productive co= nversation. >=20 > There will be an updated draft quite soon after IETF 88. It's rather difficult to have a "productive conversation" about something th= at's hypothetical (happening "soon after IETF 88"), that we know nothing abo= ut and can't prepare for (no I-D, no slides, no discussion).=20 At best, it can be a monologue....which isn't the best use of WG session tim= e. Respectfully, Thomas > Regards, > Charlie P. >=20 >=20 >> On 11/5/2013 1:17 PM, Thomas Heide Clausen wrote: >> All, >>=20 >> I was looking at the MANET agenda again, now that the deadline for submit= ting slides (Monday evening) has past, with the intend of preparing well for= a productive meeting. >>=20 >> I notice that there's been no update to the reactive protocol draft since= before the Berlin IETF, and also that there are no slides uploaded for this= coming WG meeting. >>=20 >> The logical conclusion to that is, that there has been, and is, no progre= ss on this item - despite what was promised (in Orlando and in Berlin). >>=20 >> Given that there's no progress to report on, and no new materials that th= e WG can consult in preparation of Thursday's meeting, I believe that the co= rresponding agenda item is superfluous. >>=20 >> Respectfully, >>=20 >> Thomas >>=20 >> Sent from my iPad >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Nov 5 14:49:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6387411E8103 for ; Tue, 5 Nov 2013 14:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYKTJy7tC5Uz for ; Tue, 5 Nov 2013 14:49:45 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 17EF221E80BA for ; Tue, 5 Nov 2013 14:49:11 -0800 (PST) Received: from [31.133.164.223] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VdpQo-0003ww-Mc for manet@ietf.org; Tue, 05 Nov 2013 17:49:07 -0500 Message-ID: <527975DC.6040504@computer.org> Date: Tue, 05 Nov 2013 14:49:00 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list References: <7906D9E3-0269-4F15-B8CE-1154D4CF00D2@thomasclausen.org><52796252.8020906@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865bbff62473c5c64692c7cc8c3adc6d6f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.164.223 Subject: Re: [manet] Looking at the MANET agenda again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:49:50 -0000 Hello folks, The AODVv2 slides are available at the following URL: http://www.ietf.org/proceedings/88/slides/slides-88-manet-7.pdf -- Regards, Charlie P. From hrogge@googlemail.com Wed Nov 6 01:40:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B0C21E8116 for ; Wed, 6 Nov 2013 01:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MjgToR0J854 for ; Wed, 6 Nov 2013 01:40:08 -0800 (PST) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AA08821E8114 for ; Wed, 6 Nov 2013 01:40:08 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id gc15so6042554qeb.1 for ; Wed, 06 Nov 2013 01:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=tmJj1J/S5aV8OI/lzG2HaCwaPZB8d0JlWGF2R2eVkvU=; b=pwbneqs/3eNE7bReL7tXZJRUgoG57Tp/VjjaRJ6QPSDwXhOYJCJqLtDJxTvy1bKVUc a+FSQXPK3rdhOUS13RZnhM2hOK7EqGiZorvAlE0JQ7kbw7DtTjfPQCXzDvp+JhVaraqn +P/g6w3gXIgv2noPHcQAWwBWqTl5y0myaJZRWxGtpwcMZMcV3RWHA1tNa4l7l3Qta/Go MkBbgyosVepIHoCvsBq4uKd8olEYakEWrj06y0G1Yw9gACpzcRRgr0uqpG1QG7GIF9rp EzzSadJlAeRIrc2squ6PbUspCxVj38IqmQNbE26HzatRJYwwZroZ18BqisU5FnexLo58 Rqsw== X-Received: by 10.49.116.210 with SMTP id jy18mr2937823qeb.65.1383730808125; Wed, 06 Nov 2013 01:40:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.200 with HTTP; Wed, 6 Nov 2013 01:39:48 -0800 (PST) From: Henning Rogge Date: Wed, 6 Nov 2013 10:39:48 +0100 Message-ID: To: MANET IETF Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Status of DAT metric draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 09:40:09 -0000 Hi, I just wanted to notify everyone that there will be no presentation about the "Directional Airtime Metric" draft in Vancouver. This is NOT because the draft is dead but because of troubles we had with our local test network at Fraunhofer FKIE, which consumed most time in the last months. We expect to have the test network up and running within this month and I plan to attend the IETF in London to present a new draft version there. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From ulrich@herberg.name Wed Nov 6 08:34:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71D311E81E4 for ; Wed, 6 Nov 2013 08:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWfsrg19PcQM for ; Wed, 6 Nov 2013 08:34:04 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 340AA11E81DF for ; Wed, 6 Nov 2013 08:33:58 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id w20so3485494vbb.8 for ; Wed, 06 Nov 2013 08:33:57 -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; bh=dckmVaN+Mj0l56J4a0wZWrI7KS9SCA+JOfpua1MMaJQ=; b=RMvHSu4rfo7VtJKsQMIT+W5if+OE8lrSmIemK+ICnj6bem9i5GgwjnCwQJapG3s83Z VsfDJWg8TP40/IZIh/CcUYZSEL9pJ1TrBCpU7xH5ymMCOdsgBbjhO8/4+B1YaXVLv2Mu 1kR0daGCkW/5FptlqJ1fZDMMEyAbpL7B3Xv3k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dckmVaN+Mj0l56J4a0wZWrI7KS9SCA+JOfpua1MMaJQ=; b=T+yyqgKk7T1SxUgXtQWg3DBXcDIpR2E9jnM0gWc3LBz/i8VQdPiwyHxiIxK8RVRJMr kXURubRNQxjeD/pbZm4KH3vkRI5Upb9D/5eBAyBBP6dA13gnCcUqgFBv2Pg9wTqzAKhk T75QTePwNtJJVPcc5OwEDOSSyPgCDSyzydfvhRMgdwRwlPczCF1vwqQc7KZAClaWMZTd mcZWJ71UNUV/3kOUwub0jlXULZyCE95k92+PoW0cQpbtWcsv2bs/KQVXFPIQGSB10l4s 6q3yPEcb64aj8tfOCnyY14CcIUHfel8oBIoujTNFCv36OhLCCFiuMpZ0QMwodEv5z2dZ nRmg== X-Gm-Message-State: ALoCoQn/XUtX0YDU63Idlk41vCFVhLk6hqMUYGyEL3+IS8Dl3rjBXNbUxYLguSAmy8lvOiJNDLlf MIME-Version: 1.0 X-Received: by 10.220.144.80 with SMTP id y16mr3120457vcu.4.1383755637496; Wed, 06 Nov 2013 08:33:57 -0800 (PST) Received: by 10.220.253.68 with HTTP; Wed, 6 Nov 2013 08:33:57 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Nov 2013 08:33:57 -0800 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: MANET IETF Subject: Re: [manet] Status of DAT metric draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:34:05 -0000 Thanks for the info. Just to confirm, the draft you are talking about is: draft-rogge-baccelli-olsrv2-ett-metric-03 Ulrich On Wed, Nov 6, 2013 at 1:39 AM, Henning Rogge wrote: > Hi, > > I just wanted to notify everyone that there will be no presentation > about the "Directional Airtime Metric" draft in Vancouver. > > This is NOT because the draft is dead but because of troubles we had > with our local test network at Fraunhofer FKIE, which consumed most > time in the last months. > > We expect to have the test network up and running within this month > and I plan to attend the IETF in London to present a new draft version > there. > > Henning Rogge > > -- > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Nov 6 08:35:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B7E11E81DE for ; Wed, 6 Nov 2013 08:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7AiMa8cQenG for ; Wed, 6 Nov 2013 08:35:04 -0800 (PST) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 05ECC11E81FF for ; Wed, 6 Nov 2013 08:34:51 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id 8so6426206qea.4 for ; Wed, 06 Nov 2013 08:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AJ/dQf6lJuPaPLbaY62cxrT7JCef/jIoK8N40PeswhQ=; b=AOK8RIHYr9fc9hEX9sNtyWCqPPT+eRsnzuFVsRT0ZY0FFv9T5C+FrKGqf/KCFup54d 23/I2JaOBlNmQepMvpyk/wgTei3GtnRX3z1wfSYrHpG+W2avj3gPS/NtNT6nkcCKQIu6 8wTcglSYWwd3hhJf8jYhUAy3N1HU2q87Gm5ahYPOvFK+mWJH4Tbhd+MlYyHK2DOKWGKS XX41V9tIsA2Y+5nvT7fSFX6fnDOESZWggzukw1oqRHCriSZlnFOTujM36YIp00FcGux9 M0coC1M9TMy4t2tQg7M82QftZ82KAwq3clwGMkHgjq2IVXTg9NBOdWKif1kBkLJfnoW7 NLjQ== X-Received: by 10.49.117.133 with SMTP id ke5mr5551670qeb.53.1383755691193; Wed, 06 Nov 2013 08:34:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.200 with HTTP; Wed, 6 Nov 2013 08:34:31 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Wed, 6 Nov 2013 17:34:31 +0100 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: MANET IETF Subject: Re: [manet] Status of DAT metric draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:35:04 -0000 Yes. Henning Rogge On Wed, Nov 6, 2013 at 5:33 PM, Ulrich Herberg wrote: > Thanks for the info. Just to confirm, the draft you are talking about is: > draft-rogge-baccelli-olsrv2-ett-metric-03 > > Ulrich > > On Wed, Nov 6, 2013 at 1:39 AM, Henning Rogge wrote: >> Hi, >> >> I just wanted to notify everyone that there will be no presentation >> about the "Directional Airtime Metric" draft in Vancouver. >> >> This is NOT because the draft is dead but because of troubles we had >> with our local test network at Fraunhofer FKIE, which consumed most >> time in the last months. >> >> We expect to have the test network up and running within this month >> and I plan to attend the IETF in London to present a new draft version >> there. >> >> Henning Rogge >> >> -- >> We began as wanderers, and we are wanderers still. We have lingered >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From ulrich@herberg.name Wed Nov 6 12:26:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0081A21E8175 for ; Wed, 6 Nov 2013 12:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt5ZrWUi2QoR for ; Wed, 6 Nov 2013 12:26:06 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 45BE221E8089 for ; Wed, 6 Nov 2013 12:26:06 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id cz12so13290veb.38 for ; Wed, 06 Nov 2013 12:26:05 -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=MnytPZ0VLFFrWCHa7lLvsc22H+1SYwa262RGY4Ho95c=; b=xEmCPBJy66uW3smfWOe9eUwtR45r7Cn52vKfdDDDpNEGA6HaxBO3CYd18WHC9GPqGX /uW3TPyojtwo8C+Pm0n8F8oJ8vXuEn/GIJBdO0mStQhzRPon3Ksmj1vobz36s1t3/mJF OwveMMmjIfwms/beYcUKEs4naXoFxXHGcRYoY= 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=MnytPZ0VLFFrWCHa7lLvsc22H+1SYwa262RGY4Ho95c=; b=h9JsPAFTRJI3Rib593Cwcl3DDY00kkDs+mIn73HK3dcFQXixj4lZ3sBez92b9Ji+Mv 2M4KQ+FhDwB7bg+TMt81oP5v97XxzEk2mjovlUDMBvmqMB0oCWLtp0uiu9zLt/zcwLqS 5+3XmVIuc1j+fgHrEcb39PUWDLOW/VxnIP1oP3rdSuheriK6zrWZJwD8glnoXdKfPzAG UJrPyYAxbbobpnvw6B9hU/WcYYtF+uaz+gXFYkronEZxYQqu6Jb8EBhxpgbDN1OH+D5Y g9IWggJtJK5OOypou6HKpLd3HgoeCbw1nBnE9AZP8NV9wzu4qkmM1eG/EnuzG8+ghnjZ hdMQ== X-Gm-Message-State: ALoCoQmynxsrT1QPNENXKN9php0J38nBQHI8Pf2pp5qJeIyBYBGF+96z5RuWQi/GUcni9Gtj9jtN MIME-Version: 1.0 X-Received: by 10.58.19.195 with SMTP id h3mr91389vee.48.1383769565799; Wed, 06 Nov 2013 12:26:05 -0800 (PST) Received: by 10.220.253.68 with HTTP; Wed, 6 Nov 2013 12:26:05 -0800 (PST) Date: Wed, 6 Nov 2013 12:26:05 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] PLEASE: Re: Minutes taker and scribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:26:07 -0000 I have found a scribe, but no minutes takers yet. I can help with typing the minutes myself, but a second person would be really good. Ulrich On Tue, Nov 5, 2013 at 8:00 AM, Ulrich Herberg wrote: > We need two minutes takers and a jabber scribe for the MANET meeting > on Thursday. I would greatly appreciate if I can get some volunteers. > Just shoot me an email. > > Thanks > Ulrich From charliep@computer.org Wed Nov 6 13:58:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C7B11E8132 for ; Wed, 6 Nov 2013 13:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dkWi-Z6NvDM for ; Wed, 6 Nov 2013 13:58:31 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0811E815B for ; Wed, 6 Nov 2013 13:58:31 -0800 (PST) Received: from [31.133.163.28] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VeB7O-0006EW-7O; Wed, 06 Nov 2013 16:58:30 -0500 Message-ID: <527ABB65.6060706@computer.org> Date: Wed, 06 Nov 2013 13:57:57 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ulrich Herberg , manet@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86383014abc61a7abe07bc8e6770959fe4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.163.28 Subject: Re: [manet] PLEASE: Re: Minutes taker and scribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:58:36 -0000 Hello Ulrich, I'll take minutes also. Regards, Charlie P. On 11/6/2013 12:26 PM, Ulrich Herberg wrote: > I have found a scribe, but no minutes takers yet. I can help with > typing the minutes myself, but a second person would be really good. > > Ulrich > > > On Tue, Nov 5, 2013 at 8:00 AM, Ulrich Herberg wrote: >> We need two minutes takers and a jabber scribe for the MANET meeting >> on Thursday. I would greatly appreciate if I can get some volunteers. >> Just shoot me an email. >> >> Thanks >> Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From ulrich@herberg.name Wed Nov 6 13:59:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5F921E8155 for ; Wed, 6 Nov 2013 13:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEze-kWO1EDi for ; Wed, 6 Nov 2013 13:59:29 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2AD21E81AB for ; Wed, 6 Nov 2013 13:59:05 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so95312veb.13 for ; Wed, 06 Nov 2013 13:59:05 -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; bh=p4kOnG7Cg56w/SvvsIhDuyQoY6/1kMgYtnXqUw2ZddM=; b=nbJz8vjRn4pDjv3ybK7gEyfaCpthD3coOfZKDOq26iGt28fDcBAHEry1NXsEW4d8pl huOP3+MTkwpB0go2vWtYktaSOnpleGbfZ4/LJej01AlMxGTTZ4oVu9AYie6n2M1Z8uZQ +3sX12G1gBEh6rGx4OA2vNvSK+b6pRbdxwaiY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p4kOnG7Cg56w/SvvsIhDuyQoY6/1kMgYtnXqUw2ZddM=; b=L7jttPHStEQRwjG2fdgTIfPNJmGZkkPcVzA4IG1FGFHSVzJuyn2+iRmXhdLfEms3M1 8CGR2osOQnnBPVUXxPziUAAlHYr+eeovP1JDNdZ6JkCmUjUTGvbYES3SUmgczokgXm7Y RL+eeynEViMVWa9MUQ4E7pzh195Fq8oAHhylekBpNR1mVPzC/8TbzK9pJtty7AwCg0q0 Bb7jSOTzpntWBXJd1U/CKQP11yIvppuSpvvGhYw5R+VguLo1WdCO1YEMsv8PH0Uax279 yXONGUie8l3xy35wRavuldH/tKNO3kb0nQGQSE6KsJWo+oXBy/kgmNKZ2136SrA+10QY eAJA== X-Gm-Message-State: ALoCoQl3W8B8mMToF8ivVX/ZsXahHMzxLKf5GQ0Uzdv9CO3i+Tkfc8B0EZHdqpv/ybTSDvFDOK+o MIME-Version: 1.0 X-Received: by 10.58.107.204 with SMTP id he12mr4134625veb.26.1383775145556; Wed, 06 Nov 2013 13:59:05 -0800 (PST) Received: by 10.220.253.68 with HTTP; Wed, 6 Nov 2013 13:59:05 -0800 (PST) In-Reply-To: <527ABB65.6060706@computer.org> References: <527ABB65.6060706@computer.org> Date: Wed, 6 Nov 2013 13:59:05 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] PLEASE: Re: Minutes taker and scribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:59:30 -0000 Thank you! Ulrich On Wed, Nov 6, 2013 at 1:57 PM, Charles E. Perkins wrote: > Hello Ulrich, > > I'll take minutes also. > > Regards, > Charlie P. > > > On 11/6/2013 12:26 PM, Ulrich Herberg wrote: >> >> I have found a scribe, but no minutes takers yet. I can help with >> typing the minutes myself, but a second person would be really good. >> >> Ulrich >> >> >> On Tue, Nov 5, 2013 at 8:00 AM, Ulrich Herberg >> wrote: >>> >>> We need two minutes takers and a jabber scribe for the MANET meeting >>> on Thursday. I would greatly appreciate if I can get some volunteers. >>> Just shoot me an email. >>> >>> Thanks >>> Ulrich >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > From ietf@thomasclausen.org Fri Nov 8 11:45:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFA911E81D9 for ; Fri, 8 Nov 2013 11:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8MnWgdLzcw7 for ; Fri, 8 Nov 2013 11:44:53 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 79DA311E81B6 for ; Fri, 8 Nov 2013 11:44:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F1CF21C07C1; Fri, 8 Nov 2013 11:44:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [31.133.151.236] (dhcp-97ec.meeting.ietf.org [31.133.151.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AF9D31C052F; Fri, 8 Nov 2013 11:44:19 -0800 (PST) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) Message-Id: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> Date: Fri, 8 Nov 2013 11:44:18 -0800 To: List List , Stan Ratliff , Joe Macker , Joe Macker , Adrian Farrel Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:45:03 -0000 Stan Ratliff asked me to bring some of the comments I made at the mike durin= g the MANET wg meeting yesterday, to the list. I believe that this is a good= idea, if for nothing else but to enter them into public record.=20 I realize, though, that the points I raised during the meeting yesterday act= ually already ARE public record, and have been so since 2010: http://www.ietf.org/mail-archive/web/manet/current/msg11858.html So, I'll hereby go on public record indicating that I've been on public reco= rd with these things since 2010... 1) The detailed review comments that I gave to the reactive protocol (at the= time, known under the name DYMO) during the Maastricht IETF'78 (in 2010) st= ill largely apply to the current incarnation of the MANET reactive protocol.= My review comments were posted to the MANET mailing list, and are on record= in the archives: http://www.ietf.org/mail-archive/web/manet/current/msg11858.html Around at the same time, other reviews were posted by others. A quick skim t= hrough these indicate that many of those review comments have not been addre= ssed either. I believe that it would have behoved the authors to look through these revie= ws when reviving this activity, and to ensure that the comments were reflect= ed in the document - or, deflected through discussion on the list. Alas, giv= en that such reviews (still) have not been throughly addressed by the most r= ecent WG document, I'm not sure that providing a review again saying the sam= e is any good use of my (or WG) time.=20 2) RFC5444 is used wrongly in the document: positional semantics of address,= and semantics of an address given by its mere presence in a message, has a= s consequence that it is nigh impossible to develop extensions that are back= wards compatible. It's a comment that the WG well should be aware of, as it w= as raised in the context of early versions of DLEP (where it was promptly re= solved).=20 Note: This issue also was raised in the review cited under point 1.= The document must be=20 substantially revised to this effect. 3) The document is extremely unstructured. When I get a message X, then what= procedure must I follow? This information is scattered throughout the 60ish= pages, and it renders it extremely complicated to even begin to understand h= ow to implement correctly. I've read the document on the way over to Vancouv= er, and I've read it again this morning. I still can't properly draw the sta= te machines, and there're processing bits that I *think* are not specified (= but maybe reading it a 3rd time is required). The point here is, the IETF wr= ites specifications so as to help implementers make correct implementations.= This document makes it a lot of work to try to figure out what's supposed t= o be implemented. Note: This issue also was raised in the review cited under point 1.= The document must be substantially revised to this effect. 4) The document employs sloppy terminology and invented (and redundant) non-= standard terminology. For example, but non-exhaustively, the terms "Routing c= lient" and "node" - why not the well-defined terms "host" and "router"?=20 Note: This issue also was raised in the review cited under point 1.= The document must be=20 substantially revised to this effect. 5) I am worrying that there are virtually non-existent security consideratio= ns in this document. In part, "in this day and age, this is unacceptable", b= ut more pragmatically, having seen the (justified) scrutiny that the SEC-DIR= and SEC ADs apply to documents they review, this won't pass muster.=20 Note: This issue was only touched upon in the review cited under po= int 1. But, I still believe that the document must be substantially revis= ed to this effect. 6) The document is ripe with options, often expressed vaguely "XX should be d= one, you can do that by, for example ZZ, YY or WW....", and that makes me wo= rried. Options means code branches, which means more test-cases to run throu= gh (and, more branches in an interoperability test). It also means, that if a= n implementation "does XX by way of ZZ", will that, or will that not, intero= perate with an implementation that "does XX by way of WW"?=20 I believe that the author presenting implicitly acknowledged that such optio= ns make things complicated - by saying that the first implementation that he= intended to produce would be very partial and include only a "core" without= options.=20 Note: I have numerous times (since the last Paris IETF, at least) s= uggested that in that case=20 it's miles better to produce a document with that minimal "core", l= eaving options for a later=20 process. 7) Given that the above comments have been made ad infinitum since Maastrich= t, on the list and in WG meetings, without seeing any improvement of the doc= ument, it is hard to justify the efforts of making further reviews or commen= ts: so far, such have been ignored. A good start would be to incorporate tho= se reviews, for the authors to show "good faith" and listen to the WG. 8) Given that the past 12 months, when the effort was "rebooted" by the resp= onsible AD, have yielded no improvement of the document quality, and has see= n none of the comments previously made, it's hard to have confidence in this= document going forward - and, therefore, it is hard to justify the WG spend= ing further time on this document (across all venues) Respectfully, Thomas Sent from my iPad= From charliep@computer.org Sat Nov 9 05:27:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C521E80B8 for ; Sat, 9 Nov 2013 05:27:41 -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=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxf5aSK9BbVl for ; Sat, 9 Nov 2013 05:27: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 102B111E80ED for ; Sat, 9 Nov 2013 05:27:35 -0800 (PST) Received: from [64.183.192.90] (helo=[172.20.102.81]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Vf8Za-00025c-Mj; Sat, 09 Nov 2013 08:27:34 -0500 Message-ID: <527E383D.8030505@computer.org> Date: Sat, 09 Nov 2013 05:27:25 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: List List References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> In-Reply-To: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867cc205060bc539b31dcae38e09f9cdfa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.183.192.90 Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 13:27:41 -0000 Hello folks, I'm traveling and don't have time just now to go dig out the precise emails. But, given the tone of this email, I thought it appropriate to at least make an initial response. Inline below. On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote: > Stan Ratliff asked me to bring some of the comments I made at the mike during the MANET wg meeting yesterday, to the list. I believe that this is a good idea, if for nothing else but to enter them into public record. > > I realize, though, that the points I raised during the meeting yesterday actually already ARE public record, and have been so since 2010: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > So, I'll hereby go on public record indicating that I've been on public record with these things since 2010... > > 1) The detailed review comments that I gave to the reactive protocol (at the time, known under the name DYMO) during the Maastricht IETF'78 (in 2010) still largely apply to the current incarnation of the MANET reactive protocol. My review comments were posted to the MANET mailing list, and are on record in the archives: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > Around at the same time, other reviews were posted by others. A quick skim through these indicate that many of those review comments have not been addressed either. > I believe that it would have behoved the authors to look through these reviews when reviving this activity, and to ensure that the comments were reflected in the document - or, deflected through discussion on the list. Alas, given that such reviews (still) have not been throughly addressed by the most recent WG document, I'm not sure that providing a review again saying the same is any good use of my (or WG) time. I did in fact address these issues, resulting in a thoroughgoing revision of the document. I got no feedback at the time, and so thought there wasn't much more to do. It would be nice to see just what particular points remain to do, especially if they were put on the issue tracker. > 2) RFC5444 is used wrongly in the document: positional semantics of address, and semantics of an address given by its mere presence in a message, has as consequence that it is nigh impossible to develop extensions that are backwards compatible. It's a comment that the WG well should be aware of, as it was raised in the context of early versions of DLEP (where it was promptly resolved). > > Note: This issue also was raised in the review cited under point 1.The document must be > substantially revised to this effect. Similarly, I did address these issues and as far as I know the current specification is in conformance with RFC 5444. > > 3) The document is extremely unstructured. When I get a message X, then what procedure must I follow? This information is scattered throughout the 60ish pages, and it renders it extremely complicated to even begin to understand how to implement correctly. I've read the document on the way over to Vancouver, and I've read it again this morning. I still can't properly draw the state machines, and there're processing bits that I *think* are not specified (but maybe reading it a 3rd time is required). The point here is, the IETF writes specifications so as to help implementers make correct implementations. This document makes it a lot of work to try to figure out what's supposed to be implemented. > > Note: This issue also was raised in the review cited under point 1.The document must be > substantially revised to this effect. Similarly, I did address this issue. However, one person's view of proper structure may differ from another person's view. If there are any questions about how to follow a procedure, they should be pointed out. Cross references can be inserted as needed, or document sections rearranged. I already did a lot of rearrangement, but I am certainly willing to do more. > > 4) The document employs sloppy terminology and invented (and redundant) non-standard terminology. For example, but non-exhaustively, the terms "Routing client" and "node" - why not the well-defined terms "host" and "router"? > > Note: This issue also was raised in the review cited under point 1.The document must be > substantially revised to this effect. The terms cited above have particular meanings in the document. The suggested terms "host" and "router" do not capture the more specific meanings required at certain points in the document. > > 5) I am worrying that there are virtually non-existent security considerations in this document. In part, "in this day and age, this is unacceptable", but more pragmatically, having seen the (justified) scrutiny that the SEC-DIR and SEC ADs apply to documents they review, this won't pass muster. > > Note: This issue was only touched upon in the review cited under point 1. > But, I still believe that the document must be substantially revised to this effect. As best I understand, the security considerations are sufficient. This is a topic that deserves more attention. > > 6) The document is ripe with options, often expressed vaguely "XX should be done, you can do that by, for example ZZ, YY or WW....", and that makes me worried. Options means code branches, which means more test-cases to run through (and, more branches in an interoperability test). It also means, that if an implementation "does XX by way of ZZ", will that, or will that not, interoperate with an implementation that "does XX by way of WW"? > > I believe that the author presenting implicitly acknowledged that such options make things complicated - by saying that the first implementation that he intended to produce would be very partial and include only a "core" without options. This is a very generic comment that applies to practically every protocol in the IETF, including DHCP, IPv6, SIP, IP, TCP, Mobile IP, ... The "complication" alluded to is far less than in most existing protocols, and (again) has been thoroughly understood from past work. > > Note: I have numerous times (since the last Paris IETF, at least) suggested that in that case > it's miles better to produce a document with that minimal "core", leaving options for a later > process. This ignores the fact that the optional features have been well known for many years, and in fact the current division of functionality into "base" versus "option" was done in response to previous requests. I am not aware of any IETF requirement to delete all optional features when producing base documents. > > 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG. This is a gross misrepresentation of fact, and as best I can tell the person making this complaint has made very little effort been made to review recent versions of the document, despite my requests. If further elaboration is needed I will go back and find the relevant emails, but right now I can't do that. ==================================================== Having said all that, I encourage constructive dialog and more detailed suggestions about how to improve document structure and terminology. I think it is appropriate to move forward with the document including the current optional features, or perhaps including also the intermediate route reply which is a feature that was originally specified in the base document and has long been part of the reactive routing protocol development. If specific suggestions are made to improve the document structure or terminology (again, much better if posted to the issue tracker), I can respond much more effectively and will make document revisions in a timely fashion. -- Regards, Charlie P. From ha.rezaii@gmail.com Sun Nov 10 00:36:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768C221F9D19 for ; Sun, 10 Nov 2013 00:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62J4xL-Bdpl5 for ; Sun, 10 Nov 2013 00:36:55 -0800 (PST) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 213BC21F9D28 for ; Sun, 10 Nov 2013 00:36:39 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id u10so1298888bkz.35 for ; Sun, 10 Nov 2013 00:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=njK4CGjQuM6QggRedL09sWh/z4O9Ji0ujapvlRxIOjI=; b=AZSbjuzjnRrqf9Sj7zrzpxTJvaJCRI8FLS23LKOZDXNvZDLtBImZcaKHvGVyzpxUw/ 462T1EVRSzfPqyBvH2PyvPnoht2BsTaFsmX8V3ALLTlUFamfzQxLE1o1M6Wjq5gjZ37O cSavUHMBFJZL2l5+v2I8fP3SMtBmjvLRTiGfXMZ0+SXo0ovxIzU9/mENkxx/Tyjq6boa qrig9F+3ZPUEXz7T4LD85UvCQ3VGyijaJWtXYMjdAZjLDk86Ug6Rt7SS34YHJNE8jKFl 6WnZLKuBuUD7Z1broBz4IOXfV8yxpRl/7q7EzPkdfNJaeduMYH4+spbQJ2LU36OL12mt EFbg== X-Received: by 10.205.20.74 with SMTP id qn10mr80240bkb.46.1384072592456; Sun, 10 Nov 2013 00:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.243.3 with HTTP; Sun, 10 Nov 2013 00:35:52 -0800 (PST) From: =?UTF-8?B?2K3Yp9mF2K8g2LHYttin2KbZig==?= Date: Sun, 10 Nov 2013 12:05:52 +0330 Message-ID: To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Fwd: Implementation of IEEE 802.15.6 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 08:36:55 -0000 Dear All, Anyone knows if there is an existing implementation of IEEE 802.15.6, and if not implemented why it was not implemented? Regards From georg.wittenburg@fu-berlin.de Sun Nov 10 17:11:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532CA21E8197 for ; Sun, 10 Nov 2013 17:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6Hp4zAJggYQ for ; Sun, 10 Nov 2013 17:11:33 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0F311E81D1 for ; Sun, 10 Nov 2013 17:11:32 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1Vfg2M-003C63-J6>; Mon, 11 Nov 2013 02:11:30 +0100 Received: from cpe-108-182-68-141.nyc.res.rr.com ([108.182.68.141] helo=[192.168.0.11]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1Vfg2M-002owz-8y>; Mon, 11 Nov 2013 02:11:30 +0100 Message-ID: <52802EC0.8080906@fu-berlin.de> Date: Sun, 10 Nov 2013 20:11:28 -0500 From: Georg Wittenburg Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <201101121219.58614.georg.wittenburg@gmail.com> <50857817.1010602@computer.org> In-Reply-To: <50857817.1010602@computer.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8gRhXmD63glvDEaAuA1ER2V88PCckpRRg" X-Originating-IP: 108.182.68.141 X-Mailman-Approved-At: Sun, 10 Nov 2013 17:16:21 -0800 Cc: manet@ietf.org Subject: Re: [manet] Review of DYMO Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 01:13:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8gRhXmD63glvDEaAuA1ER2V88PCckpRRg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Charles, I guess now it's my turn for apologizing after taking overly long in getting back to you. First off, very glad I could contribute to AODVv2 with my feedback. To answer the question in your mail below, regarding whether it would be better to have AODVv2 parameters resemble those of AODV more closely (as opposed to those of DYMO) here's my view: The key benefit of the AODV spec over the DYMO spec used to be that it was clear how protocol parameters were derived from network properties, e.g., timeouts being derived from expected maximal network diameter. It would be great if AODVv2 could establish a similar level of transparency, and possibly suggest defaults for some typical deployments. If you're interested in specific parameter values, the values I used in my deployments were a mix of DYMO and AODV values. These values provided best layer 3 connectivity for the applications I was evaluating at the time on our 36-node IEEE 802.11b testbed. The exact values are listed on page 180 of the document at http://page.mi.fu-berlin.de/gwitten/papers/wittenburg10spi.pdf. Let me know in case there are more questions. Best, Georg Dr. Georg Wittenburg Freie Universit=E4t Berlin http://page.mi.fu-berlin.de/gwitten/index.html On 22.10.2012 12:45, Charles E. Perkins wrote: > > Hello Georg, > > Please excuse the long delay in responding to your comments. > > On 1/12/2011 3:19 AM, Georg Wittenburg wrote: > >> - 3. Terminology >> >> The reserved numeric values for unknown Distance (Dist) and Sequence >> Number >> (SeqNum) should be stated somewhere, preferably in this section. One >> could >> probably use zero (0), but it would be helpful to have some explicit >> statement >> about this. > > For both Distance and SeqNum, I included a sentence in the definition. > However, since the current distance is always a hop count, 65,535 does > not make sense as a maximum value, whereas 0 *is* a valid distance > value. > > I changed the spec as follows: > The minimum value of distance is the number of IP hops > traversed, 0 for local information. The maximum value > is 254. The value 255 is reserved to indicate that the > distance is unknown. > and > The value zero (0) is reserved to indicate that the SeqNum > for a destination address is unknown. > > >> - 4.2.2. Routing Messages (RM) - RREQ & RREP >> >> TargetNode.AddTLV.Dist is listed as an optional field, but not used >> anywhere in >> the document > > I have removed this from the base specification. > > >> >> >> - 5.3.1. RREQ Creation >> >> There should be an explanation why OrigNode.Dist is to be set to a >> number >> greater than zero and some advice on which value to use. > > Done. > >> >> In fact, I'm somewhat doubtful about the Dist field in general. Sec. >> 5.2.2 >> states that when creating or updating a routing table entry "if >> known, the >> Route.Dist is set to the Node.Dist". Node.Dist, in this context, is >> set by the >> sender of the routing message. However, for any non-trivial metric, th= e >> distance (i.e., the path metric) should differ depending on the link >> quality >> between sender and each of the potentially multiple receivers of a >> routing >> message. Hence, it should be up to each receiver to calculate Dist >> depending >> on the link quality (rather than using the sender-specified Node.Dist >> from the >> routing message which would be the same for all receivers). > > I agree with this, and after the revision to be submitted today, I > will work on using nontrivial metrics with AODVv2. I will also post > the issue on the Issue Tracker. > >> - 5.3.1. RREQ Creation >> >> The statement "For links that do not support multicast or situations i= n >> which unicast messaging is preferred, the IP.DestinationAddress for >> unicast >> RREQ is set to the NextHopAddress." could be more clear about what >> NextHopAddress (=3D IP address of the respective unicast destination) >> means in >> this context. The same applies to Sec. 5.5.3. "RERR Generation". > > Yes. I have made some clarification about this. > > >> - 5.3.4. RM Handling >> >> I found it slightly confusing that the processing of RREQs and RREPs i= s >> presented in the same section. Personally, I would have preferred two >> separate >> sections for each of them, which the commonalities (i.e., shared code >> in the >> implementation) in specific sub-section. > > I hope that the new draft is much clearer about this. > > >> - 5.5.2. Updating Route Lifetimes During Packet Forwarding >> >> If the processing of a data packet causes the routing timers to be >> reset (as >> specified in the draft), then the respective Route.Broken flag should >> also be >> cleared and the Route.Forwarding flag should set. This covers the >> case in which >> data packets arrive from a next-hop neighbor for which a route has >> been flagged >> as broken, but has not yet been removed from the routing table. > > Thanks for catching this. I have added the following for both cases: > "The Route.Broken flag is unset." > The Route.Forwarding flag was removed from the draft. > > >> Further, the timers for a routing table entry should be reset when >> processing >> both data AND signaling packets (i.e., RREQs and RREPs). Otherwise, >> existing >> routes along which these packets are forwarded may get deleted before >> seeing >> any data traffic. Note that for RREPs this includes the timers for >> the routing >> table entries to both the originator and target node. > > Yes, this is also true. I have changed the draft to refer to AODVv2 > messages as well as data packets. > >> >> Similarly, when sending an intermediate RREP (Sec. 5.3.3), the timers >> for the >> routing table entry of the TargetNode should also be reset. >> >> >> - 6. Administratively Configured Parameters and Timer Values >> >> The default value of ROUTE_SEQNUM_AGE_MAX_TIMEOUT (60 seconds) may cau= se >> low-bandwidth routes to be discarded prematurely. As the tradeoffs >> are non- >> obvious, it would be nice to have multiple recommendations for differe= nt >> scenarios. I realize that this may require more real-world experience >> with the >> protocol, but don't really consider this to be a counterargument. > > I definitely agree with this. I don't think there are any realistic > use cases where this TIMEOUT needs to be less than 600 seconds, and > probably the TIMEOUT should be even much longer than that. > > In the meantime, I will change 60 to 600. > > >> Similarly, the value for ROUTE_RREQ_WAIT_TIME (2 seconds) should be mo= re >> expressive. For instance, AODV (RFC 3561) uses NET_TRAVERSAL_TIME =3D = 2 * >> NODE_TRAVERSAL_TIME * NET_DIAMETER =3D 2 * 0.04s * 35 =3D 2.8s. A simi= larly >> detailed definition should be used in this draft. Furthermore, the >> value should >> be large enough to give retries of RREQs a chance to succeed >> (possibly taking >> lower TTLs into account, if expanded ring search is employed). >> >> Finally, the statement "The above timing parameter values work well >> for small >> and medium well-connected networks with moderate topology changes." >> is a too >> general to be useful. Once again, exact values for the number of >> nodes and the >> node degree that led to this recommendation would be more helpful. > > I hope that we can get some more recommendations for these. > My belief is that the timeout parameters are all too small. > Also, there have been experiments networks with greater than > 10 hops running AODV, so I changed the MSG_HOPLIMIT to be 20. > In AODV, NET_DIAMETER was 35, and NET_DIAMETER should be less > than MSG_HOPLIMIT. > > What if I change the AODVv2 parameters to match the AODV > parameters more closely? > --8gRhXmD63glvDEaAuA1ER2V88PCckpRRg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgC7AAAoJEI4rXcOKDq3JidoQAJGQXnUghiPHy6wxFjuB+CaD m0hsGo6OQaT/mgE0VqKRwQARMlOvxdoptvziat65alNPSzO/00AlKOPvx+HZ4I2C JAbPMMGO8L2pE1qQ98LPuIvUo7YKQOktIeyloskZG6ZmRLznNpphse5MSDPvHwmG 1FEQlmoWaRmBNkLKtSoa0JJKWT3Bh+QbH2F44vH2GFp+kOnRCArRyqjQPCvzeb7s iWO6Bse1WI3btQZ7BdkLsyrNdFPEojQMBiR/L9BsAMe17D0FNaCr6RR4TYKzqjiI xcDDkRbKmQxRCW6RmYUgpO5z3ZWEVW3AA+07/08KzZ/gWA9oIy1KudwfRd73AYN7 /Lk3t+GR0VcKr9yjZePC9esUH+luR3Hcc3zUKIKuo43HoLuQv9LlhIhj8VHcRwKL pnKbZLkNcZ+gg0UX1eB8UXeh5tbPMl7ubgY8sLxmplWwMXADbt/3GnT35BlZT2Z9 fQYG8VLr3UJ9HutuTE2S7Uo516LbwGQwKg5UeUdjGFpnUcFhTM4ikr75h7Zr0rfP YjnVaDDNi/5rDqBtkGO7UvJSwo1L4QFkLMbPGh2w4T42MJ9eSJraGe/8eeQTOGp4 NgsxeWM4YP0gUW5YmSC6Fy7PCoCPsC4+B7Dz16GeALCJV7ESHIArMtGi16sTIBTT mhLslT/sOAMhNaVw8JQV =8jI0 -----END PGP SIGNATURE----- --8gRhXmD63glvDEaAuA1ER2V88PCckpRRg-- From ulrich@herberg.name Sun Nov 10 17:38:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54E721E81A2 for ; Sun, 10 Nov 2013 17:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg3NNzs3dB2W for ; Sun, 10 Nov 2013 17:37:58 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 71DDE21E81A0 for ; Sun, 10 Nov 2013 17:37:58 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ht17so737178vcb.6 for ; Sun, 10 Nov 2013 17:37:55 -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=OOSRK/36x4fBkBziTIgPfstVeJVRbYMTDKylP6dpUzE=; b=sVX6DqoqUeKk2XlHHZpvuJdUH5H6Y/Rrt9z323cmuNblgEP4Hiimq3dIA3WE7Yla8W 4f2TAubFVJAM/Zsw1KNWxTsXrBoMolWtpvl7b1TRQi4lwh7L+myNq2coynhSBo5AlsfV HVwxvcnbIFcvC77HXa3iru9PoD/hW3pK5zY34= 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=OOSRK/36x4fBkBziTIgPfstVeJVRbYMTDKylP6dpUzE=; b=IFMx9DqweHDjuQjLkI42dVloVjCPW7Ilyz63kxrFMCzADJ47CGfdzLT2ZqQawMxPCt MEe+B0VNnTzorr8QgE7zgn5JWEK20M2EHISDdDF3IqCN7NvfjyhO5fpbDFvXH83iNmM0 EFN3BvQFUxZfvz1OWNfAJFs3OfNDx5mW16VTXMaEckJQ+fgm714hvECP2wnME2SQuSUf YuOJQxnhZK8mQUJm/eO5lkKArBtEdxFieD4d0ZzE9Lndlbt4EqBe/IZ8AkYKKeNWfRi/ Ah1c3HinV8hvvpiSd62Er1cm07QOfh8Xm4zfyGhWMiYjxdL50YY7mUkDMJg0N5NGJnIj bUqg== X-Gm-Message-State: ALoCoQlXq2/5TGVawnT5UbNINJQ8pmNdlGEPPv/auwCQI3jQtOlUhyz6lUmH2W53l0nZzxhVh5Nw MIME-Version: 1.0 X-Received: by 10.220.192.198 with SMTP id dr6mr4068732vcb.19.1384133875312; Sun, 10 Nov 2013 17:37:55 -0800 (PST) Received: by 10.220.253.68 with HTTP; Sun, 10 Nov 2013 17:37:55 -0800 (PST) Date: Sun, 10 Nov 2013 17:37:55 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 01:38:00 -0000 I have uploaded the minutes I took at: http://www.ietf.org/proceedings/88/minutes/minutes-88-manet Please check for correctness and completeness. Ulrich From abdussalambaryun@gmail.com Sun Nov 10 21:53:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44D321E8064 for ; Sun, 10 Nov 2013 21:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU5AEYzwRooa for ; Sun, 10 Nov 2013 21:53:09 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 843C221E805F for ; Sun, 10 Nov 2013 21:53:09 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kq14so4876631pab.21 for ; Sun, 10 Nov 2013 21:53:09 -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=ljtwxO3Jh0Bvw93v+l5/ZSXmRvd1SrquLx/9NqvnWGQ=; b=LVBSU/DPvgnsQCKCDNAqRJa4kcgQWRBEsLgCmJfHwlWkyIiVpT4b5eJDEFxiMjJH81 58bOLY73jeqbAxBROM01PebL8ctB1BXtPA2CtUbV1/t2UT+K8fii8G7mA6lRTEL5a427 zrmccYH/3w5pmnCphUzd8s92OYzt2oCH71k8jz8a3ipOHFVqFCFhRkBhyYz4DVqTt9yd kt/ed/a2xQfmcz4ixPdDXzXEHsy0AFRRrSr7g7dg8suGT+2FyDFXn4nNmt1JFoRcUdtE B6XB6VbGb/Tuwrg5rrEGbR62W95XdzkJU/nwkWYbzH0XVW7diMe4EU+INvAaj0qLsGPL ArOQ== MIME-Version: 1.0 X-Received: by 10.66.190.10 with SMTP id gm10mr5836605pac.126.1384149189010; Sun, 10 Nov 2013 21:53:09 -0800 (PST) Received: by 10.69.8.5 with HTTP; Sun, 10 Nov 2013 21:53:08 -0800 (PST) Date: Mon, 11 Nov 2013 06:53:08 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7bf1656eba2bc604eae0586c Subject: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 05:53:10 -0000 --047d7bf1656eba2bc604eae0586c Content-Type: text/plain; charset=ISO-8859-1 I don't know what is the design team doing, I did not see on the list progress on DLEP. I did not follow meeting this year, but just now seen minutes submitted. I object secret talks, and support Thomas's comments in the meetings regarding it should be more open. Please not DT has no authority, and I am not finding a DT list nor reports. AB --047d7bf1656eba2bc604eae0586c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't know what is the design team doing, I did not see on the list p= rogress on DLEP. I did not follow meeting this year, but just now seen minu= tes submitted. I=A0object secret talks, and support Thomas's comments i= n the meetings regarding it should be more open. Please not DT has no autho= rity, and I am not finding a DT list nor reports.

AB
--047d7bf1656eba2bc604eae0586c-- From abdussalambaryun@gmail.com Sun Nov 10 22:10:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB8D21E80CC for ; Sun, 10 Nov 2013 22:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgln1i9dJH8x for ; Sun, 10 Nov 2013 22:10:02 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9321E8064 for ; Sun, 10 Nov 2013 22:10:01 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id y13so1913282pdi.27 for ; Sun, 10 Nov 2013 22:09:49 -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=RhA9B7qm/oZTH7qTQ3p37jcdbZT61emSmgLzwKegH3k=; b=xwgoxBSWIDVjtlmRxYktPb9j92tVfvfUcT9rkr4GuEcUtA2+4f0VgvN5E4/7z6XYtV FrVDRFRVedh22eqHEQTWD7bTWOspRsUbaSBCJtMlSEI0ZzTPOH101EvPHqZeu3251lfc dZYtE7hs6TqhpoO62HP/7h4rprQfnrc+ujOtIVYbIGTXMPdBScd55vz53f6w8bFedxso sgGUeLwTn6pRwMrYQrGNM8P1guHxjtM+Ejy+0EDaciKhM0dXMa2+q2VuTUn5Z3X+d2e/ jjUHWP2zo8dqgFHAupXdxhkkB/DKLPsEOaIB0i+AoIW74Oe7xXE1q8dMVbxxcBFiy6Bb 6d+g== MIME-Version: 1.0 X-Received: by 10.66.235.106 with SMTP id ul10mr28776871pac.19.1384150189581; Sun, 10 Nov 2013 22:09:49 -0800 (PST) Received: by 10.69.8.5 with HTTP; Sun, 10 Nov 2013 22:09:49 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Nov 2013 07:09:49 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b111d195dae7a04eae0942e Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 06:10:03 -0000 --047d7b111d195dae7a04eae0942e Content-Type: text/plain; charset=ISO-8859-1 If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I recommend release adoptation first. Why we have a discussion list if we don't discuss and leave it to DT to have the fun? IMHO the draft is adopted work then it should not become a DT work only after consensus decision. AB On Monday, November 11, 2013, Abdussalam Baryun wrote: > I don't know what is the design team doing, I did not see on the list > progress on DLEP. I did not follow meeting this year, but just now seen > minutes submitted. I object secret talks, and support Thomas's comments in > the meetings regarding it should be more open. Please not DT has no > authority, and I am not finding a DT list nor reports. > > AB > --047d7b111d195dae7a04eae0942e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does= I recommend release adoptation=A0=A0first. Why we have a discussion list i= f we don't discuss and leave it to DT to have the fun? IMHO=A0=A0the dr= aft is adopted work=A0then it should not become a=A0DT work=A0only after co= nsensus decision.

AB

On Monday, November 11, 2013, Abdussalam Bary= un wrote:
I don't know what is the d= esign team doing, I did not see on the list progress on DLEP. I did not fol= low meeting this year, but just now seen minutes submitted. I=A0object secr= et talks, and support Thomas's comments in the meetings regarding it sh= ould be more open. Please not DT has no authority, and I am not finding a D= T list nor reports.

AB
--047d7b111d195dae7a04eae0942e-- From thomas@thomasclausen.org Sun Nov 10 22:50:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9687B21E80C8 for ; Sun, 10 Nov 2013 22:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XHs9DMG9VIt for ; Sun, 10 Nov 2013 22:50:13 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id B278F21E80C7 for ; Sun, 10 Nov 2013 22:50:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9DE871C5B7B for ; Sun, 10 Nov 2013 22:50:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.121.3.165] (194.106-14-84.ripe.coltfrance.com [84.14.106.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5D2BC1C5B5C for ; Sun, 10 Nov 2013 22:50:13 -0800 (PST) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) Message-Id: Date: Mon, 11 Nov 2013 07:50:11 +0100 To: List List Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [manet] RFC6622bis - a pointer to the datatracker X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 06:50:18 -0000 All, As Ulrich's and Rick's minutes (thank you for posting them so rapidly - I ha= ve sent you a couple of comments/typo's off-line) recall, I promised to post= an update on the mailing list regarding the status of RFC6622bis.=20 So, I better do that promptly. The "official" version of the status (the DISCUSS and COMMENT that the ADs h= ave raised) is here: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/ballo= t/ Essentially, the SEC ADs have raised a discuss each, and we've tried to iter= ate with them this past week on how to address them best. Specifically, we h= ad one topic with each SEC-AD: Stephen: Is worried about "how much we can truncate a HMAC", pointin= g out that a sensible truncating limit should be set, as a function of the other c= haracteristics of the=20 system (essentially, message emission rates). Sean: Is worried about getting and setting sensible default param= eters for the different cryptographic (& other) functions involved, and that these b= e specified (for ensuring interoperability). Adrian Farrel was instrumental in facilitating these discussions and in movi= ng towards resolution - thank you Adrian. And thank you Stephen and Sean (fo= r the discussions we've had, and for the education you have provided).=20 I believe that we left the week hopeful that we had sorted it all out, and a= fter a tiny bit of wordsmithing should be good. I also want to thank Russ Housley for according us a chunk of his time, for e= ducating Ulrich and myself over coffee, on some more general aspects of the i= ssues that Sean and Stephen raised. Thomas Sent from my iPad= From l.wood@surrey.ac.uk Sun Nov 10 23:44:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E6111E8100 for ; Sun, 10 Nov 2013 23:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.831 X-Spam-Level: X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7R-ayceJIlw for ; Sun, 10 Nov 2013 23:44:22 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id BBFEB11E80F5 for ; Sun, 10 Nov 2013 23:44:21 -0800 (PST) Received: from [85.158.136.51:62390] by server-17.bemta-5.messagelabs.com id D4/A8-17059-4DA80825; Mon, 11 Nov 2013 07:44:20 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-49.messagelabs.com!1384155860!25053756!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31664 invoked from network); 11 Nov 2013 07:44:20 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-7.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 11 Nov 2013 07:44:20 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.216]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 11 Nov 2013 07:44:19 +0000 From: To: , Date: Mon, 11 Nov 2013 07:44:19 +0000 Thread-Topic: [manet] DLEP DT summary Thread-Index: Ac7epLQRaFv2SG3HSoKVsAXKxXRT1wABJ/8u Message-ID: <290E20B455C66743BE178C5C84F1240847E3E25DB0@EXMB01CMS.surrey.ac.uk> References: , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 07:44:26 -0000 I see that the chief author of DLEP is also the chair of MANET. And who sel= ected the design team? No doubt this will help DLEP get smoothly through IE= TF processes. Anyway, ftp://ftp.ietf.org/ietf-mail-archive/manet-dlep-rg/2013-08.mail -09 etc is relevant, and may be of interest. Though the design team is clos= ed, its discussions are not. Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration/ ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Abdussal= am Baryun [abdussalambaryun@gmail.com] Sent: 11 November 2013 06:09 To: manet Subject: Re: [manet] DLEP DT summary If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I r= ecommend release adoptation first. Why we have a discussion list if we don= 't discuss and leave it to DT to have the fun? IMHO the draft is adopted w= ork then it should not become a DT work only after consensus decision. AB On Monday, November 11, 2013, Abdussalam Baryun wrote: I don't know what is the design team doing, I did not see on the list progr= ess on DLEP. I did not follow meeting this year, but just now seen minutes = submitted. I object secret talks, and support Thomas's comments in the meet= ings regarding it should be more open. Please not DT has no authority, and = I am not finding a DT list nor reports. AB From Chris.Dearlove@baesystems.com Mon Nov 11 02:07:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1971821F9D0A for ; Mon, 11 Nov 2013 02:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQG9FdTIqc0y for ; Mon, 11 Nov 2013 02:07:28 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 513B421F9D19 for ; Mon, 11 Nov 2013 02:07:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,676,1378854000"; d="scan'208";a="326992454" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2013 10:07:26 +0000 From: "Dearlove, Christopher (UK)" X-IronPort-AV: E=Sophos;i="4.93,676,1378854000"; d="scan'208";a="35134314" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 11 Nov 2013 10:07:26 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.93]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 10:07:26 +0000 To: Ulrich Herberg , "manet@ietf.org" Thread-Topic: [manet] Minutes Thread-Index: AQHO3n627ZRs18Wc20u65HCoa13TDpofzcDw Date: Mon, 11 Nov 2013 10:07:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:07:32 -0000 Two immediate comments, one trivial (I'd have made off-list, if at all, but= easier to put here) and one less so. The trivial; "Pair down" should be "Pare down". The less trivial: There's a heading for 25 minutes of open microphone etc. = comments, but nothing is reported. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of U= lrich Herberg Sent: 11 November 2013 01:38 To: manet@ietf.org Subject: [manet] Minutes ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I have uploaded the minutes I took at: http://www.ietf.org/proceedings/88/minutes/minutes-88-manet Please check for correctness and completeness. Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From yi.jiazi@gmail.com Mon Nov 11 03:12:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4494121E81A5 for ; Mon, 11 Nov 2013 03:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5pHhrebjUGN for ; Mon, 11 Nov 2013 03:12:23 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9321E80EC for ; Mon, 11 Nov 2013 03:12:19 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id ez12so1994366wid.3 for ; Mon, 11 Nov 2013 03:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=eQr3T9LZe77kAuI8QF9aibjjZqJ+bOjhuOtAt7TUPpg=; b=NAeOOit6PWCefs1f7BetzSuwTR9/BVZQOgQZ2CYSTQO5qkAJm8L9ZwWkR9Ke8HIm2+ 88RPmvWFp2jR51O0KtwcuNCU35gqQ8tXM4i6WvgnxbEQy46MSQpmbqVUl55aSDZ1PkhX RqtQUo5duV/CqWPxgby8eekQWOEn7zLKwUJNVFNKVumSHRlgIQxAg18Nf/0dlHBe7ai5 vHAa3Y7iE40F0wn79GXUtmq3QzoIQZGpC46Ufa99ft37WY5vhZxtnooHSSOe5XmqcnuW 2v6WpKETo3Wq8b2MNbV09dYs+T4TY0qxEpEVgIFRY6oOuyUAOqtsLlZ/2hAMJ1sGJzUY sNHw== X-Received: by 10.181.13.20 with SMTP id eu20mr11883510wid.29.1384168338904; Mon, 11 Nov 2013 03:12:18 -0800 (PST) Received: from jy-mac-pro.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id b7sm33118786wiz.8.2013.11.11.03.12.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 03:12:18 -0800 (PST) Message-ID: <5280BB8E.6000906@gmail.com> Date: Mon, 11 Nov 2013 12:12:14 +0100 From: Jiazi Yi User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: MANET IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:12:28 -0000 Hi, I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here are some comments (or some of them, I would rather call questions :) 1. In Section 4: Routing MPR Selection ... then x_1 to x_n may be removed from the set of routing MPRs, if selected. ... The first note: I think we should use RFC2119 term "MAY" here? In fact, this is the part that confuses me most. As the only "action" described in the draft, the use of "may" without further explanation when this action should be taken or not is too vague. In the end of the section, another "RECOMMENDED" is used. Therefore, if I put them together, it is something like "It is RECOMMENDED that one MAY do foo, bar..." 2. If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_2, ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the criteria d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to subset of x_1, ... x_n? If so, we probably will have a lot combinations to check in a dense network. If not, the criteria seems to be too harsh to be actually "triggered"? 3. Should this be applied to all types of metrics? A potential affects of this draft is that, we can probably have more "hops" around the neighborhood of the original router, i.e., there is higher possibility of interference. In some of metrics, the interference is not much considered (because it is hard to measure). Will it be a problem if we introduce more transmission in some scenarios? 4. We have a "Willingness" value to "represents the router's willingness to be selected as an MPR." Should this need to be considered also? What about if x_0 has low willingness, while the others x_1, ... x_n have higher willingness? 5. In some scenarios, we probably want to have certain redundancy in MPR in some lossy scenarios? sincerely Jiazi From yi.jiazi@gmail.com Mon Nov 11 03:15:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE211E8149 for ; Mon, 11 Nov 2013 03:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyqsW42cnb9Q for ; Mon, 11 Nov 2013 03:15:13 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 243C611E812F for ; Mon, 11 Nov 2013 03:15:12 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id z12so3336315wgg.7 for ; Mon, 11 Nov 2013 03:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=bVH5Jf3a0t+kEZOKFGj1sHKCuJGinQiiEJHRgtnTSpo=; b=i0O8IakUG3RZaMe89XzEHywxafLPAYubZDtpArHA9JlvAY0/GIcgoWZFG/Ty0MFBuE rfCaCwFXCfltRngdzx1nA2eYv6TH3YEiyKgy6J1KdLxkA19LA4fZ3/v3mVUyoqp40KoJ oWWXtYWDjcQZBlXwWoZVYRY0jMX/ho9xDUuVQU2FIKUKePyovzlEo3ddpKVqIjTjHSlF Hxb3uxBKG+tCIr2iVTQ6YeVPZb5gVYhD3r+m9YgvHmcTB6xMwN7cEbRxte2SDZFSNahu wnJ1um/u13jMbkmKbAWQtlScINZNwuNUmI3xkvczyEaS2ZzwUAyP5/8G4Ihi3+5h/fj8 1tpA== X-Received: by 10.181.13.20 with SMTP id eu20mr11891918wid.29.1384168512352; Mon, 11 Nov 2013 03:15:12 -0800 (PST) Received: from jy-mac-pro.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id gg20sm34161895wic.1.2013.11.11.03.15.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 03:15:11 -0800 (PST) Message-ID: <5280BC3E.7000101@gmail.com> Date: Mon, 11 Nov 2013 12:15:10 +0100 From: Jiazi Yi User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: MANET IETF References: <5280BB8E.6000906@gmail.com> In-Reply-To: <5280BB8E.6000906@gmail.com> Content-Type: multipart/alternative; boundary="------------000205070804020600040605" Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:15:14 -0000 This is a multi-part message in MIME format. --------------000205070804020600040605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And one nit: In the reference, we have [RFC6966-to-be] Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 6966, TBD 2013. I suppose the name of the draft is Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-04 ? Jiazi > Jiazi Yi > 11 Nov 2013 12:12 > Hi, > > I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. > Here are some comments (or some of them, I would rather call questions :) > > 1. In Section 4: Routing MPR Selection > ... > then x_1 to x_n may be removed from the set of routing MPRs, if selected. > ... > > The first note: I think we should use RFC2119 term "MAY" here? > In fact, this is the part that confuses me most. As the only "action" > described in the draft, the use of "may" without further explanation > when this action should be taken or not is too vague. In the end of > the section, another "RECOMMENDED" is used. Therefore, if I put them > together, it is something like "It is RECOMMENDED that one MAY do foo, > bar..." > > 2. If x_1, x_2 ... x_n are the largest set with corresponding y_1, > y_2, ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n > with the criteria > > d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to > subset of x_1, ... x_n? > > If so, we probably will have a lot combinations to check in a dense > network. If not, the criteria seems to be too harsh to be actually > "triggered"? > > > 3. Should this be applied to all types of metrics? A potential affects > of this draft is that, we can probably have more "hops" around the > neighborhood of the original router, i.e., there is higher possibility > of interference. In some of metrics, the interference is not much > considered (because it is hard to measure). Will it be a problem if we > introduce more transmission in some scenarios? > > 4. We have a "Willingness" value to "represents the router's > willingness to be selected as an MPR." Should this need to be > considered also? What about if x_0 has low willingness, while the > others x_1, ... x_n have higher willingness? > > 5. In some scenarios, we probably want to have certain redundancy in > MPR in some lossy scenarios? > > sincerely > > Jiazi > > > --------------000205070804020600040605 Content-Type: multipart/related; boundary="------------020505000304080805030408" --------------020505000304080805030408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And one nit:

In the reference, we have

   [RFC6966-to-be]
              Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for
              the Use of Link Metrics in the Optimized Link State
              Routing Protocol Version 2 (OLSRv2)", RFC 6966, TBD 2013.

I suppose the name of the draft is

  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale

http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-04 ?

Jiazi

11 Nov 2013 12:12
Hi,

I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here are some comments (or some of them, I would rather call questions :)

1. In Section 4: Routing MPR Selection
...
then x_1 to x_n may be removed from the set of routing MPRs, if selected.
...

The first note: I think we should use RFC2119 term "MAY" here?
In fact, this is the part that confuses me most. As the only "action" described in the draft, the use of "may" without further explanation when this action should be taken or not is too vague. In the end of the section, another "RECOMMENDED" is used. Therefore, if I put them together, it is something like "It is RECOMMENDED that one MAY do foo, bar..."

2.  If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_2, ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the criteria

d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to subset of x_1, ... x_n?

If so, we probably will have a lot combinations to check in a dense network. If not, the criteria seems to be too harsh to be actually "triggered"?


3. Should this be applied to all types of metrics? A potential affects of this draft is that, we can probably have more "hops" around the neighborhood of the original router, i.e., there is higher possibility of interference. In some of metrics, the interference is not much considered (because it is hard to measure). Will it be a problem if we introduce more transmission in some scenarios?

4. We have a "Willingness" value to "represents the router's willingness to be selected as an MPR." Should this need to be considered also? What about if x_0 has low willingness, while the others x_1, ... x_n have higher willingness?

5. In some scenarios, we probably want to have certain redundancy in MPR in some lossy scenarios?

sincerely

Jiazi



--------------020505000304080805030408 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxd/it4v8ADfiyz+IXxCnkurRIrbUL2a8s YJZrqV4UZlDOmSWYkAZAUYAwBgVKyQK7L837Rf7SXizxL/wnnha88J+HNJSVJrTw9cWNvKGi XG0SM0e4Mwzz8vXjArgljY05Ws2e3RyGviaXtE0vJvX/AIB9t/su/HPwz8Xfh4PEfiHT9N0z VYtSms7iCSKGOSCRGHyoygHjPB4PevRp/vI8yPBqJ0puEt0Sf8NF63/0O6/9/I/8KfIRznwR 4z8OzeNvhhFf6nNNHb2NpY35lkkLfuYo03javOME5I6YrzKlebbilc9nD4ei7OpKy7nn+rar pLTTFfDcLQzsokdrmQuyo33kYt7c8EDrXDFy7n1dWOHs7Q0e+v5HXfDFbvQ9LurywF2kVzqn 20hbgERgsuB7nAGa9CFaUeWJ8liKEJVJzg9Lnn//AAml9/z83X/fQrqvM4fcPXD4l1j4afDt rrXI9Mt9S/s06da6Vej7RcP+6KMJLdc+UAeGEu0nkAda5YxvJsdbExilCMtUfMieJ7qXU9pt 5vLdyfKjdljGTz8p7exp/V49DZZlU5XzfmfQWl3dlFoFzJoAbUrCQiR2iYJNBzkl4W+cD3G5 f9qonGXMpMVDE0pxdOL1fRnmf/Cr/H3/AETjxZ/4LJ//AImuj2jI9mjp/wBtb/k5j4gf9hNP /REdWed9pnz5J/x9L9D/ADFMvod78E/+SueDP+w9Y/8Ao9KRnLc/dupPRP/Z --------------020505000304080805030408-- --------------000205070804020600040605-- From Chris.Dearlove@baesystems.com Mon Nov 11 04:19:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829E11E8163 for ; Mon, 11 Nov 2013 04:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.476 X-Spam-Level: X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHdSOzxvO2Sl for ; Mon, 11 Nov 2013 04:19:17 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 546C921E80EC for ; Mon, 11 Nov 2013 04:19:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,677,1378854000"; d="scan'208";a="327049855" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2013 12:19:14 +0000 From: "Dearlove, Christopher (UK)" X-IronPort-AV: E=Sophos;i="4.93,677,1378854000"; d="scan'208";a="35167877" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 11 Nov 2013 12:19:14 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.93]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 12:19:14 +0000 To: Jiazi Yi , MANET IETF Thread-Topic: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 Thread-Index: AQHO3s74SeO9iNSjmE+jHuG3TyZOb5of7+xw Date: Mon, 11 Nov 2013 12:19:14 +0000 Message-ID: References: <5280BB8E.6000906@gmail.com> In-Reply-To: <5280BB8E.6000906@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:19:21 -0000 This is entirely optional, so MAY and RECOMMENDED are the right strength. The removed MPRs do not add redundancy, as suggested, as they are useless. = The whole point is to remove MPRs that will never be used. (They will never= be used because there is always a shorter path than any using them directl= y.) For discussion details, see the metrics rationale draft. As to complexity, it's a tradeoff. If you don't like the complexity, don't = do it. It won't make any difference to performance, it will just save a bit= of message size and work at the other end of the link. As noted, some of this is in the rationale document, and there's no point r= epeating that unnecessarily. But we should take a look at what may or may n= ot be clear. Thanks for your comments on that. Incidentally, top of my list is checking the specific definition of when MP= Rs can be dropped, for correctness and completeness (based on the rationale= word explanation of when MPRs can be dropped). Anyone who does that and co= nfirms they've done it (especially with something more than just "done it")= would be definitely appreciated. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of J= iazi Yi Sent: 11 November 2013 11:12 To: MANET IETF Subject: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi, I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here = are some comments (or some of them, I would rather call questions :) 1. In Section 4: Routing MPR Selection ... then x_1 to x_n may be removed from the set of routing MPRs, if selected. ... The first note: I think we should use RFC2119 term "MAY" here? In fact, this is the part that confuses me most. As the only "action" = described in the draft, the use of "may" without further explanation = when this action should be taken or not is too vague. In the end of the = section, another "RECOMMENDED" is used. Therefore, if I put them = together, it is something like "It is RECOMMENDED that one MAY do foo, = bar..." 2. If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_2, = ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the = criteria d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to = subset of x_1, ... x_n? If so, we probably will have a lot combinations to check in a dense = network. If not, the criteria seems to be too harsh to be actually = "triggered"? 3. Should this be applied to all types of metrics? A potential affects = of this draft is that, we can probably have more "hops" around the = neighborhood of the original router, i.e., there is higher possibility = of interference. In some of metrics, the interference is not much = considered (because it is hard to measure). Will it be a problem if we = introduce more transmission in some scenarios? 4. We have a "Willingness" value to "represents the router's willingness = to be selected as an MPR." Should this need to be considered also? What = about if x_0 has low willingness, while the others x_1, ... x_n have = higher willingness? 5. In some scenarios, we probably want to have certain redundancy in MPR = in some lossy scenarios? sincerely Jiazi _______________________________________________ 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 Chris.Dearlove@baesystems.com Mon Nov 11 04:25:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6F21E811B for ; Mon, 11 Nov 2013 04:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.987 X-Spam-Level: X-Spam-Status: No, score=-9.987 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtUkG+Ko86au for ; Mon, 11 Nov 2013 04:25:03 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2F22011E8163 for ; Mon, 11 Nov 2013 04:25:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,677,1378854000"; d="jpg'145?scan'145,208,217,145";a="327052439" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2013 12:25:01 +0000 From: "Dearlove, Christopher (UK)" X-IronPort-AV: E=Sophos;i="4.93,677,1378854000"; d="jpg'145?scan'145,208,217,145";a="35169343" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 11 Nov 2013 12:25:00 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.93]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 12:25:00 +0000 To: Jiazi Yi , MANET IETF Thread-Topic: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 Thread-Index: AQHO3s9g+LbWKHriwUKQlQmUlSpPcpof9Geg Date: Mon, 11 Nov 2013 12:24:59 +0000 Message-ID: References: <5280BB8E.6000906@gmail.com> <5280BC3E.7000101@gmail.com> In-Reply-To: <5280BC3E.7000101@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/related; boundary="_004_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:25:07 -0000 --_004_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_ Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_" --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Good catch, thanks. what's more that's never been the title, so don't know = how that got there. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of J= iazi Yi Sent: 11 November 2013 11:15 To: MANET IETF Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimizatio= n-00 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. 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. And one nit: In the reference, we have [RFC6966-to-be] Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 6966, TBD 2013. I suppose the name of the draft is Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv= 2 - Rationale http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-04 ? Jiazi [cid:image001.jpg@01CEDED9.09D58220] Jiazi Yi 11 Nov 2013 12:12 Hi, I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here ar= e some comments (or some of them, I would rather call questions :) 1. In Section 4: Routing MPR Selection ... then x_1 to x_n may be removed from the set of routing MPRs, if selected. ... The first note: I think we should use RFC2119 term "MAY" here? In fact, this is the part that confuses me most. As the only "action" descr= ibed in the draft, the use of "may" without further explanation when this a= ction should be taken or not is too vague. In the end of the section, anoth= er "RECOMMENDED" is used. Therefore, if I put them together, it is somethin= g like "It is RECOMMENDED that one MAY do foo, bar..." 2. If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_2, ..= . y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the crite= ria d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to subse= t of x_1, ... x_n? If so, we probably will have a lot combinations to check in a dense network= . If not, the criteria seems to be too harsh to be actually "triggered"? 3. Should this be applied to all types of metrics? A potential affects of t= his draft is that, we can probably have more "hops" around the neighborhood= of the original router, i.e., there is higher possibility of interference.= In some of metrics, the interference is not much considered (because it is= hard to measure). Will it be a problem if we introduce more transmission i= n some scenarios? 4. We have a "Willingness" value to "represents the router's willingness to= be selected as an MPR." Should this need to be considered also? What about= if x_0 has low willingness, while the others x_1, ... x_n have higher will= ingness? 5. In some scenarios, we probably want to have certain redundancy in MPR in= some lossy scenarios? sincerely Jiazi ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Good catch, thanks. what'= s more that's never been the title, so don't know how that got there.<= /o:p>

 <= /p>

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

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

 <= /p>

From:= manet-bounces@ietf.= org [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi
Sent: 11 November 2013 11:15
To: MANET IETF
Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-opti= mization-00

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Fo= r information regarding Red Flags that you can look out for in emails you r= eceive, click here.
If= you feel the email is suspicious, please follow this process.

And one nit:

In the reference, we have

   [RFC6966-to-be]
            &nb= sp; Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for
            &nb= sp; the Use of Link Metrics in the Optimized Link State
            &nb= sp; Routing Protocol Version 2 (OLSRv2)", RFC 6966, TBD 2013.

I suppose the name of the draft is

  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol = OLSRv2 - Rationale

http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationa= le-04 ?

Jiazi


11 Nov 2013 12:12

Hi,

I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here ar= e some comments (or some of them, I would rather call questions :)

1. In Section 4: Routing MPR Selection
...
then x_1 to x_n may be removed from the set of routing MPRs, if selected. <= br> ...

The first note: I think we should use RFC2119 term "MAY" here? In fact, this is the part that confuses me most. As the only "action&q= uot; described in the draft, the use of "may" without further exp= lanation when this action should be taken or not is too vague. In the end o= f the section, another "RECOMMENDED" is used. Therefore, if I put them together, it is something like "It is RECOMMENDED that = one MAY do foo, bar..."

2.  If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_= 2, ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the = criteria

d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m = belong to subset of x_1, ... x_n?

If so, we probably will have a lot combinations to check in a dense network= . If not, the criteria seems to be too harsh to be actually "triggered= "?


3. Should this be applied to all types of metrics? A potential affects of t= his draft is that, we can probably have more "hops" around the ne= ighborhood of the original router, i.e., there is higher possibility of int= erference. In some of metrics, the interference is not much considered (because it is hard to measure). Will it be a probl= em if we introduce more transmission in some scenarios?

4. We have a "Willingness" value to "represents the router's= willingness to be selected as an MPR." Should this need to be conside= red also? What about if x_0 has low willingness, while the others x_1, ... = x_n have higher willingness?

5. In some scenarios, we probably want to have certain redundancy in MPR in= some lossy scenarios?

sincerely

Jiazi


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_-- --_004_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1179; creation-date="Mon, 11 Nov 2013 12:24:59 GMT"; modification-date="Mon, 11 Nov 2013 12:24:59 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkI CQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAZABkDAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDxd/it 4v8ADfiyz+IXxCnkurRIrbUL2a8sYJZrqV4UZlDOmSWYkAZAUYAwBgVKyQK7L837Rf7SXizxL/wn nha88J+HNJSVJrTw9cWNvKGiXG0SM0e4Mwzz8vXjArgljY05Ws2e3RyGviaXtE0vJvX/AIB9t/su /HPwz8Xfh4PEfiHT9N0zVYtSms7iCSKGOSCRGHyoygHjPB4PevRp/vI8yPBqJ0puEt0Sf8NF63/0 O6/9/I/8KfIRznwR4z8OzeNvhhFf6nNNHb2NpY35lkkLfuYo03javOME5I6YrzKlebbilc9nD4ei 7OpKy7nn+rarpLTTFfDcLQzsokdrmQuyo33kYt7c8EDrXDFy7n1dWOHs7Q0e+v5HXfDFbvQ9Lury wF2kVzqn20hbgERgsuB7nAGa9CFaUeWJ8liKEJVJzg9Lnn//AAml9/z83X/fQrqvM4fcPXD4l1j4 afDtrrXI9Mt9S/s06da6Vej7RcP+6KMJLdc+UAeGEu0nkAda5YxvJsdbExilCMtUfMieJ7qXU9pt 5vLdyfKjdljGTz8p7exp/V49DZZlU5XzfmfQWl3dlFoFzJoAbUrCQiR2iYJNBzkl4W+cD3G5f9qo nGXMpMVDE0pxdOL1fRnmf/Cr/H3/AETjxZ/4LJ//AImuj2jI9mjp/wBtb/k5j4gf9hNP/REdWed9 pnz5J/x9L9D/ADFMvod78E/+SueDP+w9Y/8Ao9KRnLc/dupPRP/Z --_004_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149DFGLKXM0002VGREEN_-- From sratliff@cisco.com Mon Nov 11 06:29:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0916B21E81E3 for ; Mon, 11 Nov 2013 06:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhGbuU6Z7zpN for ; Mon, 11 Nov 2013 06:29:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6121F9D0A for ; Mon, 11 Nov 2013 06:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2673; q=dns/txt; s=iport; t=1384180123; x=1385389723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gdlQobzDX5QxhuWAm6YrUajw9v1QOqri/E7OoTfcDNA=; b=aL+ehmHwnmLFWOwKrW564VuGiqKnquEAYso8mLyJ1XmTlYnTIZ2JuEes oxV7JLxyzU8lGfZRw6WR8LWTsxvm+bQIkhHENmeJ35uuzhGun72CqJbyw 7la4MBMCNGLdCdwhEL4Y2dBX8j+dkCLp/Y33FTjRx+OpfXYJ9anvGUd/z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAETpgFKtJV2Z/2dsb2JhbABZgwc4U78WgToWdIIlAQEBAwEBAQFSGQMIBQcEAgEIEQQBASgHJwsUCQgCBA4FCYdyBg29f44eCg5+MwcGgxqBEAOJCo8FkgqDJoFoCRci X-IronPort-AV: E=Sophos;i="4.93,678,1378857600"; d="scan'208";a="283258295" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 11 Nov 2013 14:28:29 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rABESTgB015898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 14:28:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 08:28:29 -0600 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Minutes Thread-Index: AQHO3n6r55vvxE5lcUevLds/GBojWZogMzuAgABI8YA= Date: Mon, 11 Nov 2013 14:28:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.107] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <767702F4C6333749B174C07831537475@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 14:29:05 -0000 Chris,=20 On Nov 11, 2013, at 5:07 AM, "Dearlove, Christopher (UK)" wrote: > Two immediate comments, one trivial (I'd have made off-list, if at all, b= ut easier to put here) and one less so. >=20 > The trivial; "Pair down" should be "Pare down". >=20 > The less trivial: There's a heading for 25 minutes of open microphone etc= . comments, but nothing is reported. As it turned out, there was no open mic time. The conversation on the other= topics ran the full meeting. Regards, Stan=20 >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Ulrich Herberg > Sent: 11 November 2013 01:38 > To: manet@ietf.org > Subject: [manet] Minutes >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I have uploaded the minutes I took at: > http://www.ietf.org/proceedings/88/minutes/minutes-88-manet >=20 > Please check for correctness and completeness. >=20 > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Nov 11 07:38:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB40021E80FA for ; Mon, 11 Nov 2013 07:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsHQ-2uN19YY for ; Mon, 11 Nov 2013 07:38:28 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 22ED311E8185 for ; Mon, 11 Nov 2013 07:38:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,678,1378854000"; d="scan'208";a="327128237" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2013 15:38:22 +0000 From: "Dearlove, Christopher (UK)" X-IronPort-AV: E=Sophos;i="4.93,678,1378854000"; d="scan'208";a="35215099" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 11 Nov 2013 15:38:22 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.93]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 15:38:22 +0000 To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Minutes Thread-Index: AQHO3n627ZRs18Wc20u65HCoa13TDpofzcDwgABJ1ICAABNrQA== Date: Mon, 11 Nov 2013 15:38:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 15:38:33 -0000 Worth adding a sentence to that effect, IMHO. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 11 November 2013 14:28 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet@ietf.org Subject: Re: [manet] Minutes ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Chris,=20 On Nov 11, 2013, at 5:07 AM, "Dearlove, Christopher (UK)" wrote: > Two immediate comments, one trivial (I'd have made off-list, if at all, b= ut easier to put here) and one less so. >=20 > The trivial; "Pair down" should be "Pare down". >=20 > The less trivial: There's a heading for 25 minutes of open microphone etc= . comments, but nothing is reported. As it turned out, there was no open mic time. The conversation on the other= topics ran the full meeting. Regards, Stan=20 >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Ulrich Herberg > Sent: 11 November 2013 01:38 > To: manet@ietf.org > Subject: [manet] Minutes >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I have uploaded the minutes I took at: > http://www.ietf.org/proceedings/88/minutes/minutes-88-manet >=20 > Please check for correctness and completeness. >=20 > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Nov 11 09:16:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108CE11E81B5 for ; Mon, 11 Nov 2013 09:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2gW1TGRZl4O for ; Mon, 11 Nov 2013 09:16:27 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4087811E81B6 for ; Mon, 11 Nov 2013 09:16:27 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id jz11so2316663veb.22 for ; Mon, 11 Nov 2013 09:16:26 -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; bh=HeFfg+1SOldwRq2qhvz3XopPILooUn+uVfcO0wbfF7w=; b=3Kqc5ED7kNq+4k+Ust3sQ8vSLQ/URPHNuO6OYWLm4ihPzYy5bAgj+lj0GtZo/3Ea+r B1q4kJ62rx2nrBcqMT+b+WmFSWU6PwIqVJrxSwHHRLvFlnrLzwSy5PCDwVRsCoz8Nvhv TMEp9KCg7dBE3PChAsnT2tZhug+hqe6jHXDfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HeFfg+1SOldwRq2qhvz3XopPILooUn+uVfcO0wbfF7w=; b=avPRIZUoOxuSz/yrj7aEBojXcaNlVH+jaH5zaI6T8J6DF+z69niM95fDERiTXgP0ys zfjswJAH0SOVgYgfXdvHATbnUL7vr6ShRv3ymMSgcQpLOT9GxD+fWWMJK+mHfbG3SfQ1 wUrwHpU7byyWtLQSxVfJRukPXKBhZXCOzJdY/TE/KQ9iyFlQNe9OEgsq19p68SkddRLT 2TnCtOwMHUcoQdxc19Lx6YY61w4ANQtd4+pTdHyXuOrDkBlCY6RoM8ocaGimRBBBuINu TPkodiPHkHuan/K/UcI0CnIZ5IFAYONl8cNopxO360TNXRfvpcPNnT7aj/FYFvMod/QO 9alQ== X-Gm-Message-State: ALoCoQlvk5jLrSpX58hvS/fP8zNBNdjPE5A5kD0Ze8t4ScpbxCQT1Qvm/U5Rt1cKZWjKQ5kCPVnr MIME-Version: 1.0 X-Received: by 10.52.163.165 with SMTP id yj5mr111368vdb.42.1384190186644; Mon, 11 Nov 2013 09:16:26 -0800 (PST) Received: by 10.220.253.68 with HTTP; Mon, 11 Nov 2013 09:16:26 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Nov 2013 09:16:26 -0800 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:16:28 -0000 Chris, thanks for these comments. I have uploaded an updated version of the minutes, based on your input and some off-list comments I received. I have updated the duration in the [brackets] for each agenda item to the time actually spent, not what was originally scheduled. In particular, the last slot for open mike that was scheduled for 25 minutes actually took 0 minutes ;-) Regards Ulrich On Mon, Nov 11, 2013 at 2:07 AM, Dearlove, Christopher (UK) wrote: > Two immediate comments, one trivial (I'd have made off-list, if at all, but easier to put here) and one less so. > > The trivial; "Pair down" should be "Pare down". > > The less trivial: There's a heading for 25 minutes of open microphone etc. comments, but nothing is reported. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 11 November 2013 01:38 > To: manet@ietf.org > Subject: [manet] Minutes > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > I have uploaded the minutes I took at: > http://www.ietf.org/proceedings/88/minutes/minutes-88-manet > > Please check for correctness and completeness. > > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From abdussalambaryun@gmail.com Mon Nov 11 12:10:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D758621E8207 for ; Mon, 11 Nov 2013 12:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV9aCT7XhRfg for ; Mon, 11 Nov 2013 12:10:45 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C736B21E8249 for ; Mon, 11 Nov 2013 12:10:44 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id ld10so1563213pab.20 for ; Mon, 11 Nov 2013 12:10:43 -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=2R+3mqRxWSWxpfu7oItw2zUPuqgwoPpfY+56ldNM1jg=; b=wNCxfcS3W57xTASfnJRAfU8G5zdSanqcDke66lAz88GsKeoCigMASDZH4Mw1kWhSDE gkeQODLeBW+7QYe4rG9zWH4o930iBqMTC1GBEak3/koSvl719tqKXDhQqwmypBS71AAw RNj5DbcpkmREOdRB0BbBQFULA2WCk/wWS5b8DYev63QGyEPaA1XlCOA7kagcKeMbBsry Nb1Ke+x0yQuT0bGZ2eT9EO4ekWMrBi5LzzRDK00Rqf1kTO0Wfq05aaoGFWCmcBHF+0jW VhFypuCvYj1pgka0tQHvEEToqhGHObCjM5S788tEg9Ww8kliHr+R1fDVxrTSVuWhZzDN KogQ== MIME-Version: 1.0 X-Received: by 10.68.232.3 with SMTP id tk3mr32061483pbc.121.1384200643344; Mon, 11 Nov 2013 12:10:43 -0800 (PST) Received: by 10.69.8.5 with HTTP; Mon, 11 Nov 2013 12:10:43 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Nov 2013 20:10:43 +0000 Message-ID: From: Abdussalam Baryun To: adrian Content-Type: multipart/alternative; boundary=047d7b33dbf2a5087904eaec53db Cc: manet Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:10:46 -0000 --047d7b33dbf2a5087904eaec53db Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian AD of MANET There should be a posted report from DT as per the discussion of its process at meeting 87, to get feedback and community discuss. There was no consensus but only private editors meeting. In August a post informed the WG of a report by 15/09 but no report, does that mean the DT is now the WG without any report to community, or Does that ignore some minorities/majority of community for some purpose, IMHO this process isolated some participants. http://www.ietf.org/mail-archive/web/manet/current/msg15553.html At last meeting it said there will be a summary but meeting forgot to mention community feedback/decisions. It is not a good process to have DT for long time while WG is only authorised of discussions and adopted the work. I don't agree to continue this DT without reporting and with isolating some other. Please respond. AB On Monday, November 11, 2013, Abdussalam Baryun wrote: > I don't know what is the design team doing, I did not see on the list > progress on DLEP. I did not follow meeting this year, but just now seen > minutes submitted. I object secret talks, and support Thomas's comments in > the meetings regarding it should be more open. Please not DT has no > authority, and I am not finding a DT list nor reports. > > AB > --047d7b33dbf2a5087904eaec53db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian
AD of MANET

There should=A0be a post= ed report from DT as per the=A0discussion of its process at meeting 87, to = get feedback and community discuss. There was no consensus but only private= editors=A0meeting.=A0In August a post informed the WG of a report by 15/09= but no report, does that mean the DT is now the=A0WG=A0without any report = to community, or Does that=A0ignore some minorities/majority of community f= or some purpose, IMHO=A0this process isolated some participants.


At last meeting it said there will= be a summary but meeting=A0forgot to mention community feedback/decisions.= =A0It is not a good process to have DT for long time=A0while WG is only=A0a= uthorised of=A0discussions and=A0adopted the work.=A0I don't agree to c= ontinue this DT without reporting and with isolating some other.=A0Please r= espond.

AB

On Monday, November 11, 2013, Abdussalam Bary= un wrote:
I don't know what is the d= esign team doing, I did not see on the list progress on DLEP. I did not fol= low meeting this year, but just now seen minutes submitted. I=A0object secr= et talks, and support Thomas's comments in the meetings regarding it sh= ould be more open. Please not DT has no authority, and I am not finding a D= T list nor reports.

AB
--047d7b33dbf2a5087904eaec53db-- From hrogge@googlemail.com Mon Nov 11 12:53:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2527A11E8102 for ; Mon, 11 Nov 2013 12:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB6BIpBiKPtc for ; Mon, 11 Nov 2013 12:53:21 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3F77311E80EC for ; Mon, 11 Nov 2013 12:53:20 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id n9so4645427qcw.29 for ; Mon, 11 Nov 2013 12:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=25vJOZDLhe+qeqsBcr93+v7DIF94la8qxssucbigyMQ=; b=C93hobPx31ixwjefVSXrcaNod0GQOjLlsqPp0IfIV9VT1zXAnEbCcElPh+yd7ov5Bi QsAu96ErhAjNKhKxyfMP8qsRRmoHfncy6vD3mJR7ovKDlLAoGjU+1hPGv2GHVzGEdUTI nAopW0a+rvISd/gecxJABxE8LddM6nXtVoF/pejF2p1NbAUfI14USykitlzh2n4AdPIG dihhEBBnobjYqKps477bldZoU3GIyZyknlaZfzG2wPPhPWZGthLdYVsUuzr0YkNaraLQ CG2eFtKBSVnrq1Mtfv76qwal+P3QFqZG2kqxxbodcIEcINMtAwuHfK8XsDVESkp71gGV xE5w== X-Received: by 10.49.30.66 with SMTP id q2mr50574055qeh.38.1384203199938; Mon, 11 Nov 2013 12:53:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.200 with HTTP; Mon, 11 Nov 2013 12:52:59 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Mon, 11 Nov 2013 21:52:59 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:53:22 -0000 Hi, did you somehow missed the report at the IETF in Vancouver? Henning Rogge On Mon, Nov 11, 2013 at 9:10 PM, Abdussalam Baryun wrote: > Hi Adrian > AD of MANET > > There should be a posted report from DT as per the discussion of its process > at meeting 87, to get feedback and community discuss. There was no consensus > but only private editors meeting. In August a post informed the WG of a > report by 15/09 but no report, does that mean the DT is now the WG without > any report to community, or Does that ignore some minorities/majority of > community for some purpose, IMHO this process isolated some participants. > > http://www.ietf.org/mail-archive/web/manet/current/msg15553.html > > At last meeting it said there will be a summary but meeting forgot to > mention community feedback/decisions. It is not a good process to have DT > for long time while WG is only authorised of discussions and adopted the > work. I don't agree to continue this DT without reporting and with isolating > some other. Please respond. > > AB > > On Monday, November 11, 2013, Abdussalam Baryun wrote: >> >> I don't know what is the design team doing, I did not see on the list >> progress on DLEP. I did not follow meeting this year, but just now seen >> minutes submitted. I object secret talks, and support Thomas's comments in >> the meetings regarding it should be more open. Please not DT has no >> authority, and I am not finding a DT list nor reports. >> >> AB > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From adrian@olddog.co.uk Mon Nov 11 13:08:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D46911E8110 for ; Mon, 11 Nov 2013 13:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vOdoUifVzDY for ; Mon, 11 Nov 2013 13:08:49 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4F21E8133 for ; Mon, 11 Nov 2013 13:08:33 -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 rABL8Ulj013578; Mon, 11 Nov 2013 21:08:31 GMT Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rABL8SE8013551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Nov 2013 21:08:29 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: In-Reply-To: Date: Mon, 11 Nov 2013 21:08:27 -0000 Message-ID: <00f201cedf22$2bda9330$838fb990$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01CEDF22.2BDDA070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKBth9GAcx9+ivI3kh1rtPqD8fNtgHzEiC/mKs5N8A= Content-Language: en-gb Cc: 'manet' Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 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, 11 Nov 2013 21:08:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F3_01CEDF22.2BDDA070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Abdussalam, Your email is almost impossible for me to parse. I apologise if I have missed your point in my reply. However, here is a general statement which I think will help you and the WG see what is going on. A Design Team is a group of people who work together on a common piece of work. It is usually efficient for such a team to work in private and report back through email or Internet-Drafts. This team is no different. Design Teams may form themselves or be formed under the guidance of WG chairs. This DT is of the second type. Under the guidance of WG chairs often, but not always, involves the participation of one or more of the chairs. In this case, both WG chairs participate in the DT: one because he is the principal author of DLEP; the other because he is WG chair. Nothing about the existence of a DT precludes others from working on the same topic on their own, on the mailing list, or in their own DT. In this case: - there have been email threads about DLEP on the list notwithstanding the existence of this DT - the DT has accepted new members who came along specifically offering to do active work (i.e. to research and write text) Like nearly every project in our industry, this project is behind schedule. But note that the schedule is the group's own schedule. This DT did promise to produce output and report back. Like several of you, I saw nothing on the MANET list and assumed there had been no progress. It turns out, however, that the archive of the DT's mail list (which is a public archive at http://www.ietf.org/mail-archive/web/manet-dlep-rg/current/maillist.html) has been pretty busy in a patchy kind of way. It was my mistake that I didn't follow that archive to find out what the DT has been up to. Many thanks to Rick Taylor for presenting the status slides at http://www.ietf.org/proceedings/88/slides/slides-88-manet-1.pdf during the Vancouver meeting. I hope that gave people a good idea of what the DT has been doing and intends to do. I note a couple of things from the (draft) minutes of the MANET meeting (http://www.ietf.org/proceedings/88/minutes/minutes-88-manet) - DT will continue to track progress on their mailing list - DT will send reports (monthly?) to the MANET list to show progress - DT will welcome new (active) participants - DLEP author will not wait until IETF-89 before updating the draft Please also note that the output of the DT can be questioned. This makes it important for the DT to present its results *and* its reasoning. Please note that unless you lend me your time machine, I cannot ix what has already happened. It is perhaps enough to make sure that things go smoothly going forward. Adrian From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 11 November 2013 20:11 To: adrian Cc: manet Subject: Re: DLEP DT summary Hi Adrian AD of MANET There should be a posted report from DT as per the discussion of its process at meeting 87, to get feedback and community discuss. There was no consensus but only private editors meeting. In August a post informed the WG of a report by 15/09 but no report, does that mean the DT is now the WG without any report to community, or Does that ignore some minorities/majority of community for some purpose, IMHO this process isolated some participants. http://www.ietf.org/mail-archive/web/manet/current/msg15553.html At last meeting it said there will be a summary but meeting forgot to mention community feedback/decisions. It is not a good process to have DT for long time while WG is only authorised of discussions and adopted the work. I don't agree to continue this DT without reporting and with isolating some other. Please respond. AB On Monday, November 11, 2013, Abdussalam Baryun wrote: I don't know what is the design team doing, I did not see on the list progress on DLEP. I did not follow meeting this year, but just now seen minutes submitted. I object secret talks, and support Thomas's comments in the meetings regarding it should be more open. Please not DT has no authority, and I am not finding a DT list nor reports. AB ------=_NextPart_000_00F3_01CEDF22.2BDDA070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Abdussalam,

 

Your email is almost = impossible for me to parse. I apologise if I have missed your point in = my reply.

 

However, here is a general = statement which I think will help you and the WG see what is going = on.

 

A Design Team is a group of = people who work together on a common piece of work. It is usually = efficient for such a team to work in private and report back through = email or Internet-Drafts. This team is no = different.

 

Design Teams may form = themselves or be formed under the guidance of WG chairs. This DT is of = the second type. Under the guidance of WG chairs often, but not always, = involves the participation of one or more of the chairs. In this case, = both WG chairs participate in the DT: one because he is the principal = author of DLEP; the other because he is WG = chair.

 

Nothing about the existence of = a DT precludes others from working on the same topic on their own, on = the mailing list, or in their own DT. In this = case:

- there have been email = threads about DLEP on the list

 notwithstanding the existence of = this DT

- the DT has accepted new = members who came along

  specifically offering to do = active work  (i.e. to = research

  and write = text)

 

Like nearly every project in = our industry, this project is behind schedule. But note that the = schedule is the group's own schedule.

 

This DT did promise to produce = output and report back. Like several of you, I saw nothing on the MANET = list and assumed there had been no progress. It turns out, however, that = the archive of the DT's mail list (which is a public archive at = http://www.ietf.org/mail-archive/web/manet-dlep-rg/current/maillist.html)= has been pretty busy in a patchy kind of way. It was my mistake that I = didn't follow that archive to find out what the DT has been up = to.

 

Many thanks to Rick Taylor for = presenting the status slides at = http://www.ietf.org/proceedings/88/slides/slides-88-manet-1.pdf during = the Vancouver meeting. I hope that gave people a good idea of what the = DT has been doing and intends to do.

 

I note a couple of things from = the (draft) minutes of the MANET meeting = (http://www.ietf.org/proceedings/88/minutes/minutes-88-manet)<= /span>

- DT will continue to track = progress on their mailing list

- DT will send reports = (monthly?) to the MANET list to show progress

- DT will welcome new (active) = participants

- DLEP author will not wait = until IETF-89 before updating the draft

 

Please also note that the = output of the DT can be questioned. This makes it important for the DT = to present its results *and* its reasoning.

 

Please note that unless you = lend me your time machine, I cannot ix what has already happened. It is = perhaps enough to make sure that things go smoothly going = forward.

 

Adrian

 

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] =
Sent: 11 November 2013 20:11
To: = adrian
Cc: manet
Subject: Re: DLEP DT = summary

 

Hi = Adrian

AD of = MANET

 

There should be a posted report from DT as per = the discussion of its process at meeting 87, to get feedback and = community discuss. There was no consensus but only private = editors meeting. In August a post informed the WG of a report = by 15/09 but no report, does that mean the DT is now = the WG without any report to community, or Does = that ignore some minorities/majority of community for some purpose, = IMHO this process isolated some = participants.

 

 

At last meeting it said there will be a summary but = meeting forgot to mention community feedback/decisions. It is = not a good process to have DT for long time while WG is = only authorised of discussions and adopted the = work. I don't agree to continue this DT without reporting and with = isolating some other. Please respond.

 

AB

On Monday, November 11, 2013, Abdussalam = Baryun wrote:

I don't know what is = the design team doing, I did not see on the list progress on DLEP. I did = not follow meeting this year, but just now seen minutes submitted. = I object secret talks, and support Thomas's comments in the = meetings regarding it should be more open. Please not DT has no = authority, and I am not finding a DT list nor = reports.

 

AB

------=_NextPart_000_00F3_01CEDF22.2BDDA070-- From john.dowdell@cassidian.com Tue Nov 12 05:37:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDE121E8125 for ; Tue, 12 Nov 2013 05:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akat5jIsQYrP for ; Tue, 12 Nov 2013 05:37:47 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id A706B21E811F for ; Tue, 12 Nov 2013 05:37:37 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 12 Nov 2013 14:37:37 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 12 Nov 2013 14:35:56 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Nov 2013 14:35:56 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Nov 2013 14:35:56 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 12 Nov 2013 13:35:55 +0000 From: "Dowdell, John" To: "l.wood@surrey.ac.uk" , "abdussalambaryun@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] DLEP DT summary Thread-Index: Ac7epLQRtFYLFZTQS0isPzY0enMPLwABJ/8uAD/G+lA= Date: Tue, 12 Nov 2013 13:35:55 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> 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.80.23.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2013 13:35:56.0357 (UTC) FILETIME=[1D8E7F50:01CEDFAC] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20284.007 X-TM-AS-Result: No--12.853400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 13:37:56 -0000 For the avoidance of doubt, please understand that I asked for an informal = meeting at Berlin IETF that half way through became the Design Team. The me= eting attendees were drawn from those who had regularly posted on DLEP sinc= e the 00 draft, and therefore were deemed to be most interested in getting = to an RFC, as I was. Kindly lay off the lead author of DLEP. In the meantime, if anyone else is actively developing with DLEP (router or= modem side) and is willing to directly contribute to the speedy and succes= sful development of the draft, please post on the manet list and we will be= in touch. One person joined the team since the first meeting in Berlin. For timescales and upcoming work, please listen to the DLEP presentation in= the early part of the manet WG meeting at Vancouver. The DLEP mailing list can be observed at http://www.ietf.org/mail-archive/w= eb/manet-dlep-rg/current/maillist.html. If there is no activity, nothing is= happening. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of l= .wood@surrey.ac.uk Sent: 11 November 2013 07:44 To: abdussalambaryun@gmail.com; manet@ietf.org Subject: Re: [manet] DLEP DT summary I see that the chief author of DLEP is also the chair of MANET. And who sel= ected the design team? No doubt this will help DLEP get smoothly through IE= TF processes. Anyway, ftp://ftp.ietf.org/ietf-mail-archive/manet-dlep-rg/2013-08.mail -09 etc is relevant, and may be of interest. Though the design team is clos= ed, its discussions are not. Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration/ ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Abdussal= am Baryun [abdussalambaryun@gmail.com] Sent: 11 November 2013 06:09 To: manet Subject: Re: [manet] DLEP DT summary If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I r= ecommend release adoptation first. Why we have a discussion list if we don= 't discuss and leave it to DT to have the fun? IMHO the draft is adopted w= ork then it should not become a DT work only after consensus decision. AB On Monday, November 11, 2013, Abdussalam Baryun wrote: I don't know what is the design team doing, I did not see on the list progr= ess on DLEP. I did not follow meeting this year, but just now seen minutes = submitted. I object secret talks, and support Thomas's comments in the meet= ings regarding it should be more open. Please not DT has no authority, and = I am not finding a DT list nor reports. AB _______________________________________________ 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 infor= mation. 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 disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From Ronald.intVelt@tno.nl Tue Nov 12 06:58:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6935A11E8168 for ; Tue, 12 Nov 2013 06:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNOR6qqRSoD6 for ; Tue, 12 Nov 2013 06:58:01 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4C611E816D for ; Tue, 12 Nov 2013 06:57:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,685,1378850400"; d="scan'208";a="2667725" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 12 Nov 2013 15:57:46 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.174]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 15:57:46 +0100 From: "Velt, R. (Ronald) in 't" To: "manet@ietf.org" Thread-Topic: two nits in draft-ietf-manet-olsrv2-19 Thread-Index: Ac7frue5jILuQiy8TX2dpa4hdAbcYg== Date: Tue, 12 Nov 2013 14:57:46 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307D91F29B@EXC-MBX03.tsn.tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [manet] two nits in draft-ietf-manet-olsrv2-19 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:58:07 -0000 Reading through draft-ietf-manet-olsrv2-19, I came across two minor editori= al nits: 1. In section 7.2, Local Attached Network Set, this Set is said to consist = of Local Attached Network Tuples. However, in the last paragraph of this se= ction mention is made of Local Attached *Neighbor* Tuples. I believe this s= hould be Local Attached Network Tuples as well. 2. In section 10.2, Router Topology Set, the second indented paragraph unde= r "where:" reads: = " TR_to_orig_addr is the originator address of a router which can be reache= d by the router with originator address TR_to_orig_addr in one hop, note th= at this does not include a prefix length;". I believe the second instance o= f "TR_to_orig_addr" in this paragraph should actually be "TR_from_orig_addr= ". = While I'm still reading the I-D, I report these nits now in the hope that t= hey can be repaired before the document's prolonged sojourn in the RFC Edi= tor queue comes to an end. Thanks, Ronald in 't Velt -- Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From chris.dearlove@baesystems.com Tue Nov 12 08:18:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31F011E818E for ; Tue, 12 Nov 2013 08:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv3WK8tBvcJ8 for ; Tue, 12 Nov 2013 08:17:47 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id E764F11E810C for ; Tue, 12 Nov 2013 08:17:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,685,1378854000"; d="scan'208";a="388744757" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Nov 2013 16:17:36 +0000 X-IronPort-AV: E=Sophos;i="4.93,685,1378854000"; d="scan'208";a="32603645" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 12 Nov 2013 16:17:35 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.43]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 16:17:36 +0000 From: "Dearlove, Christopher (UK)" To: "Velt, R. (Ronald) in 't" , "manet@ietf.org" Thread-Topic: two nits in draft-ietf-manet-olsrv2-19 Thread-Index: Ac7frue5jILuQiy8TX2dpa4hdAbcYgAEwJqA Date: Tue, 12 Nov 2013 16:17:34 +0000 Message-ID: References: <72FB622921C13746AD6349E70A8D9F307D91F29B@EXC-MBX03.tsn.tno.nl> In-Reply-To: <72FB622921C13746AD6349E70A8D9F307D91F29B@EXC-MBX03.tsn.tno.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] two nits in draft-ietf-manet-olsrv2-19 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:18:04 -0000 We haven't had AUTH48, so we should be able to fix these (and we have a sma= ll number of other nits too). Thanks for those. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of V= elt, R. (Ronald) in 't Sent: 12 November 2013 14:58 To: manet@ietf.org Subject: [manet] two nits in draft-ietf-manet-olsrv2-19 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Reading through draft-ietf-manet-olsrv2-19, I came across two minor editori= al nits: 1. In section 7.2, Local Attached Network Set, this Set is said to consist = of Local Attached Network Tuples. However, in the last paragraph of this se= ction mention is made of Local Attached *Neighbor* Tuples. I believe this s= hould be Local Attached Network Tuples as well. 2. In section 10.2, Router Topology Set, the second indented paragraph unde= r "where:" reads: = " TR_to_orig_addr is the originator address of a router which can be reache= d by the router with originator address TR_to_orig_addr in one hop, note th= at this does not include a prefix length;". I believe the second instance o= f "TR_to_orig_addr" in this paragraph should actually be "TR_from_orig_addr= ". = While I'm still reading the I-D, I report these nits now in the hope that t= hey can be repaired before the document's prolonged sojourn in the RFC Edi= tor queue comes to an end. Thanks, Ronald in 't Velt -- Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. _______________________________________________ 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 abdussalambaryun@gmail.com Tue Nov 12 08:29:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC3021E820D for ; Tue, 12 Nov 2013 08:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkr4KNnl8BE5 for ; Tue, 12 Nov 2013 08:29:34 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9611E810C for ; Tue, 12 Nov 2013 08:29:34 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kq14so6771228pab.35 for ; Tue, 12 Nov 2013 08:29: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=PSgRgySAigi9ChqXyVZA6D7rFVq2LK4KUP+7nyNtz9I=; b=Zgy+bzlUbg5Nv9e6RBTu/dYPSclhTliJMf/MtdGJscA392H7vQPinv9kAoGuFCZNy6 4f0k1VARdzUPZiLHHdOyszeZNSy7R8v1Izr5yZBbw4/DPM/H/D33rc25kyzzaYDgqlP8 KcL4/iVYl8Xa4ZNI9qWkqpVLYZ1M3sM83bmAIEnf9WJTGfwNTAhJBKiiA8WV50jgfvmN fouhBJbNOpZYe4FqC2dep8uumlwF9jpjK/i3L7SZmjjEFmsFwzPDnHiEtjoMOS2xFwMZ pHzwKoJ+BDqBQrSDikIR1uG/iUBU+uh6cm4FR+slG3vwlsdJwiARjArhDOVwfLFNY7S1 QUEw== MIME-Version: 1.0 X-Received: by 10.68.166.3 with SMTP id zc3mr36747532pbb.95.1384273774126; Tue, 12 Nov 2013 08:29:34 -0800 (PST) Received: by 10.69.8.5 with HTTP; Tue, 12 Nov 2013 08:29:34 -0800 (PST) In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Tue, 12 Nov 2013 16:29:34 +0000 Message-ID: From: Abdussalam Baryun To: "Dowdell, John" Content-Type: multipart/alternative; boundary=047d7bacb70494ea1604eafd5ad4 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:29:36 -0000 --047d7bacb70494ea1604eafd5ad4 Content-Type: text/plain; charset=ISO-8859-1 Hi John I have been very interested and was regular posting and reviewing the work but should not be excluded (there are others ). However, I thank you and the members of DT for your contributions, and always want to speed the process for DLEP but with best practices and awareness. In the last two meeting there were comments from the community that the DT should follow. The WG did not decide to give its job to the DT. I don't agree that the DT makes changes to the DLEP draft, the DT should report its recommendations to this list, so the WG decides and discusses what to do. AB On Tuesday, November 12, 2013, Dowdell, John wrote: > For the avoidance of doubt, please understand that I asked for an informal > meeting at Berlin IETF that half way through became the Design Team. The > meeting attendees were drawn from those who had regularly posted on DLEP > since the 00 draft, and therefore were deemed to be most interested in > getting to an RFC, as I was. Kindly lay off the lead author of DLEP. > > In the meantime, if anyone else is actively developing with DLEP (router > or modem side) and is willing to directly contribute to the speedy and > successful development of the draft, please post on the manet list and we > will be in touch. One person joined the team since the first meeting in > Berlin. > > For timescales and upcoming work, please listen to the DLEP presentation > in the early part of the manet WG meeting at Vancouver. > > The DLEP mailing list can be observed at > http://www.ietf.org/mail-archive/web/manet-dlep-rg/current/maillist.html. > If there is no activity, nothing is happening. > > John > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] > On Behalf Of l.wood@surrey.ac.uk > Sent: 11 November 2013 07:44 > To: abdussalambaryun@gmail.com ; manet@ietf.org > Subject: Re: [manet] DLEP DT summary > > I see that the chief author of DLEP is also the chair of MANET. And who > selected the design team? No doubt this will help DLEP get smoothly through > IETF processes. > > Anyway, > ftp://ftp.ietf.org/ietf-mail-archive/manet-dlep-rg/2013-08.mail > -09 etc is relevant, and may be of interest. Though the design team is > closed, its discussions are not. > > > Lloyd Wood > http://sat-net.com/L.Wood/router-modem-integration/ > > > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] > On Behalf Of Abdussalam Baryun [abdussalambaryun@gmail.com ] > Sent: 11 November 2013 06:09 > To: manet > Subject: Re: [manet] DLEP DT summary > > If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I > recommend release adoptation first. Why we have a discussion list if we > don't discuss and leave it to DT to have the fun? IMHO the draft is > adopted work then it should not become a DT work only after consensus > decision. > > AB > > On Monday, November 11, 2013, Abdussalam Baryun wrote: > I don't know what is the design team doing, I did not see on the list > progress on DLEP. I did not follow meeting this year, but just now seen > minutes submitted. I object secret talks, and support Thomas's comments in > the meetings regarding it should be more open. Please not DT has no > authority, and I am not finding a DT list nor reports. > > AB > _______________________________________________ > 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. Cassidian Limited, Registered Office : Quadrant House, Celtic > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > --047d7bacb70494ea1604eafd5ad4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John

I have been very interested and was regular post= ing and reviewing the work but should not be excluded (there are others ). = However, I thank you and the members of DT for your contributions, and alwa= ys want to speed the process for DLEP but with best practices and awareness= . In the last two meeting there were comments from the community that the D= T should follow. The WG did not decide to give its job to the DT.

I don't agree that the DT makes changes to the DLEP= draft, the DT should report its recommendations to this list, so the WG de= cides and discusses what to do.

AB

On Tuesd= ay, November 12, 2013, Dowdell, John wrote:
For the avoidance of doubt, please understan= d that I asked for an informal meeting at Berlin IETF that half way through= became the Design Team. The meeting attendees were drawn from those who ha= d regularly posted on DLEP since the 00 draft, and therefore were deemed to= be most interested in getting to an RFC, as I was. Kindly lay off the lead= author of DLEP.

In the meantime, if anyone else is actively developing with DLEP (router or= modem side) and is willing to directly contribute to the speedy and succes= sful development of the draft, please post on the manet list and we will be= in touch. One person joined the team since the first meeting in Berlin.
For timescales and upcoming work, please listen to the DLEP presentation in= the early part of the manet WG meeting at Vancouver.

The DLEP mailing list can be observed at http:/= /www.ietf.org/mail-archive/web/manet-dlep-rg/current/maillist.html. If = there is no activity, nothing is happening.

John

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of l.woo= d@surrey.ac.uk
Sent: 11 November 2013 07:44
To: abdussalambaryun@gmail.com; manet@ietf.org
Subject: Re: [manet] DLEP DT summary

I see that the chief author of DLEP is also the chair of MANET. And who sel= ected the design team? No doubt this will help DLEP get smoothly through IE= TF processes.

Anyway,
ftp://ftp.ietf.org/ietf-mail-archive/manet-dlep-rg/2013-= 08.mail
-09 etc is relevant, and may be of interest. Though the design team is clos= ed, its discussions are not.


Lloyd Wood
http://sat-net.com/L.Wood/router-modem-integration/


________________________________________
From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambaryun@gmail.com]
Sent: 11 November 2013 06:09
To: manet
Subject: Re: [manet] DLEP DT summary

If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I r= ecommend release adoptation =A0first. Why we have a discussion list if we d= on't discuss and leave it to DT to have the fun? IMHO =A0the draft is a= dopted work then it should not become a DT work only after consensus decisi= on.

AB

On Monday, November 11, 2013, Abdussalam Baryun wrote:
I don't know what is the design team doing, I did not see on the list p= rogress on DLEP. I did not follow meeting this year, but just now seen minu= tes submitted. I object secret talks, and support Thomas's comments in = the meetings regarding it should be more open. Please not DT has no authori= ty, and I am not finding a DT list nor reports.

AB
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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 infor= mation. 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 disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com
--047d7bacb70494ea1604eafd5ad4-- From chris.dearlove@baesystems.com Tue Nov 12 08:42:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB9D11E81AC for ; Tue, 12 Nov 2013 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.423 X-Spam-Level: X-Spam-Status: No, score=-9.423 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdsVp2fI-MaU for ; Tue, 12 Nov 2013 08:42:28 -0800 (PST) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 31B9F11E8190 for ; Tue, 12 Nov 2013 08:42:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,686,1378854000"; d="scan'208,217";a="388754566" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Nov 2013 16:42:26 +0000 X-IronPort-AV: E=Sophos;i="4.93,686,1378854000"; d="scan'208,217";a="32607263" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 12 Nov 2013 16:42:26 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.43]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 16:42:26 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "Dowdell, John" Thread-Topic: [manet] DLEP DT summary Thread-Index: AQHO3qJRUWoBATbYIkqERBisMh1ROgABJ/8uAD/G+lCaH8QBAIAAAqZQ Date: Tue, 12 Nov 2013 16:42:26 +0000 Message-ID: References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC25798GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:42:33 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC25798GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Wrong I'm afraid, both procedurally and practically. WGs can't write docume= nts, that just isn't a viable approach. Documents are written by authors, o= r sometimes editors. The WG can reject a document. But that's not the same = as writing one. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 12 November 2013 16:30 To: Dowdell, John Cc: manet@ietf.org Subject: Re: [manet] DLEP DT summary *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Hi John I have been very interested and was regular posting and reviewing the work = but should not be excluded (there are others ). However, I thank you and th= e members of DT for your contributions, and always want to speed the proces= s for DLEP but with best practices and awareness. In the last two meeting t= here were comments from the community that the DT should follow. The WG did= not decide to give its job to the DT. I don't agree that the DT makes changes to the DLEP draft, the DT should re= port its recommendations to this list, so the WG decides and discusses what= to do. AB On Tuesday, November 12, 2013, Dowdell, John wrote: For the avoidance of doubt, please understand that I asked for an informal = meeting at Berlin IETF that half way through became the Design Team. The me= eting attendees were drawn from those who had regularly posted on DLEP sinc= e the 00 draft, and therefore were deemed to be most interested in getting = to an RFC, as I was. Kindly lay off the lead author of DLEP. In the meantime, if anyone else is actively developing with DLEP (router or= modem side) and is willing to directly contribute to the speedy and succes= sful development of the draft, please post on the manet list and we will be= in touch. One person joined the team since the first meeting in Berlin. For timescales and upcoming work, please listen to the DLEP presentation in= the early part of the manet WG meeting at Vancouver. The DLEP mailing list can be observed at http://www.ietf.org/mail-archive/w= eb/manet-dlep-rg/current/maillist.html. If there is no activity, nothing is= happening. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk Sent: 11 November 2013 07:44 To: abdussalambaryun@gmail.com; manet@ietf.org Subject: Re: [manet] DLEP DT summary I see that the chief author of DLEP is also the chair of MANET. And who sel= ected the design team? No doubt this will help DLEP get smoothly through IE= TF processes. Anyway, ftp://ftp.ietf.org/ietf-mail-archive/manet-dlep-rg/2013-08.mail -09 etc is relevant, and may be of interest. Though the design team is clos= ed, its discussions are not. Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration/ ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambaryun@gmail.com] Sent: 11 November 2013 06:09 To: manet Subject: Re: [manet] DLEP DT summary If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I r= ecommend release adoptation first. Why we have a discussion list if we don= 't discuss and leave it to DT to have the fun? IMHO the draft is adopted w= ork then it should not become a DT work only after consensus decision. AB On Monday, November 11, 2013, Abdussalam Baryun wrote: I don't know what is the design team doing, I did not see on the list progr= ess on DLEP. I did not follow meeting this year, but just now seen minutes = submitted. I object secret talks, and support Thomas's comments in the meet= ings regarding it should be more open. Please not DT has no authority, and = I am not finding a DT list nor reports. AB _______________________________________________ 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 infor= mation. 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 disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com ******************************************************************** 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC25798GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Wrong I'm afraid, both pr= ocedurally and practically. WGs can't write documents, that just isn't a vi= able approach. Documents are written by authors, or sometimes editors. The WG can reject a document. But that's not the same as writing = one.

 <= /p>

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

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

 <= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 12 November 2013 16:30
To: Dowdell, John
Cc: manet@ietf.org
Subject: Re: [manet] DLEP DT summary

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Fo= r information regarding Red Flags that you can look out for in emails you r= eceive, click here.
If= you feel the email is suspicious, please follow this process.

Hi John

 

I have been very interested and was regular posting = and reviewing the work but should not be excluded (there are others ). Howe= ver, I thank you and the members of DT for your contributions, and always w= ant to speed the process for DLEP but with best practices and awareness. In the last two meeting there were = comments from the community that the DT should follow. The WG did not decid= e to give its job to the DT.

 

I don't agree that the DT makes changes to the DLEP = draft, the DT should report its recommendations to this list, so the WG dec= ides and discusses what to do.

 

AB

On Tuesday, November 12, 2013, Dowdell, John wrote:

For the avoidance of doubt, please understand that I= asked for an informal meeting at Berlin IETF that half way through became = the Design Team. The meeting attendees were drawn from those who had regula= rly posted on DLEP since the 00 draft, and therefore were deemed to be most interested in getting to an RFC, as I= was. Kindly lay off the lead author of DLEP.

In the meantime, if anyone else is actively developing with DLEP (router or= modem side) and is willing to directly contribute to the speedy and succes= sful development of the draft, please post on the manet list and we will be= in touch. One person joined the team since the first meeting in Berlin.

For timescales and upcoming work, please listen to the DLEP presentation in= the early part of the manet WG meeting at Vancouver.

The DLEP mailing list can be observed at http://www.ietf.org/mail-archive/web/manet-dlep-rg/current/maillist.html. If there is no activity, nothing is happening.

John

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk
Sent: 11 November 2013 07:44
To: abdussalambaryun@gmail.com; manet@ietf.org
Subject: Re: [manet] DLEP DT summary

I see that the chief author of DLEP is also the chair of MANET. And who sel= ected the design team? No doubt this will help DLEP get smoothly through IE= TF processes.

Anyway,
ftp://ftp.ietf.org/ietf-mail-archive/manet-dlep-rg/2013-= 08.mail
-09 etc is relevant, and may be of interest. Though the design team is clos= ed, its discussions are not.


Lloyd Wood
http://sat-net.com/L.Wood/router-modem-integration/


________________________________________
From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambaryun@gmail.com]
Sent: 11 November 2013 06:09
To: manet
Subject: Re: [manet] DLEP DT summary

If DLEP-04 is a WG draft, how can a DT take over the WG job, if it does I r= ecommend release adoptation  first. Why we have a discussion list if w= e don't discuss and leave it to DT to have the fun? IMHO  the draft is= adopted work then it should not become a DT work only after consensus decision.

AB

On Monday, November 11, 2013, Abdussalam Baryun wrote:
I don't know what is the design team doing, I did not see on the list progr= ess on DLEP. I did not follow meeting this year, but just now seen minutes = submitted. I object secret talks, and support Thomas's comments in the meet= ings regarding it should be more open. Please not DT has no authority, and I am not finding a DT list nor r= eports.

AB
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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 infor= mation. 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 con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian= .com

********************************************************************
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC25798GLKXM0002VGREEN_-- From hrogge@googlemail.com Tue Nov 12 08:49:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFD021E81BF for ; Tue, 12 Nov 2013 08:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liOkrU09Jl6e for ; Tue, 12 Nov 2013 08:49:59 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8311E810B for ; Tue, 12 Nov 2013 08:49:12 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id j7so2986226qaq.20 for ; Tue, 12 Nov 2013 08:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UJBO1pNKQcUWfCPnpF4KG8GNen6m3o1jSVZymvHYFiA=; b=qXfEEOVXy7TcyHV/AHCxps00ZttLJiM5+ySYDMUtTuy667tJnVwCCE5uYbt1WHBXme OJPXB8nYA91UGppuPCN2kz1W5xb8aSSEPFLMf0lB6SIOkczyLw1WrBqnEn6s1qZW9ffD dObRJTVD6VSXnqEwRHTcFOp7Eb+SDZIwTQGNtX26SAbvLF6CA5hQ4nF9k+IlUQXPwUF0 IGPmxfwDHDiBXBO26HJz3XW96tyUK18RaKPERwW5W7qp9Tzo1pjASuURw6i3Md7TPb0y JbgJ1fnCr68Aa2sL7T/Ncy0aQOhpsEVHYbGhfcB3OdDoaWJy18hjvAxd3SvEkPkQZ3IQ sciw== X-Received: by 10.49.30.66 with SMTP id q2mr57882663qeh.38.1384274952064; Tue, 12 Nov 2013 08:49:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.200 with HTTP; Tue, 12 Nov 2013 08:48:51 -0800 (PST) In-Reply-To: References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> From: Henning Rogge Date: Tue, 12 Nov 2013 17:48:51 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:49:59 -0000 On Tue, Nov 12, 2013 at 5:29 PM, Abdussalam Baryun wrote: > Hi John > > I have been very interested and was regular posting and reviewing the work > but should not be excluded > (there are others ). If there are others I am pretty sure they are willing to speak for themselves. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From ulrich@herberg.name Tue Nov 12 15:41:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D64321E8090 for ; Tue, 12 Nov 2013 15:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhfKTTaogUYs for ; Tue, 12 Nov 2013 15:41:20 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 003F021E8089 for ; Tue, 12 Nov 2013 15:41:19 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jx11so4390997veb.12 for ; Tue, 12 Nov 2013 15:41:19 -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; bh=LvmfdJgvpcqBXNnSm39WFFBCph+py/56m0SBmjDq2f8=; b=ylheAIVH+nTLbAn1G8t6mBp55J4IjvE3LMKBsCK/IVOwqBwnmGOM2ygWcXe629VKKL GZOu+otY/w237KNZPpd4zTonVq5BhRaCn5kTJJPglDbngFT35rAxUERbT/peuDp9DiTi F3jb3ZSrc3zDhfIgMkUpMUWqM0Fc/sVf42YaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LvmfdJgvpcqBXNnSm39WFFBCph+py/56m0SBmjDq2f8=; b=MuWpXY9XZvC5HIlwu37Bfid/DtKWjO/agvtxsKV+PD+A8hdZWv72xperVhSfJQHaj6 aFoEc6h+oVTo5YFS0GFlueXbV+GM22NxnXRlOQPpO4yhvC1SiExqAJP2fQUs0tt3Fxfd rC3OQTIwb1zW+AFgvjB13utgz4gDavwGthk6rVBb9kNbI1sR1I3JzIT9KA7xa8iSVPoR 8vOEilEdVvdJ3YqxkOon7zTlelOP0UDWeZq7EY13DJAgSGQBaU8/Vv6UhMuF78oLvXPu lWi98wlmz6jYoB/FgC1HYJe3+11+niXoYXTYhjFeHSr3dOC2c+5imKHg6UxvYzUZbdqn WZeg== X-Gm-Message-State: ALoCoQktDyyF5V64emBz0zz1/XVOUJ2hbK2CMjZy2CdB4zkQiPqNq+iZs2eaVSLe0onpRcqyTE2V MIME-Version: 1.0 X-Received: by 10.220.174.200 with SMTP id u8mr31426081vcz.6.1384299679244; Tue, 12 Nov 2013 15:41:19 -0800 (PST) Received: by 10.220.253.68 with HTTP; Tue, 12 Nov 2013 15:41:19 -0800 (PST) In-Reply-To: <527E383D.8030505@computer.org> References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <527E383D.8030505@computer.org> Date: Tue, 12 Nov 2013 15:41:19 -0800 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=089e0149ca3aa5111c04eb03629e Cc: List List Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:41:22 -0000 --089e0149ca3aa5111c04eb03629e Content-Type: text/plain; charset=ISO-8859-1 Hi, UH> I agree with many points from Thomas' review, and I am sad to see that there was so little progress of AODVv2 (not even a new revision). UH> I went through one of my old reviews to see which of these items have been addressed (there was another one in 2010). UH> November 2012 (my second detailed review of the DYMO/AODVv2 draft): http://www.ietf.org/mail-archive/web/manet/current/msg14023.html ============== [text from the review was:] The main comments (as shown in detail below) are: - The draft is still very difficult to read and is underspecified in many occasions. UH> That is still true. The draft is still very hard to read. The structure makes it very hard for implementers to follow the draft in an easy way (e.g., which steps do I have to perform when I receive a message / generate a message). I much prefer the document structure of the OLSRv2 draft. There are several terms specified (e.g., routers client, upstream router) that are unclear how they affect the MANET architecture, and why existing terms (e.g., hosts) would not be sufficient. For example, it is unclear how the blacklisting works, how metrics are used, how the TLVs are associated with certain addresses. UH> In the black list section, there are many SHOULDs. It is unclear why they are not MUSTs, or what happens if an implementation decides not to do so. Text such as "The IP address of the node" is ambiguous: why node, not router? Which IP address? A router may have many interfaces, and each of them may have multiple IP addresses. "The time at which Blacklist.Node will be removed from the blacklist.". What does "will" mean? MUST? UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" still indicate requirement of address order in an address block. WG consensus was not to use that. Also, the text seems to indicate that there is a single address block. That would be against the intended RFC5444 architecture. Some of the parameters and TLVs specified in the IANA section are not used. There are at least four timers for each route entry, and it is unclear how they may affect each other. It is not clearly specified how to update forward/reverse routes + the route to the previous hop - The use of metrics is not well defined; there is an optional distance field. It is unclear how metrics are created, whether they are additive, how they are formatted etc. What happens if some routers now the Distance field, others don't use it. - There are several extensions specified, but too few details to assure interoperability. Some of them violate end-to-end security. UH> That still applies (see section 13 of the AODVv2 draft) During IETF86, we have been promised a summary of these options (see http://tools.ietf.org/wg/manet/minutes?item=minutes-86-manet.html), but that has not been delivered. There needs to be a lot more discussion about how these options affect interoperability and security (e.g., the argument that intermediate RREPs make end-to-end security very difficult still applies). I still believe that a slim core without any optional features would be a better approach. Some of these extensions severely affect how message integrity can be provided. That must be discussed in a lot of detail. I also note that none of these extensions are tested in the (yet-to-be-done) AODVv2 implementations. - As messages are modified in transit, end-to-end security is not possible. The security considerations section does not fulfill the requirements in RFC3552. UH> This still applies (in particular with intermediate RREPs) - Extensions, such as for security, cannot be hooked into AODVv2, as there is no section to allow an external mechanism to provide additional reasons to reject a message as invalid, such as done in RFC6130. UH> This still applies. - The IANA section is not correct. There are no requests, no new registries or code points in existing registries, no allocation policy is provided. UH> This still applies. - There are some layer violations where tasks that are to be done by the RFC5444 (de)multiplexer are handled in AODVv2. UH> This still applies, e.g., in section 5.4, when the RFC5444 parser and the IP layer are mixed, and where AODVv2 uses RFC2119 language for IP layer operations such as TTL. - There is a mandated order of addresses in RFC5444 messages; I think this is a bad idea if extensions want to add addresses. - Originator address and sequence number are contained in address block and address block TLV, instead of the message header, so there is additional overhead. UH> That still applies. Incidentally, I also don't understand why the metric type is not encoded as TLV type extension, but rather in a separate TLV. - There is no RREP_ACK or other mechanism to verify bidirectionality of links. UH> This has been added as (very short) extension, although it is unclear how this works in detail, or how interoperability is assured with deployments not using that message (e.g. one router expecting a RREP_ACK, a neighbor not supporting it). - It is unclear to me how the destination sequence number is used in RREQ and what it serves for. - Intermediate route replies are hard to secure with signatures UH> This still applies ============== Conclusion: UH> I could go again in such great detail through the AODVv2 draft, but I fear that given the slow progress, this would not be a good investment of my time. I also notice that so far, implementations and interop tests have only been promised, but not delivered. UH> Adrian has selected the AODVv2 text as basis for the reactive protocol. Two IETFs later, I am personally disappointed with the progress, and believe that the decision was a wrong one (this is not to blame Adrian, just an observation of the outcome). There have been many I-Ds and academic publications produced for LOADng (ask, if you want the details); in addition, it has been approved by the G3 Alliance to as routing protocol standard for PLC. UH> There are at least four interoperable LOADng implementations with interop report, MIB document, very readable and close to WGLC-ready draft of LOADng, large-scale deployments as well as academic experience, a slim core design without complicated extensions, and several companion drafts. UH> My recommendation to the WG is to: 1) Admit defeat on the ability to produce a reactive protocol, and recharter (or close) the WG 2) Make LOADng the WG document and appoint new editors for the reactive protocol. Best regards Ulrich On Sat, Nov 9, 2013 at 5:27 AM, Charles E. Perkins wrote: > Hello folks, > > I'm traveling and don't have time just now to go dig out the precise > emails. But, given the tone of this email, I thought it appropriate to > at least make an initial response. Inline below. > > > On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote: > >> Stan Ratliff asked me to bring some of the comments I made at the mike >> during the MANET wg meeting yesterday, to the list. I believe that this is >> a good idea, if for nothing else but to enter them into public record. >> >> I realize, though, that the points I raised during the meeting yesterday >> actually already ARE public record, and have been so since 2010: >> >> http://www.ietf.org/mail-archive/web/manet/current/msg11858.html >> >> So, I'll hereby go on public record indicating that I've been on public >> record with these things since 2010... >> >> 1) The detailed review comments that I gave to the reactive protocol (at >> the time, known under the name DYMO) during the Maastricht IETF'78 (in >> 2010) still largely apply to the current incarnation of the MANET reactive >> protocol. My review comments were posted to the MANET mailing list, and are >> on record in the archives: >> >> http://www.ietf.org/mail-archive/web/manet/current/msg11858.html >> >> Around at the same time, other reviews were posted by others. A quick >> skim through these indicate that many of those review comments have not >> been addressed either. >> I believe that it would have behoved the authors to look through these >> reviews when reviving this activity, and to ensure that the comments were >> reflected in the document - or, deflected through discussion on the list. >> Alas, given that such reviews (still) have not been throughly addressed by >> the most recent WG document, I'm not sure that providing a review again >> saying the same is any good use of my (or WG) time. >> > > I did in fact address these issues, resulting in a thoroughgoing > revision of the document. I got no feedback at the time, and so > thought there wasn't much more to do. It would be nice to see > just what particular points remain to do, especially if they were > put on the issue tracker. > > > 2) RFC5444 is used wrongly in the document: positional semantics of >> address, and semantics of an address given by its mere presence in a >> message, has as consequence that it is nigh impossible to develop >> extensions that are backwards compatible. It's a comment that the WG well >> should be aware of, as it was raised in the context of early versions of >> DLEP (where it was promptly resolved). >> >> Note: This issue also was raised in the review cited under point >> 1.The document must be >> substantially revised to this effect. >> > > Similarly, I did address these issues and as far as I know the > current specification is in conformance with RFC 5444. > > > >> 3) The document is extremely unstructured. When I get a message X, then >> what procedure must I follow? This information is scattered throughout the >> 60ish pages, and it renders it extremely complicated to even begin to >> understand how to implement correctly. I've read the document on the way >> over to Vancouver, and I've read it again this morning. I still can't >> properly draw the state machines, and there're processing bits that I >> *think* are not specified (but maybe reading it a 3rd time is required). >> The point here is, the IETF writes specifications so as to help >> implementers make correct implementations. This document makes it a lot of >> work to try to figure out what's supposed to be implemented. >> >> Note: This issue also was raised in the review cited under point >> 1.The document must be >> substantially revised to this effect. >> > > Similarly, I did address this issue. However, one person's view of > proper structure may differ from another person's view. If there > are any questions about how to follow a procedure, they should > be pointed out. Cross references can be inserted as needed, or > document sections rearranged. I already did a lot of rearrangement, > but I am certainly willing to do more. > > > >> 4) The document employs sloppy terminology and invented (and redundant) >> non-standard terminology. For example, but non-exhaustively, the terms >> "Routing client" and "node" - why not the well-defined terms "host" and >> "router"? >> >> Note: This issue also was raised in the review cited under point >> 1.The document must be >> substantially revised to this effect. >> > > The terms cited above have particular meanings in the document. > The suggested terms "host" and "router" do not capture the more > specific meanings required at certain points in the document. > > > >> 5) I am worrying that there are virtually non-existent security >> considerations in this document. In part, "in this day and age, this is >> unacceptable", but more pragmatically, having seen the (justified) scrutiny >> that the SEC-DIR and SEC ADs apply to documents they review, this won't >> pass muster. >> >> Note: This issue was only touched upon in the review cited under >> point 1. >> But, I still believe that the document must be substantially >> revised to this effect. >> > > As best I understand, the security considerations are sufficient. > This is a topic that deserves more attention. > > > >> 6) The document is ripe with options, often expressed vaguely "XX should >> be done, you can do that by, for example ZZ, YY or WW....", and that makes >> me worried. Options means code branches, which means more test-cases to run >> through (and, more branches in an interoperability test). It also means, >> that if an implementation "does XX by way of ZZ", will that, or will that >> not, interoperate with an implementation that "does XX by way of WW"? >> >> I believe that the author presenting implicitly acknowledged that such >> options make things complicated - by saying that the first implementation >> that he intended to produce would be very partial and include only a "core" >> without options. >> > > This is a very generic comment that applies to practically every > protocol in the IETF, including DHCP, IPv6, SIP, IP, TCP, Mobile IP, ... > The "complication" alluded to is far less than in most existing > protocols, and (again) has been thoroughly understood from > past work. > > > >> Note: I have numerous times (since the last Paris IETF, at least) >> suggested that in that case >> it's miles better to produce a document with that minimal "core", >> leaving options for a later >> process. >> > > This ignores the fact that the optional features have been > well known for many years, and in fact the current division of > functionality into "base" versus "option" was done in response > to previous requests. I am not aware of any IETF requirement > to delete all optional features when producing base documents. > > > >> 7) Given that the above comments have been made ad infinitum since >> Maastricht, on the list and in WG meetings, without seeing any improvement >> of the document, it is hard to justify the efforts of making further >> reviews or comments: so far, such have been ignored. A good start would be >> to incorporate those reviews, for the authors to show "good faith" and >> listen to the WG. >> > > This is a gross misrepresentation of fact, and as best I can tell > the person making this complaint has made very little effort > been made to review recent versions of the document, despite > my requests. If further elaboration is needed I will go back and > find the relevant emails, but right now I can't do that. > > ==================================================== > > Having said all that, I encourage constructive dialog and more > detailed suggestions about how to improve document structure > and terminology. I think it is appropriate to move forward with > the document including the current optional features, or perhaps > including also the intermediate route reply which is a feature that > was originally specified in the base document and has long been > part of the reactive routing protocol development. > > If specific suggestions are made to improve the document structure > or terminology (again, much better if posted to the issue tracker), > I can respond much more effectively and will make document > revisions in a timely fashion. > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0149ca3aa5111c04eb03629e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

UH> I agree with many points from Thomas'= ; review, and I am sad to see that there was so little progress of AODVv2 (= not even a new revision).

UH> I went through one of my old review= s to see which of these items have been addressed (there was another one in= 2010).

UH> November 2012 (my second detailed review of the DYMO/AODVv2 draf= t):
=A0=A0=A0 http://www.ietf.org/mail-archive/web/manet/current/msg14= 023.html

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[text from the review was= :]
The main comments (as shown in detail below) are:
=A0 - The draft = is still very difficult to read and is underspecified in
many occasions.=

UH> That is still true. The draft is still very hard to read. Th= e structure makes it very hard for implementers to follow the draft in an e= asy way (e.g., which steps do I have to perform when I receive a message / = generate a message). I much prefer the document structure of the OLSRv2 dra= ft.
There are several terms specified (e.g., routers client, upstream router) t= hat are unclear how they affect the MANET architecture, and why existing te= rms (e.g., hosts) would not be sufficient.


For example, it is un= clear how the blacklisting works,
how metrics are used, how the TLVs are associated with certain
addresses= .

UH> In the black list section, there are many SHOULDs. It is un= clear why they are not MUSTs, or what happens if an implementation decides = not to do so. Text such as "The IP address of the node" is ambigu= ous: why node, not router? Which IP address? A router may have many interfa= ces, and each of them may have multiple IP addresses. "The time at whi= ch Blacklist.Node will be removed from the blacklist.". What does &quo= t;will" mean? MUST?

UH> Notations such as "AddrBlk[1] - The first address slot in A= ddrBlk" still indicate requirement of address order in an address bloc= k. WG consensus was not to use that. Also, the text seems to indicate that = there is a single address block. That would be against the intended RFC5444= architecture.

Some of the parameters and TLVs specified in the IANA
section are no= t used. There are at least four timers for each route
entry, and it is u= nclear how they may affect each other. It is not
clearly specified how t= o update forward/reverse routes + the route to
the previous hop
=A0 - The use of metrics is not well defined; there is = an optional
distance field. It is unclear how metrics are created, wheth= er they
are additive, how they are formatted etc. What happens if some r= outers
now the Distance field, others don't use it.
=A0 - There are several= extensions specified, but too few details to
assure interoperability. S= ome of them violate end-to-end security.

UH> That still applies (= see section 13 of the AODVv2 draft) During IETF86, we have been promised a = summary of these options (see http://tools.ietf.org/wg/manet/minutes?i= tem=3Dminutes-86-manet.html), but that has not been delivered. There ne= eds to be a lot more discussion about how these options affect interoperabi= lity and security (e.g., the argument that intermediate RREPs make end-to-e= nd security very difficult still applies). I still believe that a slim core= without any optional features would be a better approach. Some of these ex= tensions severely affect how message integrity can be provided. That must b= e discussed in a lot of detail. I also note that none of these extensions a= re tested in the (yet-to-be-done) AODVv2 implementations.


=A0 - As messages are modified in transit, end-to-end security is n= ot
possible. The security considerations section does not fulfill therequirements in RFC3552.

UH> This still applies (in particular = with intermediate RREPs)

=A0 - Extensions, such as for security, cannot be hooked into AODVv2, a= s
there is no section to allow an external mechanism to provide
addit= ional reasons to reject a message as invalid, such as done in
RFC6130.
UH> This still applies.

=A0 - The IANA section is not correct= . There are no requests, no new
registries or code points in existing re= gistries, no allocation policy
is provided.

UH> This still app= lies.

=A0 - There are some layer violations where tasks that are to be done b= y
the RFC5444 (de)multiplexer are handled in AODVv2.

UH> This = still applies, e.g., in section 5.4, when the RFC5444 parser and the IP lay= er are mixed, and where AODVv2 uses RFC2119 language for IP layer operation= s such as TTL.

=A0 - There is a mandated order of addresses in RFC5444 messages; I
= think this is a bad idea if extensions want to add addresses.
=A0 - Orig= inator address and sequence number are contained in address
block and ad= dress block TLV, instead of the message header, so there
is additional overhead.

UH> That still applies. Incidentally, I a= lso don't understand why the metric type is not encoded as TLV type ext= ension, but rather in a separate TLV.

=A0 - There is no RREP_ACK or = other mechanism to verify bidirectionality
of links.

UH> This has been added as (very short) extension, alth= ough it is unclear how this works in detail, or how interoperability is ass= ured with deployments not using that message (e.g. one router expecting a R= REP_ACK, a neighbor not supporting it).


=A0 - It is unclear to me how the destination sequence number is us= ed in
RREQ and what it serves for.
=A0 - Intermediate route replies a= re hard to secure with signatures
=A0=A0=A0
UH> This still applie= s
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Conclusion:

UH> I could go again in such great detail through= the AODVv2 draft, but I fear that given the slow progress, this would not = be a good investment of my time. I also notice that so far, implementations= and interop tests have only been promised, but not delivered.

UH> Adrian has selected the AODVv2 text as basis for the reactive pr= otocol. Two IETFs later, I am personally disappointed with the progress, an= d believe that the decision was a wrong one (this is not to blame Adrian, j= ust an observation of the outcome). There have been many I-Ds and academic = publications produced for LOADng (ask, if you want the details); in additio= n, it has been approved by the G3 Alliance to=A0 as routing protocol standa= rd for PLC.

UH> There are at least four interoperable LOADng implementations wit= h interop report, MIB document, very readable and close to WGLC-ready draft= of LOADng, large-scale deployments as well as academic experience, a slim = core design without complicated extensions, and several companion drafts.
UH> My recommendation to the WG is to:
=A0=A0 1) Admit defeat on = the ability to produce a reactive protocol, and recharter (or close) the WG=
=A0=A0 2) Make LOADng the WG document and appoint new editors for the r= eactive protocol.


Best regards
Ulrich


=
On Sat, Nov 9, 2013 at 5:27 AM, Charles E. Perki= ns <charliep@computer.org> wrote:
Hello folks,

I'm traveling and don't have time just now to go dig out the precis= e
emails. =A0But, given the tone of this email, I thought it appropriate to at least make an initial response. =A0Inline below.


On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote:
Stan Ratliff asked me to bring some of the comments I made at the mike duri= ng the MANET wg meeting yesterday, to the list. I believe that this is a go= od idea, if for nothing else but to enter them into public record.

I realize, though, that the points I raised during the meeting yesterday ac= tually already ARE public record, and have been so since 2010:

=A0 =A0 =A0 =A0 http://www.ietf.org/mail-archive= /web/manet/current/msg11858.html

So, I'll hereby go on public record indicating that I've been on pu= blic record with these things since 2010...

1) The detailed review comments that I gave to the reactive protocol (at th= e time, known under the name DYMO) during the Maastricht IETF'78 (in 20= 10) still largely apply to the current incarnation of the MANET reactive pr= otocol. My review comments were posted to the MANET mailing list, and are o= n record in the archives:

=A0 =A0 =A0 =A0 http://www.ietf.org/mail-archive= /web/manet/current/msg11858.html

Around at the same time, other reviews were posted by others. A quick skim = through these indicate that many of those review comments have not been add= ressed either.
I believe that it would have behoved the authors to look through these revi= ews when reviving this activity, and to ensure that the comments were refle= cted in the document - or, deflected through discussion on the list. Alas, = given that such reviews (still) have not been throughly addressed by the mo= st recent WG document, I'm not sure that providing a review again sayin= g the same is any good use of my (or WG) time.

I did in fact address these issues, resulting in a thoroughgoing
revision of the document. =A0I got no feedback at the time, and so
thought there wasn't much more to do. =A0It would be nice to see
just what particular points remain to do, especially if they were
put on the issue tracker.


2) RFC5444 is used wrongly in the document: positional semantics of address= , and semantics of =A0an address given by its mere presence in a message, h= as as consequence that it is nigh impossible to develop extensions that are= backwards compatible. It's a comment that the WG well should be aware = of, as it was raised in the context of early versions of DLEP (where it was= promptly resolved).

=A0 =A0 =A0 =A0 Note: This issue also was raised in the review cited under = point 1.The document must be
=A0 =A0 =A0 =A0 substantially revised to this effect.

Similarly, I did address these issues and as far as I know the
current specification is in conformance with RFC 5444.


3) The document is extremely unstructured. When I get a message X, then wha= t procedure must I follow? This information is scattered throughout the 60i= sh pages, and it renders it extremely complicated to even begin to understa= nd how to implement correctly. I've read the document on the way over t= o Vancouver, and I've read it again this morning. I still can't pro= perly draw the state machines, and there're processing bits that I *thi= nk* are not specified (but maybe reading it a 3rd time is required). The po= int here is, the IETF writes specifications so as to help implementers make= correct implementations. This document makes it a lot of work to try to fi= gure out what's supposed to be implemented.

=A0 =A0 =A0 =A0 Note: This issue also was raised in the review cited under = point 1.The document must be
=A0 =A0 =A0 =A0 substantially revised to this effect.

Similarly, I did address this issue. =A0However, one person's view of proper structure may differ from another person's view. =A0If there
are any questions about how to follow a procedure, they should
be pointed out. =A0Cross references can be inserted as needed, or
document sections rearranged. =A0I already did a lot of rearrangement,
but I am certainly willing to do more.



4) The document employs sloppy terminology and invented (and redundant) non= -standard terminology. For example, but non-exhaustively, the terms "R= outing client" and "node" - why not =A0the well-defined term= s "host" and "router"?

=A0 =A0 =A0 =A0 Note: This issue also was raised in the review cited under = point 1.The document must be
=A0 =A0 =A0 =A0 substantially revised to this effect.

The terms cited above have particular meanings in the document.
The suggested terms "host" and "router" do not capture = the more
specific meanings required at certain points in the document.



5) I am worrying that there are virtually non-existent security considerati= ons in this document. In part, "in this day and age, this is unaccepta= ble", but more pragmatically, having seen the (justified) scrutiny tha= t the SEC-DIR and SEC ADs apply to documents they review, this won't pa= ss muster.

=A0 =A0 =A0 =A0 Note: This issue was only touched upon in the review cited = under point 1.
=A0 =A0 =A0 =A0 But, I still believe that the document must be =A0substanti= ally revised to this effect.

As best I understand, the security considerations are sufficient.
This is a topic that deserves more attention.



6) The document is ripe with options, often expressed vaguely "XX shou= ld be done, you can do that by, for example ZZ, YY or WW....", and tha= t makes me worried. Options means code branches, which means more test-case= s to run through (and, more branches in an interoperability test). It also = means, that if an implementation "does XX by way of ZZ", will tha= t, or will that not, interoperate with an implementation that "does XX= by way of WW"?

I believe that the author presenting implicitly acknowledged that such opti= ons make things complicated - by saying that the first implementation that = he intended to produce would be very partial and include only a "core&= quot; without options.

This is a very generic comment that applies to practically every
protocol in the IETF, including DHCP, IPv6, SIP, IP, TCP, Mobile IP, ... The "complication" alluded to is far less than in most existing protocols, and (again) has been thoroughly understood from
past work.



=A0 =A0 =A0 =A0 Note: I have numerous times (since the last Paris IETF, at = least) suggested that in that case
=A0 =A0 =A0 =A0 it's miles better to produce a document with that minim= al "core", leaving options for a later
=A0 =A0 =A0 =A0 process.

This ignores the fact that the optional features have been
well known for many years, and in fact the current division of
functionality into "base" versus "option" was done in r= esponse
to previous requests. =A0I am not aware of any IETF requirement
to delete all optional features when producing base documents.



7) Given that the above comments have been made ad infinitum since Maastric= ht, on the list and in WG meetings, without seeing any improvement of the d= ocument, it is hard to justify the efforts of making further reviews or com= ments: so far, such have been ignored. A good start would be to incorporate= those reviews, for the authors to show "good faith" and listen t= o the WG.

This is a gross misrepresentation of fact, and as best I can tell
the person making this complaint has made very little effort
been made to review recent versions of the document, despite
my requests. =A0If further elaboration is needed I will go back and
find the relevant emails, but right now I can't do that.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Having said all that, I encourage constructive dialog and more
detailed suggestions about how to improve document structure
and terminology. =A0I think it is appropriate to move forward with
the document including the current optional features, or perhaps
including also the intermediate route reply which is a feature that
was originally specified in the base document and has long been
part of the reactive routing protocol development.

If specific suggestions are made to improve the document structure
or terminology (again, much better if posted to the issue tracker),
I can respond much more effectively and will make document
revisions in a timely fashion.

--
Regards,
Charlie P.


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

--089e0149ca3aa5111c04eb03629e-- From sratliff@cisco.com Wed Nov 13 07:49:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C0421E8154 for ; Wed, 13 Nov 2013 07:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjRU-vkVaEoQ for ; Wed, 13 Nov 2013 07:49:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C56E111E8100 for ; Wed, 13 Nov 2013 07:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6136; q=dns/txt; s=iport; t=1384357780; x=1385567380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uaspolWaG9OXao3SxCGDK5LN1DlyVbcjxD0ezY8XYu0=; b=QFRskOMkSX24Tz1LDdoz+LlK5C78GR/09NJ+dJ2eRGEyTHWa47Scoe7D ot1zSHFinS/C04O1FH49x9OllvjfU2h9ZXwNdtwLoXluRVxL8ubHQBAtG S5tDqG7/OqBLr5OV51k9yttNuAzSVefDAOHllPVnRaZZ3Pavjnk4xlel3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAAKfg1KtJXG9/2dsb2JhbABagwc4U78pgSIWdIIlAQEBAwE6NAsFCwIBCDYQMiUCBAENBQmHcgYNwBaOFRGBBjMCBYMggREDmBCSC4MogXE5 X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="scan'208";a="284293741" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 13 Nov 2013 15:49:40 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rADFndPE011076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 15:49:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 09:49:39 -0600 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen , Ulrich Herberg Thread-Topic: Regarding the reactive protocol development. Thread-Index: AQHO3LrrPjsrTFurgkuiiIuhZyqWGJojuwkA Date: Wed, 13 Nov 2013 15:49:38 +0000 Message-ID: <8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> In-Reply-To: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <35CD876631922945AEB513EB312D15A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List List , Joe Macker Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 15:49:47 -0000 Thomas,=20 Thank you for taking the time to do this. The editing team will work throug= h the items you list here, and endeavor to make the document better.=20 I'd also like to thank Ulrich for his additional comments & review; those i= tems will be looked at as well.=20 Regards, Stan On Nov 8, 2013, at 2:44 PM, Thomas Heide Clausen w= rote: > Stan Ratliff asked me to bring some of the comments I made at the mike du= ring the MANET wg meeting yesterday, to the list. I believe that this is a = good idea, if for nothing else but to enter them into public record.=20 >=20 > I realize, though, that the points I raised during the meeting yesterday = actually already ARE public record, and have been so since 2010: >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html >=20 > So, I'll hereby go on public record indicating that I've been on public r= ecord with these things since 2010... >=20 > 1) The detailed review comments that I gave to the reactive protocol (at = the time, known under the name DYMO) during the Maastricht IETF'78 (in 2010= ) still largely apply to the current incarnation of the MANET reactive prot= ocol. My review comments were posted to the MANET mailing list, and are on = record in the archives: >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html >=20 > Around at the same time, other reviews were posted by others. A quick ski= m through these indicate that many of those review comments have not been a= ddressed either. > I believe that it would have behoved the authors to look through these re= views when reviving this activity, and to ensure that the comments were ref= lected in the document - or, deflected through discussion on the list. Alas= , given that such reviews (still) have not been throughly addressed by the = most recent WG document, I'm not sure that providing a review again saying = the same is any good use of my (or WG) time.=20 >=20 > 2) RFC5444 is used wrongly in the document: positional semantics of addre= ss, and semantics of an address given by its mere presence in a message, h= as as consequence that it is nigh impossible to develop extensions that are= backwards compatible. It's a comment that the WG well should be aware of, = as it was raised in the context of early versions of DLEP (where it was pro= mptly resolved).=20 >=20 > Note: This issue also was raised in the review cited under point 1.The d= ocument must be=20 > substantially revised to this effect. >=20 > 3) The document is extremely unstructured. When I get a message X, then w= hat procedure must I follow? This information is scattered throughout the 6= 0ish pages, and it renders it extremely complicated to even begin to unders= tand how to implement correctly. I've read the document on the way over to = Vancouver, and I've read it again this morning. I still can't properly draw= the state machines, and there're processing bits that I *think* are not sp= ecified (but maybe reading it a 3rd time is required). The point here is, t= he IETF writes specifications so as to help implementers make correct imple= mentations. This document makes it a lot of work to try to figure out what'= s supposed to be implemented. >=20 > Note: This issue also was raised in the review cited under point 1.The d= ocument must be > substantially revised to this effect. >=20 > 4) The document employs sloppy terminology and invented (and redundant) n= on-standard terminology. For example, but non-exhaustively, the terms "Rout= ing client" and "node" - why not the well-defined terms "host" and "router= "?=20 >=20 > Note: This issue also was raised in the review cited under point 1.The d= ocument must be=20 > substantially revised to this effect. >=20 > 5) I am worrying that there are virtually non-existent security considera= tions in this document. In part, "in this day and age, this is unacceptable= ", but more pragmatically, having seen the (justified) scrutiny that the SE= C-DIR and SEC ADs apply to documents they review, this won't pass muster.=20 >=20 > Note: This issue was only touched upon in the review cited under point 1= . > But, I still believe that the document must be substantially revised to= this effect. >=20 > 6) The document is ripe with options, often expressed vaguely "XX should = be done, you can do that by, for example ZZ, YY or WW....", and that makes = me worried. Options means code branches, which means more test-cases to run= through (and, more branches in an interoperability test). It also means, t= hat if an implementation "does XX by way of ZZ", will that, or will that no= t, interoperate with an implementation that "does XX by way of WW"?=20 >=20 > I believe that the author presenting implicitly acknowledged that such op= tions make things complicated - by saying that the first implementation tha= t he intended to produce would be very partial and include only a "core" wi= thout options.=20 >=20 > Note: I have numerous times (since the last Paris IETF, at least) sugges= ted that in that case=20 > it's miles better to produce a document with that minimal "core", leavin= g options for a later=20 > process. >=20 > 7) Given that the above comments have been made ad infinitum since Maastr= icht, on the list and in WG meetings, without seeing any improvement of the= document, it is hard to justify the efforts of making further reviews or c= omments: so far, such have been ignored. A good start would be to incorpora= te those reviews, for the authors to show "good faith" and listen to the WG= . >=20 > 8) Given that the past 12 months, when the effort was "rebooted" by the r= esponsible AD, have yielded no improvement of the document quality, and has= seen none of the comments previously made, it's hard to have confidence in= this document going forward - and, therefore, it is hard to justify the WG= spending further time on this document (across all venues) >=20 > Respectfully, >=20 > Thomas >=20 > Sent from my iPad From chris.dearlove@baesystems.com Wed Nov 13 08:33:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1571021E8063 for ; Wed, 13 Nov 2013 08:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.061 X-Spam-Level: X-Spam-Status: No, score=-9.061 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axrvaJT9taj8 for ; Wed, 13 Nov 2013 08:33:19 -0800 (PST) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7291821F9EAF for ; Wed, 13 Nov 2013 08:33:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,693,1378854000"; d="scan'208";a="389123549" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 13 Nov 2013 16:33:19 +0000 X-IronPort-AV: E=Sophos;i="4.93,693,1378854000"; d="scan'208";a="32739669" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 13 Nov 2013 16:33:17 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.43]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 16:33:17 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , List List Thread-Topic: [manet] Regarding the reactive protocol development. Thread-Index: AQHO3LsZj65PnZR3tUqi5mA8pezmMpoc5WSAgAZ7pbA= Date: Wed, 13 Nov 2013 16:33:16 +0000 Message-ID: References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <527E383D.8030505@computer.org> In-Reply-To: <527E383D.8030505@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:33:23 -0000 I'm not going to get into most of this. I'm just going to note that were th= e security considerations section in this draft regarded as adequate by the= security ADs, then they would be applying very different standards to thos= e they have applied to OLSRv2. (I think that's easy to see as a factual statement by consulting the record= of what they have required, and then noting that several of these things a= re not present in this draft. Note that in the case of OLSRv2 that has resu= lted in the production of additional documents. This are not just trivial a= dditions either.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 09 November 2013 13:27 To: List List Subject: Re: [manet] Regarding the reactive protocol development. ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello folks, I'm traveling and don't have time just now to go dig out the precise emails. But, given the tone of this email, I thought it appropriate to at least make an initial response. Inline below. On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote: > Stan Ratliff asked me to bring some of the comments I made at the mike du= ring the MANET wg meeting yesterday, to the list. I believe that this is a = good idea, if for nothing else but to enter them into public record. > > I realize, though, that the points I raised during the meeting yesterday = actually already ARE public record, and have been so since 2010: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > So, I'll hereby go on public record indicating that I've been on public r= ecord with these things since 2010... > > 1) The detailed review comments that I gave to the reactive protocol (at = the time, known under the name DYMO) during the Maastricht IETF'78 (in 2010= ) still largely apply to the current incarnation of the MANET reactive prot= ocol. My review comments were posted to the MANET mailing list, and are on = record in the archives: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > Around at the same time, other reviews were posted by others. A quick ski= m through these indicate that many of those review comments have not been a= ddressed either. > I believe that it would have behoved the authors to look through these re= views when reviving this activity, and to ensure that the comments were ref= lected in the document - or, deflected through discussion on the list. Alas= , given that such reviews (still) have not been throughly addressed by the = most recent WG document, I'm not sure that providing a review again saying = the same is any good use of my (or WG) time. I did in fact address these issues, resulting in a thoroughgoing revision of the document. I got no feedback at the time, and so thought there wasn't much more to do. It would be nice to see just what particular points remain to do, especially if they were put on the issue tracker. > 2) RFC5444 is used wrongly in the document: positional semantics of addre= ss, and semantics of an address given by its mere presence in a message, h= as as consequence that it is nigh impossible to develop extensions that are= backwards compatible. It's a comment that the WG well should be aware of, = as it was raised in the context of early versions of DLEP (where it was pro= mptly resolved). > > Note: This issue also was raised in the review cited under point 1.The d= ocument must be > substantially revised to this effect. Similarly, I did address these issues and as far as I know the current specification is in conformance with RFC 5444. > > 3) The document is extremely unstructured. When I get a message X, then w= hat procedure must I follow? This information is scattered throughout the 6= 0ish pages, and it renders it extremely complicated to even begin to unders= tand how to implement correctly. I've read the document on the way over to = Vancouver, and I've read it again this morning. I still can't properly draw= the state machines, and there're processing bits that I *think* are not sp= ecified (but maybe reading it a 3rd time is required). The point here is, t= he IETF writes specifications so as to help implementers make correct imple= mentations. This document makes it a lot of work to try to figure out what'= s supposed to be implemented. > > Note: This issue also was raised in the review cited under point 1.The d= ocument must be > substantially revised to this effect. Similarly, I did address this issue. However, one person's view of proper structure may differ from another person's view. If there are any questions about how to follow a procedure, they should be pointed out. Cross references can be inserted as needed, or document sections rearranged. I already did a lot of rearrangement, but I am certainly willing to do more. > > 4) The document employs sloppy terminology and invented (and redundant) n= on-standard terminology. For example, but non-exhaustively, the terms "Rout= ing client" and "node" - why not the well-defined terms "host" and "router= "? > > Note: This issue also was raised in the review cited under point 1.The d= ocument must be > substantially revised to this effect. The terms cited above have particular meanings in the document. The suggested terms "host" and "router" do not capture the more specific meanings required at certain points in the document. > > 5) I am worrying that there are virtually non-existent security considera= tions in this document. In part, "in this day and age, this is unacceptable= ", but more pragmatically, having seen the (justified) scrutiny that the SE= C-DIR and SEC ADs apply to documents they review, this won't pass muster. > > Note: This issue was only touched upon in the review cited under point 1. > But, I still believe that the document must be substantially revised to= this effect. As best I understand, the security considerations are sufficient. This is a topic that deserves more attention. > > 6) The document is ripe with options, often expressed vaguely "XX should = be done, you can do that by, for example ZZ, YY or WW....", and that makes = me worried. Options means code branches, which means more test-cases to run= through (and, more branches in an interoperability test). It also means, t= hat if an implementation "does XX by way of ZZ", will that, or will that no= t, interoperate with an implementation that "does XX by way of WW"? > > I believe that the author presenting implicitly acknowledged that such op= tions make things complicated - by saying that the first implementation tha= t he intended to produce would be very partial and include only a "core" wi= thout options. This is a very generic comment that applies to practically every protocol in the IETF, including DHCP, IPv6, SIP, IP, TCP, Mobile IP, ... The "complication" alluded to is far less than in most existing protocols, and (again) has been thoroughly understood from past work. > > Note: I have numerous times (since the last Paris IETF, at least) sugges= ted that in that case > it's miles better to produce a document with that minimal "core", leavin= g options for a later > process. This ignores the fact that the optional features have been well known for many years, and in fact the current division of functionality into "base" versus "option" was done in response to previous requests. I am not aware of any IETF requirement to delete all optional features when producing base documents. > > 7) Given that the above comments have been made ad infinitum since Maastr= icht, on the list and in WG meetings, without seeing any improvement of the= document, it is hard to justify the efforts of making further reviews or c= omments: so far, such have been ignored. A good start would be to incorpora= te those reviews, for the authors to show "good faith" and listen to the WG. This is a gross misrepresentation of fact, and as best I can tell the person making this complaint has made very little effort been made to review recent versions of the document, despite my requests. If further elaboration is needed I will go back and find the relevant emails, but right now I can't do that. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Having said all that, I encourage constructive dialog and more detailed suggestions about how to improve document structure and terminology. I think it is appropriate to move forward with the document including the current optional features, or perhaps including also the intermediate route reply which is a feature that was originally specified in the base document and has long been part of the reactive routing protocol development. If specific suggestions are made to improve the document structure or terminology (again, much better if posted to the issue tracker), I can respond much more effectively and will make document revisions in a timely fashion. -- = Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ietf@thomasclausen.org Wed Nov 13 12:06:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF911E814C for ; Wed, 13 Nov 2013 12:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Z73tiKsDBw for ; Wed, 13 Nov 2013 12:06:38 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F311E8126 for ; Wed, 13 Nov 2013 12:06:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5E0D62019A3; Wed, 13 Nov 2013 12:06:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.23] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A57FA2019A1; Wed, 13 Nov 2013 12:06:37 -0800 (PST) References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> X-Mailer: iPad Mail (11B511) From: Thomas Heide Clausen Date: Wed, 13 Nov 2013 21:06:35 +0100 To: "Stan Ratliff (sratliff)" Cc: List List , Joe Macker Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:06:43 -0000 I would have expected that the editing team had worked through this already i= n 2010 when the comments were first raised......or that the current editing t= eam would have done so when appointed.=20 Indeed, Mr. Perkins indicated in his reply to my email that he believes that= the team has done so already, that no further actions are required on these= points, and generally brushes off the comments made. Past behavior is a good way of predicting future actions. Given that the author "holding the pen" for this document is the same since 2= 010, and that that author has gone on record stating that he believes that n= o further changes are needed to address my comments, I submit that I do not h= ave any confidence that "the editing team will work through the items...and e= ndeavor to make the document better". It behoves the WG to act accordingly - as Ulrich suggest, by either declarin= g defeat wrt delivering on a reactive protocol milestone, and recharter to r= emove this from the charter, or by appointing a different set of authors for= this item. Respectfully, Thomas Sent from my iPad > On 13 nov. 2013, at 16:49, "Stan Ratliff (sratliff)" w= rote: >=20 > Thomas,=20 >=20 > Thank you for taking the time to do this. The editing team will work throu= gh the items you list here, and endeavor to make the document better.=20 >=20 > I'd also like to thank Ulrich for his additional comments & review; those i= tems will be looked at as well.=20 >=20 > Regards, > Stan >=20 >> On Nov 8, 2013, at 2:44 PM, Thomas Heide Clausen = wrote: >>=20 >> Stan Ratliff asked me to bring some of the comments I made at the mike du= ring the MANET wg meeting yesterday, to the list. I believe that this is a g= ood idea, if for nothing else but to enter them into public record.=20 >>=20 >> I realize, though, that the points I raised during the meeting yesterday a= ctually already ARE public record, and have been so since 2010: >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg11858.html >>=20 >> So, I'll hereby go on public record indicating that I've been on public r= ecord with these things since 2010... >>=20 >> 1) The detailed review comments that I gave to the reactive protocol (at t= he time, known under the name DYMO) during the Maastricht IETF'78 (in 2010) s= till largely apply to the current incarnation of the MANET reactive protocol= . My review comments were posted to the MANET mailing list, and are on recor= d in the archives: >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg11858.html >>=20 >> Around at the same time, other reviews were posted by others. A quick ski= m through these indicate that many of those review comments have not been ad= dressed either. >> I believe that it would have behoved the authors to look through these re= views when reviving this activity, and to ensure that the comments were refl= ected in the document - or, deflected through discussion on the list. Alas, g= iven that such reviews (still) have not been throughly addressed by the most= recent WG document, I'm not sure that providing a review again saying the s= ame is any good use of my (or WG) time.=20 >>=20 >> 2) RFC5444 is used wrongly in the document: positional semantics of addre= ss, and semantics of an address given by its mere presence in a message, ha= s as consequence that it is nigh impossible to develop extensions that are b= ackwards compatible. It's a comment that the WG well should be aware of, as i= t was raised in the context of early versions of DLEP (where it was promptly= resolved).=20 >>=20 >> Note: This issue also was raised in the review cited under point 1.The= document must be=20 >> substantially revised to this effect. >>=20 >> 3) The document is extremely unstructured. When I get a message X, then w= hat procedure must I follow? This information is scattered throughout the 60= ish pages, and it renders it extremely complicated to even begin to understa= nd how to implement correctly. I've read the document on the way over to Van= couver, and I've read it again this morning. I still can't properly draw the= state machines, and there're processing bits that I *think* are not specifi= ed (but maybe reading it a 3rd time is required). The point here is, the IET= F writes specifications so as to help implementers make correct implementati= ons. This document makes it a lot of work to try to figure out what's suppos= ed to be implemented. >>=20 >> Note: This issue also was raised in the review cited under point 1.The= document must be >> substantially revised to this effect. >>=20 >> 4) The document employs sloppy terminology and invented (and redundant) n= on-standard terminology. For example, but non-exhaustively, the terms "Routi= ng client" and "node" - why not the well-defined terms "host" and "router"?= =20 >>=20 >> Note: This issue also was raised in the review cited under point 1.The= document must be=20 >> substantially revised to this effect. >>=20 >> 5) I am worrying that there are virtually non-existent security considera= tions in this document. In part, "in this day and age, this is unacceptable"= , but more pragmatically, having seen the (justified) scrutiny that the SEC-= DIR and SEC ADs apply to documents they review, this won't pass muster.=20 >>=20 >> Note: This issue was only touched upon in the review cited under point= 1. >> But, I still believe that the document must be substantially revised t= o this effect. >>=20 >> 6) The document is ripe with options, often expressed vaguely "XX should b= e done, you can do that by, for example ZZ, YY or WW....", and that makes me= worried. Options means code branches, which means more test-cases to run th= rough (and, more branches in an interoperability test). It also means, that i= f an implementation "does XX by way of ZZ", will that, or will that not, int= eroperate with an implementation that "does XX by way of WW"?=20 >>=20 >> I believe that the author presenting implicitly acknowledged that such op= tions make things complicated - by saying that the first implementation that= he intended to produce would be very partial and include only a "core" with= out options.=20 >>=20 >> Note: I have numerous times (since the last Paris IETF, at least) sugg= ested that in that case=20 >> it's miles better to produce a document with that minimal "core", leav= ing options for a later=20 >> process. >>=20 >> 7) Given that the above comments have been made ad infinitum since Maastr= icht, on the list and in WG meetings, without seeing any improvement of the d= ocument, it is hard to justify the efforts of making further reviews or comm= ents: so far, such have been ignored. A good start would be to incorporate t= hose reviews, for the authors to show "good faith" and listen to the WG. >>=20 >> 8) Given that the past 12 months, when the effort was "rebooted" by the r= esponsible AD, have yielded no improvement of the document quality, and has s= een none of the comments previously made, it's hard to have confidence in th= is document going forward - and, therefore, it is hard to justify the WG spe= nding further time on this document (across all venues) >>=20 >> Respectfully, >>=20 >> Thomas >>=20 >> Sent from my iPad >=20 From charliep@computer.org Wed Nov 13 12:42:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193B721F9E9D for ; Wed, 13 Nov 2013 12:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPGMhfLlXKtj for ; Wed, 13 Nov 2013 12:42:45 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 44E9121E8121 for ; Wed, 13 Nov 2013 12:42:18 -0800 (PST) Received: from [216.1.225.2] (helo=[10.100.9.87]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VghGO-0001HY-3l for manet@ietf.org; Wed, 13 Nov 2013 15:42:12 -0500 Message-ID: <5283E41E.4080607@computer.org> Date: Wed, 13 Nov 2013 12:42:06 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org><8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> In-Reply-To: <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f4c563ad6af5ba009c685fe8a3544bfb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.1.225.2 Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:42:51 -0000 Hello folks, The narrative below misrepresents my past actions. On 11/13/2013 12:06 PM, Thomas Heide Clausen wrote: > I would have expected that the editing team had worked through this already in 2010 when the comments were first raised......or that the current editing team would have done so when appointed. > > Indeed, Mr. Perkins indicated in his reply to my email that he believes that the team has done so already, that no further actions are required on these points, and generally brushes off the comments made. What I said was that, after revisions had been proposed to resolve the old comments, no further feedback was received. If further revision is needed, I am certainly ready to discuss and take action. That is really quite different than the above-mentioned characterization of my response. Also please keep in mind that these comments were submitted a long time before I restarted as the active document editor. I retrieved them from the mailing list archive precisely so that I could be as responsive as possible to the concerns that had been raised. This is the polar opposite from being dismissive. > Past behavior is a good way of predicting future actions. Indeed. Publicly and privately I have always done what I said I would do. > Given that the author "holding the pen" for this document is the same since 2010, and that that author has gone on record stating that he believes that no further changes are needed to address my comments, ... Again, this is not at all what I said. After I made the revisions in an effort to resolve the issues that had been raised, no further response was ever received and therefore I could not know whether or not my resolution was successful. Given recent notifications that more work is needed, I suggest we identify proper resolutions to the remaining problems. > It behoves the WG to act accordingly - as Ulrich suggest, by either declaring defeat wrt delivering on a reactive protocol milestone, and recharter to remove this from the charter, or by appointing a different set of authors for this item. Now that new comments have been received, I suggest that we work through them. It would be nice if the new comments were submitted to the issue tracker. Failing that, I will identify and isolate the separate issues and put them on the issue tracker myself. -- Regards, Charlie P. From ietf@thomasclausen.org Wed Nov 13 13:27:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1DB21E80B3 for ; Wed, 13 Nov 2013 13:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPrM8FJMipKP for ; Wed, 13 Nov 2013 13:27:37 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id F3CBB21E80E2 for ; Wed, 13 Nov 2013 13:27:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D063E480322; Wed, 13 Nov 2013 13:27:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.23] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6BEA04801ED; Wed, 13 Nov 2013 13:27:36 -0800 (PST) References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> <5283E41E.4080607@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5283E41E.4080607@computer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B511) From: Thomas Heide Clausen Date: Wed, 13 Nov 2013 22:27:33 +0100 To: "Charles E. Perkins" Cc: Mobile Ad Hoc Networks mailing list , Stan Ratliff Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:27:43 -0000 AFAIK, there has been no "editor" designation for either iteration of this I= -D, but a collective of authors. Mr. Perkins claims that: "Also please keep in mind that these comments were submitted a long= =20 time before I restarted as the active document editor. " Let me produce some evidence that Mr. Perkins is wrong in that claim: 2005: draft-ietf-manet-dymo-00 Authors: I. Chakeres, B. Belding-Royer, C. Perkins (neither of which is postfixed as "Ed" or "Editor")= 2010: draft-ietf-manet-dymo-21 Authors: I. Chakeres, C. Perkins (neither of which is postfixed as "Ed" or "Editor")= =09 2013: draft-ietf-manet-aodvv2-02 Authors: C. Perkins, S. Ratliff, J. Dowdell (neither of which is postfixed as "Ed" or "Editor")= Thus, Mr. Perkins has been among the authors *continuously* since the incept= ion of the reactive protocol development, and thus carries responsibility fo= r having ignored WG input in the protocol development process. Also, Mr. Perkins claims: "Now that new comments have been received," I shall insist that no new comments have been made, and therefore not receiv= ed, and that Mr. Perkins is factually wrong also here.=20 The recent mails by Ulrich and I (and, to some extend, also by Chris) are si= mply restatements (with pointers) of the reviews/comments that were already m= ade since, at least, 2010. Thus, there are no misrepresentations in the "narrative", contrary to the cl= aims of Mr. Perkins. Respectfully, Thomas Sent from my iPad > On 13 nov. 2013, at 21:42, "Charles E. Perkins" wr= ote: >=20 >=20 > Hello folks, >=20 > The narrative below misrepresents my past actions. >=20 >> On 11/13/2013 12:06 PM, Thomas Heide Clausen wrote: >> I would have expected that the editing team had worked through this alrea= dy in 2010 when the comments were first raised......or that the current edit= ing team would have done so when appointed. >>=20 >> Indeed, Mr. Perkins indicated in his reply to my email that he believes t= hat the team has done so already, that no further actions are required on th= ese points, and generally brushes off the comments made. >=20 > What I said was that, after revisions had been proposed to resolve the old= comments, > no further feedback was received. If further revision is needed, I am cer= tainly ready > to discuss and take action. >=20 > That is really quite different than the above-mentioned characterization o= f my > response. Also please keep in mind that these comments were submitted a l= ong > time before I restarted as the active document editor. I retrieved them f= rom the > mailing list archive precisely so that I could be as responsive as possibl= e to the > concerns that had been raised. This is the polar opposite from being dism= issive. >=20 >=20 >> Past behavior is a good way of predicting future actions. >=20 > Indeed. Publicly and privately I have always done what I said I would do.= >=20 >> Given that the author "holding the pen" for this document is the same sin= ce 2010, and that that author has gone on record stating that he believes th= at no further changes are needed to address my comments, ... >=20 > Again, this is not at all what I said. After I made the revisions in an e= ffort > to resolve the issues that had been raised, no further response was ever > received and therefore I could not know whether or not my resolution > was successful. Given recent notifications that more work is needed, I > suggest we identify proper resolutions to the remaining problems. >=20 >> It behoves the WG to act accordingly - as Ulrich suggest, by either decla= ring defeat wrt delivering on a reactive protocol milestone, and recharter t= o remove this from the charter, or by appointing a different set of authors f= or this item. >=20 > Now that new comments have been received, I suggest that we work through t= hem. > It would be nice if the new comments were submitted to the issue tracker. = Failing > that, I will identify and isolate the separate issues and put them on the i= ssue tracker > myself. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@gmail.com Wed Nov 13 13:47:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7021E8168 for ; Wed, 13 Nov 2013 13:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ipd7GOROOGL for ; Wed, 13 Nov 2013 13:47:41 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AA7E221E8160 for ; Wed, 13 Nov 2013 13:47:40 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id t60so1049146wes.36 for ; Wed, 13 Nov 2013 13:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uqge1qfTo/cro8uj8AeXTAwkWZdJnKvl6iDGyj9QNgs=; b=P9Ta+TipGf6NSOijHOVJS0ooVFKyNoXt9WW7IyM5ziM8aRcocug8IGDtXH/WQYkv/V tKtenE/M5/kv13Rn2+yEktfEX4i38uEtTHZxdLV0ATw4pclb8SoPDSHgbE6k8qzd+u/i lWFcF5tYe5aS6bjbpO+c8cjrDFqJNrq3ONIpBsWDtNrpi3QWJXVI3HKtV1ULnQnztANE R5e0Kl8iUcRkhyZswdUX0db6UCZuqkxTbq63x8IhamKf3bukkWme/ZXpLUOnaO0CxFXz RsYSkoTNC9u25ffSUAFkbv7U7vW/L9eElUFb9ATwPsFjOKqBUPFZaw2EyX0W2a7jpm9o Zy0g== X-Received: by 10.180.39.212 with SMTP id r20mr22358490wik.13.1384379259716; Wed, 13 Nov 2013 13:47:39 -0800 (PST) Received: from [192.168.254.4] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id dz5sm35589323wib.7.2013.11.13.13.47.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 13:47:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Wed, 13 Nov 2013 21:47:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7E0AE238-C88B-4119-8EE7-F8329707CB0C@mnemosyne.demon.co.uk> References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> <5283E41E.4080607@computer.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1283) Cc: Mobile Ad Hoc Networks mailing list , Stan Ratliff Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:47:42 -0000 Actually, on my comment, I'll note that something of the style of the = current security considerations section might have flown some years back = - compare for example RFC 6130. But won't fly now, unless things change = again, which I find unlikely. So I wouldn't classify my comment from this round as simply a = restatement. (Once you get to deciding you need an actual mechanism, then some other = issues arise. But those come later.) On 13 Nov 2013, at 21:27, Thomas Heide Clausen wrote: >=20 > AFAIK, there has been no "editor" designation for either iteration of = this I-D, but a collective of authors. >=20 > Mr. Perkins claims that: > "Also please keep in mind that these comments were submitted a = long=20 > time before I restarted as the active document editor. " >=20 > Let me produce some evidence that Mr. Perkins is wrong in that claim: >=20 > 2005: > draft-ietf-manet-dymo-00 > Authors: I. Chakeres, B. Belding-Royer, C. Perkins > (neither of which is postfixed as "Ed" or = "Editor") >=20 > 2010: > draft-ietf-manet-dymo-21 > Authors: I. Chakeres, C. Perkins > (neither of which is postfixed as "Ed" or = "Editor")=09 >=20 > 2013: > draft-ietf-manet-aodvv2-02 > Authors: C. Perkins, S. Ratliff, J. Dowdell > (neither of which is postfixed as "Ed" or = "Editor") >=20 > Thus, Mr. Perkins has been among the authors *continuously* since the = inception of the reactive protocol development, and thus carries = responsibility for having ignored WG input in the protocol development = process. >=20 > Also, Mr. Perkins claims: > "Now that new comments have been received," >=20 > I shall insist that no new comments have been made, and therefore not = received, and that Mr. Perkins is factually wrong also here.=20 >=20 > The recent mails by Ulrich and I (and, to some extend, also by Chris) = are simply restatements (with pointers) of the reviews/comments that = were already made since, at least, 2010. >=20 > Thus, there are no misrepresentations in the "narrative", contrary to = the claims of Mr. Perkins. >=20 > Respectfully, >=20 > Thomas >=20 > Sent from my iPad >=20 >> On 13 nov. 2013, at 21:42, "Charles E. Perkins" = wrote: >>=20 >>=20 >> Hello folks, >>=20 >> The narrative below misrepresents my past actions. >>=20 >>> On 11/13/2013 12:06 PM, Thomas Heide Clausen wrote: >>> I would have expected that the editing team had worked through this = already in 2010 when the comments were first raised......or that the = current editing team would have done so when appointed. >>>=20 >>> Indeed, Mr. Perkins indicated in his reply to my email that he = believes that the team has done so already, that no further actions are = required on these points, and generally brushes off the comments made. >>=20 >> What I said was that, after revisions had been proposed to resolve = the old comments, >> no further feedback was received. If further revision is needed, I = am certainly ready >> to discuss and take action. >>=20 >> That is really quite different than the above-mentioned = characterization of my >> response. Also please keep in mind that these comments were = submitted a long >> time before I restarted as the active document editor. I retrieved = them from the >> mailing list archive precisely so that I could be as responsive as = possible to the >> concerns that had been raised. This is the polar opposite from being = dismissive. >>=20 >>=20 >>> Past behavior is a good way of predicting future actions. >>=20 >> Indeed. Publicly and privately I have always done what I said I = would do. >>=20 >>> Given that the author "holding the pen" for this document is the = same since 2010, and that that author has gone on record stating that he = believes that no further changes are needed to address my comments, ... >>=20 >> Again, this is not at all what I said. After I made the revisions in = an effort >> to resolve the issues that had been raised, no further response was = ever >> received and therefore I could not know whether or not my resolution >> was successful. Given recent notifications that more work is needed, = I >> suggest we identify proper resolutions to the remaining problems. >>=20 >>> It behoves the WG to act accordingly - as Ulrich suggest, by either = declaring defeat wrt delivering on a reactive protocol milestone, and = recharter to remove this from the charter, or by appointing a different = set of authors for this item. >>=20 >> Now that new comments have been received, I suggest that we work = through them. >> It would be nice if the new comments were submitted to the issue = tracker. Failing >> that, I will identify and isolate the separate issues and put them on = the issue tracker >> myself. >>=20 >> --=20 >> Regards, >> Charlie P. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From yi.jiazi@gmail.com Thu Nov 14 09:05:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0005021E80EC for ; Thu, 14 Nov 2013 09:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmgfc3VBsJRB for ; Thu, 14 Nov 2013 09:05:24 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B849A21E80E3 for ; Thu, 14 Nov 2013 09:05:24 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id q10so2266886pdj.1 for ; Thu, 14 Nov 2013 09:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=YrehTKsSkPsHBHV3QPPeTF7nKlMQwZ6Eg/3ivQdPdtA=; b=EjiwKllBVH6M/TCyKvsoF66rTFm2c4TE/qIv1kcedNRdUojDZRy6JrVYLlvUIl9ggm 93HgG/OSdm/dFCKLDO7U/FsDZ9ubdXFN8JZxq+MFvVwGbQ+TPKiyd0xq9Gns+y3LKS+e 7Z81j+OgqOmgFK9f3t9DlNe59LOuXltPZDGTcw9b6IURH5VTo8LDHNOPZ1zVchNHYnTC TDUEgFEfIGWLgZS7n3RHj+cbnlLbRWfKFuLKaxXo+yJGVCzl+ntvZITQnLqLyV86+Fh+ RDljpfi5lrII+bNBQpzfmgHyqxprGIvX7dKO/kkEgoq7bxLvblVAjDznVSZFdBCXXo88 5v6g== X-Received: by 10.68.240.2 with SMTP id vw2mr2502545pbc.80.1384448724273; Thu, 14 Nov 2013 09:05:24 -0800 (PST) Received: from jy-mac-pro.local ([58.212.52.123]) by mx.google.com with ESMTPSA id ye1sm319843pab.19.2013.11.14.09.05.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 09:05:22 -0800 (PST) Message-ID: <528502C6.2070507@gmail.com> Date: Fri, 15 Nov 2013 01:05:10 +0800 From: Jiazi Yi User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org><8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> <5283E41E.4080607@computer.org> In-Reply-To: <5283E41E.4080607@computer.org> Content-Type: multipart/alternative; boundary="------------090409010209040503050401" Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:05:27 -0000 This is a multi-part message in MIME format. --------------090409010209040503050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, While Thomas Clausen believed that > TC>> 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG. > > TC>> 8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues) Charles Perkins keeps saying: > CP>> This is a gross misrepresentation of fact. Without going into every comment that Thomas Clausen made, we can do a little "case study" here: >> : 2) RFC5444 is used wrongly in the document: positional >> semantics of address, and semantics of an address given by its mere >> presence in a message, has as consequence that it is nigh impossible >> to develop extensions that are backwards compatible. It's a comment >> that the WG well should be aware of, as it was raised in the context >> of early versions of DLEP (where it was promptly resolved). >> >> Note: This issue also was raised in the review cited under point >> 1.The document must be >> substantially revised to this effect. > > : Similarly, I did address these issues and as far as I know the > current specification is in conformance with RFC 5444. > This issue, has been discussed for 1~ year in the working group. Most of the participants (if not all the other), including Ulrich, Justin, Henning have expressed that the address positions should be independent. In the previous discussions, Ulrich, Henning, and Thomas have stated why this is important. The feedback from Charlie is "I'm not at all interested in arguing about it, especially right now!" http://www.ietf.org/mail-archive/web/manet/current/msg14756.html Stan also said that > For me, the issue here is that working group consensus seems to > have solidified around positional independence. If fact, Charlie, you > seem to be the only one holding the counter position. Based on > Adrian's email on the way forward, the specification needs to reflect > the consensus of the WG. As of right now, that means it (the spec) > needs to change. http://www.ietf.org/mail-archive/web/manet/current/msg14763.html However, if we look back at the latest revision of AODVv2, we still have http://tools.ietf.org/html/draft-ietf-manet-aodvv2-02#section-3 > | AddrBlk[1] | The first address slot in AddrBlk | > | AddrBlk[N] | The Nth address slot in AddrBlk | > | OrigNdx | The index of OrigNode within the AddrBlk | > | TargNdx | The index of TargNode within the AddrBlk | > | AddrTLV[1] | the first item in AddrTLV | > | AddrTLV[N] | the Nth item in AddrTLV | > | AddrTLV[OrigNode] | AddrTLV[OrigNdx] | > | AddrTLV[TargNode] | AddrTLV[TargNdx] Defined in "Notational Conventions" section, and used in all over the draft. While Charles Perkins still thinks > CP>> Similarly, I did address these issues and as far as I know the > current specification is in conformance with RFC 5444. ================================================= This is just one example - I can dig into the mailing list to get similar discussions on other issues. What I observed is that, even the WG group consensus is so obvious, it is extremely hard to have it addressed in the WG document (because the editor thinks it is addressed). Therefore, I would say that from my point of view, Thomas Clausen's observation is not misrepresented. Additionally, I'm very shocked when hearing Charlie said > Also please keep in mind that these comments were submitted a long > time before I restarted as the active document editor. who had been listed as co-author of dymo draft since 2005. Sincerely Jiazi YI > Charles E. Perkins > 14 Nov 2013 04:42 > > Hello folks, > > The narrative below misrepresents my past actions. > > On 11/13/2013 12:06 PM, Thomas Heide Clausen wrote: >> I would have expected that the editing team had worked through this >> already in 2010 when the comments were first raised......or that the >> current editing team would have done so when appointed. >> >> Indeed, Mr. Perkins indicated in his reply to my email that he >> believes that the team has done so already, that no further actions >> are required on these points, and generally brushes off the comments >> made. > > What I said was that, after revisions had been proposed to resolve the > old comments, > no further feedback was received. If further revision is needed, I am > certainly ready > to discuss and take action. > > That is really quite different than the above-mentioned > characterization of my > response. Also please keep in mind that these comments were submitted > a long > time before I restarted as the active document editor. I retrieved > them from the > mailing list archive precisely so that I could be as responsive as > possible to the > concerns that had been raised. This is the polar opposite from being > dismissive. > > >> Past behavior is a good way of predicting future actions. > > Indeed. Publicly and privately I have always done what I said I would > do. > >> Given that the author "holding the pen" for this document is the same >> since 2010, and that that author has gone on record stating that he >> believes that no further changes are needed to address my comments, ... > > Again, this is not at all what I said. After I made the revisions in > an effort > to resolve the issues that had been raised, no further response was ever > received and therefore I could not know whether or not my resolution > was successful. Given recent notifications that more work is needed, I > suggest we identify proper resolutions to the remaining problems. > >> It behoves the WG to act accordingly - as Ulrich suggest, by either >> declaring defeat wrt delivering on a reactive protocol milestone, and >> recharter to remove this from the charter, or by appointing a >> different set of authors for this item. > > Now that new comments have been received, I suggest that we work > through them. > It would be nice if the new comments were submitted to the issue > tracker. Failing > that, I will identify and isolate the separate issues and put them on > the issue tracker > myself. > > Stan Ratliff (sratliff) > 13 Nov 2013 23:49 > Thomas, > > Thank you for taking the time to do this. The editing team will work > through the items you list here, and endeavor to make the document > better. > > I'd also like to thank Ulrich for his additional comments & review; > those items will be looked at as well. > > Regards, > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > Thomas Heide Clausen > 9 Nov 2013 03:44 > Stan Ratliff asked me to bring some of the comments I made at the mike > during the MANET wg meeting yesterday, to the list. I believe that > this is a good idea, if for nothing else but to enter them into public > record. > > I realize, though, that the points I raised during the meeting > yesterday actually already ARE public record, and have been so since 2010: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > So, I'll hereby go on public record indicating that I've been on > public record with these things since 2010... > > 1) The detailed review comments that I gave to the reactive protocol > (at the time, known under the name DYMO) during the Maastricht IETF'78 > (in 2010) still largely apply to the current incarnation of the MANET > reactive protocol. My review comments were posted to the MANET mailing > list, and are on record in the archives: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > Around at the same time, other reviews were posted by others. A quick > skim through these indicate that many of those review comments have > not been addressed either. > I believe that it would have behoved the authors to look through these > reviews when reviving this activity, and to ensure that the comments > were reflected in the document - or, deflected through discussion on > the list. Alas, given that such reviews (still) have not been > throughly addressed by the most recent WG document, I'm not sure that > providing a review again saying the same is any good use of my (or WG) > time. > > 2) RFC5444 is used wrongly in the document: positional semantics of > address, and semantics of an address given by its mere presence in a > message, has as consequence that it is nigh impossible to develop > extensions that are backwards compatible. It's a comment that the WG > well should be aware of, as it was raised in the context of early > versions of DLEP (where it was promptly resolved). > > Note: This issue also was raised in the review cited under point 1.The > document must be > substantially revised to this effect. > > 3) The document is extremely unstructured. When I get a message X, > then what procedure must I follow? This information is scattered > throughout the 60ish pages, and it renders it extremely complicated to > even begin to understand how to implement correctly. I've read the > document on the way over to Vancouver, and I've read it again this > morning. I still can't properly draw the state machines, and there're > processing bits that I *think* are not specified (but maybe reading it > a 3rd time is required). The point here is, the IETF writes > specifications so as to help implementers make correct > implementations. This document makes it a lot of work to try to figure > out what's supposed to be implemented. > > Note: This issue also was raised in the review cited under point 1.The > document must be > substantially revised to this effect. > > 4) The document employs sloppy terminology and invented (and > redundant) non-standard terminology. For example, but > non-exhaustively, the terms "Routing client" and "node" - why not the > well-defined terms "host" and "router"? > > Note: This issue also was raised in the review cited under point 1.The > document must be > substantially revised to this effect. > > 5) I am worrying that there are virtually non-existent security > considerations in this document. In part, "in this day and age, this > is unacceptable", but more pragmatically, having seen the (justified) > scrutiny that the SEC-DIR and SEC ADs apply to documents they review, > this won't pass muster. > > Note: This issue was only touched upon in the review cited under point 1. > But, I still believe that the document must be substantially revised > to this effect. > > 6) The document is ripe with options, often expressed vaguely "XX > should be done, you can do that by, for example ZZ, YY or WW....", and > that makes me worried. Options means code branches, which means more > test-cases to run through (and, more branches in an interoperability > test). It also means, that if an implementation "does XX by way of > ZZ", will that, or will that not, interoperate with an implementation > that "does XX by way of WW"? > > I believe that the author presenting implicitly acknowledged that such > options make things complicated - by saying that the first > implementation that he intended to produce would be very partial and > include only a "core" without options. > > Note: I have numerous times (since the last Paris IETF, at least) > suggested that in that case > it's miles better to produce a document with that minimal "core", > leaving options for a later > process. > > 7) Given that the above comments have been made ad infinitum since > Maastricht, on the list and in WG meetings, without seeing any > improvement of the document, it is hard to justify the efforts of > making further reviews or comments: so far, such have been ignored. A > good start would be to incorporate those reviews, for the authors to > show "good faith" and listen to the WG. > > 8) Given that the past 12 months, when the effort was "rebooted" by > the responsible AD, have yielded no improvement of the document > quality, and has seen none of the comments previously made, it's hard > to have confidence in this document going forward - and, therefore, it > is hard to justify the WG spending further time on this document > (across all venues) > > Respectfully, > > Thomas > > Sent from my iPad > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------090409010209040503050401 Content-Type: multipart/related; boundary="------------080505090303080902010809" --------------080505090303080902010809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

While Thomas Clausen believed that

TC>> 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG.

TC>> 8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues)
Charles Perkins keeps saying:
CP>> This is a gross misrepresentation of fact.

Without going into every comment that Thomas Clausen made, we can do a little "case study" here:
<TC>: 2) RFC5444 is used wrongly in the document: positional semantics of address, and semantics of  an address given by its mere presence in a message, has as consequence that it is nigh impossible to develop extensions that are backwards compatible. It's a comment that the WG well should be aware of, as it was raised in the context of early versions of DLEP (where it was promptly resolved).

    Note: This issue also was raised in the review cited under point 1.The document must be
    substantially revised to this effect.

<CP>: Similarly, I did address these issues and as far as I know the
current specification is in conformance with RFC 5444.
<SNIP>

This issue, has been discussed for 1~ year in the working group. Most of the participants (if not all the other), including Ulrich, Justin, Henning have expressed that the address positions should be independent.

In the previous discussions, Ulrich, Henning, and Thomas have stated why this is important. The feedback from Charlie is "I'm not at
all interested in arguing about it, especially right now!"  http://www.ietf.org/mail-archive/web/manet/current/msg14756.html

Stan also said that

<SR> For me, the issue here is that working group consensus seems to have solidified around positional independence. If fact, Charlie, you seem to be the only one holding the counter position. Based on Adrian's email on the way forward, the specification needs to reflect the consensus of the WG. As of right now, that means it (the spec) needs to change. 
http://www.ietf.org/mail-archive/web/manet/current/msg14763.html

However, if we look back at the latest revision of AODVv2, we still have
http://tools.ietf.org/html/draft-ietf-manet-aodvv2-02#section-3
    |      AddrBlk[1]     |    The first address slot in AddrBlk     |
    |      AddrBlk[N]     |     The Nth address slot in AddrBlk      |
    |       OrigNdx       | The index of OrigNode within the AddrBlk |
    |       TargNdx       | The index of TargNode within the AddrBlk |
 
    |      AddrTLV[1]     |        the first item in AddrTLV         |
    |      AddrTLV[N]     |         the Nth item in AddrTLV          |
    |  AddrTLV[OrigNode]  |             AddrTLV[OrigNdx]             |
    |  AddrTLV[TargNode]  |             AddrTLV[TargNdx]
 
Defined in "Notational Conventions" section, and used in all over the draft.

While Charles Perkins still thinks

CP>> Similarly, I did address these issues and as far as I know the
current specification is in conformance with RFC 5444. 
=================================================

This is just one example  - I can dig into the mailing list to get similar discussions on other issues.
What I observed is that, even the WG group consensus is so obvious, it is extremely hard to have it addressed in the WG document (because the editor thinks it is addressed).

Therefore, I would say that from my point of view, Thomas Clausen's observation is not misrepresented.

Additionally, I'm very shocked when hearing Charlie said

Also please keep in mind that these comments were submitted a long 
	  time before I restarted as the active document editor.
who had been listed as co-author of dymo draft since 2005.

Sincerely

Jiazi YI


14 Nov 2013 04:42

Hello folks,

The narrative below misrepresents my past actions.

On 11/13/2013 12:06 PM, Thomas Heide Clausen wrote:
I would have expected that the editing team had worked through this already in 2010 when the comments were first raised......or that the current editing team would have done so when appointed.

Indeed, Mr. Perkins indicated in his reply to my email that he believes that the team has done so already, that no further actions are required on these points, and generally brushes off the comments made.

What I said was that, after revisions had been proposed to resolve the old comments,
no further feedback was received.  If further revision is needed, I am certainly ready
to discuss and take action.

That is really quite different than the above-mentioned characterization of my
response.  Also please keep in mind that these comments were submitted a long
time before I restarted as the active document editor.  I retrieved them from the
mailing list archive precisely so that I could be as responsive as possible to the
concerns that had been raised.  This is the polar opposite from being dismissive.


Past behavior is a good way of predicting future actions.

Indeed.  Publicly and privately I have always done what I said I would do.

Given that the author "holding the pen" for this document is the same since 2010, and that that author has gone on record stating that he believes that no further changes are needed to address my comments, ...

Again, this is not at all what I said.  After I made the revisions in an effort
to resolve the issues that had been raised, no further response was ever
received and therefore I could not know whether or not my resolution
was successful.  Given recent notifications that more work is needed, I
suggest we identify proper resolutions to the remaining problems.

It behoves the WG to act accordingly - as Ulrich suggest, by either declaring defeat wrt delivering on a reactive protocol milestone, and recharter to remove this from the charter, or by appointing a different set of authors for this item.

Now that new comments have been received, I suggest that we work through them.
It would be nice if the new comments were submitted to the issue tracker.  Failing
that, I will identify and isolate the separate issues and put them on the issue tracker
myself.

13 Nov 2013 23:49
Thomas,

Thank you for taking the time to do this. The editing team will work through the items you list here, and endeavor to make the document better.

I'd also like to thank Ulrich for his additional comments & review; those items will be looked at as well.

Regards,
Stan


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
9 Nov 2013 03:44
Stan Ratliff asked me to bring some of the comments I made at the mike during the MANET wg meeting yesterday, to the list. I believe that this is a good idea, if for nothing else but to enter them into public record.

I realize, though, that the points I raised during the meeting yesterday actually already ARE public record, and have been so since 2010:

http://www.ietf.org/mail-archive/web/manet/current/msg11858.html

So, I'll hereby go on public record indicating that I've been on public record with these things since 2010...

1) The detailed review comments that I gave to the reactive protocol (at the time, known under the name DYMO) during the Maastricht IETF'78 (in 2010) still largely apply to the current incarnation of the MANET reactive protocol. My review comments were posted to the MANET mailing list, and are on record in the archives:

http://www.ietf.org/mail-archive/web/manet/current/msg11858.html

Around at the same time, other reviews were posted by others. A quick skim through these indicate that many of those review comments have not been addressed either.
I believe that it would have behoved the authors to look through these reviews when reviving this activity, and to ensure that the comments were reflected in the document - or, deflected through discussion on the list. Alas, given that such reviews (still) have not been throughly addressed by the most recent WG document, I'm not sure that providing a review again saying the same is any good use of my (or WG) time.

2) RFC5444 is used wrongly in the document: positional semantics of address, and semantics of an address given by its mere presence in a message, has as consequence that it is nigh impossible to develop extensions that are backwards compatible. It's a comment that the WG well should be aware of, as it was raised in the context of early versions of DLEP (where it was promptly resolved).

Note: This issue also was raised in the review cited under point 1.The document must be
substantially revised to this effect.

3) The document is extremely unstructured. When I get a message X, then what procedure must I follow? This information is scattered throughout the 60ish pages, and it renders it extremely complicated to even begin to understand how to implement correctly. I've read the document on the way over to Vancouver, and I've read it again this morning. I still can't properly draw the state machines, and there're processing bits that I *think* are not specified (but maybe reading it a 3rd time is required). The point here is, the IETF writes specifications so as to help implementers make correct implementations. This document makes it a lot of work to try to figure out what's supposed to be implemented.

Note: This issue also was raised in the review cited under point 1.The document must be
substantially revised to this effect.

4) The document employs sloppy terminology and invented (and redundant) non-standard terminology. For example, but non-exhaustively, the terms "Routing client" and "node" - why not the well-defined terms "host" and "router"?

Note: This issue also was raised in the review cited under point 1.The document must be
substantially revised to this effect.

5) I am worrying that there are virtually non-existent security considerations in this document. In part, "in this day and age, this is unacceptable", but more pragmatically, having seen the (justified) scrutiny that the SEC-DIR and SEC ADs apply to documents they review, this won't pass muster.

Note: This issue was only touched upon in the review cited under point 1.
But, I still believe that the document must be substantially revised to this effect.

6) The document is ripe with options, often expressed vaguely "XX should be done, you can do that by, for example ZZ, YY or WW....", and that makes me worried. Options means code branches, which means more test-cases to run through (and, more branches in an interoperability test). It also means, that if an implementation "does XX by way of ZZ", will that, or will that not, interoperate with an implementation that "does XX by way of WW"?

I believe that the author presenting implicitly acknowledged that such options make things complicated - by saying that the first implementation that he intended to produce would be very partial and include only a "core" without options.

Note: I have numerous times (since the last Paris IETF, at least) suggested that in that case
it's miles better to produce a document with that minimal "core", leaving options for a later
process.

7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG.

8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues)

Respectfully,

Thomas

Sent from my iPad
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--------------080505090303080902010809 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------080505090303080902010809-- --------------090409010209040503050401-- From abdussalambaryun@gmail.com Thu Nov 14 10:41:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D66011E814D for ; Thu, 14 Nov 2013 10:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFiXHti0NEqs for ; Thu, 14 Nov 2013 10:41:01 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5637011E8143 for ; Thu, 14 Nov 2013 10:41:00 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id y13so2349646pdi.41 for ; Thu, 14 Nov 2013 10:41:00 -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=6F0EZ8sj9SLsb7mM0PXF0C5UKY3lB1xZFQWnNSqMgUg=; b=KsFGVkdbvtV9NA3guzsl7q74SYT9IaAp+JpEm95QhMtGRotJE85cMV5HLK4Soo3n66 cTSqoY0u3RQ0sarjgYq3Dl/E5mYFxkQxqy11q+5F6+dRPhM+ot4Ay8N1gmzvMi/UgYP7 iLRyBITtZajqBFgzZUB8hG7OGVwGNkJa/x+IJaoufkuhH3LBd3Py3aVaU4+m7YljN4SO tD8Z4oRoYVey1uphU4y1JGzp4uc5DyVzkUGIPtE3M2Hd5/aaSr3JkSGt9YG4DXwIHwG6 sNWhTYcqlm+qpRBUJ4JXbh2+4TZk/XxLte9XlZW4XQk2/okCdpJRWDgu09hf8ddPSSPH skzw== MIME-Version: 1.0 X-Received: by 10.68.190.103 with SMTP id gp7mr2921836pbc.74.1384454460158; Thu, 14 Nov 2013 10:41:00 -0800 (PST) Received: by 10.69.8.5 with HTTP; Thu, 14 Nov 2013 10:41:00 -0800 (PST) In-Reply-To: <7E0AE238-C88B-4119-8EE7-F8329707CB0C@mnemosyne.demon.co.uk> References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com> <49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org> <5283E41E.4080607@computer.org> <7E0AE238-C88B-4119-8EE7-F8329707CB0C@mnemosyne.demon.co.uk> Date: Thu, 14 Nov 2013 18:41:00 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=e89a8ff1c68a4e3d1604eb276c0a Subject: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:41:01 -0000 --e89a8ff1c68a4e3d1604eb276c0a Content-Type: text/plain; charset=ISO-8859-1 There still time available for new editors to target the milestone given, Comments/reviews should be reminded on list or in meetings with new revisions, but not restated after years. Editors and WG both could be blamed for missing comments in past (I was not in the WG). Past comments on dymo are related if reposted for new draft. I remember the current WG decision is that we are starting new reactive draft by adopting the past work of WG and to use tracker tool. Also WG continues discussing docs of DYMO and LOADng to help form together the new WG reactive protocol AODVv2, (I think the first who recommended the change to new name was not the editors but it was Mr.Thomas recommend in one past meeting). AB --e89a8ff1c68a4e3d1604eb276c0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There still time available=A0for new editors to target the milestone g= iven,=A0

Comments/reviews=A0should be reminded on list = or in meetings with new revisions,=A0but not restated after years. Editors = and WG both could be=A0blamed for missing comments in past (I was not in th= e WG).=A0Past comments on dymo=A0are related if reposted for new draft.=A0<= div>
I=A0remember the current=A0WG=A0decision is=A0that we are=A0starti= ng new reactive=A0draft by adopting the past work of WG=A0and to use tracke= r tool. Also WG=A0continues=A0discussing docs of=A0DYMO and=A0LOADng to hel= p form together=A0the new WG=A0reactive protocol AODVv2, (I think the first= who recommended the change to new=A0name was not the editors but it was Mr= .Thomas recommend=A0in one past=A0meeting).

AB
--e89a8ff1c68a4e3d1604eb276c0a-- From internet-drafts@ietf.org Fri Nov 15 18:08:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A24311E815E; Fri, 15 Nov 2013 18:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVLByuLftaHP; Fri, 15 Nov 2013 18:08:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C93CC11E81C4; Fri, 15 Nov 2013 18:08:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131116020801.5441.82079.idtracker@ietfa.amsl.com> Date: Fri, 15 Nov 2013 18:08:01 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 02:08:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Integrity Check Value and Timestamp TLV Definitions for = Mobile Ad Hoc Networks (MANETs) Author(s) : Ulrich Herberg Thomas Heide Clausen Christopher Dearlove Filename : draft-ietf-manet-rfc6622-bis-06.txt Pages : 30 Date : 2013-11-15 Abstract: This document revises, extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-06 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 charliep@computer.org Tue Nov 19 22:31:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37051AE336 for ; Tue, 19 Nov 2013 22:31:29 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HlnxWbjouHu for ; Tue, 19 Nov 2013 22:31:27 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B95941AE33D for ; Tue, 19 Nov 2013 22:31:26 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.70]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Vj1Jn-0000BB-HK; Wed, 20 Nov 2013 01:31:19 -0500 Message-ID: <528C5726.8020402@computer.org> Date: Tue, 19 Nov 2013 22:31:02 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ulrich Herberg References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org><527E383D.8030505@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864b1ff3ef075e9fd6fc084c4566766a1a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 06:31:30 -0000 Hello Ulrich, Comments and follow-up inline. On 11/12/2013 3:41 PM, Ulrich Herberg wrote: > Hi, > > UH> I agree with many points from Thomas' review, and I am sad to see > that there was so little progress of AODVv2 (not even a new revision). There weren't any open issues requiring resolution in a new revision, and we were busy going about the production of interoperable implementations. The current draft expires in January, and before that time I hope the new discussions will bear fruit. > > UH> I went through one of my old reviews to see which of these items > have been addressed (there was another one in 2010). I had responded to the issues that you raised, and I did not get any notification that the proposed resolutions were insufficient. I am happy to restart the discussion. > > UH> November 2012 (my second detailed review of the DYMO/AODVv2 draft): > http://www.ietf.org/mail-archive/web/manet/current/msg14023.html > > ============== > [text from the review was:] > The main comments (as shown in detail below) are: > - The draft is still very difficult to read and is underspecified in > many occasions. > > UH> That is still true. The draft is still very hard to read. The > structure makes it very hard for implementers to follow the draft in > an easy way (e.g., which steps do I have to perform when I receive a > message / generate a message). I much prefer the document structure of > the OLSRv2 draft. > There are several terms specified (e.g., routers client, upstream > router) that are unclear how they affect the MANET architecture, and > why existing terms (e.g., hosts) would not be sufficient. I'll look at the need for "router client", but keep in mind that AODVv2 and AODV do not require that all nodes participate in the AODV protocol. An AODV router can serve nodes, and the terminology in question was intended to distinguish those nodes which receive packets relayed by their first hop router which does run AODVv2. About upstream and downstream -- if these are really confusing, please suggest alternative terminology. Underspecification is something that needs to be fixed ASAP. > > > For example, it is unclear how the blacklisting works, > how metrics are used, how the TLVs are associated with certain > addresses. The calculations for metrics are according to the function Cost(), which is specified in section 5.6, and used in section 6.2. Blacklisting works as always, and I didn't see what was wrong with the text. But you make suggestions below which need to be discussed. > > UH> In the black list section, there are many SHOULDs. It is unclear > why they are not MUSTs, or what happens if an implementation decides > not to do so. Text such as "The IP address of the node" is ambiguous: > why node, not router? Which IP address? A router may have many > interfaces, and each of them may have multiple IP addresses. I will look to see, but in every case I am aware of the IP address is associated with a network interface. I'll look at the use of node versus router, but a RREQ can be for a node that isn't a router. I think that, if an interface has multiple IP addresses, it may not matter which one is selected (in the sense that correct results will be obtained either way). However, I need to verify that. Or, if any problems are noted, we could simply restrict each interface to using only a single IP address for the purpose of running AODVv2. > "The time at which Blacklist.Node will be removed from the > blacklist.". What does "will" mean? MUST? I am O.K. to replace "will" by "MUST". > > UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" > still indicate requirement of address order in an address block. WG > consensus was not to use that. Also, the text seems to indicate that > there is a single address block. That would be against the intended > RFC5444 architecture. Well, there has to be a first address in any such list. The specification only needs a single address block. I'm not aware of the need to allow multiple such blocks except for optional features. If you think that the reactive protocol should define a feature using multiple blocks, that would be an interesting discussion. I have mentioned this in connection with RERR with multiple metrics, but there was no discussion. > > Some of the parameters and TLVs specified in the IANA > section are not used. There are at least four timers for each route > entry, and it is unclear how they may affect each other. It is not > clearly specified how to update forward/reverse routes + the route to > the previous hop I think this is clear in the text. Did you look at the recent revision? Route table timers were confusing in DYMO but I believe they are much more clear now. Please let me know what exactly is difficult. Roughly speaking, a route is either Active, Idle, or Expired (or Broken). These have very intuitive meanings, and if they are not clear in the text please help me to understand why. > - The use of metrics is not well defined; there is an optional > distance field. It is unclear how metrics are created, whether they > are additive, how they are formatted etc. What happens if some routers > now the Distance field, others don't use it. ...? It is not the purpose of the AODVv2 spec to define all the metrics, and I doubt you are suggesting this. They are created according to the definition of the metric, and only hop-count is specified. AODVv2 requires strictly monotonically increasing metrics, as was discussed at length on the mailing list. I am not exactly sure which field is the "Distance" field... > - There are several extensions specified, but too few details to > assure interoperability. Some of them violate end-to-end security. This is not specific enough for me to know how to resolve. However, the entire question of security deserves closer study. > > UH> That still applies (see section 13 of the AODVv2 draft) During > IETF86, we have been promised a summary of these options (see > http://tools.ietf.org/wg/manet/minutes?item=minutes-86-manet.html), > but that has not been delivered. There needs to be a lot more > discussion about how these options affect interoperability and > security (e.g., the argument that intermediate RREPs make end-to-end > security very difficult still applies). I still believe that a slim > core without any optional features would be a better approach. Some of > these extensions severely affect how message integrity can be > provided. That must be discussed in a lot of detail. I also note that > none of these extensions are tested in the (yet-to-be-done) AODVv2 > implementations. I could have easily supplied this list for the recent IETF. I'll certainly have it for the next one. > > - As messages are modified in transit, end-to-end security is not > possible. The security considerations section does not fulfill the > requirements in RFC3552. > > UH> This still applies (in particular with intermediate RREPs) Intermediate RREPs are in a different document, at your request. I would indeed like to re-incorporate it into the main text, but this is less important than resolving the other issues. > > - Extensions, such as for security, cannot be hooked into AODVv2, as > there is no section to allow an external mechanism to provide > additional reasons to reject a message as invalid, such as done in > RFC6130. > > UH> This still applies. I'll take a look, can't comment right now. > > - The IANA section is not correct. There are no requests, no new > registries or code points in existing registries, no allocation policy > is provided. > > UH> This still applies. I think you may be looking at an older version of the document. Allocation policies do need to be supplied -- thanks for pointing this out. > > - There are some layer violations where tasks that are to be done by > the RFC5444 (de)multiplexer are handled in AODVv2. > > UH> This still applies, e.g., in section 5.4, when the RFC5444 parser > and the IP layer are mixed, and where AODVv2 uses RFC2119 language for > IP layer operations such as TTL. > > - There is a mandated order of addresses in RFC5444 messages; I > think this is a bad idea if extensions want to add addresses. This was resolved in newer versions of the specification by adopting a proposal from Henning. > - Originator address and sequence number are contained in address > block and address block TLV, instead of the message header, so there > is additional overhead. > > UH> That still applies. Incidentally, I also don't understand why the > metric type is not encoded as TLV type extension, but rather in a > separate TLV. > > - There is no RREP_ACK or other mechanism to verify bidirectionality > of links. > > UH> This has been added as (very short) extension, although it is > unclear how this works in detail, or how interoperability is assured > with deployments not using that message (e.g. one router expecting a > RREP_ACK, a neighbor not supporting it). > > > - It is unclear to me how the destination sequence number is used in > RREQ and what it serves for. > - Intermediate route replies are hard to secure with signatures > > UH> This still applies I don't understand what is wrong with the RREP_ACK description. It doesn't have to be very long, does it? The destination sequence number is used to guarantee non-looping and robustness against out-of-order delivery. This is exactly the same as in AODV versions and has been studied extensively. Anyway, I will look to see how the explanation can be improved. I would like to put the issues that can be identified into the issue tracker. I did not make any specific comment on your disappointment with the progress of the draft, but it would have been better to have comments on the drafts as they were produced. I remain committed to producing a clear and implementable specification, and if you can be more specific in some of the comments about clarity I will definitely appreciate that. -- Regards, Charlie P. From d.sturek@att.net Wed Nov 20 06:44:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9391AE3A2 for ; Wed, 20 Nov 2013 06:44:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKMEgRKa9mgX for ; Wed, 20 Nov 2013 06:44:23 -0800 (PST) Received: from nm3-vm6.access.bullet.mail.gq1.yahoo.com (nm3-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.151]) by ietfa.amsl.com (Postfix) with ESMTP id 445661AE338 for ; Wed, 20 Nov 2013 06:44:23 -0800 (PST) Received: from [216.39.60.168] by nm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 20 Nov 2013 14:44:17 -0000 Received: from [98.138.226.242] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 20 Nov 2013 14:44:16 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 20 Nov 2013 14:44:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1384958656; bh=o9/6YUxHUfiz6IawAc9CFVic3K2+UlXvHHlWx+uo2AM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=alOo7f4YCpjTV6qeWc5y/mFo0dbN6JmYeiehTz1LGCN1fEl7990UtrDB9u+oO4zHln356BhlPeloZyq2+wetuscbkcreB3wU0f4W7oAoy/8cyXthkV035umspObMJO6z3BgzrbTT4gUpwxYaQTCzB85Q1LHrtBKYPqcTEQ9oduE= X-Yahoo-Newman-Id: 439182.24259.bm@smtp113.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uuq8CUUVM1mBbIDRD9X7NiqCmvJiFb4NHq.cf7FD2qp2Ptr n3nSUaW0eNO9DQSzl2s_1PL7wWMO1x_0bpk.1lyVXShR3jeQdbQX13U_300I N430NwG4qhWwh.aJBET.IBcwrHVr4YQtpKgr1s4ftexmiXjHKdzqfGZUWKXn 9CO7uiv4F.RaNdoINGeXqtCVGwmGVto0yHyv60Xbs3etBeb16MCArDiqZCVI Ml2tpuqLHwKC1WvLPodXaEUOcLFMCObcvaPRR_Z5W4znlZAgTVKBtX.qxpRZ aAWiODQib05u.7vLsntzzt8QQxEQMHJB1pW.e7ZOv4xCLSjebGxSmKMfzEAq mgcwCtAHaZ_TTyrNr0.NlxAsu3HO.D.syFA786ofh4uSdwMk_j7OdGjEVmG9 Xw129x3LD5H.dZAVkXguq8QSuJpYPsPf0D3VZL._zNB83WV_KTKu0R49ZaKx eU7WAKflxBGTLUqC3CP2SIh6bI9p.BYbjva0zggDMXGnbpHqSJfy7VpJaPWi CIcjtnY38goXtxF2qlPDV8xIvs87UAZuFHyaxwkPjoOpz0Bs4gr5b6goS8sT Sm4Zy6Q-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.5] (d.sturek@108.193.229.189 with ) by smtp113.sbc.mail.ne1.yahoo.com with SMTP; 20 Nov 2013 14:44:16 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Wed, 20 Nov 2013 06:44:12 -0800 From: Don Sturek To: "Charles E. Perkins" , Ulrich Herberg Message-ID: Thread-Topic: [manet] Regarding the reactive protocol development. In-Reply-To: <528C5726.8020402@computer.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 14:44:26 -0000 I am just wondering if consensus can ever be reached on the AODVv2 draft given the recent reflector traffic. Maybe the thing to do is to abandon the work and recharter. Don On 11/19/13 10:31 PM, "Charles E. Perkins" wrote: > >Hello Ulrich, > >Comments and follow-up inline. > >On 11/12/2013 3:41 PM, Ulrich Herberg wrote: >> Hi, >> >> UH> I agree with many points from Thomas' review, and I am sad to see >> that there was so little progress of AODVv2 (not even a new revision). > >There weren't any open issues requiring resolution in a new revision, >and we were busy going about the production of interoperable >implementations. The current draft expires in January, and before >that time I hope the new discussions will bear fruit. > >> >> UH> I went through one of my old reviews to see which of these items >> have been addressed (there was another one in 2010). > >I had responded to the issues that you raised, and I did not get >any notification that the proposed resolutions were insufficient. >I am happy to restart the discussion. > >> >> UH> November 2012 (my second detailed review of the DYMO/AODVv2 draft): >> http://www.ietf.org/mail-archive/web/manet/current/msg14023.html >> >> ============== >> [text from the review was:] >> The main comments (as shown in detail below) are: >> - The draft is still very difficult to read and is underspecified in >> many occasions. >> >> UH> That is still true. The draft is still very hard to read. The >> structure makes it very hard for implementers to follow the draft in >> an easy way (e.g., which steps do I have to perform when I receive a >> message / generate a message). I much prefer the document structure of >> the OLSRv2 draft. >> There are several terms specified (e.g., routers client, upstream >> router) that are unclear how they affect the MANET architecture, and >> why existing terms (e.g., hosts) would not be sufficient. > >I'll look at the need for "router client", but keep in mind that AODVv2 >and AODV >do not require that all nodes participate in the AODV protocol. An AODV >router >can serve nodes, and the terminology in question was intended to >distinguish >those nodes which receive packets relayed by their first hop router >which does >run AODVv2. > >About upstream and downstream -- if these are really confusing, please >suggest >alternative terminology. > >Underspecification is something that needs to be fixed ASAP. > >> >> >> For example, it is unclear how the blacklisting works, >> how metrics are used, how the TLVs are associated with certain >> addresses. > >The calculations for metrics are according to the function Cost(), >which is specified in section 5.6, and used in section 6.2. Blacklisting >works as always, and I didn't see what was wrong with the text. >But you make suggestions below which need to be discussed. > >> >> UH> In the black list section, there are many SHOULDs. It is unclear >> why they are not MUSTs, or what happens if an implementation decides >> not to do so. Text such as "The IP address of the node" is ambiguous: >> why node, not router? Which IP address? A router may have many >> interfaces, and each of them may have multiple IP addresses. > >I will look to see, but in every case I am aware of the IP address is >associated with a network interface. I'll look at the use of node versus >router, but a RREQ can be for a node that isn't a router. I think that, >if an interface has multiple IP addresses, it may not matter which one >is selected (in the sense that correct results will be obtained either >way). However, I need to verify that. Or, if any problems are noted, >we could simply restrict each interface to using only a single IP address >for the purpose of running AODVv2. > > >> "The time at which Blacklist.Node will be removed from the >> blacklist.". What does "will" mean? MUST? > >I am O.K. to replace "will" by "MUST". > >> >> UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" >> still indicate requirement of address order in an address block. WG >> consensus was not to use that. Also, the text seems to indicate that >> there is a single address block. That would be against the intended >> RFC5444 architecture. > >Well, there has to be a first address in any such list. The specification >only needs a single address block. I'm not aware of the need to allow >multiple such blocks except for optional features. If you think that the >reactive protocol should define a feature using multiple blocks, that >would be an interesting discussion. I have mentioned this in connection >with RERR with multiple metrics, but there was no discussion. > >> >> Some of the parameters and TLVs specified in the IANA >> section are not used. There are at least four timers for each route >> entry, and it is unclear how they may affect each other. It is not >> clearly specified how to update forward/reverse routes + the route to >> the previous hop > >I think this is clear in the text. Did you look at the recent revision? >Route table timers were confusing in DYMO but I believe they are >much more clear now. Please let me know what exactly is difficult. >Roughly speaking, a route is either Active, Idle, or Expired (or >Broken). These have very intuitive meanings, and if they are not >clear in the text please help me to understand why. > >> - The use of metrics is not well defined; there is an optional >> distance field. It is unclear how metrics are created, whether they >> are additive, how they are formatted etc. What happens if some routers >> now the Distance field, others don't use it. > >...? It is not the purpose of the AODVv2 spec to define all the metrics, >and I doubt you are suggesting this. They are created according to >the definition of the metric, and only hop-count is specified. >AODVv2 requires strictly monotonically increasing metrics, as >was discussed at length on the mailing list. > >I am not exactly sure which field is the "Distance" field... > > >> - There are several extensions specified, but too few details to >> assure interoperability. Some of them violate end-to-end security. > >This is not specific enough for me to know how to resolve. However, >the entire question of security deserves closer study. > >> >> UH> That still applies (see section 13 of the AODVv2 draft) During >> IETF86, we have been promised a summary of these options (see >> http://tools.ietf.org/wg/manet/minutes?item=minutes-86-manet.html), >> but that has not been delivered. There needs to be a lot more >> discussion about how these options affect interoperability and >> security (e.g., the argument that intermediate RREPs make end-to-end >> security very difficult still applies). I still believe that a slim >> core without any optional features would be a better approach. Some of >> these extensions severely affect how message integrity can be >> provided. That must be discussed in a lot of detail. I also note that >> none of these extensions are tested in the (yet-to-be-done) AODVv2 >> implementations. > >I could have easily supplied this list for the recent IETF. I'll >certainly have it >for the next one. > > >> >> - As messages are modified in transit, end-to-end security is not >> possible. The security considerations section does not fulfill the >> requirements in RFC3552. >> >> UH> This still applies (in particular with intermediate RREPs) > >Intermediate RREPs are in a different document, at your request. >I would indeed like to re-incorporate it into the main text, but this >is less important than resolving the other issues. > >> >> - Extensions, such as for security, cannot be hooked into AODVv2, as >> there is no section to allow an external mechanism to provide >> additional reasons to reject a message as invalid, such as done in >> RFC6130. >> >> UH> This still applies. > >I'll take a look, can't comment right now. > >> >> - The IANA section is not correct. There are no requests, no new >> registries or code points in existing registries, no allocation policy >> is provided. >> >> UH> This still applies. > >I think you may be looking at an older version of the document. >Allocation policies do need to be supplied -- thanks for pointing >this out. > >> >> - There are some layer violations where tasks that are to be done by >> the RFC5444 (de)multiplexer are handled in AODVv2. >> >> UH> This still applies, e.g., in section 5.4, when the RFC5444 parser >> and the IP layer are mixed, and where AODVv2 uses RFC2119 language for >> IP layer operations such as TTL. >> >> - There is a mandated order of addresses in RFC5444 messages; I >> think this is a bad idea if extensions want to add addresses. > >This was resolved in newer versions of the specification by adopting >a proposal from Henning. > >> - Originator address and sequence number are contained in address >> block and address block TLV, instead of the message header, so there >> is additional overhead. >> >> UH> That still applies. Incidentally, I also don't understand why the >> metric type is not encoded as TLV type extension, but rather in a >> separate TLV. >> >> - There is no RREP_ACK or other mechanism to verify bidirectionality >> of links. >> >> UH> This has been added as (very short) extension, although it is >> unclear how this works in detail, or how interoperability is assured >> with deployments not using that message (e.g. one router expecting a >> RREP_ACK, a neighbor not supporting it). >> >> >> - It is unclear to me how the destination sequence number is used in >> RREQ and what it serves for. >> - Intermediate route replies are hard to secure with signatures >> >> UH> This still applies > >I don't understand what is wrong with the RREP_ACK description. >It doesn't have to be very long, does it? > >The destination sequence number is used to guarantee non-looping >and robustness against out-of-order delivery. This is exactly the >same as in AODV versions and has been studied extensively. Anyway, >I will look to see how the explanation can be improved. > >I would like to put the issues that can be identified into the >issue tracker. > >I did not make any specific comment on your disappointment with >the progress of the draft, but it would have been better to have comments >on the drafts as they were produced. I remain committed to producing >a clear and implementable specification, and if you can be more specific >in some of the comments about clarity I will definitely appreciate that. > >-- >Regards, >Charlie P. > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Wed Nov 20 07:54:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8681AE2E0 for ; Wed, 20 Nov 2013 07:54:35 -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 5vORRnkzEIT6 for ; Wed, 20 Nov 2013 07:54:32 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD591ADEB7 for ; Wed, 20 Nov 2013 07:54:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7E48736A; Wed, 20 Nov 2013 07:54:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F372D366; Wed, 20 Nov 2013 07:54:23 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D0D9146-686C-4B20-B6C5-6AE3AA9820E4" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Thomas Clausen In-Reply-To: <528C5726.8020402@computer.org> Date: Wed, 20 Nov 2013 16:54:21 +0100 Message-Id: References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org><527E383D.8030505@computer.org> <528C5726.8020402@computer.org> To: Charles Perkins X-Mailer: Apple Mail (2.1822) Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 15:54:35 -0000 --Apple-Mail=_1D0D9146-686C-4B20-B6C5-6AE3AA9820E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> [text from the review was:] >> The main comments (as shown in detail below) are: >> - The draft is still very difficult to read and is underspecified in >> many occasions. >>=20 >> UH> That is still true. The draft is still very hard to read. The = structure makes it very hard for implementers to follow the draft in an = easy way (e.g., which steps do I have to perform when I receive a = message / generate a message). I much prefer the document structure of = the OLSRv2 draft. >> There are several terms specified (e.g., routers client, upstream = router) that are unclear how they affect the MANET architecture, and why = existing terms (e.g., hosts) would not be sufficient. >=20 > I'll look at the need for "router client", but keep in mind that = AODVv2 and AODV > do not require that all nodes participate in the AODV protocol. An = AODV router > can serve nodes, and the terminology in question was intended to = distinguish > those nodes which receive packets relayed by their first hop router = which does > run AODVv2. Hang on...... What would the link model for *that* look like?=20 Keeping in mind that applications and protocols (say, Neighbour = Discovery) running on hosts typically do have specific expectations of a = specific link model, and that those expectations most definitely are = *not* satisfied on the interfaces-between-routers in a MANET in the = general case.=20 This does seem *really* problematic. This architectural point needs to = be throughlyre-thought, in a way similar to how it is done in other = routing protocols. > About upstream and downstream -- if these are really confusing, please = suggest > alternative terminology. >=20 > Underspecification is something that needs to be fixed ASAP. >=20 >>=20 >>=20 >> For example, it is unclear how the blacklisting works, >> how metrics are used, how the TLVs are associated with certain >> addresses. >=20 > The calculations for metrics are according to the function Cost(), > which is specified in section 5.6, and used in section 6.2. = Blacklisting > works as always, and I didn't see what was wrong with the text. > But you make suggestions below which need to be discussed. >=20 >>=20 >> UH> In the black list section, there are many SHOULDs. It is unclear = why they are not MUSTs, or what happens if an implementation decides not = to do so. Text such as "The IP address of the node" is ambiguous: why = node, not router? Which IP address? A router may have many interfaces, = and each of them may have multiple IP addresses. >=20 > I will look to see, but in every case I am aware of the IP address is > associated with a network interface. I'll look at the use of node = versus > router, but a RREQ can be for a node that isn't a router. No. An RREQ is for an addressable entity, typically called a host (or, = "host interface"). That host interface has an address. If that host = interface is present in (aka, reachable by way of a router in) a = network, then a router is configured to (i) respond to an RREQ for that = address, and (ii) provide connectivity to/from that entity. "Router" is the right word, we do not know what "node" is, and so an = RREQ can't be for one. > I think that, > if an interface has multiple IP addresses, it may not matter which one > is selected (in the sense that correct results will be obtained either > way). However, I need to verify that. Or, if any problems are noted, > we could simply restrict each interface to using only a single IP = address > for the purpose of running AODVv2. That seems to be an extremely constraining restriction, in part because = it would mean that you'd not be running IPv6. I'm *very* surprised that = multi-interface/multiple-addresses-per-interface has not been studied = and resolved already: it's an almost trivially common case that routers = have multiple interfaces, and it's equally trivially common that in = IPv6, each interface has multiple addresses. >> "The time at which Blacklist.Node will be removed from the = blacklist.". What does "will" mean? MUST? >=20 > I am O.K. to replace "will" by "MUST". >=20 >>=20 >> UH> Notations such as "AddrBlk[1] - The first address slot in = AddrBlk" still indicate requirement of address order in an address = block. WG consensus was not to use that. Also, the text seems to = indicate that there is a single address block. That would be against the = intended RFC5444 architecture. >=20 > Well, there has to be a first address in any such list. The = specification > only needs a single address block. I'm not aware of the need to allow > multiple such blocks except for optional features. If you think that = the > reactive protocol should define a feature using multiple blocks, that > would be an interesting discussion. I have mentioned this in = connection > with RERR with multiple metrics, but there was no discussion. The above is completely and utterly wrong. When using RFC5444, you are (or rather, your message/packet generator = is) able to organise addresses into address blocks so as to be able to = do maximum "compression". It may be that this is a single address block, = or it may be multiple address blocks. Each address has, then, semantics = associated by way of TLVs. Each message/packet generator may do things = differently, optimise for different things, but the beauty is that the = "semantics associated only by way of a TLV association" ensures that any = parser can parse a message correctly, regardless. A protocol that assumes either positional semantics, or semantics of = simple existence of an address in an address block, or that there is = only a single address block in a message, is not using RFC5444 correctly = (either, it leads to inefficiencies, or it leads to the inability to = develop extensions - or, both - or to the inability to use generic = packet/message generator/parser libraries). I'm very surprised that the proper use of RFC5444 has not been assumed, = especially since this has been pointed out ad infinitum, for /years/ on = end, and is hugely important. Frankly, I am getting more and more worried, the more of these exchanges = that I see on this document.=20 It seems that discussions are circling around the same few topics for = years, without ever seeing any of them addressed by the author(s) by = updating to the document.=20 --Apple-Mail=_1D0D9146-686C-4B20-B6C5-6AE3AA9820E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
<SNIP>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[text from = the review was:]
The main comments (as shown in detail below) = are:
 - The draft is still very difficult to read and is = underspecified in
many occasions.

UH> That is still true. = The draft is still very hard to read. The structure makes it very hard = for implementers to follow the draft in an easy way (e.g., which steps = do I have to perform when I receive a message / generate a message). I = much prefer the document structure of the OLSRv2 draft.
There are = several terms specified (e.g., routers client, upstream router) that are = unclear how they affect the MANET architecture, and why existing terms = (e.g., hosts) would not be sufficient.

I'll look at = the need for "router client", but keep in mind that AODVv2 and = AODV
do not require that all nodes participate in the AODV protocol. =  An AODV router
can serve nodes, and the terminology in question = was intended to distinguish
those nodes which receive packets relayed = by their first hop router which does
run = AODVv2.

Hang = on......

What would the link model for *that* = look like? 

Keeping in mind that = applications and protocols (say, Neighbour Discovery) running on hosts = typically do have specific expectations of a specific link model, and = that those expectations most definitely are *not* satisfied on the = interfaces-between-routers in a MANET in the general = case. 

This does seem *really* = problematic. This architectural point needs to be throughlyre-thought, = in a way similar to how it is done in other routing = protocols.


About upstream and downstream -- = if these are really confusing, please suggest
alternative = terminology.

Underspecification is something that needs to be = fixed ASAP.



For example, it is = unclear how the blacklisting works,
how metrics are used, how the = TLVs are associated with certain
addresses.

The = calculations for metrics are according to the function Cost(),
which = is specified in section 5.6, and used in section 6.2. = Blacklisting
works as always, and I didn't see what was wrong with = the text.
But you make suggestions below which need to be = discussed.


UH> In the black list = section, there are many SHOULDs. It is unclear why they are not MUSTs, = or what happens if an implementation decides not to do so. Text such as = "The IP address of the node" is ambiguous: why node, not router? Which = IP address? A router may have many interfaces, and each of them may have = multiple IP addresses.

I will look to see, but in = every case I am aware of the IP address is
associated with a network = interface.  I'll look at the use of node versus
router, but a = RREQ can be for a node that isn't a router. =

No. An RREQ is for an addressable = entity, typically called a host (or, "host interface"). That host = interface  has an address. If that host interface is present in = (aka, reachable by way of a router in) a network, then a router is = configured to (i) respond to an RREQ for that address, and (ii) provide = connectivity to/from that entity.

"Router" is = the right word, we do not know what "node" is, and so an RREQ can't be = for one.

I = think that,
if an interface has multiple IP addresses, it may not = matter which one
is selected (in the sense that correct results will = be obtained either
way).  However, I need to verify that. =  Or, if any problems are noted,
we could simply restrict each = interface to using only a single IP address
for the purpose of = running AODVv2.

That seems to be an = extremely constraining restriction, in part because it would mean that = you'd not be running IPv6.

I'm *very* surprised = that multi-interface/multiple-addresses-per-interface has not been = studied and resolved already: it's an almost trivially common case that = routers have multiple interfaces, and it's equally trivially common that = in IPv6, each interface has multiple = addresses.


"The time at = which Blacklist.Node will be removed from the blacklist.". What does = "will" mean? MUST?

I am O.K. to replace "will" by = "MUST".


UH> Notations such as = "AddrBlk[1] - The first address slot in AddrBlk" still indicate = requirement of address order in an address block. WG consensus was not = to use that. Also, the text seems to indicate that there is a single = address block. That would be against the intended RFC5444 = architecture.

Well, there has to be a first address = in any such list.  The specification
only needs a single address = block.  I'm not aware of the need to allow
multiple such blocks = except for optional features.  If you think that the
reactive = protocol should define a feature using multiple blocks, that
would be = an interesting discussion.  I have mentioned this in = connection
with RERR with multiple metrics, but there was no = discussion.

The above is completely = and utterly wrong.

When using RFC5444, you are = (or rather, your message/packet generator is) able to organise addresses = into address blocks so as to be able to do maximum "compression". It may = be that this is a single address block, or it may be multiple address = blocks. Each address has, then, semantics associated by way of TLVs. = Each message/packet generator may do things differently, optimise for = different things, but the beauty is that the "semantics associated only = by way of a TLV association" ensures that any parser can parse a message = correctly, regardless.

A protocol that assumes = either positional semantics, or semantics of simple existence of an = address in an address block, or that there is only a single address = block in a message, is not using RFC5444 correctly (either, it leads to = inefficiencies, or it leads to the inability to develop extensions - or, = both - or to the inability to use generic packet/message = generator/parser libraries).

I'm very surprised = that the proper use of RFC5444 has not been assumed, especially since = this has been pointed out ad infinitum, for /years/ on end, and is = hugely important.

Frankly, I am getting more = and more worried, the more of these exchanges that I see on this = document. 
It seems that discussions are circling around = the same few topics for years, without ever seeing any of them addressed = by the author(s) by updating to the = document. 



<= /html>= --Apple-Mail=_1D0D9146-686C-4B20-B6C5-6AE3AA9820E4-- From charliep@computer.org Wed Nov 20 11:17:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584031AE109 for ; Wed, 20 Nov 2013 11:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auHKWZ7FXG-x for ; Wed, 20 Nov 2013 11:17:36 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA8F1ADF98 for ; Wed, 20 Nov 2013 11:17:36 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.254.184]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VjDHE-0000cv-Qn; Wed, 20 Nov 2013 14:17:29 -0500 Message-ID: <528D0AB4.4070608@computer.org> Date: Wed, 20 Nov 2013 11:17:08 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Jiazi Yi , Mobile Ad Hoc Networks mailing list References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org><8D7AF1B0-0BAF-406F-ADD0-039E7E718D31@cisco.com><49947CA7-C84F-42CB-A7C5-C6ECCB711C60@thomasclausen.org><5283E41E.4080607@computer.org> <528502C6.2070507@gmail.com> In-Reply-To: <528502C6.2070507@gmail.com> Content-Type: multipart/alternative; boundary="------------070408080108060800090404" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861d1f54b2bb66aa4469487d7cad47b6e0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 19:17:40 -0000 This is a multi-part message in MIME format. --------------070408080108060800090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, Comments inline below... but right now I'll have to skip over some of the discussion about what happened in very old emails... On 11/14/2013 9:05 AM, Jiazi Yi wrote: > Dear all, > > While Thomas Clausen believed that > >> TC>> 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG. >> >> TC>> 8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues) > Charles Perkins keeps saying: >> CP>> This is a gross misrepresentation of fact. > > Without going into every comment that Thomas Clausen made, we can do a > little "case study" here: >>> : 2) RFC5444 is used wrongly in the document: positional >>> semantics of address, and semantics of an address given by its mere >>> presence in a message, has as consequence that it is nigh impossible >>> to develop extensions that are backwards compatible. It's a comment >>> that the WG well should be aware of, as it was raised in the context >>> of early versions of DLEP (where it was promptly resolved). >>> >>> Note: This issue also was raised in the review cited under point >>> 1.The document must be >>> substantially revised to this effect. >> >> : Similarly, I did address these issues and as far as I know the >> current specification is in conformance with RFC 5444. >> > > This issue, has been discussed for 1~ year in the working group. Most > of the participants (if not all the other), including Ulrich, Justin, > Henning have expressed that the address positions should be independent. Indeed, the order dependence for addresses in the AddrBlocks has been removed by incorporating a suggesting by Henning. > > > In the previous discussions, Ulrich, Henning, and Thomas have stated > why this is important. The feedback from Charlie is "I'm not at > all interested in arguing about it, especially right now!" > http://www.ietf.org/mail-archive/web/manet/current/msg14756.html Well, I went back to look at *that* email, and the interpretation given is at least unfriendly. Moreover, as pointed out above, the requested dependence has been designed out. > > Stan also said that > >> For me, the issue here is that working group consensus seems to >> have solidified around positional independence. If fact, Charlie, you >> seem to be the only one holding the counter position. Based on >> Adrian's email on the way forward, the specification needs to reflect >> the consensus of the WG. As of right now, that means it (the spec) >> needs to change. > http://www.ietf.org/mail-archive/web/manet/current/msg14763.html > > However, if we look back at the latest revision of AODVv2, we still have > http://tools.ietf.org/html/draft-ietf-manet-aodvv2-02#section-3 >> | AddrBlk[1] | The first address slot in AddrBlk | >> | AddrBlk[N] | The Nth address slot in AddrBlk | >> | OrigNdx | The index of OrigNode within the AddrBlk | >> | TargNdx | The index of TargNode within the AddrBlk | >> | AddrTLV[1] | the first item in AddrTLV | >> | AddrTLV[N] | the Nth item in AddrTLV | >> | AddrTLV[OrigNode] | AddrTLV[OrigNdx] | >> | AddrTLV[TargNode] | AddrTLV[TargNdx] > Defined in "Notational Conventions" section, and used in all over the > draft. I'm not sure exactly what the point is for this excerpt. > >> CP>> Similarly, I did address these issues and as far as I know the >> current specification is in conformance with RFC 5444. > ================================================= Indeed, I will stand by that. But that's what I think, and I am certainly open to further discussion. > > This is just one example - I can dig into the mailing list to get > similar discussions on other issues. > What I observed is that, even the WG group consensus is so obvious, it > is extremely hard to have it addressed in the WG document (because the > editor thinks it is addressed). Please do follow up with other issues that remain unresolved. I have noted some new technical issues that were raised by Ulrich, and I intend to somehow put them into the issue tracker soon. If you would like to post specific issues to the issue tracker, that would be quite welcome. > >> Also please keep in mind that these comments were submitted a long >> time before I restarted as the active document editor. > who had been listed as co-author of dymo draft since 2005. > Since, Jiazi, you were in the room during the time in Taipei when this was discussed, I don't think this is a reasonable characterization of the true situation. Regarding the activity of co-authors, I can point to many drafts and RFCs that were published with inactive participants named. Indeed, when Mobile IPv6 was published, the lead author had not been active for years. -- Regards, Charlie P. --------------070408080108060800090404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello folks,

Comments inline below...  but right now I'll have to skip over some
of the discussion about what happened in very old emails...

On 11/14/2013 9:05 AM, Jiazi Yi wrote:
Dear all,

While Thomas Clausen believed that

TC>> 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG.

TC>> 8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues)
Charles Perkins keeps saying:
CP>> This is a gross misrepresentation of fact.

Without going into every comment that Thomas Clausen made, we can do a little "case study" here:
<TC>: 2) RFC5444 is used wrongly in the document: positional semantics of address, and semantics of  an address given by its mere presence in a message, has as consequence that it is nigh impossible to develop extensions that are backwards compatible. It's a comment that the WG well should be aware of, as it was raised in the context of early versions of DLEP (where it was promptly resolved).

    Note: This issue also was raised in the review cited under point 1.The document must be
    substantially revised to this effect.

<CP>: Similarly, I did address these issues and as far as I know the
current specification is in conformance with RFC 5444.
<SNIP>

This issue, has been discussed for 1~ year in the working group. Most of the participants (if not all the other), including Ulrich, Justin, Henning have expressed that the address positions should be independent.

Indeed, the order dependence for addresses in the AddrBlocks has been removed
by incorporating a suggesting by Henning.



In the previous discussions, Ulrich, Henning, and Thomas have stated why this is important. The feedback from Charlie is "I'm not at
all interested in arguing about it, especially right now!"  http://www.ietf.org/mail-archive/web/manet/current/msg14756.html

Well, I went back to look at *that* email, and the interpretation
given is at least unfriendly.  Moreover, as pointed out above, the
requested dependence has been designed out.


Stan also said that

<SR> For me, the issue here is that working group consensus seems to have solidified around positional independence. If fact, Charlie, you seem to be the only one holding the counter position. Based on Adrian's email on the way forward, the specification needs to reflect the consensus of the WG. As of right now, that means it (the spec) needs to change. 
http://www.ietf.org/mail-archive/web/manet/current/msg14763.html

However, if we look back at the latest revision of AODVv2, we still have
http://tools.ietf.org/html/draft-ietf-manet-aodvv2-02#section-3
    |      AddrBlk[1]     |    The first address slot in AddrBlk     |
    |      AddrBlk[N]     |     The Nth address slot in AddrBlk      |
    |       OrigNdx       | The index of OrigNode within the AddrBlk |
    |       TargNdx       | The index of TargNode within the AddrBlk |
 
    |      AddrTLV[1]     |        the first item in AddrTLV         |
    |      AddrTLV[N]     |         the Nth item in AddrTLV          |
    |  AddrTLV[OrigNode]  |             AddrTLV[OrigNdx]             |
    |  AddrTLV[TargNode]  |             AddrTLV[TargNdx]
 
Defined in "Notational Conventions" section, and used in all over the draft.

I'm not sure exactly what the point is for this excerpt.


CP>> Similarly, I did address these issues and as far as I know the
current specification is in conformance with RFC 5444. 
=================================================

Indeed, I will stand by that.  But that's what I think, and I am certainly
open to further discussion.


This is just one example  - I can dig into the mailing list to get similar discussions on other issues.
What I observed is that, even the WG group consensus is so obvious, it is extremely hard to have it addressed in the WG document (because the editor thinks it is addressed).

Please do follow up with other issues that remain unresolved.
I have noted some new technical issues that were raised by Ulrich,
and I intend to somehow put them into the issue tracker soon.
If you would like to post specific issues to the issue tracker, that
would be quite welcome.


Also please keep in mind that these comments were submitted a long 
	  time before I restarted as the active document editor.
who had been listed as co-author of dymo draft since 2005.


Since, Jiazi, you were in the room during the time in Taipei when this was
discussed, I don't think this is a reasonable characterization of the true
situation.

Regarding the activity of co-authors, I can point to many drafts and RFCs
that were published with inactive participants named.  Indeed, when
Mobile IPv6 was published, the lead author had not been active for years.
-- 
Regards,
Charlie P.
--------------070408080108060800090404-- From charliep@computer.org Wed Nov 20 13:05:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC8E1AE1A1 for ; Wed, 20 Nov 2013 13:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 cFIP_GjIygBR for ; Wed, 20 Nov 2013 13:05:01 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4021AE123 for ; Wed, 20 Nov 2013 13:05:01 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.254.184]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VjEwu-0004g5-8Q; Wed, 20 Nov 2013 16:04:36 -0500 Message-ID: <528D23D2.3000400@computer.org> Date: Wed, 20 Nov 2013 13:04:18 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Heide Clausen , Mobile Ad Hoc Networks mailing list , Stan Ratliff , Joe Macker , Joe Macker , Adrian Farrel References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> In-Reply-To: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866d28662c7dc6aa6e0bda7ea751f3e527350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 21:05:03 -0000 Hello folks, I'm trying to identify the issues so that we can go about finding technical resolutions. Follow-up below: On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote: > > 1) The detailed review comments that I gave to the reactive protocol (at the time, known under the name DYMO) during the Maastricht IETF'78 (in 2010) still largely apply to the current incarnation of the MANET reactive protocol. My review comments were posted to the MANET mailing list, and are on record in the archives: > > http://www.ietf.org/mail-archive/web/manet/current/msg11858.html > > Around at the same time, other reviews were posted by others. A quick skim through these indicate that many of those review comments have not been addressed either. > I believe that it would have behoved the authors to look through these reviews when reviving this activity, and to ensure that the comments were reflected in the document - or, deflected through discussion on the list. Alas, given that such reviews (still) have not been throughly addressed by the most recent WG document, I'm not sure that providing a review again saying the same is any good use of my (or WG) time. I have recently responded to some email from Ulrich which clearly pointed out some issues. If your issues overlap with his, then the resolution of the issues Ulrich has raised will also take care of the above. If not, then please let's get the other issues out for discussion also. > > > 2) RFC5444 is used wrongly in the document: positional semantics of address, and semantics of an address given by its mere presence in a message, has as consequence that it is nigh impossible to develop extensions that are backwards compatible. It's a comment that the WG well should be aware of, as it was raised in the context of early versions of DLEP (where it was promptly resolved). > > Note: This issue also was raised in the review cited under point 1.The document must be > substantially revised to this effect. The document has been revised to change the way RFC 5444 is used. I do not currently know what else needs to be done. This claim was also made in other emails, but given that the positional dependence has been designed out, I am not sure what else remains. > > 3) The document is extremely unstructured. When I get a message X, then what procedure must I follow? This information is scattered throughout the 60ish pages, and it renders it extremely complicated to even begin to understand how to implement correctly. I've read the document on the way over to Vancouver, and I've read it again this morning. I still can't properly draw the state machines, and there're processing bits that I *think* are not specified (but maybe reading it a 3rd time is required). The point here is, the IETF writes specifications so as to help implementers make correct implementations. This document makes it a lot of work to try to figure out what's supposed to be implemented. > > Note: This issue also was raised in the review cited under point 1.The document must be > substantially revised to this effect. There are only the three messages: RREQ, RREP, and RERR. I don't think that state machines are the best way to exhibit the simple flow of control for these messages, but an appendix could be added for this purpose. Since the flow of control is substantially the same as for AODV RFC 3561, and people had no trouble with that, I know it's quite easy to do. I am quite open to suggestion about how to make improvements; text is appreciated. Would you like an introductory session that simply puts in the signaling diagrams with no other explanatory material other than cross-references? > > 4) The document employs sloppy terminology and invented (and redundant) non-standard terminology. For example, but non-exhaustively, the terms "Routing client" and "node" - why not the well-defined terms "host" and "router"? > > Note: This issue also was raised in the review cited under point 1.The document must be > substantially revised to this effect. I really don't think that "client" and "node" are sloppy terminology! A node can be either a host or a router, so "host" is not an appropriate replacement. The number of IETF documents using "client" and "node" terminology is pretty good indication that the terminology is acceptable. However, again, I am open to suggestion and especially open to text contributions. > > 5) I am worrying that there are virtually non-existent security considerations in this document. In part, "in this day and age, this is unacceptable", but more pragmatically, having seen the (justified) scrutiny that the SEC-DIR and SEC ADs apply to documents they review, this won't pass muster. > > Note: This issue was only touched upon in the review cited under point 1. > But, I still believe that the document must be substantially revised to this effect. Security must be revisited, and I intend to do this. If it takes a major document revision, so be it, but first it has to be carefully discussed. I will begin this process in some follow-on emails. > > 6) The document is ripe with options, often expressed vaguely "XX should be done, you can do that by, for example ZZ, YY or WW....", and that makes me worried. Options means code branches, which means more test-cases to run through (and, more branches in an interoperability test). It also means, that if an implementation "does XX by way of ZZ", will that, or will that not, interoperate with an implementation that "does XX by way of WW"? Specific examples, please! Usually, interoperability depends on the messages sent or received, not the "way" a message is sent or received. Do you mean the algorithm by which a message is produced? > > I believe that the author presenting implicitly acknowledged that such options make things complicated - by saying that the first implementation that he intended to produce would be very partial and include only a "core" without options. > > Note: I have numerous times (since the last Paris IETF, at least) suggested that in that case > it's miles better to produce a document with that minimal "core", leaving options for a later > process. The document with mandatory behaviors and some optional behaviors is a reformulation of features known for quite many years. The existing layout was produced in response to your previous request to locate the optional features in document sections which were separated from the mandatory features. Many IETF protocols have various optional features, and typically interoperability testing does not test them at the very beginning. Options are included often based on experience of the engineers involved, and that is certainly true for the remaining options which are specified in AODVv2. Testing the options after testing the mandatory features is simply the most sensible approach. This is certainly nothing surprising! > 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG. Indeed, I have incorporated revisions based on comments received, including the separation of document sections, complete overhaul of terminology, reduction of acronyms, designing out positional dependence, simplification of the route table timeout structure, elimination of various configuration parameters, and on and on. I intend to be very responsive to current and future such requests. It will be helpful if you can provide text. I am sure that my good faith is continually on display, and I hope you can identify those places in the document which still need work. The above comments are mostly generic claims about past history, and I can't really locate the parts of the current document to which they are supposed to be relevant (except for occurrences of node and client). -- Regards, Charlie P. From charliep@computer.org Wed Nov 20 13:24:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E1C1AE52B for ; Wed, 20 Nov 2013 13:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U-gpXD9JPkn for ; Wed, 20 Nov 2013 13:24:05 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id D39371AE523 for ; Wed, 20 Nov 2013 13:24:02 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.254.184]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VjFFa-0001jx-2y; Wed, 20 Nov 2013 16:23:54 -0500 Message-ID: <528D2859.5050206@computer.org> Date: Wed, 20 Nov 2013 13:23:37 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Clausen References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org><527E383D.8030505@computer.org> <528C5726.8020402@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050700040201080009080908" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d4ceb92b83cea959ac8043ab06436aa5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 21:24:08 -0000 This is a multi-part message in MIME format. --------------050700040201080009080908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, Follow-up below. On 11/20/2013 7:54 AM, Thomas Clausen wrote: > > >>> ============== >>> [text from the review was:] >>> The main comments (as shown in detail below) are: >>> - The draft is still very difficult to read and is underspecified in >>> many occasions. >>> >>> UH> That is still true. The draft is still very hard to read. The >>> structure makes it very hard for implementers to follow the draft in >>> an easy way (e.g., which steps do I have to perform when I receive a >>> message / generate a message). I much prefer the document structure >>> of the OLSRv2 draft. >>> There are several terms specified (e.g., routers client, upstream >>> router) that are unclear how they affect the MANET architecture, and >>> why existing terms (e.g., hosts) would not be sufficient. >> >> I'll look at the need for "router client", but keep in mind that >> AODVv2 and AODV >> do not require that all nodes participate in the AODV protocol. An >> AODV router >> can serve nodes, and the terminology in question was intended to >> distinguish >> those nodes which receive packets relayed by their first hop router >> which does >> run AODVv2. > > Hang on...... > > What would the link model for *that* look like? > > Keeping in mind that applications and protocols (say, Neighbour > Discovery) running on hosts typically do have specific expectations of > a specific link model, and that those expectations most definitely are > *not* satisfied on the interfaces-between-routers in a MANET in the > general case. > > This does seem *really* problematic. This architectural point needs to > be throughlyre-thought, in a way similar to how it is done in other > routing protocols. I am not at all sure how link model matters here. Plus, Neighbor Discovery is not under discussion here, and I do not see why it is relevant. > > >> About upstream and downstream -- if these are really confusing, >> please suggest >> alternative terminology. >> >> Underspecification is something that needs to be fixed ASAP. >> >>> >>> >>> For example, it is unclear how the blacklisting works, >>> how metrics are used, how the TLVs are associated with certain >>> addresses. >> >> The calculations for metrics are according to the function Cost(), >> which is specified in section 5.6, and used in section 6.2. Blacklisting >> works as always, and I didn't see what was wrong with the text. >> But you make suggestions below which need to be discussed. >> >>> >>> UH> In the black list section, there are many SHOULDs. It is unclear >>> why they are not MUSTs, or what happens if an implementation decides >>> not to do so. Text such as "The IP address of the node" is >>> ambiguous: why node, not router? Which IP address? A router may have >>> many interfaces, and each of them may have multiple IP addresses. >> >> I will look to see, but in every case I am aware of the IP address is >> associated with a network interface. I'll look at the use of node versus >> router, but a RREQ can be for a node that isn't a router. > > No. An RREQ is for an addressable entity, typically called a host (or, > "host interface"). That host interface has an address. If that host > interface is present in (aka, reachable by way of a router in) a > network, then a router is configured to (i) respond to an RREQ for > that address, and (ii) provide connectivity to/from that entity. Since your explanation agrees with my text, I am not sure about the function of the word "No". > > "Router" is the right word, we do not know what "node" is, and so an > RREQ can't be for one. This does not follow. A RREQ can be for an address of a host that is not a router, or for a router, so "node" seems quite suitable for this purpose. However, if a definition for "node" is needed, I will insert one of the standard definitions from other IETF documents. > >> I think that, >> if an interface has multiple IP addresses, it may not matter which one >> is selected (in the sense that correct results will be obtained either >> way). However, I need to verify that. Or, if any problems are noted, >> we could simply restrict each interface to using only a single IP address >> for the purpose of running AODVv2. > > That seems to be an extremely constraining restriction, in part > because it would mean that you'd not be running IPv6. No, it means that AODVv2 would only use one of the IPv6 addresses. But whether or not the restriction would be imposed should be the topic of additional discussion. I don't think it needs to be imposed. > > I'm *very* surprised that > multi-interface/multiple-addresses-per-interface has not been studied > and resolved already: it's an almost trivially common case that > routers have multiple interfaces, and it's equally trivially common > that in IPv6, each interface has multiple addresses. See above. It's fine for any router to have multiple addresses. I only said that I need to check whether any difficulty arises given the current document. In all previous discussions on this point, no difficulties were raised, and it has been discussed at various times in [manet] for the last ten years. > > >>> "The time at which Blacklist.Node will be removed from the >>> blacklist.". What does "will" mean? MUST? >> >> I am O.K. to replace "will" by "MUST". >> >>> >>> UH> Notations such as "AddrBlk[1] - The first address slot in >>> AddrBlk" still indicate requirement of address order in an address >>> block. WG consensus was not to use that. Also, the text seems to >>> indicate that there is a single address block. That would be against >>> the intended RFC5444 architecture. >> >> Well, there has to be a first address in any such list. The >> specification >> only needs a single address block. I'm not aware of the need to allow >> multiple such blocks except for optional features. If you think that the >> reactive protocol should define a feature using multiple blocks, that >> would be an interesting discussion. I have mentioned this in connection >> with RERR with multiple metrics, but there was no discussion. > > The above is completely and utterly wrong. No, it's not. > > When using RFC5444, you are (or rather, your message/packet generator > is) able to organise addresses into address blocks so as to be able to > do maximum "compression". It may be that this is a single address > block, or it may be multiple address blocks. Each address has, then, > semantics associated by way of TLVs. Each message/packet generator may > do things differently, optimise for different things, but the beauty > is that the "semantics associated only by way of a TLV association" > ensures that any parser can parse a message correctly, regardless. Basically, RREQ and RREP don't typically need any address compression, and so we are left with the task of fitting the message requirements into a packetization facility that was meant for something else. > > A protocol that assumes either positional semantics, or semantics of > simple existence of an address in an address block, or that there is > only a single address block in a message, is not using RFC5444 > correctly (either, it leads to inefficiencies, or it leads to the > inability to develop extensions - or, both - or to the inability to > use generic packet/message generator/parser libraries). How would you suggest that we put in RREQ or RREP addresses into the packet? If we're not supposed to put them into an AddrBlk, what else is appropriate? > > I'm very surprised that the proper use of RFC5444 has not been > assumed, especially since this has been pointed out ad infinitum, for > /years/ on end, and is hugely important. The proper use of RFC 5444 is that which conforms to the standard. If there are some processing inefficiencies, that can be discussed. > > Frankly, I am getting more and more worried, the more of these > exchanges that I see on this document. > It seems that discussions are circling around the same few topics for > years, without ever seeing any of them addressed by the author(s) by > updating to the document. Please relax and help to find the proper technical resolutions for the above-mentioned issues. I think my follow-up points have been responsive to your questions, and I hope to get closer to resolution with each round of discussion. -- Regards, Charlie P. --------------050700040201080009080908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello folks,

Follow-up below.

On 11/20/2013 7:54 AM, Thomas Clausen wrote:
<SNIP>

==============
[text from the review was:]
The main comments (as shown in detail below) are:
 - The draft is still very difficult to read and is underspecified in
many occasions.

UH> That is still true. The draft is still very hard to read. The structure makes it very hard for implementers to follow the draft in an easy way (e.g., which steps do I have to perform when I receive a message / generate a message). I much prefer the document structure of the OLSRv2 draft.
There are several terms specified (e.g., routers client, upstream router) that are unclear how they affect the MANET architecture, and why existing terms (e.g., hosts) would not be sufficient.

I'll look at the need for "router client", but keep in mind that AODVv2 and AODV
do not require that all nodes participate in the AODV protocol.  An AODV router
can serve nodes, and the terminology in question was intended to distinguish
those nodes which receive packets relayed by their first hop router which does
run AODVv2.

Hang on......

What would the link model for *that* look like? 

Keeping in mind that applications and protocols (say, Neighbour Discovery) running on hosts typically do have specific expectations of a specific link model, and that those expectations most definitely are *not* satisfied on the interfaces-between-routers in a MANET in the general case. 

This does seem *really* problematic. This architectural point needs to be throughlyre-thought, in a way similar to how it is done in other routing protocols.

I am not at all sure how link model matters here.
Plus, Neighbor Discovery is not under discussion here, and
I do not see why it is relevant.



About upstream and downstream -- if these are really confusing, please suggest
alternative terminology.

Underspecification is something that needs to be fixed ASAP.



For example, it is unclear how the blacklisting works,
how metrics are used, how the TLVs are associated with certain
addresses.

The calculations for metrics are according to the function Cost(),
which is specified in section 5.6, and used in section 6.2. Blacklisting
works as always, and I didn't see what was wrong with the text.
But you make suggestions below which need to be discussed.


UH> In the black list section, there are many SHOULDs. It is unclear why they are not MUSTs, or what happens if an implementation decides not to do so. Text such as "The IP address of the node" is ambiguous: why node, not router? Which IP address? A router may have many interfaces, and each of them may have multiple IP addresses.

I will look to see, but in every case I am aware of the IP address is
associated with a network interface.  I'll look at the use of node versus
router, but a RREQ can be for a node that isn't a router.

No. An RREQ is for an addressable entity, typically called a host (or, "host interface"). That host interface  has an address. If that host interface is present in (aka, reachable by way of a router in) a network, then a router is configured to (i) respond to an RREQ for that address, and (ii) provide connectivity to/from that entity.

Since your explanation agrees with my text, I am not sure about the
function of the word "No".


"Router" is the right word, we do not know what "node" is, and so an RREQ can't be for one.

This does not follow.  A RREQ can be for an address of a host that is not a router,
or for a router, so "node" seems quite suitable for this purpose.

However, if a definition for "node" is needed, I will insert one of the standard
definitions from other IETF documents.


I think that,
if an interface has multiple IP addresses, it may not matter which one
is selected (in the sense that correct results will be obtained either
way).  However, I need to verify that.  Or, if any problems are noted,
we could simply restrict each interface to using only a single IP address
for the purpose of running AODVv2.

That seems to be an extremely constraining restriction, in part because it would mean that you'd not be running IPv6.

No, it means that AODVv2 would only use one of the IPv6 addresses.
But whether or not the restriction would be imposed should be the
topic of additional discussion.  I don't think it needs to be imposed.


I'm *very* surprised that multi-interface/multiple-addresses-per-interface has not been studied and resolved already: it's an almost trivially common case that routers have multiple interfaces, and it's equally trivially common that in IPv6, each interface has multiple addresses.

See above.  It's fine for any router to have multiple addresses.  I only
said that I need to check whether any difficulty arises given the current
document.  In all previous discussions on this point, no difficulties were
raised, and it has been discussed at various times in [manet] for the last
ten years.



"The time at which Blacklist.Node will be removed from the blacklist.". What does "will" mean? MUST?

I am O.K. to replace "will" by "MUST".


UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" still indicate requirement of address order in an address block. WG consensus was not to use that. Also, the text seems to indicate that there is a single address block. That would be against the intended RFC5444 architecture.

Well, there has to be a first address in any such list.  The specification
only needs a single address block.  I'm not aware of the need to allow
multiple such blocks except for optional features.  If you think that the
reactive protocol should define a feature using multiple blocks, that
would be an interesting discussion.  I have mentioned this in connection
with RERR with multiple metrics, but there was no discussion.

The above is completely and utterly wrong.

No, it's not.


When using RFC5444, you are (or rather, your message/packet generator is) able to organise addresses into address blocks so as to be able to do maximum "compression". It may be that this is a single address block, or it may be multiple address blocks. Each address has, then, semantics associated by way of TLVs. Each message/packet generator may do things differently, optimise for different things, but the beauty is that the "semantics associated only by way of a TLV association" ensures that any parser can parse a message correctly, regardless.

Basically, RREQ and RREP don't typically need any address compression,
and so we are left with the task of fitting the message requirements into
a packetization facility that was meant for something else.


A protocol that assumes either positional semantics, or semantics of simple existence of an address in an address block, or that there is only a single address block in a message, is not using RFC5444 correctly (either, it leads to inefficiencies, or it leads to the inability to develop extensions - or, both - or to the inability to use generic packet/message generator/parser libraries).

How would you suggest that we put in RREQ or RREP addresses into
the packet?  If we're not supposed to put them into an AddrBlk, what
else is appropriate?


I'm very surprised that the proper use of RFC5444 has not been assumed, especially since this has been pointed out ad infinitum, for /years/ on end, and is hugely important.

The proper use of RFC 5444 is that which conforms to the standard.  If
there are some processing inefficiencies, that can be discussed.


Frankly, I am getting more and more worried, the more of these exchanges that I see on this document. 
It seems that discussions are circling around the same few topics for years, without ever seeing any of them addressed by the author(s) by updating to the document.

Please relax and help to find the proper technical resolutions for the
above-mentioned issues.  I think my follow-up points have been responsive
to your questions, and I hope to get closer to resolution with each round
of discussion.



-- 
Regards,
Charlie P.
--------------050700040201080009080908-- From ietf@thomasclausen.org Wed Nov 20 14:39:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C511ADF98 for ; Wed, 20 Nov 2013 14:39:40 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbkmgVPnSyCZ for ; Wed, 20 Nov 2013 14:39:36 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 386D11AD845 for ; Wed, 20 Nov 2013 14:39:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F19393409C9; Wed, 20 Nov 2013 14:39:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.23] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E139A3409C8; Wed, 20 Nov 2013 14:39:28 -0800 (PST) References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <527E383D.8030505@computer.org> <528C5726.8020402@computer.org> <528D2859.5050206@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: <528D2859.5050206@computer.org> Content-Type: multipart/alternative; boundary=Apple-Mail-619A46E6-0264-4577-91F8-3126E04FE31F Content-Transfer-Encoding: 7bit Message-Id: <715C347C-39A7-4CD6-9320-385D0991E374@thomasclausen.org> X-Mailer: iPad Mail (11B511) From: Thomas Heide Clausen Date: Wed, 20 Nov 2013 23:39:27 +0100 To: "Charles E. Perkins" Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 22:39:40 -0000 --Apple-Mail-619A46E6-0264-4577-91F8-3126E04FE31F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 20 nov. 2013, at 22:23, "Charles E. Perkins" wr= ote: >=20 >=20 > Hello folks, >=20 > Follow-up below. >=20 >> On 11/20/2013 7:54 AM, Thomas Clausen wrote: >> >>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> [text from the review was:] >>>> The main comments (as shown in detail below) are: >>>> - The draft is still very difficult to read and is underspecified in >>>> many occasions. >>>>=20 >>>> UH> That is still true. The draft is still very hard to read. The struc= ture makes it very hard for implementers to follow the draft in an easy way (= e.g., which steps do I have to perform when I receive a message / generate a= message). I much prefer the document structure of the OLSRv2 draft. >>>> There are several terms specified (e.g., routers client, upstream route= r) that are unclear how they affect the MANET architecture, and why existing= terms (e.g., hosts) would not be sufficient. >>>=20 >>> I'll look at the need for "router client", but keep in mind that AODVv2 a= nd AODV >>> do not require that all nodes participate in the AODV protocol. An AODV= router >>> can serve nodes, and the terminology in question was intended to disting= uish >>> those nodes which receive packets relayed by their first hop router whic= h does >>> run AODVv2. >>=20 >>=20 >> Hang on...... >>=20 >> What would the link model for *that* look like?=20 >>=20 >> Keeping in mind that applications and protocols (say, Neighbour Discovery= ) running on hosts typically do have specific expectations of a specific lin= k model, and that those expectations most definitely are *not* satisfied on t= he interfaces-between-routers in a MANET in the general case.=20 >>=20 >> This does seem *really* problematic. This architectural point needs to be= throughlyre-thought, in a way similar to how it is done in other routing pr= otocols. >=20 > I am not at all sure how link model matters here. > Plus, Neighbor Discovery is not under discussion here, and > I do not see why it is relevant. ND, and other stuff that runs on a host, has expectations to the nature of t= he link. ND is an example - a highly relevant one, I'd say. I'm afraid that i= t's not clear what the authors are saying: if over the same interface a rout= er can see another router AND a host, then the link has to behave as a host (= or rather, protocols and applications on the host) expect. Otherwise, it's g= oing to break stuff. For the end-users. But, I am not even sure if that is what it is the authors are saying since t= he document (and, your email) is very unclear on also this point. It is, how= ever, necessary to be *very* clear on this point.=20 It may be that the authors want to say the right thing, but that the non-sta= ndard use of terminology makes it come across wrongly -- or, the authors are= doing something very differently, but not defining and describing it. Either way, this is symptomatic of the document: it requires a lot of interp= retation and a lot of "guesses" to be made as to what the authors intended. This has been brought up many times, by many different people, and we're *st= ill* waiting for an effort to be made on that front....on a document that da= tes back to 2005.... >>> About upstream and downstream -- if these are really confusing, please s= uggest >>> alternative terminology. >>>=20 >>> Underspecification is something that needs to be fixed ASAP. >>>=20 >>>>=20 >>>>=20 >>>> For example, it is unclear how the blacklisting works, >>>> how metrics are used, how the TLVs are associated with certain >>>> addresses. >>>=20 >>> The calculations for metrics are according to the function Cost(), >>> which is specified in section 5.6, and used in section 6.2. Blacklisting= >>> works as always, and I didn't see what was wrong with the text. >>> But you make suggestions below which need to be discussed. >>>=20 >>>>=20 >>>> UH> In the black list section, there are many SHOULDs. It is unclear wh= y they are not MUSTs, or what happens if an implementation decides not to do= so. Text such as "The IP address of the node" is ambiguous: why node, not r= outer? Which IP address? A router may have many interfaces, and each of them= may have multiple IP addresses. >>>=20 >>> I will look to see, but in every case I am aware of the IP address is >>> associated with a network interface. I'll look at the use of node versu= s >>> router, but a RREQ can be for a node that isn't a router. >>=20 >> No. An RREQ is for an addressable entity, typically called a host (or, "h= ost interface"). That host interface has an address. If that host interface= is present in (aka, reachable by way of a router in) a network, then a rout= er is configured to (i) respond to an RREQ for that address, and (ii) provid= e connectivity to/from that entity. >=20 > Since your explanation agrees with my text, I am not sure about the > function of the word "No". "No" as in "no, there is no good reason for using the term node". >> "Router" is the right word, we do not know what "node" is, and so an RREQ= can't be for one. >=20 > This does not follow. A RREQ can be for an address of a host that is not a= router, > or for a router, so "node" seems quite suitable for this purpose. >=20 No, it doesn't seem suitable at all, it's confusing. > However, if a definition for "node" is needed, I will insert one of the st= andard > definitions from other IETF documents. No. Use host and router, as appropriate. These are well-defined. Node is not= . >>> I think that, >>> if an interface has multiple IP addresses, it may not matter which one >>> is selected (in the sense that correct results will be obtained either >>> way). However, I need to verify that. Or, if any problems are noted, >>> we could simply restrict each interface to using only a single IP addres= s >>> for the purpose of running AODVv2. >>=20 >> That seems to be an extremely constraining restriction, in part because i= t would mean that you'd not be running IPv6. >=20 > No, it means that AODVv2 would only use one of the IPv6 addresses. > But whether or not the restriction would be imposed should be the > topic of additional discussion. I don't think it needs to be imposed. >=20 >>=20 >> I'm *very* surprised that multi-interface/multiple-addresses-per-interfac= e has not been studied and resolved already: it's an almost trivially common= case that routers have multiple interfaces, and it's equally trivially comm= on that in IPv6, each interface has multiple addresses. >=20 > See above. It's fine for any router to have multiple addresses. I only > said that I need to check whether any difficulty arises given the current > document. In all previous discussions on this point, no difficulties were= > raised, and it has been discussed at various times in [manet] for the last= > ten years. So, what is being said here is "the authors do not know how to do this yet".= ..in a document that dates back from 2005?=20 FWIW, doing multiple-address/multile-interfaces correctly isn't trivial, esp= ecially not in MANETs. >>>> "The time at which Blacklist.Node will be removed from the blacklist.".= What does "will" mean? MUST? >>>=20 >>> I am O.K. to replace "will" by "MUST". >>>=20 >>>>=20 >>>> UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" s= till indicate requirement of address order in an address block. WG consensus= was not to use that. Also, the text seems to indicate that there is a singl= e address block. That would be against the intended RFC5444 architecture. >>>=20 >>> Well, there has to be a first address in any such list. The specificati= on >>> only needs a single address block. I'm not aware of the need to allow >>> multiple such blocks except for optional features. If you think that th= e >>> reactive protocol should define a feature using multiple blocks, that >>> would be an interesting discussion. I have mentioned this in connection= >>> with RERR with multiple metrics, but there was no discussion. >>=20 >> The above is completely and utterly wrong. >=20 > No, it's not. Yes it is. >> When using RFC5444, you are (or rather, your message/packet generator is)= able to organise addresses into address blocks so as to be able to do maxim= um "compression". It may be that this is a single address block, or it may b= e multiple address blocks. Each address has, then, semantics associated by w= ay of TLVs. Each message/packet generator may do things differently, optimis= e for different things, but the beauty is that the "semantics associated onl= y by way of a TLV association" ensures that any parser can parse a message c= orrectly, regardless. >=20 > Basically, RREQ and RREP don't typically need any address compression, > and so we are left with the task of fitting the message requirements into > a packetization facility that was meant for something else. That is not at all the case.=20 I do, btw., not see where you get "don't typically need any address compress= ion" from, but it would be interesting to see the actual deployments in whic= h you've made that observation. But that's beyond the point I'm trying to m= ake. >> A protocol that assumes either positional semantics, or semantics of simp= le existence of an address in an address block, or that there is only a sing= le address block in a message, is not using RFC5444 correctly (either, it le= ads to inefficiencies, or it leads to the inability to develop extensions - o= r, both - or to the inability to use generic packet/message generator/parser= libraries). >=20 > How would you suggest that we put in RREQ or RREP addresses into > the packet? If we're not supposed to put them into an AddrBlk, what > else is appropriate? >=20 In *an* address block, yes. But its not OK to make assumptions as to where i= n an address block an address is put, or how many address blocks there are o= r should be, nor that the simple presence of an address in an address block c= arries semantics. >>=20 >> I'm very surprised that the proper use of RFC5444 has not been assumed, e= specially since this has been pointed out ad infinitum, for /years/ on end, a= nd is hugely important. >=20 > The proper use of RFC 5444 is that which conforms to the standard. If > there are some processing inefficiencies, that can be discussed. >=20 You keep stubbornly bringing out "processing inefficiencies that can be disc= ussed". It is *NOT*, about "inefficiencies"...and it has never been so. Kin= dly stop spreading such misinformation. Proper use of RFC5444 is about generic packet/message generation and parsing= logic. It is about writing /one/ parser for *all* 5444-messages. It's about= designing protocols that are extensible, and extensions to protocols that c= an co-exist without conflicting. And this document does - as has been pointed out over and over and over - no= t use RFC5444 properly. >> Frankly, I am getting more and more worried, the more of these exchanges t= hat I see on this document.=20 >> It seems that discussions are circling around the same few topics for yea= rs, without ever seeing any of them addressed by the author(s) by updating t= o the document.=20 >=20 > Please relax and help to find the proper technical resolutions for the > above-mentioned issues. > I think my follow-up points have been responsive > to your questions, and I hope to get closer to resolution with each round > of discussion. Reviews, comments have been provided in the past - and the comments given in= 2010 have *still* not been taken on board (cf. this email).=20 --Apple-Mail-619A46E6-0264-4577-91F8-3126E04FE31F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 20 nov. 2013, at 22:= 23, "Charles E. Perkins" <charli= ep@computer.org> wrote:

=20 =20 =20

Hello folks,

Follow-up below.

On 11/20/2013 7:54 AM, Thomas Clausen wrote:
<SNIP>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
[text from the review was:]
The main comments (as shown in detail below) are:
 - The draft is still very difficult to read and is underspecified in
many occasions.

UH> That is still true. The draft is still very hard to read. The structure makes it very hard for implementers to follow the draft in an easy way (e.g., which steps do I have to perform when I receive a message / generate a message). I much prefer the document structure of the OLSRv2 draft.
There are several terms specified (e.g., routers client, upstream router) that are unclear how they affect the MANET architecture, and why existing terms (e.g., hosts) would not be sufficient.

I'll look at the need for "router client", but keep in mind that AODVv2 and AODV
do not require that all nodes participate in the AODV protocol.  An AODV router
can serve nodes, and the terminology in question was intended to distinguish
those nodes which receive packets relayed by their first hop router which does
run AODVv2.

Hang on......

What would the link model for *that* look like? 

Keeping in mind that applications and protocols (say, Neighbour Discovery) running on hosts typically do have specific expectations of a specific link model, and that those expectations most definitely are *not* satisfied on the interfaces-between-routers in a MANET in the general case. 

This does seem *really* problematic. This architectural point needs to be throughlyre-thought, in a way similar to how it is done in other routing protocols.

I am not at all sure how link model matters here.
Plus, Neighbor Discovery is not under discussion here, and
I do not see why it is relevant.

ND, and other stuff that runs on a host, has expectations to the nature o= f the link. ND is an example - a highly relevant one, I'd say. I'm afraid th= at it's not clear what the authors are saying: if over the same interface a r= outer can see another router AND a host, then the link has to behave as a ho= st (or rather, protocols and applications on the host) expect. Otherwise, it= 's going to break stuff. For the end-users.

But, I a= m not even sure if that is what it is the authors are saying since the docum= ent (and, your email) is very unclear on also this point. It is, however, ne= cessary to be *very* clear on this point. 

It m= ay be that the authors want to say the right thing, but that the non-standar= d use of terminology makes it come across wrongly -- or, the authors are doi= ng something very differently, but not defining and describing it.

Either way, this is symptomatic of the document: it requires= a lot of interpretation and a lot of "guesses" to be made as to what the au= thors intended.

This has been brought up many times= , by many different people, and we're *still* waiting for an effort to be ma= de on that front....on a document that dates back to 2005....

=
=20
About upstream and downstream -- if these are really confusing, please suggest
alternative terminology.

Underspecification is something that needs to be fixed ASAP.
=


For example, it is unclear how the blacklisting works,
how metrics are used, how the TLVs are associated with certain
addresses.

The calculations for metrics are according to the function Cost(),
which is specified in section 5.6, and used in section 6.2. Blacklisting
works as always, and I didn't see what was wrong with the text.
But you make suggestions below which need to be discussed.


UH> In the black list section, there are many SHOULDs. It is unclear why they are not MUSTs, or what happens if an implementation decides not to do so. Text such as "The IP address of the node" is ambiguous: why node, not router? Which IP address? A router may have many interfaces, and each of them may have multiple IP addresses.

I will look to see, but in every case I am aware of the IP address is
associated with a network interface.  I'll look at the use of node versus
router, but a RREQ can be for a node that isn't a router.
=

No. An RREQ is for an addressable entity, typically called a host (or, "host interface"). That host interface  has an address. If that host interface is present in (aka, reachable by way of a router in) a network, then a router is configured to (i) respond to an RREQ for that address, and (ii) provide connectivity to/from that entity.

Since your explanation agrees with my text, I am not sure about the
function of the word "No".

"No" as i= n "no, there is no good reason for using the term node".

"Router" is the right word, we do not know what "node" is, and so an RREQ can't be for one.

This does not follow.  A RREQ can be for an address of a host that is not a router,
or for a router, so "node" seems quite suitable for this purpose.


No, it doesn't seem suitable at al= l, it's confusing.

However, if a definition for "node" is needed, I will insert one of the standard
definitions from other IETF documents.

No. Use host and router, as appropriate. These are well-defined. Node is= not.

I think that,
if an interface has multiple IP addresses, it may not matter which one
is selected (in the sense that correct results will be obtained either
way).  However, I need to verify that.  Or, if any pro= blems are noted,
we could simply restrict each interface to using only a single IP address
for the purpose of running AODVv2.

That seems to be an extremely constraining restriction, in part because it would mean that you'd not be running IPv6.

No, it means that AODVv2 would only use one of the IPv6 addresses.
But whether or not the restriction would be imposed should be the
topic of additional discussion.  I don't think it needs to be imposed.


I'm *very* surprised that multi-interface/multiple-addresses-per-interface has not been studied and resolved already: it's an almost trivially common case that routers have multiple interfaces, and it's equally trivially common that in IPv6, each interface has multiple addresses.

See above.  It's fine for any router to have multiple addresses.&nb= sp; I only
said that I need to check whether any difficulty arises given the current
document.  In all previous discussions on this point, no difficulties were
raised, and it has been discussed at various times in [manet] for the last
ten years.

So, what is being said h= ere is "the authors do not know how to do this yet"...in a document that dat= es back from 2005? 

FWIW, doing multiple-addre= ss/multile-interfaces correctly isn't trivial, especially not in MANETs.

"The time at which Blacklist.Node will be removed from the blacklist.". What does "will" mean? MUST?

I am O.K. to replace "will" by "MUST".


UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" still indicate requirement of address order in an address block. WG consensus was not to use that. Also, the text seems to indicate that there is a single address block. That would be against the intended RFC5444 architecture.

Well, there has to be a first address in any such list.  Th= e specification
only needs a single address block.  I'm not aware of the need to allow
multiple such blocks except for optional features.  If you think that the
reactive protocol should define a feature using multiple blocks, that
would be an interesting discussion.  I have mentioned this in connection
with RERR with multiple metrics, but there was no discussion.

The above is completely and utterly wrong.

No, it's not.

Yes it is.
=
=20
When using RFC5444, you are (or rather, your message/packet generator is) able to organise addresses into address blocks so as to be able to do maximum "compression". It may be that this is a single address block, or it may be multiple address blocks. Each address has, then, semantics associated by way of TLVs. Each message/packet generator may do things differently, optimise for different things, but the beauty is that the "semantics associated only by way of a TLV association" ensures that any parser can parse a message correctly, regardless.

Basically, RREQ and RREP don't typically need any address compression,
and so we are left with the task of fitting the message requirements into
a packetization facility that was meant for something else.

That is not at all the case. 

I do, btw., not see where you get "don't typically need any address= compression" from, but it would be interesting to see the actual deployment= s in which you've made that observation.  But that's beyond the point I= 'm trying to make.

A protocol that assumes either positional semantics, or semantics of simple existence of an address in an address block, or that there is only a single address block in a message, is not using RFC5444 correctly (either, it leads to inefficiencies, or it leads to the inability to develop extensions - or, both - or to the inability to use generic packet/message generator/parser libraries).

How would you suggest that we put in RREQ or RREP addresses into
the packet?  If we're not supposed to put them into an AddrBlk, wha= t
else is appropriate?


In *an* address block, yes. But its not O= K to make assumptions as to where in an address block an address is put, or h= ow many address blocks there are or should be, nor that the simple presence o= f an address in an address block carries semantics.


I'm very surprised that the proper use of RFC5444 has not been assumed, especially since this has been pointed out ad infinitum, for /years/ on end, and is hugely important.

The proper use of RFC 5444 is that which conforms to the standard. = If
there are some processing inefficiencies, that can be discussed.


You keep stubbornly bringing out "= processing inefficiencies that can be discussed".  It is *NOT*, about "= inefficiencies"...and it has never been so. Kindly stop spreading such misin= formation.

Proper use of RFC5444 is about generic p= acket/message generation and parsing logic. It is about writing /one/ parser= for *all* 5444-messages. It's about designing protocols that are extensible= , and extensions to protocols that can co-exist without conflicting.

And this document does - as has been pointed out over and o= ver and over - not use RFC5444 properly.

=20
Frankly, I am getting more and more worried, the more of these exchanges that I see on this document. 
It seems that discussions are circling around the same few topics for years, without ever seeing any of them addressed by the author(s) by updating to the document.

Please relax and help to find the proper technical resolutions for the
above-mentioned issues.
  I think my follow-up points have been responsive
to your questions, and I hope to get closer to resolution with each round
of discussion.

Reviews, comm= ents have been provided in the past - and the comments given in 2010 have *s= till* not been taken on board (cf. this email). 

=20
= --Apple-Mail-619A46E6-0264-4577-91F8-3126E04FE31F-- From charliep@computer.org Wed Nov 20 15:44:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F11AE5B4 for ; Wed, 20 Nov 2013 15:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sidl9KEVxB_X for ; Wed, 20 Nov 2013 15:44:41 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2103D1AE194 for ; Wed, 20 Nov 2013 15:44:40 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.254.184]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VjHRf-00036K-OE; Wed, 20 Nov 2013 18:44:32 -0500 Message-ID: <528D494F.4000807@computer.org> Date: Wed, 20 Nov 2013 15:44:15 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Heide Clausen References: <801AFDFB-1DB1-4642-AE20-8986C3EBE35F@thomasclausen.org> <527E383D.8030505@computer.org> <528C5726.8020402@computer.org> <528D2859.5050206@computer.org> <715C347C-39A7-4CD6-9320-385D0991E374@thomasclausen.org> In-Reply-To: <715C347C-39A7-4CD6-9320-385D0991E374@thomasclausen.org> Content-Type: multipart/alternative; boundary="------------040907090307040304050003" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86311d4aa90397884dfbce6a4ec9d50b48350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Nov 2013 23:44:45 -0000 This is a multi-part message in MIME format. --------------040907090307040304050003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello again folks, More follow-up inline... On 11/20/2013 2:39 PM, Thomas Heide Clausen wrote: > > On 20 nov. 2013, at 22:23, "Charles E. Perkins" > wrote: > >> >> Hello folks, >> >> Follow-up below. >> >> On 11/20/2013 7:54 AM, Thomas Clausen wrote: >>> >>> >>>>> ============== >>>>> [text from the review was:] >>>>> The main comments (as shown in detail below) are: >>>>> - The draft is still very difficult to read and is underspecified in >>>>> many occasions. >>>>> >>>>> UH> That is still true. The draft is still very hard to read. The >>>>> structure makes it very hard for implementers to follow the draft >>>>> in an easy way (e.g., which steps do I have to perform when I >>>>> receive a message / generate a message). I much prefer the >>>>> document structure of the OLSRv2 draft. >>>>> There are several terms specified (e.g., routers client, upstream >>>>> router) that are unclear how they affect the MANET architecture, >>>>> and why existing terms (e.g., hosts) would not be sufficient. >>>> >>>> I'll look at the need for "router client", but keep in mind that >>>> AODVv2 and AODV >>>> do not require that all nodes participate in the AODV protocol. An >>>> AODV router >>>> can serve nodes, and the terminology in question was intended to >>>> distinguish >>>> those nodes which receive packets relayed by their first hop router >>>> which does >>>> run AODVv2. >>> >>> Hang on...... >>> >>> What would the link model for *that* look like? >>> >>> Keeping in mind that applications and protocols (say, Neighbour >>> Discovery) running on hosts typically do have specific expectations >>> of a specific link model, and that those expectations most >>> definitely are *not* satisfied on the interfaces-between-routers in >>> a MANET in the general case. >>> >>> This does seem *really* problematic. This architectural point needs >>> to be throughlyre-thought, in a way similar to how it is done in >>> other routing protocols. >> >> I am not at all sure how link model matters here. >> Plus, Neighbor Discovery is not under discussion here, and >> I do not see why it is relevant. > > ND, and other stuff that runs on a host, has expectations to the > nature of the link. ND is an example - a highly relevant one, I'd say. > I'm afraid that it's not clear what the authors are saying: if over > the same interface a router can see another router AND a host, then > the link has to behave as a host (or rather, protocols and > applications on the host) expect. Otherwise, it's going to break > stuff. For the end-users. This isn't true. A router can see other routers and hosts over the same interface. Links don't behave as hosts (I do not understand this). Nodes on a link behave according to whatever protocols they are running. This does not break anything. > > > Either way, this is symptomatic of the document: it requires a lot of > interpretation and a lot of "guesses" to be made as to what the > authors intended. Is my statement above unclear? Oftentimes, misunderstanding is caused by preconceptions about what one *expects* another to say, while missing what actually *was* said. > > > "No" as in "no, there is no good reason for using the term node". What about the reason that a node can be either a host or a router? > >>> "Router" is the right word, we do not know what "node" is, and so an >>> RREQ can't be for one. >> >> This does not follow. A RREQ can be for an address of a host that is >> not a router, >> or for a router, so "node" seems quite suitable for this purpose. >> > > No, it doesn't seem suitable at all, it's confusing. ?? I do not understand how to make it simpler. > >> However, if a definition for "node" is needed, I will insert one of >> the standard >> definitions from other IETF documents. > > No. Use host and router, as appropriate. These are well-defined. Node > is not. I think the use of node to mean either host or router is well-defined. http://www.ietf.org/rfc/rfc4294.txt for one example. Quoting: > The goal of this document is to define the common functionality > required from both IPv6 hosts and routers. Anyway, what alternative terminology would you suggest to enable discussion of an IP addressable network entity in an ad hoc network that could be either a host or a router? > >>>> I think that, >>>> if an interface has multiple IP addresses, it may not matter which one >>>> is selected (in the sense that correct results will be obtained either >>>> way). However, I need to verify that. Or, if any problems are noted, >>>> we could simply restrict each interface to using only a single IP >>>> address >>>> for the purpose of running AODVv2. >>> >>> That seems to be an extremely constraining restriction, in part >>> because it would mean that you'd not be running IPv6. >> >> No, it means that AODVv2 would only use one of the IPv6 addresses. >> But whether or not the restriction would be imposed should be the >> topic of additional discussion. I don't think it needs to be imposed. >> >>> >>> I'm *very* surprised that >>> multi-interface/multiple-addresses-per-interface has not been >>> studied and resolved already: it's an almost trivially common case >>> that routers have multiple interfaces, and it's equally trivially >>> common that in IPv6, each interface has multiple addresses. >> >> See above. It's fine for any router to have multiple addresses. I only >> said that I need to check whether any difficulty arises given the current >> document. In all previous discussions on this point, no difficulties >> were >> raised, and it has been discussed at various times in [manet] for the >> last >> ten years. > > So, what is being said here is "the authors do not know how to do this > yet"...in a document that dates back from 2005? Please do not twist my words. Plainly, I meant that the issue has been discussed and decided previously, but upon your request I am willing to review the current document to see if there are any problems. > > FWIW, doing multiple-address/multile-interfaces correctly isn't > trivial, especially not in MANETs. I'll keep that in mind. > >>> When using RFC5444, you are (or rather, your message/packet >>> generator is) able to organise addresses into address blocks so as >>> to be able to do maximum "compression". It may be that this is a >>> single address block, or it may be multiple address blocks. Each >>> address has, then, semantics associated by way of TLVs. Each >>> message/packet generator may do things differently, optimise for >>> different things, but the beauty is that the "semantics associated >>> only by way of a TLV association" ensures that any parser can parse >>> a message correctly, regardless. >> >> Basically, RREQ and RREP don't typically need any address compression, >> and so we are left with the task of fitting the message requirements into >> a packetization facility that was meant for something else. > > That is not at all the case. > > I do, btw., not see where you get "don't typically need any address > compression" from, but it would be interesting to see the actual > deployments in which you've made that observation. But that's beyond > the point I'm trying to make. Well, if there are only two addresses, and they're not aggregated into any address prefix, I think the address compression isn't helping. We are discussing ad hoc networks, and there may not be any subnet aggregation whatsoever imposed on the nodes of the network. > >>> A protocol that assumes either positional semantics, or semantics of >>> simple existence of an address in an address block, or that there is >>> only a single address block in a message, is not using RFC5444 >>> correctly (either, it leads to inefficiencies, or it leads to the >>> inability to develop extensions - or, both - or to the inability to >>> use generic packet/message generator/parser libraries). >> >> How would you suggest that we put in RREQ or RREP addresses into >> the packet? If we're not supposed to put them into an AddrBlk, what >> else is appropriate? >> > > In *an* address block, yes. But its not OK to make assumptions as to > where in an address block an address is put, or how many address > blocks there are or should be, nor that the simple presence of an > address in an address block carries semantics. If the protocol only needs one address block, I don't understand the problem here. > >>> >>> I'm very surprised that the proper use of RFC5444 has not been >>> assumed, especially since this has been pointed out ad infinitum, >>> for /years/ on end, and is hugely important. >> >> The proper use of RFC 5444 is that which conforms to the standard. If >> there are some processing inefficiencies, that can be discussed. >> > > You keep stubbornly bringing out "processing inefficiencies that can > be discussed". It is *NOT*, about "inefficiencies"...and it has never > been so. Kindly stop spreading such misinformation. > > Proper use of RFC5444 is about generic packet/message generation and > parsing logic. It is about writing /one/ parser for *all* > 5444-messages. It's about designing protocols that are extensible, and > extensions to protocols that can co-exist without conflicting. So you want to know whether your parser can parse AODVv2 packets? I guess I'll let you know the answer to that as soon as I find out. > >> I think my follow-up points have been responsive >> to your questions, and I hope to get closer to resolution with each round >> of discussion. > > Reviews, comments have been provided in the past - and the comments > given in 2010 have *still* not been taken on board (cf. this email). > To reiterate, copying from another email: > Indeed, I have incorporated revisions based on comments received, > including the separation of document sections, complete overhaul of > terminology, reduction of acronyms, designing out positional dependence, > simplification of the route table timeout structure, elimination of > various > configuration parameters, and on and on. It would be nice to find out how to resolve any remaining points of difference. Text will be appreciated. -- Regards, Charlie P. --------------040907090307040304050003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hello again folks,

More follow-up inline...

On 11/20/2013 2:39 PM, Thomas Heide Clausen wrote:

On 20 nov. 2013, at 22:23, "Charles E. Perkins" <charliep@computer.org> wrote:


Hello folks,

Follow-up below.

On 11/20/2013 7:54 AM, Thomas Clausen wrote:
<SNIP>

==============
[text from the review was:]
The main comments (as shown in detail below) are:
 - The draft is still very difficult to read and is underspecified in
many occasions.

UH> That is still true. The draft is still very hard to read. The structure makes it very hard for implementers to follow the draft in an easy way (e.g., which steps do I have to perform when I receive a message / generate a message). I much prefer the document structure of the OLSRv2 draft.
There are several terms specified (e.g., routers client, upstream router) that are unclear how they affect the MANET architecture, and why existing terms (e.g., hosts) would not be sufficient.

I'll look at the need for "router client", but keep in mind that AODVv2 and AODV
do not require that all nodes participate in the AODV protocol.  An AODV router
can serve nodes, and the terminology in question was intended to distinguish
those nodes which receive packets relayed by their first hop router which does
run AODVv2.

Hang on......

What would the link model for *that* look like? 

Keeping in mind that applications and protocols (say, Neighbour Discovery) running on hosts typically do have specific expectations of a specific link model, and that those expectations most definitely are *not* satisfied on the interfaces-between-routers in a MANET in the general case. 

This does seem *really* problematic. This architectural point needs to be throughlyre-thought, in a way similar to how it is done in other routing protocols.

I am not at all sure how link model matters here.
Plus, Neighbor Discovery is not under discussion here, and
I do not see why it is relevant.

ND, and other stuff that runs on a host, has expectations to the nature of the link. ND is an example - a highly relevant one, I'd say. I'm afraid that it's not clear what the authors are saying: if over the same interface a router can see another router AND a host, then the link has to behave as a host (or rather, protocols and applications on the host) expect. Otherwise, it's going to break stuff. For the end-users.

This isn't true.  A router can see other routers and hosts over the same interface.
Links don't behave as hosts (I do not understand this).  Nodes on a link behave
according to whatever protocols they are running.  This does not break anything.



Either way, this is symptomatic of the document: it requires a lot of interpretation and a lot of "guesses" to be made as to what the authors intended.

Is my statement above unclear?  Oftentimes, misunderstanding is
caused by preconceptions about what one *expects* another to say,
while missing what actually *was* said.



"No" as in "no, there is no good reason for using the term node".

What about the reason that a node can be either a host or a router?


"Router" is the right word, we do not know what "node" is, and so an RREQ can't be for one.

This does not follow.  A RREQ can be for an address of a host that is not a router,
or for a router, so "node" seems quite suitable for this purpose.


No, it doesn't seem suitable at all, it's confusing.

??  I do not understand how to make it simpler.


However, if a definition for "node" is needed, I will insert one of the standard
definitions from other IETF documents.

No. Use host and router, as appropriate. These are well-defined. Node is not.

I think the use of node to mean either host or router is well-defined.
http://www.ietf.org/rfc/rfc4294.txt for one example.

Quoting:
   The goal of this document is to define the common functionality
   required from both IPv6 hosts and routers.


Anyway, what alternative terminology would you suggest to enable
discussion of an IP addressable network entity in an ad hoc network that
could be either a host or a router?


I think that,
if an interface has multiple IP addresses, it may not matter which one
is selected (in the sense that correct results will be obtained either
way).  However, I need to verify that.  Or, if any problems are noted,
we could simply restrict each interface to using only a single IP address
for the purpose of running AODVv2.

That seems to be an extremely constraining restriction, in part because it would mean that you'd not be running IPv6.

No, it means that AODVv2 would only use one of the IPv6 addresses.
But whether or not the restriction would be imposed should be the
topic of additional discussion.  I don't think it needs to be imposed.


I'm *very* surprised that multi-interface/multiple-addresses-per-interface has not been studied and resolved already: it's an almost trivially common case that routers have multiple interfaces, and it's equally trivially common that in IPv6, each interface has multiple addresses.

See above.  It's fine for any router to have multiple addresses.  I only
said that I need to check whether any difficulty arises given the current
document.  In all previous discussions on this point, no difficulties were
raised, and it has been discussed at various times in [manet] for the last
ten years.

So, what is being said here is "the authors do not know how to do this yet"...in a document that dates back from 2005?

Please do not twist my words.  Plainly, I meant that the issue has been
discussed and decided previously, but upon your request I am willing to
review the current document to see if there are any problems.

 

FWIW, doing multiple-address/multile-interfaces correctly isn't trivial, especially not in MANETs.

I'll keep that in mind.


When using RFC5444, you are (or rather, your message/packet generator is) able to organise addresses into address blocks so as to be able to do maximum "compression". It may be that this is a single address block, or it may be multiple address blocks. Each address has, then, semantics associated by way of TLVs. Each message/packet generator may do things differently, optimise for different things, but the beauty is that the "semantics associated only by way of a TLV association" ensures that any parser can parse a message correctly, regardless.

Basically, RREQ and RREP don't typically need any address compression,
and so we are left with the task of fitting the message requirements into
a packetization facility that was meant for something else.

That is not at all the case. 

I do, btw., not see where you get "don't typically need any address compression" from, but it would be interesting to see the actual deployments in which you've made that observation.  But that's beyond the point I'm trying to make.

Well, if there are only two addresses, and they're not aggregated into
any address prefix, I think the address compression isn't helping.
We are discussing ad hoc networks, and there may not be any subnet
aggregation whatsoever imposed on the nodes of the network.


A protocol that assumes either positional semantics, or semantics of simple existence of an address in an address block, or that there is only a single address block in a message, is not using RFC5444 correctly (either, it leads to inefficiencies, or it leads to the inability to develop extensions - or, both - or to the inability to use generic packet/message generator/parser libraries).

How would you suggest that we put in RREQ or RREP addresses into
the packet?  If we're not supposed to put them into an AddrBlk, what
else is appropriate?


In *an* address block, yes. But its not OK to make assumptions as to where in an address block an address is put, or how many address blocks there are or should be, nor that the simple presence of an address in an address block carries semantics.

If the protocol only needs one address block, I don't understand
the problem here.



I'm very surprised that the proper use of RFC5444 has not been assumed, especially since this has been pointed out ad infinitum, for /years/ on end, and is hugely important.

The proper use of RFC 5444 is that which conforms to the standard.  If
there are some processing inefficiencies, that can be discussed.


You keep stubbornly bringing out "processing inefficiencies that can be discussed".  It is *NOT*, about "inefficiencies"...and it has never been so. Kindly stop spreading such misinformation.

Proper use of RFC5444 is about generic packet/message generation and parsing logic. It is about writing /one/ parser for *all* 5444-messages. It's about designing protocols that are extensible, and extensions to protocols that can co-exist without conflicting.

So you want to know whether your parser can parse AODVv2 packets?
I guess I'll let you know the answer to that as soon as I find out.


  I think my follow-up points have been responsive
to your questions, and I hope to get closer to resolution with each round
of discussion.

Reviews, comments have been provided in the past - and the comments given in 2010 have *still* not been taken on board (cf. this email). 


To reiterate, copying from another email:

Indeed, I have incorporated revisions based on comments received,
including the separation of document sections, complete overhaul of
terminology, reduction of acronyms, designing out positional dependence,
simplification of the route table timeout structure, elimination of various
configuration parameters, and on and on.

It would be nice to find out how to resolve any remaining points
of difference.  Text will be appreciated.


-- 
Regards,
Charlie P.
--------------040907090307040304050003-- From abdussalambaryun@gmail.com Wed Nov 20 18:22:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECCB1ADF87 for ; Wed, 20 Nov 2013 18:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHD90PH045s5 for ; Wed, 20 Nov 2013 18:22:27 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 283001ADF85 for ; Wed, 20 Nov 2013 18:22:27 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so4403739pbc.34 for ; Wed, 20 Nov 2013 18:22:20 -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:cc:content-type; bh=fI1j0N6lZXBJzfq3jUYwve/U/Alzcq7PInQ1qTD/SzM=; b=P+l/0i2TDLXiDm+aVXfrODBk1rHf4JS36PsnHUlyxNEyr8Xo1sggx3DsV7bl/bRHxF Nj17aP5gCtzt+hUHLEztFcYSTYUK+jX2y/K8rzy9n8y65y5EbFsIcWLIcKkDX3tU1bTo JgepOVk/5aEHEZTS24330hmw6iTLAXBEvaHycSSuC2rTDNPBYl8woZ8YkbpFOZS7M/lA sXaEnG2PdD6GZNph2BfybPNd71fg+7LjGoPAI+MMpu173EdSuvazmFnP+m8LooW5VnmX +Vem5wtI/fEXR3fmspNFjpwXz2KouuZnPniqVOBGxhxkxOQYagh4Bc/TVFMq7AM0/iSU JYJA== MIME-Version: 1.0 X-Received: by 10.68.113.195 with SMTP id ja3mr68242pbb.176.1385000540624; Wed, 20 Nov 2013 18:22:20 -0800 (PST) Received: by 10.68.59.1 with HTTP; Wed, 20 Nov 2013 18:22:20 -0800 (PST) Date: Thu, 21 Nov 2013 03:22:20 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] Comment THC#3 AODVv2 I-D structure and implementation (was Re: Regarding the reactive protocol development.) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 21 Nov 2013 02:22:28 -0000 Hi Charlie, Just a general comment, I was thinking we are in stage of editing text of the I-D for better readings and not in stage of changing structure for better reading. If we discuss new ideas (as changing draft main ideas) in one thread it will be difficult to read/follow productive discussion and may make the I-D progress slow. I want to break the previous discussion in parts because it does not give new edit text related to draft, but provides many new ideas that need separating them into discussions or tracker tickets for best progress. I support that the structure of AODVv2 draft should be similar to AODVv1 RFC3561 structure. I don't think the draft should specify/restrict how to implement as in state machines, but specify what are the AODVv2 procedures, IMHO, usually we are implementing router procedures not router states. So restructuring I-D for router states may make it restricted and not flexible/interoperable. IMO, the optional features should not be separated from each procedure, because if we separate it for simpler reading it will make implementation difficult. So if some people say the I-D is difficult to read, then I say because it is easier to implement, that is a trade off that we need to consider, so restructure to make it easy to read may make it difficult to implement. comments below, AB On 11/20/13, Charles E. Perkins wrote: > > Hello folks, > > I'm trying to identify the issues so that we can go about finding > technical resolutions. Follow-up below: > > On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote: .. >> 3) The document is extremely unstructured. When I get a message X, then >> what procedure must I follow? This information is scattered throughout the >> 60ish pages, and it renders it extremely complicated to even begin to >> understand how to implement correctly. I've read the document on the way >> over to Vancouver, and I've read it again this morning. I still can't >> properly draw the state machines, and there're processing bits that I >> *think* are not specified (but maybe reading it a 3rd time is required). >> The point here is, the IETF writes specifications so as to help >> implementers make correct implementations. This document makes it a lot of >> work to try to figure out what's supposed to be implemented. >> >> Note: This issue also was raised in the review cited under point 1.The >> document must be >> substantially revised to this effect. > > There are only the three messages: RREQ, RREP, and RERR. I don't think > that state > machines are the best way to exhibit the simple flow of control for > these messages, > but an appendix could be added for this purpose. I don't think it is necessary it may add confusion, especially for security considerations. > > Since the flow of control is substantially the same as for AODV RFC > 3561, and people > had no trouble with that, I know it's quite easy to do. I am quite open > to suggestion > about how to make improvements; text is appreciated. I had no problem implementing RFC3561 > > Would you like an introductory session that simply puts in the signaling > diagrams with no other explanatory material other than cross-references? I think this session diagram can be done in the appendix which clarifies for readers more than to implementers. From abdussalambaryun@gmail.com Wed Nov 20 18:30:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A01ADFE6 for ; Wed, 20 Nov 2013 18:30:40 -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 eANkQhCKnwNE for ; Wed, 20 Nov 2013 18:30:39 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id E5B791ADFDF for ; Wed, 20 Nov 2013 18:30:38 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id ma3so10739459pbc.26 for ; Wed, 20 Nov 2013 18:30:32 -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=3v6jRUqcChy7Iqn8eawgJxM5veRmrrnZTs/HsDwBOiM=; b=FhJN1a7PxIG9l6jbjI01PC5ssP7ZgJlwzVHxwlnkEjxnKpwh8K8jlJFqvsgHJgOmQI YIrn4hMDwX2QMKXW0SbK0GtKiFdYmlfWS9RjYotOQ6E+C3HS8uVJkty88C2L9IJKpgtd rd45jjofQzHrj45kIbejgbyIHW9aqFxoovtm+EotEEESbFlqJV/bNWQtw3ExKNNOYdd7 AUqSSnNUR46t6b1fV0HPBiat/ebXT3NH2LZftpY7jNXDTTLVbaxHNSG5CjC5iTUzyGsx Ztxxo1vfomoM+HSSNZH9WoTQQFhOg4G/2asqxqOqKxQmXgL6rs31Am0RfAeQooC9ycKk YCQw== MIME-Version: 1.0 X-Received: by 10.68.240.2 with SMTP id vw2mr3906010pbc.80.1385001032515; Wed, 20 Nov 2013 18:30:32 -0800 (PST) Received: by 10.68.59.1 with HTTP; Wed, 20 Nov 2013 18:30:32 -0800 (PST) In-Reply-To: References: <528C5726.8020402@computer.org> Date: Thu, 21 Nov 2013 03:30:32 +0100 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: text/plain; charset=ISO-8859-1 Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 21 Nov 2013 02:30:40 -0000 I think the thing to do is direct thoes who discuss new ideas to work in a DT with editors for AODVv2, and report the results within 45 days, similar to the DT for DLEP, this way we can get progress for the charter item/work. AB On 11/20/13, Don Sturek wrote: > I am just wondering if consensus can ever be reached on the AODVv2 draft > given the recent reflector traffic. > > Maybe the thing to do is to abandon the work and recharter. > > Don > From ietf@thomasclausen.org Thu Nov 21 04:18:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6BB1AE126 for ; Thu, 21 Nov 2013 04:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZVst2LdIEll for ; Thu, 21 Nov 2013 04:18:25 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id C32B01AE112 for ; Thu, 21 Nov 2013 04:18:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6E0F3360B6C; Thu, 21 Nov 2013 04:18:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9FBD9360B6A; Thu, 21 Nov 2013 04:18:17 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Thomas Clausen In-Reply-To: Date: Thu, 21 Nov 2013 13:18:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1822) Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Comment THC#3 AODVv2 I-D structure and implementation (was Re: Regarding the reactive protocol development.) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 21 Nov 2013 12:18:27 -0000 On 21 Nov 2013, at 03:22, Abdussalam Baryun = wrote: > Hi Charlie, >=20 > Just a general comment, I was thinking we are in stage of editing text > of the I-D for better readings and not in stage of changing structure > for better reading. If we discuss new ideas (as changing draft main > ideas) in one thread it will be difficult to read/follow productive > discussion and may make the I-D progress slow. I want to break the > previous discussion in parts because it does not give new edit text > related to draft, but provides many new ideas that need separating > them into discussions or tracker tickets for best progress. >=20 > I support that the structure of AODVv2 draft should be similar to > AODVv1 RFC3561 structure. I don't think the draft should > specify/restrict how to implement as in state machines, but specify > what are the AODVv2 procedures, State machines do not "restrict how to implement", but they are an = unambiguous way to *specify* protocol operations. Thomas > IMHO, usually we are implementing > router procedures not router states. So restructuring I-D for router > states may make it restricted and not flexible/interoperable. >=20 > IMO, the optional features should not be separated from each > procedure, because if we separate it for simpler reading it will make > implementation difficult. So if some people say the I-D is difficult > to read, then I say because it is easier to implement, that is a trade > off that we need to consider, so restructure to make it easy to read > may make it difficult to implement. >=20 > comments below, >=20 > AB >=20 > On 11/20/13, Charles E. Perkins wrote: >>=20 >> Hello folks, >>=20 >> I'm trying to identify the issues so that we can go about finding >> technical resolutions. Follow-up below: >>=20 >> On 11/8/2013 11:44 AM, Thomas Heide Clausen wrote: > .. >>> 3) The document is extremely unstructured. When I get a message X, = then >>> what procedure must I follow? This information is scattered = throughout the >>> 60ish pages, and it renders it extremely complicated to even begin = to >>> understand how to implement correctly. I've read the document on the = way >>> over to Vancouver, and I've read it again this morning. I still = can't >>> properly draw the state machines, and there're processing bits that = I >>> *think* are not specified (but maybe reading it a 3rd time is = required). >>> The point here is, the IETF writes specifications so as to help >>> implementers make correct implementations. This document makes it a = lot of >>> work to try to figure out what's supposed to be implemented. >>>=20 >>> Note: This issue also was raised in the review cited under point = 1.The >>> document must be >>> substantially revised to this effect. >>=20 >> There are only the three messages: RREQ, RREP, and RERR. I don't = think >> that state >> machines are the best way to exhibit the simple flow of control for >> these messages, >> but an appendix could be added for this purpose. >=20 > I don't think it is necessary it may add confusion, especially for > security considerations. >=20 >>=20 >> Since the flow of control is substantially the same as for AODV RFC >> 3561, and people >> had no trouble with that, I know it's quite easy to do. I am quite = open >> to suggestion >> about how to make improvements; text is appreciated. >=20 > I had no problem implementing RFC3561 >=20 >>=20 >> Would you like an introductory session that simply puts in the = signaling >> diagrams with no other explanatory material other than = cross-references? >=20 > I think this session diagram can be done in the appendix which > clarifies for readers more than to implementers.