From nobody Wed Apr 3 10:34:20 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 200AE120156; Wed, 3 Apr 2019 10:34:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Housley Message-ID: <155431284696.22772.5756397598445681320@ietfa.amsl.com> Date: Wed, 03 Apr 2019 10:34:07 -0700 Archived-At: Subject: [Roll] Genart last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 17:34:07 -0000 Reviewer: Russ Housley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-roll-useofrplinfo-25 Reviewer: Russ Housley Review Date: 2019-04-03 IETF LC End Date: 2019-04-11 IESG Telechat date: unknown Summary: Ready with Nits Major Concerns: None. Minor Concerns: Section 1 says: ... This document clarifies examples that intend to illustrate the result of the normative language in RFC8200 and RFC6553. In other words, the examples are intended to be normative explanation of the results of executing that language. This set the wrong expectation for me. What the document seems to be doing is aligning with the recent normative change in RFC8200. The alignment could lead to a flag day, and this document suggests a way to avoid a flag day. It goes through a whole bunch of use cases to illustrate the updates. Nits: In Table 6, please move some of the whitespace on the right to the first column to avoid so many words being split across lines. From nobody Fri Apr 5 08:56:17 2019 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 C312912048C for ; Fri, 5 Apr 2019 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 S-5giS3JYXti for ; Fri, 5 Apr 2019 08:56:12 -0700 (PDT) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 0B9FE120088 for ; Fri, 5 Apr 2019 08:56:11 -0700 (PDT) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id x35FddWH048164 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 5 Apr 2019 15:39:39 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id x35Fdd8R056569 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 5 Apr 2019 15:39:39 GMT Received: from dhcp138.math.unipd.it (dhcp138.math.unipd.it [147.162.114.138]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Fri, 05 Apr 2019 17:39:39 +0200 Date: Fri, 05 Apr 2019 17:39:39 +0200 Message-ID: <20190405173939.Horde.He83hXLYiPxz14M8znuNYLf@webmail.math.unipd.it> From: gquadrio@math.unipd.it To: roll@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DCC-dmv.com-Metrics: server4 1096; Body=71 Fuz1=81 Fuz2=154 X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker (-11) X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.83 Archived-At: Subject: [Roll] [CFP] [5 days Remained] EAI GOODTECHS 2019 - Valencia, Spain, 25/09 - 27/09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 15:56:15 -0000 ******************************************************************** * * Call for Papers * * GoodTechs 2019 * * 5th EAI International Conference on * Smart Objects and Technologies for Social Good * * September 25-27, 2019 * * Submissions due: April 10, 2019 [extended] * ******************************************************************** SCOPE ====== By social good we refer to a “good” or a service that benefits the largest number of people in the largest possible way. Some classic examples of social goods are, of course, healthcare, safety, environment, democracy, and human rights, but we can add to this classic list even communication, art, entertainment and much more. In this context, the popularity of portable computing devices, like smartphones, tablets, or smart watches combined with the emergence of many other small smart objects with computational, sensing and communication capabilities coupled with the popularity of social networks and new human-technology interaction paradigms is creating unprecedented opportunities for each of us to do something useful, ranging from a single person to the whole world. Furthermore, Internet of Things, Smart-cities, distributed sensing and Fog computing are representative examples of modern ICT paradigms that aim to describe a dynamic and globally cooperative infrastructure built upon objects’ intelligence and self-configuring capabilities. These connected objects are finding their way into our pockets, vehicles, urban areas and infrastructure, thus becoming the very texture of our society and providing us the possibility, but also the responsibility, to shape it. In GOODTECHS we are hence interested in experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Clearly, we are not considering only the so called first world as the scenario for this evolution; we also refer to those areas where ICT is currently less widespread, hoping that it may represent a societal development opportunity rather than a source for further divide. Topics Authors are solicited to submit original, previously unpublished papers in the following, but not limited to topic areas: - App concepts and technologies for different mobile platforms - Blockchain for social good - Communication between mobile devices - Content Distribution - E-learning solutions - Data collection, organization and dissemination methods - Delay-tolerant aerial networks and ferrying approaches - Deployment and field-testing - Digital tools for art and feelings - Environment sensing, monitoring and preservation - Experimental results of communication testbeds - Game, entertainment, and multimedia applications - Health and social care - Human-object interaction - ICT for development - Mobile service architectures and frameworks - Mobility and handover management - New application scenarios for vehicular communications - Pervasive and ubiquitous services in cloud and IoT - Platforms and frameworks for mobile devices - Privacy issues and solutions - Protocol design, testing and verification - Security issues, architectures and solutions - Smart cities and transportation - Smart economy solutions: e-banking, e-business - Smart governance and e-administration - Smart living and E-health - Technology addressing the digital divide SPECIAL SESSIONS ================ In addition to the main conference, GOODTECHS19 features special sessions, aimed to emphasize emerging topics not fully or not specifically covered in the main conference. Special sessions highlight current topics related to experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Presentations delivered during the events should be based on original papers, selected through a peer-review process and that have not been previously published. Accepted papers will be included in the Conference Proceedings. For more information please refer to the main conference website: http://goodtechs.eu PUBLICATION =========== All registered papers will be published by ACM and made available through ACM Digital Library. Papers should be in English. Regular papers should be up to 6 pages in length. Short papers should be up to 4 pages in length. Previously published work may not be submitted, nor may the work be concurrently submitted to any other conference or journal. Such papers will be rejected without review. Proceedings will be submitted for inclusion in leading indexing services, Ei Compendex, ISI Web of Science, Scopus, CrossRef, Google Scholar, DBLP, as well as EAI’s own EU Digital Library (EUDL). Authors of selected best accepted and presented papers will be invited to submit an extended version to: - Springer Mobile Networks and Applications (MONET) Journal (IF: 2.497) - Wiley Concurrency and Computation: Practice and Experience Journal (IF: 1.114) All accepted authors are eligible to submit an extended version in a fast track of: - EAI Endorsed Transactions on Cloud Systems - EAI Endorsed Transactions on Serious Games SUBMISSION ========== Papers should be submitted through EAI ‘Confy‘ system (http://confy.eai.eu/52608), and have to comply with the ACM format (see Author’s kit section). IMPORTANT DATES =============== Full Paper Submission deadline: April 10, 2019 Notification deadline: June 1, 2019 Camera-ready deadline: July 1, 2019 Start of Conference: September 25, 2019 End of Conference: September 27, 2019 -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy From nobody Wed Apr 10 12:01:49 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A76DD120389; Wed, 10 Apr 2019 12:01:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Migault Message-ID: <155492289657.22741.9562291002133198844@ietfa.amsl.com> Date: Wed, 10 Apr 2019 12:01:36 -0700 Archived-At: Subject: [Roll] Secdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 19:01:43 -0000 Reviewer: Daniel Migault Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY nits: ROLL Working Group M. Robles Internet-Draft Aalto Updates: 6553, 6550, 8138 (if approved) M. Richardson Intended status: Standards Track SSW Expires: September 12, 2019 P. Thubert Cisco March 11, 2019 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane draft-ietf-roll-useofrplinfo-25 Abstract This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. """ s/on which// s/. /. / """ This document updates RFC 6553 adding a change to the RPL Option Type. Additionally, this document updates RFC 6550 to indicate about this change and updates RFC8138 as well to consider the new Option Type when RPL Option is decompressed. 1. Introduction RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a routing protocol for constrained networks. RFC 6553 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 Hop-by-Hop header to quickly identify inconsistencies (loops) in the routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header to deliver datagrams within a There is certainly a reason for the RH3 spelling, but from 6554 it seems to me that the abbreviation of Source Routing Header is SRH. RPL routing domain, particularly in non-storing mode. For my personal knowledge, I do not understand why this is specific to non-storing mode. Is the reason that in non-storing modes nodes S steer datagram D via the root node R. The IPv6 packet (S,D) is tunneled from S to R and then from R to D. The first tunnel from S to R does not need SRH as nodes are able to steer this to the root (upward routing), while downward routing needs SRH extension. In a storing mode *regular* routing tables are able to steer the traffic from S, to D. There is no need of tunnel and SRH extension. Am I correct, or I am missing something? I apology in advance for the noise. 3. Updates to RFC6553, RFC6550 and RFC 8138 3.1. Updates to RFC 6553 This modification is required to be able to send, for example, IPv6 packets from a RPL-aware-leaf to a not-RPL-aware node through Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 encapsulation. [RFC6553] states as shown below, that in the Option Type field of the RPL Option header, the two high order bits must be set to '01' and the third bit is equal to '1'. The first two bits indicate that the IPv6 node must discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data may change in route. The remaining bits serve as the option type. Robles, et al. Expires September 12, 2019 [Page 5] Internet-Draft RPL-data-plane March 2019 Hex Value Binary Value act chg rest Description Reference --------- --- --- ------- ----------------- ---------- 0x63 01 1 00011 RPL Option [RFC6553] Figure 1: Option Type in RPL Option. Recent changes in [RFC8200] (section 4, page 8), states: "it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so". Processing of the Hop-by-Hop Options header (by IPv6 intermediate nodes) is now optional, but if they are configured to process the header, and if such nodes encounter an option with the first two bits set to 01, they will drop the packet (if they conform to [RFC8200]). Host systems should do the same, irrespective of the configuration. Based on that, if an IPv6 (intermediate) node (RPL-not-capable) receives a packet with an RPL Option, it should ignore the HBH RPL option (skip over this option and continue processing the header). This is relevant, as it was mentioned previously, in the case that there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). I might miss something, but it seems to me that 2460 would end up in the discard of packets with the RPL Option. 8200 introduces some instability. Typically, packets may reach their destination depending on the configuration of the intermediary nodes. In both cases communication between RPL-aware and not-RPL-aware nodes needs to relax the status of the RPL Option. It seems independent to the update of 2460. Thus, this document updates the Option Type field to: the two high order bits MUST be set to '00' and the third bit is equal to '1'. The first two bits indicate that the IPv6 node MUST skip over this option and continue processing the header ([RFC8200] Section 4.2) if it doesn't recognize the option type, and the third bit continues to be set to indicate that the Option Data may change en route. The remaining bits serve as the option type and remain as 0x3. This ensures that a packet that leaves the RPL domain of an LLN (or that leaves the LLN entirely) will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop option known as RPI. This is a significant update to [RFC6553]. [RFCXXXX] represents this document. Hex Value Binary Value act chg rest Description Reference --------- --- --- ------- ----------------- ---------- 0x23 00 1 00011 RPL Option [RFCXXXX] Figure 2: Revised Option Type in RPL Option. 5. Use cases NOTE: There is some possible security risk when the RPI information is released to the Internet. At this point this is a theoretical situation; no clear attack has been described. At worst, it is clear that the RPI option would waste some network bandwidth when it escapes. This is traded off against the savings in the LLN by not having to encapsulate the packet in order to remove the artifact. I believe that worst means minimal here. One of the risk is at least marking the packet as originating to/from a LLN. It may reveal the type of the information carried by the packet in addition to the information contained in the RPI. Possible information leaked may be related to the topology of the LLN, but I am not familiar enough to define clearly how this could be exploited. The information may also reveals information about the stability of the LLN by observing the rate. IF that is correct this could eventually provide indication an attack is effective or not. My understanding is that with 63 the packet is dropped after the first non aware router, while this is not the case with 23. Now that I have been through the security consideration section, I believe a sinple reference to the security consideration woudl be sufficient. 11. Security Considerations The security considerations covered in [RFC6553] and [RFC6554] apply when the packets are in the RPL Domain. The IPv6-in-IPv6 mechanism described in this document is much more limited than the general mechanism described in [RFC2473]. The willingness of each node in the LLN to decapsulate packets and forward them could be exploited by nodes to disguise the origin of an attack. While a typical LLN may be a very poor origin for attack traffic (as the networks tend to be very slow, and the nodes often have very low duty cycles) given enough nodes, they could still have a significant impact, particularly if the attack was on another LLN! maybe it might be clearer - at least to me, but I am not English native. s/was on another LLN!/is targeting another LLN!/ Additionally, some uses of RPL involve large backbone ISP scale equipment [I-D.ietf-anima-autonomic-control-plane], which may be equipped with multiple 100Gb/s interfaces. Blocking or careful filtering of IPv6-in-IPv6 traffic entering the LLN as described above will make sure that any attack that is mounted must originate from compromised nodes within the LLN. The use of BCP38 filtering at the RPL root on egress traffic will both alert the operator to the existence of the attack, as well as drop the attack traffic. As the RPL network is typically numbered from a single prefix, which is itself assigned by RPL, BCP38 filtering involves a single prefix comparison and should be trivial to automatically configure. There are some scenarios where IPv6-in-IPv6 traffic should be allowed to pass through the RPL root, such as the IPv6-in-IPv6 mediated communications between a new Pledge and the Join Registrar/ Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the RPL root to do careful filtering: it occurs only when the Join Coordinator is not co-located inside the RPL root. Robles, et al. Expires September 12, 2019 [Page 45] Internet-Draft RPL-data-plane March 2019 With the above precautions, an attack using IPv6-in-IPv6 tunnels will be by a node within the LLN on another node within the LLN. Such an attack could, of course, be done directly. An attack of this kind is meaningful only if the source addresses are either fake or if the point is to amplify return traffic. Such an attack, could also be done without the use of IPv6-in-IPv6 headers using forged source addresses. If the attack requires bi-directional communication, then IPv6-in-IPv6 provides no advantages. [RFC2473] suggests that tunnel entry and exit points can be secured, via the "Use IPsec". The suggested solution has all the problems that [RFC5406] goes into. In an LLN such a solution would degenerate into every node having a tunnel with every other node. It would provide a small amount of origin address authentication at a very high cost; doing BCP38 at every node (linking layer-3 addresses to layer-2 addresses, and to already present layer-2 cryptographic mechanisms) would be cheaper should RPL be run in an environment where hostile nodes are likely to be a part of the LLN. My understanding is that IPsec SA will be needed between each parent - children and that a hop-by-hop decapsulation/encapsulation is happening. If that is correct, we may avoid the situation where each node deals with 2 * n *(n-1) SA. However without any transit devices IPsec provides no obvious advantages over L2 security. It might be god to recommend that one or the other layer implements security. In addition, I am also wondering if the use of IPsec would not be recommended as an alternative when LLN are involving communication over the Internet. From nobody Wed Apr 10 17:25:54 2019 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 68474120363; Wed, 10 Apr 2019 17:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 93FHqWCU5_hw; Wed, 10 Apr 2019 17:25:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0A5120092; Wed, 10 Apr 2019 17:25:28 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [207.164.179.98]) by relay.sandelman.ca (Postfix) with ESMTPS id A51541F483; Thu, 11 Apr 2019 00:25:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id F2FC64291; Thu, 11 Apr 2019 01:43:22 +0200 (CEST) From: Michael Richardson To: Russ Housley cc: gen-art@ietf.org, roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org In-reply-to: <155431284696.22772.5756397598445681320@ietfa.amsl.com> References: <155431284696.22772.5756397598445681320@ietfa.amsl.com> Comments: In-reply-to Russ Housley via Datatracker message dated "Wed, 03 Apr 2019 10:34:07 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 10 Apr 2019 19:43:22 -0400 Message-ID: <23139.1554939802@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] Genart last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 11 Apr 2019 00:25:38 -0000 --=-=-= Content-Type: text/plain Russ Housley via Datatracker wrote: > Section 1 says: > ... This document clarifies examples that intend to illustrate the > result of the normative language in RFC8200 and RFC6553. In other > words, the examples are intended to be normative explanation of the > results of executing that language. > This set the wrong expectation for me. What the document seems to be > doing is aligning with the recent normative change in RFC8200. The > alignment could lead to a flag day, and this document suggests a way to > avoid a flag day. It goes through a whole bunch of use cases to > illustrate the updates. So, the actual order of operations was more like: - we aren't following 2460, so let's write down the right rules - oh, look, 2460bis is happening, can we get the rules changed? - cool, it happened, now what does that mean. So I'll try to fix the text to match what a reader would now expect. Can you help with that paragraph? How about: } This document provides a series of examples that align RFC6553 } with the recent changes in processing described in RFC8200. In other } words, the examples are intended to be normative explanation of the } results of executing that language. } Existing deployed networks may experience a flag day as a result of } some of the suggested changes, and this document provides a way } to mitigate such an occurance. > Nits: > In Table 6, please move some of the whitespace on the right to the > first column to avoid so many words being split across lines. I don't think we control the table formatting, xml2rfc does. I'll see if I can do something about that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyuf5oACgkQlUzhVv38 QpCwzQf/f2QS1EFqtJSnk/nHVcuyPDCceYeMQjdOr5wTwmlkS5Y3woyOxgDWMOJg 5kDaYuNVhn8WlLN4CsnoqxxnCOOWmFWEZc9MQZUCDfsAbODBrbk+Ie/geKh8XtM5 3GhU+gPo1/9siIa4yKYX2XMXADnyxMmFamcuhflp9sLwfOTwbt1cvgahY9Htr5f4 fbTCq6NI/FVnlEf/fx4u+ltXeoI+Jv8jTwf4lM3GK1FZftok0o5Wjv+uIRIcoxaO nXdNglJhXTaf0nHUNLEwLxlEoxEyaWwrLwHrfJwWQnmZrq5TYpu51a9AJa2Hqi3M sVnl8ZrO06i05hjvVblHh3YuUyH6/w== =xS48 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 10 17:25:59 2019 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 57C601203D2; Wed, 10 Apr 2019 17:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NK-7FTbjnSqZ; Wed, 10 Apr 2019 17:25:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B20F1200A0; Wed, 10 Apr 2019 17:25:28 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [207.164.179.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 9F82B1F482; Thu, 11 Apr 2019 00:25:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1FFC84289; Thu, 11 Apr 2019 01:31:13 +0200 (CEST) From: Michael Richardson To: Daniel Migault cc: secdir@ietf.org, roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org In-reply-to: <155492289657.22741.9562291002133198844@ietfa.amsl.com> References: <155492289657.22741.9562291002133198844@ietfa.amsl.com> Comments: In-reply-to Daniel Migault via Datatracker message dated "Wed, 10 Apr 2019 12:01:36 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 10 Apr 2019 19:31:13 -0400 Message-ID: <22524.1554939073@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] Secdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 11 Apr 2019 00:25:42 -0000 --=-=-= Content-Type: text/plain Thank you for the review Daniel. I'm unclear if there are any changes you want, given that you've given it a "ready" Some replies/clarifications to your comments. Daniel Migault via Datatracker wrote: > RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) > [RFC6550] is a routing protocol for constrained networks. RFC 6553 > [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 > Hop-by-Hop header to quickly identify inconsistencies (loops) in the > routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route > Header" (RH3), an IPv6 Extension Header to deliver datagrams within a > There is certainly a reason for the RH3 spelling, but from 6554 > it seems to me that the abbreviation of Source Routing Header is SRH. > It's SRH type 3. The use of "RHx" is common in many documents, including 6554, so it would be wrong for us to change that, I think. > RPL routing domain, particularly in non-storing mode. > For my personal knowledge, I do not understand why this is > specific to non-storing mode. Is the reason that in non-storing modes > nodes S steer datagram D via the root node R. The IPv6 packet (S,D) is > tunneled from S to R and then from R to D. The first tunnel from S to R > does not need SRH as nodes are able to steer this to the root (upward > routing), while downward routing needs SRH extension. > In a storing mode *regular* routing tables are able to steer the > traffic from S, to D. There is no need of tunnel and SRH extension. > Am I correct, or I am missing something? I apology in advance for the > noise. Yes, that's correct. > Based on that, if an IPv6 (intermediate) node (RPL-not-capable) > receives a packet with an RPL Option, it should ignore the HBH RPL > option (skip over this option and continue processing the header). > This is relevant, as it was mentioned previously, in the case that > there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). > I might miss something, but it seems to me that 2460 would end > up in the discard of packets with the RPL Option. 8200 introduces some > instability. Typically, packets may reach their destination depending > on the configuration of the intermediary nodes. In both cases > communication between RPL-aware and not-RPL-aware nodes needs to relax > the status of the RPL Option. It seems independent to the update of > 2460. 2460 says that you have to examine all options, and discard if you do not understand. 8200 says that you examine options you are configured to examine. 8200 gives us additional options and removes the need for some IPIP tunnels, as we do not need to remove the option. > NOTE: There is some possible security risk when the RPI information > is released to the Internet. At this point this is a theoretical > situation; no clear attack has been described. At worst, it is clear > that the RPI option would waste some network bandwidth when it escapes. > This is traded off against the savings in the LLN by not having to > encapsulate the packet in order to remove the artifact. > I believe that worst means minimal here. One of the risk is at > least marking the packet as originating to/from a LLN. It may reveal > the type of the information carried by the packet in addition to the > information contained in the RPI. Possible information leaked may be > related to the topology of the LLN, but I am not familiar enough to > define clearly how this could be exploited. The information may also > reveals information about the stability of the LLN by observing the > rate. IF that is correct this could eventually provide indication an > attack is effective or not. > My understanding is that with 63 the packet is dropped after the first > non aware router, while this is not the case with 23. Correct. We picked 63 back in the day, so that packets that "escaped" would never reveal anything. But that was just too restrictive, and basically many assumed that they could just add/remove extension headers whenever they wanted. > Now that I have been through the security consideration section, I > believe a sinple reference to the security consideration woudl be > sufficient. I personally do not like writing text in SC that is new, I prefer to refer back to normative text in the Security Considerations, because non-security people do not read Security Considerations. > [RFC2473] suggests that tunnel entry and exit points can be secured, > via the "Use IPsec". The suggested solution has all the problems that > [RFC5406] goes into. In an LLN such a solution would degenerate into > every node having a tunnel with every other node. It would provide a > small amount of origin address authentication at a very high cost; > doing BCP38 at every node (linking layer-3 addresses to layer-2 > addresses, and to already present layer-2 cryptographic mechanisms) > would be cheaper should RPL be run in an environment where hostile > nodes are likely to be a part of the LLN. > My understanding is that IPsec SA will be needed between each > parent - children and that a hop-by-hop decapsulation/encapsulation is > happening. If that is correct, we may avoid the situation where each > node deals with 2 * n *(n-1) SA. However without any transit devices > IPsec provides no obvious advantages over L2 security. It might be god > to recommend that one or the other layer implements security. In > addition, I am also wondering if the use of IPsec would not be > recommended as an alternative when LLN are involving communication over > the Internet. A recommendation for End to End IPsec or End to End OSCORE/EDHOC or End to End DTLS for application data is certainly reasonably, but seems out of scope for this document. There are cases where we insert IPIP headers between nodes which are not parent-child. For instance, from root to leaf in the non-storing downward direction (because we add RH3). If we were to "Use IPsec", then we'd need more tunnels. In the cases where an RPL-aware 6LR adds an RPI header (in storing mode), for an RPL-unaware-leaf, and then sends it to some other leaf, we'd need an IPsec tunnel from two random nodes in order to secure the IPIP. So while we don't need 2*n*(n-1) SAs in every case, that is the worst case scenario. (btw: I think that there are some non-constrained, non-LLN uses of RPL where that actually might be worth doing) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyufMAACgkQlUzhVv38 QpDtXgf9G2QnODnORwLuHF5yjb2rLTgh9namaVq6bUFvNsPlHVooKKm/IMR8pozb P0UYK7xJJ616ItqHQTxJUejUwx7JvACRth8DUsfWmJztQRzCMH5YsRUfvCBpDcXu t9X1rXpt8tpPyCnFWu2sRj9vOEazA/zRlGG+Oaks8wR/SJSKBslj8xERtJMYqwoo iHWMHova4yy6tltkoXp73sY4j/m4sXzAFS+RzDhRycdMdXUPBXcumc5alYoQG2lC qx7icJdz9dbtAWIyGVubI1Zfwl9GRMtz9s9FZ8TGuAPAV1+PriH2Z1f61JuvGxhz izPHjMik27oVrLT/98ygU7gN3AYlrQ== =1s3k -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 10 18:12:02 2019 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 D7B7A120465; Wed, 10 Apr 2019 18:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 lDiyK80ZsWGI; Wed, 10 Apr 2019 18:11:57 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720041.outbound.protection.outlook.com [40.107.72.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C463E120125; Wed, 10 Apr 2019 18:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GCh32v/atE0NwLDyVGZLnpgdDRoG42OiWTdLKuwK6hM=; b=jEKvTk/QFhTDsm6raRhIN2zrbafoFRE3Sw6L40Ri/1r5Gre8ZyBWepkSh3XfUhVvqT6TPLws5FQM0SJoggGpZR7Rjxp8+y8TpLi38jUCO59CltZ7TYgf1eWtwUcDJBivb39DiOjO607tf8/DsMvt0K1W2XOlzRteC8HSM+Z5QfM= Received: from MN2PR15MB3310.namprd15.prod.outlook.com (20.179.21.142) by MN2PR15MB2735.namprd15.prod.outlook.com (20.179.147.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Thu, 11 Apr 2019 01:11:54 +0000 Received: from MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::3568:7582:3c7d:6f18]) by MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::3568:7582:3c7d:6f18%2]) with mapi id 15.20.1771.016; Thu, 11 Apr 2019 01:11:54 +0000 From: Daniel Migault To: Michael Richardson CC: "secdir@ietf.org" , "roll@ietf.org" , "ietf@ietf.org" , "draft-ietf-roll-useofrplinfo.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-roll-useofrplinfo-25 Thread-Index: AQHU7/0VC3CEKOMN4UKr1zrsdJOI3aY2IUHA Date: Thu, 11 Apr 2019 01:11:53 +0000 Message-ID: References: <155492289657.22741.9562291002133198844@ietfa.amsl.com> <22524.1554939073@dooku.sandelman.ca> In-Reply-To: <22524.1554939073@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: becde922-ddec-41f5-be94-08d6be1aaf6c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR15MB2735; x-ms-traffictypediagnostic: MN2PR15MB2735: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(51914003)(13464003)(51444003)(199004)(189003)(106356001)(33656002)(102836004)(4326008)(486006)(7736002)(7696005)(53936002)(6436002)(66066001)(105586002)(9686003)(476003)(305945005)(55016002)(229853002)(99286004)(186003)(446003)(86362001)(74316002)(25786009)(6246003)(44832011)(52536014)(11346002)(5660300002)(316002)(54906003)(81156014)(81166006)(2906002)(3846002)(53546011)(8676002)(14444005)(71200400001)(256004)(71190400001)(8936002)(26005)(97736004)(478600001)(6506007)(68736007)(76176011)(14454004)(6116002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB2735; H:MN2PR15MB3310.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LHwZzHV3nsMYzIOMdxIFokKdn1FknRms8J3CpcLArt/6h2eJUluIvGGgADU5LBF8bHxle87OnsireiQXGAh2dszp98ywVouucnbO3YdeSvr6nGufTSV0gADqyY5UQnc6e0pyOsvyQsmLu/8Dk85/RuD0dj3a85zBZj4Jxt9vShWiXlzEH0PLyBMAiGZf4eCurZxYurNAHz70zARSEmxx6FddQ9gHaMt3Hbvn/rCUCpa+yvYxGPNY3BIu/VkmwsmyvjDEvrTWEuWgdUq+2Dzvcru4LbWpiOWgHBhk26kvFM0l/dM4NT0vqgE/VR5BVki4Qnk9Gps/RkL0Xwe7JXET9/Of5Ci3b8gic3bFK9WrLWxyE2s8GJBpcn0FDLxgr7YKtsLv0qR5BbJmuFYeSgWpiftjsXQ+Eg9AqpagqYXjlI4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: becde922-ddec-41f5-be94-08d6be1aaf6c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 01:11:53.9139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2735 Archived-At: Subject: Re: [Roll] Secdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 11 Apr 2019 01:12:00 -0000 Thanks for the responses. I am not requesting any changes. My comments most= ly reflected some personal interests/questions. I found pretty much what I = needed in the text and let you decide if my comments may lead to some chang= es in the text. In any case that seems nits and I find the document ready.= =20 Yours,=20 Daniel -----Original Message----- From: Michael Richardson =20 Sent: Wednesday, April 10, 2019 7:31 PM To: Daniel Migault Cc: secdir@ietf.org; roll@ietf.org; ietf@ietf.org; draft-ietf-roll-useofrpl= info.all@ietf.org Subject: Re: Secdir last call review of draft-ietf-roll-useofrplinfo-25 Thank you for the review Daniel. I'm unclear if there are any changes you want, given that you've given it a= "ready" Some replies/clarifications to your comments. Daniel Migault via Datatracker wrote: > RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) > [RFC6550] is a routing protocol for constrained networks. RFC 6553 > [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 > Hop-by-Hop header to quickly identify inconsistencies (loops) in the > routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route > Header" (RH3), an IPv6 Extension Header to deliver datagrams within a > There is certainly a reason for the RH3 spelling, but from 655= 4 > it seems to me that the abbreviation of Source Routing Header is SRH. > It's SRH type 3. The use of "RHx" is common in many documents, including 6= 554, so it would be wrong for us to change that, I think. > RPL routing domain, particularly in non-storing mode. > For my personal knowledge, I do not understand why this is > specific to non-storing mode. Is the reason that in non-storing modes > nodes S steer datagram D via the root node R. The IPv6 packet (S,D) i= s > tunneled from S to R and then from R to D. The first tunnel from S to= R > does not need SRH as nodes are able to steer this to the root (upward > routing), while downward routing needs SRH extension. > In a storing mode *regular* routing tables are able to steer the > traffic from S, to D. There is no need of tunnel and SRH extension. > Am I correct, or I am missing something? I apology in advance for the > noise. Yes, that's correct. > Based on that, if an IPv6 (intermediate) node (RPL-not-capable) > receives a packet with an RPL Option, it should ignore the HBH RPL > option (skip over this option and continue processing the header). > This is relevant, as it was mentioned previously, in the case that > there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). > I might miss something, but it seems to me that 2460 would end > up in the discard of packets with the RPL Option. 8200 introduces som= e > instability. Typically, packets may reach their destination depending > on the configuration of the intermediary nodes. In both cases > communication between RPL-aware and not-RPL-aware nodes needs to rela= x > the status of the RPL Option. It seems independent to the update of > 2460. 2460 says that you have to examine all options, and discard if you do not u= nderstand. 8200 says that you examine options you are configured to examine= . 8200 gives us additional options and removes the need for some IPIP tunnels= , as we do not need to remove the option. > NOTE: There is some possible security risk when the RPI informatio= n > is released to the Internet. At this point this is a theoretical > situation; no clear attack has been described. At worst, it is clear > that the RPI option would waste some network bandwidth when it escape= s. > This is traded off against the savings in the LLN by not having to > encapsulate the packet in order to remove the artifact. > I believe that worst means minimal here. One of the risk is at > least marking the packet as originating to/from a LLN. It may reveal > the type of the information carried by the packet in addition to the > information contained in the RPI. Possible information leaked may be > related to the topology of the LLN, but I am not familiar enough to > define clearly how this could be exploited. The information may also > reveals information about the stability of the LLN by observing the > rate. IF that is correct this could eventually provide indication an > attack is effective or not. > My understanding is that with 63 the packet is dropped after the firs= t > non aware router, while this is not the case with 23. Correct. We picked 63 back in the day, so that packets that "escaped" woul= d never reveal anything. But that was just too restrictive, and basically = many assumed that they could just add/remove extension headers whenever the= y wanted. > Now that I have been through the security consideration section, I > believe a sinple reference to the security consideration woudl be > sufficient. I personally do not like writing text in SC that is new, I prefer to refer = back to normative text in the Security Considerations, because non-security= people do not read Security Considerations. > [RFC2473] suggests that tunnel entry and exit points can be secure= d, > via the "Use IPsec". The suggested solution has all the problems tha= t > [RFC5406] goes into. In an LLN such a solution would degenerate into > every node having a tunnel with every other node. It would provide a > small amount of origin address authentication at a very high cost; > doing BCP38 at every node (linking layer-3 addresses to layer-2 > addresses, and to already present layer-2 cryptographic mechanisms) > would be cheaper should RPL be run in an environment where hostile > nodes are likely to be a part of the LLN. > My understanding is that IPsec SA will be needed between each > parent - children and that a hop-by-hop decapsulation/encapsulation i= s > happening. If that is correct, we may avoid the situation where each > node deals with 2 * n *(n-1) SA. However without any transit devices > IPsec provides no obvious advantages over L2 security. It might be go= d > to recommend that one or the other layer implements security. In > addition, I am also wondering if the use of IPsec would not be > recommended as an alternative when LLN are involving communication ov= er > the Internet. A recommendation for End to End IPsec or End to End OSCORE/EDHOC or End to = End DTLS for application data is certainly reasonably, but seems out of sco= pe for this document. There are cases where we insert IPIP headers between nodes which are not pa= rent-child. For instance, from root to leaf in the non-storing downward di= rection (because we add RH3). If we were to "Use IPsec", then we'd need mo= re tunnels. In the cases where an RPL-aware 6LR adds an RPI header (in storing mode), f= or an RPL-unaware-leaf, and then sends it to some other leaf, we'd need an = IPsec tunnel from two random nodes in order to secure the IPIP. So while we don't need 2*n*(n-1) SAs in every case, that is the worst case = scenario. (btw: I think that there are some non-constrained, non-LLN uses of RPL wher= e that actually might be worth doing) -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Apr 11 03:21:24 2019 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 3B65912004D for ; Thu, 11 Apr 2019 03:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DtJIsyaQGV0Z for ; Thu, 11 Apr 2019 03:21:21 -0700 (PDT) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 E2A6E120116 for ; Thu, 11 Apr 2019 03:21:20 -0700 (PDT) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id x3BAEcpK014177 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Apr 2019 10:14:39 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id x3BAEcES009059 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Apr 2019 10:14:38 GMT Received: from host171-175-dynamic.9-87-r.retail.telecomitalia.it (host171-175-dynamic.9-87-r.retail.telecomitalia.it [87.9.175.171]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Thu, 11 Apr 2019 12:14:38 +0200 Date: Thu, 11 Apr 2019 12:14:38 +0200 Message-ID: <20190411121438.Horde.Rd8L_5hA9k5y2hk2I_8LMeC@webmail.math.unipd.it> From: gquadrio@math.unipd.it To: roll@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DCC--Metrics: server4 1480; Body=82 Fuz1=many Fuz2=82 X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker (-7.638) X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.83 Archived-At: Subject: [Roll] [CFP] EAI GOODTECHS 2019, Extended Deadline to 1st May (Firm Deadline) - Valencia, Spain, 25/09 - 27/09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 11 Apr 2019 10:21:23 -0000 ******************************************************************** * * Call for Papers * * GoodTechs 2019 * * 5th EAI International Conference on * Smart Objects and Technologies for Social Good * * September 25-27, 2019 * * Submissions due: May 1st, 2019 [Firm Deadline] * ******************************************************************** SCOPE ====== By social good we refer to a “good” or a service that benefits the largest number of people in the largest possible way. Some classic examples of social goods are, of course, healthcare, safety, environment, democracy, and human rights, but we can add to this classic list even communication, art, entertainment and much more. In this context, the popularity of portable computing devices, like smartphones, tablets, or smart watches combined with the emergence of many other small smart objects with computational, sensing and communication capabilities coupled with the popularity of social networks and new human-technology interaction paradigms is creating unprecedented opportunities for each of us to do something useful, ranging from a single person to the whole world. Furthermore, Internet of Things, Smart-cities, distributed sensing and Fog computing are representative examples of modern ICT paradigms that aim to describe a dynamic and globally cooperative infrastructure built upon objects’ intelligence and self-configuring capabilities. These connected objects are finding their way into our pockets, vehicles, urban areas and infrastructure, thus becoming the very texture of our society and providing us the possibility, but also the responsibility, to shape it. In GOODTECHS we are hence interested in experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Clearly, we are not considering only the so called first world as the scenario for this evolution; we also refer to those areas where ICT is currently less widespread, hoping that it may represent a societal development opportunity rather than a source for further divide. Topics Authors are solicited to submit original, previously unpublished papers in the following, but not limited to topic areas: - App concepts and technologies for different mobile platforms - Blockchain for social good - Communication between mobile devices - Content Distribution - E-learning solutions - Data collection, organization and dissemination methods - Delay-tolerant aerial networks and ferrying approaches - Deployment and field-testing - Digital tools for art and feelings - Environment sensing, monitoring and preservation - Experimental results of communication testbeds - Game, entertainment, and multimedia applications - Health and social care - Human-object interaction - ICT for development - Mobile service architectures and frameworks - Mobility and handover management - New application scenarios for vehicular communications - Pervasive and ubiquitous services in cloud and IoT - Platforms and frameworks for mobile devices - Privacy issues and solutions - Protocol design, testing and verification - Security issues, architectures and solutions - Smart cities and transportation - Smart economy solutions: e-banking, e-business - Smart governance and e-administration - Smart living and E-health - Technology addressing the digital divide SPECIAL SESSIONS ================ In addition to the main conference, GOODTECHS19 features special sessions, aimed to emphasize emerging topics not fully or not specifically covered in the main conference. Special sessions highlight current topics related to experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Presentations delivered during the events should be based on original papers, selected through a peer-review process and that have not been previously published. Accepted papers will be included in the Conference Proceedings. For more information please refer to the main conference website: http://goodtechs.eu PUBLICATION =========== All registered papers will be published by ACM and made available through ACM Digital Library. Papers should be in English. Regular papers should be up to 6 pages in length. Short papers should be up to 4 pages in length. Previously published work may not be submitted, nor may the work be concurrently submitted to any other conference or journal. Such papers will be rejected without review. Proceedings will be submitted for inclusion in leading indexing services, Ei Compendex, ISI Web of Science, Scopus, CrossRef, Google Scholar, DBLP, as well as EAI’s own EU Digital Library (EUDL). Authors of selected best accepted and presented papers will be invited to submit an extended version to: - Springer Mobile Networks and Applications (MONET) Journal (IF: 2.497) - Wiley Concurrency and Computation: Practice and Experience Journal (IF: 1.114) All accepted authors are eligible to submit an extended version in a fast track of: - EAI Endorsed Transactions on Cloud Systems - EAI Endorsed Transactions on Serious Games SUBMISSION ========== Papers should be submitted through EAI ‘Confy‘ system (https://confyplus.eai.eu/app#conftrack-overview/conf/52608/cid/52655), and have to comply with the ACM format (see Author’s kit section). IMPORTANT DATES =============== Full Paper Submission deadline: May 1, 2019 Notification deadline: June 1, 2019 Camera-ready deadline: July 1, 2019 Start of Conference: September 25, 2019 End of Conference: September 27, 2019 -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy From nobody Thu Apr 11 03:46:14 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0BA1201B8; Thu, 11 Apr 2019 03:46:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Colin Perkins via Datatracker To: Cc: roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Colin Perkins Message-ID: <155497956717.12785.2838340405405604916@ietfa.amsl.com> Date: Thu, 11 Apr 2019 03:46:07 -0700 Archived-At: Subject: [Roll] Tsvart last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 10:46:07 -0000 Reviewer: Colin Perkins Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. The draft updates RFC 6553 to use a different IPv6 hop-by-hop option type for RPL packets, to avoid some issues discovered through deployment experience. This looks to require a flag day cutover, and hence has some potential interoperability concerns, but introduces no transport concern. The draft also describes a number of clarifications around when to use the RPL hop-by-hop option header and when to use IP-in-IP tunnelling, described based on a set of use case examples. There do not look to be any new transport-related concerns with this draft. The draft does not mention ECN when using IPv6-in-IPv6 tunneling. It is perhaps implied, but a reference to RFC 6040 would be helpful to clarify how ECN bits are copied between inner and outer headers when encapsulating and decapsulating packets from an IPv6-in-IPv6 tunnel. ECN is seeing increasing use in transport protocols, so correctly propagating this information is important. From nobody Thu Apr 11 14:12:22 2019 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 2C98E120220; Thu, 11 Apr 2019 14:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UDuyQhcWua9l; Thu, 11 Apr 2019 14:12:15 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 B976B120165; Thu, 11 Apr 2019 14:12:11 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id j132so6201430oib.2; Thu, 11 Apr 2019 14:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=+lUVvRQoldCsb4S76Dv/23eALwY4tmsfSTKUilhanD8=; b=oHFnsIJkzyDVuK3mUXmphTH6WnzLp8PDuaXO2JEzepPXw/wh8JBw8aFdgWjYJ12LOR +aZ7gLN/txy1l66QjFtF0ufJlRCsqdK4S1b2dGvQGmEgqw8mPM5a5rXP9hI4nFGmR5Xr fGBGREzPNuPjcB0bdINDSGBu5md/rZHHlD/f3PN8OM39KtkAWMOcbJymYyKlRT4lZN6Z DGJdvMW6/Sc5JucsS5X0gSdNCiJnad//exRv9CpW16u15bpMl/VypeIuzsP0SDmoc59R a503BZT9StwspH49BhUm2ULeI9Iiea8tsCDq2V1LvbHYvZ159dhvIcezAg6qcDkQ0c9P H5DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=+lUVvRQoldCsb4S76Dv/23eALwY4tmsfSTKUilhanD8=; b=g+4k3w+Z1qE3DQie0OjcrYiSVwpwLVBx+EV1y90hk9OUcPK2RipFCcGwlOHlUtYOwc /wNS2b/IhHyFDFNr0DH/a51iWfBHkspC2MEdw9W3P7fykrd2RUqzUWSlzqND58cpPZub mCflwznYbWfJkAnV8Di9Za/M6GTRWElMKpuyTqbfZ7g7NYEk/5OLvgOLXv6skaAGMXW+ HvqzklsNTFrTpkJaBfPVVoZnz8UWT5JfqPShObfaOoQ8ckQ2yq1bcuhIw6w37jgP22Ar /478803112iIyiJCsTquwYsAm52qknztnqm4BdDruqJtW66meAhn8chegBHWr4mdNyc6 LEvA== X-Gm-Message-State: APjAAAUSjnyaBT01MyF7oegGR0rq/0VeZL3VbvCmq8w/aVK6Z7IfeqZF dqE0eL67OUUL+SoHO9hYG3Ea7cdMECZhpK6UpNt1xQ== X-Google-Smtp-Source: APXvYqx8paGriTziqKPBolEk9DimFZxiiCxzndy6bQbcXKsPGRSeRAW8PSvrxEdLQeBLQFt4Wp+mTvMQ2lqG9PBAFzA= X-Received: by 2002:aca:ea54:: with SMTP id i81mr7791213oih.115.1555017130306; Thu, 11 Apr 2019 14:12:10 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Apr 2019 14:12:09 -0700 From: Alvaro Retana MIME-Version: 1.0 Date: Thu, 11 Apr 2019 14:12:09 -0700 Message-ID: To: draft-ietf-roll-efficient-npdao@ietf.org Cc: Peter van der Stok , roll-chairs , roll Content-Type: multipart/alternative; boundary="000000000000abf257058647a36b" Archived-At: Subject: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 11 Apr 2019 21:12:21 -0000 --000000000000abf257058647a36b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: Here's my review of this document. The first part of the document mostly resulted in nits, but (starting in =C2=A74) I then have some major comments= . I'll wait for those to be addressed before starting the IETF Last Call. The most significant issue is the fact that the suggested values for the DCO are already assigned! The Shepherd's writeup says that a pilot implementation exists -- which, I assume uses the suggested values. What is the impact on existing implementations? Thanks! Alvaro. [Line numbers come from idnits.] ... 14 Abstract 16 This document describes the problems associated with NPDAO messaging 17 used in RPL for route invalidation and signaling changes to improve 18 route invalidation efficiency. [nit] Please expand NPDAO...you may have to do it completely (including DAO). [nit] RPL should be expanded in the Abstract as well... ... 91 1. Introduction 93 RPL [RFC6550] (Routing Protocol for Low power and lossy networks) 94 specifies a proactive distance-vector based routing scheme. RPL has 95 an optional messaging in the form of DAO (Destination Advertisement 96 Object) messages using which the 6LBR (6Lo Border Router) and 6LR 97 (6Lo Router) can learn route towards the downstream nodes. In 98 storing mode, DAO messages would result in routing entries been 99 created on all intermediate 6LRs from the node's parent all the way 100 towards the 6LBR. [nit] s/messages using which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can learn route/messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can use to learn a route [nit] s/routing entries been created/routing entries being created 102 RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a 103 routing path corresponding to the given target, thus releasing 104 resources utilized on that path. A NPDAO is a DAO message with route 105 lifetime of zero, originates at the target node and always flows 106 upstream towards the 6LBR. This document explains the problems 107 associated with the current use of NPDAO messaging and also discusses 108 the requirements for an optimized route invalidation messaging 109 scheme. Further a new pro-active route invalidation message called 110 as "Destination Cleanup Object (DCO)" is specified which fulfills 111 requirements of an optimized route invalidation messaging. [nit] s/allows use of/allows the use of [nit] s/"Destination Cleanup Object (DCO)"/"Destination Cleanup Object" (DCO) ... 117 1.1. Requirements Language and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the template in rfc8174. 123 6LR: 6LoWPAN Router. This is an intermediate 6lowpan router which 124 allows traffic routing through itself in a multihop 6lo network. [nit] Please be consistent: 6LoWPAN vs 6lowpan [nit] You may have to define 6lo. [minor] In this case, the definition includes the name: "6LoWPAN Router...is an intermediate 6lowpan router..." [nit] In general, simply pointing to rfc6550 (or other documents where the terms are already defined) may be easier than redefining. ... 161 1.2. Current NPDAO messaging 163 RPL uses NPDAO messaging in the storing mode so that the node 164 changing it routing adjacencies can invalidate the previous route. 165 This is needed so that nodes along previous path can release any 166 resources (such as the routing entry) it maintains on behalf of 167 target node. [nit] s/along previous path/along the previous path ... 200 1.3. Why NPDAO is important? 202 Nodes in LLNs may be resource constrained. There is limited memory 203 available and routing entry records are one of the primary elements 204 occupying dynamic memory in the nodes. Route invalidation helps 6LR 205 nodes to decide which entries could be discarded to better achieve 206 resource utilization. Thus it becomes necessary to have efficient 207 route invalidation mechanism. Also note that a single parent switch 208 may result in a "sub-tree" switching from one parent to another. 209 Thus the route invalidation needs to be done on behalf of the sub- 210 tree and not the switching node alone. In the above example, when 211 Node (D) switches parent, the route updates needs to be done for the 212 routing tables entries of (C),(H),(A),(G), and (B) with destination 213 (D),(E) and (F). Without efficient route invalidation, a 6LR may 214 have to hold a lot of stale route entries. [nit] s/to have efficient/to have an efficient ... 225 2.2. Invalidate routes of dependent nodes 227 RPL does not specify how route invalidation will work for dependent 228 nodes rooted at switching node, resulting in stale routing entries of 229 the dependent nodes. The only way for 6LR to invalidate the route 230 entries for dependent nodes would be to use route lifetime expiry 231 which could be substantially high for LLNs. [nit] s/rooted at switching node/rooted at the switching node ... 239 2.3. Possible route downtime caused by async operation of NPDAO and DA= O ... 247 In the example topology, consider Node (D) switches from parent (B) 248 to (C). An NPDAO sent via previous route may invalidate the previous 249 route whereas there is no way to determine whether the new DAO has 250 successfully updated the route entries on the new path. [nit] s/via previous route/via the previous route 252 3. Requirements for the NPDAO Optimization 254 3.1. Req#1: Remove messaging dependency on link to the previous parent 256 When the switching node sends the NPDAO message to the previous 257 parent, it is normal that the link to the previous parent is prone to 258 failure (thats why the node decided to switch). Therefore, it is 259 required that the route invalidation does not depend on the previous 260 link which is prone to failure. The previous link referred here 261 represents the link between the node and its previous parent (from 262 whom the node is now disassociating). [nit] s/thats/that's ... 278 4. Proposed changes to RPL signaling [minor] These changes are not "proposed" anymore. s/Proposed changes to RPL signaling/Changes to RPL signaling 280 4.1. Change in RPL route invalidation semantics 282 As described in Section 1.2, the NPDAO originates at the node 283 switching the parent and traverses upstream towards the root. In 284 order to solve the problems as mentioned in Section 2, the draft adds 285 new pro-active route invalidation message called as "Destination 286 Cleanup Object" (DCO) that originates at a common ancestor node 287 between the new and old path. The common ancestor node generates a 288 DCO in response to the change in the next-hop on receiving a regular 289 DAO with updated path sequence for the target. [nit] Maybe it's just me, but the "switching the parent" terminology doesn't sound great. By now I am not having to reread the text because my mind tends to think of a switch (not the switching action)...but maybe "changing", or even "switching to a new parent" may be better. Another option is to simply use the "target node" term defined above. Please take this comment for what it is: just a nit. [nit] s/draft/document/g [nit] s/adds new/adds a new [nit] s/called as /called /g 291 In Figure 1, when node D decides to switch the path from B to C, it 292 sends a regular DAO to node C with reachability information 293 containing target as address of D and a incremented path sequence 294 number. Node C will update the routing table based on the 295 reachability information in DAO and in turn generate another DAO with 296 the same reachability information and forward it to H. Node H also 297 follows the same procedure as Node C and forwards it to node A. When 298 node A receives the regular DAO, it finds that it already has a 299 routing table entry on behalf of the target address of node D. It 300 finds however that the next hop information for reaching node D has 301 changed i.e. the node D has decided to change the paths. In this 302 case, Node A which is the common ancestor node for node D along the 303 two paths (previous and new), should generate a DCO which traverses 304 downwards in the network. [major] I think that this illustration should be Normatively spelled out. There are details, for example due to the fact that a new DAO is created at every hop, that are not explicitly mentioned. As the DAO is sent up the tree, it is generated "with the same reachability information" -- I think this document should be explicit about the setting of the I flag, the Path Sequence to be used, etc.. [major] Is a DCO generated at every hop? IOW, A sends the DCO to G, which takes action based on it (invalidates the routes) and then sends another DCO (with the same information) to B... If so, then that needs to be explicitly specified as well. [nit] s/in DAO/in the DAO [nit] s/i.e. the node D/i.e. node D 306 4.2. Transit Information Option changes 308 Every RPL message is divided into base message fields and additional 309 Options. The base fields apply to the message as a whole and options 310 are appended to add message/use-case specific attributes. As an 311 example, a DAO message may be attributed by one or more "RPL Target" 312 options which specify the reachability information for the given 313 targets. Similarly, a Transit Information option may be associated 314 with a set of RPL Target options. [nit] A reference to rfc6550 somewhere in the paragraph would help the reader know that none of that is new...but a review. 316 The draft proposes a change in Transit Information option to contain 317 "Invalidate previous route" (I) bit. This I-bit signals the common 318 ancestor node to generate a DCO on behalf of the target node. The 319 I-bit is carried in the transit information option which augments the 320 reachability information for a given set of RPL Target(s). Transit 321 information option should be carried in the DAO message with I-bit 322 set in case route invalidation is sought for the correspondig 323 target(s). [nit] s/The draft proposes a change/This document specifies a change [nit] s/in Transit Information option/in the Transit Information Option [nit] s/contain "Invalidate/contain the "Invalidate [nit] s/. Transit information option/. The Transit Information Option [nit] s/correspondig/corresponding 325 0 1 2 3 326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type =3D 0x06 | Option Length |E|I| Flags | Path Control | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Path Sequence | Path Lifetime | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 332 | | 333 + + 334 | | 335 + Parent Address* + 336 | | 337 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 2: Updated Transit Information Option (New I flag added) [nit] Take the "*" off -- it was used in rfc6500, but has no meaning here. [nit] Indent the definition of the fields for clarity. ... 347 The common ancestor node SHOULD generate a DCO message in response to 348 this I-bit when it sees that the routing adjacencies have changed for 349 the target. I-bit governs the ownership of the DCO message in a way 350 that the target node is still in control of its own route 351 invalidation. [major] When/why would the common ancestor not generate a DCO message? IOW, why is MUST not used? I imagine that simply the nature of the LLN may prevent it from generating one (which makes the SHOULD ok)...but I'm trying to find out if there are other reasons. 353 4.3. Destination Cleanup Object (DCO) ... 383 K: The 'K' flag indicates that the recipient is expected to send a 384 DCO-ACK back. If the DCO-ACK is not received even after setting the 385 'K', an implementation may choose to retry the DCO at a later time. 386 The number of retries are implementation and deployment dependent. 387 This document recommends using retries similar to what will be set 388 for DAO-ACK handling. [minor] Why are the retries optional? If "the recipient is expected to send a DCO-ACK", then why wouldn't the sender retry? If it doesn't matter, then just don't set the flag. Given that the DCO is akin to the DAO, maybe use similar text as what is in rfc6550/=C2=A79.3... [minor] The last sentence makes a recommendation, but with no reference. rfc6550 says that the retries are implementation specific...maybe mention something like that here too. 390 D: The 'D' flag indicates that the DODAGID field is present. This 391 flag MUST be set when a local RPLInstanceID is used. 393 Flags: The 6 bits remaining unused in the Flags field are reserved 394 for future use. These bits MUST be initialized to zero by the sender 395 and MUST be ignored by the receiver. [major] Do you expect IANA to manage the assignments of those bits? ... 404 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 405 uniquely identifies a DODAG. This field is only present when the 'D' 406 flag is set. This field is typically only present when a local 407 RPLInstanceID is in use, in order to identify the DODAGID that is 408 associated with the RPLInstanceID. When a global RPLInstanceID is in 409 use, this field need not be present. Unassigned bits of the DCO Base 410 are reserved. They MUST be set to zero on transmission and MUST be 411 ignored on reception. [minor] "This field is typically only present when a local RPLInstanceID is in use..." "typically only present" is not in line with the MUST above (describing the D flag): s/typically only present/only present [major] The last couple of sentences seem to have been left behind, or at least meant for their own paragraph... I see that similar text is used in rfc6550...but I'm not sure what bits it refers to. 413 4.3.1. Secure DCO 415 A Secure DCO message follows the format in [RFC6550] figure 7, where 416 the base message format is the DCO message shown in Figure 3. [nit] s/figure 7/Figure 7 418 4.3.2. DCO Options 420 The DCO message MAY carry valid options. This specification allows 421 for the DCO message to carry the following options: 423 0x00 Pad1 424 0x01 PadN 425 0x05 RPL Target 426 0x06 Transit Information 427 0x09 RPL Target Descriptor 429 The DCO carries a Target option and an associated Transit Information 430 option with a lifetime of 0x00000000 to indicate a loss of 431 reachability to that Target. [major] Are the RPL Target and Transit Information options mandatory? If so, then that is at odds with the MAY above. [nit] s/a Target option/an RPL Target option 433 4.3.3. Path Sequence number in the DCO 435 A DCO message may contain a Path Sequence in the transit information 436 option to identify the freshness of the DCO message. The Path 437 Sequence in the DCO MUST use the same Path Sequence number present in 438 the regular DAO message when the DCO is generated in response to DAO 439 message. The DAO and DCO path sequence are picked from the same 440 sequence number set. Thus if a DCO is received by a 6LR and 441 subsequently a DAO is received with old seqeunce number, then the DAO 442 should be ignored. [minor] To make sure I'm clear: the "DCO path sequence" refers to the Path Sequence field in the Transit Information Option, right? If so, please be clear and specific. [major] The text is not clear (I asked the same thing above) if the Transit Information Option is mandatory or not in the DCO...is it? The text above says that the "DCO message may contain a Path Sequence in the transit information option". If the Transit Information Option is present, then the Path Sequence is present too...so it sounds like the Transit Information Option is not optional. [major] "Path Sequence in the DCO MUST use the same Path Sequence number present in the regular DAO message when the DCO is generated in response to DAO message" The DAO message is obviously the one that triggered the DCO... When would a DCO *not* be originated in response to a DAO? Are there other cases when the DCO can be originated? Requiring the same Path Sequence is fine...the reason for this comment is the condition ("when the DCO..."). [minor] "The DAO and DCO path sequence are picked from the same sequence number set." I'm not sure what this means -- the text before it says that the Path Sequence number "MUST use the same...present in the regular DAO message", so in reality the Path Sequence in the DCO is not picked from the same set...it's just copied. [minor] "Thus if a DCO is received by a 6LR and subsequently a DAO is received with old seqeunce number, then the DAO should be ignored." Should this behavior be Normative? IOW, do you want to use "SHOULD" instead? Maybe even "MUST". Just wondering: it seems like an important behavior.. [major] I know that the "ancestor node SHOULD generate a DCO message in response to this I-bit" (=C2=A74.2), but what prevents a (rogue) ancestor f= rom generating a DCO at any other time? The last sentence above opens the door to an attack where the ancestor can send a DCO with a Path Sequence in the future...and cause the route to be invalidated...*and* future updates to be ignored. Is this possible? [This risk, and any possible mitigation should be mentioned in the Security Considerations.] [nit] s/transit information option/Transit Information Option [nit] s/response to DAO/response to a DAO [nit] s/path sequence/Path Sequence [minor] s/old seqeunce number/old Path Sequence number 444 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 446 The DCO-ACK message may be sent as a unicast packet by a DCO 447 recipient in response to a unicast DCO message. [minor] "may be sent" Is this an optional response? =C2=A74.3 defines the= K flag in the DCO to indicate "that the recipient is expected to send a DCO-ACK back" -- that is not a Normative statement...but it seems like a waste if no ACK is sent back. ... 477 Status: Indicates the completion. Status 0 is defined as unqualified 478 acceptance in this specification. The remaining status values are 479 reserved as rejection codes. [minor] Do you expect IANA to handle the assignment of new codes? 481 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 482 uniquely identifies a DODAG. This field is only present when the 'D' 483 flag is set. This field is typically only present when a local 484 RPLInstanceID is in use, in order to identify the DODAGID that is 485 associated with the RPLInstanceID. When a global RPLInstanceID is in 486 use, this field need not be present. Unassigned bits of the DCO-Ack 487 Base are reserved. They MUST be set to zero on transmission and MUST 488 be ignored on reception. [minor] Those last 2 sentences seem to be out of place. Also, I think all the bits are accounted for above. [nit] s/DCO-Ack/DCO-ACK 490 4.3.5. Secure DCO-ACK 492 A Secure DCO-ACK message follows the format in [RFC6550] figure 7, 493 where the base message format is the DCO-ACK message shown in 494 Figure 4. [nit] s/figure 7/Figure 7 496 4.4. Other considerations 498 4.4.1. Dependent Nodes invalidation 500 Current RPL [RFC6550] does not provide a mechanism for route 501 invalidation for dependent nodes. This document allows the dependent 502 nodes invalidation. Dependent nodes will generate their respective 503 DAOs to update their paths, and the previous route invalidation for 504 those nodes should work in the similar manner described for switching 505 node. The dependent node may set the I-bit in the transit 506 information option as part of regular DAO so as to request 507 invalidation of previous route from the common ancestor node. [major] This part is underspecified. How do the dependent nodes know of the switch? Is A (Figure 1) the common ancestor node mentioned above? I found the same question being asked during WGLC, and the answer seems to be: "the dependent nodes will always set the I-flag". Is that my correct interpretation? The behavior needs to be reflected in the specification. https://mailarchive.ietf.org/arch/msg/roll/LejLNET8Hk92wPWU3Xi6OaxCujg 509 4.4.2. NPDAO and DCO in the same network 511 Even with the changed semantics, the current NPDAO mechanism in 512 [RFC6550] can still be used, for example, when the route lifetime 513 expiry of the target happens or when the node simply decides to 514 gracefully terminate the RPL session on graceful node shutdown. 515 Moreover a deployment can have a mix of nodes supporting the proposed 516 DCO and the existing NPDAO mechanism. [major] This text sounds as if the NPDAO is made optional. Is that the intent? rfc6550 says that "when a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message". If the behavior from rfc6550 is changing, then this document should be more specific and Normative about it. 518 4.4.3. DCO with multiple preferred parents 520 [RFC6550] allows a node to select multiple preferred parents for 521 route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs 522 generated at the same time for the same Target MUST be sent with the 523 same Path Sequence in the Transit Information". Thus a DAO message 524 with the same path sequence MUST be sent to all the parents. 525 Subsequently when route invalidation has to be initiated, RPL 526 mentions that an NPDAO must be initiated with updated path sequence 527 to all the routes to be invalidated. [major] "Thus a DAO message with the same path sequence MUST be sent to all the parents." This sentence seems to just be a repetition of what the quoted text says...but making it Normative to this document. I don't see the point since the behavior is already Normative. [major] "RPL mentions that an NPDAO must be initiated with updated path sequence to all the routes to be invalidated." I couldn't find a place in rfc6550 that says that. 529 With DCO, the Target node itself does not initiate the route 530 invalidation and it is left to the common ancestor node. A common 531 ancestor node when it discovers an updated DAO from a new next-hop, 532 it initiates a DCO. With multiple preferred parents, this handling 533 does not change. But in this case it is recommended that an 534 implementation initiates a DCO after a time period such that the 535 common ancestor node may receive updated DAOs from all possible next- 536 hops. This will help to reduce DCO control overhead i.e., the common 537 ancestor can wait for updated DAOs from all possible directions 538 before initiating a DCO for route invalidation. The time period for 539 initiating a DCO could be based on the depth of the network. After 540 timeout, the DCO needs to be generated for all the next-hops for whom 541 the route invalidation needs to be done. [major] "With multiple preferred parents...it is recommended that an implementation initiates a DCO after a time period..." How does the ancestor know if there are multiple parents or not? Should this recommendation be generic? How long is should the ancestor wait? ... 548 6. IANA Considerations 550 IANA is requested to allocate new ICMPv6 RPL control codes in RPL 551 [RFC6550] for DCO and DCO-ACK messages. [major] The name of the registry is "RPL Control Codes". s//IANA is requested to allocate new codes for the DCO and DCO-ACK messages from the RPL Control Codes registry. 553 +------+---------------------------------------------+--------------+ 554 | Code | Description | Reference | 555 +------+---------------------------------------------+--------------+ 556 | 0x04 | Destination Cleanup Object | This | 557 | | | document | 558 | 0x05 | Destination Cleanup Object Acknowledgement | This | 559 | | | document | 560 | 0x84 | Secure Destination Cleanup Object | This | 561 | | | document | 562 | 0x85 | Secure Destination Cleanup Object | This | 563 | | Acknowledgement | document | 564 +------+---------------------------------------------+--------------+ [major] The values suggested in this table are already assigned. I would suggest you simply call the codes TBD1-TBD4. Note that the corresponding figures must also be updated. https://www.iana.org/assignments/rpl/rpl.xhtml#control-codes 566 IANA is requested to allocate bit 18 in the Transit Information 567 Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route 568 'I' flag. [major] The registry is called "Transit Information Option Flags"...and the requested assignment corresponds to bit 1. s//IANA is requested to allocate bit 1 from the Transit Information Option Flags registry the I-bit (Section 4.2). 570 7. Security Considerations [major] This section mostly points at rfc6550 (which is ok), but it doesn't say anything about vulnerabilities (if any) that this specification may be introducing...or why it doesn't. [See my related comment in =C2=A74.3.3.] I would like to see (perhaps after the current text) something along the lines of "This document introduces the ability to do abc. It doesn't introduce any new vulnerabilities becasue... OR ... These are the new vulnerabilities and this is how they can be mitigated...or why they are not really of concern..." ... 609 Appendix A. Example Messaging 611 A.1. Example DCO Messaging 613 In Figure 1, node (D) switches its parent from (B) to (C). The 614 sequence of actions is as follows: 616 1. Node D switches its parent from node B to node C 617 2. D sends a regular DAO(tgt=3DD,pathseq=3Dx+1,I_flag=3D1) in the up= dated 618 path to C [minor] The notation "DAO/DCO()" should be explained somewhere...and should be consistent throughout (it changes below). 619 3. C checks for routing entry on behalf of D, since it cannot find 620 an entry on behalf of D it creates a new routing entry and 621 forwards the reachability information of the target D to H in a 622 DAO. [nit] s/for routing entry/for a routing entry/g ... 637 7. Similarly, B processes the DCO by invalidating the routing entry 638 of target D and forwards the (un)reachability information 639 downstream to D. 641 8. D ignores the DCO since the target is itself. [?] Just curious: why will B even propagate the DCO to D? B already knows that the target is D... 642 9. The propagation of the DCO will stop at any node where the node 643 does not have an routing information associated with the target. 644 If the routing information is present and the pathseq associated 645 is not older, then still the DCO is dropped. [major] This paragraph contains information that hasn't been specified elsewhere in the document. It must be. [minor] This sentence is awkwardly worded: "If the routing information is present and the pathseq associated is not older, then still the DCO is dropped." Perhaps s/the pathseq associated is not older/its Path Sequence is higher 647 A.2. Example DCO Messaging with multiple preferred parents ... 675 2. (N32) sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N22). (N33) als= o 676 sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N22). (N22) learns mu= ltiple 677 routes for the same destination (N41) through multiple next-hops. 678 The route table at N22 should contain (Dst,NextHop,PS): { 679 (N41,N32,x), (N41,N33,x) }. 680 3. (N22) sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N11). [major] The I_flag is set...but (N22) doesn't originate a DCO... I think the flag should not be set at this point. ... 687 7. (N32) sends DAO(tgt=3DN41,PS=3Dx+1,I_flag=3D1) to (N22). (N22) h= as 688 multiple routes to destination (N41). It sees that a new path 689 sequence for Target=3DN41 is received and thus it waits for pre- 690 determined time period to invalidate another route 691 {(N41),(N33),x}. After time period, (N22) sends 692 DCO(tgt=3DN41,PS=3Dx+1) to (N33). [minor] The example is incomplete: (N33) sends a DCO to (N41)... --000000000000abf257058647a36b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors:

Here's my re= view of this document.=C2=A0 The first part of the document mostly resulted= in nits, but (starting in =C2=A74) I then have some major comments.=C2=A0 = I'll wait for those to be addressed before starting the IETF Last Call.=

The mos= t significant issue is the fact that the suggested values for the DCO are a= lready assigned!=C2=A0 The Shepherd's writeup says that a pilot impleme= ntation exists -- which, I assume uses the suggested values.=C2=A0 What is = the impact on existing implementations?

=
Thanks!

=
Alvaro.

=
[Line numbers come from idnits.]

...
14 Abstract

16 =C2=A0 This document describes the problems associated with NPDAO messag= ing
17 =C2=A0 used in RPL for route invalidation and= signaling changes to improve
18 =C2=A0 route invalid= ation efficiency.

[nit] Please expand NPDAO...you may have to do it completely (inc= luding DAO).

[nit] RPL should be expanded in the Abstract as well...


...
91 1.=C2=A0 Introduction

93 =C2=A0 RPL [RFC6550] (Rou= ting Protocol for Low power and lossy networks)
94 =C2= =A0 specifies a proactive distance-vector based routing scheme.=C2=A0 RPL h= as
95 =C2=A0 an optional messaging in the form of DAO = (Destination Advertisement
96 =C2=A0 Object) messages = using which the 6LBR (6Lo Border Router) and 6LR
97 = =C2=A0 (6Lo Router) can learn route towards the downstream nodes.=C2=A0 In<= /div>
98 =C2=A0 storing mode, DAO messages would result in r= outing entries been
99 =C2=A0 created on all intermedi= ate 6LRs from the node's parent all the way
100 = =C2=A0 towards the 6LBR.

[nit] s/messages using which the 6LBR (6Lo Border Router) = and 6LR (6Lo Router) can learn route/messages, which the 6LBR (6Lo Border R= outer) and 6LR (6Lo Router) can use to learn a route

[nit] s/routing entries been c= reated/routing entries being created

102 =C2=A0 RPL allows use of No-Path DAO (NPDAO) messagi= ng to invalidate a
103 =C2=A0 routing path correspondi= ng to the given target, thus releasing
104 =C2=A0 reso= urces utilized on that path.=C2=A0 A NPDAO is a DAO message with route
105 =C2=A0 lifetime of zero, originates at the target node= and always flows
106 =C2=A0 upstream towards the 6LBR= .=C2=A0 This document explains the problems
= 107 =C2=A0= associated with the current use of NPDAO messaging and also discusses
108 =C2=A0 the requirements for an optimized route invalid= ation messaging
109 =C2=A0 scheme.=C2=A0 Further a new= pro-active route invalidation message called
110 =C2= =A0 as "Destination Cleanup Object (DCO)" is specified which fulf= ills
111 =C2=A0 requirements of an optimized route inv= alidation messaging.

[nit] s/allows use of/allows the use of

[nit] s/"Destination Clea= nup Object (DCO)"/"Destination Cleanup Object" (DCO)


...
117 1.1.=C2=A0 Requirements La= nguage and Terminology

119 =C2=A0 The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
120 =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
121 =C2=A0 document are to be interpreted as described in RFC 2119 [= RFC2119].

[major] Please use the template in rfc8174.

123 =C2=A0 6LR: 6LoWPAN Router.=C2=A0 This is a= n intermediate 6lowpan router which
124 =C2=A0 allows = traffic routing through itself in a multihop 6lo network.

[nit] Please be consist= ent: 6LoWPAN vs 6lowpan

[nit] You may have to define 6lo.

[minor] In this case, the definit= ion includes the name: "6LoWPAN Router...is an intermediate 6lowpan ro= uter..."

[nit] In general, simply pointing to rfc6550 (or other documents wher= e the terms are already defined) may be easier than redefining.


...
161 1.2.=C2=A0 Current NPDAO messa= ging

163= =C2=A0 RP= L uses NPDAO messaging in the storing mode so that the node
164 =C2=A0 changing it routing adjacencies can invalidate the previou= s route.
165 =C2=A0 This is needed so that nodes along= previous path can release any
166 =C2=A0 resources (s= uch as the routing entry) it maintains on behalf of
167 =C2=A0 target node.

[nit] s/along previous path/along the previous path


...
200 1.3.=C2=A0 Why NPDAO is im= portant?

202 =C2= =A0 Nodes in LLNs may be resource constrained.=C2=A0 There is limited memor= y
203 =C2=A0 available and routing entry records are o= ne of the primary elements
204 =C2=A0 occupying dynami= c memory in the nodes.=C2=A0 Route invalidation helps 6LR
205 =C2=A0 nodes to decide which entries could be discarded to better= achieve
206 =C2=A0 resource utilization.=C2=A0 Thus i= t becomes necessary to have efficient
207 =C2=A0 route= invalidation mechanism.=C2=A0 Also note that a single parent switch
<= div style=3D"margin:0px">208 =C2=A0 may result in a "sub-tree" switching fr= om one parent to another.
209 =C2=A0 Thus the route in= validation needs to be done on behalf of the sub-
210 = =C2=A0 tree and not the switching node alone.=C2=A0 In the above example, w= hen
211 =C2=A0 Node (D) switches parent, the route up= dates needs to be done for the
212 =C2=A0 routing tabl= es entries of (C),(H),(A),(G), and (B) with destination
213 =C2=A0 (D),(E) and (F).=C2=A0 Without efficient route invalidation, a= 6LR may
214 =C2=A0 have to hold a lot of stale route = entries.

[nit] s/to have efficient/to have an efficient


...
225 2.2.=C2=A0 Invalidate routes of dependent node= s

227 =C2=A0 RPL d= oes not specify how route invalidation will work for dependent
228 =C2=A0 nodes rooted at switching node, resulting in stale rout= ing entries of
229 =C2=A0 the dependent nodes.=C2=A0 T= he only way for 6LR to invalidate the route
= 230 =C2=A0= entries for dependent nodes would be to use route lifetime expiry
231 =C2=A0 which could be substantially high for LLNs.

[nit] s/rooted = at switching node/rooted at the switching node


= ...
239 2.3.=C2=A0 Possible route downtime caused by a= sync operation of NPDAO and DAO
...
247 =C2=A0 In the example topology, consider Node (D) switches= from parent (B)
248 =C2=A0 to (C).=C2=A0 An NPDAO sen= t via previous route may invalidate the previous
249 = =C2=A0 route whereas there is no way to determine whether the new DAO has
250 =C2=A0 successfully updated the route entries on th= e new path.

[nit] s/via previous route/via the previous route

252 3.=C2=A0 Requirements for the NPDAO = Optimization

254 3.= 1.=C2=A0 Req#1: Remove messaging dependency on link to the previous parent<= /div>

256 =C2=A0 When th= e switching node sends the NPDAO message to the previous
257 <= /span> =C2=A0 parent, it is normal that the link to the previous parent is = prone to
258 =C2=A0 failure (thats why the node decide= d to switch).=C2=A0 Therefore, it is
259 =C2=A0 requir= ed that the route invalidation does not depend on the previous
260 =C2=A0 link which is prone to failure.=C2=A0 The previous link= referred here
261 =C2=A0 represents the link between = the node and its previous parent (from
262 =C2=A0 whom= the node is now disassociating).

=
[nit] s/thats/that's


...
278 4.=C2=A0 Proposed changes to RPL signaling<= /div>

[minor] = These changes are not "proposed" anymore. =C2=A0s/Proposed change= s to RPL signaling/Changes to RPL signaling
=
280 4.1.=C2=A0 Change in RPL route invalidation se= mantics

= 282 =C2=A0= As described in Section 1.2, the NPDAO originates at the node
283 =C2=A0 switching the parent and traverses upstream towards the= root.=C2=A0 In
284 =C2=A0 order to solve the problems= as mentioned in Section 2, the draft adds
2= 85 =C2=A0 = new pro-active route invalidation message called as "Destination
=
286 =C2=A0 Cleanup Object" (DCO) that originates at a = common ancestor node
287 =C2=A0 between the new and ol= d path.=C2=A0 The common ancestor node generates a
288 = =C2=A0 DCO in response to the change in the next-hop on receiving a regula= r
289 =C2=A0 DAO with updated path sequence for the ta= rget.

[n= it] Maybe it's just me, but the "switching the parent" termin= ology doesn't sound great.=C2=A0 By now I am not having to reread the t= ext because my mind tends to think of a switch (not the switching action)..= .but maybe "changing", or even "switching to a new parent&qu= ot; may be better.=C2=A0 Another option is to simply use the "target n= ode" term defined above.=C2=A0 Please take this comment for what it is= : just a nit.

[nit] s/draft/document/g

[nit] s/adds new/adds a new

[nit] s/called as /called /g

291 =C2=A0 In Figure = 1, when node D decides to switch the path from B to C, it
292 =C2=A0 sends a regular DAO to node C with reachability informatio= n
293 =C2=A0 containing target as address of D and a i= ncremented path sequence
294 =C2=A0 number.=C2=A0 Node= C will update the routing table based on the
295 =C2= =A0 reachability information in DAO and in turn generate another DAO with
296 =C2=A0 the same reachability information and forwar= d it to H.=C2=A0 Node H also
297 =C2=A0 follows the s= ame procedure as Node C and forwards it to node A.=C2=A0 When
298 =C2=A0 node A receives the regular DAO, it finds that it alread= y has a
299 =C2=A0 routing table entry on behalf of th= e target address of node D.=C2=A0 It
300 =C2=A0 finds = however that the next hop information for reaching node D has
301 =C2=A0 changed i.e. the node D has decided to change the paths.= =C2=A0 In this
302 =C2=A0 case, Node A which is the co= mmon ancestor node for node D along the
303<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 two= paths (previous and new), should generate a DCO which traverses
304 =C2=A0 downwards in the network.

[major] I think that this illustrat= ion should be Normatively spelled out.=C2=A0 There are details, for example= due to the fact that a new DAO is created at every hop, that are not expli= citly mentioned.=C2=A0 As the DAO is sent up the tree, it is generated &quo= t;with the same reachability information" -- I think this document sho= uld be explicit about the setting of the I flag, the Path Sequence to be us= ed, etc..

[major] Is a DCO generated at every hop?=C2=A0 IOW, A sends the DCO to G,= which takes action based on it (invalidates the routes) and then sends ano= ther DCO (with the same information) to B...=C2=A0 If so, then that needs t= o be explicitly specified as well.

[nit] s/in DAO/in the DAO

[nit] s/i.e. the node D/i.e. n= ode D

30= 6 4.2.=C2= =A0 Transit Information Option changes

<= /div>
308 =C2=A0 Every RPL message is divided into base mess= age fields and additional
309 =C2=A0 Options.=C2=A0 Th= e base fields apply to the message as a whole and options
310 =C2=A0 are appended to add message/use-case specific attributes.= =C2=A0 As an
311 =C2=A0 example, a DAO message may be = attributed by one or more "RPL Target"
312 = =C2=A0 options which specify the reachability information for the given
313 =C2=A0 targets.=C2=A0 Similarly, a Transit Informatio= n option may be associated
314 =C2=A0 with a set of RP= L Target options.

[nit] A reference to rfc6550 somewhere in the paragraph would hel= p the reader know that none of that is new...but a review.

316 =C2=A0 The draft proposes a c= hange in Transit Information option to contain
317 =C2= =A0 "Invalidate previous route" (I) bit.=C2=A0 This I-bit signals= the common
318 =C2=A0 ancestor node to generate a DCO= on behalf of the target node.=C2=A0 The
319= =C2=A0 I-= bit is carried in the transit information option which augments the
320 =C2=A0 reachability information for a given set of RPL Ta= rget(s).=C2=A0 Transit
321 =C2=A0 information option s= hould be carried in the DAO message with I-bit
322 =C2= =A0 set in case route invalidation is sought for the correspondig
323 =C2=A0 target(s).

=
[nit] s/The draft proposes a change/This document= specifies a change

[nit] s/in Transit Information option/in the Transit Informatio= n Option

[nit] s/contain "Invalidate/contain the "Invalidate

[nit] s/.=C2=A0 Tran= sit information option/.=C2=A0 The Transit Information Option

[nit] s/correspondig/= corresponding

325 = =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
326 =C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1
327 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
328 =C2= =A0 =C2=A0 | =C2=A0 Type =3D 0x06 | Option Length |E|I| =C2=A0Flags =C2=A0 = =C2=A0| Path Control =C2=A0|
329 =C2=A0 =C2=A0 +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
330 =C2=A0 =C2=A0 | Path Sequence | Path Lifetime | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
331 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
332 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
333 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
334 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
335 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Parent Ad= dress* =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+
336 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
337 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
338 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
339 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

341 = =C2=A0 =C2=A0 =C2=A0Figure 2: Updated Transit Information Option (New I fla= g added)

[nit] Take the "*" off -- it was used in rfc6500, but has no mea= ning here.

[nit] Indent the definition of the fields for clarity.


...
347 =C2=A0 The common ancestor node S= HOULD generate a DCO message in response to
= 348 =C2=A0= this I-bit when it sees that the routing adjacencies have changed for
349 =C2=A0 the target.=C2=A0 I-bit governs the ownership o= f the DCO message in a way
350 =C2=A0 that the target = node is still in control of its own route
35= 1 =C2=A0 i= nvalidation.

[major] When/why would the common ancestor not generate a DCO message?= =C2=A0 IOW, why is MUST not used?=C2=A0 I imagine that simply the nature of= the LLN may prevent it from generating one (which makes the SHOULD ok)...b= ut I'm trying to find out if there are other reasons.

353 4.3.=C2=A0 Destination Cleanup= Object (DCO)
...
383 = =C2=A0 K: The 'K' flag indicates that the recipient is expected to = send a
384 =C2=A0 DCO-ACK back.=C2=A0 If the DCO-ACK i= s not received even after setting the
385 =C2=A0 '= K', an implementation may choose to retry the DCO at a later time.
386 =C2=A0 The number of retries are implementation and de= ployment dependent.
387 =C2=A0 This document recommend= s using retries similar to what will be set
= 388 =C2=A0= for DAO-ACK handling.

[minor] Why are the retries optional?=C2=A0 If "the re= cipient is expected to send a DCO-ACK", then why wouldn't the send= er retry?=C2=A0 If it doesn't matter, then just don't set the flag.= =C2=A0 Given that the DCO is akin to the DAO, maybe use similar text as wha= t is in rfc6550/=C2=A79.3...

[minor] The last sentence makes a recommendation, but = with no reference. =C2=A0rfc6550 says that the retries are implementation s= pecific...maybe mention something like that here too.

390 =C2=A0 D: The 'D' flag indi= cates that the DODAGID field is present.=C2=A0 This
391 =C2=A0 flag MUST be set when a local RPLInstanceID is used.

393 =C2=A0 Flags: The 6 bits re= maining unused in the Flags field are reserved
394 =C2= =A0 for future use.=C2=A0 These bits MUST be initialized to zero by the sen= der
395 =C2=A0 and MUST be ignored by the receiver.

[major] D= o you expect IANA to manage the assignments of those bits?


...
404 =C2=A0 DODAGID (optional): 128-bi= t unsigned integer set by a DODAG root that
= 405 =C2=A0= uniquely identifies a DODAG.=C2=A0 This field is only present when the = 9;D'
406 =C2=A0 flag is set.=C2=A0 This field is t= ypically only present when a local
407 =C2=A0 RPLInsta= nceID is in use, in order to identify the DODAGID that is
408 =C2=A0 associated with the RPLInstanceID.=C2=A0 When a global RPL= InstanceID is in
409 =C2=A0 use, this field need not b= e present.=C2=A0 Unassigned bits of the DCO Base
410 = =C2=A0 are reserved.=C2=A0 They MUST be set to zero on transmission and MUS= T be
411 =C2=A0 ignored on reception.

[minor] "This fiel= d is typically only present when a local RPLInstanceID is in use..." = =C2=A0"typically only present" is not in line with the MUST above= (describing the D flag): s/typically only present/only present

[major] The last co= uple of sentences seem to have been left behind, or at least meant for thei= r own paragraph... I see that similar text is used in rfc6550...but I'm= not sure what bits it refers to.

=
413 4.3.1.=C2=A0 Secure DCO
<= br>
415 =C2=A0 A Secure DCO message follows the forma= t in [RFC6550] figure 7, where
416 =C2=A0 the base mes= sage format is the DCO message shown in Figure 3.

[nit] s/figure 7/Figure 7

418 4.3.2.=C2=A0 DCO Opti= ons

420<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 The= DCO message MAY carry valid options.=C2=A0 This specification allows
=
421 =C2=A0 for the DCO message to carry the following optio= ns:

423<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 =C2= =A0 =C2=A00x00 Pad1
424 =C2=A0 =C2=A0 =C2=A00x01 PadN<= /div>
425 =C2=A0 =C2=A0 =C2=A00x05 RPL Target
426 =C2=A0 =C2=A0 =C2=A00x06 Transit Information
427 =C2=A0 =C2=A0 =C2=A00x09 RPL Target Descriptor

429 =C2=A0 The DCO carries a Target opti= on and an associated Transit Information
430= =C2=A0 op= tion with a lifetime of 0x00000000 to indicate a loss of
431 <= /span> =C2=A0 reachability to that Target.
<= br>
[major] Are the RPL Target and Transit I= nformation options mandatory?=C2=A0 If so, then that is at odds with the MA= Y above.

[nit] s/a Target option/an RPL Target option

433 4.3.3.=C2=A0 Path Sequence number in the DCO=

435 =C2=A0 A DCO = message may contain a Path Sequence in the transit information
436 =C2=A0 option to identify the freshness of the DCO message.=C2= =A0 The Path
437 =C2=A0 Sequence in the DCO MUST use t= he same Path Sequence number present in
438<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 the= regular DAO message when the DCO is generated in response to DAO
439 =C2=A0 message.=C2=A0 The DAO and DCO path sequence are pic= ked from the same
440 =C2=A0 sequence number set.=C2= =A0 Thus if a DCO is received by a 6LR and
4= 41 =C2=A0 = subsequently a DAO is received with old seqeunce number, then the DAO
=
442 =C2=A0 should be ignored.

[minor] To make sure I'm clear: t= he "DCO path sequence" refers to the Path Sequence field in the T= ransit Information Option, right?=C2=A0 If so, please be clear and specific= .

[major= ] The text is not clear (I asked the same thing above) if the Transit Infor= mation Option is mandatory or not in the DCO...is it?=C2=A0 The text above = says that the "DCO message may contain a Path Sequence in the transit = information option".=C2=A0 If the Transit Information Option is presen= t, then the Path Sequence is present too...so it sounds like the Transit In= formation Option is not optional.

=
[major] "Path Sequence in the DCO MUST use t= he same Path Sequence number present in the regular DAO message when the DC= O is generated in response to DAO message" =C2=A0The DAO message is ob= viously the one that triggered the DCO...=C2=A0 When would a DCO *not* be o= riginated in response to a DAO?=C2=A0 Are there other cases when the DCO ca= n be originated?=C2=A0 Requiring the same Path Sequence is fine...the reaso= n for this comment is the condition ("when the DCO...").

[minor] "Th= e DAO and DCO path sequence are picked from the same sequence number set.&q= uot; =C2=A0I'm not sure what this means -- the text before it says that= the Path Sequence number "MUST use the same...present in the regular = DAO message", so in reality the Path Sequence in the DCO is not picked= from the same set...it's just copied.
<= br>
[minor] "Thus if a DCO is received = by a 6LR and subsequently a DAO is received with old seqeunce number, then = the DAO should be ignored." =C2=A0Should this behavior be Normative?= =C2=A0 IOW, do you want to use "SHOULD" instead?=C2=A0 Maybe even= "MUST".=C2=A0 Just wondering: it seems like an important behavio= r..

[maj= or] I know that the "ancestor node SHOULD generate a DCO message in re= sponse to this I-bit" (=C2=A74.2), but what prevents a (rogue) ancesto= r from generating a DCO at any other time?=C2=A0 The last sentence above op= ens the door to an attack where the ancestor can send a DCO with a Path Seq= uence in the future...and cause the route to be invalidated...*and* future = updates to be ignored.=C2=A0 Is this possible? =C2=A0[This risk, and any po= ssible mitigation should be mentioned in the Security Considerations.]

[nit] s/tran= sit information option/Transit Information Option

[nit] s/response to DAO/response = to a DAO

[nit] s/path sequence/Path Sequence

[minor] s/old seqeunce number/old Path Sequenc= e number

444 4.3.4.= =C2=A0 Destination Cleanup Option Acknowledgement (DCO-ACK)

446 =C2=A0 The DCO-ACK message ma= y be sent as a unicast packet by a DCO
447 =C2=A0 reci= pient in response to a unicast DCO message.
=
[minor] "may be sent" =C2=A0I= s this an optional response? =C2=A0=C2=A74.3 defines the K flag in the DCO = to indicate "that the recipient is expected to send a DCO-ACK back&quo= t; -- that is not a Normative statement...but it seems like a waste if no A= CK is sent back.


...
477 = =C2=A0 Status: Indicates the completion.=C2=A0 Status 0 is defined as unqua= lified
478 =C2=A0 acceptance in this specification.=C2= =A0 The remaining status values are
479 =C2=A0 reserve= d as rejection codes.

[minor] Do you expect IANA to handle the assignment of new = codes?

4= 81 =C2=A0 = DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
=
482 =C2=A0 uniquely identifies a DODAG.=C2=A0 This field is= only present when the 'D'
483 =C2=A0 flag is = set.=C2=A0 This field is typically only present when a local
484 =C2=A0 RPLInstanceID is in use, in order to identify the DODAGID= that is
485 =C2=A0 associated with the RPLInstanceID.= =C2=A0 When a global RPLInstanceID is in
486= =C2=A0 us= e, this field need not be present.=C2=A0 Unassigned bits of the DCO-Ack
487 =C2=A0 Base are reserved.=C2=A0 They MUST be set to z= ero on transmission and MUST
488 =C2=A0 be ignored on= reception.

[minor] Those last 2 sentences seem to be out of place.=C2=A0 Also, I t= hink all the bits are accounted for above.
<= br>
[nit] s/DCO-Ack/DCO-ACK

490 4.3.5.=C2=A0 Secure DCO-ACK

492 =C2=A0 A Secure = DCO-ACK message follows the format in [RFC6550] figure 7,
493 =C2=A0 where the base message format is the DCO-ACK message shown= in
494 =C2=A0 Figure 4.

[nit] s/figure 7/Figure 7

496 4.4.=C2=A0 Other consider= ations

4= 98 4.4.1.= =C2=A0 Dependent Nodes invalidation

500 =C2=A0 Current RPL [RFC6550] does not provide a mecha= nism for route
501 =C2=A0 invalidation for dependent n= odes.=C2=A0 This document allows the dependent
502 =C2= =A0 nodes invalidation.=C2=A0 Dependent nodes will generate their respectiv= e
503 =C2=A0 DAOs to update their paths, and the previ= ous route invalidation for
504 =C2=A0 those nodes shou= ld work in the similar manner described for switching
505 =C2=A0 node.=C2=A0 The dependent node may set the I-bit in the transit<= /div>
506 =C2=A0 information option as part of regular DAO s= o as to request
507 =C2=A0 invalidation of previous ro= ute from the common ancestor node.

[major] This part is underspecified.=C2=A0 How d= o the dependent nodes know of the switch?=C2=A0 Is A (Figure 1) the common = ancestor node mentioned above? =C2=A0

I found the same question being asked during = WGLC, and the answer seems to be: "the dependent nodes will always set= the I-flag".=C2=A0 Is that my correct interpretation?=C2=A0 The behav= ior needs to be reflected in the specification.


509 4.4.2.=C2=A0 NPDAO and DCO in the sa= me network

511 =C2= =A0 Even with the changed semantics, the current NPDAO mechanism in
512 =C2=A0 [RFC6550] can still be used, for example, when the= route lifetime
513 =C2=A0 expiry of the target happen= s or when the node simply decides to
514 =C2=A0 gracef= ully terminate the RPL session on graceful node shutdown.
515 =C2=A0 Moreover a deployment can have a mix of nodes supporting t= he proposed
516 =C2=A0 DCO and the existing NPDAO mech= anism.

[= major] This text sounds as if the NPDAO is made optional. Is that the inten= t? =C2=A0rfc6550 says that "when a node removes a node from its DAO pa= rent set, it SHOULD send a No-Path DAO message".=C2=A0 If the behavior= from rfc6550 is changing, then this document should be more specific and N= ormative about it.

518 4.4.3.=C2=A0 DCO with multiple preferred parents

520 =C2=A0 [RFC6550] allows a node to se= lect multiple preferred parents for
521 =C2=A0 route e= stablishment.=C2=A0 Section 9.2.1 of [RFC6550] specifies, "All DAOs
522 =C2=A0 generated at the same time for the same Targe= t MUST be sent with the
523 =C2=A0 same Path Sequence = in the Transit Information".=C2=A0 Thus a DAO message
524 =C2=A0 with the same path sequence MUST be sent to all the parent= s.
525 =C2=A0 Subsequently when route invalidation h= as to be initiated, RPL
526 =C2=A0 mentions that an NP= DAO must be initiated with updated path sequence
527 = =C2=A0 to all the routes to be invalidated.
=
[major] "Thus a DAO message with t= he same path sequence MUST be sent to all the parents." =C2=A0This sen= tence seems to just be a repetition of what the quoted text says...but maki= ng it Normative to this document.=C2=A0 I don't see the point since the= behavior is already Normative.

[major] "RPL mentions that an NPDAO must be in= itiated with updated path sequence to all the routes to be invalidated.&quo= t; I couldn't find a place in rfc6550 that says that.

529 =C2=A0 With DCO, the Target n= ode itself does not initiate the route
530 =C2=A0 inva= lidation and it is left to the common ancestor node.=C2=A0 A common
531 =C2=A0 ancestor node when it discovers an updated DAO fro= m a new next-hop,
532 =C2=A0 it initiates a DCO.=C2=A0= With multiple preferred parents, this handling
533 = =C2=A0 does not change.=C2=A0 But in this case it is recommended that an
534 =C2=A0 implementation initiates a DCO after a time p= eriod such that the
535 =C2=A0 common ancestor node ma= y receive updated DAOs from all possible next-
536 =C2= =A0 hops.=C2=A0 This will help to reduce DCO control overhead i.e., the com= mon
537 =C2=A0 ancestor can wait for updated DAOs fro= m all possible directions
538 =C2=A0 before initiating= a DCO for route invalidation.=C2=A0 The time period for
539 <= /span> =C2=A0 initiating a DCO could be based on the depth of the network.= =C2=A0 After
540 =C2=A0 timeout, the DCO needs to be g= enerated for all the next-hops for whom
541<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 the= route invalidation needs to be done.

[major] "With multiple preferred parents= ...it is recommended that an implementation initiates a DCO after a time pe= riod..." =C2=A0How does the ancestor know if there are multiple parent= s or not?=C2=A0 Should this recommendation be generic?=C2=A0 How long is sh= ould the ancestor wait?


...
548 6.=C2=A0 IANA Considerations

=
550 =C2=A0 IANA is requested to allocate new ICMPv6 RPL con= trol codes in RPL
551 =C2=A0 [RFC6550] for DCO and DCO= -ACK messages.

[major] The name of the registry is "RPL Control Codes".

s//IANA i= s requested to allocate new codes for the DCO and DCO-ACK messages from the= RPL Control Codes registry.

553 =C2=A0 +------+---------------------------------------------= +--------------+
554 =C2=A0 | Code | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Description =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Reference =C2=A0 |
555 =C2=A0 +------+---------------------------------------------+----= ----------+
556 =C2=A0 | 0x04 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Destination Cleanup Object =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 This =C2=A0 =C2=A0 |
557 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 document =C2=A0 |
558 = =C2=A0 | 0x05 | =C2=A0Destination Cleanup Object Acknowledgement | =C2=A0 = =C2=A0 This =C2=A0 =C2=A0 |
559 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 document =C2=A0 |
560 =C2= =A0 | 0x84 | =C2=A0 =C2=A0 =C2=A0Secure Destination Cleanup Object =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 This =C2=A0 =C2=A0 |
561 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 document =C2=A0 |
562 =C2=A0 | 0x85 | =C2=A0 =C2=A0 =C2=A0Secure Destination Clea= nup Object =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 This =C2=A0 =C2=A0 |
563 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Acknowledgement =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | =C2=A0 document =C2=A0 |
56= 4 =C2=A0 += ------+---------------------------------------------+--------------+
<= div style=3D"margin:0px">
[major] The va= lues suggested in this table are already assigned.=C2=A0 I would suggest yo= u simply call the codes TBD1-TBD4.=C2=A0 Note that the corresponding figure= s must also be updated.



=

s//IANA is re= quested to allocate bit 1 from the Transit Information Option Flags registr= y the I-bit (Section 4.2).


570 7.=C2=A0 Security Considera= tions

[m= ajor] This section mostly points at rfc6550 (which is ok), but it doesn'= ;t say anything about vulnerabilities (if any) that this specification may = be introducing...or why it doesn't. [See my related comment in =C2=A74.= 3.3.]

I = would like to see (perhaps after the current text) something along the line= s of "This document introduces the ability to do abc.=C2=A0 It doesn&#= 39;t introduce any new vulnerabilities becasue...=C2=A0 OR ... These are th= e new vulnerabilities and this is how they can be mitigated...or why they a= re not really of concern..."

=

...
609 Appendix A.=C2=A0 Example Messaging

<= div style=3D"margin:0px">


621 =C2=A0 =C2=A0 = =C2=A0 forwards the reachability information of the target D to H in a
622 =C2=A0 =C2=A0 =C2=A0 DAO.

[nit] s/for routing entry/for a rout= ing entry/g


...
= 637 =C2=A0= 7.=C2=A0 Similarly, B processes the DCO by invalidating the routing entry<= /div>
638 =C2=A0 =C2=A0 =C2=A0 of target D and forwards the = (un)reachability information
639 =C2=A0 =C2=A0 =C2=A0= downstream to D.

641 =C2=A0 8.=C2=A0 D ignores the DCO since the target is itself.

[?] Just curious:= why will B even propagate the DCO to D?=C2=A0 B already knows that the tar= get is D...

642 = =C2=A0 9.=C2=A0 The propagation of the DCO will stop at any node where the = node
643 =C2=A0 =C2=A0 =C2=A0 does not have an routing= information associated with the target.
644= =C2=A0 = =C2=A0 =C2=A0 If the routing information is present and the pathseq associa= ted
645 =C2=A0 =C2=A0 =C2=A0 is not older, then still= the DCO is dropped.

[major] This paragraph contains information that hasn't be= en specified elsewhere in the document.=C2=A0 It must be.

[minor] This sentence i= s awkwardly worded: "If the routing information is present and the pat= hseq associated is not older, then still the DCO is dropped." =C2=A0Pe= rhaps s/the pathseq associated is not older/its Path Sequence is higher

647 A.2.=C2=A0 Example= DCO Messaging with multiple preferred parents
...
675 =C2=A0 2. =C2=A0(N32) sends DAO(tgt=3DN41,P= S=3Dx,I_flag=3D1) to (N22). =C2=A0(N33) also
676 =C2= =A0 =C2=A0 =C2=A0 sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N22). =C2=A0(N= 22) learns multiple
677 =C2=A0 =C2=A0 =C2=A0 routes fo= r the same destination (N41) through multiple next-hops.
678 <= /span> =C2=A0 =C2=A0 =C2=A0 The route table at N22 should contain (Dst,Next= Hop,PS): {
679 =C2=A0 =C2=A0 =C2=A0 (N41,N32,x), (N41,= N33,x) }.
680 =C2=A0 3. =C2=A0(N22) sends DAO(tgt=3DN4= 1,PS=3Dx,I_flag=3D1) to (N11).

[major] The I_flag is set...but (N22) doesn't or= iginate a DCO...=C2=A0 I think the flag should not be set at this point.

...
<= div style=3D"margin:0px">687 =C2=A0 7. =C2=A0(N32) sends DAO(tgt=3DN41,PS=3Dx+1,I_fla= g=3D1) to (N22). =C2=A0(N22) has
688 =C2=A0 =C2=A0 =C2= =A0 multiple routes to destination (N41).=C2=A0 It sees that a new path
689 =C2=A0 =C2=A0 =C2=A0 sequence for Target=3DN41 is rec= eived and thus it waits for pre-
690 =C2=A0 =C2=A0 =C2= =A0 determined time period to invalidate another route
691 =C2=A0 =C2=A0 =C2=A0 {(N41),(N33),x}. After time period, (N22) sends
692 =C2=A0 =C2=A0 =C2=A0 DCO(tgt=3DN41,PS=3Dx+1) to (N3= 3).

[min= or] The example is incomplete: (N33) sends a DCO to (N41)...

=

--000000000000abf257058647a36b-- From nobody Thu Apr 11 21:00:12 2019 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 7DC1B12008A; Thu, 11 Apr 2019 21:00:10 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0vekPkw1KhWM; Thu, 11 Apr 2019 21:00:08 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 7E61112003F; Thu, 11 Apr 2019 21:00:08 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id f15so4768496vsk.9; Thu, 11 Apr 2019 21:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2HBpPIqRiKgycY+UwV+Jb+TYpva3cjU73SM2Kqj1BhM=; b=mF51ju0tryb5dDKcOFiFHwP/LnE6nFO/ciJytlFkA1vQD4Qwy4VN4H8kQYlksGd/Z7 7gUkfnKy3h/sx1Qd6b2LlxOd+bdgxKsuarf0ISKPjVvUldKVVrbQ6nz4uSJW0JfxK8QO KukzEMCXY7Pn5dz2yBzr8QyHGJWfrcqoeWXaqzOS1h18akSl0s3C6dN56HlhBIzYjl2w 5GflX9vj0fpwWf/oytkz9wgdxLXpmjFd0c/sLYQoq8r9oxO1R8Ytghhnek7/zoAtTz6/ uKd4ByHHYdgq0hReS6MXZaOq49t8ny/cJD18flEh4d88cKgbyu5eXYttalOAcYTwQTxw sxVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2HBpPIqRiKgycY+UwV+Jb+TYpva3cjU73SM2Kqj1BhM=; b=Erlb44qX5SDlgaSm6Cx3W2beCi1b7bTdciU5Uy0o+bGEcKyeGtlMhFT7Y/ekea8Qd+ BWtRVGa4dKoai+z/zHDuwNqwjqe81XF0L9nPYwWaBHljBj5UjSySOzrTEPdYXYALbraO 0G3J4AyXklhG7UnKhWhn1NMqlr2MUo68mYeb2qmir8XCm/qRaQZvJm5FC6WoWnvght0J +Bg6LNDM7t/LhKL14G6idGA3KetX/WeHqX93KhTmrBliKVrVVDLbGiwT7Z+M6hlxNEut WnvhWSnK/xZQrm5H0dLOecMrfJuj7Yrr8tTJAS3poYTvF8mrEYjlaRoyEi6ORT9mOoe0 DoCQ== X-Gm-Message-State: APjAAAVPmfWZRGO84wfnneWW3X9ww2luU8oPK0kVjc6SUnoEfgh75awL LF/2cHyN7ykp8pL5qfDRi5NBdSkpQdtsuH2S8jU= X-Google-Smtp-Source: APXvYqxEteaYiURfUlqvJ1lBH0SAO6pM4pFEKSsCOZtwuChnPOk5yyFsDMsEp30cEFp3XKdd8SznfGfX0RagZmCjB6w= X-Received: by 2002:a67:fbcc:: with SMTP id o12mr31745877vsr.60.1555041607613; Thu, 11 Apr 2019 21:00:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Fri, 12 Apr 2019 09:29:56 +0530 Message-ID: To: Alvaro Retana Cc: Peter van der Stok , draft-ietf-roll-efficient-npdao@ietf.org, roll , roll-chairs Content-Type: multipart/alternative; boundary="000000000000a2019505864d564a" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 04:00:11 -0000 --000000000000a2019505864d564a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Alvaro for the detailed review. We will handles the fixes and reply to all the concerns/issues mentioned asap. Thanks, Rahul On Fri, 12 Apr 2019 at 2:42 AM, Alvaro Retana wrote: > Dear authors: > > Here's my review of this document. The first part of the document mostly > resulted in nits, but (starting in =C2=A74) I then have some major commen= ts --000000000000a2019505864d564a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Alvaro for the detailed review. We will ha= ndles the fixes and reply to all the concerns/issues mentioned asap.
<= /div>

