From nobody Sat Aug 1 01:36:51 2015 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 76C9F1B2B0B for ; Sat, 1 Aug 2015 01:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 sssAfl0o816v for ; Sat, 1 Aug 2015 01:35:59 -0700 (PDT) Received: from itu3out.svc.unicc.org (itu3out.svc.unicc.org [206.155.102.66]) (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 87EEF1AD0D1 for ; Sat, 1 Aug 2015 01:35:59 -0700 (PDT) Received: from TUCM03.TUECSP.UNICC.ORG (unknown [10.81.38.70]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iccpfxor03.svc.unicc.org (Postfix) with ESMTPS id F2A2C40698; Sat, 1 Aug 2015 08:35:56 +0000 (UTC) Received: from TUCM02.TUECSP.UNICC.ORG (10.81.6.71) by TUCM03.TUECSP.UNICC.ORG (10.81.38.70) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 1 Aug 2015 08:35:55 +0000 Received: from TUCM02.TUECSP.UNICC.ORG ([10.81.6.71]) by TUCM02.TUECSP.UNICC.ORG ([10.81.6.71]) with mapi id 15.00.1076.000; Sat, 1 Aug 2015 08:35:55 +0000 From: "TSB SG15 Secretariat, ITU" To: Scott Mansfield , "Liaison Statement Management Tool" Thread-Topic: New Liaison Statement, "Response to LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to roll" Thread-Index: AQHQyiZnY4EL1menFEOfciBIgGuBu5321Xtg Date: Sat, 1 Aug 2015 08:35:55 +0000 Message-ID: <2707099479c94e07a1770045a654e386@TUCM02.TUECSP.UNICC.ORG> References: <20150729174543.21912.25744.idtracker@ietfa.amsl.com> In-Reply-To: <20150729174543.21912.25744.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.81.64.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 01 Aug 2015 01:36:50 -0700 Cc: Deborah Brungard , Michael Richardson , Routing Over Low power and Lossy networks Discussion List , Alia Atlas , "scott.mansfield@ericsson.com" , "OTA, Hiroshi" , Ines Robles , "rdroms@cisco.com" Subject: Re: [Roll] New Liaison Statement, "Response to LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to roll" 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, 01 Aug 2015 08:36:02 -0000 RGVhciBTY290dCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGVtYWlsLiBPbiBiZWhhbGYgb2YgSVRV LVQgU3R1ZHkgR3JvdXAgMTUgSSBjb25maXJtIHJlY2VpcHQgb2YgdGhpcyBMaWFpc29uIFN0YXRl bWVudC4NCg0KUmVnYXJkcywNClJvYg0KDQoNClJvYiBDbGFyaw0KVFNCL1NHRA0KSW50ZXJuYXRp b25hbCBUZWxlY29tbXVuaWNhdGlvbiBVbmlvbg0KUGxhY2UgZGVzIE5hdGlvbnMNCkNIMTIxMSBH ZW5ldmEsIFN3aXR6ZXJsYW5kIA0KVGVsOiArNDEgMjIgNzMwIDU0MTUNCnd3dy5pdHUuaW50DQp3 d3cuaXR1LjE1MC5vcmcNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTGlhaXNvbiBTdGF0ZW1lbnQgTWFuYWdlbWVudCBUb29sIFttYWlsdG86bHNtdEBpZXRmLm9y Z10gDQpTZW50OiAyOSBKdWx5IDIwMTUgMTk6NDYNClRvOiBUU0IgU0cxNSBTZWNyZXRhcmlhdCwg SVRVIDx0c2JzZzE1QGl0dS5pbnQ+DQpDYzogSm9obiBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0 PjsgU2NvdHQgTWFuc2ZpZWxkIDxTY290dC5NYW5zZmllbGRARXJpY3Nzb24uY29tPjsgSW5lcyBS b2JsZXMgPG1hcmlhLmluZXMucm9ibGVzQGVyaWNzc29uLmNvbT47IE1pY2hhZWwgUmljaGFyZHNv biA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb20+ OyBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hQGNpc2NvLmNvbT47IERlYm9yYWggQnJ1bmdhcmQgPGRi MzU0NkBhdHQuY29tPjsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3Mg RGlzY3Vzc2lvbiBMaXN0IDxyb2xsQGlldGYub3JnPjsgcmRyb21zQGNpc2NvLmNvbTsgc2NvdHQu bWFuc2ZpZWxkQGVyaWNzc29uLmNvbQ0KU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAi UmVzcG9uc2UgdG8gTFMgb24gY29uY2VybnMgb24gdGhlIGRlcHJlY2F0aW9uIG9mIGRpc3BhdGNo IHR5cGUgaW4gNmxvV1BBTiBhbmQgaXRzIGhlYWRlciBjb21wcmVzc2lvbiBtZWNoYW5pc20gdG8g cm9sbCINCg0KVGl0bGU6IFJlc3BvbnNlIHRvIExTIG9uIGNvbmNlcm5zIG9uIHRoZSBkZXByZWNh dGlvbiBvZiBkaXNwYXRjaCB0eXBlIGluIDZsb1dQQU4gYW5kIGl0cyBoZWFkZXIgY29tcHJlc3Np b24gbWVjaGFuaXNtIHRvIHJvbGwgU3VibWlzc2lvbiBEYXRlOiAyMDE1LTA3LTI5IFVSTCBvZiB0 aGUgSUVURiBXZWIgcGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0 MjYvDQoNCkZyb206IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIChT Y290dCBNYW5zZmllbGQgPFNjb3R0Lk1hbnNmaWVsZEBFcmljc3Nvbi5jb20+KQ0KVG86IElUVS1U IFNHIDE1ICAodHNic2cxNUBpdHUuaW50KQ0KQ2M6IEpvaG4gRHJha2UgPGpkcmFrZUBqdW5pcGVy Lm5ldD4sU2NvdHQgTWFuc2ZpZWxkIDxTY290dC5NYW5zZmllbGRARXJpY3Nzb24uY29tPixJbmVz IFJvYmxlcyA8bWFyaWEuaW5lcy5yb2JsZXNAZXJpY3Nzb24uY29tPixNaWNoYWVsIFJpY2hhcmRz b24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4sQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb20+ LEFsdmFybyBSZXRhbmEgPGFyZXRhbmFAY2lzY28uY29tPixEZWJvcmFoIEJydW5nYXJkIDxkYjM1 NDZAYXR0LmNvbT4sUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgRGlz Y3Vzc2lvbiBMaXN0IDxyb2xsQGlldGYub3JnPiBSZXNwb25zZSBDb250YWN0OiBzY290dC5tYW5z ZmllbGRAZXJpY3Nzb24uY29tIFRlY2huaWNhbCBDb250YWN0OiByZHJvbXNAY2lzY28uY29tDQpQ dXJwb3NlOiBJbiByZXNwb25zZQ0KUmVmZXJlbmNlZCBsaWFpc29uOiBMUyBvbiBjb25jZXJucyBv biB0aGUgZGVwcmVjYXRpb24gb2YgZGlzcGF0Y2ggdHlwZSBpbiA2bG9XUEFOIGFuZCBpdHMgaGVh ZGVyIGNvbXByZXNzaW9uIG1lY2hhbmlzbSB0byByb2xsIChodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTQxNS8pDQpCb2R5OiBUaGUgSUVURiB3aWxsIG5vdCBjaGFuZ2UgdGhl IGRlZmluaXRpb25zIG9mIHRoZSBjb2RlIHBvaW50cyBzcGVjaWZpZWQgaW4gUkZDIDQ5NDQgYW5k IFJGQyA2MjgyLCBhcyBwdWJsaXNoZWQgaW4gSUFOQSByZWdpc3RyeSAiSVB2NiBMb3cgUG93ZXIg UGVyc29uYWwgQXJlYSBOZXR3b3JrIFBhcmFtZXRlcnMiIDxodHRwOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL182bG93cGFuLXBhcmFtZXRlcnMvXzZsb3dwYW4tcGFyYW1ldGVycy54aHRtbD4s IGluIHN1Y2ggYSB3YXkgYXMgdG8gYWZmZWN0IHRoZSBJVFUtVCBHLjk5MDMgKDAyLzIwMTQ6IFRh YmxlIDktMzUgLSBDb21tYW5kIGZyYW1lIGhlYWRlciBpZGVudGlmaWVyKSBhbmQgRy45OTA1ICgw OC8yMDEzOiBUYWJsZSA3LTEgLSBDb21tYW5kIElEIHVzZWQgaW4gQURQIGxheWVyIGFuZCBUYWJs ZSA3LTFhIC0gTWVzc2FnZSB0eXBlKSBzcGVjaWZpY2F0aW9ucy4NCg0KVGhlIElFVEYgNmxvIHdv cmtpbmcgZ3JvdXAgb2ZmZXJzIHRvIGNvbGxhYm9yYXRlIHdpdGggSVRVLVQgU0cxNSBpbiBlc3Rh Ymxpc2hpbmcgYSBuZXcgcmVnaXN0cnkgbWFpbnRhaW5lZCBieSBJQU5BIGZvciB0aGUgY29kZSBw b2ludHMgZm9sbG93aW5nIHRoZSBFU0MgZGlzcGF0Y2ggY29kZS4gVGhpcyBuZXcgcmVnaXN0cnkg d2lsbCBiZSBwb3B1bGF0ZWQgYXQgdGhlIHRpbWUgb2YgaXRzIGVzdGFibGlzaG1lbnQgd2l0aCB0 aGUgQ29tbWFuZCBJRCB2YWx1ZXMgYXMgYWxyZWFkeSBkZWZpbmVkIGluIEcuOTkwMyBhbmQgRy45 OTA1Lg0KDQpXZSB3ZWxjb21lIGV4cGVydHMgYWxzbyBhY3RpdmUgaW4gU0cxNSB0byBwYXJ0aWNp cGF0ZSBpbiBvdXIgbmV4dCBtZWV0aW5nOiBJRVRGIDZsbyBhbmQgUk9MTCBXb3JraW5nIEdyb3Vw cyBtZWV0aW5nLCAxIC0gNiBOb3ZlbWJlciAyMDE1LCBZb2tvaGFtYSAoaHR0cDovL2lldGYub3Jn L21lZXRpbmcvOTQvaW5kZXguaHRtbCkNCg0KU2NvdHQgTWFuc2ZpZWxkDQpFcmljc3NvbiBJbmMu DQorMSA3MjQgOTMxIDkzMTYNCkF0dGFjaG1lbnRzOg0KDQpObyBkb2N1bWVudCBoYXMgYmVlbiBh dHRhY2hlZA0KDQo= From nobody Mon Aug 3 12:04:07 2015 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 BC7981A876B; Mon, 3 Aug 2015 12:04:06 -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 Rg7jac_IsJPn; Mon, 3 Aug 2015 12:04:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2991A86EA; Mon, 3 Aug 2015 12:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150803190405.21595.59324.idtracker@ietfa.amsl.com> Date: Mon, 03 Aug 2015 12:04:05 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-11.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, 03 Aug 2015 19:04:06 -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 Ruben Salazar Kazuya Monden Nancy Cam-Winget Filename : draft-ietf-roll-applicability-ami-11.txt Pages : 25 Date : 2015-08-03 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: https://tools.ietf.org/html/draft-ietf-roll-applicability-ami-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-ami-11 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 Aug 4 15:04:04 2015 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 1FEF11ACF07; Tue, 4 Aug 2015 15:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0D_craXoEwq; Tue, 4 Aug 2015 15:04:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E711AD04E; Tue, 4 Aug 2015 15:03:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804220352.29924.596.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 15:03:52 -0700 Archived-At: Cc: roll chair , roll mailing list , RFC Editor Subject: [Roll] Protocol Action: 'Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control' to Proposed Standard (draft-ietf-roll-applicability-home-building-12.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, 04 Aug 2015 22:04:03 -0000 The IESG has approved the following document: - 'Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control' (draft-ietf-roll-applicability-home-building-12.txt) as Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ Technical Summary The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. Working Group Summary There has not been much discussion on the working group mailing list about this document. Apart from a review by the shepherd, a review with a focus on security has been carried out. In both cases the authors amended the document to the reviewers' satisfaction. A further revision was made after AD review. Document Quality The document is positioned as PS according to its classification as an Applicability Statement according to RFC 2026. This gives rise to a long list of downrefs that were called out in IETF last call. An AS is not implemented, per se, but this document is written based on the experience of a number of implementations. Personnel Yvonne-Anne Pignolet is the Document Shepherd. Alvaro Retana is the Responsible AD. From nobody Thu Aug 6 03:43:18 2015 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 9A1971B2C6B for ; Thu, 6 Aug 2015 03:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5OZyuNtRqwU for ; Thu, 6 Aug 2015 03:43:14 -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 ADCD91B2C6D for ; Thu, 6 Aug 2015 03:43:14 -0700 (PDT) Received: from localhost ([::1]:40398 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZNIdj-00038F-E4; Thu, 06 Aug 2015 03:43:11 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 06 Aug 2015 10:43:11 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/172 Message-ID: <067.479dcc53142e0a2758cf77a95e643ee8@trac.tools.ietf.org> X-Trac-Ticket-ID: 172 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: Cc: roll@ietf.org Subject: [Roll] [roll] #172 (draft-doi-roll-mpl-parameter-configuration): Describe which parameters are considered time values 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, 06 Aug 2015 10:43:16 -0000 #172: Describe which parameters are considered time values From Alia Atlas 07-08, source: https://datatracker.ietf.org/doc/draft- ietf-roll-mpl-parameter-configuration/ballot/ In general, this draft is well-written and easy to understand. I do have a few points of technical clarity that I think are important. First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 bits): Reserved. Should be 0." and then in Sec 2.2: " Clients MUST discard the MPL Parameter Configuration Option if it is invalid (e.g., it sets reserved bits)." Frequently, Reserved bits are available for future enhancements - so setting to zero on write and ignoring the value on read is a useful default. If these bits are really always going to be zero and interpreted as an error, then could you rename them to MBZ (Must Be Zero) and indicate in the field definition that a value other than zero is an error. Also, from what I read in the rest of the draft, if an invalid option is received, that could cause the client to be removed from the MPL region. Could you clarify in the document what the expected behavior is if an invalid option is discarded? Is that like having no option? Is that pretending that the client didn't get one and staying with the previous option? It seems like it would be pretty easy to remove a client from the MPL region by flipping a bit. I would also like to see better clarification of how an option is considered invalid; while it may seem obvious, it's these details that impact interoperability. In the write-up, I don't see any indications that there have been interoperable implementations yet? Second, given that the meaning of the *_IMAX values is based on RFC6206 (as indicated in the update history) and that the *_IMAX and *_IMIN are confusing values, PLEASE have a reference to RFC6206. To continue, it seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - as is explained in RFC6206 where *_IMAX is the number of doublings and *_IMIN is the value in milliseconds. However, in draft-ietf-roll-trickle- mcast-12, Section 5.4, the definition of DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given as: " DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN has a default value of 10 times the expected link-layer latency. DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN. CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined in [RFC6206], for MPL Control Message transmissions. CONTROL_MESSAGE_IMIN has a default value of 10 times the worst- case link-layer latency. CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206], for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 minutes. " Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is only an 8-bit value, they are expected to have different ranges. Additionally, it's quite unclear which actually needs to be divided by TUNIT. The draft describes this as happening for DM_IMIN and C_IMIN, but then goes on to say " Note that all time values (Trickle timers and expiration periods) are in TUNIT milliseconds precision. For example, if TUNIT is 20 and the data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50." Unfortunately, the draft doesn't describe which parameters are time values and apparently draft-ietf-roll-trickle-mcast-12 has some confusion as well. For instance, CONTROL_MESSAGE_IMAX is defined as a time value (5 minutes). I suspect that the solution here is to clarify/fix draft-ietf-roll- trickle-mcast-12, add references in Sec 2 to where the parameters are defined, indicate which are considered "time values", and clean up the language in Sec 2.1. Thanks! It looks like a useful document to address an operational problem once these clarity issues are addressed. -- -------------------------------------+------------------------------------- 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 | Keywords: Severity: Submitted WG Document | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Aug 6 06:11:45 2015 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 41CA21B2F10; Thu, 6 Aug 2015 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3d3jPr38qSE; Thu, 6 Aug 2015 06:11:41 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CF11B2F08; Thu, 6 Aug 2015 06:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4032; q=dns/txt; s=iport; t=1438866701; x=1440076301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DUej4oZhS8uY9MmFH1QNx9Na4EQxDyPKb80qPRgC5dc=; b=AtJFejRAbLK3kRfFsY0sX6ulyUcUB/cwzceBejqNumxqujGKx2u/rNHU JkZFrCDDkV+95nbhF8I5tHfws5oMEHCKului7RzD3LO7gRyRWZliqljpC OYr4iLR3lRl/zcOk10QN3fuCR0lHdo+sgv9h4j/hZYmvuPEbF2OOFTLGh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B/AwC5XMNV/5BdJa1bgxtUaQaDHblwCYIGhXcCHIEtOBQBAQEBAQEBfwuEIwEBAQQjEToJAgwEAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBA4FCIgmDbcOlkEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKLYRYBisHAgICgmMvgRQFjFGIMAGEfodZgUZGg12LXYgoJoN9bwGBR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,622,1432598400"; d="scan'208";a="175849756" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 06 Aug 2015 13:11:40 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t76DBeJw011350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2015 13:11:40 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 6 Aug 2015 08:11:39 -0500 Received: from xhc-aln-x09.cisco.com (173.36.12.83) by xch-aln-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 6 Aug 2015 08:11:39 -0500 Received: from xmb-rcd-x01.cisco.com ([169.254.1.17]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 08:11:39 -0500 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-routing-dispatch-06.txt Thread-Index: AQHQ0EdYtNuUgSb1EUmFdtsis/H/Sp3+7zsw Date: Thu, 6 Aug 2015 13:11:39 +0000 Deferred-Delivery: Thu, 6 Aug 2015 13:11:36 +0000 Message-ID: References: <20150806125638.28139.68404.idtracker@ietfa.amsl.com> In-Reply-To: <20150806125638.28139.68404.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-06.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: Thu, 06 Aug 2015 13:11:43 -0000 RGVhciBhbGw6DQoNClRoYW5rcyB0byBhIHZlcnkgcHJvZHVjdGl2ZSBtZWV0aW5nIGluIFByYWd1 ZSBhbmQgZnVydGhlciBkaXNjdXNzaW9ucyBpbiB0aGUgTWFpbGluZyBMaXN0LCB0aGUgb3BlbiBx dWVzdGlvbnMgb24gZm9ybWF0dGluZyBSUEwgYXJ0aWZhY3RzIGlzIGZpbmFsbHkgc29ydGVkIG91 dC4gVGhlIGNvbmNsdXNpb25zIGFyZSByZWZsZWN0ZWQgaW4gdGhlIHVwZGF0ZSBvZiB0aGUgZG9j dW1lbnQ7IA0KDQpoaWdobGlnaHQ6DQoNCi0gYSBQYWdlLWJhc2VkIGNvbnRleHQgc3dpdGNoIHN5 c3RlbSBpcyBpbnRyb2R1Y2VkLiBQYWdlIDAgcmVwcmVzZW50cyBleGlzdGluZyA2TG9XUEFOIHNw ZWNzLiBUaGUgNkxvUkggaXMgdGhlIGZpcnN0IG5ldyBkaXNwYXRjaCBpbiBQYWdlIDEuDQotIHRo ZSBNZXNoIEhlYWRlciBlbmNvZGluZyBpcyBubyBtb3JlIGF2YWlsYWJsZSBpbiA2TG9SSCwgd2hp Y2ggaXMgbm93IGRlZGljYXRlZCB0byAoTGF5ZXItMykgcm91dGluZyBpbmZvcm1hdGlvbg0KLSB0 aGUgc3BlY2lmaWNhdGlvbiBpcyBkZXNpZ25lZCB0byBmaXQgd2l0aGluIEpvbmF0aGFuJ3MgcHJv cG9zYWwgZm9yIGEgc3VyLWNvbXByZXNzaW9uIG1lY2hhbmlzbSB0aGF0IHdpbGwgZWxpZGUgdGhl IFBhZ2UgRGlzcGF0Y2ggYnkgcHJvamVjdGluZyBkaXNwYXRjaGVzIGZyb20gbXVsdGlwbGUgcGFn ZXMgaW4gYSBzaW5nbGUgb2N0ZXQsIHdoZW4gc3VjaCBzcGVjIGlzIGF2YWlsYWJsZSAoc2VjdGlv biAzLjMpLg0KDQpEZWFyIGNoYWlyczogVGhlIGRvY3VtZW50IGhhcyBiZWVuIHN0YWJsZSBmb3Ig dGhlIG1vc3QgcGFydCBhbmQgd2UgdGhpbmsgaXQgaXMgbm93IHJpcGUgZm9yIGFkb3B0aW9uIGNh bGwuDQoNCkNvbW1lbnRzIHdlbGNvbWUsDQoNClBhc2NhbA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IGpldWRpIDYgYW/Du3QgMjAxNSAxNDo1Nw0KVG86IFJv YmVydCBDcmFnaWUgPHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbT47IFBhc2NhbCBUaHViZXJ0 IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbT47IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVy dCkgPHB0aHViZXJ0QGNpc2NvLmNvbT47IExhdXJlbnQgVG91dGFpbiA8TGF1cmVudC5Ub3V0YWlu QHRlbGVjb20tYnJldGFnbmUuZXU+OyBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47IExh dXJlbnQgVG91dGFpbiA8bGF1cmVudC50b3V0YWluQHRlbGVjb20tYnJldGFnbmUuZXU+OyBEci4g Q2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+OyBSb2JlcnQgQ3JhZ2llIDxyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXRodWJlcnQtNmxvLXJvdXRpbmctZGlzcGF0Y2gtMDYudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtNmxvLXJvdXRpbmctZGlzcGF0Y2gtMDYudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXRodWJlcnQtNmxvLXJv dXRpbmctZGlzcGF0Y2gNClJldmlzaW9uOgkwNg0KVGl0bGU6CQlBIFJvdXRpbmcgSGVhZGVyIERp c3BhdGNoIGZvciA2TG9XUEFODQpEb2N1bWVudCBkYXRlOgkyMDE1LTA4LTA2DQpHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRp c3BhdGNoLTA2LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXRodWJlcnQtNmxvLXJvdXRpbmctZGlzcGF0Y2gvDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtNmxvLXJvdXRpbmct ZGlzcGF0Y2gtMDYNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC0wNg0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBpbnRyb2R1Y2VzIGEgbmV3IGNvbnRleHQgc3dpdGNoIG1l Y2hhbmlzbSBmb3INCiAgIDZMb1dQQU4gY29tcHJlc3Npb24sIGV4cHJlc3NlZCBpbiB0ZXJtcyBv ZiBQYWdlcy4gIEEgbmV3IDZMb1dQQU4NCiAgIGRpc3BhdGNoIHR5cGUgaXMgcHJvcG9zZWQgaW4g YSBuZXcgUGFnZSAxIGZvciB1c2UgaW4gNkxvV1BBTiBSb3V0ZS0NCiAgIE92ZXIgdG9wb2xvZ2ll cywgdGhhdCBpbml0aWFsbHkgY292ZXJzIHRoZSBuZWVkcyBvZiBSUEwgKFJGQzY1NTApDQogICBk YXRhIHBhY2tldHMgY29tcHJlc3Npb24uICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIG1l dGhvZCB0bw0KICAgY29tcHJlc3MgUlBMIE9wdGlvbiAoUkZDNjU1MykgaW5mb3JtYXRpb24gYW5k IFJvdXRpbmcgSGVhZGVyIHR5cGUgMw0KICAgKFJGQzY1NTQpLCBhbiBlZmZpY2llbnQgSVAtaW4t SVAgdGVjaG5pcXVlIGFuZCBpcyBleHRlbnNpYmxlIGZvciBtb3JlDQogICBhcHBsaWNhdGlvbnMu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Aug 14 05:28:02 2015 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 235111ACE91 for ; Fri, 14 Aug 2015 05:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt2sIfMpnkEs for ; Fri, 14 Aug 2015 05:27:59 -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 DBF451ACE87 for ; Fri, 14 Aug 2015 05:27:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C1C4E200A1 for ; Fri, 14 Aug 2015 08:46:01 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7F7FF63B18; Fri, 14 Aug 2015 08:27:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 663EC63AE8 for ; Fri, 14 Aug 2015 08:27:57 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: [Roll] ticket - 172 - clarify units of trickle timers 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, 14 Aug 2015 12:28:01 -0000 --=-=-= Content-Type: text/plain https://tools.ietf.org/wg/roll/trac/ticket/172 This ticket was opened in response to a DISCUSS from AD Alia Atlas, on the draft-ietf-roll-mpl-parameter-configuration document. As a result of this DISCUSS the processing of trickle-mcast was held up at the RFC-editor, as there was concern that we needed to fix that document. Ines and I are looking for opinions from the WG about this situation; better text, even just "yes, you described the problem correctly" The specific confusion is that draft-ietf-roll-mpl-parameter-configuration and trickle-mcast are not explicit enough about the units of IMIN and IMAX values. Jonathan Hui commented that the origin of the problem is really RFC RFC 6206, and he wrote on a thread involving the ADs: - On one hand, RFC 6206 says "the maximum interval size Imax", which is an absolute value. - On the other hand, RFC 6206 says that Imax "is described as a number of doublings of the minimum interval size", which is a relative value. - Later, RFC 6206 uses Imax as if it were an absolute value. For example, "When the algorithm starts execution, it sets I to a value in the range of [Imin, Imax]". In another example, "Nodes with small Imax values will transmit faster, suppressing those with larger Imax values. The nodes with larger Imax values, always suppressed, will never transmit." That statement only makes sense if Imax was an absolute value, and not relative to Imin. - RFC 6206 also uses Imax as it it were a relative value. "Note that mismatched Imin values and matching Imax doubling constants will lead to mismatched maximum interval lengths." It seems clear to me that it doesn't really *internally* matter if Imax is a timer or a doubling of Imin, as long as it can be used an alarm that causes the trickle algorithm to run. It is only when we get to draft-ietf-roll-mpl-parameter-configuration when we put these values on the wire that we have to deal with it clearly. mpl-paramaeter-configuration says (section 2.1): Note that all time values (Trickle timers and expiration periods) are in TUNIT milliseconds precision. For example, if TUNIT is 20 and the data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50. and I suggest that it instead say: Note that time values DM_IMIN, DM_T_EXP, C_MIN, C_T_EXP are in units of TUNIT. TUNIT is a multiplier, and is in units of miliseconds. For example, if TUNIT is 20 and the desired data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50 (1000ms/ 20 = 50). Time values: DM_IMAX, and C_IMAX are in multiples of the respective DM_IMIN and C_IMIN values, so if a DM_MIN value of 50 (1000ms) is encoded, and DM_IMAX contains the number 4, then the DATA_MESSAGE_IMAX value would have be 4000ms (4s). Also, mpl-parameter-configuration needs a reference to 6206. As such I don't think we need to fix anything in the trickle-mcast document itself. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVc3ezYCLcPvd0N1lAQJ/3Qf9HRmZ8e7q0nx3Kjp597v9kC+cg9v47nNN J/KrgE+v/gYtDbvJJ0eMvnd1SCRd9tLfYydNFoAlnBiFSW7CTY07kbURCcfxnGXU rAL54uSMfQqm/vfkd09yHQF8dtHNrFNhi4+2RHiQQlNK9x4PqlwbCIYgFfq4vTzK 53uffwYVbHnOnpQvrJ47KNJBqzNysiuamee8Opk0WfqRd4Cml0f4Ya7cFqQA6c3r ngWzeBOR1L2WLfu8CERZSE7JfCi2VcnrqYERA7yV9+EWc3nMo2RtGSoUqFvlGLPX 51q0QJopKT++aPi1lJOmeWebOxQEx0OtlrKx9NwyVx3beLSbGYoadg== =Ebxn -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 17 00:15:31 2015 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 022151B2C21 for ; Mon, 17 Aug 2015 00:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VmsNqEo6j4J6 for ; Mon, 17 Aug 2015 00:15:28 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BBC1B2C20 for ; Mon, 17 Aug 2015 00:15:28 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.211]) by smtp-cloud2.xs4all.net with ESMTP id 5jFR1r00A4ZF39u01jFR4G; Mon, 17 Aug 2015 09:15:25 +0200 Received: from [2001:983:a264:1:18d:11cc:b19f:7478] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 17 Aug 2015 09:15:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Aug 2015 09:15:25 +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: <29012.1439555277@sandelman.ca> References: <29012.1439555277@sandelman.ca> Message-ID: <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> X-Sender: stokcons@xs4all.nl (cRFNIvOM8HWTbEePvshRLOVTercCHyUv) User-Agent: XS4ALL Webmail Archived-At: Cc: Michael Richardson Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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: Mon, 17 Aug 2015 07:15:31 -0000 Hi Michael, thanks for trying to solve this issue. I must confess that I had not recognized the problem. For interoperability is seems an issue when values are initialized (as you point out as well) It will be a nuisance if sets of nodes must be initialized with different Imin and Imax values to reach the same behaviour. The same problem will occur when a YANG (SMIv2) description is made for managing these parameters. Suggestion: write an ERRATA document for RFC6206 which then solves draft-ietf-roll-trickle-mcast-12 issue. Peter Michael Richardson schreef op 2015-08-14 14:27: > https://tools.ietf.org/wg/roll/trac/ticket/172 > > This ticket was opened in response to a DISCUSS from AD Alia Atlas, > on the draft-ietf-roll-mpl-parameter-configuration document. > > As a result of this DISCUSS the processing of trickle-mcast was held > up at the RFC-editor, as there was concern that we needed to fix that > document. Ines and I are looking for opinions from the WG about this > situation; better text, even just "yes, you described the problem > correctly" > > The specific confusion is that > draft-ietf-roll-mpl-parameter-configuration > and trickle-mcast are not explicit enough about the units of IMIN and > IMAX > values. > > Jonathan Hui commented that the origin of the problem is > really RFC RFC 6206, and he wrote on a thread involving the ADs: > > - On one hand, RFC 6206 says "the maximum interval size Imax", > which > is an absolute value. > - On the other hand, RFC 6206 says that Imax "is described as a > number > of doublings of the minimum interval size", which is a relative > value. > > - Later, RFC 6206 uses Imax as if it were an absolute value. For > example, "When the algorithm starts execution, it sets I to a > value in > the range of [Imin, Imax]". In another example, "Nodes with > small Imax > values will transmit faster, suppressing those with larger Imax > values. The nodes with larger Imax values, always suppressed, > will > never transmit." That statement only makes sense if Imax was an > absolute value, and not relative to Imin. > > - RFC 6206 also uses Imax as it it were a relative value. "Note > that > mismatched Imin values and matching Imax doubling constants will > lead > to mismatched maximum interval lengths." > > It seems clear to me that it doesn't really *internally* matter if Imax > is a > timer or a doubling of Imin, as long as it can be used an alarm that > causes > the trickle algorithm to run. It is only when we get to > draft-ietf-roll-mpl-parameter-configuration when we put these values > on the wire that we have to deal with it clearly. > > mpl-paramaeter-configuration says (section 2.1): > > Note that all time values (Trickle timers and expiration periods) > are > in TUNIT milliseconds precision. For example, if TUNIT is 20 and > the > data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then > DM_IMIN shall be set to 50. > > and I suggest that it instead say: > > Note that time values DM_IMIN, DM_T_EXP, C_MIN, C_T_EXP are in units > of TUNIT. TUNIT is a multiplier, and is in units of miliseconds. > For example, if TUNIT is 20 and the > desired data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, > then DM_IMIN shall be set to 50 (1000ms/ 20 = 50). > > Time values: DM_IMAX, and C_IMAX are in multiples of the respective > DM_IMIN and C_IMIN values, so if a DM_MIN value of 50 (1000ms) is > encoded, and DM_IMAX contains the number 4, then the > DATA_MESSAGE_IMAX value > would have be 4000ms (4s). > > Also, mpl-parameter-configuration needs a reference to 6206. > > As such I don't think we need to fix anything in the trickle-mcast > document > itself. > > -- > 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 Mon Aug 17 08:04:35 2015 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 BBB231A923D for ; Mon, 17 Aug 2015 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJUUodqObZXM for ; Mon, 17 Aug 2015 08:04:32 -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 59B2C1A916C for ; Mon, 17 Aug 2015 08:04:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CCD4E2016A; Mon, 17 Aug 2015 11:22:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2690963B10; Mon, 17 Aug 2015 11:04:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0D64E63AEC; Mon, 17 Aug 2015 11:04:27 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> References: <29012.1439555277@sandelman.ca> <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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, 17 Aug 2015 15:04:33 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > It will be a nuisance if sets of nodes must be initialized with different > Imin and Imax values to reach the same behaviour. > The same problem will occur when a YANG (SMIv2) description is made for > managing these parameters. I think that we expect that Imax is in units of multiple of Imin, which is in units of TUNIT. Is that part at least, non-controversial? > Suggestion: write an ERRATA document for RFC6206 which then solves > draft-ietf-roll-trickle-mcast-12 issue. I think that 6206 doesn't care what units are expressed internally. Do any math in 6206 depend upon an integer multiple relationship between Imin and Imax? -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdH3+ICLcPvd0N1lAQJI7wf9EKRADManXqzGMYsHtTTydhPvCGgxADB3 MgIklxsamkeaE4aCnWJXIJHuLNhPyKYeOQMsHcpoli7n/Iem7QRXB7NZcy71DElU wUtvQXcw2knosHdGyqXOOPn/U1vc1odZ1mCTFh5ewzwLRR+NwsaWunHVMFsIt8rL VkhNpWRQfqKRpQIMfwtKd8VaLt3qUjVqckZp478qofAgcfUEao1cchHyJ2x0FlK0 7055KBIJF1z3ubO3EYWd2/jYL+ngLjDuR93Ro1xAwUYOmW4qHCeRMLPVfkMeHVmO lAGfBkqwCFdQbga2IHSnoiHPlaUGWsmiiiEO4Px+AuuL8Ldbmacn5A== =mpCJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 17 08:27:27 2015 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 781D61AC417 for ; Mon, 17 Aug 2015 08:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 zh7ASbHAxAwK for ; Mon, 17 Aug 2015 08:27:24 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E083D1AC416 for ; Mon, 17 Aug 2015 08:27:23 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so84503000lbb.0 for ; Mon, 17 Aug 2015 08:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2yTp5ST5jcsAUzrEo3EsYXm3s/IqBLrPBPWjiybpSUM=; b=vkfsnjtLdwME5HLRfHMDZVGZHrn1kvgxnkn9lA0y3E6BpVmO4HdWZNnQ6sCkwAtI6a QO5fyrwGjTuWndipf1+R624spZqQs098ClNa/xRZDAFT0lr2D+I7khZSUjXXxwQa70M/ TuwKSNaaQxwhs78kzoBDc1W1FSL7JBkjSUB9hU5NxYNyH0YvXoz76uy1J3oRueMcbtov Wj5kG6QhhsuyuB+3XGWTXkGONyPgbR6aqnHzvEcU5WXFCWaJcuclTlbhwe09SiDjzyTJ Wfkf8l3pMrenTEVfijB7k0NmS6bGcLvWay2wfSFa7lb3xna1kMhlQM1aFqb7krVRUwvN hYUQ== MIME-Version: 1.0 X-Received: by 10.152.20.228 with SMTP id q4mr1561842lae.74.1439825242408; Mon, 17 Aug 2015 08:27:22 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.25.167.202 with HTTP; Mon, 17 Aug 2015 08:27:22 -0700 (PDT) In-Reply-To: <16420.1439823867@sandelman.ca> References: <29012.1439555277@sandelman.ca> <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> <16420.1439823867@sandelman.ca> Date: Mon, 17 Aug 2015 11:27:22 -0400 X-Google-Sender-Auth: ZnnugIBBKOURjHUv593ZdJli_sE Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e01493a0a1ccde2051d8370c9 Archived-At: Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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, 17 Aug 2015 15:27:25 -0000 --089e01493a0a1ccde2051d8370c9 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 17, 2015 at 11:04 AM, Michael Richardson wrote: > > peter van der Stok wrote: > > It will be a nuisance if sets of nodes must be initialized with > different > > Imin and Imax values to reach the same behaviour. > > The same problem will occur when a YANG (SMIv2) description is made > for > > managing these parameters. > > I think that we expect that Imax is in units of multiple of Imin, which > is in units of TUNIT. Is that part at least, non-controversial? > > Imax is expressed as *doublings* of Imin, which is a tighter constraint than "multiple". It also represents an upper bound on the interval length. See rule 5 of RFC 6206: 5. When the interval I expires, Trickle doubles the interval length. If this new interval length would be longer than the time specified by Imax, Trickle sets the interval length I to be the time specified by Imax. Regards, Kerry > Suggestion: write an ERRATA document for RFC6206 which then solves > > draft-ietf-roll-trickle-mcast-12 issue. > > I think that 6206 doesn't care what units are expressed internally. > Do any math in 6206 depend upon an integer multiple relationship between > Imin > and Imax? > > > -- > 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 > > --089e01493a0a1ccde2051d8370c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 17, 2015 at 11:04 AM, Michael Richardson <mcr+ietf@sandelman.c= a> wrote:
=
peter van der Stok <stokcons@xs4al= l.nl> wrote:
=C2=A0 =C2=A0 > It will be a nuisance if sets of nodes must be initializ= ed with different
=C2=A0 =C2=A0 > Imin and Imax values to reach the same behaviour.
=C2=A0 =C2=A0 > The same problem will occur when a YANG (SMIv2) descript= ion is made for
=C2=A0 =C2=A0 > managing these parameters.

I think that we expect that Imax is in units of multiple of Imin, wh= ich
is in units of TUNIT.=C2=A0 Is that part at least, non-controversial?

Imax is expressed as *doublin= gs* of Imin, which is a tighter constraint than "multiple".
=
It also represents an upper bound on the interval length.
See rule 5 of RFC 6206:

5.  When the interval I expires, Trickle doubles th=
e interval length.
    If this new interval length would be longer than the time
    specified by Imax, Trickle sets the interval length I to be the
    time specified by Imax.
=C2=A0
Regards, = Kerry

=C2=A0 =C2=A0 > Suggestion: write an ERRATA document for RFC6206 which t= hen solves
=C2=A0 =C2=A0 > draft-ietf-roll-trickle-mcast-12 issue.

I think that 6206 doesn't care what units are expressed internal= ly.
Do any math in 6206 depend upon an integer multiple relationship between Im= in
and Imax?


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.i= etf.org/wg/roll/charter/


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


--089e01493a0a1ccde2051d8370c9-- From nobody Mon Aug 17 10:31:57 2015 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 3AC3C1ACD84 for ; Mon, 17 Aug 2015 10:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL47pT-7r1ZZ for ; Mon, 17 Aug 2015 10:31:54 -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 60FEA1ACD7E for ; Mon, 17 Aug 2015 10:31:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 202B4200A3 for ; Mon, 17 Aug 2015 13:50:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1CF8063B10; Mon, 17 Aug 2015 13:31:52 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F3D4763AEC for ; Mon, 17 Aug 2015 13:31:52 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <29012.1439555277@sandelman.ca> <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> <16420.1439823867@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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, 17 Aug 2015 17:31:56 -0000 --=-=-= Content-Type: text/plain Kerry Lynn wrote: > peter van der Stok wrote: >> It will be a nuisance if sets of nodes must be initialized with >> different >> Imin and Imax values to reach the same behaviour. >> The same problem will occur when a YANG (SMIv2) description is >> made for >> managing these parameters. > I think that we expect that Imax is in units of multiple of Imin, > which > is in units of TUNIT. Is that part at least, non-controversial? > Imax is expressed as *doublings* of Imin, which is a tighter > constraint than "multiple". > It also represents an upper bound on the interval length. so, if the Imax field contains "5", does that mean that Imax = 2^5 * Imin (* TUNIT) -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdIahYCLcPvd0N1lAQLB1Af+Luapc6m/mUpuP5hG8q6LYcjBDfuT/pmV yFPbNYG9H+QnOU8iCdqmUXd4YcJypWpZKwstB2s7O6T3xSxmMAABU5LzZ6DGHD8x oC7YEhUc9twRMr5OQacYb+wjyIZzDaWHq4tQi2fjtdQPpJgd8VYeoUyscDBCYr8k 8w5zzJ4cl+ClRHXuQvTY/sNoB44YIy3NI2K9pCAOVDkPXu4FENnF064QTiC+iPKD qmSnCkDFDeVSFTo6k79s65jEkHsagdinlqEqE+Lp/YhqGPH5N4K5oVb4k8euFMgE BtoIXMPpGlar3jbBfGi3ffqv+BSrBUnqyV8bFM//CoDYJcnNKbIrWw== =LZiS -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 17 11:12:34 2015 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 546C11ACE67 for ; Mon, 17 Aug 2015 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 ZrVOR6tQH27b for ; Mon, 17 Aug 2015 11:12:30 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3B71ACE98 for ; Mon, 17 Aug 2015 11:12:25 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so87525536lbb.0 for ; Mon, 17 Aug 2015 11:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=AGVlPTbMzznipucIZeIQVgoJgp5O/GPzfWd2Nki6ruQ=; b=cGUKsUokOENBhkjKH25plk0wYIPNal54NoymPmuZinjA3nMdL5q+wMBGu+L/BHVGoI rBYp0PqRbU+/ovSlgBtHrxXFipV2/8jugvJUejS0TYQaB7ZVttgYzXhPeMSoEtLaebpq SlyJXrZpERQNxkvgybw6XWjXiPa2WulDqEHleIV+JOi0Bd2eEweTzIjDCQLcMy+vpzN6 LOK+BasxRb4JaknZ1JHrZHFkulMC4jB1foxZH75sRfiQVEf0hGfiQofiWCxF6ifKQeU2 jrl/7nLdAL5GzRAwRUXxP9T0kU3+AVd+juRzJgV/yDzioUs15DgKrR/sH2xegoEF+SG3 qCHw== MIME-Version: 1.0 X-Received: by 10.112.210.6 with SMTP id mq6mr2137207lbc.83.1439835143929; Mon, 17 Aug 2015 11:12:23 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.25.167.202 with HTTP; Mon, 17 Aug 2015 11:12:23 -0700 (PDT) In-Reply-To: <14493.1439832712@sandelman.ca> References: <29012.1439555277@sandelman.ca> <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> <16420.1439823867@sandelman.ca> <14493.1439832712@sandelman.ca> Date: Mon, 17 Aug 2015 14:12:23 -0400 X-Google-Sender-Auth: RCd-IIm8FXba_CAN0fIXKGoIxbc Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c3cc6e4a067d051d85be8e Archived-At: Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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, 17 Aug 2015 18:12:32 -0000 --001a11c3cc6e4a067d051d85be8e Content-Type: text/plain; charset=UTF-8 On Mon, Aug 17, 2015 at 1:31 PM, Michael Richardson wrote: > > Kerry Lynn wrote: > > peter van der Stok wrote: > >> It will be a nuisance if sets of nodes must be initialized with > >> different > >> Imin and Imax values to reach the same behaviour. > >> The same problem will occur when a YANG (SMIv2) description is > >> made for > >> managing these parameters. > > > I think that we expect that Imax is in units of multiple of Imin, > > which > > is in units of TUNIT. Is that part at least, non-controversial? > > > > > Imax is expressed as *doublings* of Imin, which is a tighter > > constraint than "multiple". > > It also represents an upper bound on the interval length. > > so, if the Imax field contains "5", does that mean that > Imax = 2^5 * Imin (* TUNIT) > > According to the example in Section 4.1 of RFC 6206, yes. It refers to "the amount of time specified by Imax" (which should probably have its own name to avoid confusion). Kerry > -- > 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 > > --001a11c3cc6e4a067d051d85be8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 17, 2015 at 1:31 PM, Michael Richardson <mcr+ietf@sandelman.ca= > wrote:
<= br> Kerry Lynn <kerlyn@ieee.org> w= rote:
=C2=A0 =C2=A0 > peter van der Stok <stokcons@xs4all.nl> wrote:
=C2=A0 =C2=A0 >> It will be a nuisance if sets of nodes must be initi= alized with
=C2=A0 =C2=A0 >> different
=C2=A0 =C2=A0 >> Imin and Imax values to reach the same behaviour. =C2=A0 =C2=A0 >> The same problem will occur when a YANG (SMIv2) desc= ription is
=C2=A0 =C2=A0 >> made for
=C2=A0 =C2=A0 >> managing these parameters.

=C2=A0 =C2=A0 > I think that we expect that Imax is in units of multiple= of Imin,
=C2=A0 =C2=A0 > which
=C2=A0 =C2=A0 > is in units of TUNIT. Is that part at least, non-controv= ersial?



=C2=A0 =C2=A0 > Imax is expressed as *doublings* of Imin, which is a tig= hter
=C2=A0 =C2=A0 > constraint than "multiple".
=C2=A0 =C2=A0 > It also represents an upper bound on the interval length= .

so, if the Imax field contains "5", does that mean that =C2=A0 =C2=A0Imax =3D 2^5 * Imin (* TUNIT)

A= ccording to the example in Section 4.1 of RFC 6206, yes.=C2=A0 It refers
to "the amount of time specified by Imax" (which should p= robably have
its own name to avoid confusion).

Kerry
=C2=A0
--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.i= etf.org/wg/roll/charter/


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


--001a11c3cc6e4a067d051d85be8e-- From nobody Sun Aug 23 17:04:12 2015 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 2CEF51B2E21 for ; Sun, 23 Aug 2015 17:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX50DnNAb1SD for ; Sun, 23 Aug 2015 17:04:09 -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 CFD571B2E1F for ; Sun, 23 Aug 2015 17:04:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1FBA92009E for ; Sun, 23 Aug 2015 20:22:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 16ACB63B10; Sun, 23 Aug 2015 20:04:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 01BA163AEC for ; Sun, 23 Aug 2015 20:04:08 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <29012.1439555277@sandelman.ca> <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> <16420.1439823867@sandelman.ca> <14493.1439832712@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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: Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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, 24 Aug 2015 00:04:11 -0000 --=-=-= Content-Type: text/plain Kerry Lynn wrote: >>> It will be a nuisance if sets of nodes must be initialized with >>> different >>> Imin and Imax values to reach the same behaviour. >>> The same problem will occur when a YANG (SMIv2) description is >>> made for >>> managing these parameters. >> I think that we expect that Imax is in units of multiple of >> Imin, >> which >> is in units of TUNIT. Is that part at least, non-controversial? >> Imax is expressed as *doublings* of Imin, which is a tighter >> constraint than "multiple". >> It also represents an upper bound on the interval length. > so, if the Imax field contains "5", does that mean that > Imax = 2^5 * Imin (* TUNIT) kerry> According to the example in Section 4.1 of RFC 6206, yes. It refers kerry> to "the amount of time specified by Imax" (which should probably have kerry> its own name to avoid confusion). I'd like the DHCP parameter document to more closely refer to this, and perhaps even copy the example from 6206 then. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdpfeICLcPvd0N1lAQJASwgAiQR1vXMs6BYm7Th9gC/zV338k4I7Dmqc RWGCJuKL1MFJWgr1V0epePQ/13hph9xRarZl63wWe0D+ujNsoqQHVlHDhonjLQBK XXRjPeV4EhWpwMAAT2im3ps2Hg1s/dk/7NGGtJrJNXVXbMfnwpVu1VThopnPYdZV i9XFxreFK2WX5ETVsJwaZ2BwTnItLnOCa2U25FD1ZzKEeXMAH9XAkiS16+LqeJDI mD83JXBoXOMfMo8CKNBVUlz/u6QossY2Lr0wkBbV/UJYNmkBEcajkMYiPgZ8hfLs gsN7SedssDjmL3fnLYje+mfEQqVFzpAL8ur7VL+z8UoFtV+G+XXA8g== =bUhr -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 23 17:48:32 2015 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 070911B2E64 for ; Sun, 23 Aug 2015 17:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 IZsMIYpg3_lk for ; Sun, 23 Aug 2015 17:48:29 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0691B2E63 for ; Sun, 23 Aug 2015 17:48:29 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t7O0mRUO025198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Aug 2015 09:48:27 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t7O0mRgo005029 for ; Mon, 24 Aug 2015 09:48:27 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 81 for ; Mon, 24 Aug 2015 09:48:27 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t7O0mRCV005019 for ; Mon, 24 Aug 2015 09:48:27 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t7O0mRl4012670 for roll@ietf.org; Mon, 24 Aug 2015 09:48:27 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA12649; Mon, 24 Aug 2015 09:48:26 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t7O0mO4E001085 for ; Mon, 24 Aug 2015 09:48:24 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t7O0mNpT016496; Mon, 24 Aug 2015 09:48:23 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:bcb9:3450:1b52:1d5b] (unknown [IPv6:2001:200:1b1:1010:bcb9:3450:1b52:1d5b]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C1F5918F4BF for ; Mon, 24 Aug 2015 09:48:23 +0900 (JST) To: roll@ietf.org References: <29012.1439555277@sandelman.ca> <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl> <16420.1439823867@sandelman.ca> <14493.1439832712@sandelman.ca> <26094.1440374648@sandelman.ca> From: Yusuke DOI Message-ID: <55DA69E6.2090503@toshiba.co.jp> Date: Mon, 24 Aug 2015 09:48:38 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <26094.1440374648@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers 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, 24 Aug 2015 00:48:32 -0000 Thanks for clarifications. I'll update the document on this week. Sorry for late update. Yusuke On 2015-08-24 09:04, Michael Richardson wrote: > > Kerry Lynn wrote: > >>> It will be a nuisance if sets of nodes must be initialized with > >>> different > >>> Imin and Imax values to reach the same behaviour. > >>> The same problem will occur when a YANG (SMIv2) description is > >>> made for > >>> managing these parameters. > > >> I think that we expect that Imax is in units of multiple of > >> Imin, > >> which > >> is in units of TUNIT. Is that part at least, non-controversial? > > >> Imax is expressed as *doublings* of Imin, which is a tighter > >> constraint than "multiple". > >> It also represents an upper bound on the interval length. > > > so, if the Imax field contains "5", does that mean that > > Imax = 2^5 * Imin (* TUNIT) > > kerry> According to the example in Section 4.1 of RFC 6206, yes. It refers > kerry> to "the amount of time specified by Imax" (which should probably have > kerry> its own name to avoid confusion). > > I'd like the DHCP parameter document to more closely refer to this, and > perhaps even copy the example from 6206 then. > > -- > 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 Fri Aug 28 04:35:35 2015 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 4A7781B38C1 for ; Thu, 27 Aug 2015 06:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BktKrIAE_WZ for ; Thu, 27 Aug 2015 06:26:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF101B38C5 for ; Thu, 27 Aug 2015 06:26:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1ECD2180473; Thu, 27 Aug 2015 06:26:17 -0700 (PDT) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, maria.ines.robles@ericsson.com, mcr+ietf@sandelman.ca X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150827132617.1ECD2180473@rfc-editor.org> Date: Thu, 27 Aug 2015 06:26:17 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 28 Aug 2015 04:35:34 -0700 Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Editorial Errata Reported] RFC6550 (4457) 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, 27 Aug 2015 13:26:34 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4457 -------------------------------------- Type: Editorial Reported by: Dominique Barthel Section: 20.9 Original Text ------------- in title of section (one instance) and text (two instances) "DODAG Informational Solicitation" Corrected Text -------------- "DODAG Information Solicitation" Notes ----- DIS is defined in Section 2 (Terminology) as "DODAG Information Solicitation". This acronym is expanded consistently throughout the RFC but in this section. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Aug 28 04:35:37 2015 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 E59801B3882 for ; Thu, 27 Aug 2015 06:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK1a9q202uVm for ; Thu, 27 Aug 2015 06:29:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2BC1B33DD for ; Thu, 27 Aug 2015 06:29:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 03B42180474; Thu, 27 Aug 2015 06:29:41 -0700 (PDT) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, maria.ines.robles@ericsson.com, mcr+ietf@sandelman.ca X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150827132941.03B42180474@rfc-editor.org> Date: Thu, 27 Aug 2015 06:29:41 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 28 Aug 2015 04:35:34 -0700 Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Editorial Errata Reported] RFC6550 (4458) 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, 27 Aug 2015 13:29:58 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4458 -------------------------------------- Type: Editorial Reported by: Dominique Barthel Section: 20.10 Original Text ------------- No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags. Corrected Text -------------- No bit is currently defined for the DIO (DODAG Information Object) Flags. Notes ----- This is obviously an erroneous copy-paste from section 20.9 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG