From nobody Tue Jul 1 08:58:19 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60E1B282A; Tue, 1 Jul 2014 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AcEL9AzI4vo; Tue, 1 Jul 2014 08:58:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B83721B283A; Tue, 1 Jul 2014 08:58:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 08:58:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/JdxBX2rqMBsxUoi3gfnAuJ40zFY Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 15:58:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-01.txt Pages : 9 Date : 2014-07-01 Abstract: This draft defines a way to configure MPL parameter set via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 13:23:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228181B27E3 for ; Wed, 2 Jul 2014 13:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.029 X-Spam-Level: * X-Spam-Status: No, score=1.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_MIME_NO_TEXT=0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO_eCy_rCr_f for ; Wed, 2 Jul 2014 13:23:04 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF01E1A0240 for ; Wed, 2 Jul 2014 13:23:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 087552002C for ; Wed, 2 Jul 2014 16:23:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3D04E63B0F; Wed, 2 Jul 2014 16:23:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2BB7263B09 for ; Wed, 2 Jul 2014 16:23:01 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xCoMAaVpQLUJKVFd-jIXZzYXfWw Subject: [Roll] question about DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 20:23:05 -0000 --=-=-= Given: - a storing implementation - DAO-ACKs requested - three nodes: A <- B <- C. A is the root. C sends a DAO with the K bit set to selected parent B. B will need to send a DAO to A indicating that it knows about C. Question 1) should B wait until it receives a DAOACK from A before sending a DAOACK back to C? (before you answer, consider the the tree could be very deep, and that this implies that the intermediate nodes have to keep potentially many outgoing DAOACKs in a queue) Or is it enough that B says, "okay, I got you", and then takes responsibility for sending reachability information on its own? The problem I have with not waiting is that if C thinks it is on the network when it gets the DAOACK, it can start sending traffic upwards, but downward packets would get lost for awhile. Further, it is going to start sending DIOs, and start attracting traffic from other nodes when really, it isn't ready to do so. 2) if B recieves a DAO with the K bit set from, does this imply that it ought to set the K bit to its parent? If the answer is no, and you answer the question (1) that B ought to wait until it has heard from A before answering, but B has a policy of not setting the K bit, should B then answer immediately? 3) in the non-storing case, if a parent (B) of C, in fact had multiple interfaces, node C might not see the interface that is closer to A, and can only, in the Transit option, indicate the interface that it does see. This implies that root A, may have to do two lookups to figure out where Bdown is, as it likely only has route to Bup. 4) what is the use case for the RPL Target Descriptor? ====== The DAO-ACK mechanism is pretty important to assure bi-directional reachability, and the security-threads document makes reference to it. I had not clued in that the K bit was optional before. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7RqJICLcPvd0N1lAQJmyQf/Wnd2gtevyuDkEFbtYtm9E5lMh+zdp6xp C/wT1PSspFOSeJXlEHmRwfKnDTB2bLNgkju0RRn1PD6yRXQIDcTZgSGU/brZqhdj FLwrMKYItBJWTvIccg2UJJVCRe/BiVxOF3dZ32DUUEnnaYeCnavnlIen753dgwa+ 9CigrCVtAzx+zQofIZY28uuyz202LgJ5HX/9/GRM80GzxNWD2ABJes1tiC5p2fG1 yy4DDeQck8A7WSpERoRpxI+TZYZTYWMhtOX9JczFgpZUH1yAi0ZVTwewxh3uQ9Ti GYsXljtJ6JWcuslVEGWck/lX4/Imicbr/BKobr0waeTEdS83WRgTuQ== =Zjel -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 4 03:15:10 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8901B2CC6 for ; Fri, 4 Jul 2014 03:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEdaUd74_p-H for ; Fri, 4 Jul 2014 03:15:07 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35501B2CDA for ; Fri, 4 Jul 2014 03:14:58 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz11so1462981veb.17 for ; Fri, 04 Jul 2014 03:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=aLi8KmNjfG5UKPvP8Rspp6GzOj3O0YoL8ZC7Tj9C1Kc=; b=oKuMrM2TkTshxgGADk/QKlJlmwj304BoJ1s2JTYzSJkJNzybqLxyXkwJBvP+ChzxuM oOPptvVV2F2v76ldekm3pPNR0mNIeYbDTt+I/xhxJdhDAlQ78JvxLyavt/TASYu5zZ7T 0d4hiNw5zwOu7mPsglu4IdzUPxAsRUDUu5M9W7yaFdk95iOYIf24x/GhbUAe+TSDUbQR rB9/tS5/yTKF/xiscGR9pnDso+LLgIDXPsIAyHWd9uANZyecgnaKFyLlUm17zHxaeojp 8mxNg5FRZg/mJmskXHbcnZ/rpbM206zrqjPvDwZxb5LHF36FPYN/75po6caZ5I6Npmc3 HE3w== MIME-Version: 1.0 X-Received: by 10.52.27.133 with SMTP id t5mr7650111vdg.9.1404468897765; Fri, 04 Jul 2014 03:14:57 -0700 (PDT) Received: by 10.220.79.19 with HTTP; Fri, 4 Jul 2014 03:14:57 -0700 (PDT) Date: Fri, 4 Jul 2014 13:14:57 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=20cf307d06e8bfe03704fd5b6518 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/PxWfljirukZ_gpJ7pQ0X73n8dC4 Cc: Michael Richardson Subject: [Roll] Please send the updated slides for IETF 90 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:15:08 -0000 --20cf307d06e8bfe03704fd5b6518 Content-Type: text/plain; charset=UTF-8 Hi, Thank you to the authors that sent us slides for the IETF 90, if you have updates, please send us the updates before 07/13/2014. Thanks and Regards, Michael and Ines. --20cf307d06e8bfe03704fd5b6518 Content-Type: text/html; charset=UTF-8
Hi,

Thank you to the authors that sent us slides for the IETF 90, if you have updates, please send us the updates before 07/13/2014.

Thanks and Regards,

Michael and Ines.
--20cf307d06e8bfe03704fd5b6518-- From nobody Mon Jul 7 05:30:26 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3AE1B283E; Mon, 7 Jul 2014 05:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDhYrqNQM1R0; Mon, 7 Jul 2014 05:30:21 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E1A1B282C; Mon, 7 Jul 2014 05:30:21 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s67CUJpA016215; Mon, 7 Jul 2014 21:30:19 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s67CUJm0023508; Mon, 7 Jul 2014 21:30:19 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA23507; Mon, 7 Jul 2014 21:30:19 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s67CUIVe006800; Mon, 7 Jul 2014 21:30:18 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s67CUI57027140; Mon, 7 Jul 2014 21:30:18 +0900 (JST) Received: from [133.196.16.134] (ncg-dhcp134.isl.rdc.toshiba.co.jp [133.196.16.134]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id B36EE97D4B; Mon, 7 Jul 2014 21:30:18 +0900 (JST) Message-ID: <53BA92D9.3000606@toshiba.co.jp> Date: Mon, 07 Jul 2014 21:30:17 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , dhcwg@ietf.org References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> In-Reply-To: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/lLc6exPkhxOXKldC1bFs_GLS9B4 Subject: [Roll] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:30:24 -0000 Hi, I've updated the proposal to control MPL parameter over DHCPv6 option. I believe this feature is required to use MPL over mesh networks in the wild, e.g. long-standing smart meter network etc. This proposal is a short one and I appreciate your review. Thanks! Yusuke (2014-07-02 00:58), internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > Title : MPL Parameter Configuration Option for DHCPv6 > Authors : Yusuke Doi > Matthew Gillmore > Filename : draft-ietf-roll-mpl-parameter-configuration-01.txt > Pages : 9 > Date : 2014-07-01 > > Abstract: > This draft defines a way to configure MPL parameter set via DHCPv6 > option. MPL has a set of parameters to control its behavior, and the > parameter set is often configured as a network-wide parameter because > the parameter set should be identical for each MPL forwarder in an > MPL domain. Using the MPL Parameter Configuration Option defined in > this document, a network can be configured with a single set of MPL > parameter easily. From nobody Mon Jul 7 09:33:22 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6021A0367 for ; Mon, 7 Jul 2014 09:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 uhew2urSmG1U for ; Mon, 7 Jul 2014 09:32:27 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id EAFC71A0358 for ; Mon, 7 Jul 2014 09:32:26 -0700 (PDT) Received: from mail-ve0-f182.google.com ([209.85.128.182]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKU7rLmhaq84xC5iegTiTlBo5mv8h9CXrH@postini.com; Mon, 07 Jul 2014 09:32:27 PDT Received: by mail-ve0-f182.google.com with SMTP id oy12so4438505veb.27 for ; Mon, 07 Jul 2014 09:32:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uIE0TQjrG355JSj7CHdsl3SclKo/KBJ27ZttyJ0WMnc=; b=ViN3ksRfLDXGc38mXgRI4tXLO37UN/oran7Ta/QPdhH1GYx3RmOGypcTD1tLJ8bVnd H0weEHrNuocizp6I9bbkGFCtA5gq4MK+D6jMGN9pHwBPQeKx70YNZolJAAj0ptcetuj5 LiHP+3pZ+Q29i3FCG+WoJnzI0GEryibn1JbQAo7ZXwUjh8BgCgArZ3u27T9aX0q3rilp 8/ylU7nlq/9SM5hABtv8WgdqGEOCuAgwkS6zG2Tb2T8oKzkXHyK5hY1or6yeh0/+NG/D 54gxxBycsCgl3pqZ6PNncTHD/TzwdgHhsa6hsHW++PRgKPBSX2x6++fJ5mQgfr3fVkAa hCiA== X-Gm-Message-State: ALoCoQmvg6FKPuTTS4INM1MNilWaL6KbmdYOawvUNkYQ4vpmY5xUO4dMRI8q6/oaxQIiBLK0v1KGSLjztynIlCkgpM9WjQTyUNJG099qHZMV2vVOOkE/W4UdaLrbDmo7Je4E6qzTjUPT X-Received: by 10.58.210.168 with SMTP id mv8mr28632823vec.12.1404750745834; Mon, 07 Jul 2014 09:32:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.210.168 with SMTP id mv8mr28632813vec.12.1404750745730; Mon, 07 Jul 2014 09:32:25 -0700 (PDT) Received: by 10.220.147.79 with HTTP; Mon, 7 Jul 2014 09:32:25 -0700 (PDT) In-Reply-To: <53BA92D9.3000606@toshiba.co.jp> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> Date: Mon, 7 Jul 2014 09:32:25 -0700 Message-ID: From: Andre Kostur To: Yusuke DOI Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/AhYtfPGfQG-pMeoxEo6GPYYQ3_w X-Mailman-Approved-At: Mon, 07 Jul 2014 09:33:20 -0700 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:32:29 -0000 A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for Creating New DHCPv6 Options): - An encoded option is frowned upon. Split all of those into separate options, and the "Reserved" parts simply disappear. A "sub-optioned" option is also frowned upon (section 9, RFC 7227). - Why add the additional complexity of the floating point? Why not use a 32-bit unsigned integer representing milliseconds which gets you a little over 40 days? Not the 18 weeks that you currently can represent, but is there a practical use for timers over a month long in MPL? - If you do go with separate options, consider what it would mean if certain options don't exist. ietf-roll-trickle-mcast appears to define defaults, perhaps reference that draft to say that if an option is missing, the client is to use the default defined in that draft? - Speaking of RFC 7227... I-D.ietf-dhc-option-guidelines got published in May -- Andre Kostur From nobody Mon Jul 7 10:19:57 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373F81A014C; Mon, 7 Jul 2014 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuI2pZwEpIcT; Mon, 7 Jul 2014 10:19:12 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB611A02EF; Mon, 7 Jul 2014 10:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2168; q=dns/txt; s=iport; t=1404753552; x=1405963152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9B0EsN0ekVZokkeaJiz2S9FHwNZb8jvNoX1FT+zWCRo=; b=YTSnOUEy6b8wXu8hY3ivom4WHGOCFXXI+DdGM7RrqIk6IWNeBsHISwzd Gs3Z4ZjfYIRqNC3o5WfsgVskNuAV86Q6/PhGn27SaNVJBRjWm3KOo+J4W dY1zlcwiWynyQpRIVJtSdswBvN6SNzUbQ2BKtYYAAlhwWEyrEyfYwlrT6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFANnVulOtJV2d/2dsb2JhbABagw5SWr52h0UBgRkWdYQDAQEBBAEBATc0CwwEAgEIDgMEAQELFAUEBycLFAkIAgQBDQUIiDoNyWwTBI5UHTEHBoMngRYFrwKCAYFCgjA X-IronPort-AV: E=Sophos;i="5.01,619,1400025600"; d="scan'208";a="58876672" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 07 Jul 2014 17:19:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s67HJBYM031148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 17:19:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 12:19:11 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , Yusuke DOI Thread-Topic: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) Thread-Index: AQHPmgEd2TBAYfQHIEyalFuCcQCzlpuU2QvA Date: Mon, 7 Jul 2014 17:19:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/D38Rp_wis4XzYTPZoEqbbvFr6yM X-Mailman-Approved-At: Mon, 07 Jul 2014 10:19:47 -0700 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:19:14 -0000 Hi: Not sure I'd suggest adding 10 (or 11) options for this? But I certainly would suggest, as Andre did, much simpler values - flags an= d "compressed" data just make for much more complex and error prone process= ing on both client and server. A structure which would have all these value= s but in a much more standard set of data formats would be better. Perhaps there is a middle grown to have groups of values (i.e., have 3-4 op= tions)? I'm really not that familiar with MPL, but perhaps there are some l= ogical groupings that make sense (seems that there are data and control mes= sages would could be one logical separation). Might also be nice in the Abstract to define MPL?=20 - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur Sent: Monday, July 07, 2014 12:32 PM To: Yusuke DOI Cc: dhcwg@ietf.org; Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-ro= ll-mpl-parameter-configuration-01.txt) A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for Creat= ing New DHCPv6 Options): - An encoded option is frowned upon. Split all of those into separate opti= ons, and the "Reserved" parts simply disappear. A "sub-optioned" option is also frowned upon (section 9, RFC 7227). - Why add the additional complexity of the floating point? Why not use a 32-bit unsigned integer representing milliseconds which gets you a li= ttle over 40 days? Not the 18 weeks that you currently can represent, but = is there a practical use for timers over a month long in MPL? - If you do go with separate options, consider what it would mean if certai= n options don't exist. ietf-roll-trickle-mcast appears to define defaults,= perhaps reference that draft to say that if an option is missing, the clie= nt is to use the default defined in that draft? - Speaking of RFC 7227... I-D.ietf-dhc-option-guidelines got published in = May -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Jul 8 02:11:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A631B27A2; Tue, 8 Jul 2014 02:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd0u-t3TiLbU; Tue, 8 Jul 2014 02:11:04 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F5F1A0154; Tue, 8 Jul 2014 02:11:03 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s689B17i026893; Tue, 8 Jul 2014 18:11:01 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s689B1C5029576; Tue, 8 Jul 2014 18:11:01 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA29571; Tue, 8 Jul 2014 18:11:01 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s689B0WT000522; Tue, 8 Jul 2014 18:11:00 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s689B0GL016702; Tue, 8 Jul 2014 18:11:00 +0900 (JST) Received: from [133.199.18.253] (ivpn-3-253.mobile.toshiba.co.jp [133.199.18.253]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 1CF6097D24; Tue, 8 Jul 2014 18:11:00 +0900 (JST) Message-ID: <53BBA43B.3080207@toshiba.co.jp> Date: Tue, 08 Jul 2014 16:56:43 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , Andre Kostur References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xVOQxurT97XmTbpMBUyms6LUGCQ Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 09:11:06 -0000 Hi Bernie, Thank you for comments, (2014-07-08 2:19), Bernie Volz (volz) wrote: > Not sure I'd suggest adding 10 (or 11) options for this? > > But I certainly would suggest, as Andre did, much simpler values - > flags and "compressed" data just make for much more complex and > error prone processing on both client and server. A structure which > would have all these values but in a much more standard set of data > formats would be better. -2 for compressed data. I'd like to make 'uncompressed' version and check if it's acceptable for roll-ish network. > Perhaps there is a middle grown to have groups of values (i.e., have > 3-4 options)? I'm really not that familiar with MPL, but perhaps > there are some logical groupings that make sense (seems that there > are data and control messages would could be one logical > separation). Ah, so your suggestion is to have (for example) three options?: 1) MPL Base configuration (P, SE_LIFETIME, {MPL Domain}) 2) MPL Control channel configuration (C_K, C_MIN, C_MAX, C_T_EXP, {MPL Domain}) 3) MPL Data channel configuration (D_K, D_MIN, D_MAX, D_T_EXI, {MPL Domain}) For me, duplication of MPL domain (128bit address x 3) seems to be wasteful. > Might also be nice in the Abstract to define MPL? Thanks, I'll add a definition. Yusuke From nobody Tue Jul 8 02:14:06 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50A1B27A8; Tue, 8 Jul 2014 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiWnxEdz02-Q; Tue, 8 Jul 2014 02:14:04 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73011B27A3; Tue, 8 Jul 2014 02:14:03 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s689E2af002095; Tue, 8 Jul 2014 18:14:02 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s689E2us020337; Tue, 8 Jul 2014 18:14:02 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA20336; Tue, 8 Jul 2014 18:14:02 +0900 Received: from mx9.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s689E1tH017473; Tue, 8 Jul 2014 18:14:01 +0900 (JST) Received: from mx.toshiba.co.jp by toshiba.co.jp id s689CvWS005136; Tue, 8 Jul 2014 18:12:57 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s689AuBT012979; Tue, 8 Jul 2014 18:10:56 +0900 (JST) Received: from [133.199.18.253] (ivpn-3-253.mobile.toshiba.co.jp [133.199.18.253]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C810397D24; Tue, 8 Jul 2014 18:10:56 +0900 (JST) Message-ID: <53BBA3EF.9040609@toshiba.co.jp> Date: Tue, 08 Jul 2014 16:55:27 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andre Kostur References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5KMhEF9XaJMzUZ9CD6cc_8Ua71Y Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 09:14:05 -0000 Hi Andre, Thank you for the comments. I think I need to explain background more. 1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops. I think a compact option format is more suitable for the case. 2) A parameter set is bound for an MPL domain. A network may have multiple MPL domains. I think it is much simpler to handle all parameters as a set. (2014-07-08 01:32), Andre Kostur wrote: > A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for > Creating New DHCPv6 Options): > > - An encoded option is frowned upon. Split all of those into separate > options, and the "Reserved" parts simply disappear. A "sub-optioned" > option is also frowned upon (section 9, RFC 7227). As described above, the parameters are considered as a set. I could not find recommended design for parameter sets. More than one parameter set will be configured. To make them separated I think each option should be with MPL domain (= IPv6 address). > - Why add the additional complexity of the floating point? Why not > use a 32-bit unsigned integer representing milliseconds which gets you > a little over 40 days? Not the 18 weeks that you currently can > represent, but is there a practical use for timers over a month long > in MPL? The motivation behind the floating point is to reduce message length as much as possible. As MPL has 7 timers, it will reduce 14 bytes. Though, usually 40 days should be enough and this is just a tradeoff (I'm not insisting on the floating point format). > - If you do go with separate options, consider what it would mean if > certain options don't exist. ietf-roll-trickle-mcast appears to > define defaults, perhaps reference that draft to say that if an option > is missing, the client is to use the default defined in that draft? If the draft goes with separate options, I agree it should be the default values. > - Speaking of RFC 7227... I-D.ietf-dhc-option-guidelines got published in May Thank you. Yusuke From nobody Tue Jul 8 22:53:57 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159281A0076; Tue, 8 Jul 2014 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cadLlR9LfvXg; Tue, 8 Jul 2014 13:59:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C851A005D; Tue, 8 Jul 2014 13:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2546; q=dns/txt; s=iport; t=1404853152; x=1406062752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MbdbfHrGgvfl6F8aEVP8N9CiNyKA/89mp6jyvO4EFho=; b=CiZXvE9fj8aUCS+9UGSjpXPwhrnlU2LtZyziQh2McuEWg3jdOKpDi/hU 4CgbSavCYUZNEtvRYNmVBwQUwySeOMtqQoTnWolAT06bu3sNnJdFnxkFq YSlS3VrClQwW3WEfkN+XC08+MIOdFcqQwsD2JTKq6WgKmDqaI7cVh6FJV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACdbvFOtJA2M/2dsb2JhbABagw6BLMZQAYEaFnWEAwEBAQMBOj8FBwQCAQgRBAEBAQoUBQQHMhQJCAIEAQ0FCIgyCMd6F4l6hGUVHSYLBwaDJ4EWAQSvAoIBgUKCMA X-IronPort-AV: E=Sophos;i="5.01,627,1400025600"; d="scan'208";a="59255687" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 08 Jul 2014 20:59:12 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68Kx9do031698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 20:59:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 15:59:09 -0500 From: "Bernie Volz (volz)" To: Yusuke DOI , Andre Kostur Thread-Topic: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) Thread-Index: AQHPmgEd2TBAYfQHIEyalFuCcQCzlpuU2QvAgAFLFYCAAIOPsA== Date: Tue, 8 Jul 2014 20:59:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EC66C@xmb-rcd-x04.cisco.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> <53BBA43B.3080207@toshiba.co.jp> In-Reply-To: <53BBA43B.3080207@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rurLtZV2z_FKYOLDP07ZWpmwIIg X-Mailman-Approved-At: Tue, 08 Jul 2014 22:53:55 -0700 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:59:12 -0000 Hi: I don't have a great answer for you as I have no idea what the typical usag= es are likely to be. If there are likely to be many instances and the desir= e to configure most of the values (and for multiple domains), then one sing= le option for each domain with all of the values is certainly a better idea= . I think the main points here are to: - avoid compressing the data / developing new data types and use more stand= ard elements (i.e., 16 or 32-bit integers) - see RFC 7227. - group things logically (i.e., alignment of the data, while making the pic= ture easier to draw, is not a requirement [of course we assume it is octet = (byte) aligned]). There are many ways to format this data, each with pros and cons. Making th= ose tradeoffs is something I am not in a good position to help you with. - Bernie -----Original Message----- From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp]=20 Sent: Tuesday, July 08, 2014 3:57 AM To: Bernie Volz (volz); Andre Kostur Cc: dhcwg@ietf.org; Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-ro= ll-mpl-parameter-configuration-01.txt) Hi Bernie, Thank you for comments, (2014-07-08 2:19), Bernie Volz (volz) wrote: > Not sure I'd suggest adding 10 (or 11) options for this? > > But I certainly would suggest, as Andre did, much simpler values -=20 > flags and "compressed" data just make for much more complex and error=20 > prone processing on both client and server. A structure which would=20 > have all these values but in a much more standard set of data formats=20 > would be better. -2 for compressed data. I'd like to make 'uncompressed' version and check i= f it's acceptable for roll-ish network. > Perhaps there is a middle grown to have groups of values (i.e., have > 3-4 options)? I'm really not that familiar with MPL, but perhaps there=20 > are some logical groupings that make sense (seems that there are data=20 > and control messages would could be one logical separation). Ah, so your suggestion is to have (for example) three options?: 1) MPL Base configuration (P, SE_LIFETIME, {MPL Domain}) 2) MPL Control channel configuration (C_K, C_MIN, C_MAX, C_T_EXP, {MPL Domain}) 3) MPL Data channel configuration (D_K, D_MIN, D_MAX, D_T_EXI, {MPL Domain}) For me, duplication of MPL domain (128bit address x 3) seems to be wasteful= . > Might also be nice in the Abstract to define MPL? Thanks, I'll add a definition. Yusuke From nobody Thu Jul 10 17:10:50 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF1D1A0168; Thu, 10 Jul 2014 17:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.994 X-Spam-Level: X-Spam-Status: No, score=-3.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrwlzVNDnOI6; Thu, 10 Jul 2014 17:10:43 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD93B1A0123; Thu, 10 Jul 2014 17:10:25 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s6B0ANf1025672; Fri, 11 Jul 2014 09:10:23 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s6B0ANFR017263; Fri, 11 Jul 2014 09:10:23 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id KAA17260; Fri, 11 Jul 2014 09:10:23 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s6B0AMkL029277; Fri, 11 Jul 2014 09:10:23 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6B0AMf2024245; Fri, 11 Jul 2014 09:10:22 +0900 (JST) Received: from [133.199.147.10] (ivpn-7-10.mobile.toshiba.co.jp [133.199.147.10]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 74B5E97D1C; Fri, 11 Jul 2014 09:10:22 +0900 (JST) Message-ID: <53BE21E8.60007@toshiba.co.jp> Date: Thu, 10 Jul 2014 14:17:28 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , Andre Kostur References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> <53BBA43B.3080207@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5EC66C@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5EC66C@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/V2mgVKmVCAG8_R0xckP-1GbcFFg Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 00:10:48 -0000 Hi Bernie, (2014-07-09 5:59), Bernie Volz (volz) wrote: > Hi: > > I don't have a great answer for you as I have no idea what the > typical usages are likely to be. If there are likely to be many > instances and the desire to configure most of the values (and for > multiple domains), then one single option for each domain with all > of the values is certainly a better idea. Thanks, I'll add some note to describe expected use case. The options are likely to be used as a set and I think open single option is easier to implement. > I think the main points here are to: - avoid compressing the data / > developing new data types and use more standard elements (i.e., 16 > or 32-bit integers) - see RFC 7227. - group things logically (i.e., > alignment of the data, while making the picture easier to draw, is > not a requirement [of course we assume it is octet (byte) aligned]). I agree. In addition, I noticed 8bit common exponent (in other words, unit time of timers) for all timers will be much much simpler. > There are many ways to format this data, each with pros and cons. > Making those tradeoffs is something I am not in a good position to > help you with. Your comments are very helpful for me, thanks! Regards, Yusuke From nobody Thu Jul 10 20:18:33 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE271A020A; Thu, 10 Jul 2014 20:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dr4uVgj37F2; Thu, 10 Jul 2014 20:18:26 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEF91A01C6; Thu, 10 Jul 2014 20:18:26 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 25D021B8504; Thu, 10 Jul 2014 20:18:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CF96E190068; Thu, 10 Jul 2014 20:18:25 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 20:18:25 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53BBA3EF.9040609@toshiba.co.jp> Date: Thu, 10 Jul 2014 16:48:57 -0400 Content-Transfer-Encoding: 7bit Message-ID: <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> To: Yusuke DOI X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-ar3TxlpS8L5D4X2YqHiLBYndWo Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks , Andre Kostur Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 03:18:27 -0000 On Jul 8, 2014, at 3:55 AM, Yusuke DOI wrote: > 1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops. > I think a compact option format is more suitable for the case. This doesn't sound like something you'd configure with DHCP. From maria.ines.robles@ericsson.com Thu Jul 10 13:56:02 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87ED1A0B12; Thu, 10 Jul 2014 13:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 XBtT6K2HWfGn; Thu, 10 Jul 2014 13:56:00 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAC01B29F8; Thu, 10 Jul 2014 13:55:59 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-bb-53befdddd845 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5F.C3.03739.DDDFEB35; Thu, 10 Jul 2014 22:55:58 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.206]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 22:55:57 +0200 From: MARIA INES ROBLES To: "ietf@ietf.org" Thread-Topic: LLN Plugfest at IETF 90 - Guidelines available Thread-Index: Ac+cgViQKchsNj+ISiGQDeHbLszfmQ== Date: Thu, 10 Jul 2014 20:55:57 +0000 Message-ID: <84931A8364A34C47BDBEAE933CD95BB4ECFF24@ESESSMB307.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_84931A8364A34C47BDBEAE933CD95BB4ECFF24ESESSMB307ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvje69v/uCDRZsYbFoniJgsexuH7PF s43zWSyaLgtYbNx6jsmB1eNwxxd2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZcxZtJe9YIFWxcfX Z9kaGK8rdzFyckgImEjcnTeREcIWk7hwbz1bFyMXh5DAUUaJa+2PWUESQgJLGCW6N+t0MXJw sAlYSBy4HwgSFhFQljgw8wYrSD2zwBpGie1PVoLVCwuYS6yavJQRoshGouUQxBwRAT2Jl+dv gMVZBFQluo+/YwOxeQW8JU6+vQ1mMwId8f3UGiYQm1lAXOLWk/lMEMcJSCzZc54ZwhaVePn4 HyuErSTRuOQJK0R9vsSUrxvYIWYKSpyc+YRlAqPwLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC 18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIysg1t+6+5gXP3a8RCj AAejEg/vgiv7goVYE8uKK3MPMUpzsCiJ8y46Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A2Ngvumt25bTL+5rubKIcdGEL3Z3Vm75PWH1hiqhhEuRvRrhv49cfiktzfNihrf/lddHep9y aUxX1ZiSOfNssSz/BoU364oye9eI/s5RkZ75pbuUQ4vBuNqK/2TJ9uayzDvtzNzS+k+TW01+ Xzf9lJaln6cr8Ofksj2ciVYe7NO+3BLIXLvU2EaJpTgj0VCLuag4EQB9LQzWjQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HtHxk1wTC-tXDq96rvxzICvGAdQ Cc: "roll@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: [Roll] LLN Plugfest at IETF 90 - Guidelines available X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 06:36:08 -0000 --_000_84931A8364A34C47BDBEAE933CD95BB4ECFF24ESESSMB307ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find the updated wiki for the Plugfest [https://bitbucket.org/6tisch= /meetings/wiki/140720a_ietf90_toronto_plugfest]; here you can find the list= of participants and the link to the guidelines [https://bitbucket.org/6tis= ch/meetings/src/master/140720_ietf90_plugfest_toronto/] Please any comments are very welcome. Thanks, Xavier and Ines. --_000_84931A8364A34C47BDBEAE933CD95BB4ECFF24ESESSMB307ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all,

Please find the updated wiki for the Plugfest [https://bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_t= oronto_plugfest]; here you can find the list of participants and the link to the guidelines [https://bitbucket.org/6tisch/meetings/src/= master/140720_ietf90_plugfest_toronto/]

Please any comments are very welcome.

Thanks,

Xavier and Ines.

--_000_84931A8364A34C47BDBEAE933CD95BB4ECFF24ESESSMB307ericsso_-- From nobody Sat Jul 12 05:37:05 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549181B286A; Sat, 12 Jul 2014 05:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xiR0oJayD82; Sat, 12 Jul 2014 05:37:02 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A9B1B2866; Sat, 12 Jul 2014 05:37:01 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so63134qap.23 for ; Sat, 12 Jul 2014 05:37:01 -0700 (PDT) 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=dTZY3HCOQARl4SuH4Ux6WOdoDOIBfsyNesa+46xWDbY=; b=BlW6m2UtBkXpUh9fzA9llkCvPxfsKDgI4TK7mrfLGMolODsjSLpmD0VYMPcSoFSQ1P 4gTueJvlSLOcaPu0+uUKqH4qu5sSPnfvO1XX8pO47w9Y9iUKm4mGeU8yKg6a+7DueHWM 0jIqHMuS5QAkPI7M410KWKGiqSZmGtrO/sgMSma+/SYUZ+uyNfb5mMJP8Pgt7xfZ6qy+ u7/iMR35+6gwSkPhIyRAPrGWzOlh1SYCcauxbihz8omdnwTTDnqVGVatMblRN0SSmpLr hw3KH3d2JQ5B3MoDbukEpRLo/GOCHjFHvVPMfOod7AbUrD7pVc200L9Tq6kbny3XjL2n e1Jw== X-Received: by 10.224.3.201 with SMTP id 9mr4947569qao.73.1405168620020; Sat, 12 Jul 2014 05:37:00 -0700 (PDT) Received: from [172.20.10.3] (mobile-198-228-204-049.mycingular.net. [198.228.204.49]) by mx.google.com with ESMTPSA id 94sm5261082qgu.20.2014.07.12.05.36.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 05:36:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> Date: Sat, 12 Jul 2014 08:36:56 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/voZc8sWk0fllYLiNc1Y0sCCLOtk Cc: "dhcwg@ietf.org" Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 12:37:03 -0000 On Jul 10, 2014, at 4:48 PM 7/10/14, Ted Lemon wrote: > On Jul 8, 2014, at 3:55 AM, Yusuke DOI wrote: >> 1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops. >> I think a compact option format is more suitable for the case. > > This doesn't sound like something you'd configure with DHCP. Ted - what does "this" refer to? MPL in general? - Ralph From nobody Sat Jul 12 09:32:08 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531431B2B94; Sat, 12 Jul 2014 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFxCedjfnUPF; Sat, 12 Jul 2014 09:32:00 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED94E1B2B92; Sat, 12 Jul 2014 09:31:59 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9A3561B860F; Sat, 12 Jul 2014 09:31:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 73B80190068; Sat, 12 Jul 2014 09:31:59 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 12 Jul 2014 09:31:53 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> Date: Sat, 12 Jul 2014 12:31:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3ktqXEC1K9t6sD0sSsS-mIYYTag Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 16:32:04 -0000 On Jul 12, 2014, at 8:36 AM, Ralph Droms wrote: > Ted - what does "this" refer to? MPL in general? Using DHCP to push a big chunk of information about the state of a mesh = network seems like a suboptimal approach. The fact that compression is = desired suggests that you are using the wrong tool for the job. From nobody Mon Jul 14 04:02:38 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FC21A03AB for ; Mon, 14 Jul 2014 04:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGPrRUtx4Ssg for ; Mon, 14 Jul 2014 04:02:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2811A03A9 for ; Mon, 14 Jul 2014 04:02:34 -0700 (PDT) Received: from localhost ([::1]:42949 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X6e1b-0006TH-Nu; Mon, 14 Jul 2014 04:02:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr+ietf@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 14 Jul 2014 11:02:27 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/160 Message-ID: <067.c837f6a66878301368eb32307147f5d6@trac.tools.ietf.org> X-Trac-Ticket-ID: 160 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr+ietf@sandelman.ca, mariainesrobles@gmail.com, robert.cragie@gridmerge.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/SEtBwU-CeqUsx-8JaOmoDTMAqr8 Cc: roll@ietf.org Subject: [Roll] [roll] #160 (security-threats): draft-ietf-roll-security-threats-07--Nits to fix X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 11:02:36 -0000 #160: draft-ietf-roll-security-threats-07--Nits to fix Robert Cragie on 2014-07-14 wrote: "Just a few comments remaining (mostly nits): Section 4.2: "applied to RPL; in particular" -> "applied to RPL in particular" Section 4.2: "In the context of RPL" -> "In the context of RPL:" Section 6.1: "An attacker can assert an arbitrary identity," -> "An attacker that can assert an arbitrary identity,". I actually think the whole sentence is unnecessary. Section 6.1.3: "join a network with any identify" -> "join a network using any identity" Section 6.1.3: "battery, ram, bandwidth" -> "battery, RAM, bandwidth" Section 6.2: "This threat results" -> "These attacks may result" "Figure 4: sinkhole attack" -> "Figure 4: Sinkhole attack" Section 7.1.2: "well-equiped" -> "well-equipped" Section 7.1.2 "particularly vulnerable to passive (and active) attacks through compromises of nodes" -> "vulnerable to passive (and active) routing attacks through compromises of nodes (see Section 8.2)." Slight modification and add reference. Section 8: "endemnic to this field" -> "endemic in this field" Section 8: General comment - much tidier, good job! Section 8.2: "However, some RPL messages are broadcast, and even when per- node layer-2 security mechanisms are used, the integrity and origin authentication of broadcast messages can not be as securely known". How so - due to using a group/network wide key? If so, maybe state that. Suggested change: "However, some RPL messages are broadcast and even when per-node layer-2 security mechanisms are used, the integrity and origin authentication of broadcast messages cannot be as trusted due to the proliferation of the key used to secure them." Section 8.2: "RPL has two specific messages which are broadcast: the DODAG Information Object (DIO), and the DODAG Information Solicitation (DIS). The purpose of the DIS is to cause potential parents to reply with a DIO, so the integrity of the DIS is not of great concern. The DIS may also be unicast" These are not actually messages; there is only one RPL Control Message. Therefore need to rephrase: "RPL has two specific options which are present in broadcast RPL Control Messages: the DODAG Information Object (DIO), and the DODAG Information Solicitation (DIS). The purpose of the DIS is to cause potential parents to reply with an RPL Control Message containing a DIO, so the integrity of the DIS is not of great concern. The DIS may also be unicast" "RPL provides for assymetric authentication at layer-3 of the DIO, and this may be waranteed in some deployments." -> "RPL provides for asymmetric authentication at layer 3 of the RPL Control Message carrying the DIO and this may be warranted in some deployments." Section 8.3 still doesn't read right. Section 11: "Robert Craigie" -> "Robert Cragie" :-) " -- ---------------------------------------+----------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr+ietf@sandelman.ca Type: defect | Status: new Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Keywords: ---------------------------------------+----------------------------------- Ticket URL: roll From nobody Tue Jul 15 01:33:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914F81A0368 for ; Tue, 15 Jul 2014 01:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js2RE_7oXnRB for ; Tue, 15 Jul 2014 01:33:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8541A001A for ; Tue, 15 Jul 2014 01:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4243; q=dns/txt; s=iport; t=1405413185; x=1406622785; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0pvB/Z1iJt3eOH/CTHHU2xiH/9b90MScxlExNsdMVO0=; b=Ig7/iiGdF8Yv6FNncs1B/nJv9l0D6JiP/JjI7dVA3vnEHDJiPlGjbJpq IIniqRcIFSEFOpVG1mgesSZNKd3D8ljKbJ01OoK5wKLTlClUgZLpl78El Lexy38bBkGTNSxmSnDoKpjfBQ9oN53dM5ewMwgKLeeSXTE6ymoeFF74MF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJzmxFOtJA2H/2dsb2JhbABZgw6BLckhAYEIFnWEBAEBAwE6RAsCAQgiFBAyJQIEG4gyCMkwF45jNziDLYEWBa84g0SCMA X-IronPort-AV: E=Sophos;i="5.01,664,1400025600"; d="scan'208";a="340080769" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2014 08:33:04 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6F8X4In017659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Jul 2014 08:33:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 03:33:03 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] question about DAO-ACK Thread-Index: AQHPljNyNFRTP6zvKEq5hluTFJmycZug1v3A Date: Tue, 15 Jul 2014 08:33:03 +0000 Deferred-Delivery: Tue, 15 Jul 2014 08:33:00 +0000 Message-ID: References: <5003.1404332581@sandelman.ca> In-Reply-To: <5003.1404332581@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.216.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZgO44h__kvg2rnt0Q2dXHaBRnkY Subject: Re: [Roll] question about DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 08:33:06 -0000 Hello Michael: Please find below what at least was in the intention in the spec: =20 > Given: > - a storing implementation > - DAO-ACKs requested > - three nodes: A <- B <- C. A is the root. >=20 > C sends a DAO with the K bit set to selected parent B. > B will need to send a DAO to A indicating that it knows about C. >=20 > Question > 1) should B wait until it receives a DAOACK from A before > sending a DAOACK back to C? > (before you answer, consider the the tree could be very > deep, and that this implies that the intermediate nodes > have to keep potentially many outgoing DAOACKs in a queue) >=20 > Or is it enough that B says, "okay, I got you", and then > takes responsibility for sending reachability information > on its own? >=20 [PT] The design was the latter, that it was OK for B to say "I got you". Today it is mostly an alternate to MAC layer Ack, but the design is richer = than that since a status code is provisioned though not used. A negative status code could say things like "I'm overloaded with DAO state= already" or "I'm out of battery". > The problem I have with not waiting is that if C thinks > it is on the network when it gets the DAOACK, it can start > sending traffic upwards, but downward packets would get lost for awhil= e. > Further, it is going to start sending DIOs, and start attracting > traffic from other nodes when really, it isn't ready to do so. >=20 [PT] This could effectively happen; mostly if you are considering the join = process. This suggests that leveraging a tunnel from a joined parent could effective= ly be a good idea there (eg piggy backing join info to system/security mana= ger on DAR/DAC message). Also that piggybacking security info to the DAO could effectively improve t= he trust in the DAO content and ensure that the next phases of join process= can be responded to. > 2) if B recieves a DAO with the K bit set from, does this imply > that it ought to set the K bit to its parent? > If the answer is no, and you answer the question (1) that B ought to > wait until it has heard from A before answering, but B > has a policy of not setting the K bit, should B then > answer immediately? [PT] No, this is not the case. The design for the K-bit was a one-hop thing= that may depend on the link properties.=20 >=20 > 3) in the non-storing case, if a parent (B) of C, in fact had > multiple interfaces, node C might not see the interface > that is closer to A, and can only, in the Transit option, > indicate the interface that it does see. This implies > that root A, may have to do two lookups to figure out > where Bdown is, as it likely only has route to Bup. >=20 [PT] You seem to imply that BDown would be advertised as reachable via BUp.= Could be, e.g. in a mobility scenario where 1) you have many BDowns and 2)= BUp changes parents frequently; in which case doing this would save advert= isements: in case of a movement you'd only advertise the change of parent o= f BUp. But the more common case is that B would advertise all its addresses= as being reachable via its parent, but concatenating multiple target optio= ns for all its interfaces and then placing a transit option for the parent = that is factorized. > 4) what is the use case for the RPL Target Descriptor? [PT] The intent was route tagging. I did not get feedback that anyone is us= ing it so far, but it is a classical thing and probably was a good idea to = support it from the start. A tag may be placed to influence routing based o= n policies, and redistribution between protocols or domains. A tag could fo= r instance indicate which RPL domain or subdomain the node is effectively a= ttached to. In classical networks you want to stay within the same area/ ro= uting protocol domain and tags are used to prevent reinjection into the ori= ginal domain from an different domain. With RPL, if you have a fast (OSPF /= Ethernet backbone) and a slow network (RPL LLN) then you may have more com= plex / asymmetric rules, since going though the fast network is probably a = good idea. Cheers, Pascal From nobody Thu Jul 17 05:02:39 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DD61A045B for ; Thu, 17 Jul 2014 05:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32Y3ImERWtME for ; Thu, 17 Jul 2014 05:02:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25D41A01DC for ; Thu, 17 Jul 2014 05:02:36 -0700 (PDT) Received: from localhost ([::1]:43351 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X7kOP-0004DH-9f; Thu, 17 Jul 2014 05:02:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 17 Jul 2014 12:02:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/157#comment:2 Message-ID: <082.0b28e04c6effb9f69a40a18dd241fb7f@trac.tools.ietf.org> References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> X-Trac-Ticket-ID: 157 In-Reply-To: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org, mariainesrobles@gmail.com, yusuke.doi@toshiba.co.jp, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: matthew.gillmore@itron.com, yusuke.doi@toshiba.co.jp Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Eb415EibBGVfifF3fmiOW9MP-6U Cc: roll@ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 12:02:38 -0000 #157: mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes Comment (by mariainesrobles@gmail.com): In version 01 - section 2.7 addresses this issue "2.7. Operational Considerations A parameter set for an MPL domain SHOULD NOT updated more often than two times of expected refresh interval. If a node with MPL forwarder configured by MPL Parameter configuration Option failed to refresh the option for two times of information refresh time, it SHALL suspend the MPL forwarders of MPL domains configured by the option. MPL forwarders configured by other methods such as static configuration file SHALL NOT be suspended." -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-doi-roll-mpl- mariainesrobles@gmail.com | parameter- Type: defect | configuration@tools.ietf.org Priority: major | Status: new Component: draft-doi-roll-mpl- | Milestone: parameter-configuration | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Sat Jul 19 11:35:06 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE6E1B29AC for ; Sat, 19 Jul 2014 11:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cbps1a2o9TU for ; Sat, 19 Jul 2014 11:35:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5461B2854 for ; Sat, 19 Jul 2014 11:35:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E7A8D2002A for ; Sat, 19 Jul 2014 14:36:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 67BA263B0E; Sat, 19 Jul 2014 14:34:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3631263AED for ; Sat, 19 Jul 2014 14:34:59 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <5003.1404332581@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3_rQXo1Ui0261K3GT9XSVf3ncUw Subject: Re: [Roll] question about DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 18:35:05 -0000 --=-=-= Pascal Thubert (pthubert) wrote: >> Or is it enough that B says, "okay, I got you", and then takes >> responsibility for sending reachability information on its own? > [PT] The design was the latter, that it was OK for B to say "I got > you". Today it is mostly an alternate to MAC layer Ack, but the design > is richer than that since a status code is provisioned though not used. > A negative status code could say things like "I'm overloaded with DAO > state already" or "I'm out of battery". Yes... so if the sender does set the K bit, they might still get the MAC layer ACK, which tells them the packet was received, but can not tell them anything about being overloaded, etc. What reason would there be not to set the K bit? In non-storing mode, if you set the K bit, can you expect to ever get a negative reply, if the root is overloaded, or otherwises refuses to accept your DAO? (You can't get a reply, because the root can't route to you, since it didn't accept your DAO...) >> The problem I have with not waiting is that if C thinks it is on the >> network when it gets the DAOACK, it can start sending traffic upwards, >> but downward packets would get lost for awhile. Further, it is going >> to start sending DIOs, and start attracting traffic from other nodes >> when really, it isn't ready to do so. > [PT] This could effectively happen; mostly if you are considering the > join process. This suggests that leveraging a tunnel from a joined > parent could effectively be a good idea there (eg piggy backing join > info to system/security manager on DAR/DAC message). Also that > piggybacking security info to the DAO could effectively improve the > trust in the DAO content and ensure that the next phases of join > process can be responded to. I was not thinking about any of the (initial) join process; it could just be a node rejoining after a movement, an RF change reveals a new parent, or just a cold restart of the node. >> 3) in the non-storing case, if a parent (B) of C, in fact had multiple >> interfaces, node C might not see the interface that is closer to A, >> and can only, in the Transit option, indicate the interface that it >> does see. This implies that root A, may have to do two lookups to >> figure out where Bdown is, as it likely only has route to Bup. > [PT] You seem to imply that BDown would be advertised as reachable via > BUp. Yes, that's right. The root would have a (source) route to Bup (whether direct or via other layers of the mesh), and another source route to Bdown (via Bup) The important thing is that C can not mention Bup, it can only mention Bown. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8q6TYCLcPvd0N1lAQKl/gf9GEqy57LRUFPXRyoo+zKjNhAyHFhjQBKy wAI80KN/6KOrqCKoH38CMidQjOUhHfmj8lxmeZcFjT2O1W4HwUj95OTHKn1n15cj bP1WuORKYDznDXDoI3YEExIm+I2Qsl9cd0wrOQ59O/BOqDUzUEFEKg0PGEEL1Z8U rfwDTisMt968q6XbYJSMaSSw1DOdaUVHGB8Nenw3Idhjnnt7G5H1T6Wq2HC5BNLT +cBLHPMuxpxGjP65hVC9vVXaVJo1L+UPwlz249Z8W9U01Szg6ycpcFYGIBIec/lK EbVH38fLyH6TCBaZC5B0cBIjIHUtI6K4DAIPxCW9MY8zftg9bsarXA== =8W7J -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 19 13:27:54 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F61B2988; Sat, 19 Jul 2014 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8HVnHcOats3; Sat, 19 Jul 2014 13:27:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B980B1B27B5; Sat, 19 Jul 2014 13:27:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CF2EB2002B; Sat, 19 Jul 2014 16:29:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 015AF63B0E; Sat, 19 Jul 2014 16:27:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DF2C563AED; Sat, 19 Jul 2014 16:27:44 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/RGDB29z0Rp8apF9thdANqHoJmyc Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 20:27:51 -0000 --=-=-= Ted Lemon wrote: >> Ted - what does "this" refer to? MPL in general? > Using DHCP to push a big chunk of information about the state of a mesh > network seems like a suboptimal approach. The fact that compression is > desired suggests that you are using the wrong tool for the job. It's not state about the network, it's configuration parameters about the (multicast) routing protocol. Ideally, the parameters need to be the same across the mesh (but we have validated that mismatches in certain directions and within certain tolerances are acceptable; usually causing excess energy use, rather than network in-operation), but over time the operator will want to tune the parameters to optimize energy. As such we need a protocol that assigns lifetimes to parameters and facilitates expiring old values. DHCP seems ideal for this; it's also not RPL specific, as MPL is not tied to RPL. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8rUvoCLcPvd0N1lAQIjKwgAwRjNXEvxE0tbsHjxJLmakv1uYgs5TUud Qqxm8SNPUatC7jGhXiUDY7uwLFBK7ewMEcVXy6KQ1SUnP15Y55g0AxuM5GvvSjes YsT0wITrVrIdSWvJ1wCUJJt/ImGx88klYW7kVqonaqBvv3cWQt/MX78qzOJgakXg XMD7QzCA1xO/c7LftXM7qU+ReQoF0F8gYNei+itIg8lrTzwUO8hIdqeZGzieO5/i Ag+hT7O6BGyg2uLf1iLSAk8VnS8GqpUdx/pRmUWiDjuCpDSAwr4mxXwRI7fJjvbL p4MHepritDi+VYBMQjFhLKwaInbKrcfz/T9rcAnE8IghmniHCDBE3Q== =SezO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 19 14:21:00 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390C41B2A13; Sat, 19 Jul 2014 14:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHT_jx9nGijK; Sat, 19 Jul 2014 14:20:53 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8A91B2A0A; Sat, 19 Jul 2014 14:20:53 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4A516F804A; Sat, 19 Jul 2014 14:20:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EAA76190060; Sat, 19 Jul 2014 14:20:52 -0700 (PDT) Received: from [192.168.0.10] (99.232.25.196) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Jul 2014 14:20:47 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <7303.1405801664@sandelman.ca> Date: Sat, 19 Jul 2014 17:20:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> <7303.1405801664@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [99.232.25.196] Archived-At: http://mailarchive.ietf.org/arch/msg/roll/_JJYiMx0JpORnO0458aLppD5Dwg Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 21:20:58 -0000 Okay, thanks. I think compressing is saving three bytes; this is = noise. Please don't do that. We need to define a fragment type for = unsigned short floating point; that should be a quick, simple DHCP = document. The rest of the document looks fine at first glance, but as = you've no doubt detected, I didn't read it before asking about the = previous thing and I still haven't read it closely, so don't take that = as a claim that I won't comment further later when I have more time = (whenever that magic day comes). From nobody Sat Jul 19 16:45:04 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCC11B2ADE; Sat, 19 Jul 2014 16:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.491 X-Spam-Level: X-Spam-Status: No, score=-16.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fKAcXFoDAGE; Sat, 19 Jul 2014 16:44:55 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058C91B2ADC; Sat, 19 Jul 2014 16:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16634; q=dns/txt; s=iport; t=1405813495; x=1407023095; h=from:to:subject:date:message-id:mime-version; bh=QaVWViGD4EQaKo82pkBrxUKJWXPXYR8ldKDHRi3A8mU=; b=j4SN6QIQktjIWdWhDD4tIjDjrqBB1rWacufjtpQS8HRivZGoz6TM0q58 YDJnCup+E1DTddno7XzgbtxO3nUemjKzaWa6jSgx3kum45VULWvd/0bau 5pyH8caBzcBVom+jumpBxsBeJ9RYYzNGjRLW9yG2YlvjK3sWxtW4cabMB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAFUCy1OtJA2L/2dsb2JhbAA+FwOCR0dSVwSCdMIXh0IBGW8WdoQDAQEBBCMKKBElARkDAQEBCwoEDAMDAgQwFAkHAgEBAwESCIg6DTaqY4VOkTcXjmkRAQwTCyIKEgeCYDaBGAWFc5Z/kmKCb1VsAYELOQ X-IronPort-AV: E=Sophos; i="5.01,693,1400025600"; d="scan'208,217"; a="62321604" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 19 Jul 2014 23:44:54 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6JNisMv029544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jul 2014 23:44:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sat, 19 Jul 2014 18:44:53 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, Routing Over Low power and Lossy networks Thread-Topic: Joined PlugFest Thread-Index: Ac+jq0gpMsu5CkIxTMmCbzNTIEIcDw== Date: Sat, 19 Jul 2014 23:44:53 +0000 Deferred-Delivery: Sat, 19 Jul 2014 23:44:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.202] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842CCD498xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/8R3F6GKVNEi-we4XBFYiWVqP0ok Subject: [Roll] Joined PlugFest X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 23:44:58 -0000 --_000_E045AECD98228444A58C61C200AE1BD842CCD498xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQoNCkdlbnRsZSByZW1pbmRlciB0byBhbGwgcHJlc2VudCBpbiBUb3JvbnRvIHRo YXQgdGhlIGpvaW5lZCBwbHVnIGZlc3Qgd2lsbCB0YWtlIHBsYWNlIGZyb20gOUFNIHRvIDFQTSBp biBTYWxvbiBCLg0KSWYgeW91IGNhbm5vdCBiZSBwcmVzZW50IGluIHBlcnNvbiB5b3UgbWF5IHdh bnQgdG8gZm9sbG93IG9uIHRoZSBhdHRhY2hlZCB3ZWJleDoNCg0KQ2hlZXJzLA0KDQpQYXNjYWwN Cg0KRnJvbTogNnRpc2NoIFttYWlsdG86NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpTZW50OiBzYW1lZGkgMTkganVpbGxldCAy MDE0IDE5OjI1DQpUbzogNnRpc2NoQGlldGYub3JnDQpTdWJqZWN0OiBbNnRpc2NoXSBXZWJleCBN ZWV0aW5nIGludml0YXRpb246IEpvaW5lZCBQbHVnRmVzdA0KDQpIZWxsbyAsDQoNClBhc2NhbCBU aHViZXJ0IGludml0ZXMgeW91IHRvIGF0dGVuZCB0aGlzIG9ubGluZSBtZWV0aW5nLg0KDQpUb3Bp YzogSm9pbmVkIFBsdWdGZXN0DQpEYXRlOiBTdW5kYXksIEp1bHkgMjAsIDIwMTQNClRpbWU6IDk6 MDAgYW0sIEVhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkNCk1lZXRp bmcgTnVtYmVyOiAyMDIgMjMyIDEzNg0KTWVldGluZyBQYXNzd29yZDogdW5wbHVnZ2VkDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K VG8gam9pbiB0aGUgb25saW5lIG1lZXRpbmcgKE5vdyBmcm9tIG1vYmlsZSBkZXZpY2VzISkNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjEu IEdvIHRvIGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tODBm YzY4NDRmOTczNTZkOTVjMzFhZTRjY2E0ZGY1OTYNCjIuIEVudGVyIHlvdXIgbmFtZSBhbmQgZW1h aWwgYWRkcmVzcy4NCjMuIEVudGVyIHRoZSBtZWV0aW5nIHBhc3N3b3JkOiB1bnBsdWdnZWQNCjQu IENsaWNrICJKb2luIE5vdyIuDQoNClRvIHZpZXcgaW4gb3RoZXIgdGltZSB6b25lcyBvciBsYW5n dWFnZXMsIHBsZWFzZSBjbGljayB0aGUgbGluazoNCmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Np c2Nvc2FsZXMvai5waHA/TVRJRD1tM2IzNzM5ZGYzYjNhMDE2ZWQ4ZjBhNGE4ZWJkOGUxMTYNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KQUxFUlQg4oCTIFBMRUFTRSBSRUFEOiBETyBOT1QgRElBTCBUSEUgVE9MTCBGUkVF IE5VTUJFUlMgRlJPTSBXSVRISU4gVEhFICg0MDgpIE9SICg5MTkpIEFSRUEgQ09ERVMNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClBsZWFzZSBkaWFsIHRoZSBsb2NhbCBhY2Nlc3MgbnVtYmVyIGZvciB5b3VyIGFyZWEgZnJv bSB0aGUgbGlzdCBiZWxvdzoNCi0gU2FuIEpvc2UvTWlscGl0YXMgKDQwOCkgYXJlYTogNTI1LTY4 MDANCi0gUlRQICg5MTkpIGFyZWE6IDM5Mi0zMzMwDQoNCkRpYWxpbmcgdGhlIFdlYkV4IHRvbGwg ZnJlZSBudW1iZXJzIGZyb20gd2l0aGluIDQwOCBvciA5MTkgYXJlYSBjb2RlcyBpcyBub3QgZW5h YmxlZCAobm9uLUNpc2NvIHBob25lcykuIOKAnCBJZiB5b3UgZGlhbCB0aGUgdG9sbC1mcmVlIG51 bWJlcnMgd2l0aGluIHRoZSA0MDggb3IgOTE5IGFyZWEgY29kZXMgeW91IHdpbGwgYmUgaW5zdHJ1 Y3RlZCB0byBoYW5nIHVwIGFuZCBkaWFsIHRoZSBsb2NhbCBhY2Nlc3MgbnVtYmVyLuKAnSBQbGVh c2UgdXNlIHRoZSBjYWxsLWJhY2sgb3B0aW9uIHdoZW5ldmVyIHBvc3NpYmxlIGFuZCBvdGhlcndp c2UgZGlhbCBsb2NhbCBudW1iZXJzIG9ubHkuIFRoZSBhZmZlY3RlZCB0b2xsIGZyZWUgbnVtYmVy cyBhcmU6ICg4NjYpIDQzMi05OTAzIGZvciB0aGUgU2FuIEpvc2UvTWlscGl0YXMgYXJlYSBhbmQg KDg2NikgMzQ5LTM1MjAgZm9yIHRoZSBSVFAgYXJlYS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVG8gam9pbiB0aGUgdGVsZWNvbmZl cmVuY2Ugb25seQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KMS4gRGlhbCBpbnRvIENpc2NvIFdlYkV4ICh2aWV3IGFsbCBHbG9iYWwgQWNj ZXNzIE51bWJlcnMgYXQNCmh0dHA6Ly9jaXNjby5jb20vZW4vVVMvYWJvdXQvZG9pbmdfYnVzaW5l c3MvY29uZmVyZW5jaW5nL2luZGV4Lmh0bWwNCjIuIEZvbGxvdyB0aGUgcHJvbXB0cyB0byBlbnRl ciB0aGUgTWVldGluZyBOdW1iZXIgKGxpc3RlZCBhYm92ZSkgb3IgQWNjZXNzIENvZGUgZm9sbG93 ZWQgYnkgdGhlICMgc2lnbi4NCg0KU2FuIEpvc2UsIENBOiArMS40MDguNTI1LjY4MDAgUlRQOiAr MS45MTkuMzkyLjMzMzANCg0KVVMvQ2FuYWRhOiArMS44NjYuNDMyLjk5MDMgVW5pdGVkIEtpbmdk b206ICs0NC4yMC44ODI0LjAxMTcNCg0KSW5kaWE6ICs5MS44MC40MzUwLjExMTEgR2VybWFueTog KzQ5LjYxOS42NzczLjkwMDINCg0KSmFwYW46ICs4MS4zLjU3NjMuOTM5NCBDaGluYTogKzg2LjEw Ljg1MTUuNTY2Ng0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpGb3IgYXNzaXN0YW5jZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMS4gR28gdG8gaHR0cHM6Ly9jaXNjby53ZWJl eC5jb20vY2lzY29zYWxlcy9tYw0KMi4gT24gdGhlIGxlZnQgbmF2aWdhdGlvbiBiYXIsIGNsaWNr ICJTdXBwb3J0Ii4NCg0KWW91IGNhbiBjb250YWN0IG1lIGF0Og0KcHRodWJlcnRAY2lzY28uY29t PG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+DQozMy00OS03MjMgMjYzNA0KDQpBZGQgdGhpcyBt ZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgcHJvZ3JhbToNCmh0dHBzOi8vY2lzY28ud2ViZXguY29t L2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tMmMzN2RmM2ZlZjBhMWYxYWNlY2ZhODU5NTFmZjlkNDkN Cg0KDQoNCg0KDQoNCmh0dHA6Ly93d3cud2ViZXguY29tDQoNCkNDUDorMTQwODUyNTY4MDB4MjAy MjMyMTM2Iw0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMg YSBmZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBt YXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVj b3JkZWQuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50 IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRp bmcsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8g dGhlIHN0YXJ0IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBs ZWFzZSBub3RlIHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNj b3ZlcnkgaW4gdGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uDQo= --_000_E045AECD98228444A58C61C200AE1BD842CCD498xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBhbGw6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HZW50bGUgcmVtaW5k ZXIgdG8gYWxsIHByZXNlbnQgaW4gVG9yb250byB0aGF0IHRoZSBqb2luZWQgcGx1ZyBmZXN0IHdp bGwgdGFrZSBwbGFjZSBmcm9tIDlBTSB0byAxUE0gaW4gU2Fsb24gQi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SWYgeW91IGNhbm5vdCBiZSBwcmVzZW50IGluIHBlcnNvbiB5b3UgbWF5 IHdhbnQgdG8gZm9sbG93IG9uIHRoZSBhdHRhY2hlZCB3ZWJleDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXNjYWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA2dGlzY2gg W21haWx0bzo2dGlzY2gtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KTxicj4NCjxiPlNlbnQ6PC9iPiBzYW1lZGkgMTkganVpbGxl dCAyMDE0IDE5OjI1PGJyPg0KPGI+VG86PC9iPiA2dGlzY2hAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gWzZ0aXNjaF0gV2ViZXggTWVldGluZyBpbnZpdGF0aW9uOiBKb2luZWQgUGx1Z0Zl c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGVsbG8gLA0KPGJyPg0KPGJyPg0KUGFzY2FsIFRodWJlcnQg aW52aXRlcyB5b3UgdG8gYXR0ZW5kIHRoaXMgb25saW5lIG1lZXRpbmcuIDxicj4NCjxicj4NClRv cGljOiBKb2luZWQgUGx1Z0Zlc3QgPGJyPg0KRGF0ZTogU3VuZGF5LCBKdWx5IDIwLCAyMDE0IDxi cj4NClRpbWU6IDk6MDAgYW0sIEVhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0w NDowMCkgPGJyPg0KTWVldGluZyBOdW1iZXI6IDIwMiAyMzIgMTM2IDxicj4NCk1lZXRpbmcgUGFz c3dvcmQ6IHVucGx1Z2dlZCA8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRvIGpvaW4gdGhlIG9ubGlu ZSBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2aWNlcyEpIDxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KMS4gR28gdG8g PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW04 MGZjNjg0NGY5NzM1NmQ5NWMzMWFlNGNjYTRkZjU5NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW04MGZjNjg0NGY5NzM1NmQ5 NWMzMWFlNGNjYTRkZjU5NjwvYT4NCjxicj4NCjIuIEVudGVyIHlvdXIgbmFtZSBhbmQgZW1haWwg YWRkcmVzcy4gPGJyPg0KMy4gRW50ZXIgdGhlIG1lZXRpbmcgcGFzc3dvcmQ6IHVucGx1Z2dlZCA8 YnI+DQo0LiBDbGljayAmcXVvdDtKb2luIE5vdyZxdW90Oy4gPGJyPg0KPGJyPg0KVG8gdmlldyBp biBvdGhlciB0aW1lIHpvbmVzIG9yIGxhbmd1YWdlcywgcGxlYXNlIGNsaWNrIHRoZSBsaW5rOiA8 YnI+DQo8YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01U SUQ9bTNiMzczOWRmM2IzYTAxNmVkOGYwYTRhOGViZDhlMTE2IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW0zYjM3MzlkZjNiM2Ew MTZlZDhmMGE0YThlYmQ4ZTExNjwvYT4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KQUxFUlQg 4oCTIFBMRUFTRSBSRUFEOiBETyBOT1QgRElBTCBUSEUgVE9MTCBGUkVFIE5VTUJFUlMgRlJPTSBX SVRISU4gVEhFICg0MDgpIE9SICg5MTkpIEFSRUEgQ09ERVMNCjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0K UGxlYXNlIGRpYWwgdGhlIGxvY2FsIGFjY2VzcyBudW1iZXIgZm9yIHlvdXIgYXJlYSBmcm9tIHRo ZSBsaXN0IGJlbG93OiA8YnI+DQotIFNhbiBKb3NlL01pbHBpdGFzICg0MDgpIGFyZWE6IDUyNS02 ODAwIDxicj4NCi0gUlRQICg5MTkpIGFyZWE6IDM5Mi0zMzMwIDxicj4NCjxicj4NCkRpYWxpbmcg dGhlIFdlYkV4IHRvbGwgZnJlZSBudW1iZXJzIGZyb20gd2l0aGluIDQwOCBvciA5MTkgYXJlYSBj b2RlcyBpcyBub3QgZW5hYmxlZCAobm9uLUNpc2NvIHBob25lcykuIOKAnCBJZiB5b3UgZGlhbCB0 aGUgdG9sbC1mcmVlIG51bWJlcnMgd2l0aGluIHRoZSA0MDggb3IgOTE5IGFyZWEgY29kZXMgeW91 IHdpbGwgYmUgaW5zdHJ1Y3RlZCB0byBoYW5nIHVwIGFuZCBkaWFsIHRoZSBsb2NhbCBhY2Nlc3Mg bnVtYmVyLuKAnSBQbGVhc2UgdXNlIHRoZQ0KIGNhbGwtYmFjayBvcHRpb24gd2hlbmV2ZXIgcG9z c2libGUgYW5kIG90aGVyd2lzZSBkaWFsIGxvY2FsIG51bWJlcnMgb25seS4gVGhlIGFmZmVjdGVk IHRvbGwgZnJlZSBudW1iZXJzIGFyZTogKDg2NikgNDMyLTk5MDMgZm9yIHRoZSBTYW4gSm9zZS9N aWxwaXRhcyBhcmVhIGFuZCAoODY2KSAzNDktMzUyMCBmb3IgdGhlIFJUUCBhcmVhLg0KPGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSA8YnI+DQpUbyBqb2luIHRoZSB0ZWxlY29uZmVyZW5jZSBvbmx5IDxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KMS4g RGlhbCBpbnRvIENpc2NvIFdlYkV4ICh2aWV3IGFsbCBHbG9iYWwgQWNjZXNzIE51bWJlcnMgYXQg PGJyPg0KPGEgaHJlZj0iaHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91dC9kb2luZ19idXNpbmVz cy9jb25mZXJlbmNpbmcvaW5kZXguaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9jaXNjby5j b20vZW4vVVMvYWJvdXQvZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5jaW5nL2luZGV4Lmh0bWw8L2E+ DQo8YnI+DQoyLiBGb2xsb3cgdGhlIHByb21wdHMgdG8gZW50ZXIgdGhlIE1lZXRpbmcgTnVtYmVy IChsaXN0ZWQgYWJvdmUpIG9yIEFjY2VzcyBDb2RlIGZvbGxvd2VkIGJ5IHRoZSAjIHNpZ24uDQo8 YnI+DQo8YnI+DQpTYW4gSm9zZSwgQ0E6ICYjNDM7MS40MDguNTI1LjY4MDAgUlRQOiAmIzQzOzEu OTE5LjM5Mi4zMzMwIDxicj4NCjxicj4NClVTL0NhbmFkYTogJiM0MzsxLjg2Ni40MzIuOTkwMyBV bml0ZWQgS2luZ2RvbTogJiM0Mzs0NC4yMC44ODI0LjAxMTcgPGJyPg0KPGJyPg0KSW5kaWE6ICYj NDM7OTEuODAuNDM1MC4xMTExIEdlcm1hbnk6ICYjNDM7NDkuNjE5LjY3NzMuOTAwMiA8YnI+DQo8 YnI+DQpKYXBhbjogJiM0Mzs4MS4zLjU3NjMuOTM5NCBDaGluYTogJiM0Mzs4Ni4xMC44NTE1LjU2 NjYgPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSA8YnI+DQpGb3IgYXNzaXN0YW5jZSA8YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NCjEuIEdvIHRvIDxh IGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbWMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21jPC9hPg0KPGJyPg0KMi4g T24gdGhlIGxlZnQgbmF2aWdhdGlvbiBiYXIsIGNsaWNrICZxdW90O1N1cHBvcnQmcXVvdDsuIDxi cj4NCjxicj4NCllvdSBjYW4gY29udGFjdCBtZSBhdDogPGJyPg0KPGEgaHJlZj0ibWFpbHRvOnB0 aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRAY2lzY28uY29tPC9hPiA8YnI+DQozMy00OS03MjMg MjYzNCA8YnI+DQo8YnI+DQpBZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgcHJvZ3Jh bTogPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBo cD9NVElEPW0yYzM3ZGYzZmVmMGExZjFhY2VjZmE4NTk1MWZmOWQ0OSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tMmMzN2RmM2Zl ZjBhMWYxYWNlY2ZhODU5NTFmZjlkNDk8L2E+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly93d3cud2ViZXguY29tPC9hPiA8YnI+DQo8YnI+DQpDQ1A6JiM0MzsxNDA4NTI1 NjgwMHgyMDIyMzIxMzYjIDxicj4NCjxicj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMgV2ViRXgg c2VydmljZSBpbmNsdWRlcyBhIGZlYXR1cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1 bWVudHMgYW5kIG90aGVyIG1hdGVyaWFscyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmluZyB0aGUg c2Vzc2lvbiB0byBiZSByZWNvcmRlZC4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRv bWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQNCiB0byB0aGUgcmVjb3JkaW5nLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVl dGluZyBob3N0IHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBq b2luIHRoZSBzZXNzaW9uLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5 IGJlIHN1YmplY3QgdG8gZGlzY292ZXJ5IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E045AECD98228444A58C61C200AE1BD842CCD498xmbrcdx01ciscoc_-- From nobody Sat Jul 19 18:07:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547371B2B4A for ; Sat, 19 Jul 2014 18:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCTKFAeKyIjB for ; Sat, 19 Jul 2014 18:07:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803B31B2B49 for ; Sat, 19 Jul 2014 18:07:41 -0700 (PDT) Received: from localhost ([::1]:52372 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X8fb4-0005yD-Px; Sat, 19 Jul 2014 18:07:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca X-Trac-Project: roll Date: Sun, 20 Jul 2014 01:07:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/160#comment:1 Message-ID: <082.f1a77adaeb5d3b87f2992258397fb2b6@trac.tools.ietf.org> References: <067.c837f6a66878301368eb32307147f5d6@trac.tools.ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <067.c837f6a66878301368eb32307147f5d6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, robert.cragie@gridmerge.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/FWuu9f5m7aYLEPWt5CJdefsV8n4 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #160 (security-threats): draft-ietf-roll-security-threats-07--Nits to fix X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 01:07:43 -0000 #160: draft-ietf-roll-security-threats-07--Nits to fix Changes (by mcr@sandelman.ca): * owner: mcr+ietf@sandelman.ca => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From nobody Sat Jul 19 22:07:21 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C6C1B2B69 for ; Sat, 19 Jul 2014 22:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNTaYCx6CK19 for ; Sat, 19 Jul 2014 22:07:08 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04E51A03A4 for ; Sat, 19 Jul 2014 22:07:08 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so5735951oag.27 for ; Sat, 19 Jul 2014 22:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fWyYTSlotFA26EfAagWgQaWDTavBdeI5ETppLlhusKA=; b=Y8KjMXCr3n5j5E133KYYs33YvfbJ+9SItAdaOkAFEB8ztn3LgGr8uccu+0o9RmHD4C W50wWnc6N6w6BwsWAmeysNKREKWL+8FuGlRsw1CbOP00Hqi7o1LxVxjCZImAoJUiS5Fo axkZy8hvFrfOX+1sT24U88arF6Kr90pQxht71e44n4K5Uu+pbZWjGtILN9IF7dWPsZTO HQ/bNJJhvFuOOgR66YiBLPhYU4apAZo3uJXX+hXVnRAEwZ3NNksbVqIlXw/87q7Eo+rx VJFOGK0mve2U3ga7nl+9zR8Em7ZaUWXJt5nmXqTtV0klJX6MQkt2SzW7PUlpiaTInu9m DXAQ== MIME-Version: 1.0 X-Received: by 10.60.34.98 with SMTP id y2mr23528911oei.9.1405832828312; Sat, 19 Jul 2014 22:07:08 -0700 (PDT) Received: by 10.202.175.84 with HTTP; Sat, 19 Jul 2014 22:07:08 -0700 (PDT) Date: Sun, 20 Jul 2014 07:07:08 +0200 Message-ID: From: khelifi nesrine To: roll@ietf.org Content-Type: multipart/alternative; boundary=089e01175d0758627d04fe98f618 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/0jpZnby20Cavwbrk1fQq3ja5KeE Subject: [Roll] pseudo code of repairing mechanism of RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 05:07:18 -0000 --089e01175d0758627d04fe98f618 Content-Type: text/plain; charset=UTF-8 Hi, I want to ask if there is an available pseudo-code of repairing mechanism under RPL? Thanks in advance. -- Nesrine Khelifi --089e01175d0758627d04fe98f618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I want to ask if there is an availa= ble pseudo-code of repairing mechanism under RPL?

= Thanks in advance.

--
=

=C2=A0Nesrine Khelifi
--089e01175d0758627d04fe98f618-- From nobody Sun Jul 20 06:13:59 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603EA1B2C18 for ; Sun, 20 Jul 2014 06:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39EFoWUkPg8J for ; Sun, 20 Jul 2014 06:13:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007731B2C11 for ; Sun, 20 Jul 2014 06:13:54 -0700 (PDT) Received: from localhost ([::1]:53667 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X8qw2-0002cV-Kx; Sun, 20 Jul 2014 06:13:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca X-Trac-Project: roll Date: Sun, 20 Jul 2014 13:13:50 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/160#comment:2 Message-ID: <082.add9611b14eb0b1eebbeb830816ff41e@trac.tools.ietf.org> References: <067.c837f6a66878301368eb32307147f5d6@trac.tools.ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <067.c837f6a66878301368eb32307147f5d6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, robert.cragie@gridmerge.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/JvyF0a1Uyr3iuIkf2TGDdte-OoQ Cc: roll@ietf.org Subject: Re: [Roll] [roll] #160 (security-threats): draft-ietf-roll-security-threats-07--Nits to fix X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:13:56 -0000 #160: draft-ietf-roll-security-threats-07--Nits to fix Changes (by mcr@sandelman.ca): * status: assigned => closed * resolution: => fixed -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: closed Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From nobody Sun Jul 20 12:24:32 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364F61B29BD; Sun, 20 Jul 2014 12:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLD1_ts4OHKO; Sun, 20 Jul 2014 12:24:24 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389381B29BE; Sun, 20 Jul 2014 12:24:24 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s6KJOMKM019501; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s6KJOMr6012759; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id EAA12758; Mon, 21 Jul 2014 04:24:22 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s6KJOMYl002294; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6KJOMJ5001756; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: from [133.199.16.43] (ivpn-1-43.mobile.toshiba.co.jp [133.199.16.43]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 4FA4C97D10; Mon, 21 Jul 2014 04:24:21 +0900 (JST) Message-ID: <53CC1763.3010309@toshiba.co.jp> Date: Mon, 21 Jul 2014 04:24:19 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , Michael Richardson References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> <7303.1405801664@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/mBiNKoRsZvkGirGHTxc82heatTw Cc: "dhcwg@ietf.org" Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:24:27 -0000 Hi Ted, Thanks for your suggestion. As I wrote to Bernie, I'll update the draft with standard data types. Regards, Yusuke (2014-07-20 6:20), Ted Lemon wrote: > Okay, thanks. I think compressing is saving three bytes; this is noise. Please don't do that. We need to define a fragment type for unsigned short floating point; that should be a quick, simple DHCP document. The rest of the document looks fine at first glance, but as you've no doubt detected, I didn't read it before asking about the previous thing and I still haven't read it closely, so don't take that as a claim that I won't comment further later when I have more time (whenever that magic day comes). > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Mon Jul 21 03:37:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569451B2D7D; Mon, 21 Jul 2014 03:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WfUyrFOjRl0; Mon, 21 Jul 2014 03:37:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A851B2D91; Mon, 21 Jul 2014 03:37:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721103707.12192.70233.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 03:37:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xpLTANpsKoDKBW9gRWabkTx7dbU Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 10:37:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-02.txt Pages : 9 Date : 2014-07-21 Abstract: This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 03:48:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76E51B2B8E; Mon, 21 Jul 2014 03:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLu5o43mlgCF; Mon, 21 Jul 2014 03:48:44 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77AA1B2D4C; Mon, 21 Jul 2014 03:48:43 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s6LAmeoU018789; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s6LAmeLd020015; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA20014; Mon, 21 Jul 2014 19:48:40 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s6LAmeC7020114; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6LAmenw008201; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: from [133.199.17.23] (ivpn-2-23.mobile.toshiba.co.jp [133.199.17.23]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C0C6597CF0; Mon, 21 Jul 2014 19:48:38 +0900 (JST) Message-ID: <53CCF001.7050400@toshiba.co.jp> Date: Mon, 21 Jul 2014 19:48:33 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , "dhcwg@ietf.org" References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> <7303.1405801664@sandelman.ca> <53CC1763.3010309@toshiba.co.jp> In-Reply-To: <53CC1763.3010309@toshiba.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/sm6zOmt6qsdRLPw2NDXymIDh3sk Subject: [Roll] Updated to -02 MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-02.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 10:48:46 -0000 Hi, With valuable inputs from DHC working group, I updated the format and removed the tricky short float values. ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-02.txt Pages : 9 Date : 2014-07-21 Abstract: This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. ---- Thanks, Yusuke From nobody Mon Jul 21 06:48:57 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD51A0043; Mon, 21 Jul 2014 06:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvDDqqdo8xVd; Mon, 21 Jul 2014 06:48:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CA31B2E0F; Mon, 21 Jul 2014 06:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721134502.18247.42831.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 06:45:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/EVlwIz9PZCE1ODVBjBD0wuCjCSY Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:48:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL) Authors : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Michael Richardson Filename : draft-ietf-roll-security-threats-08.txt Pages : 39 Date : 2014-07-21 Abstract: This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-security-threats-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-security-threats-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 12:52:08 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F6F1B2BE2 for ; Tue, 22 Jul 2014 12:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDjh5xYYpucy for ; Tue, 22 Jul 2014 12:52:04 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FCB1B2BB7 for ; Tue, 22 Jul 2014 12:52:04 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so311883vcb.7 for ; Tue, 22 Jul 2014 12:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Hont8PQMjuM5YC/j1sjkxwBqdtV5KYjX9BWzmbFsfdI=; b=CdwckXGiMZ1tXkDS5g9Nwqm6mvOT27jlCX2AVrZVTyTK7TpiTraE7JWM/0HNu/Ihgb IOhVmDz5iBQsoRR80idoTRbfwtCbGcxb8WIup+7PQFny+/IuDOSvMl/qPpuXP37J8owA 0Pxh10aMnkGSjM2vrxwvyKsS+HZcorMzFZSa4K2aF4VsTTJs+iz+olAWr4kBNlyXnOC0 pXA7WoBkBTDtKBuOAUd/do6uPh7pKE6XIGfWHeYS4sUBJMC9xwHzk0wneBMrgyijY7Ss 9+xHYhy+M72fRDq34qCmyiSnd6iJrwjtF7h9TNVnG3j6gPN+Xau4KhQtKx5Uo0COUfZV KDLg== MIME-Version: 1.0 X-Received: by 10.52.154.106 with SMTP id vn10mr29069833vdb.36.1406058723320; Tue, 22 Jul 2014 12:52:03 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Tue, 22 Jul 2014 12:52:03 -0700 (PDT) Date: Tue, 22 Jul 2014 15:52:03 -0400 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=bcaec51d2f48be79ce04fecd8eb8 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/jlq-cjXVS_4YD17U4JpdiFuS_QY Cc: Michael Richardson Subject: [Roll] Slides - IETF 90 - available to download - Final version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:52:05 -0000 --bcaec51d2f48be79ce04fecd8eb8 Content-Type: text/plain; charset=UTF-8 Hi, Please find the final slides for the meeting on Wednesday: http://www.ietf.org/proceedings/90/slides/slides-90-roll-5.pdf Please any comment are very welcome. Thank you and Kind Regards, Michael & Ines 2014-06-16 1:18 GMT-04:00 Ines Robles : > Hi, > > Please find the slides for the meeting in this link, we think it is better > have a single doc with all the slides: > > http://www.ietf.org/proceedings/90/slides/slides-90-roll-0.pdf > > These slides are not definitive, please let us know if you find something > that should be corrected before the meeting in Toronto. > > We will keep you posted about the last version. > > Thank you and Kind Regards, > > Michael & Ines. > --bcaec51d2f48be79ce04fecd8eb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the final slides for th= e meeting on Wednesday:=C2=A0http://www.ietf.org/proceedings/90/slides/slid= es-90-roll-5.pdf

Please any comment are very welcome.

Thank you and Kind Regards,

Michael & = Ines=C2=A0


2014-06-16 1:= 18 GMT-04:00 Ines Robles <mariainesrobles@googlemail.com= >:
Hi,

Plea= se find the slides for the meeting in this link, we think it is better have= a single doc with all the slides:


These slides are not definitive, please let us kn= ow if you find something that should be corrected before the meeting in Tor= onto.

We will keep you posted about the last versi= on.

Thank you and Kind Regards,

Michael & Ines.

--bcaec51d2f48be79ce04fecd8eb8-- From nobody Tue Jul 22 19:33:22 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A051A0217; Tue, 22 Jul 2014 19:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAiTZfjDi4gH; Tue, 22 Jul 2014 19:33:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2FE1ADDC6; Tue, 22 Jul 2014 19:33:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723023318.16045.93956.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 19:33:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ybP9xAY1Pm_ZeAwCLoLPL5miMNk Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 02:33:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks Authors : Daniel Popa Matthew Gillmore Laurent Toutain Jonathan Hui Kazuya Monden Filename : draft-ietf-roll-applicability-ami-09.txt Pages : 23 Date : 2014-07-22 Abstract: This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-ami-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-ami-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 19:35:09 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D711A0AAE for ; Tue, 22 Jul 2014 19:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBKDpektraKo for ; Tue, 22 Jul 2014 19:35:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19DB1A0217 for ; Tue, 22 Jul 2014 19:35:01 -0700 (PDT) Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BY2PR04MB805.namprd04.prod.outlook.com (10.141.224.144) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 02:35:00 +0000 Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 02:35:00 +0000 From: "Popa, Daniel" To: "roll@ietf.org" Thread-Topic: New Version Notification for draft-ietf-roll-applicability-ami-09.txt Thread-Index: AQHPph57ZlNVoIv18EybH17wefJ2bJus8QKg Date: Wed, 23 Jul 2014 02:34:59 +0000 Message-ID: <16228888f05c432eaa98835cd150585f@BY2PR04MB807.namprd04.prod.outlook.com> References: <20140723023318.16045.32063.idtracker@ietfa.amsl.com> In-Reply-To: <20140723023318.16045.32063.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [206.47.221.210] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377424004)(199002)(189002)(377454003)(229853001)(54356999)(4396001)(15975445006)(64706001)(105586002)(2351001)(92566001)(46102001)(83322001)(76176999)(74662001)(76482001)(15202345003)(76576001)(99396002)(110136001)(19580405001)(101416001)(50986999)(74316001)(19580395003)(85306003)(107046002)(33646002)(66066001)(83072002)(2656002)(95666004)(81542001)(106356001)(80022001)(86362001)(81342001)(77982001)(85852003)(20776003)(74502001)(99286002)(106116001)(79102001)(87936001)(21056001)(31966008)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR04MB805; H:BY2PR04MB807.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: itron.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/y2J_3LjSTJ93vN9PzSrZNZ2iVac Cc: "'Michael Richardson \(mcr+ietf@sandelman.ca\)'" , "Ines Robles \(mariainesrobles@googlemail.com\)" Subject: [Roll] TR: New Version Notification for draft-ietf-roll-applicability-ami-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 02:35:05 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCkVudm95w6nCoDogV2Vk bmVzZGF5LCBKdWx5IDIzLCAyMDE0IDQ6MzMgQU0NCsOAwqA6IENpc2NvLUpvaG5hdGhhbiBIdWk7 IEthenV5YSBNb25kZW47IENpc2NvLUpvaG5hdGhhbiBIdWk7IEdpbGxtb3JlLCBNYXR0aGV3OyBM YXVyZW50IFRvdXRhaW47IExhdXJlbnQgVG91dGFpbjsgR2lsbG1vcmUsIE1hdHRoZXc7IEthenV5 YSBNb25kZW47IFBvcGEsIERhbmllbDsgUG9wYSwgRGFuaWVsDQpPYmpldMKgOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC1hcHBsaWNhYmlsaXR5LWFtaS0wOS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1yb2xsLWFwcGxpY2FiaWxp dHktYW1pLTA5LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW5pZWwg UG9wYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1p ZXRmLXJvbGwtYXBwbGljYWJpbGl0eS1hbWkNClJldmlzaW9uOgkwOQ0KVGl0bGU6CQlBcHBsaWNh YmlsaXR5IFN0YXRlbWVudCBmb3IgdGhlIFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBh bmQgTG9zc3kgTmV0d29ya3MgKFJQTCkgaW4gQU1JIE5ldHdvcmtzDQpEb2N1bWVudCBkYXRlOgky MDE0LTA3LTIyDQpHcm91cDoJCXJvbGwNClBhZ2VzOgkJMjMNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtYXBwbGljYWJp bGl0eS1hbWktMDkudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLWFwcGxpY2FiaWxpdHktYW1pLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1hcHBsaWNhYmls aXR5LWFtaS0wOQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtcm9sbC1hcHBsaWNhYmlsaXR5LWFtaS0wOQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIFJQTCBpbiBBZHZh bmNlZCBNZXRlcmluZw0KICAgSW5mcmFzdHJ1Y3R1cmUgKEFNSSkgbmV0d29ya3MuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jul 23 05:37:56 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B6A1A01C3 for ; Wed, 23 Jul 2014 05:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4icmlcUEcdQb for ; Wed, 23 Jul 2014 05:37:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FA51A011C for ; Wed, 23 Jul 2014 05:37:53 -0700 (PDT) Received: from localhost ([::1]:58281 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9vnp-0005Dn-UA; Wed, 23 Jul 2014 05:37:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 23 Jul 2014 12:37:49 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/158#comment:2 Message-ID: <082.5ef2f3410f3f933bad00b4f5e71795f2@trac.tools.ietf.org> References: <067.fdecb6fad4434045459c5bca247c467e@trac.tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <067.fdecb6fad4434045459c5bca247c467e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/iHAJVwwp8tPa29PWeSPLFLgJN44 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #158 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - new MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:37:54 -0000 #158: mpl-parameter-configuration-00 - new MPL domain Comment (by mariainesrobles@gmail.com): Version 01 change section 2.4 from "..the node SHOULD join the MPL domain..." to "...the node MAY join the MPL domain..." -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | yusuke.doi@toshiba.co.jp Type: defect | Status: new Priority: major | Milestone: Component: draft-doi-roll-mpl- | Version: parameter-configuration | Resolution: Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 23 05:45:39 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7061A0145 for ; Wed, 23 Jul 2014 05:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpWzC7YPqzO6 for ; Wed, 23 Jul 2014 05:45:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8471A011C for ; Wed, 23 Jul 2014 05:45:36 -0700 (PDT) Received: from localhost ([::1]:58563 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9vvL-0006nt-7x; Wed, 23 Jul 2014 05:45:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 23 Jul 2014 12:45:35 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/159#comment:2 Message-ID: <082.5f2f22db6a2ebd38a345e612c475b54a@trac.tools.ietf.org> References: <067.c7da094778f4c5d6eac57429dda91b84@trac.tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <067.c7da094778f4c5d6eac57429dda91b84@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/YhxZojPCjIJauB0mtsu3vkayZZQ Cc: roll@ietf.org Subject: Re: [Roll] [roll] #159 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Format to encode timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:45:37 -0000 #159: mpl-parameter-configuration-00 - Format to encode timers Comment (by mariainesrobles@gmail.com): From Yusuke Doi - ROLL Session 07-23-2014 Version 02 "Feedbacks from DHC wg – Option format is simplified (but unaligned) – Short floating point is removed and TUNIT is added to describe precision of timers" -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | yusuke.doi@toshiba.co.jp Type: defect | Status: new Priority: major | Milestone: Component: draft-doi-roll-mpl- | Version: parameter-configuration | Resolution: Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 23 06:05:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78AA1ABB20 for ; Wed, 23 Jul 2014 06:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_11ThVrdny4 for ; Wed, 23 Jul 2014 06:05:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBED81B2868 for ; Wed, 23 Jul 2014 06:05:14 -0700 (PDT) Received: from localhost ([::1]:59295 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9wEB-000739-4O; Wed, 23 Jul 2014 06:05:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 23 Jul 2014 13:05:03 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/136#comment:4 Message-ID: <082.29a9d01cc140cbc55ddd8873c728b0d8@trac.tools.ietf.org> References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: daniel.popa@itron.com, johui@cisco.com, kazuya.monden.vw@hitachi.com, laurent.toutain@telecom-bretagne.eu, maria.ines.robles@ericsson.com, , matthew.gillmore@itron.com, mcr+ietf@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/w94ZNYl5CThRR1N0kE8Ov9v0ewI Cc: roll@ietf.org Subject: Re: [Roll] [roll] #136 (applicability-ami): - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:05:17 -0000 #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Comment (by mariainesrobles@gmail.com): draft-ietf-roll-security-threats is not mentioned in version 09 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 23 06:19:58 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029E61B28F7 for ; Wed, 23 Jul 2014 06:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcHwlOGc8gWY for ; Wed, 23 Jul 2014 06:19:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73111B28E9 for ; Wed, 23 Jul 2014 06:19:54 -0700 (PDT) Received: from localhost ([::1]:60522 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9wSN-0007B1-Cx; Wed, 23 Jul 2014 06:19:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 23 Jul 2014 13:19:43 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/136#comment:5 Message-ID: <082.9293b9c0f074f59ac64c6c3972af6d19@trac.tools.ietf.org> References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: daniel.popa@itron.com, johui@cisco.com, kazuya.monden.vw@hitachi.com, laurent.toutain@telecom-bretagne.eu, maria.ines.robles@ericsson.com, , matthew.gillmore@itron.com, mcr+ietf@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/quzycSUgFRskdVjHoc89-YKL7zU Cc: roll@ietf.org Subject: Re: [Roll] [roll] #136 (applicability-ami): - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:19:56 -0000 #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Comment (by mariainesrobles@gmail.com): Version 08 describes IEEE MAC sub-layer Security Features (7.2.3.) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 23 06:30:46 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F106A1B28E9 for ; Wed, 23 Jul 2014 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAa8vNM_KXDD for ; Wed, 23 Jul 2014 06:30:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF231A0ADC for ; Wed, 23 Jul 2014 06:30:43 -0700 (PDT) Received: from localhost ([::1]:32830 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9wcu-0005vZ-Eu; Wed, 23 Jul 2014 06:30:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 23 Jul 2014 13:30:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/135#comment:1 Message-ID: <082.45f0822694b187bdd00a19c6c9c695bb@trac.tools.ietf.org> References: <067.d2b714cc0ac70ebe3021413da1fe7ea3@trac.tools.ietf.org> X-Trac-Ticket-ID: 135 In-Reply-To: <067.d2b714cc0ac70ebe3021413da1fe7ea3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: daniel.popa@itron.com, johui@cisco.com, kazuya.monden.vw@hitachi.com, laurent.toutain@telecom-bretagne.eu, maria.ines.robles@ericsson.com, , matthew.gillmore@itron.com, mcr+ietf@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/maBcXVVtEoogIdpV28GjGcIG6hU Cc: roll@ietf.org Subject: Re: [Roll] [roll] #135 (applicability-ami): Point to the Security Considerations section of RFC 6550 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:30:45 -0000 #135: Point to the Security Considerations section of RFC 6550 Comment (by mariainesrobles@gmail.com): Version 09 does not mention RFC 6550 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 23 06:33:30 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9779E1B295F for ; Wed, 23 Jul 2014 06:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhRrmnglPK1M for ; Wed, 23 Jul 2014 06:33:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62CE11B295E for ; Wed, 23 Jul 2014 06:33:24 -0700 (PDT) Received: from localhost ([::1]:32969 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9wfV-0006S2-6S; Wed, 23 Jul 2014 06:33:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 23 Jul 2014 13:33:17 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/137#comment:1 Message-ID: <082.d7ac60be199d3c96cc2185e24640b661@trac.tools.ietf.org> References: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 In-Reply-To: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: daniel.popa@itron.com, johui@cisco.com, kazuya.monden.vw@hitachi.com, laurent.toutain@telecom-bretagne.eu, maria.ines.robles@ericsson.com, , matthew.gillmore@itron.com, mcr+ietf@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QPDHaexTAJ-c8LtWjybTnC7tZ0k Cc: roll@ietf.org Subject: Re: [Roll] [roll] #137 (applicability-ami): - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:33:28 -0000 #137: - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments Comment (by mariainesrobles@gmail.com): Version 09 addes initial and incremental deployments. No mention FCAPS model -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 23 10:50:10 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6F51B2A17 for ; Wed, 23 Jul 2014 10:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZyAmUi1xVx5 for ; Wed, 23 Jul 2014 10:49:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEF51B2BFF for ; Wed, 23 Jul 2014 10:49:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723174926.22640.77751.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 10:49:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/N5tfqfQWBWNxRkBLuuMIvuoNRL0 Subject: [Roll] Milestones changed for roll WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:49:49 -0000 Changed milestone "submit REVISED thread-analysis document based upon security directorate review to IESG.", resolved as "Done". URL: http://datatracker.ietf.org/wg/roll/charter/ From nobody Wed Jul 23 12:18:58 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5DC1A01E8 for ; Wed, 23 Jul 2014 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYLhJ5ynFXxD for ; Wed, 23 Jul 2014 12:18:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BA91B293C for ; Wed, 23 Jul 2014 12:18:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723191855.9712.59897.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 12:18:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xZaqm433XQzmsBp-T2HsSIQcRJo Subject: [Roll] Milestones changed for roll WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:18:56 -0000 Changed milestone "Evaluate WG progress, recharter or close", resolved as "Done". URL: http://datatracker.ietf.org/wg/roll/charter/ From nobody Wed Jul 23 12:38:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B54F1A033A for ; Wed, 23 Jul 2014 12:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsGB4Z9h0CR1 for ; Wed, 23 Jul 2014 12:38:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2803D1B2882 for ; Wed, 23 Jul 2014 12:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723193814.17484.87203.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 12:38:14 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/roll/AXcO3sbAEQKuW19oIgWDxOO6HGo Subject: [Roll] Milestones changed for roll WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:38:16 -0000 Changed milestone "WG to joint-LC using flow-label for RPL with 6man", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/roll/charter/ From nobody Thu Jul 24 07:46:03 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6B41A03BB for ; Thu, 24 Jul 2014 07:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.609 X-Spam-Level: *** X-Spam-Status: No, score=3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, MIME_NO_TEXT=2, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=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 pnlVxzkTaq2u for ; Thu, 24 Jul 2014 07:45:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7851A03B7 for ; Thu, 24 Jul 2014 07:45:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F9EC20012 for ; Thu, 24 Jul 2014 10:47:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B192D63B0E; Thu, 24 Jul 2014 10:45:56 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9980163B0A for ; Thu, 24 Jul 2014 10:45:56 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/w0Y_PNrh_5ihCcdolL-696bBC5Q Subject: [Roll] DRAFT minutes from IETF90 meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:46:01 -0000 --=-=-= many thanks to Thomas. Please /XXX for pieces that might need comment, here they are: - Peter van der Stock indicated that you need control over . Changed SHOULD to MAY - [Pvds] can you send e-mail? XXXX (was re: Autonomic/ANIMA) I'm not sure what "poipoi" means. 1300-1500 EDT Wednesday Afternoon Session I Territories room Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/ Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-roll Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/ietf907.m3u ROLL (Routing Over Low Power and Lossy Networks) Agenda ------ - State of all drafts (5min) - Related Internet-Drafts - State of all Issues (3min) - Updates to Milestones, Schedule and Practice (5min) - Feedback from Plugfest Event (5min) - Updates on: draft-ietf-roll-security-threats (10min) - Updates on: draft-ietf-roll-mpl-parameter-configuration (15min) - Updates on: draft-ietf-roll-admin-local-policy (15min) - Updates on: draft-ietf-roll-applicability-template. (5min) - Updates on: draft-ietf-roll-applicability-ami (10min) - Updates on: draft-thubert-6man-flow-label-for-rpl (15min) - Open floor (15 minutes) Minutes ------- - _[1300]_ Meeting starts - **[Ines]** starts the meeting - reminds note well - meetecho available, minutes taken, Jabber as well - presents agenda - _[1302]_ State of all drafts **(poipoi)** - Ines reminds status of drafts on sldies - Ines presents related I-D not adopted yet - Ines presents open tickets (see slides). Some work needed on the open tickets. - Ines presents milestones. Industrial applicability is behind. -Ines: need to decide whether nee to recharter or close. After work on MPL done, - Related Internet-Drafts **(poipoi)** - poipoi - _[1305]_ State of all Issues **(poipoi)** - poipoi - _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)** - poipoi - _[1315]_ Feedback from Plugfest Event **(poipoi)** - Thomas presents - Updates on: draft-ietf-roll-security-threats **(Michael Richardson)** - security applicability review. There was some lack of understanding amoung reviewers about the relationship between documents. After some voice communications, we agreed that we needed to be more explicit about the relatinoship to other documents. Peter van der Stock proposed some text which is now in different documents - Michael presents threats document - secu area review about sec doc (september 2013). Very good reivew. Some tickets were opened. Lots got fixed. Robert Cragie found innaccuracies and things tha didn't make sense. Tickets got opened and fixed The -08 uploaded on Monday July 21. Use the diff tool to see the changes. This document went through WGLC in Feb. Robert Cragie looked at it before sending to Adrian. Button pushed on Monday!!!!, should be discussed at IESG soon. This has been a long (3 year) process. Will be nice to have done. - one of the things that came up is that we have a number of messages in ROLL which are important and multicast. From DICE, we know that secuirty multicast is tricky. With symmetric keying, members can impersonate. Pieces in ROLL are not as strong as they could be as a result. -We clarified some of the text. Affects people that have a group-shared L2 key which is the same across the entire network. If you have a L2 master key from which link messags are derived, you can do something different. Ultimately, when multicast, you need to use key that all can read. This is something we clarified. - although DISare multicast, it's a "please answer me". The effect is that a timer goes faster. Not a huge deal if impersonated. - DIOs, if they are impersonated, that's an issue. One of the defenses is that is to unicast a DIS back, so mote sends a DIO again. There is a workaround for the paranoid. (Ines reminds about blue sheets) - Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke Doi)** - draft tp [ropose DHLC option to configureMPL - idea: control MPL. Used in smart meter network. Intended for slow update of MPL forwarded. Because MPL trickle algo has control between network usage and MPLlatency,this is a tradeoff. -parameter should be modifiable. - updated the draft to -01 weeks before the IETF meeting. Asking ROLL and DHC WG for feedback. DHC gave feedback. -02 on Monday. - operational considerations were added. What happens when MPL parameters were changes when MPL network is running - Peter van der Stock indicated that you need control over . Changed SHOULD to MAY - Asks WG for feedback. Please give review on these sentences -last week, lots of feedback from DHC. Most concern idea to make timer in floating point. Didn't like that. Changed the format, simplified. - Yusuke presents the format of the packets. the unit of the time is added to the packet. e.g.of tunit is 100,timer is 100ms. timers in uint16 - [MR] like floating point, but easily absorbed? - [YD] encoding is simple - [MR] for unknown options on DHCP server,people will have to calculate the hex anyway... - [YD] believe almost all implementers don't need to worry about this. Wrote Python code to generate this - mostly clients have to worry about this - very simple and straight forwards. Needs experience and feedback on range fo timers - current specification is only able to go up to 4.6 hours. Not sure if enough for all of usages, including expiration timers. If we need larger duration, need to think again on these timers - message: please give meyour feedback. - - Ines asks to read the drafts and comment on ML - _[1325]_ Updates on: draft-ietf-roll-admin-local-policy **(Peter van der Stok)** - draft is about having admin local be automatically determined - multiple: realm-local scope, link-local and admin-local - different topologies possible - linklocal scope: automatically determined, single hop -real: local: automatically, determined by L2 - admin-local: multiple hop, include different L2 networks. - wish is that it would be automatically discovered - idea is that we have 2 router: one standard, and one router has MPL router with MPL forwarded. They all subscribe to ALL_MPL_FORWARDER scope 3 and 4 - about MPL routers, assuming R1 and R2, assuming they have 2 mesh networks What we want to do is have an MPL scope which includes mesh networks but excludes - introduce boolean flag call MPL blocked. - we use protocol to determine whether should be true or false - start with MPLlock false. at least every hour, send an MPL message to MPL_FORWARDEDS_SCOPE. If no get message back, no interested nodes on that line, - query for nodes are interested, if none, close and don't use - result is that some interfaces are enabled (to the mesh), disabled (to the Northbound) - allows to automatically determine MPL zone -if you have an egde router, you should false interface to block - [Pascal]flow reminds in autonomic, see BoF.Encourages to ANIMA. Probably you could propose this there. - [Pvds] can you send e-mail? XXXX - [Michael] could you derive the 1h period, i.e. 3 Imax. If it can't maybe you have a new parameters forthat other doc. - [Pvds] good suggested - need also security section - _[1400]_ Updates on: draft-ietf-roll-applicability-template. - see beginning - Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2 - [Micheal] which issues are open? - [Daniel] open tickets: - #135, missed pointer to security section of RFC6550 - #136 add a section on security consideration when RPL security mechanisms are not used - #137 incorporate a model for initial and incremental deployments. Added section 9.1. and 9.2. For #136 and #137 will ask the WG to what we can change in the draft on what we can change - [Michael] excellent - _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poipoi)** - when started RPL, idea what to transport Hop by hop in flow label. 6man was redefining how it wouldoperate. At roll, we created hop by hop header in RFC6583. Header cannot be compressed - if a frame is coming from outside the RPL domain, you need to encapsulate the packet in IP-in-IP to be able to send back ICMP error and be able to strip it - these are many bit that we don't want to 802.15.4-2006 MAC - when worked in ISA100.11a, worked hard to eliminate in single bit. Real war to remove UDP checksum. Just for 2 bytes. This was key to the adoption of 6LoWPAN. - here, we are talking about 5+ octets: not acceptable - what important in 6282 compressed in the 2 bits which indicates how 6LoWPAN compresses the flow label and traffic class. we can have flow label with or without DSCP - proposed encoding fits in the 20 bits of the flow label. We are to replace 5 bytes by 20 bits. Rank expressed as 8 bites. You need to have a deployment with a min hop of 256. -[Michael]you are using upper 8 bits of rank? - [PT] yes. You can compress the rank in single octet. Described in OF0, operates wih minhop rank of 256 - RPL was prepared for this. Text says that 6583 is only one was. WE went to ROLL and 6man with this. Brian Carpenter has good response. Idea is to have a WGLC in this group, then a confirmation WGLC from 6man to make sure they agree. - if a packet has to come from the outside, it's responsibility of the root to add flow label that makes sense - Adrian was help out - draft has been out there for year. - [MR] feeling is that this is something we should adopt and seems that we can close to WGLC even with this document. Pascal, agree? - [PT] yes, different revisions from different WGs - [MR] is there a technical reason to adopt before publshing? - [Adrian] yes you can, the WG can support a draft with a name that doesn't start with WG name. People who think you should not be working - [Michael] will write line in charter? Will talk to 6man chairs to make sure - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair of 802.15, there is a reason why we don't haev longer packets. Shorter packets means less energy and better probability. Both hats say that this is what we need - [Pascal] we have running code for thos, Xavi demonstration de draft on OpenWSN implementation. Screenshot indicate wireshark,. You don't have a H2H header, was implemented very rapidly in OpenWSN - _[1448]_ Open floor **(poipoi)** - Ines asks AOB - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client can be a leaf in a RPLnetwork. Today, all devices have to have code specific to RPL. A better idea is that you have what is necessary in 6LoWPAN, so that6LoPWAN device can be a lieaf of a RPL network. THere is a need for a classical IP host and moile hist. Invite you to 6lo. - as we work on 6TiSCH, there is a case where a node moves. We would have work on how to clean upstate route. Aswechartered? - [MR] cleaning up stale motes is in charter, but depends on milestones. Let's take to ML to have a better understanding on what this means. The question is what the impact is on node which don' have the code. - [Pascal] additional functionality =[MR] then this might fit in maintenance. - [MR]any other elements in open mic? - [Peter] will there be any other ROLL meetrings? =- [MR] opinion is that not in Honolulu. We have the home automation, threads, and AMI document which seems close to done. Unless we do somethng that expands the charter, don't see a reason to meet again before closing the WG. Of course, AD could put WG in maintenant mode. Maybe will becomes controversial and we need F2F meeting. - [PT]what would help you make that decision? 6TiSCH might come up with elements, and we would need ROLL to be there. - [MR]good idea, send question. We could go in hibernation and resume when needed. - [PT] plan is to fire a number of drafts, and when - [MR] better now than in december - [Ultich] personally, don't feel 6lo is right WG because not always RPL. - [MR] we could go to the routing Area WG - [Adrain] good point. It's ok for WG to say that shut down. It's nicer to close the WG and create a new WG when needed. Not a good idea to have WG sitting around. AD can sponsor documents. Do we need a forum for discussion and driving the work? If yes, we'll create a spacefor it. - [Ines] there were e-mails about open topics. We need to work on issues before rechartering/closing. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9EcIoCLcPvd0N1lAQJyeAgAsMDgBrUY6W0XeXF0MOc45IS06G31QghH Fs0oGsJWFrd7IbV9QBzWbC0tWEIsv7ZU1UTmc2kMU5bZxHcZGMZUzOW6xnkZPp1T 76XlSI0LO8QxhROnuVrfdyXi8x3CqNjUgBmwA3GPpqHrnHHawYwfpTBXc7t/5w4P iyNrttW4g/bmy5mobffxQ6sDyw6BI8bf0Yt3UzzQh94UK6Z6Gy7D6ZLD1htbyBNe 7k+LN9bzltLwlVQ61VdwacqduZhGGrujSwOOKn+9P8QkL92HVCpZyJm9FMS/vc0P yKL88Q8G7r3GmfyOtvbQJejTHAEHXq6KZfgJuN/1JBLFIEGsyVri3g== =dDfS -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 24 08:02:45 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72171A03D6 for ; Thu, 24 Jul 2014 08:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.224 X-Spam-Level: ** X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, SPF_PASS=-0.001, WEIRD_PORT=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 bTrGA9sK7d4Y for ; Thu, 24 Jul 2014 08:02:39 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04AB1A03F7 for ; Thu, 24 Jul 2014 08:01:53 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so3786666pde.23 for ; Thu, 24 Jul 2014 08:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ZAsCg+53bNBF/ytDmMSdMhNA942O9jJXA4Uou2ZfKzc=; b=UxXuUqxEBOkNce3prsYAxTSMNCBYeo6F3KRl6tlQOEgQmeIZ7pGIjdg3YUGX9ipgm3 8LN4hkOPJMB8rmmPom4oFQqj47C0xHZCql3WfFvwtEJPOytF5hAm3k+gjLB6rIo1qxjZ 3R8OVk9bPrbhXT3f/g0cIKG9wxG2Dipv+1ot54C61yp33P48tznr/ubOAeDZ/YQWLiS+ OBh6y926Bcs6+e2petkMgyq6kTSF4l0MTPcnVucX6H5pI1AjMNWrZUuxb2an+pBPu4Tj +7A+ihma12e0A10J1cWu+D+AHQyqLxXA8Jx6WR+unRVQynddOcmAroHPPB1OGbd7A8kt eQaw== X-Received: by 10.68.68.133 with SMTP id w5mr3277410pbt.166.1406214113175; Thu, 24 Jul 2014 08:01:53 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Thu, 24 Jul 2014 08:01:32 -0700 (PDT) In-Reply-To: <13664.1406213156@sandelman.ca> References: <13664.1406213156@sandelman.ca> From: Thomas Watteyne Date: Thu, 24 Jul 2014 11:01:32 -0400 X-Google-Sender-Auth: K_JJx_qSrEgdyaY_L9NN6IPavRg Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c3e352b1af9104fef1bc60 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ernYsi0oB2V-zoA7sZb49GfCxAg Subject: Re: [Roll] DRAFT minutes from IETF90 meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:02:43 -0000 --001a11c3e352b1af9104fef1bc60 Content-Type: text/plain; charset=UTF-8 Michael, These are the raw notes at the end of the meeting. "poipoi" is just a placeholder. Thomas On Thu, Jul 24, 2014 at 10:45 AM, Michael Richardson wrote: > > many thanks to Thomas. Please /XXX for pieces that might need comment, > here > they are: > - Peter van der Stock indicated that you need control over . > Changed SHOULD to MAY > > - [Pvds] can you send e-mail? XXXX > (was re: Autonomic/ANIMA) > > > I'm not sure what "poipoi" means. > > > 1300-1500 EDT Wednesday Afternoon Session I > Territories room > > Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/ > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-roll > Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll > Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/ietf907.m3u > > ROLL (Routing Over Low Power and Lossy Networks) > > Agenda > ------ > > - State of all drafts (5min) > - Related Internet-Drafts > - State of all Issues (3min) > - Updates to Milestones, Schedule and Practice (5min) > - Feedback from Plugfest Event (5min) > - Updates on: draft-ietf-roll-security-threats (10min) > - Updates on: draft-ietf-roll-mpl-parameter-configuration (15min) > - Updates on: draft-ietf-roll-admin-local-policy (15min) > - Updates on: draft-ietf-roll-applicability-template. (5min) > - Updates on: draft-ietf-roll-applicability-ami (10min) > - Updates on: draft-thubert-6man-flow-label-for-rpl (15min) > - Open floor (15 minutes) > > Minutes > ------- > > - _[1300]_ Meeting starts > - **[Ines]** starts the meeting > - reminds note well > - meetecho available, minutes taken, Jabber as well > - presents agenda > > - _[1302]_ State of all drafts **(poipoi)** > - Ines reminds status of drafts on sldies > - Ines presents related I-D not adopted yet > - Ines presents open tickets (see slides). Some work needed on the open > tickets. > - Ines presents milestones. Industrial applicability is behind. > > -Ines: need to decide whether nee to recharter or close. > After work on MPL done, > > - Related Internet-Drafts **(poipoi)** > - poipoi > - _[1305]_ State of all Issues **(poipoi)** > - poipoi > - _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)** > - poipoi > - _[1315]_ Feedback from Plugfest Event **(poipoi)** > - Thomas presents > - Updates on: draft-ietf-roll-security-threats **(Michael > Richardson)** > - security applicability review. > There was some lack of understanding amoung reviewers about the > relationship between documents. After some voice communications, we > agreed that we needed to be more explicit about the relatinoship to > other documents. Peter van der Stock proposed some text which is now > in > different documents > - Michael presents threats document > > - secu area review about sec doc (september 2013). Very good reivew. > Some tickets were opened. Lots got fixed. Robert Cragie found > innaccuracies > and things tha didn't make sense. Tickets got opened and fixed > The -08 uploaded on Monday July 21. Use the diff tool to see the > changes. > This document went through WGLC in Feb. Robert Cragie looked at it > before > sending to Adrian. Button pushed on Monday!!!!, should be discussed at > IESG soon. This has been a long (3 year) process. > Will be nice to have done. > > - one of the things that came up is that we have a number of messages > in ROLL which are important and multicast. > From DICE, we know that secuirty multicast is tricky. > With symmetric keying, members can impersonate. Pieces in ROLL are > not > as strong as they could be as a result. > -We clarified some of the text. Affects people that have a > group-shared L2 key > which is the same across the entire network. If you have a L2 master > key > from which link messags are derived, you can do something different. > Ultimately, when multicast, you need to use key that all can read. > This is something we clarified. > - although DISare multicast, it's a "please answer me". > The effect is that a timer goes faster. Not a huge deal if > impersonated. > - DIOs, if they are impersonated, that's an issue. > One of the defenses is that is to unicast a DIS back, so mote sends a > DIO again. There is a workaround for the paranoid. > > (Ines reminds about blue sheets) > > - Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke Doi)** > - draft tp [ropose DHLC option to configureMPL > - idea: control MPL. Used in smart meter network. Intended for slow > update of MPL forwarded. Because MPL trickle algo has control between > network usage and MPLlatency,this is a tradeoff. > > -parameter should be modifiable. > > - updated the draft to -01 weeks before the IETF meeting. > Asking ROLL and DHC WG for feedback. DHC gave feedback. > -02 on Monday. > - operational considerations were added. What happens when > MPL parameters were changes when MPL network is running > - Peter van der Stock indicated that you need control over . > Changed SHOULD to MAY > > - Asks WG for feedback. Please give review on these sentences > > -last week, lots of feedback from DHC. Most concern idea to make timer > in floating point. Didn't like that. Changed the format, simplified. > - Yusuke presents the format of the packets. the unit of the time is > added to the packet. e.g.of tunit is 100,timer is 100ms. timers in > uint16 > - [MR] like floating point, but easily absorbed? > - [YD] encoding is simple > - [MR] for unknown options on DHCP server,people will have to > calculate > the hex anyway... > - [YD] believe almost all implementers don't need to worry about > this. Wrote Python code to generate this > - mostly clients have to worry about this > - very simple and straight forwards. Needs experience and feedback on > range fo timers > - current specification is only able to go up to 4.6 hours. > Not sure if enough for all of usages, including expiration timers. > If we need larger duration, need to think again on these timers > - message: please give meyour feedback. > - > - Ines asks to read the drafts and comment on ML > > - _[1325]_ Updates on: draft-ietf-roll-admin-local-policy > **(Peter van der Stok)** > - draft is about having admin local be automatically determined > - multiple: realm-local scope, link-local and admin-local > - different topologies possible > - linklocal scope: automatically determined, single hop > -real: local: automatically, determined by L2 > - admin-local: multiple hop, include different L2 networks. > - wish is that it would be automatically discovered > - idea is that we have 2 router: one standard, and one router has MPL > router with MPL forwarded. They all subscribe to > ALL_MPL_FORWARDER scope 3 > and 4 > - about MPL routers, assuming R1 and R2, assuming they have 2 mesh > networks > What we want to do is have an MPL scope which includes mesh > networks but excludes > - introduce boolean flag call MPL blocked. > - we use protocol to determine whether should be true or false > - start with MPLlock false. at least every hour, send an MPL message to > MPL_FORWARDEDS_SCOPE. If no get message back, no interested nodes on > that > line, > - query for nodes are interested, if none, close and don't use > - result is that some interfaces are enabled (to the mesh), > disabled (to the Northbound) > - allows to automatically determine MPL zone > -if you have an egde router, you should false interface to block > - [Pascal]flow reminds in autonomic, see BoF.Encourages to ANIMA. > Probably you could propose this there. > - [Pvds] can you send e-mail? XXXX > - [Michael] could you derive the 1h period, i.e. 3 Imax. If it > can't maybe you have a new parameters forthat other doc. > - [Pvds] good suggested > - need also security section > > - _[1400]_ Updates on: draft-ietf-roll-applicability-template. > - see beginning > > - Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** > - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2 > - [Micheal] which issues are open? > - [Daniel] open tickets: > - #135, missed pointer to security section of RFC6550 > - #136 add a section on security consideration when RPL security > mechanisms are not used > - #137 incorporate a model for initial and incremental > deployments. Added section 9.1. and 9.2. For #136 > and #137 will ask the WG to what we can change in the > draft on what we can change > - [Michael] excellent > > - _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poipoi)** > - when started RPL, idea what to transport Hop by hop in flow label. > 6man was redefining how it wouldoperate. At roll, we created hop by > hop > header in RFC6583. Header cannot be compressed > - if a frame is coming from outside the RPL domain, you need to > encapsulate the packet in IP-in-IP to be able to send back ICMP > error and be > able to strip it > - these are many bit that we don't want to 802.15.4-2006 MAC > - when worked in ISA100.11a, worked hard to eliminate in single bit. > Real > war to remove UDP checksum. Just for 2 bytes. This was key to the > adoption > of 6LoWPAN. > - here, we are talking about 5+ octets: not acceptable > - what important in 6282 compressed in the 2 bits which indicates how > 6LoWPAN compresses the flow label and traffic class. we can have > flow label > with or without DSCP > > - proposed encoding fits in the 20 bits of the flow label. We are > to replace 5 bytes by 20 bits. Rank expressed as 8 bites. You need > to have a > deployment with a min hop of 256. > -[Michael]you are using upper 8 bits of rank? > - [PT] yes. You can compress the rank in single octet. Described in > OF0, operates wih minhop rank of 256 > - RPL was prepared for this. Text says that 6583 is only one was. WE > went > to ROLL and 6man with this. Brian Carpenter has good response. Idea > is to > have a WGLC in this group, then a confirmation WGLC from 6man to > make sure > they agree. > - if a packet has to come from the outside, it's responsibility of the > root to add flow label that makes sense > - Adrian was help out > - draft has been out there for year. > - [MR] feeling is that this is something we should adopt and seems > that we > can close to WGLC even with this document. Pascal, agree? > - [PT] yes, different revisions from different WGs > - [MR] is there a technical reason to adopt before publshing? > - [Adrian] yes you can, the WG can support a draft with a name that > doesn't start with WG name. People who think you should not > be working > - [Michael] will write line in charter? Will talk to 6man chairs > to make sure > - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair of > 802.15, there is a reason why we don't haev longer packets. > Shorter packets > means less energy and better probability. Both hats say that > this is what > we need > - [Pascal] we have running code for thos, Xavi demonstration de draft > on > OpenWSN implementation. Screenshot indicate wireshark,. You > don't have a > H2H header, was implemented very rapidly in OpenWSN > > - _[1448]_ Open floor **(poipoi)** > - Ines asks AOB > - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client can be a > leaf in a RPLnetwork. Today, all devices have to have code specific to > RPL. > A better idea is that you have what is necessary in 6LoWPAN, so > that6LoPWAN > device can be a lieaf of a RPL network. THere is a need for a > classical IP > host and moile hist. Invite you to 6lo. > - as we work on 6TiSCH, there is a case where a node moves. > We would have work on how to clean upstate route. Aswechartered? > - [MR] cleaning up stale motes is in charter, but depends on > milestones. > Let's take to ML to have a better understanding on what this > means. The > question is what the impact is on node which don' have the code. > - [Pascal] additional functionality > =[MR] then this might fit in maintenance. > - [MR]any other elements in open mic? > - [Peter] will there be any other ROLL meetrings? > =- [MR] opinion is that not in Honolulu. We have the home automation, > threads, and AMI document which seems close to done. Unless we do > somethng > that expands the charter, don't see a reason to meet again before > closing > the WG. Of course, AD could put WG in maintenant mode. Maybe will > becomes > controversial and we need F2F meeting. > - [PT]what would help you make that decision? 6TiSCH might come up with > elements, and we would need ROLL to be there. > - [MR]good idea, send question. We could go in hibernation and resume > when needed. > - [PT] plan is to fire a number of drafts, and when > - [MR] better now than in december > - [Ultich] personally, don't feel 6lo is right WG because not > always RPL. > - [MR] we could go to the routing Area WG > - [Adrain] good point. It's ok for WG to say that shut down. It's nicer > to close the WG and create a new WG when needed. Not a good > idea to have WG > sitting around. AD can sponsor documents. Do we need a forum > for discussion > and driving the work? If yes, we'll create a spacefor it. > - [Ines] there were e-mails about open topics. We need to work on > issues before rechartering/closing. > > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c3e352b1af9104fef1bc60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,
These are the raw notes at the end of the mee= ting. "poipoi" is just a placeholder.
Thomas
<= /div>


On Thu, = Jul 24, 2014 at 10:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

many thanks to Thomas. =C2=A0Please /XXX for pieces that might need comment= , here
they are:
=C2=A0 =C2=A0 - Peter van der Stock indicated that you need control over &l= t;XXXX ????>.
=C2=A0 =C2=A0 =C2=A0 Changed SHOULD to MAY

=C2=A0 =C2=A0 - [Pvds] can you send e-mail? XXXX
=C2=A0 =C2=A0 =C2=A0 (was re: Autonomic/ANIMA)


I'm not sure what "poipoi" means.


1300-1500 EDT Wednesday Afternoon Session I
Territories room

Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/ Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-r= oll
Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll
Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/iet= f907.m3u

ROLL (Routing Over Low Power and Lossy Networks)

Agenda
------

- State of all drafts (5min)
- Related Internet-Drafts
- State of all Issues (3min)
- Updates to Milestones, Schedule and Practice (5min)
- Feedback from Plugfest Event (5min)
- Updates on: draft-ietf-roll-security-threats (10min)
- Updates on: draft-ietf-roll-mpl-parameter-configuration (15min)
- Updates on: draft-ietf-roll-admin-local-policy (15min)
- Updates on: draft-ietf-roll-applicability-template. (5min)
- Updates on: draft-ietf-roll-applicability-ami (10min)
- Updates on: draft-thubert-6man-flow-label-for-rpl (15min)
- Open floor (15 minutes)

Minutes
-------

- _[1300]_ Meeting starts
=C2=A0 =C2=A0 - **[Ines]** starts the meeting
=C2=A0 =C2=A0 - reminds note well
=C2=A0 =C2=A0 - meetecho available, minutes taken, Jabber as well
=C2=A0 =C2=A0 - presents agenda

- _[1302]_ State of all drafts **(poipoi)**
=C2=A0 =C2=A0 - Ines reminds status of drafts on sldies
=C2=A0 =C2=A0 - Ines presents related I-D not adopted yet
=C2=A0 =C2=A0 - Ines presents open tickets (see slides). Some work needed o= n the open
=C2=A0 =C2=A0 =C2=A0 tickets.
=C2=A0 =C2=A0 - Ines presents milestones. Industrial applicability is behin= d.

=C2=A0 =C2=A0 -Ines: need to decide whether nee to recharter or close.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0After work on MPL done,

- Related Internet-Drafts **(poipoi)**
=C2=A0 =C2=A0 - poipoi
- _[1305]_ State of all Issues **(poipoi)**
=C2=A0 =C2=A0 - poipoi
- _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)**
=C2=A0 =C2=A0 - poipoi
- _[1315]_ Feedback from Plugfest Event **(poipoi)**
=C2=A0 =C2=A0 - Thomas presents
=C2=A0 =C2=A0 =C2=A0 - Updates on: draft-ietf-roll-security-threats **(Mich= ael Richardson)**
=C2=A0 =C2=A0 - security applicability review.
=C2=A0 =C2=A0 =C2=A0 There was some lack of understanding amoung reviewers = about the
=C2=A0 =C2=A0 =C2=A0 relationship between documents. =C2=A0After some voice= communications, we
=C2=A0 =C2=A0 =C2=A0 agreed that we needed to be more explicit about the re= latinoship to
=C2=A0 =C2=A0 =C2=A0 other documents. Peter van der Stock proposed some tex= t which is now in
=C2=A0 =C2=A0 =C2=A0 different documents
=C2=A0 =C2=A0 - Michael presents threats document

=C2=A0 =C2=A0 - secu area review about sec doc (september 2013). Very good = reivew.
=C2=A0 =C2=A0 Some tickets were opened. Lots got fixed. Robert Cragie found= innaccuracies
=C2=A0 =C2=A0 and things tha didn't make sense. Tickets got opened and = fixed
=C2=A0 =C2=A0 The -08 uploaded on Monday July 21. Use the diff tool to see = the
=C2=A0 =C2=A0 changes.
=C2=A0 =C2=A0 This document went through WGLC in Feb. Robert Cragie looked = at it before
=C2=A0 =C2=A0 sending to Adrian. Button pushed on Monday!!!!, should be dis= cussed at
=C2=A0 =C2=A0 IESG soon. =C2=A0This has been a long (3 year) process.
=C2=A0 =C2=A0 Will be nice to have done.

=C2=A0 =C2=A0 - one of the things that came up is that we have a number of = messages
=C2=A0 =C2=A0 =C2=A0 in ROLL which are important and multicast.
=C2=A0 =C2=A0 =C2=A0 From DICE, we know that secuirty multicast is tricky.<= br> =C2=A0 =C2=A0 =C2=A0 With symmetric keying, members can impersonate. =C2=A0= Pieces in ROLL are not
=C2=A0 =C2=A0 =C2=A0 as strong as they could be as a result.
=C2=A0 =C2=A0 -We clarified some of the text. Affects people that have a gr= oup-shared L2 key
=C2=A0 =C2=A0 which is the same across the entire network. If you have a L2= master key
=C2=A0 =C2=A0 from which link messags are derived, you can do something dif= ferent.
=C2=A0 =C2=A0 Ultimately, when multicast, you need to use key that all can = read.
=C2=A0 =C2=A0 This is something we clarified.
=C2=A0 =C2=A0 =C2=A0 - although DISare multicast, it's a "please a= nswer me".
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The effect is that a timer goes faster. Not a h= uge deal if impersonated.
=C2=A0 =C2=A0 - DIOs, if they are impersonated, that's an issue.
=C2=A0 =C2=A0 =C2=A0 One of the defenses is that is to unicast a DIS back, = so mote sends a
=C2=A0 =C2=A0 =C2=A0 DIO again. =C2=A0 There is a workaround for the parano= id.

(Ines reminds about blue sheets)

- Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke Doi)**<= br> =C2=A0 =C2=A0 - draft tp [ropose DHLC option to configureMPL
=C2=A0 =C2=A0 - idea: control MPL. Used in smart meter network. Intended fo= r slow
=C2=A0 =C2=A0 =C2=A0 update of MPL forwarded. Because MPL trickle algo has = control between
=C2=A0 =C2=A0 =C2=A0 network usage and MPLlatency,this is a tradeoff.

=C2=A0 =C2=A0 =C2=A0-parameter should be modifiable.

=C2=A0 =C2=A0 - updated the draft to -01 weeks before the IETF meeting.
=C2=A0 =C2=A0 =C2=A0 Asking ROLL and DHC WG for feedback. DHC gave feedback= .
=C2=A0 =C2=A0 =C2=A0 -02 on Monday.
=C2=A0 =C2=A0 - operational considerations were added. What happens when =C2=A0 =C2=A0 =C2=A0 =C2=A0MPL parameters were changes when MPL network is = running
=C2=A0 =C2=A0 - Peter van der Stock indicated that you need control over &l= t;XXXX ????>.
=C2=A0 =C2=A0 =C2=A0 Changed SHOULD to MAY

=C2=A0 =C2=A0 - Asks WG for feedback. Please give review on these sentences=

=C2=A0 =C2=A0 -last week, lots of feedback from DHC. Most concern idea to m= ake timer
=C2=A0 =C2=A0 =C2=A0 in floating point. Didn't like that. Changed the f= ormat, simplified.
=C2=A0 =C2=A0 - Yusuke presents the format of the packets. the unit of the = time is
=C2=A0 =C2=A0 =C2=A0 =C2=A0added to the packet. e.g.of tunit is 100,timer i= s 100ms. timers in uint16
=C2=A0 =C2=A0 =C2=A0 - [MR] like floating point, but easily absorbed?
=C2=A0 =C2=A0 =C2=A0 - [YD] encoding is simple
=C2=A0 =C2=A0 =C2=A0 - [MR] for unknown options on DHCP server,people will = have to calculate
=C2=A0 =C2=A0 =C2=A0 the hex anyway...
=C2=A0 =C2=A0 =C2=A0 - [YD] believe almost all implementers don't need = to worry about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this. Wrote Python code to generate this
=C2=A0 =C2=A0 - mostly clients have to worry about this
=C2=A0 =C2=A0 - very simple and straight forwards. Needs experience and fee= dback on
=C2=A0 =C2=A0 =C2=A0 =C2=A0range fo timers
=C2=A0 =C2=A0 - current specification is only able to go up to 4.6 hours. =C2=A0 =C2=A0 =C2=A0 Not sure if enough for all of usages, including expira= tion timers.
=C2=A0 =C2=A0 =C2=A0 If we need larger duration, need to think again on the= se timers
=C2=A0 =C2=A0 - message: please give meyour feedback.
=C2=A0 =C2=A0 - <no feedback from the room>
=C2=A0 =C2=A0 - Ines asks to read the drafts and comment on ML

- _[1325]_ Updates on: draft-ietf-roll-admin-local-policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0**(Peter van der Stok)**
=C2=A0 =C2=A0 - draft is about having admin local be automatically determin= ed
=C2=A0 =C2=A0 - multiple: realm-local scope, link-local and admin-local
=C2=A0 =C2=A0 - different topologies possible
=C2=A0 =C2=A0 - linklocal scope: automatically determined, single hop
=C2=A0 =C2=A0 -real: local: automatically, determined by L2
=C2=A0 =C2=A0 - admin-local: multiple hop, include different L2 networks. =C2=A0 =C2=A0 - wish is that it would be automatically discovered
=C2=A0 =C2=A0 - idea is that we have 2 router: one standard, and one router= has MPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0router with MPL forwarded. They all subsc= ribe to ALL_MPL_FORWARDER scope 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and 4
=C2=A0 =C2=A0 - about MPL routers, assuming R1 and R2, assuming they have 2= mesh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0networks
=C2=A0 =C2=A0 =C2=A0 What we want to do is have an MPL scope which includes= mesh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 networks but excludes <the enterprise/home/e= tc.>
=C2=A0 =C2=A0 - introduce boolean flag call MPL blocked.
=C2=A0 =C2=A0 - we use protocol to determine whether should be true or fals= e
=C2=A0 =C2=A0 - start with MPLlock false. at least every hour, send an MPL = message to
=C2=A0 =C2=A0 =C2=A0 MPL_FORWARDEDS_SCOPE. If no get message back, no inter= ested nodes on that
=C2=A0 =C2=A0 =C2=A0 line,
=C2=A0 =C2=A0 - query for nodes are interested, if none, close and don'= t use
=C2=A0 =C2=A0 - result is that some interfaces are enabled (to the mesh), =C2=A0 =C2=A0 =C2=A0 disabled (to the Northbound)
=C2=A0 =C2=A0 - allows to automatically determine MPL zone
=C2=A0 =C2=A0 -if you have an egde router, you should false interface to bl= ock
=C2=A0 =C2=A0 - [Pascal]flow reminds in autonomic, see BoF.Encourages to AN= IMA.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Probably you could propose this there. =C2=A0 =C2=A0 - [Pvds] can you send e-mail? XXXX
=C2=A0 =C2=A0 - [Michael] could you derive the 1h period, i.e. 3 Imax. If i= t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can't maybe you have a = new parameters forthat other doc.
=C2=A0 =C2=A0 - [Pvds] good suggested
=C2=A0 =C2=A0 - need also security section

- _[1400]_ Updates on: draft-ietf-roll-applicability-template.
=C2=A0- see beginning

- Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)**
=C2=A0 =C2=A0 - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.= 2
=C2=A0 =C2=A0 - [Micheal] which issues are open?
=C2=A0 =C2=A0 - [Daniel] open tickets:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - #135, missed pointer to security section of R= FC6550
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- #136 add a section on security c= onsideration when RPL security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms a= re not used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- #137 incorporate a model for ini= tial and incremental
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deployments.= Added section 9.1. and 9.2. For #136
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and #137 wil= l ask the WG to what we can change in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft on wha= t we can change
=C2=A0 =C2=A0 - [Michael] excellent

- _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poipoi)** =C2=A0 =C2=A0 - when started RPL, idea what to transport Hop by hop in flow= label.
=C2=A0 =C2=A0 =C2=A0 6man was redefining how it wouldoperate. At roll, we c= reated hop by hop
=C2=A0 =C2=A0 =C2=A0 header in RFC6583. Header cannot be compressed
=C2=A0 =C2=A0 - if a frame is coming from outside the RPL domain, you need = to
=C2=A0 =C2=A0 =C2=A0 encapsulate the packet in IP-in-IP to be able to send = back ICMP error and be
=C2=A0 =C2=A0 =C2=A0 able to strip it
=C2=A0 =C2=A0 - these are many bit that we don't want to 802.15.4-2006 = MAC
=C2=A0 =C2=A0 - when worked in ISA100.11a, worked hard to eliminate in sing= le bit. Real
=C2=A0 =C2=A0 =C2=A0 war to remove UDP checksum. Just for 2 bytes. This was= key to the adoption
=C2=A0 =C2=A0 =C2=A0 of 6LoWPAN.
=C2=A0 =C2=A0 - here, we are talking about 5+ octets: not acceptable
=C2=A0 =C2=A0 - what important in 6282 compressed in the 2 bits which indic= ates how
=C2=A0 =C2=A0 =C2=A0 6LoWPAN compresses the flow label and traffic class. w= e can have flow label
=C2=A0 =C2=A0 =C2=A0 with or without DSCP

=C2=A0 =C2=A0 - proposed encoding fits in the 20 bits of the flow label. We= are
=C2=A0 =C2=A0 =C2=A0 to replace 5 bytes by 20 bits. Rank expressed as 8 bit= es. You need to have a
=C2=A0 =C2=A0 =C2=A0 deployment with a min hop of 256.
=C2=A0 =C2=A0 -[Michael]you are using upper 8 bits of rank?
=C2=A0 =C2=A0 - [PT] yes. You can compress the rank in single octet. Descri= bed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OF0, operates wih minhop rank of 2= 56
=C2=A0 =C2=A0 - RPL was prepared for this. Text says that 6583 is only one = was. WE went
=C2=A0 =C2=A0 =C2=A0 to ROLL and 6man with this. Brian Carpenter has good r= esponse. Idea is to
=C2=A0 =C2=A0 =C2=A0 have a WGLC in this group, then a confirmation WGLC fr= om 6man to make sure
=C2=A0 =C2=A0 =C2=A0 they agree.
=C2=A0 =C2=A0 - if a packet has to come from the outside, it's responsi= bility of the
=C2=A0 =C2=A0 =C2=A0 root to add flow label that makes sense
=C2=A0 =C2=A0 - Adrian was help out
=C2=A0 =C2=A0 - draft has been out there for year.
=C2=A0 =C2=A0 - [MR] feeling is that this is something we should adopt and = seems that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can close to WGLC even with this d= ocument. Pascal, agree?
=C2=A0 =C2=A0 - [PT] yes, different revisions from different WGs
=C2=A0 =C2=A0 - [MR] is there a technical reason to adopt before publshing?=
=C2=A0 =C2=A0 - [Adrian] yes you can, the WG can support a draft with a nam= e that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't start wi= th WG name. People who think you should not be working
=C2=A0 =C2=A0 - [Michael] will write line in charter? =C2=A0Will talk to 6m= an chairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to make sure
=C2=A0 =C2=A0 - [PK] chair fo ISA100.11a. Fought over every bytes. As vice = chair of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0802.15, there is a reason why we d= on't haev longer packets. Shorter packets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0means less energy and better proba= bility. Both hats say that this is what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we need
=C2=A0 =C2=A0 - [Pascal] we have running code for thos, Xavi demonstration = de draft on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenWSN implementation. Screenshot= indicate wireshark,. You don't have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0H2H header, was implemented very r= apidly in OpenWSN

- _[1448]_ Open floor **(poipoi)**
=C2=A0 =C2=A0 - Ines asks AOB
=C2=A0 =C2=A0 - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client = can be a
=C2=A0 =C2=A0 leaf in a RPLnetwork. Today, all devices have to have code sp= ecific to RPL.
=C2=A0 =C2=A0 A better idea is that you have what is necessary in 6LoWPAN, = so that6LoPWAN
=C2=A0 =C2=A0 device can be a lieaf of a RPL network. THere is a need for a= classical IP
=C2=A0 =C2=A0 host and moile hist. Invite you to 6lo.
=C2=A0 =C2=A0 - as we work on 6TiSCH, there is a case where a node moves. =C2=A0 =C2=A0 We would have work on how to clean upstate route. Aswecharter= ed?
=C2=A0 =C2=A0 - [MR] cleaning up stale motes is in charter, but depends on = milestones.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Let's take to ML to have a better und= erstanding on what this means. The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0question is what the impact is on node wh= ich don' have the code.
=C2=A0 =C2=A0 - [Pascal] additional functionality
=C2=A0 =C2=A0 =3D[MR] then this might fit in maintenance.
=C2=A0 =C2=A0 - [MR]any other elements in open mic?
=C2=A0 =C2=A0 - [Peter] will there be any other ROLL meetrings?
=C2=A0 =C2=A0 =3D- [MR] opinion is that not in Honolulu. We have the home a= utomation,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 threads, and AMI document which seems close to = done. Unless we do somethng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that expands the charter, don't see a reaso= n to meet again before closing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the WG. Of course, AD could put WG in maintenan= t mode. =C2=A0Maybe will becomes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 controversial and we need F2F meeting.
=C2=A0 =C2=A0 - [PT]what would help you make that decision? 6TiSCH might co= me up with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 elements, and we would need ROLL to be t= here.
=C2=A0 =C2=A0 - [MR]good idea, send question. We could go in hibernation an= d resume
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when needed.
=C2=A0 =C2=A0 - [PT] plan is to fire a number of drafts, and when
=C2=A0 =C2=A0 - [MR] better now than in december
=C2=A0 =C2=A0 - [Ultich] personally, don't feel 6lo is right WG because= not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 always RPL.
=C2=A0 =C2=A0 - [MR] we could go to the routing Area WG
=C2=A0 =C2=A0 - [Adrain] good point. It's ok for WG to say that shut do= wn. It's nicer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to close the WG and create a new W= G when needed. Not a good idea to have WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sitting around. AD can sponsor doc= uments. Do we need a forum for discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and driving the work? If yes, we&#= 39;ll create a spacefor it.
=C2=A0 =C2=A0 - [Ines] there were e-mails about open topics. We need to wor= k on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issues before rechartering/= closing.