Thanks,
Rahul=C2=A0

On Fri, 12 Apr 2019 at 2:42 AM, Alvaro Retana <aretana.ietf@gmail.com> wrot= e:
Dear authors:

Here's my review of this document.=C2=A0 The first part of the document= mostly
resulted in nits, but (starting in =C2=A74) I then have some major comments=
--000000000000a2019505864d564a-- From nobody Fri Apr 12 13:52:00 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5E5120632; Fri, 12 Apr 2019 13:51:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155510231855.9280.9256492859664534544@ietfa.amsl.com> Date: Fri, 12 Apr 2019 13:51:58 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-aodv-rpl-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:51: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 WG of the IETF. Title : Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) Authors : Satish Anamalamudi Mingui Zhang Charles E. Perkins S.V.R Anand Bing Liu Filename : draft-ietf-roll-aodv-rpl-07.txt Pages : 26 Date : 2019-04-12 Abstract: Route discovery for symmetric and asymmetric Point-to-Point (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol. Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-07 https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 15 05:48:15 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B8D120143; Mon, 15 Apr 2019 05:48:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Cc: roll-chairs@ietf.org, roll@ietf.org, mariainesrobles@googlemail.com, iesg-secretary@ietf.org, Ines Robles Message-ID: <155533249401.10886.15720806025350411459.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2019 05:48:14 -0700 Archived-At: Subject: [Roll] Publication has been requested for draft-ietf-roll-aodv-rpl-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 12:48:14 -0000 Ines Robles has requested publication of draft-ietf-roll-aodv-rpl-07 as Proposed Standard on behalf of the ROLL working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ From nobody Tue Apr 16 11:15:29 2019 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 46E781200E6 for ; Tue, 16 Apr 2019 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QuzZT2iisES8 for ; Tue, 16 Apr 2019 11:15:25 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 54008120096 for ; Tue, 16 Apr 2019 11:15:25 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id l7so19975894ljg.6 for ; Tue, 16 Apr 2019 11:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=EdBhHskBL69IZDxUEwgw4lyLNB3djw6tpfpuUNMGXPg=; b=BQgftxjSXuW5p120zfnaHgBi842dqSHWYDxLiA5NLETMt2W0ryb4F3yEV3vr3yelqd M3OUYjp2ZEj/pskCcgWypq1FhmxnETRGp5dnEcj4HQadHJiclHEr/Ps4XwNC1l6Ig4wd sSQaYxlnQrtAr9RBk7N06a/ogyAm6iqHZDZxVzeYa6mW/NulpjMOsPEaUwq/GJ8C3vh4 5Mzdjj5s+teLu/wLpRHGRfJRnjzuXhlDku4bcG//UTVfLSY6FQEpp84RLdu4xX+mL8b2 0fMIimOiEJmJWFZDTzclmysINF5tsZJyuLTL2V14h0VeEkNB7WsqQ2TCF73p/TX1KbPz PK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EdBhHskBL69IZDxUEwgw4lyLNB3djw6tpfpuUNMGXPg=; b=WXCX7BnN9/EfZbMNEJn/XzuUzH9+KxL8zJAWYwR9+BToA0VhNny/7YNlVA4QzQm9N9 Np+I+lYi4bEhZx2vtlL0n5qArX/kBnobgTS7LX299rXNK5K8UHDpYfqVms66N6Meh1lr sT3sQokJS+P/aqkSH//CcvqOOgCfkILouHh3kqKy0Tm8gwdKwR8LW5buRN6BRw0qyLxQ FGx3JeG3P+9TnuoNxzOQ8veNEy4fxKI0g4PeREUACLLPBC/PfqNeuYL+/GBTVDHOdR8O KW6Vj6QxWnl060Q1dCMMsBmOzss59y1+Qcgu59H/aMI0dtHxT3c4fnHzri/kmwb9Bt/R nSMA== X-Gm-Message-State: APjAAAVLD5uDXAwm6r2f16husTH8y2nok/IEjhoNi45dFi2RVp57DF6b J3Ie2bntbwqopRyOP6AoWe8GtbbcCyhVyXb8/9U= X-Google-Smtp-Source: APXvYqwFFUI+uTbhAl72LP2uOW8oKRvWDhh0i109NrNERVAwTy9oTBYRgnhiCLe+OJ4t7ceUUjLz2wUQG77lDsVCYfE= X-Received: by 2002:a05:651c:c3:: with SMTP id 3mr35423603ljr.8.1555438523384; Tue, 16 Apr 2019 11:15:23 -0700 (PDT) MIME-Version: 1.0 From: Henning Rogge Date: Tue, 16 Apr 2019 20:14:57 +0200 Message-ID: To: mariainesrobles@gmail.com, Michael Richardson , "Pascal Thubert (pthubert)" Cc: "Luc Andre Burdet (lburdet)" , Alvaro Retana , Min Ye , roll@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Roll] rtgdir Last Call Review: draft-ietf-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 16 Apr 2019 18:15:27 -0000 Hi, I was asked by the IETF to do a Routing-Directorate review of draft-ietf-roll-useofrplinfo. Please note that I do NOT follow the ROLL WG. Overall I think the draft tries too hard to condense information into one document. It often uses non-intuitive abbreviations (e.g. "RPL-aware-Leaf" as "RaF" or "target" as "tgt") and I just don't know if this is the common way to do it in ROLL or just an unlucky accident. A lot of tables are literally overloaded with information to the point where the document generator splits apart words, making the table unreadable (see table 4,6,7,8,11,21 among others). Other table entries are just not easy to interpret. Table 7 (as an example) has the options "no, "must" and "yes" for a column which raises the question what is the difference between "must" and "yes". I am not sure what advice to give for the draft, if this (as the abstract states) is the analysis for the basis of header compression design I am worried that the design decisions will be hard to understand. Henning Rogge From nobody Wed Apr 17 00:09:45 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4F9120161; Wed, 17 Apr 2019 00:09:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Min Ye via Datatracker To: Cc: roll@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Min Ye Message-ID: <155548498336.29300.5806386149863350116@ietfa.amsl.com> Date: Wed, 17 Apr 2019 00:09:43 -0700 Archived-At: Subject: [Roll] Rtgdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 07:09:44 -0000 Reviewer: Henning Rogge Review result: Has Issues Hi, I was asked by the IETF to do a Routing-Directorate review of draft-ietf-roll-useofrplinfo. Please note that I do NOT follow the ROLL WG. Overall I think the draft tries too hard to condense information into one document. It often uses non-intuitive abbreviations (e.g. "RPL-aware-Leaf" as "RaF" or "target" as "tgt") and I just don't know if this is the common way to do it in ROLL or just an unlucky accident. A lot of tables are literally overloaded with information to the point where the document generator splits apart words, making the table unreadable (see table 4,6,7,8,11,21 among others). Other table entries are just not easy to interpret. Table 7 (as an example) has the options "no, "must" and "yes" for a column which raises the question what is the difference between "must" and "yes". I am not sure what advice to give for the draft, if this (as the abstract states) is the analysis for the basis of header compression design I am worried that the design decisions will be hard to understand. Henning Rogge From nobody Fri Apr 26 02:21:53 2019 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 DB0C8120389 for ; Fri, 26 Apr 2019 02:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 u8YQTJ6sIFxM for ; Fri, 26 Apr 2019 02:21:51 -0700 (PDT) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 9AB6E1201C8 for ; Fri, 26 Apr 2019 02:21:50 -0700 (PDT) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id x3Q9Erm9035713 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 26 Apr 2019 09:14:53 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id x3Q9ErCx090114 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 26 Apr 2019 09:14:53 GMT Received: from host171-175-dynamic.9-87-r.retail.telecomitalia.it (host171-175-dynamic.9-87-r.retail.telecomitalia.it [87.9.175.171]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Fri, 26 Apr 2019 11:14:53 +0200 Date: Fri, 26 Apr 2019 11:14:53 +0200 Message-ID: <20190426111453.Horde.UjTaGFHQgzO8_v9IY_LNG85@webmail.math.unipd.it> From: gquadrio@math.unipd.it To: roll@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DCC-wuwien-Metrics: server4 1290; Body=29 Fuz1=33 Fuz2=29 X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker (-10.999) X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.83 Archived-At: Subject: [Roll] [CFP] EAI GOODTECHS 2019, Firm Deadline Approaching - Valencia, Spain, 25/09 - 27/09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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, 26 Apr 2019 09:21:53 -0000 ******************************************************************** * * Call for Papers * * GoodTechs 2019 * * 5th EAI International Conference on * Smart Objects and Technologies for Social Good * * September 25-27, 2019 * * Submissions due: May 1st, 2019 - Firm Deadline Approaching * ******************************************************************** SCOPE ====== By social good we refer to a “good” or a service that benefits the largest number of people in the largest possible way. Some classic examples of social goods are, of course, healthcare, safety, environment, democracy, and human rights, but we can add to this classic list even communication, art, entertainment and much more. In this context, the popularity of portable computing devices, like smartphones, tablets, or smart watches combined with the emergence of many other small smart objects with computational, sensing and communication capabilities coupled with the popularity of social networks and new human-technology interaction paradigms is creating unprecedented opportunities for each of us to do something useful, ranging from a single person to the whole world. Furthermore, Internet of Things, Smart-cities, distributed sensing and Fog computing are representative examples of modern ICT paradigms that aim to describe a dynamic and globally cooperative infrastructure built upon objects’ intelligence and self-configuring capabilities. These connected objects are finding their way into our pockets, vehicles, urban areas and infrastructure, thus becoming the very texture of our society and providing us the possibility, but also the responsibility, to shape it. In GOODTECHS we are hence interested in experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Clearly, we are not considering only the so called first world as the scenario for this evolution; we also refer to those areas where ICT is currently less widespread, hoping that it may represent a societal development opportunity rather than a source for further divide. Topics Authors are solicited to submit original, previously unpublished papers in the following, but not limited to topic areas: - App concepts and technologies for different mobile platforms - Blockchain for social good - Communication between mobile devices - Content Distribution - E-learning solutions - Data collection, organization and dissemination methods - Delay-tolerant aerial networks and ferrying approaches - Deployment and field-testing - Digital tools for art and feelings - Environment sensing, monitoring and preservation - Experimental results of communication testbeds - Game, entertainment, and multimedia applications - Health and social care - Human-object interaction - ICT for development - Mobile service architectures and frameworks - Mobility and handover management - New application scenarios for vehicular communications - Pervasive and ubiquitous services in cloud and IoT - Platforms and frameworks for mobile devices - Privacy issues and solutions - Protocol design, testing and verification - Security issues, architectures and solutions - Smart cities and transportation - Smart economy solutions: e-banking, e-business - Smart governance and e-administration - Smart living and E-health - Technology addressing the digital divide SPECIAL SESSIONS ================ In addition to the main conference, GOODTECHS19 features special sessions, aimed to emphasize emerging topics not fully or not specifically covered in the main conference. Special sessions highlight current topics related to experiences with the design, implementation, deployment, operation and evaluation of smart objects and technologies for social good. Presentations delivered during the events should be based on original papers, selected through a peer-review process and that have not been previously published. Accepted papers will be included in the Conference Proceedings. For more information please refer to the main conference website: http://goodtechs.eu PUBLICATION =========== All registered papers will be published by ACM and made available through ACM Digital Library. Papers should be in English. Regular papers should be up to 6 pages in length. Short papers should be up to 4 pages in length. Previously published work may not be submitted, nor may the work be concurrently submitted to any other conference or journal. Such papers will be rejected without review. Proceedings will be submitted for inclusion in leading indexing services, Ei Compendex, ISI Web of Science, Scopus, CrossRef, Google Scholar, DBLP, as well as EAI’s own EU Digital Library (EUDL). Authors of selected best accepted and presented papers will be invited to submit an extended version to: - Springer Mobile Networks and Applications (MONET) Journal (IF: 2.497) - Wiley Concurrency and Computation: Practice and Experience Journal (IF: 1.114) All accepted authors are eligible to submit an extended version in a fast track of: - EAI Endorsed Transactions on Cloud Systems - EAI Endorsed Transactions on Serious Games SUBMISSION ========== Papers should be submitted through EAI ‘Confy‘ system (https://confyplus.eai.eu/app#conftrack-overview/conf/52608/cid/52655), and have to comply with the ACM format (see Author’s kit section). IMPORTANT DATES =============== Full Paper Submission deadline: May 1, 2019 (Firm Deadline) Notification deadline: June 1, 2019 Camera-ready deadline: July 1, 2019 Start of Conference: September 25, 2019 End of Conference: September 27, 2019 -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy -- Giacomo Quadrio Ph.D student University of Padua Department of Mathematics Via Trieste, 63 - Office 731 35121, Padua, Italy From nobody Sat Apr 27 10:56:45 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 975001201D9; Sat, 27 Apr 2019 10:56:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155638779655.19901.16945496085075757276@ietfa.amsl.com> Date: Sat, 27 Apr 2019 10:56:36 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 17:56:37 -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 WG of the IETF. Title : Efficient Route Invalidation Authors : Rahul Arvind Jadhav Pascal Thubert Rabi Narayan Sahoo Zhen Cao Filename : draft-ietf-roll-efficient-npdao-10.txt Pages : 21 Date : 2019-04-27 Abstract: This document describes the problems associated with No-Path Destination Advertisement Object (NPDAO) messaging used in Routing Protocol for Low power and lossy networks (RPL) for route invalidation and signaling changes to improve route invalidation efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-10 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-10 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 Sat Apr 27 11:07:40 2019 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 B67001201C8; Sat, 27 Apr 2019 11:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SVuR275kk4oG; Sat, 27 Apr 2019 11:07:35 -0700 (PDT) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 163551201D9; Sat, 27 Apr 2019 11:07:34 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id t23so3743729vso.10; Sat, 27 Apr 2019 11:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7ESay5Z+mvtXWPFJIBXaV5vOsyGEj87RmVCn7+lzABc=; b=kkIajsOVayadtdsg2OPKfwN5dTYxoxEbyEQ0sSllqk5JiOztF8YVoNtV6qKRYOnwDr aQOHB8vW76zRwpDXrH2FeYKmWBdbmzY6PcAr0vKOuc4RET54T08oSHxmKjdf3an9KvRU vPhyEJr4hyO1sJqDl4d026+lcRLjpaIxFFZu5SIF/oKsocW8F/4hkjPhPUtauK4qXhrO 8Sh+WUAo7uwbGFGiV4QihbIikt4vBKTMPCuWSPA2MR3/fn5ZhyAo6zJLQAfhlDjewIQ7 qnhnfuKnyp2rZrUCMiZUG+I0gBClv0H+j5Q2tsOAMOvWeRm9CK4DDtK/c8Z/X6C6+jNU UYiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7ESay5Z+mvtXWPFJIBXaV5vOsyGEj87RmVCn7+lzABc=; b=ZRhpwqy40JYHiu2IjREJAlrKpoDgYMtVoVxnEPw5ODK+OrcnAG7SkHO+7s34jSY6R0 T3vsA9fxLKDXYpSkLReelzNOG5deDQ7h2SZE89L09MqT7A610BQn8b4pzEZajP0HQGEl Cv2lqrDUtJlOSa2818Z4FdwYCKkixU/VQajkh86vv3nmWLrxNcvU/x/siFp3GYvsGDaf mm43HHVwkutjbOQ15QL1BCzrT2pVYHfagpeHZyxdIJE7Vbuk+L0vnH0R5QINZ6mFXIId 6ezvdjlQysQv5DCFtgEzLpUtg/NExg25AlpoWZGDs0jK+f2soNN8qVIlR03HmVcL9y2n xpFA== X-Gm-Message-State: APjAAAU1/Gwjld+uofWsdYqW1bN/Bn9ZW/iFzQX0+SYaKqhnyPIFyGY4 pVLRgJix3JSWgulTSRDK+DG3NI4qgsj7sfO5J4A= X-Google-Smtp-Source: APXvYqx6LceeRn8i7JLaitnR5dG9ep1IyL5NhQOKoTuwZE1bZOPvgrAiFytG8sqtk2Ath97f8KRP4qUuv+4bav8p/mY= X-Received: by 2002:a05:6102:385:: with SMTP id m5mr10616529vsq.173.1556388453007; Sat, 27 Apr 2019 11:07:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Sat, 27 Apr 2019 23:37:21 +0530 Message-ID: To: Alvaro Retana Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter van der Stok , roll-chairs , roll Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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, 27 Apr 2019 18:07:39 -0000 Thank you Alvaro for the detailed review. This has greatly improved the document. We had to update major portion of the text and even though there has been no semantic changes of DCO/DCO-ACK, there are lot of text update and few new sections added. Please find the responses to your comments and unless explicitly mentioned, all the [nit]s and [minor]s comments are fixed as per your suggestions. All the [major] comments have explicit responses. Regards, Rahul ------------------------------------------- Dear authors: Here's my review of this document. The first part of the document mostly resulted in nits, but (starting in =C2=A74) I then have some major comments= . I'll wait for those to be addressed before starting the IETF Last Call. The most significant issue is the fact that the suggested values for the DCO are already assigned! The Shepherd's writeup says that a pilot implementation exists -- which, I assume uses the suggested values. What is the impact on existing implementations? [RJ] Our pilot implementation uses the codes which are assigned to P2P-RPL. Since we do not have P2P-RPL currently implemented we missed out on this po= int. We will be updating the values in the implementation once the allocation is done. Implementation-wise may have to just change the codes used. [Line numbers come from idnits.] ... 14 Abstract 16 This document describes the problems associated with NPDAO messaging 17 used in RPL for route invalidation and signaling changes to improve 18 route invalidation efficiency. [nit] Please expand NPDAO...you may have to do it completely (including DAO). [nit] RPL should be expanded in the Abstract as well... [RJ] Fixed. ... 91 1. Introduction 93 RPL [RFC6550] (Routing Protocol for Low power and lossy networks) 94 specifies a proactive distance-vector based routing scheme. RPL has 95 an optional messaging in the form of DAO (Destination Advertisement 96 Object) messages using which the 6LBR (6Lo Border Router) and 6LR 97 (6Lo Router) can learn route towards the downstream nodes. In 98 storing mode, DAO messages would result in routing entries been 99 created on all intermediate 6LRs from the node's parent all the way 100 towards the 6LBR. [nit] s/messages using which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can learn route/messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can use to learn a route [nit] s/routing entries been created/routing entries being created [RJ] Fixed. 102 RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a 103 routing path corresponding to the given target, thus releasing 104 resources utilized on that path. A NPDAO is a DAO message with route 105 lifetime of zero, originates at the target node and always flows 106 upstream towards the 6LBR. This document explains the problems 107 associated with the current use of NPDAO messaging and also discusses 108 the requirements for an optimized route invalidation messaging 109 scheme. Further a new pro-active route invalidation message called 110 as "Destination Cleanup Object (DCO)" is specified which fulfills 111 requirements of an optimized route invalidation messaging. [nit] s/allows use of/allows the use of [nit] s/"Destination Cleanup Object (DCO)"/"Destination Cleanup Object" (DCO) [RJ] Fixed. ... 117 1.1. Requirements Language and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the template in rfc8174. [RJ] Updated based on RFC8174 123 6LR: 6LoWPAN Router. This is an intermediate 6lowpan router which 124 allows traffic routing through itself in a multihop 6lo network. [nit] Please be consistent: 6LoWPAN vs 6lowpan [nit] You may have to define 6lo. [minor] In this case, the definition includes the name: "6LoWPAN Router...is an intermediate 6lowpan router..." [nit] In general, simply pointing to rfc6550 (or other documents where the terms are already defined) may be easier than redefining. [RJ] Fixed. ... 161 1.2. Current NPDAO messaging 163 RPL uses NPDAO messaging in the storing mode so that the node 164 changing it routing adjacencies can invalidate the previous route. 165 This is needed so that nodes along previous path can release any 166 resources (such as the routing entry) it maintains on behalf of 167 target node. [nit] s/along previous path/along the previous path [RJ] Fixed. ... 200 1.3. Why NPDAO is important? 202 Nodes in LLNs may be resource constrained. There is limited memory 203 available and routing entry records are one of the primary elements 204 occupying dynamic memory in the nodes. Route invalidation helps 6LR 205 nodes to decide which entries could be discarded to better achieve 206 resource utilization. Thus it becomes necessary to have efficient 207 route invalidation mechanism. Also note that a single parent switch 208 may result in a "sub-tree" switching from one parent to another. 209 Thus the route invalidation needs to be done on behalf of the sub- 210 tree and not the switching node alone. In the above example, when 211 Node (D) switches parent, the route updates needs to be done for the 212 routing tables entries of (C),(H),(A),(G), and (B) with destination 213 (D),(E) and (F). Without efficient route invalidation, a 6LR may 214 have to hold a lot of stale route entries. [nit] s/to have efficient/to have an efficient [RJ] Fixed. ... 225 2.2. Invalidate routes of dependent nodes 227 RPL does not specify how route invalidation will work for dependent 228 nodes rooted at switching node, resulting in stale routing entries of 229 the dependent nodes. The only way for 6LR to invalidate the route 230 entries for dependent nodes would be to use route lifetime expiry 231 which could be substantially high for LLNs. [nit] s/rooted at switching node/rooted at the switching node [RJ] Fixed. ... 239 2.3. Possible route downtime caused by async operation of NPDAO and DA= O ... 247 In the example topology, consider Node (D) switches from parent (B) 248 to (C). An NPDAO sent via previous route may invalidate the previous 249 route whereas there is no way to determine whether the new DAO has 250 successfully updated the route entries on the new path. [nit] s/via previous route/via the previous route [RJ] Fixed. 252 3. Requirements for the NPDAO Optimization 254 3.1. Req#1: Remove messaging dependency on link to the previous parent 256 When the switching node sends the NPDAO message to the previous 257 parent, it is normal that the link to the previous parent is prone to 258 failure (thats why the node decided to switch). Therefore, it is 259 required that the route invalidation does not depend on the previous 260 link which is prone to failure. The previous link referred here 261 represents the link between the node and its previous parent (from 262 whom the node is now disassociating). [nit] s/thats/that's [RJ] Fixed. ... 278 4. Proposed changes to RPL signaling [minor] These changes are not "proposed" anymore. s/Proposed changes to RPL signaling/Changes to RPL signaling [RJ] Fixed. 280 4.1. Change in RPL route invalidation semantics 282 As described in Section 1.2, the NPDAO originates at the node 283 switching the parent and traverses upstream towards the root. In 284 order to solve the problems as mentioned in Section 2, the draft adds 285 new pro-active route invalidation message called as "Destination 286 Cleanup Object" (DCO) that originates at a common ancestor node 287 between the new and old path. The common ancestor node generates a 288 DCO in response to the change in the next-hop on receiving a regular 289 DAO with updated path sequence for the target. [nit] Maybe it's just me, but the "switching the parent" terminology doesn't sound great. By now I am not having to reread the text because my mind tends to think of a switch (not the switching action)...but maybe "changing", or even "switching to a new parent" may be better. Another option is to simply use the "target node" term defined above. Please take this comment for what it is: just a nit. [nit] s/draft/document/g [nit] s/adds new/adds a new [nit] s/called as /called /g [RJ] Fixed. 291 In Figure 1, when node D decides to switch the path from B to C, it 292 sends a regular DAO to node C with reachability information 293 containing target as address of D and a incremented path sequence 294 number. Node C will update the routing table based on the 295 reachability information in DAO and in turn generate another DAO with 296 the same reachability information and forward it to H. Node H also 297 follows the same procedure as Node C and forwards it to node A. When 298 node A receives the regular DAO, it finds that it already has a 299 routing table entry on behalf of the target address of node D. It 300 finds however that the next hop information for reaching node D has 301 changed i.e. the node D has decided to change the paths. In this 302 case, Node A which is the common ancestor node for node D along the 303 two paths (previous and new), should generate a DCO which traverses 304 downwards in the network. [major] I think that this illustration should be Normatively spelled out. There are details, for example due to the fact that a new DAO is created at every hop, that are not explicitly mentioned. As the DAO is sent up the tree, it is generated "with the same reachability information" -- I think this document should be explicit about the setting of the I flag, the Path Sequence to be used, etc.. [RJ] There is a new para added in the same section. Inspired by "DAO Base R= ules" section in rfc6550, a separate section "DCO Base Rules" is added which expl= ains rules an implementation should follow to handle DCO. [major] Is a DCO generated at every hop? IOW, A sends the DCO to G, which takes action based on it (invalidates the routes) and then sends another DCO (with the same information) to B... If so, then that needs to be explicitly specified as well. [RJ] A new para in this section now clarifies this. [nit] s/in DAO/in the DAO [nit] s/i.e. the node D/i.e. node D [RJ] Fixed. 306 4.2. Transit Information Option changes 308 Every RPL message is divided into base message fields and additional 309 Options. The base fields apply to the message as a whole and options 310 are appended to add message/use-case specific attributes. As an 311 example, a DAO message may be attributed by one or more "RPL Target" 312 options which specify the reachability information for the given 313 targets. Similarly, a Transit Information option may be associated 314 with a set of RPL Target options. [nit] A reference to rfc6550 somewhere in the paragraph would help the reader know that none of that is new...but a review. [RJ] added ref. 316 The draft proposes a change in Transit Information option to contain 317 "Invalidate previous route" (I) bit. This I-bit signals the common 318 ancestor node to generate a DCO on behalf of the target node. The 319 I-bit is carried in the transit information option which augments the 320 reachability information for a given set of RPL Target(s). Transit 321 information option should be carried in the DAO message with I-bit 322 set in case route invalidation is sought for the correspondig 323 target(s). [nit] s/The draft proposes a change/This document specifies a change [nit] s/in Transit Information option/in the Transit Information Option [nit] s/contain "Invalidate/contain the "Invalidate [nit] s/. Transit information option/. The Transit Information Option [nit] s/correspondig/corresponding [RJ] Fixed. 325 0 1 2 3 326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type =3D 0x06 | Option Length |E|I| Flags | Path Control | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Path Sequence | Path Lifetime | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 332 | | 333 + + 334 | | 335 + Parent Address* + 336 | | 337 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 2: Updated Transit Information Option (New I flag added) [nit] Take the "*" off -- it was used in rfc6500, but has no meaning here. [nit] Indent the definition of the fields for clarity. [RJ] Fixed. ... 347 The common ancestor node SHOULD generate a DCO message in response to 348 this I-bit when it sees that the routing adjacencies have changed for 349 the target. I-bit governs the ownership of the DCO message in a way 350 that the target node is still in control of its own route 351 invalidation. [major] When/why would the common ancestor not generate a DCO message? IOW, why is MUST not used? I imagine that simply the nature of the LLN may prevent it from generating one (which makes the SHOULD ok)...but I'm trying to find out if there are other reasons. [RJ] I could not think of any other reason as well. Having said that, I am = also not particularly religious about this i.e. am ok to change it to MUST if th= ere is any other good reason (from the WG pariticipants). 353 4.3. Destination Cleanup Object (DCO) ... 383 K: The 'K' flag indicates that the recipient is expected to send a 384 DCO-ACK back. If the DCO-ACK is not received even after setting the 385 'K', an implementation may choose to retry the DCO at a later time. 386 The number of retries are implementation and deployment dependent. 387 This document recommends using retries similar to what will be set 388 for DAO-ACK handling. [minor] Why are the retries optional? If "the recipient is expected to send a DCO-ACK", then why wouldn't the sender retry? If it doesn't matter, then just don't set the flag. Given that the DCO is akin to the DAO, maybe use similar text as what is in rfc6550/=C2=A79.3... [minor] The last sentence makes a recommendation, but with no reference. rfc6550 says that the retries are implementation specific...maybe mention something like that here too. [RJ] Have added the section "DCO Base Rules" inline with "DAO Base Rules" (rfc6550/sect9.3). 390 D: The 'D' flag indicates that the DODAGID field is present. This 391 flag MUST be set when a local RPLInstanceID is used. 393 Flags: The 6 bits remaining unused in the Flags field are reserved 394 for future use. These bits MUST be initialized to zero by the sender 395 and MUST be ignored by the receiver. [major] Do you expect IANA to manage the assignments of those bits? [RJ] Yes, added this in IANA considerations section. ... 404 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 405 uniquely identifies a DODAG. This field is only present when the 'D' 406 flag is set. This field is typically only present when a local 407 RPLInstanceID is in use, in order to identify the DODAGID that is 408 associated with the RPLInstanceID. When a global RPLInstanceID is in 409 use, this field need not be present. Unassigned bits of the DCO Base 410 are reserved. They MUST be set to zero on transmission and MUST be 411 ignored on reception. [minor] "This field is typically only present when a local RPLInstanceID is in use..." "typically only present" is not in line with the MUST above (describing the D flag): s/typically only present/only present [RJ] Have changed the wordings here. Removed 'typically' also. [major] The last couple of sentences seem to have been left behind, or at least meant for their own paragraph... I see that similar text is used in rfc6550...but I'm not sure what bits it refers to. [RJ] Yeah, not sure what these bits are. I sheepishly picked up the whole description as is from rfc6550. Removing this text even though it appears i= n rfc6550. 413 4.3.1. Secure DCO 415 A Secure DCO message follows the format in [RFC6550] figure 7, where 416 the base message format is the DCO message shown in Figure 3. [nit] s/figure 7/Figure 7 418 4.3.2. DCO Options 420 The DCO message MAY carry valid options. This specification allows 421 for the DCO message to carry the following options: 423 0x00 Pad1 424 0x01 PadN 425 0x05 RPL Target 426 0x06 Transit Information 427 0x09 RPL Target Descriptor 429 The DCO carries a Target option and an associated Transit Information 430 option with a lifetime of 0x00000000 to indicate a loss of 431 reachability to that Target. [major] Are the RPL Target and Transit Information options mandatory? If so, then that is at odds with the MAY above. [RJ] Explicitly added the MUST clause for Target and Transit options. Also = the lifetime field in the transit option MUST be set to 0 in DCO's transit opti= on. Surprisingly rfc6550 does not mandate target/transit information in the DAO message. We have raised this point with WG before and have already added th= is to observation's draft. [nit] s/a Target option/an RPL Target option 433 4.3.3. Path Sequence number in the DCO 435 A DCO message may contain a Path Sequence in the transit information 436 option to identify the freshness of the DCO message. The Path 437 Sequence in the DCO MUST use the same Path Sequence number present in 438 the regular DAO message when the DCO is generated in response to DAO 439 message. The DAO and DCO path sequence are picked from the same 440 sequence number set. Thus if a DCO is received by a 6LR and 441 subsequently a DAO is received with old seqeunce number, then the DAO 442 should be ignored. [minor] To make sure I'm clear: the "DCO path sequence" refers to the Path Sequence field in the Transit Information Option, right? If so, please be clear and specific. [RJ] Updated. [major] The text is not clear (I asked the same thing above) if the Transit Information Option is mandatory or not in the DCO...is it? The text above says that the "DCO message may contain a Path Sequence in the transit information option". If the Transit Information Option is present, then the Path Sequence is present too...so it sounds like the Transit Information Option is not optional. [RJ] We have made target/transit MUST options in DCO. DCO cannot operate without these options. [major] "Path Sequence in the DCO MUST use the same Path Sequence number present in the regular DAO message when the DCO is generated in response to DAO message" The DAO message is obviously the one that triggered the DCO... When would a DCO *not* be originated in response to a DAO? Are there other cases when the DCO can be originated? Requiring the same Path Sequence is fine...the reason for this comment is the condition ("when the DCO..."). [RJ] One other condition that i can think of is, if the common ancestor nod= e somehow believes that there are other high priority routing entries that it must entertain, thus evicting existing ones. During such eviction the commo= n ancestor node could make use of the stored path sequence and initiate a DCO= . DCO can fully support this in current form. Do you think this use-case make= s sense? We introduced 'I' bit especially so that target is in full control o= f its own invalidation. With such change we loosen up that part. [minor] "The DAO and DCO path sequence are picked from the same sequence number set." I'm not sure what this means -- the text before it says that the Path Sequence number "MUST use the same...present in the regular DAO message", so in reality the Path Sequence in the DCO is not picked from the same set...it's just copied. [RJ] Yes the Path Sequence is simply copied. I have changed the wordings. [minor] "Thus if a DCO is received by a 6LR and subsequently a DAO is received with old seqeunce number, then the DAO should be ignored." Should this behavior be Normative? IOW, do you want to use "SHOULD" instead? Maybe even "MUST". Just wondering: it seems like an important behavior.. [RJ] I have updated to MUST, because the older DAO MUST not be used. [major] I know that the "ancestor node SHOULD generate a DCO message in response to this I-bit" (=C2=A74.2), but what prevents a (rogue) ancestor f= rom generating a DCO at any other time? The last sentence above opens the door to an attack where the ancestor can send a DCO with a Path Sequence in the future...and cause the route to be invalidated...*and* future updates to be ignored. Is this possible? [This risk, and any possible mitigation should be mentioned in the Security Considerations.] [RJ] As commented above, yes, this is possible. I am wondering whether to retain this behaviour as a feature i.e. common ancestor node could unilater= ally invalidate the route since it has all the possible state info required to d= o this. I will reupdate the document based on response. [nit] s/transit information option/Transit Information Option [nit] s/response to DAO/response to a DAO [nit] s/path sequence/Path Sequence [minor] s/old seqeunce number/old Path Sequence number [RJ] Fixed. 444 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 446 The DCO-ACK message may be sent as a unicast packet by a DCO 447 recipient in response to a unicast DCO message. [minor] "may be sent" Is this an optional response? =C2=A74.3 defines the= K flag in the DCO to indicate "that the recipient is expected to send a DCO-ACK back" -- that is not a Normative statement...but it seems like a waste if no ACK is sent back. [RJ] I have used SHOULD to send back the DCO-ACK. RFC6550 mentions similar behaviour for DAO message with 'K' bit set. ... 477 Status: Indicates the completion. Status 0 is defined as unqualified 478 acceptance in this specification. The remaining status values are 479 reserved as rejection codes. [minor] Do you expect IANA to handle the assignment of new codes? [RJ] Unlike DAO-ACK status which has categorised statuses (normal status, rejection, outright rejection), DCO-ACK status field is flat i.e. there is = no outright rejections. Added the status field to the IANA considerations sect= ion. 481 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 482 uniquely identifies a DODAG. This field is only present when the 'D' 483 flag is set. This field is typically only present when a local 484 RPLInstanceID is in use, in order to identify the DODAGID that is 485 associated with the RPLInstanceID. When a global RPLInstanceID is in 486 use, this field need not be present. Unassigned bits of the DCO-Ack 487 Base are reserved. They MUST be set to zero on transmission and MUST 488 be ignored on reception. [minor] Those last 2 sentences seem to be out of place. Also, I think all the bits are accounted for above. [RJ] Yes this is fixed as per similar comment above. [nit] s/DCO-Ack/DCO-ACK 490 4.3.5. Secure DCO-ACK 492 A Secure DCO-ACK message follows the format in [RFC6550] figure 7, 493 where the base message format is the DCO-ACK message shown in 494 Figure 4. [nit] s/figure 7/Figure 7 496 4.4. Other considerations 498 4.4.1. Dependent Nodes invalidation 500 Current RPL [RFC6550] does not provide a mechanism for route 501 invalidation for dependent nodes. This document allows the dependent 502 nodes invalidation. Dependent nodes will generate their respective 503 DAOs to update their paths, and the previous route invalidation for 504 those nodes should work in the similar manner described for switching 505 node. The dependent node may set the I-bit in the transit 506 information option as part of regular DAO so as to request 507 invalidation of previous route from the common ancestor node. [major] This part is underspecified. How do the dependent nodes know of the switch? Is A (Figure 1) the common ancestor node mentioned above? I found the same question being asked during WGLC, and the answer seems to be: "the dependent nodes will always set the I-flag". Is that my correct interpretation? The behavior needs to be reflected in the specification. https://mailarchive.ietf.org/arch/msg/roll/LejLNET8Hk92wPWU3Xi6OaxCujg [RJ] I have added a para to describe this more. Please check if it makes se= nse. 509 4.4.2. NPDAO and DCO in the same network 511 Even with the changed semantics, the current NPDAO mechanism in 512 [RFC6550] can still be used, for example, when the route lifetime 513 expiry of the target happens or when the node simply decides to 514 gracefully terminate the RPL session on graceful node shutdown. 515 Moreover a deployment can have a mix of nodes supporting the proposed 516 DCO and the existing NPDAO mechanism. [major] This text sounds as if the NPDAO is made optional. Is that the intent? rfc6550 says that "when a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message". If the behavior from rfc6550 is changing, then this document should be more specific and Normative about it. [RJ] Two new paras are added to further elaborate. 518 4.4.3. DCO with multiple preferred parents 520 [RFC6550] allows a node to select multiple preferred parents for 521 route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs 522 generated at the same time for the same Target MUST be sent with the 523 same Path Sequence in the Transit Information". Thus a DAO message 524 with the same path sequence MUST be sent to all the parents. 525 Subsequently when route invalidation has to be initiated, RPL 526 mentions that an NPDAO must be initiated with updated path sequence 527 to all the routes to be invalidated. [major] "Thus a DAO message with the same path sequence MUST be sent to all the parents." This sentence seems to just be a repetition of what the quoted text says...but making it Normative to this document. I don't see the point since the behavior is already Normative. [RJ] I have removed the redundant statement. [major] "RPL mentions that an NPDAO must be initiated with updated path sequence to all the routes to be invalidated." I couldn't find a place in rfc6550 that says that. [RJ] I have updated the sentence. 529 With DCO, the Target node itself does not initiate the route 530 invalidation and it is left to the common ancestor node. A common 531 ancestor node when it discovers an updated DAO from a new next-hop, 532 it initiates a DCO. With multiple preferred parents, this handling 533 does not change. But in this case it is recommended that an 534 implementation initiates a DCO after a time period such that the 535 common ancestor node may receive updated DAOs from all possible next- 536 hops. This will help to reduce DCO control overhead i.e., the common 537 ancestor can wait for updated DAOs from all possible directions 538 before initiating a DCO for route invalidation. The time period for 539 initiating a DCO could be based on the depth of the network. After 540 timeout, the DCO needs to be generated for all the next-hops for whom 541 the route invalidation needs to be done. [major] "With multiple preferred parents...it is recommended that an implementation initiates a DCO after a time period..." How does the ancestor know if there are multiple parents or not? Should this recommendation be generic? How long is should the ancestor wait? [RJ] Have added two paras to explain the rationale for delaying DCO, what happens if the DCO and DAO still overlaps and specific text to explain how = to set the timer. ... 548 6. IANA Considerations 550 IANA is requested to allocate new ICMPv6 RPL control codes in RPL 551 [RFC6550] for DCO and DCO-ACK messages. [major] The name of the registry is "RPL Control Codes". [RJ] Fixed s//IANA is requested to allocate new codes for the DCO and DCO-ACK messages from the RPL Control Codes registry. 553 +------+---------------------------------------------+--------------+ 554 | Code | Description | Reference | 555 +------+---------------------------------------------+--------------+ 556 | 0x04 | Destination Cleanup Object | This | 557 | | | document | 558 | 0x05 | Destination Cleanup Object Acknowledgement | This | 559 | | | document | 560 | 0x84 | Secure Destination Cleanup Object | This | 561 | | | document | 562 | 0x85 | Secure Destination Cleanup Object | This | 563 | | Acknowledgement | document | 564 +------+---------------------------------------------+--------------+ [major] The values suggested in this table are already assigned. I would suggest you simply call the codes TBD1-TBD4. Note that the corresponding figures must also be updated. https://www.iana.org/assignments/rpl/rpl.xhtml#control-codes [RJ] Fixed as per suggestion 566 IANA is requested to allocate bit 18 in the Transit Information 567 Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route 568 'I' flag. [major] The registry is called "Transit Information Option Flags"...and the requested assignment corresponds to bit 1. [RJ] Fixed s//IANA is requested to allocate bit 1 from the Transit Information Option Flags registry the I-bit (Section 4.2). 570 7. Security Considerations [major] This section mostly points at rfc6550 (which is ok), but it doesn't say anything about vulnerabilities (if any) that this specification may be introducing...or why it doesn't. [See my related comment in =C2=A74.3.3.] I would like to see (perhaps after the current text) something along the lines of "This document introduces the ability to do abc. It doesn't introduce any new vulnerabilities becasue... OR ... These are the new vulnerabilities and this is how they can be mitigated...or why they are not really of concern..." [RJ] Have added this text in the beginning of the security considerations section. Also have updated the "Unsecured" mode para, to say that the DCO a= nd DCO-ACK MUST be link-layer encrypted if link-layer security is been put to = use. ... 609 Appendix A. Example Messaging 611 A.1. Example DCO Messaging 613 In Figure 1, node (D) switches its parent from (B) to (C). The 614 sequence of actions is as follows: 616 1. Node D switches its parent from node B to node C 617 2. D sends a regular DAO(tgt=3DD,pathseq=3Dx+1,I_flag=3D1) in the up= dated 618 path to C [minor] The notation "DAO/DCO()" should be explained somewhere...and should be consistent throughout (it changes below). [RJ] Have added detailed explanation of the messaging convention used and t= he details of the message parameters used. 619 3. C checks for routing entry on behalf of D, since it cannot find 620 an entry on behalf of D it creates a new routing entry and 621 forwards the reachability information of the target D to H in a 622 DAO. [nit] s/for routing entry/for a routing entry/g ... 637 7. Similarly, B processes the DCO by invalidating the routing entry 638 of target D and forwards the (un)reachability information 639 downstream to D. 641 8. D ignores the DCO since the target is itself. [?] Just curious: why will B even propagate the DCO to D? B already knows that the target is D... [RJ] B receives the target information of node D which is a non link-local = IPv6 address. B cannot infer from this address that D is directly connected to i= t. 642 9. The propagation of the DCO will stop at any node where the node 643 does not have an routing information associated with the target. 644 If the routing information is present and the pathseq associated 645 is not older, then still the DCO is dropped. [major] This paragraph contains information that hasn't been specified elsewhere in the document. It must be. [RJ] Have added this point in the "DCO Base Rules" section (newly added section). [minor] This sentence is awkwardly worded: "If the routing information is present and the pathseq associated is not older, then still the DCO is dropped." Perhaps s/the pathseq associated is not older/its Path Sequence is higher [RJ] Fixed as per suggestion. 647 A.2. Example DCO Messaging with multiple preferred parents ... 675 2. (N32) sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N22). (N33) als= o 676 sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N22). (N22) learns mu= ltiple 677 routes for the same destination (N41) through multiple next-hops. 678 The route table at N22 should contain (Dst,NextHop,PS): { 679 (N41,N32,x), (N41,N33,x) }. 680 3. (N22) sends DAO(tgt=3DN41,PS=3Dx,I_flag=3D1) to (N11). [major] The I_flag is set...but (N22) doesn't originate a DCO... I think the flag should not be set at this point. [RJ] I have updated point 2 to explain why (N22) didnt initiate a DCO. ... 687 7. (N32) sends DAO(tgt=3DN41,PS=3Dx+1,I_flag=3D1) to (N22). (N22) h= as 688 multiple routes to destination (N41). It sees that a new path 689 sequence for Target=3DN41 is received and thus it waits for pre- 690 determined time period to invalidate another route 691 {(N41),(N33),x}. After time period, (N22) sends 692 DCO(tgt=3DN41,PS=3Dx+1) to (N33). [minor] The example is incomplete: (N33) sends a DCO to (N41)... [RJ] Yes the example was incomplete (last 4 steps were missing). Have added all the steps now. On Fri, 12 Apr 2019 at 02:42, Alvaro Retana wrote: > > Dear authors: > > Here's my review of this document. The first part of the document mostly > resulted in nits, but (starting in =C2=A74) I then have some major commen= ts From nobody Tue Apr 30 03:01:02 2019 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 8213E120125 for ; Tue, 30 Apr 2019 03:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0VvR4zMcajbt for ; Tue, 30 Apr 2019 03:00:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A305B12029C for ; Tue, 30 Apr 2019 03:00:58 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D52399E931EC7F4CA9A9 for ; Tue, 30 Apr 2019 11:00:56 +0100 (IST) Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Apr 2019 11:00:56 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.86]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Tue, 30 Apr 2019 15:30:43 +0530 From: Rahul Arvind Jadhav To: roll Thread-Topic: Unassigned bits of the ... are reserved Thread-Index: AdT/OaA2dn6+1tMPS1mhUStT51rH4A== Date: Tue, 30 Apr 2019 10:00:43 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DE82645@BLREML503-MBX.china.huawei.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DE82645BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] Unassigned bits of the ... are reserved X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 30 Apr 2019 10:01:00 -0000 --_000_982B626E107E334DBE601D979F31785C5DE82645BLREML503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello ROLL, RPL (RFC6550) base objects and options have a couple of sentences in the co= ntext saying, "Unassigned bits of the [MSG] are reserved. They MUST be set to zero on tra= nsmission and MUST be ignored on reception." This text is present for all base objects including, DIO/DAO/DAO-ACK/CC. Also it is present for following options, RIO/PIO/Transit Information Optio= n/Solicited Information But it is not present for following options, DODAG Configuration/DAG Metric= Container/Pad1/PadN/RPL Target. Want to understand which bits are referenced by this statement and why for = certain options it is not mentioned? Regards, Rahul --_000_982B626E107E334DBE601D979F31785C5DE82645BLREML503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello ROLL,

 

RPL (RFC6550) base objects and options have a couple= of sentences in the context saying,

“Unassigned bits of the [MSG] are reserved.= They MUST be set to zero on transmission and MUST be ignored on reception.= ”

 

This text is present for all base objects including,= DIO/DAO/DAO-ACK/CC.

Also it is present for following options, RIO/PIO/Tr= ansit Information Option/Solicited Information

But it is not present for following options, DODAG C= onfiguration/DAG Metric Container/Pad1/PadN/RPL Target.

 

Want to understand which bits are referenced by this= statement and why for certain options it is not mentioned?

 

<This point was commented upon by Alvaro during r= eview of draft-ietf-roll-efficient-npdao-09>

 

Regards,

Rahul

--_000_982B626E107E334DBE601D979F31785C5DE82645BLREML503MBXchi_-- From nobody Tue Apr 30 03:10:49 2019 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 EDBB4120296 for ; Tue, 30 Apr 2019 03:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FiPFb+Bi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UL+OpARg 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 tp71d0NN9lYu for ; Tue, 30 Apr 2019 03:10:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0679012028A for ; Tue, 30 Apr 2019 03:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5915; q=dns/txt; s=iport; t=1556619045; x=1557828645; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9Z/2aO17STxk27qtkbNt94WDqwuK4syFZ+VQXBDdRP0=; b=FiPFb+Bi3wEBnAFIRpBT+eT+o2MjBFz9veuM6iGoSaZbzcPajAx0a/MM jHNVFcxh1jJQal9wWlDDpQJpuDSaZ0ZZ9LrcuP42bQmL0Hd6cYaBbOe+2 Fvc6i/9b9AixzJTuNGRposB5O2mCZZQrEq5HyUoXNIgmG5JIaaA3u/v9U c=; IronPort-PHdr: =?us-ascii?q?9a23=3Aq8gKqx2OApcsXQpTsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAAAIHshc/40NJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEOL1ADaVUgBAsoh1cDhFKKPUqCDX6RWIRMgS6BJAN?= =?us-ascii?q?UDgEBLYM/gQEChjEjNAkOAQMBAQQBAQIBAm0cDIVKAQEBBBIbEwEBOA8CAQg?= =?us-ascii?q?RBAEBLzIdCAEBBBMIGoMBgR1NAx0BAqMoAoE1iF+CIIJ5AQEFhQkYgg4JgTI?= =?us-ascii?q?BhGGGaBeBQD+BEUaCFwcuPoRGDCqDBIImkgSVAAkCggmSU5UtoF0CBAIEBQI?= =?us-ascii?q?OAQEFgU84gVZwFYMngg+Db4pTcoEpkxEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,413,1549929600"; d="scan'208,217";a="553210891" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 10:10:43 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UAAhFp020635 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Apr 2019 10:10:43 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 05:10:43 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 05:10:42 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 30 Apr 2019 05:10:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=df6ebtzBdri/++Bw5g6RT6S3mN6sUtpyHzcmb+RbqOw=; b=UL+OpARgwYtPxUmWH0/xjaCvCnKxquczPexVIjvZm+qxQOHYlYG4aDgKZ0Ulr6HRF+HEFgX9zYbohshiEVQ5vFN7U4yvDMmr6v2oT+Q+ECsi4ErgA1OBQ06Q9r9bdlUgnKkcqbsCiIxpSIy6+8GX1ThVEtwnRoxsADT5mXV6ULY= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3758.namprd11.prod.outlook.com (20.178.253.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.14; Tue, 30 Apr 2019 10:10:41 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::68f6:21c8:b681:c73]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::68f6:21c8:b681:c73%4]) with mapi id 15.20.1835.010; Tue, 30 Apr 2019 10:10:41 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Unassigned bits of the ... are reserved Thread-Index: AdT/OaA2dn6+1tMPS1mhUStT51rH4AAAvbhg Date: Tue, 30 Apr 2019 10:10:33 +0000 Deferred-Delivery: Tue, 30 Apr 2019 10:09:51 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DE82645@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DE82645@BLREML503-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::26c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca3823c9-e8fe-4789-cdd7-08d6cd5419fb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3758; x-ms-traffictypediagnostic: MN2PR11MB3758: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(366004)(39860400002)(376002)(199004)(189003)(6436002)(256004)(476003)(6666004)(790700001)(81156014)(2906002)(6116002)(81166006)(8936002)(76116006)(66556008)(64756008)(66946007)(19627235002)(5660300002)(71190400001)(52536014)(66446008)(7736002)(316002)(229853002)(73956011)(8676002)(7696005)(74316002)(71200400001)(66476007)(86362001)(68736007)(33656002)(186003)(9686003)(55016002)(54896002)(6246003)(446003)(97736004)(486006)(478600001)(11346002)(46003)(76176011)(25786009)(53936002)(53546011)(14454004)(99286004)(102836004)(6916009)(6306002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3758; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZP6aUJ0VqllYto8zfN/Hay28uzxPn0cPL7tI27SFgunY0faNegHaCAn6lxqFCiORKcYkO9TtzPo/3UbnKQvUIl370JLOJZ9lu5MFSbQwQTxY+178Rqge7Tgw8kfPGImJtSU23UG8dpFBm50qOpkh+m1vq2WQ5shjPtuLno7BiNK55Ttb5eOL2tubwT4+hNvCdH0BHN1e58VF63TxD84ErdO/3jx0rK8utgzK15n3XRuWhNLx9kQ5s41I+EtcUCkmsEj1i3FQGQotOzw66fv2MWh/aaQ+xgCvUScdMiNWh2aGQ9svaO8BD7/G7ZPcYjD0UEisFNEZjB6VD4+qxmtL3NtokFfao2uQ4FNLiShBKXYYbCjePlmRURZzpeY0FSPseb4En6e81v+0AOFd9xpEXZTDh8hCbfKJi+D0IsSIesk= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565DAABA73E0AF3F712F648D83A0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ca3823c9-e8fe-4789-cdd7-08d6cd5419fb X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 10:10:41.4342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3758 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [Roll] Unassigned bits of the ... are reserved X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 30 Apr 2019 10:10:47 -0000 --_000_MN2PR11MB3565DAABA73E0AF3F712F648D83A0MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul I guess we forgot. Reserved is always zero as a general practice but it is = good to say it to make sure : ) All the best, Pascal From: Roll On Behalf Of Rahul Arvind Jadhav Sent: mardi 30 avril 2019 12:01 To: roll Subject: [Roll] Unassigned bits of the ... are reserved Hello ROLL, RPL (RFC6550) base objects and options have a couple of sentences in the co= ntext saying, "Unassigned bits of the [MSG] are reserved. They MUST be set to zero on tra= nsmission and MUST be ignored on reception." This text is present for all base objects including, DIO/DAO/DAO-ACK/CC. Also it is present for following options, RIO/PIO/Transit Information Optio= n/Solicited Information But it is not present for following options, DODAG Configuration/DAG Metric= Container/Pad1/PadN/RPL Target. Want to understand which bits are referenced by this statement and why for = certain options it is not mentioned? Regards, Rahul --_000_MN2PR11MB3565DAABA73E0AF3F712F648D83A0MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rahul

 

I guess we forgot. Reserved is always zero as a gene= ral practice but it is good to say it to make sure  : )

 

