From nobody Sun Feb 1 08:55:44 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 7A79F1A8998 for ; Sun, 1 Feb 2015 08:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9ZGGqkRySD8 for ; Sun, 1 Feb 2015 08:55:40 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222D31A898B for ; Sun, 1 Feb 2015 08:55:39 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t11Gta9U018894; Sun, 1 Feb 2015 16:55:37 GMT Received: from 950129200 (089144235122.atnat0044.highway.a1.net [89.144.235.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t11GtZUd018868 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2015 16:55:36 GMT From: "Adrian Farrel" To: "'Badis Djamaa'" References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> <32747.1421682839@sandelman.ca> In-Reply-To: Date: Sun, 1 Feb 2015 16:55:34 -0000 Message-ID: <01cd01d03e3f$e688a140$b399e3c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCw53+4e4VHsW0uBojrMI8G7plKKAIWK/tsAexzYaue+pZIMA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21298.001 X-TM-AS-Result: No--22.045-10.0-31-10 X-imss-scan-details: No--22.045-10.0-31-10 X-TMASE-MatchedRID: PL66URbwWA+0m/IROg5s5Z21GZGE81yGLi2dwKiMR9yqvcIF1TcLYKjg 8LvuPaQlQzWq4+8TLKt0kid+wG2aZ05w1HfNpbI4pvwZ9GmdwDOH7D1bP/FcOkENV4Lwnu7BRzW p7lR8ws4wpXxVu0nDORi8DAZaW4MB/c/S25H4jhvaUa2JYfrGrIVdLK46Krcf+a3bC2tdCMzRLH HtqtWAcfz4vZmX3KxYBuY9AIeqHo50tMeOizCSGsNrWpY804TGU5ulGJaO5WvfUZT83lbkEMCS2 AMm1nQC0PWu5Ebg3mbUTchm4zJLB6ezlDj0PvT93FqOVb7PDEK+F//Mn3a2w+Rmz46Q29bDlSpE XhOCtBSVgn2f2/Mgg6JtjVoePu+q/0j7XSCRjJCVOwZbcOalS279evoIpeI3CpfQdoiBsn4P/Fb H9DutneRY/3djULvkNPDRjTX9xLjl+2yjbMzve8OD5TU1KZy5zJmqByfAaS2X1Zxre5XTAMjeyY VLjHqEISf7n2qaXhJftuJwrFEhTbew1twePJJB3QfwsVk0UbslCGssfkpInQ== Archived-At: Cc: 'Routing Over Low power and Lossy networks' Subject: Re: [Roll] Telechat update notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 01 Feb 2015 16:55:42 -0000 Hi Badis, I'm finally processing your comments on this draft before it goes in = front of the IESG on Thursday. Comments in line. > Draft 11, Section 5.4. MPL Parameters states: > > MPL-TEXT: 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. > Starting from the above statement (dubbed MPL-TEXT), I have two main = comments > 1) terminology related: [RFC6206] (4.1. Parameters and Variables) = defines "The > maximum Trickle timer interval" as: > RFC6206-TEXT1: The maximum interval size, Imax, is described as a = number of > doublings of the minimum interval size (the base-2 log(max/min)). > For example, a protocol might define Imax as 16. If the minimum > interval is 100 ms, then the amount of time specified by Imax is > 100 ms * 65,536, i.e., 6,553.6 seconds or approximately > 109 minutes. > > MPL-TEXT refers to RFC6206 for the definition of "The maximum Trickle = timer > interval". However, I think "The maximum Trickle timer interval" usage = in > MPL-TEXT is different than its definition in RFC6206-TEXT1. Thus, I = think it > would be better to explicitly specify what is meant by "The maximum = Trickle > timer interval" to avoid any ambiguity.=20 I agree this is somewhat confusing.=20 However, it states that Imax "is described as a number of doublings" not = that Imax is a count of doublings. Sigh - we should have made this clearer in 6206. Of course, an implementation can do this however it likes, but Imax = specifies an amount of time, and I think 6206 is clear about this in the = text you quoted. That means that the text in this draft is also unambiguous that Imax = specifies a time. > Note that the same comment is also valid for this MPL text (Draft 11, = Section 5.4. > MPL Parameters ) 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. Same answer :-) > 2) Now arriving to the main concern, suppose that DATA_MESSAGE_IMAX > literally means the maximum trickle interval (the time specified by = Imax using > RFC6206 terminology), then: "DATA_MESSAGE_IMAX has a default value = equal > to DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted" = behavior. > This is because RFC6206's section 4.2. Algorithm Description, rule 6 = states: > RFC6206-TEXT2: 6. ...If I is equal to Imin when Trickle hears an > "inconsistent" transmission, Trickle does nothing... > Recommending "DATA_MESSAGE_IMAX has a default value equal to > DATA_MESSAGE_IMIN." makes the trickle timer always fall under = RFC6206-TEXT2 > and hence the timer will never get reset when hearing = "inconsistencies"=20 > However, if this default recommendation is deliberately designed = considering the=20 > above point, then choosing a non-default value of DATA_MESSAGE_IMAX = will=20 > result in a different behavior (nodes will reset their timers when = receiving > inconsistencies). This might even propagate faster than the default = recommendation. >=20 > To avoid the aforementioned ambiguities, I can think of recommending = either a > default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose a > change to RFC6206-TEXT2 in the MPL draf, if the current default = recommendation > is not deliberately designed to work as shown above. Otherwise, = explicitly state > in the MPL text that choosing a non-default value of DATA_MESSAGE_IMAX = may > result in different behavior. =20 Well, we can come back and work on 6206, but we only have *this* = document in front of us at the moment. I tripped over the IMAX=3D=3DIMIN piece until reading (later in the = section) the explanation... | Setting DATA_MESSAGE_IMAX to the same as DATA_MESSAGE_IMIN | in this case is acceptable since subsequent MPL Data Message | retransmissions are triggered by MPL Control Messages, where | CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN. > 3) By the way, RFC6206 also contains a typo, which might confuse the = reader, > in the following text (RFC6206 4.2. Algorithm Description, rule 1):=20 > Current: > 1. When the algorithm starts execution, it sets I to a value in the > range of [Imin, Imax] -- that is, greater than or equal to Imin > and less than or equal to Imax. The algorithm then begins the > first interval. > Following the definition of the maximum interval size (RFC6206-TEXT1, > above) this rule should be rewritten=20 > Proposed: > 1. When the algorithm starts execution, it sets I to a value in the=20 > range of [Imin, Imin x POW(2, Imax)] -- that is, greater than or = equal to Imin=20 > and less than or equal to the time specified by Imax. The = algorithm then begins=20 > the first interval. This could be approached with an Errata Report for RFC 6206, but I think = you have fixated on how Imax is expressed, rather than the fact that = Imax is a time. Thanks, Adrian From nobody Mon Feb 2 03:24:41 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 AB32E1A00EA for ; Mon, 2 Feb 2015 03:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s6-XyhBKe8t for ; Mon, 2 Feb 2015 03:24:35 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0221D1A00CD for ; Mon, 2 Feb 2015 03:24:35 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x19so16763854ier.10 for ; Mon, 02 Feb 2015 03:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BMpALFEBKVNLa50HNLhpRx4dwUimUZni/CsObRjRClA=; b=x2DFGLypJXsl9/bLYaHm/6mv0nJCR6VB/vX3oGnbpvITXKnj2xsJKH54fhLJ1WEfz0 j9xhd703f28J8O9B2GCW4LZ2q9hECSl0iCVTrQ+NjLOoYKUYZu0uI8p29pCWvtiS0t/y std53g4VEhY/BU+mMXPRDSMNjQKSoWAAfaOlx53QXx7lzRC3ZkNTtUObCtuJeC+ZC7FM aFInH2yH+ET6oPs4Nwwm2LDArN2lI5MqUM0m5VstMiIl1hxND8Edq5OeV6IQ1loj0jg2 J4p9oIoFh95YRUsoMo8CZygiX655vWMDWJdMtFeWuaVrs7hvl5ekWTOTyESxZnk1qF67 mBuw== MIME-Version: 1.0 X-Received: by 10.107.151.80 with SMTP id z77mr21683315iod.51.1422876274170; Mon, 02 Feb 2015 03:24:34 -0800 (PST) Received: by 10.107.52.16 with HTTP; Mon, 2 Feb 2015 03:24:34 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2015 11:24:34 +0000 Message-ID: From: Badis Djamaa To: consultancy@vanderstok.org Content-Type: multipart/alternative; boundary=001a1140f5eee1c42e050e1932f1 Archived-At: Cc: Jonathan Hui , "Thomas Heide Clausen \(work\)" , Routing Over Low power and Lossy networks , JeongGil Ko Subject: Re: [Roll] Revisiting the Trickle Algorithm 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, 02 Feb 2015 11:24:39 -0000 --001a1140f5eee1c42e050e1932f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for your comments peter, Our works on Trickle started in 2012. A first paper [1] was accepted March 2013 and appeared in IEEEXplorer (October 2013). A second work [2] appeared in Springer WiNet Journal (Jun 2014). Others including variants of the ones discussed here are under review. I am aware of the useful MSc thesis mentioned, cited in our detailed report ( https://dspace.lib.cranfield.ac.uk/handle/1826/9116). If I got it right, the thesis proposes a one-dimensional abstract mathematical model of the message count and propagation time of Trickle and =E2=80=9CShort-Trickle=E2= =80=9D. The author also proposed to make the listen-only period parametric over ALL intervals. A quick look at the mentioned pre-print [3] shows that the authors moved their parametric listen-only period to the Imin interval. Clearly, this proposition is different than ours, which explicitly proposes to choose t from [0, Imin), demonstrates why and discusses the trade-offs. Despite this, the pre-print only models, in function of the parametric listen-only period, simplistic line-topology lossless scenarios. Note that mathematically modelling Trickle is also performed in many of the abundant works related to Trickle such as [4] and [5] (2012). To the best of our knowledge, and as of today, no published work has proposed the New-Trickle algorithm as it is described in our first report ( https://dspace.lib.cranfield.ac.uk/handle/1826/9033) even less as detailed in the second report (https://dspace.lib.cranfield.ac.uk/handle/1826/9116), which are backed with around a year-worth of extensive public large-scale testbed experiments and realistic simulations, in accordance with RFC 6206 section 6.7 . Tweaks and Improvements to Trickle, especially this paragraph: RFC6206-TEXT: =E2=80=9CIn our experiences using Trickle, attempts to tweak = its behavior are typically not worth the cost. As written, the algorithm is already highly efficient: further reductions in transmissions or response time come at the cost of failures in edge cases. Based on our experiences, we urge protocol designers to suppress the instinct to tweak or improve Trickle without a great deal of experimental evidence that the change does not violate its assumptions and break the algorithm in edge cases.=E2=80=9D To this end, we collected over 300 GB of data trace files and experimented in sever conditions. Other experiments are being run in Indriya, TWIST and IoTLab testbeds along with other simulations under TOSSIM. We have been in contact with the first author of Trickle, Prof Philip Levis (cc=E2=80=99d) with 9-page document, stating our ideas backed with experime= ntal results (several-months-worth of work) submitted to him just after summer holidays (exactly on 02-09-2014). We have been in discussion with Prof Philip since then. I would like to take this opportunity to thank Prof Philip for his insightful and fruitful comments. Finally, as both works and the comments seem to agree on the need for revisiting Trickle, we are happy to collaborate. BTW, I have written an I-D which can be used as a starting point for discussions. Please let me know if you are interested. Any comments and discussions concerning the detailed report are warmly welcomed All the best, badis [1] http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=3Dtrue&tp=3D&arnum= ber=3D6661808 [2] http://link.springer.com/article/10.1007/s11276-014-0749-3 [3] http://arxiv.org/abs/1407.6396 [4] http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=3D&arnumber=3D6355= 930 [5] http://link.springer.com/chapter/10.1007/978-3-642-30422-4_10 On 20 January 2015 at 15:06, peter van der Stok wrote: > Dear all, > > I like to draw you attention to the following articles. > In these articles calculations are done on the optimal MPL interval > division with the aid of queuing networks. > > In the masters thesis "Modeling and Simulating the Trickle algorithm" ( > http://alexandria.tue.nl/extra1/afstversl/wsk-i/meyfroyt2013.pdf ) by > T.M.M. Meyfroyt (August 2013) propagation delay and message overhead for > Trickle and "Short-Trickle" are compared by simulations and analysis in > single-hop and multi-hop networks. > > The paper "Data Dissemination Performance in Large-Scale Sensor Networks"= ( > http://dl.acm.org/citation.cfm?id=3D2591981 ) by T.M.M. Meyfroyt, S.C. > Borst, O.J. Boxma, D. Denteneer (June 2014), analyzes the message overhea= d > of the original Trickle algorithm compared to the "Short-Trickle > algorithm". An extended journal version of this paper has been submitted = to > QUESTA (and has been attached in this email). > > In the paper "A Data Propagation Model for Wireless Gossiping" ( > http://arxiv.org/abs/1407.6396) by T.M.M. Meyfroyt, S.C. Borst, O.J. > Boxma, D. Denteneer (Juli 2014), an extension to the Trickle algorithm is > proposed, similar to the "New Trickle algorithm" and its performance is > analyzed and compared to that of the original Trickle algorithm. This pap= er > has recently been accepted in Performance Evaluation ( > http://www.sciencedirect.com/science/article/pii/S0166531615000024). > > Hope this is useful. > > Greetings, > > peter > > > Badis Djamaa schreef op 2015-01-20 00:43: > >> Thank you Gnawali for your comments, >> >> Could you discuss the tradeoffs due to the proposed modification? Are >>> there some scenarios that will be worse off due to the changes? >>> >> >> Figure1, page 2 of the document, shows the scheme in its best-case >> (lossless networks). From that Figure, we can see a side-effect of the >> proposed scheme which can add an extra cost in lossy-networks. >> >> Figure 4 in page 4, clearly shows this side-effect in lossy networks. >> But results in Figure 5 ( network with 90% physical loss rate) shows >> that the extra cost only affects a few following intervals and >> disappears later. Also Figure 5 shows that this additional cost does >> not affect trickle scalability. >> >> When generating heavy inconsistencies (periodically injecting new >> packets), testbed results depicted in third row of graphs in Figure 6, >> page 4, shows a bigger additional cost because of heavy inconsistent >> traffic being generated. >> >> Did you consider minor variations to your scheme - e.g., rather than >>> just the first interval starting at 0, how about the first n >>> >> intervals >> >>> starting at 0 rather than I/2? >>> >> >> Because of the side-effect depicted in Figure 4, the additional cost >> increases if we go for n intervals. Generally speaking, Trickle's >> scalability might remain logarithmic, because the extra cost only >> depends on losses. However, the extra cost is noticeable under heavy >> inconsistent traffic and wastes energy. >> >> Note however, that we made a small variation to the scheme by letting >> a node that transmitted in an Imin interval to start listening >> immediately (put c=3D0). Preliminary results look promising and show >> that the side-effect can be addressed. >> >> More results are being analysed to see whether other side-effects can >> emerge. >> >> Best, badis >> >> On 19 January 2015 at 15:01, Omprakash Gnawali >> wrote: >> >> It is a good idea to explore how to make Trickle work better. >>> >>> Could you discuss the tradeoffs due to the proposed modification? >>> Are >>> there some scenarios that will be worse off due to the changes? >>> >>> Did you consider minor variations to your scheme - e.g., rather than >>> just the first interval starting at 0, how about the first n >>> intervals >>> starting at 0 rather than I/2? >>> >>> It will be useful to poll the community what they use for Imin and >>> do >>> experiments with similar Imin. >>> >>> - om_p >>> >>> On Mon, Jan 19, 2015 at 7:51 AM, badis DJAMAA >>> wrote: >>> >>>> Dear all >>>> >>>> We have been working with Trickle for more than two years. A >>>> >>> 4-page document >>> >>>> available here https://dspace.lib.cranfield.ac.uk/handle/1826/9033 >>>> >>> [1] shows >>> >>> that by a simple modification to Trickle, a great decrease in the >>>> propagation time can be achieved without affecting Trickle's >>>> >>> scalability. >>> >>>> >>>> The results are backed by extensive simulations and large-scale >>>> >>> testbed >>> >>>> experiments. In-depth explanation along with more extensive >>>> >>> results are >>> >>>> under analysis to be announced very soon. >>>> >>>> In a nutshell the modification recommends to change step 2, >>>> >>> section 4.2. of >>> >>>> RFC6206 as follows >>>> >>>> Old: >>>> >>>> 2. When an interval begins, Trickle resets c to 0 and sets t to >>>> >>> a >>> >>>> random point in the interval, taken from the range [I/2, >>>> >>> I), that >>> >>>> is, values greater than or equal to I/2 and less than I. >>>> >>> The >>> >>>> interval ends at I. >>>> >>>> New: >>>> >>>> 2. When an interval begins, Trickle resets c to 0 and sets t to >>>> >>> a >>> >>>> random point in the interval, taken from the range: >>>> >>>> o [0, Imin) if the interval began as result of step 6 >>>> (because of an inconsistency or external events). >>>> >>>> o [I/2, I), otherwise(the interval began because of step 1 or >>>> >>> step 5) >>> >>>> >>>> The rationale behind this modification is briefly explained here >>>> https://dspace.lib.cranfield.ac.uk/handle/1826/9033 [1] >>>> >>>> any comment is warmly welcomed >>>> >>>> All the best >>>> badis >>>> >>> >> >> >> Links: >> ------ >> [1] https://dspace.lib.cranfield.ac.uk/handle/1826/9033 >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > --001a1140f5eee1c42e050e1932f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you for your comments peter,

=C2=A0

Our works on Trickle started in 2012. A first paper [1] was accepted M= arch 2013 and appeared in IEEEXplorer (October 2013). A second work [2] appeared in Springer WiNet Journal (Jun 2014). Others including variants of the ones discussed here are under review. I am aware of the useful=C2=A0 MSc thesis = mentioned, cited in our detailed report (https://dspace.lib.cranfield.ac.uk/handle/1826/= 9116). If I got it right, the thesis proposes a one-dimensional abstract mathematical m= odel of the message count and propagation time of Trickle and =E2=80=9CShort-Tri= ckle=E2=80=9D. The author also proposed to make the listen-only period parametric over ALL int= ervals.

=C2=A0

A quick look at the mentioned pre-print [3] shows that the authors moved their parametric listen-only period to the Imin interval. Clearly, this propositi= on is different than ours, which explicitly proposes to choose t from [0, Imin= ), demonstrates why and discusses the trade-offs. Despite this, t= he pre-print only models, in function of the parametric listen-only period, simplistic line-topology = lossless scenarios. Note that mathematically modelling Trickle is also performed in many of the abundant works related to Trickle such as [4] and [5] (2012).

=C2=A0

To the best of our knowledge, and as of today, no published work has proposed the New-Trickle algorithm as it is described in our first report (https:= //dspace.lib.cranfield.ac.uk/handle/1826/9033) even less as detailed in the second report (https://dspace.lib.cranf= ield.ac.uk/handle/1826/9116), which are backed with around a year-worth= of extensive public large-scale testbed experiments and realistic simulations, in accordance with RFC 6206 section = 6.7.=C2= =A0 Tweaks and Improvements to Trickle, especially this paragraph:

=C2=A0

RFC6206-TEXT: =E2=80=9CIn our experiences using Trickle, attempts to tweak its behavior a= re typically not worth the cost.=C2=A0 As written, the algorithm is already highly efficient: further reductions in transmissions or response time come at the cost of failures in edge cases.=C2=A0 Based on our experiences, we urge protocol designers to suppress the instinct to tweak or improve Trickle wit= hout a great deal of experimental evidence that the change does not violate its assumptions and break the algorithm in edge cases.=E2=80=9D

=C2=A0

To this end, we collected over 300 GB of data trace files and experimented in sever conditions. Other experiments are being run in Indriya, TWIST and IoTLab testbeds along with other simulations under TOSSIM.

=C2=A0

We have been in contact with the first author of Trickle, Prof Philip Levis (cc=E2= =80=99d) with 9-page document, stating our ideas backed with experimental r= esults (several-months-worth of work) submitted to him just after summer holidays (exactly on 02-09-2014= ). We have been in discussion with Prof Philip since then. I would like to take t= his opportunity to thank Prof Philip for his insightful and fruitful comments.

=C2=A0

Finally, as both works and the comments seem to agree on the need for revisiting Tri= ckle, we are happy to collaborate. BTW, I have written an I-D which can be used a= s a starting point for discussions. Please let me know if you are interested.

=C2=A0

Any comments and discussions concerning the detailed report are warmly welcomed

All the best, badis

=C2=A0

[1] h= ttp://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=3Dtrue&tp=3D&am= p;arnumber=3D6661808

[2] http://link.springer.com/article/10.100= 7/s11276-014-0749-3

[3] http:= //arxiv.org/abs/1407.6396

[4] http://ieeexplore.ieee.org/xpl/arti= cleDetails.jsp?tp=3D&arnumber=3D6355930

[5] http://link.springer.com/chapter/10.1007/978-3-642-3= 0422-4_10


On 20 Janua= ry 2015 at 15:06, peter van der Stok <stokcons@xs4all.nl> w= rote:
Dear all,

I like to draw you attention to the following articles.
In these articles calculations are done on the optimal MPL interval divisio= n with the aid of queuing networks.

In the masters thesis "Modeling and Simulating the Trickle algorithm&q= uot; (http://alexandria.tue.nl/extra1/afstversl/= wsk-i/meyfroyt2013.pdf ) by T.M.M. Meyfroyt (August 2013) propag= ation delay and message overhead for Trickle and "Short-Trickle" = are compared by simulations and analysis in single-hop and multi-hop networ= ks.

The paper "Data Dissemination Performance in Large-Scale Sensor Networ= ks" (http://dl.acm.org/citation.cfm?id=3D2591981 ) by T.M.M.= Meyfroyt, S.C. Borst, O.J. Boxma, D. Denteneer (June 2014), analyzes the m= essage overhead of the original Trickle algorithm compared to the "Sho= rt-Trickle algorithm". An extended journal version of this paper has b= een submitted to QUESTA (and has been attached in this email).

In the paper "A Data Propagation Model for Wireless Gossiping" (<= a href=3D"http://arxiv.org/abs/1407.6396" target=3D"_blank">http://arxiv.or= g/abs/1407.6396)=C2=A0 by T.M.M. Meyfroyt, S.C. Borst, O.J. Boxm= a, D. Denteneer (Juli 2014), an extension to the Trickle algorithm is propo= sed, similar to the "New Trickle algorithm" and its performance i= s analyzed and compared to that of the original Trickle algorithm. This pap= er has recently been accepted in Performance Evaluation (http://www.sciencedirect.com/science/article/pii/S0166531= 615000024).

Hope this is useful.

Greetings,

peter


Badis Djamaa schreef op 2015-01-20 00:43:
Thank you Gnawali for your comments,

Could you discuss the tradeoffs due to the proposed modification? Are
there some scenarios that will be worse off due to the changes?

Figure1, page 2 of the document, shows the scheme in its best-case
(lossless networks). From that Figure, we can see a side-effect of the
proposed scheme which can add an extra cost in lossy-networks.

Figure 4 in page 4, clearly shows this side-effect in lossy networks.
But results in Figure 5 ( network with 90% physical loss rate) shows
that the extra cost only affects a few following intervals and
disappears later. Also Figure 5 shows that this additional cost does
not affect trickle scalability.

When generating heavy inconsistencies (periodically injecting new
packets), testbed results depicted in third row of graphs in Figure 6,
page 4, shows a bigger additional cost because of heavy inconsistent
traffic being generated.

Did you consider minor variations to your scheme - e.g., rather than
just the first interval starting at 0, how about the first n
intervals
starting at 0 rather than I/2?

Because of the side-effect depicted in Figure 4, the additional cost
increases if we go for n intervals. Generally speaking, Trickle's
scalability might remain logarithmic, because the extra cost only
depends on losses. However, the extra cost is noticeable under heavy
inconsistent traffic and wastes energy.

Note however, that we made a small variation to the scheme by letting
a node that transmitted in an Imin interval to start listening
immediately (put c=3D0). Preliminary results look promising and show
that the side-effect can be addressed.

More results are being analysed to see whether other side-effects can
emerge.

Best, badis

On 19 January 2015 at 15:01, Omprakash Gnawali <gnawali@cs.uh.edu>
wrote:

It is a good idea to explore how to make Trickle work better.

Could you discuss the tradeoffs due to the proposed modification?
Are
there some scenarios that will be worse off due to the changes?

Did you consider minor variations to your scheme - e.g., rather than
just the first interval starting at 0, how about the first n
intervals
starting at 0 rather than I/2?

It will be useful to poll the community what they use for Imin and
do
experiments with similar Imin.

- om_p

On Mon, Jan 19, 2015 at 7:51 AM, badis DJAMAA
<badis.djamaa= @ieee.org> wrote:
Dear all

We have been working with Trickle for more than two years. A
4-page document
available here https://dspace.lib.cranfield.ac.uk/handle/1826= /9033
[1] shows

that by a simple modification to Trickle, a great decrease in the
propagation time can be achieved without affecting Trickle's
scalability.

The results are backed by extensive simulations and large-scale
testbed
experiments. In-depth explanation along with more extensive
results are
under analysis to be announced very soon.

In a nutshell the modification recommends to change step 2,
section 4.2. of
RFC6206 as follows

Old:

2. When an interval begins, Trickle resets c to 0 and sets t to
a
random point in the interval, taken from the range [I/2,
I), that
is, values greater than or equal to I/2 and less than I.
The
interval ends at I.

New:

2. When an interval begins, Trickle resets c to 0 and sets t to
a
random point in the interval, taken from the range:

o [0, Imin) if the interval began as result of step 6
(because of an inconsistency or external events).

o [I/2, I), otherwise(the interval began because of step 1 or
step 5)

The rationale behind this modification is briefly explained here
https://dspace.lib.cranfield.ac.uk/handle/1826/90= 33 [1]

any comment is warmly welcomed

All the best
badis



Links:
------
[1] https://dspace.lib.cranfield.ac.uk/handle/1826/9033<= span class=3D"">

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

--001a1140f5eee1c42e050e1932f1-- From nobody Mon Feb 2 08:32: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 9D5781A8731 for ; Mon, 2 Feb 2015 08:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 2ykOOAbNzfdz for ; Mon, 2 Feb 2015 08:15:50 -0800 (PST) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 862131A8760 for ; Mon, 2 Feb 2015 08:13:08 -0800 (PST) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id C89F723CA79 for ; Mon, 2 Feb 2015 10:13:07 -0600 (CST) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wijYyidsh6E7 for ; Mon, 2 Feb 2015 10:13:04 -0600 (CST) Received: from it.cs.uh.edu (unknown [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 31D0523CA77 for ; Mon, 2 Feb 2015 10:13:04 -0600 (CST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by it.cs.uh.edu (Postfix) with ESMTP id 0DA782A280BD for ; Mon, 2 Feb 2015 10:23:38 -0600 (CST) Received: by mail-pa0-f46.google.com with SMTP id lj1so83995933pab.5 for ; Mon, 02 Feb 2015 08:13:03 -0800 (PST) X-Received: by 10.70.47.104 with SMTP id c8mr8522483pdn.42.1422893583411; Mon, 02 Feb 2015 08:13:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.49.73 with HTTP; Mon, 2 Feb 2015 08:12:43 -0800 (PST) In-Reply-To: References: From: Omprakash Gnawali Date: Mon, 2 Feb 2015 10:12:43 -0600 Message-ID: To: Badis Djamaa Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 08:32:25 -0800 Cc: "Thomas Heide Clausen \(work\)" , Michael Richardson , ROLL WG , badis DJAMAA , Jonathan Hui , Ines Robles , JeongGil Ko Subject: Re: [Roll] Revisiting the Trickle Algorithm 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, 02 Feb 2015 16:15:51 -0000 On Mon, Jan 19, 2015 at 5:35 PM, Badis Djamaa wrote: > Thank you Gnawali for your comments, > > > >>Could you discuss the tradeoffs due to the proposed modification? Are >>there some scenarios that will be worse off due to the changes? > > > > Figure1, page 2 of the document, shows the scheme in its best-case (lossless > networks). From that Figure, we can see a side-effect of the proposed scheme > which can add an extra cost in lossy-networks. > > > > Figure 4 in page 4, clearly shows this side-effect in lossy networks. But > results in Figure 5 ( network with 90% physical loss rate) shows that the > extra cost only affects a few following intervals and disappears later. Also > Figure 5 shows that this additional cost does not affect trickle > scalability. > > > > When generating heavy inconsistencies (periodically injecting new packets), > testbed results depicted in third row of graphs in Figure 6, page 4, shows a > bigger additional cost because of heavy inconsistent traffic being > generated. > > > >>Did you consider minor variations to your scheme - e.g., rather than >>just the first interval starting at 0, how about the first n intervals >>starting at 0 rather than I/2? > > > > Because of the side-effect depicted in Figure 4, the additional cost > increases if we go for n intervals. Generally speaking, Trickle's > scalability might remain logarithmic, because the extra cost only depends on > losses. However, the extra cost is noticeable under heavy inconsistent > traffic and wastes energy. > > > > Note however, that we made a small variation to the scheme by letting a node > that transmitted in an Imin interval to start listening immediately (put > c=0). Preliminary results look promising and show that the side-effect can > be addressed. > > > > More results are being analysed to see whether other side-effects can > emerge. Look forward to this. Could you also post your code so others can do experiments on different testbeds to verify the results once you have converged on a design that addresses the side effects. For example, I can try to have a student do this as a short project in TinyOS. If the side effects remain, this will be a question of tradeoff in which case it is better to have this as a commentary in the RFC rather than replace it. It will also be helpful to do a survey of what type of intervals are being used by the community so we know how big a problem this is. - om_p From nobody Mon Feb 2 08:37: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 6B6AE1A870E for ; Mon, 2 Feb 2015 08:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 xpyefq3kn9of for ; Mon, 2 Feb 2015 08:37:44 -0800 (PST) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id EBB741A802E for ; Mon, 2 Feb 2015 08:37:30 -0800 (PST) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A4A1123CA79 for ; Mon, 2 Feb 2015 10:37:30 -0600 (CST) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXB2SoV7QRs6 for ; Mon, 2 Feb 2015 10:37:27 -0600 (CST) Received: from it.cs.uh.edu (unknown [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 794AE23CA77 for ; Mon, 2 Feb 2015 10:37:27 -0600 (CST) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by it.cs.uh.edu (Postfix) with ESMTP id 66EDA2A280BD for ; Mon, 2 Feb 2015 10:48:01 -0600 (CST) Received: by mail-pa0-f41.google.com with SMTP id kq14so84362462pab.0 for ; Mon, 02 Feb 2015 08:37:26 -0800 (PST) X-Received: by 10.66.234.2 with SMTP id ua2mr31644504pac.4.1422895046788; Mon, 02 Feb 2015 08:37:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.49.73 with HTTP; Mon, 2 Feb 2015 08:37:06 -0800 (PST) In-Reply-To: References: From: Omprakash Gnawali Date: Mon, 2 Feb 2015 10:37:06 -0600 Message-ID: To: ROLL WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Roll] Fwd: Revisiting the Trickle Algorithm 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, 02 Feb 2015 16:37:52 -0000 ---------- Forwarded message ---------- From: Omprakash Gnawali Date: Mon, Feb 2, 2015 at 10:12 AM Subject: Re: Revisiting the Trickle Algorithm To: Badis Djamaa Cc: badis DJAMAA , ROLL WG , "Thomas Heide Clausen (work)" , Philip Levis , JeongGil Ko , JeongGil Ko , Jonathan Hui , Ines Robles , Michael Richardson On Mon, Jan 19, 2015 at 5:35 PM, Badis Djamaa wrote: > Thank you Gnawali for your comments, > > > >>Could you discuss the tradeoffs due to the proposed modification? Are >>there some scenarios that will be worse off due to the changes? > > > > Figure1, page 2 of the document, shows the scheme in its best-case (lossless > networks). From that Figure, we can see a side-effect of the proposed scheme > which can add an extra cost in lossy-networks. > > > > Figure 4 in page 4, clearly shows this side-effect in lossy networks. But > results in Figure 5 ( network with 90% physical loss rate) shows that the > extra cost only affects a few following intervals and disappears later. Also > Figure 5 shows that this additional cost does not affect trickle > scalability. > > > > When generating heavy inconsistencies (periodically injecting new packets), > testbed results depicted in third row of graphs in Figure 6, page 4, shows a > bigger additional cost because of heavy inconsistent traffic being > generated. > > > >>Did you consider minor variations to your scheme - e.g., rather than >>just the first interval starting at 0, how about the first n intervals >>starting at 0 rather than I/2? > > > > Because of the side-effect depicted in Figure 4, the additional cost > increases if we go for n intervals. Generally speaking, Trickle's > scalability might remain logarithmic, because the extra cost only depends on > losses. However, the extra cost is noticeable under heavy inconsistent > traffic and wastes energy. > > > > Note however, that we made a small variation to the scheme by letting a node > that transmitted in an Imin interval to start listening immediately (put > c=0). Preliminary results look promising and show that the side-effect can > be addressed. > > > > More results are being analysed to see whether other side-effects can > emerge. Look forward to this. Could you also post your code so others can do experiments on different testbeds to verify the results once you have converged on a design that addresses the side effects. For example, I can try to have a student do this as a short project in TinyOS. If the side effects remain, this will be a question of tradeoff in which case it is better to have this as a commentary in the RFC rather than replace it. It will also be helpful to do a survey of what type of intervals are being used by the community so we know how big a problem this is. - om_p From nobody Mon Feb 2 13:56: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 B5E341A037A for ; Mon, 2 Feb 2015 13:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pWaJo4vhxzX for ; Mon, 2 Feb 2015 13:56:51 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 B48261A1AC6 for ; Mon, 2 Feb 2015 13:56:50 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id l13so20343974iga.1 for ; Mon, 02 Feb 2015 13:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vjpQQZIKeL9clnVTofXRdmOfATHrJ9O8gljV7JPlrd4=; b=c6PXLSIzezmiqXThnfl1/rqH7Op0DTbuQm+oPZa8fJJ0c+KljHFSXDwJtPIy3N6DSf 4xmwcRJ0u3qateXLlu6bG5WisoiDdODPHUBjyw/MZvVBnI2S/EYY3fVCsVfo+IhRy/+I ZdAogZHv8fnrT/wGo/LeAqGgbRb01jEeb0ozMeSgEXND9rbLzG1CqdOoJrymCZl1+OqL Kt5A4q8jpsXHyIz1n/eMu8Hmk8VFAwTxETATAEqag+XoDyDTvBJ2cYeB89b2b47JaOZZ ixcRXschbLv2y5kdGLYfajB0P0ybMzpZk7b6w3b9dqJr2+RZS8rgSzWzDFQOtaUIbs+E Ai/Q== MIME-Version: 1.0 X-Received: by 10.107.132.101 with SMTP id g98mr19786655iod.66.1422914209839; Mon, 02 Feb 2015 13:56:49 -0800 (PST) Received: by 10.107.52.16 with HTTP; Mon, 2 Feb 2015 13:56:49 -0800 (PST) In-Reply-To: <01cd01d03e3f$e688a140$b399e3c0$@olddog.co.uk> References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> <32747.1421682839@sandelman.ca> <01cd01d03e3f$e688a140$b399e3c0$@olddog.co.uk> Date: Mon, 2 Feb 2015 21:56:49 +0000 Message-ID: From: Badis Djamaa To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a113eccb8060045050e220884 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] Telechat update notice: 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, 02 Feb 2015 21:56:54 -0000 --001a113eccb8060045050e220884 Content-Type: text/plain; charset=UTF-8 Much clearer now Thnak you Adrian best, badis On 1 February 2015 at 16:55, Adrian Farrel wrote: > Hi Badis, > > I'm finally processing your comments on this draft before it goes in front > of the IESG on Thursday. > > Comments in line. > > > Draft 11, Section 5.4. MPL Parameters states: > > > > MPL-TEXT: 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. > > Starting from the above statement (dubbed MPL-TEXT), I have two main > comments > > 1) terminology related: [RFC6206] (4.1. Parameters and Variables) > defines "The > > maximum Trickle timer interval" as: > > RFC6206-TEXT1: The maximum interval size, Imax, is described as a > number of > > doublings of the minimum interval size (the base-2 log(max/min)). > > For example, a protocol might define Imax as 16. If the minimum > > interval is 100 ms, then the amount of time specified by Imax is > > 100 ms * 65,536, i.e., 6,553.6 seconds or approximately > > 109 minutes. > > > > MPL-TEXT refers to RFC6206 for the definition of "The maximum Trickle > timer > > interval". However, I think "The maximum Trickle timer interval" usage in > > MPL-TEXT is different than its definition in RFC6206-TEXT1. Thus, I > think it > > would be better to explicitly specify what is meant by "The maximum > Trickle > > timer interval" to avoid any ambiguity. > > I agree this is somewhat confusing. > However, it states that Imax "is described as a number of doublings" not > that Imax is a count of doublings. > Sigh - we should have made this clearer in 6206. > Of course, an implementation can do this however it likes, but Imax > specifies an amount of time, and I think 6206 is clear about this in the > text you quoted. > > That means that the text in this draft is also unambiguous that Imax > specifies a time. > > > Note that the same comment is also valid for this MPL text (Draft 11, > Section 5.4. > > MPL Parameters ) 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. > > Same answer :-) > > > 2) Now arriving to the main concern, suppose that DATA_MESSAGE_IMAX > > literally means the maximum trickle interval (the time specified by Imax > using > > RFC6206 terminology), then: "DATA_MESSAGE_IMAX has a default value equal > > to DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted" > behavior. > > This is because RFC6206's section 4.2. Algorithm Description, rule 6 > states: > > RFC6206-TEXT2: 6. ...If I is equal to Imin when Trickle hears an > > "inconsistent" transmission, Trickle does nothing... > > Recommending "DATA_MESSAGE_IMAX has a default value equal to > > DATA_MESSAGE_IMIN." makes the trickle timer always fall under > RFC6206-TEXT2 > > and hence the timer will never get reset when hearing "inconsistencies" > > However, if this default recommendation is deliberately designed > considering the > > above point, then choosing a non-default value of DATA_MESSAGE_IMAX will > > result in a different behavior (nodes will reset their timers when > receiving > > inconsistencies). This might even propagate faster than the default > recommendation. > > > > To avoid the aforementioned ambiguities, I can think of recommending > either a > > default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose a > > change to RFC6206-TEXT2 in the MPL draf, if the current default > recommendation > > is not deliberately designed to work as shown above. Otherwise, > explicitly state > > in the MPL text that choosing a non-default value of DATA_MESSAGE_IMAX > may > > result in different behavior. > > Well, we can come back and work on 6206, but we only have *this* document > in front of us at the moment. > > I tripped over the IMAX==IMIN piece until reading (later in the section) > the explanation... > > | Setting DATA_MESSAGE_IMAX to the same as DATA_MESSAGE_IMIN > | in this case is acceptable since subsequent MPL Data Message > | retransmissions are triggered by MPL Control Messages, where > | CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN. > > > 3) By the way, RFC6206 also contains a typo, which might confuse the > reader, > > in the following text (RFC6206 4.2. Algorithm Description, rule 1): > > Current: > > 1. When the algorithm starts execution, it sets I to a value in the > > range of [Imin, Imax] -- that is, greater than or equal to Imin > > and less than or equal to Imax. The algorithm then begins the > > first interval. > > Following the definition of the maximum interval size (RFC6206-TEXT1, > > above) this rule should be rewritten > > Proposed: > > 1. When the algorithm starts execution, it sets I to a value in the > > range of [Imin, Imin x POW(2, Imax)] -- that is, greater than or > equal to Imin > > and less than or equal to the time specified by Imax. The > algorithm then begins > > the first interval. > > This could be approached with an Errata Report for RFC 6206, but I think > you have fixated on how Imax is expressed, rather than the fact that Imax > is a time. > > Thanks, > Adrian > > --001a113eccb8060045050e220884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Much clearer now
Thnak you Adrian
=C2=A0
best, badis
On 1 February 2015 at 16:55, Adrian Farrel <a= drian@olddog.co.uk> wrote:
Hi Badis,

I'm finally proc= essing your comments on this draft before it goes in front of the IESG on T= hursday.

Comments in line.

> Draft 11, Section 5.4.= =C2=A0 MPL Parameters states:
>
> MPL-TEXT: DATA MESSAGE_IMAX= =C2=A0 The maximum Trickle timer interval, as defined in
>=C2=A0 =C2= =A0 =C2=A0 [RFC6206], for MPL Data Message transmissions.=C2=A0 DATA_MESSAG= E_IMAX
>=C2=A0 =C2=A0 =C2=A0 has a default value equal to DATA_MESSAG= E_IMIN.
> Starting from the above statement (dubbed MPL-TEXT), I have= two main comments
> 1) terminology related: [RFC6206]=C2=A0 (4.1.=C2= =A0 Parameters and Variables) defines "The
> maximum Trickle tim= er interval" as:
> RFC6206-TEXT1:=C2=A0 The maximum interval siz= e, Imax, is described as a number of
>=C2=A0 =C2=A0 =C2=A0 doublings = of the minimum interval size (the base-2 log(max/min)).
>=C2=A0 =C2= =A0 =C2=A0 For example, a protocol might define Imax as 16.=C2=A0 If the mi= nimum
>=C2=A0 =C2=A0 =C2=A0 interval is 100 ms, then the amount of ti= me specified by Imax is
>=C2=A0 =C2=A0 =C2=A0 100 ms * 65,536, i.e., = 6,553.6 seconds or approximately
>=C2=A0 =C2=A0 =C2=A0 109 minutes.>
> MPL-TEXT refers to RFC6206 for the definition of "The m= aximum Trickle timer
> interval". However, I think "The max= imum Trickle timer interval" usage in
> MPL-TEXT is different th= an its definition in RFC6206-TEXT1. Thus, I think it
> would be bette= r to explicitly specify what is meant by "The maximum Trickle
> = timer interval" to avoid any ambiguity.

I agree this is = somewhat confusing.
However, it states that Imax "is described as a= number of doublings" not that Imax is a count of doublings.
Sigh -= we should have made this clearer in 6206.
Of course, an implementation = can do this however it likes, but Imax specifies an amount of time, and I t= hink 6206 is clear about this in the text you quoted.

That means tha= t the text in this draft is also unambiguous that Imax specifies a time.
> Note that the same comment is also valid for this MPL text = (Draft 11, Section 5.4.
>=C2=A0 MPL Parameters ) CONTROL_MESSAGE_IMAX= =C2=A0 The maximum Trickle timer interval,
> as defined in [RFC6206],= for MPL Control Message transmissions.
> CONTROL_MESSAGE_IMAX has a = default value of 5 minutes.

Same answer :-)

>= 2) Now arriving to the main concern, suppose that=C2=A0 DATA_MESSAGE_IMAX<= br>> literally means the maximum trickle interval (the time specified by= Imax using
> RFC6206 terminology), then: "DATA_MESSAGE_IMAX has= a default value equal
> to DATA_MESSAGE_IMIN." in MPL-TEXT coul= d result in a "non-wanted" behavior.
> This is because RFC6= 206's section 4.2.=C2=A0 Algorithm Description, rule 6 states:
> = RFC6206-TEXT2: 6.=C2=A0 ...If I is equal to Imin when Trickle hears an
&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0"inconsistent" transmission, Trickl= e does nothing...
> Recommending "DATA_MESSAGE_IMAX has a defaul= t value equal to
> DATA_MESSAGE_IMIN." makes the trickle timer a= lways fall under RFC6206-TEXT2
> and hence the timer will never get r= eset when hearing "inconsistencies"
> However, if this defa= ult recommendation is deliberately designed=C2=A0 considering the
> a= bove point, then choosing a non-default value of DATA_MESSAGE_IMAX will
= > result in a different behavior (nodes will reset their timers when rec= eiving
> inconsistencies). This might even propagate faster than the = default recommendation.
>
> To avoid the aforementioned ambigui= ties, I can think of recommending either a
> default DATA_MESSAGE_IMA= X equals 2*DATA_MESSAGE_IMIN or propose a
> change to RFC6206-TEXT2 i= n the MPL draf, if the current default recommendation
> is not delibe= rately designed to work as shown above. Otherwise, explicitly state
>= in the MPL text that choosing a non-default value of DATA_MESSAGE_IMAX may=
> result in different behavior.

Well, we can come back= and work on 6206, but we only have *this* document in front of us at the m= oment.

I tripped over the IMAX=3D=3DIMIN piece until reading (later = in the section) the explanation...

|=C2=A0 Setting DATA_MESSAGE_IMAX= to the same as DATA_MESSAGE_IMIN
|=C2=A0 in this case is acceptable sin= ce subsequent MPL Data Message
|=C2=A0 retransmissions are triggered by = MPL Control Messages, where
|=C2=A0 CONTROL_MESSAGE_IMAX is greater than= CONTROL_MESSAGE_IMIN.

> 3) By the way, RFC6206 also contai= ns a typo, which might confuse the reader,
> in the following text (R= FC6206 4.2. Algorithm Description, rule 1):
> Current:
> 1.=C2= =A0 When the algorithm starts execution, it sets I to a value in the
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0range of [Imin, Imax] -- that is, greater than = or equal to Imin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and less than or equal t= o Imax.=C2=A0 The algorithm then begins the
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0first interval.
> Following the definition of the maximum interval= size (RFC6206-TEXT1,
> above) this rule should be rewritten
> = Proposed:
> 1.=C2=A0 When the algorithm starts execution, it sets I t= o a value in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0range of [Imin, Imin x P= OW(2, Imax)] -- that is, greater than or equal to Imin
>=C2=A0 =C2=A0= =C2=A0 =C2=A0and less than or equal to the time specified by Imax.=C2=A0 T= he algorithm then begins
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the first interv= al.

This could be approached with an Errata Report for RFC 62= 06, but I think you have fixated on how Imax is expressed, rather than the = fact that Imax is a time.

Thanks,
Adrian


--001a113eccb8060045050e220884-- From nobody Wed Feb 4 10:18: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 004391A1A64 for ; Wed, 4 Feb 2015 10:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXzcWAtTmJra for ; Wed, 4 Feb 2015 10:17:57 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 008211A1A3E for ; Wed, 4 Feb 2015 10:17:56 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so36540912igq.0 for ; Wed, 04 Feb 2015 10:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=do0mMRZnsbZkggL2ghzHhp/lVLPh50xTZTtVDbPYUhM=; b=k9iCpfI1CokUjge7g3CSW6RRgHSl6ZCrQ+ldpknkFXYjdxsn0RJQWdNty7BAMDQkRG DVynB+eeJUrdRqOADPEoEyOYBvHXF4w4i5LnSNTWyM8d5+nrUZF0L7lLpcIeh20mofUV RUxiLesnl0+CNAV1tMZHToEnB9x3OPbXR9FCKaFFWlxD306mXmIDIVa4DCrwPym+Qc86 r2FaP4QxTTei4BltbkREgk00ATBsVygF0TesZ6nv1Z9v/fjKxtHUssGxiQf/om+644NW /Fe3koe4fwYPKRX82QGbf7boBbwJrKd4Tqz76bwq3umltPDQyCa5fqAA1TKhqjYD7gpt LQrA== MIME-Version: 1.0 X-Received: by 10.50.108.108 with SMTP id hj12mr3666126igb.47.1423073876151; Wed, 04 Feb 2015 10:17:56 -0800 (PST) Received: by 10.107.52.16 with HTTP; Wed, 4 Feb 2015 10:17:56 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Feb 2015 18:17:56 +0000 Message-ID: From: Badis Djamaa To: Omprakash Gnawali Content-Type: multipart/alternative; boundary=089e0149392ae09464050e473420 Archived-At: Cc: Jonathan Hui , "Thomas Heide Clausen \(work\)" , Michael Richardson , ROLL WG , Ines Robles , JeongGil Ko Subject: Re: [Roll] Revisiting the Trickle Algorithm 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, 04 Feb 2015 18:18:00 -0000 --089e0149392ae09464050e473420 Content-Type: text/plain; charset=UTF-8 Thank you Omprakash for your email That's great. The side-effect discussed in section 4.5. of the detailed report [1] might provide other benefits. In sparse networks using k=1, "New-Trickle" outperformed Trickle in both time/cost aspects, as shown in Appendix A. When k > 1, however, it generated more packets than Trickle. This is also observed in dense single-hop networks (Figure 13 (d), page 22). In dense multi-hop networks, this side-effect is less noticeable (see results on pages 18-19), but another effect can emerge with smaller Imin (Figure 11 (d)). I think this is not related to "New-Trickle" as it emerges from the efficiency of CSMA strategies and timer-based suppression mechanisms. Note that "New-trickle" generally transmit less in the Imin interval as can be seen from the third column of graphs. Also, it seems that "New-Trickle" can provide a better load distribution (Figure 10, page 12). Allowing a node to rest c to zero at time t of an Imin interval (rather than at the beginning of the next interval) might suppress most of this cost. I am doing some simulations with this second design. However, I think a detailed study is required to decide which design to choose. We can also consider other designs. I will send you a copy of the TinyOS code as soon as I clean it up. Both designs are implemented and I think your student can help us to choose. Concerning Imin and k values, I agree that such a survey better guides the evaluation. I surveyed some of the use-cases such as RPL, MPL, CTP, some dissemination protocols and AMI use-cases. A generic list is still to be built. [1]https://dspace.lib.cranfield.ac.uk/handle/1826/9116 all the best badis On 2 February 2015 at 16:12, Omprakash Gnawali wrote: > On Mon, Jan 19, 2015 at 5:35 PM, Badis Djamaa > wrote: > > Thank you Gnawali for your comments, > > > > > > > >>Could you discuss the tradeoffs due to the proposed modification? Are > >>there some scenarios that will be worse off due to the changes? > > > > > > > > Figure1, page 2 of the document, shows the scheme in its best-case > (lossless > > networks). From that Figure, we can see a side-effect of the proposed > scheme > > which can add an extra cost in lossy-networks. > > > > > > > > Figure 4 in page 4, clearly shows this side-effect in lossy networks. But > > results in Figure 5 ( network with 90% physical loss rate) shows that the > > extra cost only affects a few following intervals and disappears later. > Also > > Figure 5 shows that this additional cost does not affect trickle > > scalability. > > > > > > > > When generating heavy inconsistencies (periodically injecting new > packets), > > testbed results depicted in third row of graphs in Figure 6, page 4, > shows a > > bigger additional cost because of heavy inconsistent traffic being > > generated. > > > > > > > >>Did you consider minor variations to your scheme - e.g., rather than > >>just the first interval starting at 0, how about the first n intervals > >>starting at 0 rather than I/2? > > > > > > > > Because of the side-effect depicted in Figure 4, the additional cost > > increases if we go for n intervals. Generally speaking, Trickle's > > scalability might remain logarithmic, because the extra cost only > depends on > > losses. However, the extra cost is noticeable under heavy inconsistent > > traffic and wastes energy. > > > > > > > > Note however, that we made a small variation to the scheme by letting a > node > > that transmitted in an Imin interval to start listening immediately (put > > c=0). Preliminary results look promising and show that the side-effect > can > > be addressed. > > > > > > > > More results are being analysed to see whether other side-effects can > > emerge. > > > Look forward to this. Could you also post your code so others can do > experiments on different testbeds to verify the results once you have > converged on a design that addresses the side effects. For example, I > can try to have a student do this as a short project in TinyOS. > > If the side effects remain, this will be a question of tradeoff in > which case it is better to have this as a commentary in the RFC rather > than replace it. > > It will also be helpful to do a survey of what type of intervals are > being used by the community so we know how big a problem this is. > > - om_p > --089e0149392ae09464050e473420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Omprakash for your= email

That's great.

The side= -effect discussed in section 4.5. of the detailed report [1] might provide = other benefits.

In sparse networks using k=3D1, "New-Trickle&q= uot; outperformed Trickle in both time/cost aspects, as shown in Appendix A= . When k > 1, however, it generated more packets than Trickle. This is a= lso observed in dense single-hop networks (Figure 13 (d), page 22).

=
In dense multi-hop networks, this side-effect is less noticeable (see= results on pages 18-19), but another effect can emerge with smaller Imin (= Figure 11 (d)). I think this is not related to "New-Trickle" as i= t emerges from the efficiency of CSMA strategies and timer-based suppressio= n mechanisms. Note that "New-trickle" generally transmit less in = the Imin interval as can be seen from the third column of graphs. Also, it = seems that "New-Trickle" can provide a better load distribution (= Figure 10, page 12).

Allowing a node to rest c to zero at time= t of an Imin interval (rather than at the beginning of the next interval) = might suppress most of this cost. I am doing some simulations with this sec= ond design. However, I think a detailed study is required to decide which d= esign to choose. We can also consider other designs.

I will se= nd you a copy of the TinyOS code as soon as I clean it up. Both designs are= implemented and I think your student can help us to choose.

<= div>Concerning Imin and k values, I agree that such a survey better guides = the evaluation. I surveyed some of the use-cases such as RPL, MPL, CTP, som= e dissemination protocols and AMI use-cases. A generic list is still to be = built.
all the bes= t
badis


On 2 February 2015 at 16:12= , Omprakash Gnawali <gnawali@cs.uh.edu> wrote:
On Mon, Jan 19= , 2015 at 5:35 PM, Badis Djamaa <badis.djamaa@gmail.com> wrote:
> Thank you Gnawali for your comments,
>
>
>
>>Could you discuss the tradeoffs due to the proposed modification? A= re
>>there some scenarios that will be worse off due to the changes?
>
>
>
> Figure1, page 2 of the document, shows the scheme in its best-case (lo= ssless
> networks). From that Figure, we can see a side-effect of the proposed = scheme
> which can add an extra cost in lossy-networks.
>
>
>
> Figure 4 in page 4, clearly shows this side-effect in lossy networks. = But
> results in Figure 5 ( network with 90% physical loss rate) shows that = the
> extra cost only affects a few following intervals and disappears later= . Also
> Figure 5 shows that this additional cost does not affect trickle
> scalability.
>
>
>
> When generating heavy inconsistencies (periodically injecting new pack= ets),
> testbed results depicted in third row of graphs in Figure 6, page 4, s= hows a
> bigger additional cost because of heavy inconsistent traffic being
> generated.
>
>
>
>>Did you consider minor variations to your scheme - e.g., rather tha= n
>>just the first interval starting at 0, how about the first n interv= als
>>starting at 0 rather than I/2?
>
>
>
> Because of the side-effect depicted in Figure 4, the additional cost > increases if we go for n intervals. Generally speaking, Trickle's<= br> > scalability might remain logarithmic, because the extra cost only depe= nds on
> losses. However, the extra cost is noticeable under heavy inconsistent=
> traffic and wastes energy.
>
>
>
> Note however, that we made a small variation to the scheme by letting = a node
> that transmitted in an Imin interval to start listening immediately (p= ut
> c=3D0). Preliminary results look promising and show that the side-effe= ct can
> be addressed.
>
>
>
> More results are being analysed to see whether other side-effects can<= br> > emerge.


Look forward to this. Could you also post your code so others c= an do
experiments on different testbeds to verify the results once you have
converged on a design that addresses the side effects. For example, I
can try to have a student do this as a short project in TinyOS.

If the side effects remain, this will be a question of tradeoff in
which case it is better to have this as a commentary in the RFC rather
than replace it.

It will also be helpful to do a survey of what type of intervals are
being used by the community so we know how big a problem this is.

- om_p

--089e0149392ae09464050e473420-- From nobody Thu Feb 5 10:51: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 8D4FC1A8A76; Thu, 5 Feb 2015 10:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdmes-l-cU7Z; Thu, 5 Feb 2015 10:51:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9345F1A8A7A; Thu, 5 Feb 2015 10:50:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-roll-admin-local-policy.all@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205185040.22249.82102.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 10:50:40 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] Telechat update notice: 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: Thu, 05 Feb 2015 18:51:03 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Thu Feb 5 10:51:22 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AE8131A8A79; Thu, 5 Feb 2015 10:51:03 -0800 (PST) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4FC1A8A76; Thu, 5 Feb 2015 10:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdmes-l-cU7Z; Thu, 5 Feb 2015 10:51:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9345F1A8A7A; Thu, 5 Feb 2015 10:50:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-roll-admin-local-policy.all@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205185040.22249.82102.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 10:50:40 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] Telechat update notice: 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: Thu, 05 Feb 2015 18:51:03 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Fri Feb 6 01:05: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 D44001A0145; Fri, 6 Feb 2015 01:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlQucDrlCYn4; Fri, 6 Feb 2015 01:04:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8651A1A9D; Fri, 6 Feb 2015 01:04:52 -0800 (PST) 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: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206090452.1359.26238.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 01:04:52 -0800 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-admin-local-policy-03.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: Fri, 06 Feb 2015 09:04:59 -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 : Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL) Authors : Peter van der Stok Robert Cragie Filename : draft-ietf-roll-admin-local-policy-03.txt Pages : 15 Date : 2015-02-06 Abstract: The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low power and Lossy Networks (MPL) multicast messages with admin-local scope in a border router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-admin-local-policy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 6 01:05:17 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 8DE421A0430; Fri, 6 Feb 2015 01:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2sBmq_FdXZe; Fri, 6 Feb 2015 01:04:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 389A81A1AA0; Fri, 6 Feb 2015 01:04:52 -0800 (PST) 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: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206090452.1359.49640.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 01:04:52 -0800 Archived-At: Subject: [Roll] New Version Notification - draft-ietf-roll-admin-local-policy-03.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: Fri, 06 Feb 2015 09:05:00 -0000 A new version (-03) has been submitted for draft-ietf-roll-admin-local-policy: http://www.ietf.org/internet-drafts/draft-ietf-roll-admin-local-policy-03.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Feb 6 01:05:18 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 43A571A049A; Fri, 6 Feb 2015 01:05:01 -0800 (PST) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE421A0430; Fri, 6 Feb 2015 01:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2sBmq_FdXZe; Fri, 6 Feb 2015 01:04:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 389A81A1AA0; Fri, 6 Feb 2015 01:04:52 -0800 (PST) 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: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206090452.1359.49640.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 01:04:52 -0800 Archived-At: Subject: [Roll] New Version Notification - draft-ietf-roll-admin-local-policy-03.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: Fri, 06 Feb 2015 09:05:01 -0000 A new version (-03) has been submitted for draft-ietf-roll-admin-local-policy: http://www.ietf.org/internet-drafts/draft-ietf-roll-admin-local-policy-03.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Feb 6 01:17:55 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 24EC51A19F8 for ; Fri, 6 Feb 2015 01:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unuVWKvkdxfi for ; Fri, 6 Feb 2015 01:17:50 -0800 (PST) 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 2C5ED1A023E for ; Fri, 6 Feb 2015 01:17:50 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.207]) by smtp-cloud2.xs4all.net with ESMTP id oxHo1p00F4U4Moq01xHoZs; Fri, 06 Feb 2015 10:17:48 +0100 Received: from AMontpellier-654-1-194-252.w90-0.abo.wanadoo.fr ([90.0.97.252]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 06 Feb 2015 10:17:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 06 Feb 2015 10:17:48 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <019bae404b42bcb0e98c316cb4499b39@xs4all.nl> X-Sender: stokcons@xs4all.nl (b/yjtIApOBtfTh23iu5fSISDluCo0Eii) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] Fwd: New Version Notification - draft-ietf-roll-admin-local-policy-03.txt 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: Fri, 06 Feb 2015 09:17:52 -0000 A new version (-03) has been submitted for draft-ietf-roll-admin-local-policy: http://www.ietf.org/internet-drafts/draft-ietf-roll-admin-local-policy-03.txt The new draft contains text following the reviews received to improve the document. Many thanks to the reviewers for their comments. - The use of the zone concept is clarified - The layer-2 security policy during forwarding is clarified - security considerations are redone - and divers omissions and typos have been addressed. Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-admin-local-policy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Fri Feb 6 08:33:54 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 64AE41A6FBC; Fri, 6 Feb 2015 08:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjrrGC7jvk-u; Fri, 6 Feb 2015 08:33:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA13C1A6FF7; Fri, 6 Feb 2015 08:33:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206163315.20277.31447.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 08:33:15 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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: Fri, 06 Feb 2015 16:33:37 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Fri Feb 6 08:33:56 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C36B31A6FF6; Fri, 6 Feb 2015 08:33:37 -0800 (PST) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE41A6FBC; Fri, 6 Feb 2015 08:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjrrGC7jvk-u; Fri, 6 Feb 2015 08:33:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA13C1A6FF7; Fri, 6 Feb 2015 08:33:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206163315.20277.31447.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 08:33:15 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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: Fri, 06 Feb 2015 16:33:37 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Fri Feb 6 10:06:13 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 0E6441A8734; Fri, 6 Feb 2015 10:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhDBlXHvPkrh; Fri, 6 Feb 2015 10:06:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDBB1A8710; Fri, 6 Feb 2015 10:05:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206180541.5494.46236.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 10:05:41 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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: Fri, 06 Feb 2015 18:06:08 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Fri Feb 6 10:06:17 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 95D571A872F; Fri, 6 Feb 2015 10:06:08 -0800 (PST) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6441A8734; Fri, 6 Feb 2015 10:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhDBlXHvPkrh; Fri, 6 Feb 2015 10:06:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDBB1A8710; Fri, 6 Feb 2015 10:05:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206180541.5494.46236.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 10:05:41 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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: Fri, 06 Feb 2015 18:06:08 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Mon Feb 9 04:08:46 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 ACBE51A036E for ; Mon, 9 Feb 2015 04:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92r4cNQ_ZdVb for ; Mon, 9 Feb 2015 04:08:10 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3741A036D for ; Mon, 9 Feb 2015 04:08:09 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t19C85fU017673; Mon, 9 Feb 2015 12:08:05 GMT Received: from 950129200 (xdsl-77-74-119-17.c.btirol.at [77.74.119.17] (may be forged)) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t19C83T0017610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 12:08:04 GMT From: "Adrian Farrel" To: Date: Mon, 9 Feb 2015 12:08:04 -0000 Message-ID: <064501d04461$0f7644f0$2e62ced0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBEYO7VAR47rJCnTvK9sfBEXNy8Yw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21316.006 X-TM-AS-Result: No--15.962-10.0-31-10 X-imss-scan-details: No--15.962-10.0-31-10 X-TMASE-MatchedRID: /Rx38rPJfgvqFSjy6OERe31zro62qhdC7JU5VR9SYzebaqf1L9+tlPM+ 9Fw01I7Gcb75tXMR5DIsNm0J+q5LsNcUNjoF7YuVz4XVyhFFZHLs8rI+Arq54bV5fSMRD1zqBAd PriCD69+19T3v1Bw+JUhxaJhuh0LPRf0zRYpo0rhwUSK4/EeOxYiU4AhMsFDm40ErCTccNCgsgd kHScxUMSFs256C7TkbVfTW18GxnX5ZfetjAr6CxGgws6g0ewz2ZbPBlDYvqM3JyYU2J054Pbt6I p6ECVpCbYBtV6i2qU565rrWKXsbyBNj8dEIVpt0ngIgpj8eDcC063Wh9WVqgqbyPFGTn+O41GcR AJRT6POOhzOa6g8KrXNx3rsyoxLlWeTwXXdy3xWeZYS3l7plM23ZYi4aUS6Hg/vG+sAkpPg= Archived-At: Subject: [Roll] Heads-up: Last Call: (Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 09 Feb 2015 12:08:18 -0000 As usual, don't send your comments here, follow the instructions in the email. Adrian > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The > IESG > Sent: 06 February 2015 23:28 > To: IETF-Announce > Cc: 6tisch@ietf.org > Subject: Last Call: (Using IEEE802.15.4e TSCH in an > IoT context: Overview, Problem Statement and Goals) to Informational RFC > > > The IESG has received a request from the IPv6 over the TSCH mode of IEEE > 802.15.4e WG (6tisch) to consider the following document: > - 'Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem > Statement and Goals' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-02-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the environment, problem statement, and goals > for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. > The set of goals enumerated in this document form an initial set > only. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6tisch-tsch/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6tisch-tsch/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 9 09:20: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 956481A1B34; Mon, 9 Feb 2015 09:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 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, URIBL_DBL_ABUSE_REDIR=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 cRmyWKLN1wRv; Mon, 9 Feb 2015 09:00:09 -0800 (PST) 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 A7FAB1A0145; Mon, 9 Feb 2015 09:00:08 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id b6so8435930lbj.12; Mon, 09 Feb 2015 09:00:07 -0800 (PST) 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=WEjbL4l/SGgdY9moqD7x3KpPMPubQmXErpojm7Y8xBE=; b=zVpaCGgGc4I05G33AaFupUPy0/Dj9ZqN4CL9kQ6JUcW07y/14awam5aI32tECUSsFm ZP68/3loHqWeFJAHiCtZLykYn316JcBnpALRmYFv070osaYR83qy6/BluULu87WYI+Np 0U0VCokbcTBD1vUERJFYGYESFlLrVbyrguVWXeJXnP9v6vIUa4+wygDThwlFLjwVuauS mcv11xVqNSQqXQJ3KIfdUuilDVRBmAiR/y6m+WYrVEAimiL/cUZzyXics+yP5/GYlBQO rqleoqm5eJIZFle17i/1vnccZK5nT4DlZsy18ehfbgVu9RkZauif2jfZPB1Ym4OvQhIQ 2M1g== MIME-Version: 1.0 X-Received: by 10.152.27.136 with SMTP id t8mr18407854lag.60.1423501206883; Mon, 09 Feb 2015 09:00:06 -0800 (PST) Received: by 10.25.39.2 with HTTP; Mon, 9 Feb 2015 09:00:06 -0800 (PST) In-Reply-To: <7200.1421359216@sandelman.ca> References: <7200.1421359216@sandelman.ca> Date: Mon, 9 Feb 2015 19:00:06 +0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e0160bcfec61176050eaab3b4 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, 6man@ietf.org, Brian Haberman , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC 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, 09 Feb 2015 17:00:12 -0000 --089e0160bcfec61176050eaab3b4 Content-Type: text/plain; charset=UTF-8 Hello, This is a reminder of the ROLL Interim meeting tomorrow. Please find a draft of the slides here http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-1.pdf We will use JITSI for audio, video and slides, with the following URL: https://jitsi.tools.ietf.org/Roll20150210VirtualInterim Thank you very much, Michael and Ines. 2015-01-16 0:00 GMT+02:00 Michael Richardson : > > In accordance with: > https://www.ietf.org/iesg/statement/interim-meetings.html > the ROLL Working Group Chairs are announcing a virtual interim meeting for > February 10, 2015, from 15:00 UTC to 18:00 UTC. > (please see: http://goo.gl/NVefsy to convert the time) > > The very draft agenda is in development, and can be seen at: > > http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1 > > The goal of this interim meeting is to do a deep technical dive into the > different ways of optimizing the byte/power cost of the RFC6553 (RPI) and > RFC6554 (RH3) options. This could involve compression or recoding, or??? > We invite submissions on this. Please post your -00 draft by January 23 if > possible, or point us at your other drafts. > > We will use JITSI for audio, video and slides, with the following URL: > https://jitsi.tools.ietf.org/Roll20150210VirtualInterim > Participants are encouraged to visit this URL in advance to verify that > it works for them. If you need another participant to help verify, > please > email me. > > There will be a PSTN bridge for a backup, should things completely fail. > We will have a dial-in phone number connected to the bridge for those that > are unable to connect with a computer, but it won't be toll-free. > The phone numbers involved will be posted to the agenda as it is finalized, > and we expect to distribute slides by January 27, 2015. > > (BTW: we do not believe that ROLL will meet in Dallas/IETF92) > > > > -- > 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 > > --089e0160bcfec61176050eaab3b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