--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =C2=A0 =C2=A0http://datatracker.ietf.org/wg/roll/cha= rter/


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


--001a11c3e352b1af9104fef1bc60-- From nobody Thu Jul 24 08:24:36 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F6D1A037A for ; Thu, 24 Jul 2014 08:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.695 X-Spam-Level: *** X-Spam-Status: No, score=3.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=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 kw-_9o21lDvY for ; Thu, 24 Jul 2014 08:24:28 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA571A0199 for ; Thu, 24 Jul 2014 08:22:03 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id s6OFLxoc034906; Thu, 24 Jul 2014 17:22:00 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:4504:afd5:eade:ce52]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 17:21:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 17:21:59 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <13664.1406213156@sandelman.ca> References: <13664.1406213156@sandelman.ca> Message-ID: <69c78be764b6c1aa4b55168b26090b52@xs4all.nl> X-Sender: stokcons@xs4all.nl (rNj89yb3j7SHdDOiatU0g3wG2KTcKrtD) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ohER5Qvbz2oTYMqOJlcFxHhR0z0 Cc: Michael Richardson Subject: Re: [Roll] DRAFT minutes from IETF90 meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:24:35 -0000 Peter van der Stock indicated that you need control over . -> I'm sorry, I don't remember this intervention. [Pvds] can you send e-mail? XXXX (was re: Autonomic/ANIMA) -> I said probably "many thanks" Michael Richardson schreef op 2014-07-24 16:45: > many thanks to Thomas. Please /XXX for pieces that might need comment, > here > they are: > - Peter van der Stock indicated that you need control over ????>. > Changed SHOULD to MAY > > - [Pvds] can you send e-mail? XXXX > (was re: Autonomic/ANIMA) > > > I'm not sure what "poipoi" means. > > > 1300-1500 EDT Wednesday Afternoon Session I > Territories room > > Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/ > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-roll > Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll > Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/ietf907.m3u > > ROLL (Routing Over Low Power and Lossy Networks) > > Agenda > ------ > > - State of all drafts (5min) > - Related Internet-Drafts > - State of all Issues (3min) > - Updates to Milestones, Schedule and Practice (5min) > - Feedback from Plugfest Event (5min) > - Updates on: draft-ietf-roll-security-threats (10min) > - Updates on: draft-ietf-roll-mpl-parameter-configuration (15min) > - Updates on: draft-ietf-roll-admin-local-policy (15min) > - Updates on: draft-ietf-roll-applicability-template. (5min) > - Updates on: draft-ietf-roll-applicability-ami (10min) > - Updates on: draft-thubert-6man-flow-label-for-rpl (15min) > - Open floor (15 minutes) > > Minutes > ------- > > - _[1300]_ Meeting starts > - **[Ines]** starts the meeting > - reminds note well > - meetecho available, minutes taken, Jabber as well > - presents agenda > > - _[1302]_ State of all drafts **(poipoi)** > - Ines reminds status of drafts on sldies > - Ines presents related I-D not adopted yet > - Ines presents open tickets (see slides). Some work needed on the > open > tickets. > - Ines presents milestones. Industrial applicability is behind. > > -Ines: need to decide whether nee to recharter or close. > After work on MPL done, > > - Related Internet-Drafts **(poipoi)** > - poipoi > - _[1305]_ State of all Issues **(poipoi)** > - poipoi > - _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)** > - poipoi > - _[1315]_ Feedback from Plugfest Event **(poipoi)** > - Thomas presents > - Updates on: draft-ietf-roll-security-threats **(Michael > Richardson)** > - security applicability review. > There was some lack of understanding amoung reviewers about the > relationship between documents. After some voice communications, > we > agreed that we needed to be more explicit about the relatinoship > to > other documents. Peter van der Stock proposed some text which is > now in > different documents > - Michael presents threats document > > - secu area review about sec doc (september 2013). Very good > reivew. > Some tickets were opened. Lots got fixed. Robert Cragie found > innaccuracies > and things tha didn't make sense. Tickets got opened and fixed > The -08 uploaded on Monday July 21. Use the diff tool to see the > changes. > This document went through WGLC in Feb. Robert Cragie looked at it > before > sending to Adrian. Button pushed on Monday!!!!, should be discussed > at > IESG soon. This has been a long (3 year) process. > Will be nice to have done. > > - one of the things that came up is that we have a number of > messages > in ROLL which are important and multicast. > From DICE, we know that secuirty multicast is tricky. > With symmetric keying, members can impersonate. Pieces in ROLL > are not > as strong as they could be as a result. > -We clarified some of the text. Affects people that have a > group-shared L2 key > which is the same across the entire network. If you have a L2 > master key > from which link messags are derived, you can do something > different. > Ultimately, when multicast, you need to use key that all can read. > This is something we clarified. > - although DISare multicast, it's a "please answer me". > The effect is that a timer goes faster. Not a huge deal if > impersonated. > - DIOs, if they are impersonated, that's an issue. > One of the defenses is that is to unicast a DIS back, so mote > sends a > DIO again. There is a workaround for the paranoid. > > (Ines reminds about blue sheets) > > - Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke > Doi)** > - draft tp [ropose DHLC option to configureMPL > - idea: control MPL. Used in smart meter network. Intended for slow > update of MPL forwarded. Because MPL trickle algo has control > between > network usage and MPLlatency,this is a tradeoff. > > -parameter should be modifiable. > > - updated the draft to -01 weeks before the IETF meeting. > Asking ROLL and DHC WG for feedback. DHC gave feedback. > -02 on Monday. > - operational considerations were added. What happens when > MPL parameters were changes when MPL network is running > - Peter van der Stock indicated that you need control over ????>. > Changed SHOULD to MAY > > - Asks WG for feedback. Please give review on these sentences > > -last week, lots of feedback from DHC. Most concern idea to make > timer > in floating point. Didn't like that. Changed the format, > simplified. > - Yusuke presents the format of the packets. the unit of the time > is > added to the packet. e.g.of tunit is 100,timer is 100ms. timers > in uint16 > - [MR] like floating point, but easily absorbed? > - [YD] encoding is simple > - [MR] for unknown options on DHCP server,people will have to > calculate > the hex anyway... > - [YD] believe almost all implementers don't need to worry about > this. Wrote Python code to generate this > - mostly clients have to worry about this > - very simple and straight forwards. Needs experience and feedback > on > range fo timers > - current specification is only able to go up to 4.6 hours. > Not sure if enough for all of usages, including expiration > timers. > If we need larger duration, need to think again on these timers > - message: please give meyour feedback. > - > - Ines asks to read the drafts and comment on ML > > - _[1325]_ Updates on: draft-ietf-roll-admin-local-policy > **(Peter van der Stok)** > - draft is about having admin local be automatically determined > - multiple: realm-local scope, link-local and admin-local > - different topologies possible > - linklocal scope: automatically determined, single hop > -real: local: automatically, determined by L2 > - admin-local: multiple hop, include different L2 networks. > - wish is that it would be automatically discovered > - idea is that we have 2 router: one standard, and one router has > MPL > router with MPL forwarded. They all subscribe to > ALL_MPL_FORWARDER scope 3 > and 4 > - about MPL routers, assuming R1 and R2, assuming they have 2 mesh > networks > What we want to do is have an MPL scope which includes mesh > networks but excludes > - introduce boolean flag call MPL blocked. > - we use protocol to determine whether should be true or false > - start with MPLlock false. at least every hour, send an MPL > message to > MPL_FORWARDEDS_SCOPE. If no get message back, no interested nodes > on that > line, > - query for nodes are interested, if none, close and don't use > - result is that some interfaces are enabled (to the mesh), > disabled (to the Northbound) > - allows to automatically determine MPL zone > -if you have an egde router, you should false interface to block > - [Pascal]flow reminds in autonomic, see BoF.Encourages to ANIMA. > Probably you could propose this there. > - [Pvds] can you send e-mail? XXXX > - [Michael] could you derive the 1h period, i.e. 3 Imax. If it > can't maybe you have a new parameters forthat other doc. > - [Pvds] good suggested > - need also security section > > - _[1400]_ Updates on: draft-ietf-roll-applicability-template. > - see beginning > > - Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** > - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2 > - [Micheal] which issues are open? > - [Daniel] open tickets: > - #135, missed pointer to security section of RFC6550 > - #136 add a section on security consideration when RPL > security > mechanisms are not used > - #137 incorporate a model for initial and incremental > deployments. Added section 9.1. and 9.2. For #136 > and #137 will ask the WG to what we can change in the > draft on what we can change > - [Michael] excellent > > - _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl > **(poipoi)** > - when started RPL, idea what to transport Hop by hop in flow > label. > 6man was redefining how it wouldoperate. At roll, we created hop > by hop > header in RFC6583. Header cannot be compressed > - if a frame is coming from outside the RPL domain, you need to > encapsulate the packet in IP-in-IP to be able to send back ICMP > error and be > able to strip it > - these are many bit that we don't want to 802.15.4-2006 MAC > - when worked in ISA100.11a, worked hard to eliminate in single > bit. Real > war to remove UDP checksum. Just for 2 bytes. This was key to the > adoption > of 6LoWPAN. > - here, we are talking about 5+ octets: not acceptable > - what important in 6282 compressed in the 2 bits which indicates > how > 6LoWPAN compresses the flow label and traffic class. we can have > flow label > with or without DSCP > > - proposed encoding fits in the 20 bits of the flow label. We are > to replace 5 bytes by 20 bits. Rank expressed as 8 bites. You > need to have a > deployment with a min hop of 256. > -[Michael]you are using upper 8 bits of rank? > - [PT] yes. You can compress the rank in single octet. Described in > OF0, operates wih minhop rank of 256 > - RPL was prepared for this. Text says that 6583 is only one was. > WE went > to ROLL and 6man with this. Brian Carpenter has good response. > Idea is to > have a WGLC in this group, then a confirmation WGLC from 6man to > make sure > they agree. > - if a packet has to come from the outside, it's responsibility of > the > root to add flow label that makes sense > - Adrian was help out > - draft has been out there for year. > - [MR] feeling is that this is something we should adopt and seems > that we > can close to WGLC even with this document. Pascal, agree? > - [PT] yes, different revisions from different WGs > - [MR] is there a technical reason to adopt before publshing? > - [Adrian] yes you can, the WG can support a draft with a name that > doesn't start with WG name. People who think you should > not be working > - [Michael] will write line in charter? Will talk to 6man chairs > to make sure > - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair > of > 802.15, there is a reason why we don't haev longer packets. > Shorter packets > means less energy and better probability. Both hats say > that this is what > we need > - [Pascal] we have running code for thos, Xavi demonstration de > draft on > OpenWSN implementation. Screenshot indicate wireshark,. You > don't have a > H2H header, was implemented very rapidly in OpenWSN > > - _[1448]_ Open floor **(poipoi)** > - Ines asks AOB > - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client can be > a > leaf in a RPLnetwork. Today, all devices have to have code specific > to RPL. > A better idea is that you have what is necessary in 6LoWPAN, so > that6LoPWAN > device can be a lieaf of a RPL network. THere is a need for a > classical IP > host and moile hist. Invite you to 6lo. > - as we work on 6TiSCH, there is a case where a node moves. > We would have work on how to clean upstate route. Aswechartered? > - [MR] cleaning up stale motes is in charter, but depends on > milestones. > Let's take to ML to have a better understanding on what this > means. The > question is what the impact is on node which don' have the > code. > - [Pascal] additional functionality > =[MR] then this might fit in maintenance. > - [MR]any other elements in open mic? > - [Peter] will there be any other ROLL meetrings? > =- [MR] opinion is that not in Honolulu. We have the home > automation, > threads, and AMI document which seems close to done. Unless we > do somethng > that expands the charter, don't see a reason to meet again > before closing > the WG. Of course, AD could put WG in maintenant mode. Maybe > will becomes > controversial and we need F2F meeting. > - [PT]what would help you make that decision? 6TiSCH might come up > with > elements, and we would need ROLL to be there. > - [MR]good idea, send question. We could go in hibernation and > resume > when needed. > - [PT] plan is to fire a number of drafts, and when > - [MR] better now than in december > - [Ultich] personally, don't feel 6lo is right WG because not > always RPL. > - [MR] we could go to the routing Area WG > - [Adrain] good point. It's ok for WG to say that shut down. It's > nicer > to close the WG and create a new WG when needed. Not a good > idea to have WG > sitting around. AD can sponsor documents. Do we need a > forum for discussion > and driving the work? If yes, we'll create a spacefor it. > - [Ines] there were e-mails about open topics. We need to work on > issues before rechartering/closing. > > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Jul 24 08:29:47 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A181A0205 for ; Thu, 24 Jul 2014 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.124 X-Spam-Level: ** X-Spam-Status: No, score=2.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, SPF_PASS=-0.001, WEIRD_PORT=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 5NiRb7uh9FAp for ; Thu, 24 Jul 2014 08:29:42 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CB61A0309 for ; Thu, 24 Jul 2014 08:29:23 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so5177139vcb.33 for ; Thu, 24 Jul 2014 08:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rdf7zQTr8Hq4WdZTyYv30yjXnam+0y32qmw81nbCg7k=; b=evyoJ/qc1YqYwUbPv9GDBWIV2tcoUuyvkWDNJ8nKfemIWyWORDUGYy6117ZFbdwCEw KIo9FNn3c4IByqbYChdCTkVpPaVVelFuL0tJ9l37EWjDGmFp6nn1IG9VxucSHBYukz1d cpBXEnAdeY+ON8whCLG0SYjnvIEzq7LQ/W8ePZqd+2d6s4QeN5MMAs2pIQxTzUZU+Yh1 rxb62GkzuapbAYl0DhMfrn3wA5pbuOOmcad+OVp9LQJ0a8mNVZze/4yj6lIBkE9l+dY4 Zb3QC5cxLrcx1/aff0S4sE0/pcjULN19mhK4rQfSMVfLKyGP+KFCUKGRNgKWTu1c7sIB ouTQ== MIME-Version: 1.0 X-Received: by 10.220.74.10 with SMTP id s10mr13222244vcj.61.1406215762218; Thu, 24 Jul 2014 08:29:22 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Thu, 24 Jul 2014 08:29:22 -0700 (PDT) In-Reply-To: <69c78be764b6c1aa4b55168b26090b52@xs4all.nl> References: <13664.1406213156@sandelman.ca> <69c78be764b6c1aa4b55168b26090b52@xs4all.nl> Date: Thu, 24 Jul 2014 11:29:22 -0400 Message-ID: From: Ines Robles To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=e89a8f647193fc146404fef21e9e Archived-At: http://mailarchive.ietf.org/arch/msg/roll/V1igZWIHGllxFDuUkVxyVDpRU2g Cc: Michael Richardson Subject: Re: [Roll] DRAFT minutes from IETF90 meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:29:46 -0000 --e89a8f647193fc146404fef21e9e Content-Type: text/plain; charset=UTF-8 Thank you Peter, the minutes are going to be updated with the audio of meetecho. Best, 2014-07-24 11:21 GMT-04:00 peter van der Stok : > Peter van der Stock indicated that you need control over . > -> I'm sorry, I don't remember this intervention. > > > [Pvds] can you send e-mail? XXXX > (was re: Autonomic/ANIMA) > -> I said probably "many thanks" > > Michael Richardson schreef op 2014-07-24 16:45: > >> many thanks to Thomas. Please /XXX for pieces that might need comment, >> here >> they are: >> - Peter van der Stock indicated that you need control over > ????>. >> Changed SHOULD to MAY >> >> - [Pvds] can you send e-mail? XXXX >> (was re: Autonomic/ANIMA) >> >> >> I'm not sure what "poipoi" means. >> >> >> 1300-1500 EDT Wednesday Afternoon Session I >> Territories room >> >> Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/ >> Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-roll >> Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll >> Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/ietf907.m3u >> >> ROLL (Routing Over Low Power and Lossy Networks) >> >> Agenda >> ------ >> >> - State of all drafts (5min) >> - Related Internet-Drafts >> - State of all Issues (3min) >> - Updates to Milestones, Schedule and Practice (5min) >> - Feedback from Plugfest Event (5min) >> - Updates on: draft-ietf-roll-security-threats (10min) >> - Updates on: draft-ietf-roll-mpl-parameter-configuration (15min) >> - Updates on: draft-ietf-roll-admin-local-policy (15min) >> - Updates on: draft-ietf-roll-applicability-template. (5min) >> - Updates on: draft-ietf-roll-applicability-ami (10min) >> - Updates on: draft-thubert-6man-flow-label-for-rpl (15min) >> - Open floor (15 minutes) >> >> Minutes >> ------- >> >> - _[1300]_ Meeting starts >> - **[Ines]** starts the meeting >> - reminds note well >> - meetecho available, minutes taken, Jabber as well >> - presents agenda >> >> - _[1302]_ State of all drafts **(poipoi)** >> - Ines reminds status of drafts on sldies >> - Ines presents related I-D not adopted yet >> - Ines presents open tickets (see slides). Some work needed on the >> open >> tickets. >> - Ines presents milestones. Industrial applicability is behind. >> >> -Ines: need to decide whether nee to recharter or close. >> After work on MPL done, >> >> - Related Internet-Drafts **(poipoi)** >> - poipoi >> - _[1305]_ State of all Issues **(poipoi)** >> - poipoi >> - _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)** >> - poipoi >> - _[1315]_ Feedback from Plugfest Event **(poipoi)** >> - Thomas presents >> - Updates on: draft-ietf-roll-security-threats **(Michael >> Richardson)** >> - security applicability review. >> There was some lack of understanding amoung reviewers about the >> relationship between documents. After some voice communications, we >> agreed that we needed to be more explicit about the relatinoship to >> other documents. Peter van der Stock proposed some text which is >> now in >> different documents >> - Michael presents threats document >> >> - secu area review about sec doc (september 2013). Very good reivew. >> Some tickets were opened. Lots got fixed. Robert Cragie found >> innaccuracies >> and things tha didn't make sense. Tickets got opened and fixed >> The -08 uploaded on Monday July 21. Use the diff tool to see the >> changes. >> This document went through WGLC in Feb. Robert Cragie looked at it >> before >> sending to Adrian. Button pushed on Monday!!!!, should be discussed at >> IESG soon. This has been a long (3 year) process. >> Will be nice to have done. >> >> - one of the things that came up is that we have a number of messages >> in ROLL which are important and multicast. >> From DICE, we know that secuirty multicast is tricky. >> With symmetric keying, members can impersonate. Pieces in ROLL are >> not >> as strong as they could be as a result. >> -We clarified some of the text. Affects people that have a >> group-shared L2 key >> which is the same across the entire network. If you have a L2 master >> key >> from which link messags are derived, you can do something different. >> Ultimately, when multicast, you need to use key that all can read. >> This is something we clarified. >> - although DISare multicast, it's a "please answer me". >> The effect is that a timer goes faster. Not a huge deal if >> impersonated. >> - DIOs, if they are impersonated, that's an issue. >> One of the defenses is that is to unicast a DIS back, so mote sends >> a >> DIO again. There is a workaround for the paranoid. >> >> (Ines reminds about blue sheets) >> >> - Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke >> Doi)** >> - draft tp [ropose DHLC option to configureMPL >> - idea: control MPL. Used in smart meter network. Intended for slow >> update of MPL forwarded. Because MPL trickle algo has control >> between >> network usage and MPLlatency,this is a tradeoff. >> >> -parameter should be modifiable. >> >> - updated the draft to -01 weeks before the IETF meeting. >> Asking ROLL and DHC WG for feedback. DHC gave feedback. >> -02 on Monday. >> - operational considerations were added. What happens when >> MPL parameters were changes when MPL network is running >> - Peter van der Stock indicated that you need control over > ????>. >> Changed SHOULD to MAY >> >> - Asks WG for feedback. Please give review on these sentences >> >> -last week, lots of feedback from DHC. Most concern idea to make timer >> in floating point. Didn't like that. Changed the format, simplified. >> - Yusuke presents the format of the packets. the unit of the time is >> added to the packet. e.g.of tunit is 100,timer is 100ms. timers in >> uint16 >> - [MR] like floating point, but easily absorbed? >> - [YD] encoding is simple >> - [MR] for unknown options on DHCP server,people will have to >> calculate >> the hex anyway... >> - [YD] believe almost all implementers don't need to worry about >> this. Wrote Python code to generate this >> - mostly clients have to worry about this >> - very simple and straight forwards. Needs experience and feedback on >> range fo timers >> - current specification is only able to go up to 4.6 hours. >> Not sure if enough for all of usages, including expiration timers. >> If we need larger duration, need to think again on these timers >> - message: please give meyour feedback. >> - >> - Ines asks to read the drafts and comment on ML >> >> - _[1325]_ Updates on: draft-ietf-roll-admin-local-policy >> **(Peter van der Stok)** >> - draft is about having admin local be automatically determined >> - multiple: realm-local scope, link-local and admin-local >> - different topologies possible >> - linklocal scope: automatically determined, single hop >> -real: local: automatically, determined by L2 >> - admin-local: multiple hop, include different L2 networks. >> - wish is that it would be automatically discovered >> - idea is that we have 2 router: one standard, and one router has MPL >> router with MPL forwarded. They all subscribe to >> ALL_MPL_FORWARDER scope 3 >> and 4 >> - about MPL routers, assuming R1 and R2, assuming they have 2 mesh >> networks >> What we want to do is have an MPL scope which includes mesh >> networks but excludes >> - introduce boolean flag call MPL blocked. >> - we use protocol to determine whether should be true or false >> - start with MPLlock false. at least every hour, send an MPL message >> to >> MPL_FORWARDEDS_SCOPE. If no get message back, no interested nodes >> on that >> line, >> - query for nodes are interested, if none, close and don't use >> - result is that some interfaces are enabled (to the mesh), >> disabled (to the Northbound) >> - allows to automatically determine MPL zone >> -if you have an egde router, you should false interface to block >> - [Pascal]flow reminds in autonomic, see BoF.Encourages to ANIMA. >> Probably you could propose this there. >> - [Pvds] can you send e-mail? XXXX >> - [Michael] could you derive the 1h period, i.e. 3 Imax. If it >> can't maybe you have a new parameters forthat other doc. >> - [Pvds] good suggested >> - need also security section >> >> - _[1400]_ Updates on: draft-ietf-roll-applicability-template. >> - see beginning >> >> - Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** >> - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2 >> - [Micheal] which issues are open? >> - [Daniel] open tickets: >> - #135, missed pointer to security section of RFC6550 >> - #136 add a section on security consideration when RPL >> security >> mechanisms are not used >> - #137 incorporate a model for initial and incremental >> deployments. Added section 9.1. and 9.2. For #136 >> and #137 will ask the WG to what we can change in the >> draft on what we can change >> - [Michael] excellent >> >> - _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poipoi)** >> - when started RPL, idea what to transport Hop by hop in flow label. >> 6man was redefining how it wouldoperate. At roll, we created hop by >> hop >> header in RFC6583. Header cannot be compressed >> - if a frame is coming from outside the RPL domain, you need to >> encapsulate the packet in IP-in-IP to be able to send back ICMP >> error and be >> able to strip it >> - these are many bit that we don't want to 802.15.4-2006 MAC >> - when worked in ISA100.11a, worked hard to eliminate in single bit. >> Real >> war to remove UDP checksum. Just for 2 bytes. This was key to the >> adoption >> of 6LoWPAN. >> - here, we are talking about 5+ octets: not acceptable >> - what important in 6282 compressed in the 2 bits which indicates how >> 6LoWPAN compresses the flow label and traffic class. we can have >> flow label >> with or without DSCP >> >> - proposed encoding fits in the 20 bits of the flow label. We are >> to replace 5 bytes by 20 bits. Rank expressed as 8 bites. You >> need to have a >> deployment with a min hop of 256. >> -[Michael]you are using upper 8 bits of rank? >> - [PT] yes. You can compress the rank in single octet. Described in >> OF0, operates wih minhop rank of 256 >> - RPL was prepared for this. Text says that 6583 is only one was. WE >> went >> to ROLL and 6man with this. Brian Carpenter has good response. Idea >> is to >> have a WGLC in this group, then a confirmation WGLC from 6man to >> make sure >> they agree. >> - if a packet has to come from the outside, it's responsibility of the >> root to add flow label that makes sense >> - Adrian was help out >> - draft has been out there for year. >> - [MR] feeling is that this is something we should adopt and seems >> that we >> can close to WGLC even with this document. Pascal, agree? >> - [PT] yes, different revisions from different WGs >> - [MR] is there a technical reason to adopt before publshing? >> - [Adrian] yes you can, the WG can support a draft with a name that >> doesn't start with WG name. People who think you should >> not be working >> - [Michael] will write line in charter? Will talk to 6man chairs >> to make sure >> - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair of >> 802.15, there is a reason why we don't haev longer packets. >> Shorter packets >> means less energy and better probability. Both hats say >> that this is what >> we need >> - [Pascal] we have running code for thos, Xavi demonstration de draft >> on >> OpenWSN implementation. Screenshot indicate wireshark,. You >> don't have a >> H2H header, was implemented very rapidly in OpenWSN >> >> - _[1448]_ Open floor **(poipoi)** >> - Ines asks AOB >> - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client can be a >> leaf in a RPLnetwork. Today, all devices have to have code specific >> to RPL. >> A better idea is that you have what is necessary in 6LoWPAN, so >> that6LoPWAN >> device can be a lieaf of a RPL network. THere is a need for a >> classical IP >> host and moile hist. Invite you to 6lo. >> - as we work on 6TiSCH, there is a case where a node moves. >> We would have work on how to clean upstate route. Aswechartered? >> - [MR] cleaning up stale motes is in charter, but depends on >> milestones. >> Let's take to ML to have a better understanding on what this >> means. The >> question is what the impact is on node which don' have the code. >> - [Pascal] additional functionality >> =[MR] then this might fit in maintenance. >> - [MR]any other elements in open mic? >> - [Peter] will there be any other ROLL meetrings? >> =- [MR] opinion is that not in Honolulu. We have the home automation, >> threads, and AMI document which seems close to done. Unless we >> do somethng >> that expands the charter, don't see a reason to meet again >> before closing >> the WG. Of course, AD could put WG in maintenant mode. Maybe >> will becomes >> controversial and we need F2F meeting. >> - [PT]what would help you make that decision? 6TiSCH might come up >> with >> elements, and we would need ROLL to be there. >> - [MR]good idea, send question. We could go in hibernation and resume >> when needed. >> - [PT] plan is to fire a number of drafts, and when >> - [MR] better now than in december >> - [Ultich] personally, don't feel 6lo is right WG because not >> always RPL. >> - [MR] we could go to the routing Area WG >> - [Adrain] good point. It's ok for WG to say that shut down. It's >> nicer >> to close the WG and create a new WG when needed. Not a good >> idea to have WG >> sitting around. AD can sponsor documents. Do we need a >> forum for discussion >> and driving the work? If yes, we'll create a spacefor it. >> - [Ines] there were e-mails about open topics. We need to work on >> issues before rechartering/closing. >> >> >> >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --e89a8f647193fc146404fef21e9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Peter, the minutes are going to be updated with = the audio of meetecho.=C2=A0

Best,


2014-07-24 11:21 GMT-04= :00 peter van der Stok <stokcons@xs4all.nl>:
Peter van der Stock indicate= d that you need control over <XXXX ????>.
-> I'm sorry, I don't remember this intervention.


[Pvds] can you send e-mail? XXXX
=C2=A0 =C2=A0 =C2=A0 =C2=A0(was re: Autonomic/ANIMA)
-> I said probably "many thanks"

Michael Richardson schreef op 2014-07-24 16:45:
many thanks to Thomas. =C2=A0Please /XXX for pieces that might need comment= , here
they are:
=C2=A0 =C2=A0 - Peter van der Stock indicated that you need control over &l= t;XXXX ????>.
=C2=A0 =C2=A0 =C2=A0 Changed SHOULD to MAY

=C2=A0 =C2=A0 - [Pvds] can you send e-mail? XXXX
=C2=A0 =C2=A0 =C2=A0 (was re: Autonomic/ANIMA)


I'm not sure what "poipoi" means.


1300-1500 EDT Wednesday Afternoon Session I
Territories room

Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/=
Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ie= tf-90-roll
Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll
Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/= ietf907.m3u

ROLL (Routing Over Low Power and Lossy Networks)

Agenda
------

- State of all drafts (5min)
- Related Internet-Drafts
- State of all Issues (3min)
- Updates to Milestones, Schedule and Practice (5min)
- Feedback from Plugfest Event (5min)
- Updates on: draft-ietf-roll-security-threats (10min)
- Updates on: draft-ietf-roll-mpl-parameter-configuration (15min) - Updates on: draft-ietf-roll-admin-local-policy (15min)
- Updates on: draft-ietf-roll-applicability-template. (5min)
- Updates on: draft-ietf-roll-applicability-ami (10min)
- Updates on: draft-thubert-6man-flow-label-for-rpl (15min)
- Open floor (15 minutes)

Minutes
-------

- _[1300]_ Meeting starts
=C2=A0 =C2=A0 - **[Ines]** starts the meeting
=C2=A0 =C2=A0 - reminds note well
=C2=A0 =C2=A0 - meetecho available, minutes taken, Jabber as well
=C2=A0 =C2=A0 - presents agenda

- _[1302]_ State of all drafts **(poipoi)**
=C2=A0 =C2=A0 - Ines reminds status of drafts on sldies
=C2=A0 =C2=A0 - Ines presents related I-D not adopted yet
=C2=A0 =C2=A0 - Ines presents open tickets (see slides). Some work needed o= n the open
=C2=A0 =C2=A0 =C2=A0 tickets.
=C2=A0 =C2=A0 - Ines presents milestones. Industrial applicability is behin= d.

=C2=A0 =C2=A0 -Ines: need to decide whether nee to recharter or close.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0After work on MPL done,

- Related Internet-Drafts **(poipoi)**
=C2=A0 =C2=A0 - poipoi
- _[1305]_ State of all Issues **(poipoi)**
=C2=A0 =C2=A0 - poipoi
- _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)**
=C2=A0 =C2=A0 - poipoi
- _[1315]_ Feedback from Plugfest Event **(poipoi)**
=C2=A0 =C2=A0 - Thomas presents
=C2=A0 =C2=A0 =C2=A0 - Updates on: draft-ietf-roll-security-threats = **(Michael Richardson)**
=C2=A0 =C2=A0 - security applicability review.
=C2=A0 =C2=A0 =C2=A0 There was some lack of understanding amoung reviewers = about the
=C2=A0 =C2=A0 =C2=A0 relationship between documents. =C2=A0After some voice= communications, we
=C2=A0 =C2=A0 =C2=A0 agreed that we needed to be more explicit about the re= latinoship to
=C2=A0 =C2=A0 =C2=A0 other documents. Peter van der Stock proposed some tex= t which is now in
=C2=A0 =C2=A0 =C2=A0 different documents
=C2=A0 =C2=A0 - Michael presents threats document