All the best,

 

Pascal

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Rahul Arvind Jadhav
Sent: mardi 30 avril 2019 12:01
To: roll <roll@ietf.org>
Subject: [Roll] Unassigned bits of the ... are reserved

 

Hello ROLL,

 

RPL (RFC6550) base objects and options have a couple= of sentences in the context saying,

“Unassigned bits of the [MSG] are reserved.= They MUST be set to zero on transmission and MUST be ignored on reception.= ”

 

This text is present for all base objects including,= DIO/DAO/DAO-ACK/CC.

Also it is present for following options, RIO/PIO/Tr= ansit Information Option/Solicited Information

But it is not present for following options, DODAG C= onfiguration/DAG Metric Container/Pad1/PadN/RPL Target.

 

Want to understand which bits are referenced by this= statement and why for certain options it is not mentioned?

 

<This point was commented upon by Alvaro during r= eview of draft-ietf-roll-efficient-npdao-09>

 

Regards,

Rahul

--_000_MN2PR11MB3565DAABA73E0AF3F712F648D83A0MN2PR11MB3565namp_-- From nobody Tue Apr 30 11:52:38 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBF120043; Tue, 30 Apr 2019 11:52:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155665035621.7536.208543956693234352.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 11:52:36 -0700 Archived-At: Subject: [Roll] Alissa Cooper's No Objection on draft-ietf-roll-useofrplinfo-25: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 18:52:36 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-roll-useofrplinfo-25: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 1 = "An interim meeting went through the 24 cases defined here to discover if there were any shortcuts, and this document is the result of that discussion." These details seem unnecessary to include in an archival document. = Section 3.1 = "[RFCXXXX] represents this document." This is not necessary to include. = Section 9 = "Related to the deployment of RPL, there are no known multivendor deployments outside of the research groups! All known deployments of RPL are in market verticals, with a single vendor providing all components. Research groups typically are using Contiki, RiotOS, or OpenWSN, and these are easily adapted to 0x23 functionality." It seems like this text should be dropped or marked for removal once the RFC is published, since it will likely become out-of-date soon enough. From nobody Tue Apr 30 11:53:33 2019 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 771FA12032C; Tue, 30 Apr 2019 11:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=PF73kDqh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WGGAtLjb 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 TmcZAfYKAGc5; Tue, 30 Apr 2019 11:53:13 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06E912032A; Tue, 30 Apr 2019 11:53:13 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 914DA2228D; Tue, 30 Apr 2019 14:53:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 30 Apr 2019 14:53:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=h 6O3+hJjtEaQ6tdj7vLb1rmgsClQ4rQkNdCWcGBA1kc=; b=PF73kDqhV1tu7Z7wR wpDtolX4ojsChr2mIA0iM2zQpQiYwKyW7kMvCbW6VU3cKWsdB0kngGgDFFLnjogr DVYVdZntXcKOQfqQBpS0wvi1p8pdt/ITapll2kqJ49xdIh1AsB7GQibhM8RANbkj 6Jb8y15/3ylK5xBXF6kagZFkrafFe5f9VEHLTbOr6PG2X+KM/FewDV1VD8qNCFNW HH3W9puxkA6mgljSR6lfqRGouce7CByKbR4IV9kwbqqv0KlUjUA8ItBW9rGB1G62 H+S+QURquuOBwepd9hzkcmG0fMaa1FU8HiQPWxKbUZ9ZdSDvurUs17dyrW5iqeFR EG7qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=h6O3+hJjtEaQ6tdj7vLb1rmgsClQ4rQkNdCWcGBA1 kc=; b=WGGAtLjbxq0uK5ZRv3+uYIufa+bJ3oVL7O4mvH3JmwLOFVN6/Yo/HjPQT Jhm+hpmUBjB0MYOlUFAq/LK3+DpwwAsU4HVIipeIEmUzwRDStgs9Jrz0CBdWOFpX aQ2/rMJfSw19pnFYJUJt36HdQwlRaYAPXA5CyTkz0jJ+0AoU4VtjlbcLBjuIDK23 TJKlT4ys4RWSsoSNzWCS3rsYxNmWv6TrdwIaX9OC7tQREadPLW5T/nOqzRErawBh RzF/jUZIMEJd4FLgKZN882Mc4Yvy1HEs7fwDNN77KrXEnmoBMB2XtTS3Rl1ir9+9 Pyv6XenU2aYraQCMfuC1A3owlP5sg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieehgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejheenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 36CFAE47C4; Tue, 30 Apr 2019 14:53:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <23139.1554939802@dooku.sandelman.ca> Date: Tue, 30 Apr 2019 14:53:09 -0400 Cc: draft-ietf-roll-useofrplinfo.all@ietf.org, General Area Review Team , roll@ietf.org, "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155431284696.22772.5756397598445681320@ietfa.amsl.com> <23139.1554939802@dooku.sandelman.ca> To: Michael Richardson , Russ Housley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Roll] [Gen-art] Genart last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 30 Apr 2019 18:53:17 -0000 Russ, thank you for your review. Michael, thank you for your response. I = entered a No Objection ballot. Alissa > On Apr 10, 2019, at 7:43 PM, Michael Richardson = wrote: >=20 > Russ Housley via Datatracker wrote: >> Section 1 says: >=20 >> ... This document clarifies examples that intend to illustrate the >> result of the normative language in RFC8200 and RFC6553. In other >> words, the examples are intended to be normative explanation of the >> results of executing that language. >=20 >> This set the wrong expectation for me. What the document seems to be >> doing is aligning with the recent normative change in RFC8200. The >> alignment could lead to a flag day, and this document suggests a way = to >> avoid a flag day. It goes through a whole bunch of use cases to >> illustrate the updates. >=20 > So, the actual order of operations was more like: > - we aren't following 2460, so let's write down the right rules > - oh, look, 2460bis is happening, can we get the rules changed? > - cool, it happened, now what does that mean. >=20 > So I'll try to fix the text to match what a reader would now expect. > Can you help with that paragraph? How about: >=20 > } This document provides a series of examples that align RFC6553 > } with the recent changes in processing described in RFC8200. In = other > } words, the examples are intended to be normative explanation of = the > } results of executing that language. > } Existing deployed networks may experience a flag day as a result = of > } some of the suggested changes, and this document provides a way > } to mitigate such an occurance. >=20 >=20 >> Nits: >=20 >> In Table 6, please move some of the whitespace on the right to the >> first column to avoid so many words being split across lines. >=20 > I don't think we control the table formatting, xml2rfc does. > I'll see if I can do something about that. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Apr 30 13:24:49 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9C120146; Tue, 30 Apr 2019 13:24:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155665588791.7542.16300641006212249788.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 13:24:47 -0700 Archived-At: Subject: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 20:24:48 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-roll-useofrplinfo-25: Discuss 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Per Section 11: [RFC2473] suggests that tunnel entry and exit points can be secured, via the "Use IPsec". The suggested solution has all the problems that [RFC5406] goes into. In an LLN such a solution would degenerate into every node having a tunnel with every other node. It would provide a small amount of origin address authentication at a very high cost; doing BCP38 at every node (linking layer-3 addresses to layer-2 addresses, and to already present layer-2 cryptographic mechanisms) would be cheaper should RPL be run in an environment where hostile nodes are likely to be a part of the LLN. ** I'm having trouble understanding what recommendation this text was making. The first sentence seems to suggest IPSec, the second sentence seems to discount that advice; and the third seems to suggest BCP38 as an alternative. Could you please clarify. ** Please be explicit on which challenges in RFC5406 are being cited (e.g., which sections) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Abstract. Per “Additionally, this document updates RFC 6550 to indicate about this change …”, this sentence didn’t parse for me in explaining the relationship with RFC6550. (2) Section 1. Typo. s/implementors/implementers/ (3) Section 2. Editorial Nit. s/header refers to:/header refers to/ (4) Section 3. A few editorial comments on how these updates are presented: ** Inconsistent spacing in Section 3 title: s/Updates to RFC6553, RFC6550 and RFC 8138/ Updates to RFC6553, RFC6550 and RFC8138/ ** Section 3.1 and Section 3.3 open with the motivation for the change. Section 3.2 does not. ** Section 3.3 title describes the proposed change. Section 3.1 and 3.2 simple state “Updates to RFCxxx” ** Section 3.1 – 3 titles include a space in the RFC names (i.e., RFC-space-number). The Section 3 title does not. (5) Section 3.1. Editorial Nit. ** s/[RFC6553] states as shown below/[RFC6553] states as shown in Figure 1/ ** Recommend citing the relevant page and section number from RFC6553 too. (6) Section 3.2. Please use more explicit language to describe how this section updates RFC8138. (7) Section 3.2. Figure 3 is depicted in this section but not referenced in the text. (8) Section 4. Typo. s/A RPL Stack is shown in Figure 5/A RPL Stack is shown in Figure 6/ (9) Section 5. Editorial Nit. s/these nodes are/These nodes are/ (10) Section 5. A few editorial recommendations for this paragraph: The uses cases describe the communication between RPL-aware-nodes, with the root (6LBR), and with Internet. This document also describe the communication between nodes acting as leaves that do not understand RPL, but are part of the LLN. these nodes are named as not-RPL-aware-leaf, mentioned previously. (e.g. Section 6.1.4 Flow from not-RPL-aware-leaf to root) This document describes also how is the communication inside of the LLN when it has the final destination addressed outside of the LLN e.g. with destination to Internet. (e.g. Section 6.2.3 Flow from not-RPL-aware-leaf to Internet) ** s/these nodes are/These nodes are/ ** The sentence “This document describes also how …” doesn’t parse. ** The use of “(e.g. …)” as a standalone sentence doesn’t parse. (11) Section 5. Per “There is some possible security risk when the RPI information is released on the internet …”, I recommend reframing this text around the fact that the leak of RPI info would not present an issue. As is, the impact reads ambiguously to me. (12) Section 6. The meaning of “root” in Figure 7 is not explained in the text above it. (13) Section 6.1.4. Typo. s/encapsuladed/encapsulated/ (14) Section 9. Editorial Nit. s/ During bootstrapping the node get the DIO with the information of RPL Option Type/ During bootstrapping the node gets the DIO with the information of RPL Option Type/ (15) Section 11. Make BCP38 a reference (i.e., [BCP38]) From nobody Tue Apr 30 16:07:59 2019 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 D98A31200A3 for ; Tue, 30 Apr 2019 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 y0wIzyKk7ykI for ; Tue, 30 Apr 2019 16:07:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6011203DE for ; Tue, 30 Apr 2019 16:07:55 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 093B73826B for ; Tue, 30 Apr 2019 19:07:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F386CEA0; Tue, 30 Apr 2019 19:07:53 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F12AA926 for ; Tue, 30 Apr 2019 19:07:53 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <982B626E107E334DBE601D979F31785C5DE82645@BLREML503-MBX.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DE82645@BLREML503-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Unassigned bits of the ... are reserved X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 30 Apr 2019 23:07:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rahul Arvind Jadhav wrote: > RPL (RFC6550) base objects and options have a couple of sentences in = the > context saying, > =E2=80=9CUnassigned bits of the [MSG] are reserved. They MUST be set = to zero on > transmission and MUST be ignored on reception.=E2=80=9D > This text is present for all base objects including, DIO/DAO/DAO-ACK/= CC. > Also it is present for following options, RIO/PIO/Transit Information > Option/Solicited Information > But it is not present for following options, DODAG Configuration/DAG = Metric > Container/Pad1/PadN/RPL Target. > Want to understand which bits are referenced by this statement and wh= y for > certain options it is not mentioned? I think that it's an omission, that all reserved bits should be set to zero and ignored. I don't think we have good IANA text on how to allocate them, so I would assume it takes an IETF Standards Action, which your document is. > draft-ietf-roll-efficient-npdao-09> =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzI1UkACgkQgItw+93Q 3WVojwf/bsnpMOeui7vJ9HeVIH9dKjuPoLGMS6BqCFUdTDaXyuTrnIpKbnQB8XMT sayTJ8x2NPSjzeZi40aeFkLeBEMVysOCPjKvID92iKKwffGAWRnVp/CBbJCZB7P8 brvmslX/ER7e6HO5+O0yuzZxMMCcqfMye26C+6tHdEYWGtqouRjDvBDQwHr2qj+/ QpacyT6HWtc9vrr/G5gXz4oSYoA+TryHzKxit4sjXRzoKxrVGak2lbBSoT7Rmjs0 t6nmTCcxDK5rRMdc1CFKdPQnUMcd38PpaHnw4otQaTYA26TioSTtpyS88qpn/oVp nEJtQwKrRbaPGQxXy8QMwpQ1fNY8oA== =vHHS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 30 21:27:34 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330AE1200B1; Tue, 30 Apr 2019 21:27:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155668484520.29014.7741405460230963379.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 21:27:25 -0700 Archived-At: Subject: [Roll] Adam Roach's No Objection on draft-ietf-roll-useofrplinfo-25: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 04:27:25 -0000 Adam Roach has entered the following ballot position for draft-ietf-roll-useofrplinfo-25: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have only one minor comment. I'm a bit perplexed by the interplay between sections 3.1 and 3.3. Section 3.1 says: > This change creates a flag day for existing networks which are > currently using 0x63 as the RPI value. And then section 3.3 says: > In order to avoid a Flag Day caused by lack of interoperation between > new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag > in the DIO Configuration Option... Which leaves me wondering whether the net effect of this document does or does not create a flag day for networks. Please consider updating these sections to be consistent with each other.