This is a reminder of the ROLL I= nterim meeting tomorrow.


We will use JITSI for audio, video and slides,= with the following URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.to= ols.ietf.org/Roll20150210VirtualInterim

Th= ank you very much,

Michael and Ines.

2015-01-16= 0:00 GMT+02:00 Michael Richardson <mcr+ietf@sandelman.ca>:

In accordance with: https://www.ietf.org/iesg/statement/interi= m-meetings.html
the ROLL Working Group Chairs are announcing a virtual interim meeting for<= br> February 10, 2015, from 15:00 UTC to 18:00 UTC.
=C2=A0 =C2=A0 =C2=A0 (please see: http://goo.gl/NVefsy to convert the time)

The very draft agenda is in development, and can be seen at:
=C2=A0 http://www.ietf.org/pro= ceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1

The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options.=C2=A0 This could involve compression or recoding, or= ???
We invite submissions on this.=C2=A0 Please post your -00 draft by January = 23 if
possible, or point us at your other drafts.

We will use JITSI for audio, video and slides, with the following URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.tools.ietf.org/Roll20150210Vir= tualInterim
=C2=A0 Participants are encouraged to visit this URL in advance to verify t= hat
=C2=A0 it works for them.=C2=A0 If you need another participant to help ver= ify, please
=C2=A0 email me.

There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that<= br> are unable to connect with a computer, but it won't be toll-free.
The phone numbers involved will be posted to the agenda as it is finalized,=
and we expect to distribute slides by January 27, 2015.

(BTW: we do not believe that ROLL will meet in Dallas/IETF92)



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


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


--089e0160bcfec61176050eaab3b4-- From nobody Mon Feb 9 21:48:25 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 2BE201A8BBD for ; Mon, 9 Feb 2015 21:48:24 -0800 (PST) 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 hX0oZzVlCoCb for ; Mon, 9 Feb 2015 21:48:21 -0800 (PST) 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 CCAFB1A011B for ; Mon, 9 Feb 2015 21:48:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B7719203AF for ; Tue, 10 Feb 2015 00:55:41 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 15BFC63A21; Tue, 10 Feb 2015 00:48:19 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E31BA637F4 for ; Tue, 10 Feb 2015 00:48:19 -0500 (EST) 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] updates to slides for 2015-02-10 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, 10 Feb 2015 05:48:24 -0000 --=-=-= Content-Type: text/plain If I did this right, I have just replaced the slides: roll-1-1.pdf with roll-1-3.pdf. This includes four diagrams, which I hope accurately represent the different proposals from a high-level architecture point of view. They should be at: http://www.ietf.org/proceedings/interim/2015/02/10/roll/proceedings.html Another copy is at: http://www.sandelman.ca/SSW/ietf/roll/ They should say, on the first page: 2015-02-10 slide set version 3 but it is also possible that Ines will edit some other things. Some of you have asked for dial-in number. If you would like to be called, I may be able to arrange that, please unicast me. -- 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) iQEVAwUBVNmbn4CLcPvd0N1lAQIZywf8DOBl6Z2mzE3s3s/Ju9JrM6fPkOiNtvRv eaEnHW1bFUxR/NuHzlf9VUsagDqjgy/9bVhAZst03v6hfgX+WfX/HCS5yw7O2cem egmaezlVLHxuu/w+DCsBBVQm2egHaiedK4NUr1hC3OPbGxJJyc3QZ9uB8i4Cp4sS /59uaOXE/bbYSL2HUhk7h1Wfxda4vrHlSUdjsd8npqmX9nLFfMBcTx2KwhD79nhC 8Xz+EYS1a7jzNNGrnUpZH/KDqCKDD/F0mV+6ZS5pOts4rA41Vc1iBwaP/AsVNGD1 7kCwioQ3mjCpilMdndJAzAql/0AzUkHFN2RiN4Z7o81g8q4qQBi6ng== =qQJY -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 9 21:54:09 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 366E51A011B for ; Mon, 9 Feb 2015 21:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZCDoOTrXh5Ea for ; Mon, 9 Feb 2015 21:54:04 -0800 (PST) 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 EE6F71A007C for ; Mon, 9 Feb 2015 21:54:03 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t1A5s2Ze002389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2015 14:54:02 +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 t1A5s1wE017139 for ; Tue, 10 Feb 2015 14:54:01 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 335 for ; Tue, 10 Feb 2015 14:54:01 +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 t1A5s0VY017101 for ; Tue, 10 Feb 2015 14:54:00 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t1A5s0Vs024412 for roll@ietf.org; Tue, 10 Feb 2015 14:54:00 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA24397; Tue, 10 Feb 2015 14:53:59 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t1A5rw56019360 for ; Tue, 10 Feb 2015 14:53:58 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id t1A5rw7j014159; Tue, 10 Feb 2015 14:53:58 +0900 (JST) Received: from [133.196.16.128] (ncg-dhcp128.isl.rdc.toshiba.co.jp [133.196.16.128]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id EEF9497D3B for ; Tue, 10 Feb 2015 14:53:57 +0900 (JST) Message-ID: <54D99CF5.9000206@toshiba.co.jp> Date: Tue, 10 Feb 2015 14:53:57 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <7521.1423547299@sandelman.ca> In-Reply-To: <7521.1423547299@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] updates to slides for 2015-02-10 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, 10 Feb 2015 05:54:06 -0000 Hi Michael, On 2015-02-10 14:48, Michael Richardson wrote: > but it is also possible that Ines will edit some other things. > Some of you have asked for dial-in number. If you would like to be called, > I may be able to arrange that, please unicast me. Is there any dial-in? My PC has bad audio I/O and Skype on iPad will be far better. I don't have Skype-in number so I cannot receive a call. If it's in U.S. I'm ok with a tolled number. Thanks! Yusuke From nobody Tue Feb 10 00:19: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 98FB51A007D; Tue, 10 Feb 2015 00:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 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, URIBL_DBL_ABUSE_REDIR=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 V3ucv0jB3dm9; Tue, 10 Feb 2015 00:19:21 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 458571A000F; Tue, 10 Feb 2015 00:19:21 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so1026413lbv.0; Tue, 10 Feb 2015 00:19:19 -0800 (PST) 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=ETm+wI0XpH2O6FzkyAgB0PqtmlF6T9fPVAFK8dR7en8=; b=05iJ3ry4YynHd1OOZrZ+KFQGZV9VDka+vwg2yYF6pv3VrmWbUWTlyN0oNHGDwfqVqH 3Saj4ZgatKMbbWprpiGGNsWySaa0KwJWZZ4jGSFQ08T/eE9U6UD0iurtl0rWcv/kzN1q O6QufLraSSyrW0pCHT/lMm3bqTbqIg+wqz9WIer3Nbs5n2K0nogcwV7WxaFwvPntxa3R vlljCD1SXKvUid7I/2achdj0GslAwDORg98Q9eebmJ/uE92sR64sjO5Lmow3kAcDdtC3 Os12K6VwUmjVrx/lPAcNq4O7Z9+ytrqXRxE/kUB/R7VIp+gADUL5MhBuCIkdPnh4Pw07 ur+w== MIME-Version: 1.0 X-Received: by 10.112.13.38 with SMTP id e6mr9437917lbc.31.1423556359477; Tue, 10 Feb 2015 00:19:19 -0800 (PST) Received: by 10.25.39.2 with HTTP; Tue, 10 Feb 2015 00:19:19 -0800 (PST) In-Reply-To: References: <7200.1421359216@sandelman.ca> Date: Tue, 10 Feb 2015 10:19:19 +0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a11c3f2141fe048050eb78bde Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, 6man@ietf.org, Brian Haberman , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC 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, 10 Feb 2015 08:19:23 -0000 --001a11c3f2141fe048050eb78bde Content-Type: text/plain; charset=UTF-8 Hello, Please find an updated slides at http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-3.pdf Thanks, 2015-02-09 19:00 GMT+02:00 Ines Robles : > Hello, > > This is a reminder of the ROLL Interim meeting tomorrow. > > Please find a draft of the slides here > http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-1.pdf > > > We will use JITSI for audio, video and slides, with the following URL: > https://jitsi.tools.ietf.org/Roll20150210VirtualInterim > > Thank you very much, > > Michael and Ines. > > > 2015-01-16 0:00 GMT+02:00 Michael Richardson : > >> >> In accordance with: >> https://www.ietf.org/iesg/statement/interim-meetings.html >> the ROLL Working Group Chairs are announcing a virtual interim meeting for >> February 10, 2015, from 15:00 UTC to 18:00 UTC. >> (please see: http://goo.gl/NVefsy to convert the time) >> >> The very draft agenda is in development, and can be seen at: >> >> http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1 >> >> The goal of this interim meeting is to do a deep technical dive into the >> different ways of optimizing the byte/power cost of the RFC6553 (RPI) and >> RFC6554 (RH3) options. This could involve compression or recoding, or??? >> We invite submissions on this. Please post your -00 draft by January 23 >> if >> possible, or point us at your other drafts. >> >> We will use JITSI for audio, video and slides, with the following URL: >> https://jitsi.tools.ietf.org/Roll20150210VirtualInterim >> Participants are encouraged to visit this URL in advance to verify that >> it works for them. If you need another participant to help verify, >> please >> email me. >> >> There will be a PSTN bridge for a backup, should things completely fail. >> We will have a dial-in phone number connected to the bridge for those that >> are unable to connect with a computer, but it won't be toll-free. >> The phone numbers involved will be posted to the agenda as it is >> finalized, >> and we expect to distribute slides by January 27, 2015. >> >> (BTW: we do not believe that ROLL will meet in Dallas/IETF92) >> >> >> >> -- >> 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 >> >> > --001a11c3f2141fe048050eb78bde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2015-02-09 19:00 GMT+02:00 Ines Robles <= span dir=3D"ltr"><mariainesrobles@googlemail.com>:
Hello,

This is a re= minder of the ROLL Interim meeting tomorrow.


<= /div>
We will use JITSI for audio, video and slides, with the following= URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.tools.ietf.org/Roll20= 150210VirtualInterim

Thank you very= much,

Michael and Ines.


2015-= 01-16 0:00 GMT+02:00 Michael Richardson <mcr+ietf@sandelman.ca>= :

In accordance with: https://www.ietf.org/iesg/statement/interi= m-meetings.html
the ROLL Working Group Chairs are announcing a virtual interim meeting for<= br> February 10, 2015, from 15:00 UTC to 18:00 UTC.
=C2=A0 =C2=A0 =C2=A0 (please see: http://goo.gl/NVefsy to convert the time)

The very draft agenda is in development, and can be seen at:
=C2=A0 http://www.ietf.org/pro= ceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1

The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options.=C2=A0 This could involve compression or recoding, or= ???
We invite submissions on this.=C2=A0 Please post your -00 draft by January = 23 if
possible, or point us at your other drafts.

We will use JITSI for audio, video and slides, with the following URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.tools.ietf.org/Roll20150210Vir= tualInterim
=C2=A0 Participants are encouraged to visit this URL in advance to verify t= hat
=C2=A0 it works for them.=C2=A0 If you need another participant to help ver= ify, please
=C2=A0 email me.

There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that<= br> are unable to connect with a computer, but it won't be toll-free.
The phone numbers involved will be posted to the agenda as it is finalized,=
and we expect to distribute slides by January 27, 2015.

(BTW: we do not believe that ROLL will meet in Dallas/IETF92)



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


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



--001a11c3f2141fe048050eb78bde-- From nobody Tue Feb 10 05:48: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 5CAF61A0271 for ; Tue, 10 Feb 2015 05:48:25 -0800 (PST) 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 AU6ZTWzxynEy for ; Tue, 10 Feb 2015 05:48:23 -0800 (PST) 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 63C351A011B for ; Tue, 10 Feb 2015 05:48:23 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DD1320098 for ; Tue, 10 Feb 2015 08:55:44 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BAED063A21; Tue, 10 Feb 2015 08:48:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8BE10637F4 for ; Tue, 10 Feb 2015 08:48:21 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <54D99CF5.9000206@toshiba.co.jp> References: <7521.1423547299@sandelman.ca> <54D99CF5.9000206@toshiba.co.jp> 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] updates to slides for 2015-02-10 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, 10 Feb 2015 13:48:25 -0000 Yusuke DOI wrote: > Is there any dial-in? My PC has bad audio I/O and Skype on iPad will be > far better. I don't have Skype-in number so I cannot receive a call. If > it's in U.S. I'm ok with a tolled number. If you can do Skype on iPad, then you can do JITSI on iPad. Try the URL. From nobody Tue Feb 10 06:17:38 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 703141A0162; Tue, 10 Feb 2015 06:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi-_Lead2IV0; Tue, 10 Feb 2015 06:17:30 -0800 (PST) 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 62D0A1A0066; Tue, 10 Feb 2015 06:17:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ECFB20098; Tue, 10 Feb 2015 09:24:52 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 50E1863A21; Tue, 10 Feb 2015 09:17:29 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 14CA1637F4; Tue, 10 Feb 2015 09:17:28 -0500 (EST) From: Michael Richardson To: Ines Robles In-Reply-To: References: <7200.1421359216@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: Cc: Brian Haberman , 6man@ietf.org, roll , "6lo@ietf.org WG" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC 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, 10 Feb 2015 14:17:35 -0000 Ines Robles wrote: > We will use JITSI for audio, video and slides, with the following URL: > https://jitsi.tools.ietf.org/Roll20150210VirtualInterim Although JITSI creates a shared etherpad, it's not clear what it actually is, so it's hard to tell others about it. So, let's explicitely use this for note taking: http://etherpad.tools.ietf.org:9000/p/Roll20150210VirtualInterim?useMonospaceFont=true If JITSI should fail, instructions on connecting to a backup will be placed there. From nobody Tue Feb 10 06:49: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 809321A8848 for ; Tue, 10 Feb 2015 06:49:32 -0800 (PST) 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 YEBnJ5tgNsoV for ; Tue, 10 Feb 2015 06:49:30 -0800 (PST) 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 5AF351A889B for ; Tue, 10 Feb 2015 06:49:02 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t1AEn0Bk011704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2015 23:49:00 +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 t1AEn0I9008009 for ; Tue, 10 Feb 2015 23:49:00 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 308 for ; Tue, 10 Feb 2015 23:49:00 +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 t1AEn0XM008000 for ; Tue, 10 Feb 2015 23:49:00 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t1AEn0Nl025272 for roll@ietf.org; Tue, 10 Feb 2015 23:49:00 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA25271; Tue, 10 Feb 2015 23:49:00 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t1AEn0FV004543 for ; Tue, 10 Feb 2015 23:49:00 +0900 (JST) Received: from snazzy.isl.rdc.toshiba.co.jp by toshiba.co.jp id t1AEmx7P010373; Tue, 10 Feb 2015 23:49:00 +0900 (JST) Received: from maltesein.wide.toshiba.co.jp (unknown [202.249.10.100]) by snazzy.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id 7F7C150082; Tue, 10 Feb 2015 23:48:59 +0900 (JST) Received: from malteseout.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by maltesein.wide.toshiba.co.jp (8.13.8/8.9.1) with ESMTP id t1AEmxJg016494; Tue, 10 Feb 2015 23:48:59 +0900 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by malteseout.wide.toshiba.co.jp (8.13.8/8.9.1) with ESMTP id t1AEmxx4010649; Tue, 10 Feb 2015 23:48:59 +0900 Received: from localhost (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 46D8627CD1; Tue, 10 Feb 2015 23:48:59 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp ([127.0.0.1]) by localhost (tsbgw.wide.toshiba.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2PdLAQNpFIC; Tue, 10 Feb 2015 23:48:59 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id F157027CCF; Tue, 10 Feb 2015 23:48:58 +0900 (JST) Date: Tue, 10 Feb 2015 23:48:58 +0900 (JST) Message-Id: <20150210.234858.1898388363586176725.ydoi@tsbgw.wide.toshiba.co.jp> To: roll@ietf.org, mcr@sandelman.ca From: yusuke.doi@toshiba.co.jp In-Reply-To: <8053.1423576101@sandelman.ca> References: <7521.1423547299@sandelman.ca> <54D99CF5.9000206@toshiba.co.jp> <8053.1423576101@sandelman.ca> X-Mailer: Mew version 6.4 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] updates to slides for 2015-02-10 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, 10 Feb 2015 14:49:33 -0000 Ah, that's my fault not tried it first. Thanks! Yusuke From: Michael Richardson Subject: Re: [Roll] updates to slides for 2015-02-10 Date: Tue, 10 Feb 2015 08:48:21 -0500 > > Yusuke DOI wrote: > > Is there any dial-in? My PC has bad audio I/O and Skype on iPad will be > > far better. I don't have Skype-in number so I cannot receive a call. If > > it's in U.S. I'm ok with a tolled number. > > If you can do Skype on iPad, then you can do JITSI on iPad. > Try the URL. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Feb 10 17:41:56 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 1CAC71A1A20; Tue, 10 Feb 2015 17:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 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, URIBL_DBL_ABUSE_REDIR=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 0iFpaBDHoSgZ; Tue, 10 Feb 2015 17:41:45 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 9F4601A1ADB; Tue, 10 Feb 2015 17:41:44 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id w7so509060lbi.9; Tue, 10 Feb 2015 17:41:43 -0800 (PST) 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=kVUMmqh/WOdqJ1UCI8onp9kx6GT2oIswjzvMKH4BvvU=; b=Xwzs+kJodTm5NjhJNMHoXVHEWl/CnczZNUHDNfwmxpUENRe02ViTHSXhWYykdYR8nA YkySxJJteG5r3jI7z+uO2KROcImMzidI5pC5P9yCYTt0j73TcnzXNFD6PTvl+4CfO1Vf IG2gMbm5D1vgmHs4NpCJnT1c4kAkLOFqw5QekkSTXvnn7sKW2EM/2PA2U+gRmc630APG BQBaqcaRUFFQQjzgla6uRg1j96ULOIkMHjH5jKR6J4lXzxvBkvC00yIcsLekHlBqICoS h6suz1Sif6z9lrR1fFf9bv1P3cyHxOpA/FesgePLGT71jenIIGKnnXwYzIq0ttFcgzMZ r2FA== MIME-Version: 1.0 X-Received: by 10.152.6.101 with SMTP id z5mr26012633laz.19.1423618903092; Tue, 10 Feb 2015 17:41:43 -0800 (PST) Received: by 10.25.39.2 with HTTP; Tue, 10 Feb 2015 17:41:43 -0800 (PST) In-Reply-To: References: <7200.1421359216@sandelman.ca> Date: Wed, 11 Feb 2015 03:41:43 +0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e0149433203b64f050ec61b50 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, 6man@ietf.org, Brian Haberman , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC 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, 11 Feb 2015 01:41:47 -0000 --089e0149433203b64f050ec61b50 Content-Type: text/plain; charset=UTF-8 Hello, Many thanks to Ralph for being the presenter and all the participants. Please find a draft of the minutes here: http://www.ietf.org/proceedings/interim/2015/02/10/roll/minutes/minutes-interim-2015-roll-1 Note that it could be updated in the following days. Cheers, Michael and Ines. 2015-02-10 10:19 GMT+02:00 Ines Robles : > Hello, > > Please find an updated slides at > http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-3.pdf > > Thanks, > > 2015-02-09 19:00 GMT+02:00 Ines Robles : > >> Hello, >> >> This is a reminder of the ROLL Interim meeting tomorrow. >> >> Please find a draft of the slides here >> http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-1.pdf >> >> >> We will use JITSI for audio, video and slides, with the following URL: >> https://jitsi.tools.ietf.org/Roll20150210VirtualInterim >> >> Thank you very much, >> >> Michael and Ines. >> >> >> 2015-01-16 0:00 GMT+02:00 Michael Richardson : >> >>> >>> In accordance with: >>> https://www.ietf.org/iesg/statement/interim-meetings.html >>> the ROLL Working Group Chairs are announcing a virtual interim meeting >>> for >>> February 10, 2015, from 15:00 UTC to 18:00 UTC. >>> (please see: http://goo.gl/NVefsy to convert the time) >>> >>> The very draft agenda is in development, and can be seen at: >>> >>> http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1 >>> >>> The goal of this interim meeting is to do a deep technical dive into the >>> different ways of optimizing the byte/power cost of the RFC6553 (RPI) and >>> RFC6554 (RH3) options. This could involve compression or recoding, or??? >>> We invite submissions on this. Please post your -00 draft by January 23 >>> if >>> possible, or point us at your other drafts. >>> >>> We will use JITSI for audio, video and slides, with the following URL: >>> https://jitsi.tools.ietf.org/Roll20150210VirtualInterim >>> Participants are encouraged to visit this URL in advance to verify that >>> it works for them. If you need another participant to help verify, >>> please >>> email me. >>> >>> There will be a PSTN bridge for a backup, should things completely fail. >>> We will have a dial-in phone number connected to the bridge for those >>> that >>> are unable to connect with a computer, but it won't be toll-free. >>> The phone numbers involved will be posted to the agenda as it is >>> finalized, >>> and we expect to distribute slides by January 27, 2015. >>> >>> (BTW: we do not believe that ROLL will meet in Dallas/IETF92) >>> >>> >>> >>> -- >>> 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 >>> >>> >> > --089e0149433203b64f050ec61b50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Many thanks to Ralph for being t= he presenter and all the participants.