=C2=A0 =C2=A0 - secu area review about sec doc (september 2013). Very good = reivew.
=C2=A0 =C2=A0 Some tickets were opened. Lots got fixed. Robert Cragie found= innaccuracies
=C2=A0 =C2=A0 and things tha didn't make sense. Tickets got opened and = fixed
=C2=A0 =C2=A0 The -08 uploaded on Monday July 21. Use the diff tool to see = the
=C2=A0 =C2=A0 changes.
=C2=A0 =C2=A0 This document went through WGLC in Feb. Robert Cragie looked = at it before
=C2=A0 =C2=A0 sending to Adrian. Button pushed on Monday!!!!, should be dis= cussed at
=C2=A0 =C2=A0 IESG soon. =C2=A0This has been a long (3 year) process.
=C2=A0 =C2=A0 Will be nice to have done.

=C2=A0 =C2=A0 - one of the things that came up is that we have a number of = messages
=C2=A0 =C2=A0 =C2=A0 in ROLL which are important and multicast.
=C2=A0 =C2=A0 =C2=A0 From DICE, we know that secuirty multicast is tricky.<= br> =C2=A0 =C2=A0 =C2=A0 With symmetric keying, members can impersonate. =C2=A0= Pieces in ROLL are not
=C2=A0 =C2=A0 =C2=A0 as strong as they could be as a result.
=C2=A0 =C2=A0 -We clarified some of the text. Affects people that have a group-shared L2 key
=C2=A0 =C2=A0 which is the same across the entire network. If you have a L2= master key
=C2=A0 =C2=A0 from which link messags are derived, you can do something dif= ferent.
=C2=A0 =C2=A0 Ultimately, when multicast, you need to use key that all can = read.
=C2=A0 =C2=A0 This is something we clarified.
=C2=A0 =C2=A0 =C2=A0 - although DISare multicast, it's a "please a= nswer me".
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The effect is that a timer goes faster. Not a h= uge deal if impersonated.
=C2=A0 =C2=A0 - DIOs, if they are impersonated, that's an issue.
=C2=A0 =C2=A0 =C2=A0 One of the defenses is that is to unicast a DIS back, = so mote sends a
=C2=A0 =C2=A0 =C2=A0 DIO again. =C2=A0 There is a workaround for the parano= id.

