From adrian@olddog.co.uk Sat Jun 11 14:37:56 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F4711E80AF for ; Sat, 11 Jun 2011 14:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+NjLVsq4ee1 for ; Sat, 11 Jun 2011 14:37:55 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0E311E80B6 for ; Sat, 11 Jun 2011 14:37:54 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5BLbgEP025861; Sat, 11 Jun 2011 22:37:42 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5BLbe6m025852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 22:37:41 +0100 From: "Adrian Farrel" To: Date: Sat, 11 Jun 2011 22:37:44 +0100 Message-ID: <0bd201cc287f$cd278a60$67769f20$@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: Acwof6imW3R71k0UTtWgnG7jsTjMYg== Content-Language: en-gb Cc: roll@ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] AD review of draft-ietf-roll-of0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 21:37:56 -0000 Hi, Don't panic! I have done my usual AD review of your draft to ensure that it has a smooth passage through IETF last call and IESG review. The good news is that I don't have any technical issues with your I-D, but I am afraid I have a very large number of suggested editorial nits to make the document read more clearly. This clarity is important both to allow successful implementation and interoperability, and to ensure that the reviewers can quickly reach the correct understanding. I think that a new version of the I-D is needed before I can issue the IETF last call. However, since the changes are purely editorial (and, for the avoidance of doubt, these are the only changes you should make at this stage) we will be able to go ahead quickly as soon as the new revision is posted. Thanks, Adrian --- Could you please capitalise all section headers. --- Abstract OLD of a specific Objective Function NEW of specific Objective Functions. END --- Abstract I would like the Abstract to say what an objective function is used for. How about adding a second sentence... An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. --- Introduction (line 1) OLD The Routing Protocol for Low Power and Lossy Networks NEW The Routing Protocol for Low Power and Lossy Networks (RPL) END --- Introduction The Abstract says it better than paragraph 1, here. The word "problem" is quite ambiguous. Can you... s/problem/deployment and application is a specific design of network" --- Introduction Can you add the same sentence as added to the Abstract as sentence 2 in para 1. --- Introduction para 1 s/RPL to adapt/RPL to be adapted/ --- Introduction para 2 s/in a new Version/as a new DODAG Version/ --- Introduction para 3 OLD An Objective Function selects the DODAG Version that a device joins within an instance, and a number of neighbor routers within that DODAG Version as parents or feasible successors. The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG. In turn, the Rank is used by the generic RPL core to avoid loops and verify forward progression towards a destination, as specified in [I-D.ietf-roll-rpl]. NEW An instance of RPL running on a device uses an Objective Function to help it determine which DODAG Version it should join. The OF is also used by the RPL instance to select a number of routers within the DODAG Version to serve as parents or as feasible successors. The RPL instance uses the OF to compute a Rank for the device. This value represents an abstract distance to the root of the DODAG within the DODAG Version. The Rank is exchanged between nodes using RPL and allows other RPL nodes to avoid loops and verify forward progression toward the destination, as specified in [I-D.ietf-roll-rpl]. END --- Introduction s/( excellent)/(excellent)/ --- Introduction As a result, OF0 with default settings allows to encode a minimum of 28 (worst acceptable) hops and a maximum of 255 (excellent) hops. This is true (and 9*29 > 255), but is more than a little opaque! How about: Because RPL allows a leaf-to-root path in a DODAG to have a distance of any value up to 255, OF0 with default settings allows to encode a minimum of 28 (worst acceptable) hops and a maximum of 255 (excellent) hops. --- Introduction OLD Since there is no default OF or metric container in the RPL main specification, it might happen that, unless two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate. NEW It is important that devices deployed in a particular network or environment use the same OF to build and operate DODAGs. If they do not, it is likely that sub-optimal paths will be selected, and it is possible that parts of the network will become disconnected (perhaps because devices select paths that would cause loops to be formed). In practice, without a common definition of an OF, RPL implementations cannot guarantee to interoperate correctly. The RPL specification [I-D.ietf-roll-rpl] does not include any OF definitions. This is left for other documents specific to different deployments and application environments. END --- Section 2 s/The term feasible successor/The term 'feasible successor'/ --- Section 3 OLD For the purpose of OF0, Grounded thus means that the root provides such connectivity. NEW Thus, for the purpose of OF0, the term Grounded [I-D.ietf-roll-rpl] means that the DODAG root provides such connectivity. END --- Section 3 OLD This can be achieved if the Rank of a node represents closely its distance to the root. NEW This can be achieved if the Rank of a node is very close to an abstract function of its distance to the root. END --- The terms LLN and DAG are used without expansion. --- Section 3 OF0 assigns a rank_increase to each link to another node that it monitors. I think it is the link that is monitored not the node. Furthermore, OF0 doesn't monitor anything. So... A RPL node monitors links to neighbor nodes, and can use OF0 to assign a rank_increase to each link. --- Section 4.1 A couple of terms are introduced as being computed and implying something, but the use of the terms is not explained. For example, at the head of 4.1, step_of_rank is defined as something that is computed, but we don't find out what it is for until the end of the section (where it turns out just to be a multiplier used to help determine the increase in rank to apply). I suggest OLD An OF0 implementation first computes a step_of_rank associated with a given parent from relevant link properties and metrics. NEW An OF0 implementation first computes a step_of_rank associated with a given parent from relevant link properties and metrics. The step_of_rank is used to compute the amount by which to increase the rank along a particular link, as explained later in this section. END --- Section 4.1 s/recommended to base/RECOMMENDED to base/ --- Section 4.1 s/less but longer/fewer but longer/ --- Section 4.1 I think that draft-ietf-roll-routing-metrics would be a better reference than [DeCouto03] for ETX. --- Section 4.1 An implementation MAY allow to stretch the step_of_rank with a stretch_of_rank up to no more than MAXIMUM_RANK_STRETCH in order to enable the selection of at least one feasible successor and thus maintain path diversity. Not sure what this means! Possibly... An implementation MAY stretch the step_of_rank in order to enable the selection of at least one feasible successor and thus maintain path diversity. It uses a stretch_of_rank to do this and may set it to any value between 0 (no stretch) and the fixed constant MAXIMUM_RANK_STRETCH (see Section 6.3). --- Section 4.1 s/not recommended/NOT RECOMMENDED/ But I don't like the order of progression in the paragraph! First you say that an implementation may do something. Then you say it should not. Can you reorder the paragraph. Also put it into the positive, not the negative... The implementation SHOULD do something (or is RECOMMENDED to do that thing). Although it has bad side effects, an implementation MAY do something else. --- Section 4.1 OLD MUST maintain the stretched step_of_rank between MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK NEW MUST maintain the stretched step_of_rank between the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK (see Section 6.3). END --- Section 4.1 An implementation SHOULD allow a configurable factor called rank_factor and to apply the factor on all links and peers. You need to say how this is applied! --- Section 4.1 The rank_factor SHOULD be set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. Surely this is s/SHOULD/MUST/ Please say "between the fixed constants... ... (see Section 6.3)." --- Section 4.1 The rank_increase is expressed in units of MinHopRankIncrease, which defaults to DEFAULT_MIN_HOP_RANK_INCREASE; with that setting, the least significant octet in the RPL Rank is not used. becomes... The rank_increase is expressed in units expressed by the variable MinHopRankIncrease which defaults to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE (see Section 6.3); with that setting, the least significant octet in the RPL Rank field in the DIO Base Object is not used. --- Section 4.2.1 step 2 s/should/SHOULD/ s/out of scope/out of scope of this document/ s/succeeded that/passes that/ --- Section 4.2.1 step 7 s/2/two/ --- Section 4.2.1 step 9 s/optional/OPTIONAL/ --- Section 4.2.1 is full of "SHOULD" rules. This is fine, but it means that you need to describe the variance. This might be a catch-all such as... These rules MAY be varied by an implementation according to configured policy. --- Section 4.2.2 Ditto the issue about variance of "SHOULD" rules. --- Section 5 The term "RPL core" is not introduced or discussed. It doesn't show in the RPL spec or in the terminology draft. Reading the section, I think you are referring to some implementation- specific element of the code. If that is so, I wish you wouldn't! Whether I implement RPL as a core protocol component, or a number of flimby wing-nuts is entirely my business. Can you please re-write the section in terms of what OF0 is used for and what information it has to access. What code component calls what other code component really is out of scope. --- Section 5 s/OCP)/(OCP)/ s/DIO ./DIO./ OLD OF0 corresponds to the OCP 0 (to be validated by IANA). NEW OF0 is identified by OCP 0 (to be validated by IANA). END --- Section 6.2 What is a "Configurable parameter" and how is it optional. I don't think you mean that it is a constant. Is it a variable that is only used if the optional feature is implemented? Maybe you mean that it is a configurable value. Can you clarify the text, please. --- Section 6.3 OLD OF0 fixes the following constants: NEW Section 17 of [I-D.ietf-roll-rpl] defines RPL constants. OF0 fixes the values of the following constants: END --- We need a discussion of manageability. This fits best between Sections 6 and 7. You can say which values should be configurable and when (build time, load time / run-time, dynamically). You should also say what information it should be possible to retrieve from a system that implements OF0. --- Section 7 Please identify the registry you want IANA to make an allocation from. --- Section 8 Security Considerations for OCP/OF are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. I am not sure that this means anything at all! You should have: What RPL protocol elements are involved? - Rank - OCP What are the risks if they are compromised or sniffed? Then point to the security framework for a discussion of how to secure RPL protocol elements. What happens if an element says it is implementing OF0, but through an error or malign action implements something else? Can this be detected or mitigated? --- Section 9 I am not sure, but I think... s/implementer's feedback/implementers' feedback/ --- Section 10.2 The use in Section 4.2.1 makes [I-D.ietf-roll-rpl] a normative reference [I-D.tsao-roll-security-framework] is surely [I-D.ietf-roll-security-framework] --- From internet-drafts@ietf.org Wed Jun 15 14:48:47 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFFB11E81C8; Wed, 15 Jun 2011 14:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biEbWzC650I5; Wed, 15 Jun 2011 14:48:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BEE11E81C0; Wed, 15 Jun 2011 14:48:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615214847.4839.10515.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 14:48:47 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-framework-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:48:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : A Security Framework for Routing over Low Power and Loss= y Networks Author(s) : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Filename : draft-ietf-roll-security-framework-06.txt Pages : 48 Date : 2011-06-15 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-06.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-security-framework-06.txt From internet-drafts@ietf.org Fri Jun 17 00:13:38 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A231B11E812C; Fri, 17 Jun 2011 00:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI+9Kh-bsHDY; Fri, 17 Jun 2011 00:13:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B162811E8109; Fri, 17 Jun 2011 00:13:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110617071337.3697.92524.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 00:13:37 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 07:13:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-13.txt Pages : 13 Date : 2011-06-17 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions. An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-13.txt From internet-drafts@ietf.org Mon Jun 20 02:31:50 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B421C1F0C45; Mon, 20 Jun 2011 02:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVIKb3LCizeY; Mon, 20 Jun 2011 02:31:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF641F0C37; Mon, 20 Jun 2011 02:31:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620093150.14593.53757.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 02:31:50 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-14.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:31:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-14.txt Pages : 13 Date : 2011-06-20 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions. An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-14.txt From iesg-secretary@ietf.org Mon Jun 20 08:08:51 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCFE21F8565; Mon, 20 Jun 2011 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2Cwm5XIHohF; Mon, 20 Jun 2011 08:08:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5960D21F8557; Mon, 20 Jun 2011 08:08:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620150850.14535.96841.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 08:08:50 -0700 Cc: roll@ietf.org Subject: [Roll] Last Call: (RPL Objective Function 0) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:08:52 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'RPL Objective Function 0' as a Proposed Standard 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 2011-07-04. 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 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions. An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any extension. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-of0/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-of0/ No IPR declarations have been submitted directly on this I-D. From jpv@cisco.com Sat Jun 25 03:25:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B177F21F8466 for ; Sat, 25 Jun 2011 03:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.53 X-Spam-Level: X-Spam-Status: No, score=-109.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtVkF7q3WqSJ for ; Sat, 25 Jun 2011 03:25:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF121F8465 for ; Sat, 25 Jun 2011 03:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=565; q=dns/txt; s=iport; t=1308997558; x=1310207158; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=iIteSXECBap3/BmTvE2iOBcHmkv+IrJW402fw5sq7ik=; b=IqwFhYN3w1xjlU9EKjNwYt6HjO2oHSAc1GOpHGP92nQUgCtJBbOcThoi zgxgQpT8F08RA7OIAH/BBjMm73A31Z5iGfmiDD88KJHyXKvsRaI+Eq+7B 9M5WuDHCBK/l1JFJmgrcKVTZRXpiOuHIRXerQm+dlElg+E7WUpjLgfOlq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUGAGu3BU6Q/khM/2dsb2JhbABSLacbd4h0pCmdV4YwBJIDhG4JiyY X-IronPort-AV: E=Sophos;i="4.65,424,1304294400"; d="scan'208";a="39236089" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 25 Jun 2011 10:25:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5PAPsTT009766 for ; Sat, 25 Jun 2011 10:25:54 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Jun 2011 12:25:54 +0200 Received: from [172.18.20.79] ([10.61.106.48]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Jun 2011 12:25:53 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 25 Jun 2011 05:52:50 +0200 References: <20110624003320.3E02211E8180@ietfa.amsl.com> To: ROLL WG Message-Id: <61CA521C-CA47-41D3-996B-F2483D20844D@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 25 Jun 2011 10:25:54.0015 (UTC) FILETIME=[436EEEF0:01CC3322] Subject: [Roll] Provisional Fwd: ROLL - Requested session has been scheduled for IETF 81 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 10:25:58 -0000 Dear all, The provisional ROLL WG meeting slot is > ROLL Session 1 (2 hours) > Friday, Afternoon Session I 1300-1400 > Room Name: 208 AB > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: roll > Area Name: Routing Area > Session Requester: JP Vasseur > > Number of Sessions: 1 > Length of Session(s): 2 hours > Please indicate to the chairs before July 8 if you are requesting a slot. Thanks. JP. > >