Note that it could be updated in the follo= wing days.

Cheers,

Michae= l and Ines.

2015-02-10 10:19 GMT+02:00 Ines Robles <mariainesroble= s@googlemail.com>:
Hello,

Please find an updated slides at=C2=A0http://www.ietf.org/procee= dings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-3.pdf

Thanks,

2015-02-0= 9 19:00 GMT+02:00 Ines Robles <mariainesrobles@googlemail.co= m>:
Hello,=

This is a reminder of the ROLL Interim meeting tomorrow= .

Please find a draft of the slides here http://www.ietf.org/proceedings= /interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-1.pdf=C2=A0<= /div>

We will use JITSI for audio, video and slide= s, with the following URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.= tools.ietf.org/Roll20150210VirtualInterim

Thank you very much,

Michael and Ines.


<= span>2015-01-16 0:00 GMT+02:00 Michael Richardson <mcr+ietf@sandelman.= ca>:

In accordance with: https://www.ietf.org/iesg/statement/interi= m-meetings.html
the ROLL Working Group Chairs are announcing a virtual interim meeting for<= br> February 10, 2015, from 15:00 UTC to 18:00 UTC.
=C2=A0 =C2=A0 =C2=A0 (please see: http://goo.gl/NVefsy to convert the time)

The very draft agenda is in development, and can be seen at:
=C2=A0 http://www.ietf.org/pro= ceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1

The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options.=C2=A0 This could involve compression or recoding, or= ???
We invite submissions on this.=C2=A0 Please post your -00 draft by January = 23 if
possible, or point us at your other drafts.

We will use JITSI for audio, video and slides, with the following URL:
=C2=A0 =C2=A0 =C2=A0https://jitsi.tools.ietf.org/Roll20150210Vir= tualInterim
=C2=A0 Participants are encouraged to visit this URL in advance to verify t= hat
=C2=A0 it works for them.=C2=A0 If you need another participant to help ver= ify, please
=C2=A0 email me.

There will be a PSTN bridge for a backup, should things completely fail. We will have a dial-in phone number connected to the bridge for those that<= br> are unable to connect with a computer, but it won't be toll-free.
The phone numbers involved will be posted to the agenda as it is finalized,=
and we expect to distribute slides by January 27, 2015.

(BTW: we do not believe that ROLL will meet in Dallas/IETF92)



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


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




--089e0149433203b64f050ec61b50-- From nobody Thu Feb 12 04:34:54 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 230311A870D; Thu, 12 Feb 2015 04:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASrfNamdcr1v; Thu, 12 Feb 2015 04:34:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B04451A87C5; Thu, 12 Feb 2015 04:34:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ines Robles" To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212123432.18138.31833.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 04:34:32 -0800 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, iesg-secretary@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, roll-chairs@tools.ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: [Roll] Publication has been requested for draft-ietf-roll-applicability-home-building-07 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: Thu, 12 Feb 2015 12:34:53 -0000 Ines Robles has requested publication of draft-ietf-roll-applicability-home-building-07 as Informational on behalf of the ROLL working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Thu Feb 12 15:38: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 587661A1A1E; Thu, 12 Feb 2015 15:37:58 -0800 (PST) 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 lZ6KRDMKccq7; Thu, 12 Feb 2015 15:37:56 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54D31A00D8; Thu, 12 Feb 2015 15:37:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B198A1C059F; Thu, 12 Feb 2015 15:37:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A81261C0497; Thu, 12 Feb 2015 15:37:55 -0800 (PST) Message-ID: <54DD3945.1070000@joelhalpern.com> Date: Thu, 12 Feb 2015 18:37:41 -0500 From: Joel Halpern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: gen-art@ietf.org, maria.ines.robles@ericsson.com, IETF discussion list References: <548A29DC.6080303@nostrum.com> <548F67D8.9080402@joelhalpern.com> In-Reply-To: <548F67D8.9080402@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [Gen-art] review: draft-ietf-roll-admin-local-policy-03 (was -02) 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, 12 Feb 2015 23:37:58 -0000 This is a re-review of -03 of this document. While I find it slightly odd, upon consideration I believe the statement that turning this protocol on is the administrative control required by the definition of admin-local scope is sufficient, and thus addresses my original concern. If for some reason this needs to be revised further, I would like to see an explicit statement that this behavior (scope-4 announcing and forwarding) MUST by default be turned. That would seem aligned with the declaration that turning this behavior on is the administrative action. Otherwise, this document is now ready for publication as an Informational RFC. Document: draft-ietf-roll-admin-local-policy-03 MPL forwarder policy for multicast with admin-local scope Reviewer: Joel M. Halpern Review Date: 12-Feb-2015 IETF LC End Date: done IESG Telechat date: 19-Feb-2015 Yours, Joel M. Halpern From nobody Tue Feb 17 00:15:38 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 12C491A8728 for ; Tue, 17 Feb 2015 00:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, 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 hvY5UXU3txtl for ; Tue, 17 Feb 2015 00:15:35 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 EF0761A037D for ; Tue, 17 Feb 2015 00:15:34 -0800 (PST) Received: by lbiz11 with SMTP id z11so3040452lbi.8 for ; Tue, 17 Feb 2015 00:15:33 -0800 (PST) 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=Dhax0le31fXMHSDjdlHHILh6B6PHFtOufSv2L9nWzZ8=; b=BhqAvXAbAx5QY9bbyEZZqTsxOZ4zPN7YdKcHM4asblttd2ShIE6YcaYfTyXRQtQYCS jCAGZCKxrkRqQkLuL5j0zQgd+f4aBnis4300dfAAYF+zAiYONQm9fvuGdtEBpnoWsNpQ mt1HrdnojH7l2GuuXYgx/tWFsJjUh8NhcgfKoZm2AvbGDtIn0PmWbHClpCOXwWZz2GQw GmAxQsDV2zSxkvpvkPm4JwxnlcDVJYNdg/VqQHvm6lnvYY918YIVVGrQF0jw6ccIOJ9J E+qbbtu1/tEls5wwHq/l+j/VLZwsUo0ZCc/WEkrfFRS/k6F/tmgRzWf6RdgwHKhELeQl qftA== MIME-Version: 1.0 X-Received: by 10.112.199.39 with SMTP id jh7mr27150654lbc.46.1424160933314; Tue, 17 Feb 2015 00:15:33 -0800 (PST) Received: by 10.25.39.2 with HTTP; Tue, 17 Feb 2015 00:15:33 -0800 (PST) Date: Tue, 17 Feb 2015 10:15:33 +0200 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c32cf0888633050f444ed9 Archived-At: Cc: Michael Richardson Subject: [Roll] WGLC for draft-ietf-roll-applicability-ami 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, 17 Feb 2015 08:15:37 -0000 --001a11c32cf0888633050f444ed9 Content-Type: text/plain; charset=UTF-8 Dear all, A Working Group Last call (WGLC) starts today (02/17) until 03/03/2015 for draft-ietf-roll-applicability-ami The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ http://tools.ietf.org/html/draft-ietf-roll-applicability-ami-10 Please review this draft to see if you think it is ready for publication and send comments to the list stating your view. Thank you very much in advance, Michael and Ines. 2015-01-31 1:52 GMT+02:00 Michael Richardson : > > internet-drafts@ietf.org wrote: > > Title : Applicability Statement for the Routing Protocol > for > > Low Power and Lossy Networks (RPL) in AMI Networks > > Thanks to Nancy for agreeing to revise this document. > > I would ask all WG participants to read it anew, and to review the open > tickets on it, and see if we are making progress towards getting this into > WGLC. > > Ines & Michael > > -- > 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 > > --001a11c32cf0888633050f444ed9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

A Working Group La= st call (WGLC) starts today (02/17) until 03/03/2015 for draft-ietf-roll-ap= plicability-ami

The draft is available here:=C2=A0=

Please review this draft to see i= f you think it is ready for publication and send comments to the list stati= ng your view.

Thank you very much in advance,

Michael and Ines.

=
2015-01-31 1:52 GMT+02:00 Michael Richardson <mcr+ietf@sandelman.ca>:
=
internet-drafts@ietf.org wr= ote:
=C2=A0 =C2=A0 > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Applicab= ility Statement for the Routing Protocol for
=C2=A0 =C2=A0 > Low Power and Lossy Networks (RPL) in AMI Networks

Thanks to Nancy for agreeing to revise this document.

I would ask all WG participants to read it anew, and to review the open
tickets on it, and see if we are making progress towards getting this into<= br> WGLC.

Ines & Michael

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


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


--001a11c32cf0888633050f444ed9-- From nobody Wed Feb 18 20:51:38 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 11C581A8778; Wed, 18 Feb 2015 20:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30ZHy5lewNM5; Wed, 18 Feb 2015 20:51:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A21A86F6; Wed, 18 Feb 2015 20:51:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219045129.7667.64711.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 20:51:29 -0800 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@ietf.org Subject: [Roll] Spencer Dawkins' No Objection on draft-ietf-roll-admin-local-policy-03: (with COMMENT) 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: Thu, 19 Feb 2015 04:51:31 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-roll-admin-local-policy-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question: In this text: 4.1. Legal multicast messages Multicast messages can be created within the node by an application or can arrive at an interface. A multicast message created at a source (MPL seed) is legal when it conforms to the properties described in section 9.1 of [I-D.ietf-roll-trickle-mcast]. A multicast message received at a given interface is legal when: o The message carries an MPL option (MPL message) and the incoming MPL interface is subscribed to the destination multicast address. o The message does not carry an MPL option, the multicast address is unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the interface has expressed interest to receive messages with the specified multicast address via MLD [RFC3810] or via IGMP [RFC3376]. The message was sent on according to PIM-DM [RFC3973] or according to PIM-SM [RFC4601]. Illegal multicast messages are discarded. 4.2. Forwarding legal packets A legal multicast message received at a given interface is assigned the network identifier of the interface of the incoming link . A message that is created within the node is assigned the network identifier "any". Two types of legal multicast messages are considered: (1) MPL messages, and (2) multicast messages which do not carry the MPL option. Is "legal/illegal" the right terminology for this? From nobody Wed Feb 18 20:51:41 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3CF851A877D; Wed, 18 Feb 2015 20:51:31 -0800 (PST) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C581A8778; Wed, 18 Feb 2015 20:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30ZHy5lewNM5; Wed, 18 Feb 2015 20:51:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A21A86F6; Wed, 18 Feb 2015 20:51:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219045129.7667.64711.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 20:51:29 -0800 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@ietf.org Subject: [Roll] Spencer Dawkins' No Objection on draft-ietf-roll-admin-local-policy-03: (with COMMENT) 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: Thu, 19 Feb 2015 04:51:31 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-roll-admin-local-policy-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question: In this text: 4.1. Legal multicast messages Multicast messages can be created within the node by an application or can arrive at an interface. A multicast message created at a source (MPL seed) is legal when it conforms to the properties described in section 9.1 of [I-D.ietf-roll-trickle-mcast]. A multicast message received at a given interface is legal when: o The message carries an MPL option (MPL message) and the incoming MPL interface is subscribed to the destination multicast address. o The message does not carry an MPL option, the multicast address is unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the interface has expressed interest to receive messages with the specified multicast address via MLD [RFC3810] or via IGMP [RFC3376]. The message was sent on according to PIM-DM [RFC3973] or according to PIM-SM [RFC4601]. Illegal multicast messages are discarded. 4.2. Forwarding legal packets A legal multicast message received at a given interface is assigned the network identifier of the interface of the incoming link . A message that is created within the node is assigned the network identifier "any". Two types of legal multicast messages are considered: (1) MPL messages, and (2) multicast messages which do not carry the MPL option. Is "legal/illegal" the right terminology for this? From nobody Thu Feb 19 00:18: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 DD45C1A88DB for ; Thu, 19 Feb 2015 00:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuoJ9u5JtuOi for ; Thu, 19 Feb 2015 00:18:24 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723031A88BF for ; Thu, 19 Feb 2015 00:18:24 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud6.xs4all.net with ESMTP id u8JN1p0084NtgTm018JNnr; Thu, 19 Feb 2015 09:18:22 +0100 Received: from AMontpellier-654-1-246-246.w92-133.abo.wanadoo.fr ([92.133.17.246]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 19 Feb 2015 09:18:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 19 Feb 2015 09:18:22 +0100 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: <20150219045129.7667.64711.idtracker@ietfa.amsl.com> References: <20150219045129.7667.64711.idtracker@ietfa.amsl.com> Message-ID: <41de52458882d6879002aec790ee20cc@xs4all.nl> X-Sender: stokcons@xs4all.nl (lm03SPz63X97L6R2cnvzD/2VYmcVlRcW) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] Spencer Dawkins' No Objection on draft-ietf-roll-admin-local-policy-03: (with COMMENT) 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, 19 Feb 2015 08:18:27 -0000 Hi Spencer, Actually I don't know whether it is the right terminology here. It is used in algorithm proving texts, that I was used to. The terms seem clear, and I will keep them for the moment, thanks, Peter Spencer Dawkins schreef op 2015-02-19 05:51: > Spencer Dawkins has entered the following ballot position for > draft-ietf-roll-admin-local-policy-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > One question: In this text: > > 4.1. Legal multicast messages > > Multicast messages can be created within the node by an application > or can arrive at an interface. > > A multicast message created at a source (MPL seed) is legal when it > conforms to the properties described in section 9.1 of > [I-D.ietf-roll-trickle-mcast]. > > A multicast message received at a given interface is legal when: > > o The message carries an MPL option (MPL message) and the incoming > MPL interface is subscribed to the destination multicast address. > > o The message does not carry an MPL option, the multicast address > is > unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the > interface has expressed interest to receive messages with the > specified multicast address via MLD [RFC3810] or via IGMP > [RFC3376]. The message was sent on according to PIM-DM [RFC3973] > or according to PIM-SM [RFC4601]. > > Illegal multicast messages are discarded. > > 4.2. Forwarding legal packets > > A legal multicast message received at a given interface is assigned > the network identifier of the interface of the incoming link . A > message that is created within the node is assigned the network > identifier "any". > > Two types of legal multicast messages are considered: (1) MPL > messages, and (2) multicast messages which do not carry the MPL > option. > > Is "legal/illegal" the right terminology for this? > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Feb 19 11:37: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 4E2D01A877F; Thu, 19 Feb 2015 11:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2cdxdy9NfZz; Thu, 19 Feb 2015 11:37:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515B1A8795; Thu, 19 Feb 2015 11:37:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193727.31662.30759.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:37:27 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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: Thu, 19 Feb 2015 19:37:44 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Thu Feb 19 11:37:47 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6CB5C1A87DE; Thu, 19 Feb 2015 11:37:44 -0800 (PST) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2D01A877F; Thu, 19 Feb 2015 11:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2cdxdy9NfZz; Thu, 19 Feb 2015 11:37:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515B1A8795; Thu, 19 Feb 2015 11:37:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193727.31662.30759.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:37:27 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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: Thu, 19 Feb 2015 19:37:44 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Sat Feb 21 06:24:40 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 5F61F1A6FFF; Sat, 21 Feb 2015 06:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y92y-XYByUp; Sat, 21 Feb 2015 06:24:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 926251A6FF6; Sat, 21 Feb 2015 06:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t1LEOVoS024412; Sat, 21 Feb 2015 15:24:31 +0100 (CET) Received: from alma.local (p5DC7E14D.dip0.t-ipconnect.de [93.199.225.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kqBk716hrz2QKk; Sat, 21 Feb 2015 15:24:31 +0100 (CET) Message-ID: <54E89536.7000007@tzi.org> Date: Sat, 21 Feb 2015 15:24:54 +0100 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "6tisch@ietf.org" <6tisch@ietf.org>, roll@ietf.org, lwip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Roll] Fwd: Constrained Node/Network Cluster @ IETF92, early draft 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: Sat, 21 Feb 2015 14:24:36 -0000 Sorry for the separate message, but there are too many WGs in this cluster now for a single cross posting... > *From:* Carsten Bormann > *Date:* 21 Feb 2015 15:21 > *To:* dtls-iot@ietf.org, core , ace@ietf.org, > "6lo@ietf.org WG" <6lo@ietf.org>, t2trg@irtf.org > *Subject:* [6lo] Constrained Node/Network Cluster @ IETF92, early > draft version > A first draft version of the IETF92 agenda is out. > ** THIS IS GOING TO CHANGE ** for conflict resolution, > so please don't make travel arrangements based on it. > > Here is my usual eclectic condensed agenda built from that. > There are no ROLL or DICE meetings in the agenda this time. > Again, the Constrained Node/Network group meetings are nicely spread > out over the week, with a peak on Wednesday. > I also put in the weekend meeting of the proposed Thing-to-thing > Research Group ; I hope to have details for this on Monday. > > All times are CDT (UTC-0500) (use > https://datatracker.ietf.org/meeting/agenda-utc and press the button > to get your local time in case you want to listen in from remote). > > Grüße, Carsten > > SATURDAY, March 21, 2015 > > 1300-1800 Session I > (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group > > SUNDAY, March 22, 2015 > > 0900-1500 Session II > (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group > > MONDAY, March 23, 2015 > > 0900-1130 Morning Session I > Venetian APP appsawg Applications Area Working Group WG - > Combined with APPSAREA > International INT 6man IPv6 Maintenance WG > > 1300-1500 Afternoon Session I > International INT dnssd Extensions for Scalable DNS Service > Discovery WG > Parisian TSV taps Transport Services WG > > 1520-1650 Afternoon Session II > Parisian APP uta Using TLS in Applications WG > Continental INT *** 6tisch IPv6 over the TSCH mode of IEEE > 802.15.4e WG > Far East RAI webpush Web-Based Push Notifications WG > Gold TSV tsvarea Transport Area Open Meeting > > TUESDAY, March 24, 2015 > > 0900-1130 Morning Session I > International INT homenet Home Networking WG > Parisian SEC tokbind Token Binding WG > > 1300-1500 Afternoon Session I > Oak APP httpbis Hypertext Transfer Protocol WG > Parisian SEC *** ace Authentication and Authorization for > Constrained Environments WG > > 1520-1720 Afternoon Session II > International INT *** 6lo IPv6 over Networks of > Resource-constrained Nodes WG > Oak OPS anima Autonomic Networking Integrated Model and > Approach WG > Parisian TSV tsvwg Transport Area Working Group WG > > 1730-1830 Afternoon Session III > Royal SEC jose Javascript Object Signing and Encryption WG > > WEDNESDAY, March 25, 2015 > > 0900-1130 Morning Session I > International TSV spud Session Protocol for User Datagrams BOF > > 1300-1500 Afternoon Session I > International OPS v6ops IPv6 Operations WG > Venetian RTG bier Bit Indexed Explicit Replication WG > Royal SEC oauth Web Authorization Protocol WG > > 1520-1620 Afternoon Session II > Oak INT *** lwig Light-Weight Implementation Guidance WG > Venetian SEC acme Automated Certificate Management > Environment BOF > > THURSDAY, March 26, 2015 > > 0900-1130 Morning Session I > Continental INT *** 6tisch IPv6 over the TSCH mode of IEEE > 802.15.4e WG > Gold OPS v6ops IPv6 Operations WG > Oak SEC tls Transport Layer Security WG > Venetian TSV rmcat RTP Media Congestion Avoidance Techniques WG > > 1300-1500 Afternoon Session I > International SEC saag Security Area Open Meeting > Parisian TSV tsvwg Transport Area Working Group WG > > 1520-1720 Afternoon Session II > Oak APP *** core Constrained RESTful Environments WG > Gold RTG rtgarea Routing Area Open Meeting > Parisian TSV tcpinc TCP Increased Security WG > > 1740-1840 Afternoon Session III > Venetian INT intarea Internet Area Working Group WG > Continental SEC httpauth Hypertext Transfer Protocol > Authentication WG > > FRIDAY, March 27, 2015 > > 0900-1130 Morning Session I > Far East APP *** core Constrained RESTful Environments WG > > 1150-1320 Afternoon Session I > Parisian OPS anima Autonomic Networking Integrated Model and > Approach WG > Venetian TSV tsvarea Transport Area Open Meeting From nobody Mon Feb 23 13:46:55 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 A1F121A6F2A; Mon, 23 Feb 2015 13:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlyfC58IujaW; Mon, 23 Feb 2015 13:46:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB01A6F3A; Mon, 23 Feb 2015 13:46:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223214649.11949.60839.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 13:46:49 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: 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, 23 Feb 2015 21:46:53 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/