(Ines reminds about blue sheets)

- Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke = Doi)**
=C2=A0 =C2=A0 - draft tp [ropose DHLC option to configureMPL
=C2=A0 =C2=A0 - idea: control MPL. Used in smart meter network. Intended fo= r slow
=C2=A0 =C2=A0 =C2=A0 update of MPL forwarded. Because MPL trickle algo has = control between
=C2=A0 =C2=A0 =C2=A0 network usage and MPLlatency,this is a tradeoff.

=C2=A0 =C2=A0 =C2=A0-parameter should be modifiable.

=C2=A0 =C2=A0 - updated the draft to -01 weeks before the IETF meeting.
=C2=A0 =C2=A0 =C2=A0 Asking ROLL and DHC WG for feedback. DHC gave feedback= .
=C2=A0 =C2=A0 =C2=A0 -02 on Monday.
=C2=A0 =C2=A0 - operational considerations were added. What happens when =C2=A0 =C2=A0 =C2=A0 =C2=A0MPL parameters were changes when MPL network is = running
=C2=A0 =C2=A0 - Peter van der Stock indicated that you need control over &l= t;XXXX ????>.
=C2=A0 =C2=A0 =C2=A0 Changed SHOULD to MAY

=C2=A0 =C2=A0 - Asks WG for feedback. Please give review on these sentences=

=C2=A0 =C2=A0 -last week, lots of feedback from DHC. Most concern idea to m= ake timer
=C2=A0 =C2=A0 =C2=A0 in floating point. Didn't like that. Changed the f= ormat, simplified.
=C2=A0 =C2=A0 - Yusuke presents the format of the packets. the unit of the = time is
=C2=A0 =C2=A0 =C2=A0 =C2=A0added to the packet. e.g.of tunit is 100,timer i= s 100ms. timers in uint16
=C2=A0 =C2=A0 =C2=A0 - [MR] like floating point, but easily absorbed?
=C2=A0 =C2=A0 =C2=A0 - [YD] encoding is simple
=C2=A0 =C2=A0 =C2=A0 - [MR] for unknown options on DHCP server,people will = have to calculate
=C2=A0 =C2=A0 =C2=A0 the hex anyway...
=C2=A0 =C2=A0 =C2=A0 - [YD] believe almost all implementers don't need = to worry about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this. Wrote Python code to generate this
=C2=A0 =C2=A0 - mostly clients have to worry about this
=C2=A0 =C2=A0 - very simple and straight forwards. Needs experience and fee= dback on
=C2=A0 =C2=A0 =C2=A0 =C2=A0range fo timers
=C2=A0 =C2=A0 - current specification is only able to go up to 4.6 hours. =C2=A0 =C2=A0 =C2=A0 Not sure if enough for all of usages, including expira= tion timers.
=C2=A0 =C2=A0 =C2=A0 If we need larger duration, need to think again on the= se timers
=C2=A0 =C2=A0 - message: please give meyour feedback.
=C2=A0 =C2=A0 - <no feedback from the room>
=C2=A0 =C2=A0 - Ines asks to read the drafts and comment on ML

- _[1325]_ Updates on: draft-ietf-roll-admin-local-policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0**(Peter van der Stok)**
=C2=A0 =C2=A0 - draft is about having admin local be automatically determin= ed
=C2=A0 =C2=A0 - multiple: realm-local scope, link-local and admin-local
=C2=A0 =C2=A0 - different topologies possible
=C2=A0 =C2=A0 - linklocal scope: automatically determined, single hop
=C2=A0 =C2=A0 -real: local: automatically, determined by L2
=C2=A0 =C2=A0 - admin-local: multiple hop, include different L2 networks. =C2=A0 =C2=A0 - wish is that it would be automatically discovered
=C2=A0 =C2=A0 - idea is that we have 2 router: one standard, and one router= has MPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0router with MPL forwarded. They all subsc= ribe to
ALL_MPL_FORWARDER scope 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and 4
=C2=A0 =C2=A0 - about MPL routers, assuming R1 and R2, assuming they have 2= mesh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0networks
=C2=A0 =C2=A0 =C2=A0 What we want to do is have an MPL scope which includes= mesh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 networks but excludes <the enterprise/home/e= tc.>
=C2=A0 =C2=A0 - introduce boolean flag call MPL blocked.
=C2=A0 =C2=A0 - we use protocol to determine whether should be true or fals= e
=C2=A0 =C2=A0 - start with MPLlock false. at least every hour, send an MPL = message to
=C2=A0 =C2=A0 =C2=A0 MPL_FORWARDEDS_SCOPE. If no get message back, no inter= ested nodes on that
=C2=A0 =C2=A0 =C2=A0 line,
=C2=A0 =C2=A0 - query for nodes are interested, if none, close and don'= t use
=C2=A0 =C2=A0 - result is that some interfaces are enabled (to the mesh), =C2=A0 =C2=A0 =C2=A0 disabled (to the Northbound)
=C2=A0 =C2=A0 - allows to automatically determine MPL zone
=C2=A0 =C2=A0 -if you have an egde router, you should false interface to bl= ock
=C2=A0 =C2=A0 - [Pascal]flow reminds in autonomic, see BoF.Encourages to AN= IMA.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Probably you could propose this there. =C2=A0 =C2=A0 - [Pvds] can you send e-mail? XXXX
=C2=A0 =C2=A0 - [Michael] could you derive the 1h period, i.e. 3 Imax. If i= t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can't maybe you have a = new parameters forthat other doc.
=C2=A0 =C2=A0 - [Pvds] good suggested
=C2=A0 =C2=A0 - need also security section

- _[1400]_ Updates on: draft-ietf-roll-applicability-template.
=C2=A0- see beginning

- Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** =C2=A0 =C2=A0 - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.= 2
=C2=A0 =C2=A0 - [Micheal] which issues are open?
=C2=A0 =C2=A0 - [Daniel] open tickets:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - #135, missed pointer to security section of R= FC6550
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- #136 add a section on security c= onsideration when RPL security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms a= re not used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- #137 incorporate a model for ini= tial and incremental
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deployments.= Added section 9.1. and 9.2. For #136
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and #137 wil= l ask the WG to what we can change in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft on wha= t we can change
=C2=A0 =C2=A0 - [Michael] excellent

- _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poip= oi)**
=C2=A0 =C2=A0 - when started RPL, idea what to transport Hop by hop in flow= label.
=C2=A0 =C2=A0 =C2=A0 6man was redefining how it wouldoperate. At roll, we c= reated hop by hop
=C2=A0 =C2=A0 =C2=A0 header in RFC6583. Header cannot be compressed
=C2=A0 =C2=A0 - if a frame is coming from outside the RPL domain, you need = to
=C2=A0 =C2=A0 =C2=A0 encapsulate the packet in IP-in-IP to be able to send = back ICMP
error and be
=C2=A0 =C2=A0 =C2=A0 able to strip it
=C2=A0 =C2=A0 - these are many bit that we don't want to 802.15.4-2006 = MAC
=C2=A0 =C2=A0 - when worked in ISA100.11a, worked hard to eliminate in sing= le bit. Real
=C2=A0 =C2=A0 =C2=A0 war to remove UDP checksum. Just for 2 bytes. This was= key to the adoption
=C2=A0 =C2=A0 =C2=A0 of 6LoWPAN.
=C2=A0 =C2=A0 - here, we are talking about 5+ octets: not acceptable
=C2=A0 =C2=A0 - what important in 6282 compressed in the 2 bits which indic= ates how
=C2=A0 =C2=A0 =C2=A0 6LoWPAN compresses the flow label and traffic class. w= e can have
flow label
=C2=A0 =C2=A0 =C2=A0 with or without DSCP

=C2=A0 =C2=A0 - proposed encoding fits in the 20 bits of the flow label. We= are
=C2=A0 =C2=A0 =C2=A0 to replace 5 bytes by 20 bits. Rank expressed as 8 bit= es. You
need to have a
=C2=A0 =C2=A0 =C2=A0 deployment with a min hop of 256.
=C2=A0 =C2=A0 -[Michael]you are using upper 8 bits of rank?
=C2=A0 =C2=A0 - [PT] yes. You can compress the rank in single octet. Descri= bed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OF0, operates wih minhop rank of 2= 56
=C2=A0 =C2=A0 - RPL was prepared for this. Text says that 6583 is only one = was. WE went
=C2=A0 =C2=A0 =C2=A0 to ROLL and 6man with this. Brian Carpenter has good r= esponse. Idea is to
=C2=A0 =C2=A0 =C2=A0 have a WGLC in this group, then a confirmation WGLC fr= om 6man to make sure
=C2=A0 =C2=A0 =C2=A0 they agree.
=C2=A0 =C2=A0 - if a packet has to come from the outside, it's responsi= bility of the
=C2=A0 =C2=A0 =C2=A0 root to add flow label that makes sense
=C2=A0 =C2=A0 - Adrian was help out
=C2=A0 =C2=A0 - draft has been out there for year.
=C2=A0 =C2=A0 - [MR] feeling is that this is something we should adopt and = seems that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can close to WGLC even with this d= ocument. Pascal, agree?
=C2=A0 =C2=A0 - [PT] yes, different revisions from different WGs
=C2=A0 =C2=A0 - [MR] is there a technical reason to adopt before publshing?=
=C2=A0 =C2=A0 - [Adrian] yes you can, the WG can support a draft with a nam= e that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't start wi= th WG name. People who think you should
not be working
=C2=A0 =C2=A0 - [Michael] will write line in charter? =C2=A0Will talk to 6m= an chairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to make sure
=C2=A0 =C2=A0 - [PK] chair fo ISA100.11a. Fought over every bytes. As vice = chair of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0802.15, there is a reason why we d= on't haev longer packets.
Shorter packets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0means less energy and better proba= bility. Both hats say
that this is what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we need
=C2=A0 =C2=A0 - [Pascal] we have running code for thos, Xavi demonstration = de draft on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenWSN implementation. Screenshot= indicate wireshark,. You
don't have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0H2H header, was implemented very r= apidly in OpenWSN

- _[1448]_ Open floor **(poipoi)**
=C2=A0 =C2=A0 - Ines asks AOB
=C2=A0 =C2=A0 - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client = can be a
=C2=A0 =C2=A0 leaf in a RPLnetwork. Today, all devices have to have code sp= ecific to RPL.
=C2=A0 =C2=A0 A better idea is that you have what is necessary in 6LoWPAN, = so that6LoPWAN
=C2=A0 =C2=A0 device can be a lieaf of a RPL network. THere is a need for a= classical IP
=C2=A0 =C2=A0 host and moile hist. Invite you to 6lo.
=C2=A0 =C2=A0 - as we work on 6TiSCH, there is a case where a node moves. =C2=A0 =C2=A0 We would have work on how to clean upstate route. Aswecharter= ed?
=C2=A0 =C2=A0 - [MR] cleaning up stale motes is in charter, but depends on = milestones.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Let's take to ML to have a better und= erstanding on what this means. The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0question is what the impact is on node wh= ich don' have the code.
=C2=A0 =C2=A0 - [Pascal] additional functionality
=C2=A0 =C2=A0 =3D[MR] then this might fit in maintenance.
=C2=A0 =C2=A0 - [MR]any other elements in open mic?
=C2=A0 =C2=A0 - [Peter] will there be any other ROLL meetrings?
=C2=A0 =C2=A0 =3D- [MR] opinion is that not in Honolulu. We have the home a= utomation,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 threads, and AMI document which seems close to = done. Unless we
do somethng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that expands the charter, don't see a reaso= n to meet again
before closing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the WG. Of course, AD could put WG in maintenan= t mode. =C2=A0Maybe
will becomes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 controversial and we need F2F meeting.
=C2=A0 =C2=A0 - [PT]what would help you make that decision? 6TiSCH might co= me up with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 elements, and we would need ROLL to be t= here.
=C2=A0 =C2=A0 - [MR]good idea, send question. We could go in hibernation an= d resume
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when needed.
=C2=A0 =C2=A0 - [PT] plan is to fire a number of drafts, and when
=C2=A0 =C2=A0 - [MR] better now than in december
=C2=A0 =C2=A0 - [Ultich] personally, don't feel 6lo is right WG because= not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 always RPL.
=C2=A0 =C2=A0 - [MR] we could go to the routing Area WG
=C2=A0 =C2=A0 - [Adrain] good point. It's ok for WG to say that shut do= wn. It's nicer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to close the WG and create a new W= G when needed. Not a good
idea to have WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sitting around. AD can sponsor doc= uments. Do we need a
forum for discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and driving the work? If yes, we&#= 39;ll create a spacefor it.
=C2=A0 =C2=A0 - [Ines] there were e-mails about open topics. We need to wor= k on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issues before rechartering/= closing.




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =C2=A0 =C2=A0http://datatracker.ietf.org/wg/r= oll/charter/


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

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

--e89a8f647193fc146404fef21e9e-- From nobody Tue Jul 29 10:25:47 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412211B290A for ; Tue, 29 Jul 2014 10:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZskif8PEiML for ; Tue, 29 Jul 2014 10:25:43 -0700 (PDT) Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0781B2919 for ; Tue, 29 Jul 2014 10:25:42 -0700 (PDT) Received: from gates-ap-275.stanford.edu ([171.64.70.25]:54429 helo=[10.171.216.192]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCB9f-0003V4-Hm; Tue, 29 Jul 2014 10:25:40 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <538302CC.9020904@toshiba.co.jp> Date: Tue, 29 Jul 2014 10:25:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 143d975f4418483bad6282b216f6b212 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/r0DpyxRsMl4RYde_CXJS2xelNkI Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 17:25:45 -0000 On May 26, 2014, at 2:01 AM, Yusuke DOI = wrote: > Hi, >=20 > Thank you for summarizing issues on my draft. > On #157, my understanding is as follows. If there are any issues you = know, please let me know. >=20 > Inconsistent but valid parameter does not harm the network much (it = may harm battery-powered nodes). Given the L in RPL/MPL includes the term "low power", harming = battery-powered nodes is kind of important. It's easy to try to ignore = them because they're so challenging, but I'd strongly recommend against = it. >=20 > Reason: >=20 > 1) If a node have smaller Imin/Imax, it takes more responsibility to = repeat messages than surrounding nodes. The node will consume more power = and the area will have higher traffic than expected until MPL parameters = of the node is updated. It's worth noting that transmission (in most link layers MPL/RPL care = about) does not consume significantly more energy than reception. = Therefore, one node that has a smaller Imin or Imax introduces an energy = cost on *all* of the nodes around it. A smaller Imin can double the latency of propagation over a single hop, = as nodes, on receiving an update, receive multiple Trickle messages and = so suppress for their first interval. Depending on K, a difference in Imax can do more than just = increase/reduce responsibility. It could actually lead to complete = suppression. Consider the case where three nodes have Imax=3Dt and one = node has Imax=3Dt+2 (so the actual time interval is 4 times greater). = K<=3D3. The three nodes will almost always completely suppress the = fourth node with the longer interval. > 2) If a node have larger Imin/Imax, it takes less responsibility to = send messages than surrounding nodes. As other nodes will send the = message instead of the node with old parameters, effect for traffic load = and e2e delay is negligible on dense mesh clusters. If the node with old = parameters is on sparse area of a mesh network, larger Imin/Imax will = cause larger e2e delay than new parameter's expectation untilthe node is = updated. You should disambiguate the effects of Imin and Imax.=20 > 3) If a node have smaller K, it takes less responsibility to repeat = messages than surrounding nodes. On dense network, the effect is = negligible. On sparse network, messages pass through the node will have = less reliability until the node is updated. It also introduces uneven transmission load. A node with a higher K will = transmit with a much higher probability that those with the lower K = (within the logarithmic bounds introduced by packet loss). I'd suggest re-reading 6206 (Section 6), which goes into greater detail = than the bullet points above and is much more specific. > 4) If a node have larger K, it will repeat almost all the messages. = The area will have excessive traffic untile the node is updated. >=20 This is not true. Note that packet loss/imperfect duplicate = suppression/uneven topologies often cause some nodes to receive more = than K packets. Again, I'd suggest re-reading 6206. Phil= From nobody Tue Jul 29 14:21:34 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EBF1A0178; Tue, 29 Jul 2014 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXb0jVXj5lSM; Tue, 29 Jul 2014 14:21:30 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB5C1A00E1; Tue, 29 Jul 2014 14:21:29 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so478010vcb.28 for ; Tue, 29 Jul 2014 14:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VurvvMSvsEsXETzvDQf6iZ4tOt4HbA7Ogv2j4PWP528=; b=fWvu4kWVGNhjH+U58TZz/ugNj6WAx0WDl/Bs+Zs06EJy5CANymDC4uErq2rSjOKdJo R+WuCWhM44Pme4JX22ntbMW+OsdgtjbrQ4KSLWWMYA1zlVBDDsrgEyI7w3ltQMl8LXtf mbzlScvpS52EVKmY+Y2kBZny4jMo2fnADYlbrx+Xdh9jt9Q3M7mdN7Ow4WiSfkztXgXR TzCEwc43Rm1CJb48RqVIUhjE5daIY/GjAFu/hOZ8kG2fTQ5ByekZgXVn67kIveQ/mbXI ZwSnulRPpJFWNHdrOLC2b0v5kWH78nhlZeZq0Ddtv38uMv6gwz3SHu0MDK/lhsNH2sj+ PStQ== MIME-Version: 1.0 X-Received: by 10.52.251.195 with SMTP id zm3mr3900030vdc.36.1406668888995; Tue, 29 Jul 2014 14:21:28 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Tue, 29 Jul 2014 14:21:28 -0700 (PDT) Date: Wed, 30 Jul 2014 00:21:28 +0300 Message-ID: From: Ines Robles To: "ipv6@ietf.org" , roll Content-Type: multipart/alternative; boundary=001a1136030a71ffe304ff5b9f48 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/pk6SPBXCPQM3XXCex3TWX9pBsM8 Cc: Brian Haberman , Michael Richardson , Bob Hinden , Ole Troan , Alia Atlas Subject: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:21:31 -0000 --001a1136030a71ffe304ff5b9f48 Content-Type: text/plain; charset=UTF-8 Dear 6man and roll WGs, We announce a joint Working Group Last Call for draft-thubert-6man-flow-label-for-rpl-03 , since this document is related to both WGs, we ask for comments to 6man and roll members. We are going to request for an AD sponsored document. This WGLC is going to take from 07/30/2014 to 08/13/2014. Thank you very much, 6man and roll chairs. --001a1136030a71ffe304ff5b9f48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear 6man and roll WGs,

We announce a j= oint Working Group Last Call for=C2=A0draft-thubert-6man-flow-label-fo= r-rpl-03, since this document is related to both WGs, we ask for commen= ts to 6man and roll members. We are going to=C2=A0request for an AD sponsored document.

This WGLC is going to take from 07/30/2014 to 08/13/201= 4.

Thank you very much,

6man and roll chairs.


--001a1136030a71ffe304ff5b9f48-- From nobody Tue Jul 29 17:02:41 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBC1B2A28; Tue, 29 Jul 2014 17:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9CpefRPLJkK; Tue, 29 Jul 2014 17:02:23 -0700 (PDT) Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B94A1A038D; Tue, 29 Jul 2014 17:02:23 -0700 (PDT) Received: from [76.14.66.110] (port=55794 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCHLY-0004Ah-A0; Tue, 29 Jul 2014 17:02:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Tue, 29 Jul 2014 17:02:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> References: To: Ines Robles X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 1620fcb02ed1792cf65161168a9fe1e9 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Th2NnqLiNx1QJuyhHHqH7D2yefA Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Bob Hinden , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 00:02:27 -0000 On Jul 29, 2014, at 2:21 PM, Ines Robles = wrote: > Dear 6man and roll WGs, >=20 > We announce a joint Working Group Last Call for = draft-thubert-6man-flow-label-for-rpl-03, since this document is related = to both WGs, we ask for comments to 6man and roll members. We are going = to request for an AD sponsored document. >=20 > This WGLC is going to take from 07/30/2014 to 08/13/2014. >=20 > Thank you very much, I'm worried by the fundamental premise of the approach: "The 8-octets overhead is detrimental to the LLN operation, in = particular with regards to bandwidth and battery constraints. The extra = encapsulation may cause a containing frame to grow above maximum frame = size, leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in = turn cause even more energy spending and issues discussed in the LLN = Fragment Forwarding and Recovery = [I-D.thubert-6lo-forwarding-fragments]." The basic assumption of this paragraph is that energy consumption is = dominated by transmission time. Has anyone presented any actual evidence = -- i.e., actual energy numbers -- of the cost this introduces?=20 Because "This specification suggests that energy-saving is another compelling = reason for a violation to the aforementioned rule." makes the assumption that the energy saving is significant. Breaking the = end-to-end nature of the flow label for some tiny saving seems like a = mistake. But if this would actually save a significant amount of energy = that couldn't be saved through other, simpler, means, then it seems like = a great idea. My fear is that this area -- low-power link layers, energy saving = protocols -- is an area that is still new to the IETF and tends to have = very subtle issues. What's being proposed here is pretty significant. = Simple, intuitive arguments might not hold up to scrutiny in real = networks. If you look at it in this light, one comment the draft makes is = especially troubling: "But if we consider the whole RPL domain as a large virtual host from = the standpoint of the rest of the Internet" This is completely contrary to the deep, fundamental premise of the = Internet of Things and when we started down the path of bringing IPv6 to = LLNs. Before 6lowpan, LLN devices were typically considered peripherals, = devices that connect to an Internet host through other interfaces and = protocols (USB, ZWave, ZigBee, etc., etc.). This gave greater = flexibility on what those networks could do, but it placed a hard = barrier on the Internet. You needed new tools, management interfaces, = software, and policies for managing the two sides of the network. E.g, = you manage your IP network and separately manage your embedded network. = The big promise of 6lowpan and all of the subsequent technologies the = IETF has developed is that instead, we can consider it IP down into = these networks as well. Considering an entire LLN as a virtual host goes = back to this segmented model, and so is a step backwards. In summary, this draft presents a tradeoff: break the end-to-end = behavior of the flow label for improved energy efficiency. I'd argue = strongly in favor of this draft if "improved" meant "doubles". But if it = means "5% in 1% of use cases", this seems like a poor tradeoff. The IETF = 90 slides say it's a "show stopper" for SDOs. I'm not sure what that = means? Is there any greater detail on this? I'd like to make an informed = engineering decision, but don't have enough data to do so. Phil= From nobody Tue Jul 29 22:01:34 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0109D1A0AC7; Tue, 29 Jul 2014 18:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaYwcBlOfV8J; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942F81A04B8; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wm4so92488obc.41 for ; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yrQ9LoTrf1Q4U9V34/5txGmGYjCRtxv9TwB0OnBOpb8=; b=WcysxmVcch3hDugj5Df2Q0QUtgu4644Rdnel+DkA0UbT5kR3bdCtVGhV/ATJX4I1CO lwwM+EhBznzy7HrmpPAz3J+KjeVkS24QqfNInzwOA9ewLtJddqDJu0hW0IH2cQaPk6WG +IOttgfG9G2gI2jcL+dGk5sO4MrLFnZza5O6sJagldQ6xxJ1ef4DDTaFd7ZqIz5hdc24 fKaFn513MXDKP15APANftOaQF7btdjHzV+JE89PJP/GY00BncQOx1Kdi//oJVe2odbbQ sv6CdGOaQN55xHLm7QdfuRJJ7pv+eIBfxG1unFrb/RFWVW5EWUoBcI4ZrXx9SJA5HmG3 e/OA== X-Received: by 10.182.113.199 with SMTP id ja7mr556539obb.74.1406684203040; Tue, 29 Jul 2014 18:36:43 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id d3sm3031667oez.5.2014.07.29.18.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 18:36:42 -0700 (PDT) Message-ID: <53D84C2C.9050709@gmail.com> Date: Wed, 30 Jul 2014 13:36:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> In-Reply-To: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/1WHxGkqbOwKuFKSdh_9wuU7q4_8 X-Mailman-Approved-At: Tue, 29 Jul 2014 22:01:33 -0700 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 01:36:45 -0000 On 30/07/2014 12:02, Philip Levis wrote: ... > "This specification suggests that energy-saving is another > compelling reason for a violation to the aforementioned > rule." > > makes the assumption that the energy saving is significant. > Breaking the end-to-end nature of the flow label for some > tiny saving seems like a mistake. I can't evaluate whether the energy saving is significant. However, I don't have any deep faith in the e2e-ness of the flow label. The reality (as RFC 6437 tries to recognise) is that it's a mutable field, and is therefore untrustworthy for e2e use. It has value for load balancing if all packets of a given flow have the same label, whether the label is set by the source or by a border device. For that reason, I think the usage proposed in this draft is OK. However, I do agree that at least a hand-waving estimate of the % energy saving would be useful. Brian Carpenter From nobody Wed Jul 30 02:29:35 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA121B2A35 for ; Wed, 30 Jul 2014 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCO5HV73Pncq for ; Wed, 30 Jul 2014 02:29:31 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1421B2A25 for ; Wed, 30 Jul 2014 02:29:30 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s6U9TSf1017359 for ; Wed, 30 Jul 2014 18:29:28 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s6U9TSZs027697 for roll@ietf.org; Wed, 30 Jul 2014 18:29:28 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA27695; Wed, 30 Jul 2014 18:29:28 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s6U9TRUg004656 for ; Wed, 30 Jul 2014 18:29:27 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6U9TROo006660; Wed, 30 Jul 2014 18:29:27 +0900 (JST) Received: from [133.196.16.151] (ncg-dhcp151.isl.rdc.toshiba.co.jp [133.196.16.151]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C6D8097D33; Wed, 30 Jul 2014 18:29:27 +0900 (JST) Message-ID: <53D8BAF7.8040105@toshiba.co.jp> Date: Wed, 30 Jul 2014 18:29:27 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> In-Reply-To: <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fBvoSifSohZVpjhWEpckfzuT5wI Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 09:29:33 -0000 Phil, Thank you for your kind review. First of all, please let me clarify this effect is transient. Inconsistent parameter shall be avoided but AFAIK we currently have no handy way to change all the parameter in a network at once (at least, in IETF standards). DHCP is basically client-driven update and some transitional inconsistency is inevitable. In addition, the proposal assumes the old and new parameter sets should be reasonable parameters in a transient period. The motivation is to make a slow 'control knob' to handle steadly-changing environments. (2014-07-30 02:25), Philip Levis wrote: > Given the L in RPL/MPL includes the term "low power", harming battery-powered nodes is kind of important. It's easy to try to ignore them because they're so challenging, but I'd strongly recommend against it. Do you strongly recommend synchronized update of parameter set of all nodes in a MPL domain? If so, I'd like to add some way (adding a time to activate/deactivate a parameter, etc). But it may become difficult to operate in standard DHCP context. Thanks for your comments and advices. I admit my argument is not precise and strict. There are some hidden assumptions (for example, our use case is AMI and uneven load was acceptable). I'll add reference to 6206 section 6 as operational considerations. Best Regards, Yusuke From nobody Wed Jul 30 12:11:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00F51A0397 for ; Wed, 30 Jul 2014 12:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sye25nnxF_py for ; Wed, 30 Jul 2014 12:11:11 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89071A0389 for ; Wed, 30 Jul 2014 12:11:11 -0700 (PDT) Received: from [76.14.66.110] (port=59233 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCZHH-0007On-PV; Wed, 30 Jul 2014 12:11:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <53D8BAF7.8040105@toshiba.co.jp> Date: Wed, 30 Jul 2014 12:11:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6420A78D-4C7D-4DDE-8480-3C913F27F0A9@cs.stanford.edu> References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> <53D8BAF7.8040105@toshiba.co.jp> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 34530ccd932157cd24ba9d2c27818ca4 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/9wvb6C2kMvkWUUb6BMfQ-0a_LYo Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:11:13 -0000 On Jul 30, 2014, at 2:29 AM, Yusuke DOI = wrote: > Phil, >=20 > Thank you for your kind review. >=20 > First of all, please let me clarify this effect is transient. = Inconsistent parameter shall be avoided but AFAIK we currently have no = handy way to change all the parameter in a network at once (at least, in = IETF standards). DHCP is basically client-driven update and some = transitional inconsistency is inevitable. In addition, the proposal = assumes the old and new parameter sets should be reasonable parameters = in a transient period. The motivation is to make a slow 'control knob' = to handle steadly-changing environments. >=20 > (2014-07-30 02:25), Philip Levis wrote: >=20 >> Given the L in RPL/MPL includes the term "low power", harming = battery-powered nodes is kind of important. It's easy to try to ignore = them because they're so challenging, but I'd strongly recommend against = it. >=20 > Do you strongly recommend synchronized update of parameter set of all = nodes in a MPL domain? If so, I'd like to add some way (adding a time to = activate/deactivate a parameter, etc). But it may become difficult to = operate in standard DHCP context. >=20 > Thanks for your comments and advices. I admit my argument is not = precise and strict. There are some hidden assumptions (for example, our = use case is AMI and uneven load was acceptable). I'll add reference to = 6206 section 6 as operational considerations. >=20 > Best Regards, Yusuke, Synchronized updates of parameters aren't necessary: the differences = reduce efficiency/load balancing in potentially significant ways over = the long term but not significantly for transient periods. E.g., it = matters in the long term if one node always transmits and another is = always suppressed, but if this happens for some small number of = intervals per configuration change that's not tremendous in practice and = definitely not worth greater complexity. I think the most significant concern is when configuration changes = significantly modify Imin. In this case, the speed of per-hop update can = be bounded by the maximum of the old and new Imin values. E.g., if the = update has a much smaller Imin, then it will trigger nodes with the old = state to use their Imin, but if it's much larger it will take a while = before they transmit and implicitly request an update. Similarly, if the = update has a much higher Imin, it will take much longer for each hop to = transmit the first broadcast that triggers neighbors to shrink their = interval. There's also a potential livelock case with a buggy implementation when = Imin is changed significantly -- the specification notes this with the = clause "If Trickle hears a transmission that is "inconsistent" and I is = greater than Imin, it resets the Trickle timer. " If an implementation = elides the check that I is greater than Imin, then hearing a series of = inconsistent transmissions could cause it to keep on resetting I. Overall, I think the approach is sound and does not warrant any = modifications. I just thought that the operational considerations on = parameter differences were a bit vague and inaccurate. Trickle is on one = hand very simple but on the other very subtle, so anything we can do to = guide people on how to use it is valuable. Thanks! Phil= From nobody Wed Jul 30 12:48:13 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6777A1A035A for ; Wed, 30 Jul 2014 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF8TqhHVxqv8 for ; Wed, 30 Jul 2014 12:48:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E67D1A032E for ; Wed, 30 Jul 2014 12:48:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BBD220028; Wed, 30 Jul 2014 15:50:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2BC5F63B0E; Wed, 30 Jul 2014 15:48:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 17F7D637FE; Wed, 30 Jul 2014 15:48:05 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <6420A78D-4C7D-4DDE-8480-3C913F27F0A9@cs.stanford.edu> References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> <53D8BAF7.8040105@toshiba.co.jp> <6420A78D-4C7D-4DDE-8480-3C913F27F0A9@cs.stanford.edu> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/P1pJt7hUyKs27o2AHcSSSJuZG3Y Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:48:10 -0000 --=-=-= Philip Levis wrote: > I think the most significant concern is when configuration changes > significantly modify Imin. In this case, the speed of per-hop update > can be bounded by the maximum of the old and new Imin values. E.g., if > the update has a much smaller Imin, then it will trigger nodes with the > old state to use their Imin, but if it's much larger it will take a > while before they transmit and implicitly request an update. Similarly, > if the update has a much higher Imin, it will take much longer for each > hop to transmit the first broadcast that triggers neighbors to shrink > their interval. Can you offer any advice for the document on maximum deltas for Imin? (a formula, if necessary) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9lL8oCLcPvd0N1lAQKJ/AgArjvkgFfFdT8aDxkLfcD1ARV2yhD/UV32 YpFzEAsoYJ7ObhXH7o39WhIlAJOWIVA4JhO/wA3x9mKFS8V2G9Ya2mhtCsEGHQYk lBwGrnEpZdZaykaf5mJujjtQHlroQFjvkd41s5lbv4uuUjoDVZ9V5Io0rRToL2px M7XRGQvdiUCl2QH04kZTJmHJLtg4U+sX6U0ym4w2iR/5SNDHMXjj/g9EJefi2pdS FMIw+ZVBQXa3qUJk17igR7LnGUJg1Ipz67OUrQV4ZwgIYvJDJ9uQ7IGq5dfZcrcF /lVrNXHZPcR0CKX6M0yTd8tfh6AZ9WLXfHN0YdJE/IDfDC8eu5Wr5g== =TdVm -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 30 16:59:08 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF63B1A00DB for ; Wed, 30 Jul 2014 16:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk7y1Cf6rYnQ for ; Wed, 30 Jul 2014 16:59:04 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AF21A00A5 for ; Wed, 30 Jul 2014 16:59:04 -0700 (PDT) Received: from [76.14.66.110] (port=61966 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCdls-0001sT-4M; Wed, 30 Jul 2014 16:59:01 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <21697.1406749685@sandelman.ca> Date: Wed, 30 Jul 2014 16:58:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> <53D8BAF7.8040105@toshiba.co.jp> <6420A78D-4C7D-4DDE-8480-3C913F27F0A9@cs.stanford.edu> <21697.1406749685@sandelman.ca> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/1PCZiD9eWSDS51W26YdOCb5pW2o Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 23:59:06 -0000 On Jul 30, 2014, at 12:48 PM, Michael Richardson = wrote: >=20 > Philip Levis wrote: >> I think the most significant concern is when configuration changes >> significantly modify Imin. In this case, the speed of per-hop update >> can be bounded by the maximum of the old and new Imin values. E.g., = if >> the update has a much smaller Imin, then it will trigger nodes with = the >> old state to use their Imin, but if it's much larger it will take a >> while before they transmit and implicitly request an update. = Similarly, >> if the update has a much higher Imin, it will take much longer for = each >> hop to transmit the first broadcast that triggers neighbors to shrink >> their interval. >=20 > Can you offer any advice for the document on maximum deltas for Imin? > (a formula, if necessary) I don't think there are any. If you want to change Imin from a to b, = then the most efficient way to do so is to do it in one update. I.e., = you won't gain any efficiency by staging it in a series of updates = (you'll have log(max(a/b, b/a)) wasted transmissions). If you gotta = change Imin, you gotta change it. But it's just useful to know the = implications of doing so. Perhaps the one recommendation is that you should be careful setting = Imin to a large value. If you accidentally set it very high, then it's = going to bound the speed by which you can fix your mistake. E.g., = imagine you by accident set Imin to an hour then find that something = starts going wrong with your network over the next few hours. It'll take = that long to undo the change because propagation can be bounded by the = maximum of the new and old values. Phil= From nobody Thu Jul 31 15:13:11 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8463F1A01D6; Thu, 31 Jul 2014 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ0FDCJq_YdI; Thu, 31 Jul 2014 15:11:27 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085831A01CB; Thu, 31 Jul 2014 15:11:27 -0700 (PDT) Received: from [76.14.66.110] (port=50440 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XCyZH-00082Z-0U; Thu, 31 Jul 2014 15:11:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <53D84C2C.9050709@gmail.com> Date: Thu, 31 Jul 2014 15:11:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 3912120d3a1bcf28d29a6770933a4e79 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/IPTO2d3w2u-0qPtDS4mh2Fo5oc4 X-Mailman-Approved-At: Thu, 31 Jul 2014 15:13:01 -0700 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:11:30 -0000 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter = wrote: > On 30/07/2014 12:02, Philip Levis wrote: > ... >> "This specification suggests that energy-saving is another >> compelling reason for a violation to the aforementioned >> rule." >>=20 >> makes the assumption that the energy saving is significant. >> Breaking the end-to-end nature of the flow label for some >> tiny saving seems like a mistake.=20 >=20 > I can't evaluate whether the energy saving is significant. > However, I don't have any deep faith in the e2e-ness of the > flow label. The reality (as RFC 6437 tries to recognise) > is that it's a mutable field, and is therefore untrustworthy > for e2e use. It has value for load balancing if all packets > of a given flow have the same label, whether the label is > set by the source or by a border device. For that reason, > I think the usage proposed in this draft is OK. >=20 > However, I do agree that at least a hand-waving estimate of > the % energy saving would be useful. >=20 > Brian Carpenter *shrug* My thoughts are pretty simple. I'm sure you know all this (as = one of the authors!) but I'll revisit for everyone else's sake. 6437 = states "A forwarding node MUST either leave a non-zero flow label value = unchanged or change it only for compelling operational security reasons = as described in Section 6.1." So, this is a MUST. Either the RPL flow label draft contradicts 6437 = (and should say so explicitly), or there should be an explicit update to = 6437. In fact, the current draft is misleading and incorrect. It says "but the RFC also indicates a violation to the rule can be accepted for = compelling reasons, and that security is a case justifying such a = violation. This specification suggests that energy-saving is another = compelling reason for a violation to the aforementioned rule." This is *not* what 6437 says. It says for compelling operational = security reasons, not compelling reasons, of which one case is security. Having been researching, implementing, and deploying low-power protocols = for over a decade, I've become exceedingly skeptical when someone = proposes a protocol with energy as a motivation without quantifying it. = For example, there are tons of protocols in the research literature = which talk about using transmission power control to save energy = (trading off range for power). But almost all of these papers ignore the = fact that (unlike mobile/cellular systems, which the authors have been = publishing in for years) RF is a tiny sliver of power in low-power = networks. So reducing your transmission (RF) power by 99% only reduces = your radio power by 50%. Generally a losing proposition. This is the = same reason why power saving in WiFi involves synchronization on AP = beacons and not adjusting transmit power. If someone doesn't quantify = the potential benefit based on real hardware and protocols, then it = could be based on mistaken assumptions. I mean, it doesn't take much here. Start with a working low-power RPL = network. Send packets with sizes following a reasonable distribution = based on an actual application. In one experiment send just those = packets. In another add the 8 bytes. In a third add 8 + the IP-in-IP = encapsulation. Measure the energy cost. And, generally speaking, if you can't demonstrate the problem very = easily, then perhaps it isn't a real problem at all. All that being said, I think using the flow label in this way is a good = idea, and definitely valuable. But as it is now, doing so violates 6437, = and so the assumptions implementers make when reading 6437. I think the = bar for doing so should be high, higher than vague suggestions and hand = waving which might not be correct. Phil