From nobody Thu Jul 1 02:23:14 2021 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 4EE4A3A1390 for ; Thu, 1 Jul 2021 02:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, 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 bMpiOC-FqQsD for ; Thu, 1 Jul 2021 02:23:08 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9693A138E for ; Thu, 1 Jul 2021 02:23:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 2A0DA603688CF for ; Thu, 1 Jul 2021 11:23:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zUeKG5qTiJnJ for ; Thu, 1 Jul 2021 11:23:02 +0200 (CEST) Received: from [IPv6:2001:6a0:5001:2:903b:9dd8:7a5b:693a] (unknown [IPv6:2001:6a0:5001:2:903b:9dd8:7a5b:693a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA for ; Thu, 1 Jul 2021 11:23:02 +0200 (CEST) To: Routing Over Low power and Lossy networks References: From: Konrad Iwanicki Message-ID: Date: Thu, 1 Jul 2021 11:23:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] ROLL Interim Meeting - 31th August- 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, 01 Jul 2021 09:23:13 -0000 Dear Chairs, I would be interested in having a session on: https://datatracker.ietf.org/doc/draft-iwanicki-roll-rnfd/ I have no experience to give a precise duration, but I would estimate something between 30-45 mins. I will be the presenter. Best, -- - Konrad Iwanicki. On 30.06.2021 12:10, Ines Robles wrote: > Dear all, > > Thank you very much for filling the doodle. The date selected is 31th > August at 3pm UTC. > > Please let us know if you would like to Present a topic by 30th July > specifying: > > - Topic > - Duration > - Presenter. > > Further meeting details (webex, codimd, etc.) will be provided later. > > Thank you very much in advance, > > Ines and Dominique. > > > On Mon, Jun 7, 2021 at 12:57 PM Ines Robles > > > wrote: > > Dear all, > > We would like to organize an interim meeting. Thus, we kindly > request to let us know your availability by filling the following > doodle by *12th June. * > * > * > https://doodle.com/poll/nd3z4wyar6tqudcv?utm_source=poll&utm_medium=link* > * > > Thank you very much in advance, > > Ines and Dominique. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Fri Jul 2 15:26:58 2021 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 30C473A1129; Fri, 2 Jul 2021 15:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 GrOc03RiwjQ0; Fri, 2 Jul 2021 15:26:44 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D0C3A120D; Fri, 2 Jul 2021 15:25:47 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GGqRD5b0dz2xGy; Sat, 3 Jul 2021 00:25:44 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 646957545.3131779-a3fcb51a88f94abf43925774da3a25eb Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <873BE539-1A57-4370-A8A5-9E34B4097911@tzi.org> Date: Sat, 3 Jul 2021 00:25:45 +0200 To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan@ietf.org, lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF111: "FINAL" AGENDA 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, 02 Jul 2021 22:26:57 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF111. Remember that further agenda changes can still happen. A number of changes have been made with respect to the draft agenda. Most notably, IOTOPS has moved on top of SECDISPATCH (was on top of RATS), but LAKE stays on RATS. All times *on my agenda* are in UTC (the default page is UTC-0700). Please forgive the 2430 and 2500, I'm way too lazy to write code to turn this into 0030 and 0100. (And it is advisable to ignore the fictional end time of the Wednesday plenary anyway.) https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 19, 2021 1900-2100 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, July 23, 2021 1900-2100 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, July 26, 2021 1900-2100 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - New Internet Protocols & Practical Congestion Control Rm 3 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 2130-2230 Session II Rm 1 ART wpack Web Packaging WG Rm 2 IRTF irtfopen IRTF Open Meeting Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG babel Babel routing protocol WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvwg Transport Area Working Group WG 2300-2500 Session III Rm 2 ART jsonpath JSON Path WG Rm 3 IRTF coinrg Computing in the Network Research Group Rm 5 OPS *** iotops IOT Operations WG Rm 8 SEC secdispatch Security Dispatch WG Rm 9 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, July 27, 2021 1900-2100 Session I Rm 1 ART sedate Serialising Extended Data About Times = and Events WG Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Interconnection and Routing & Monitoring Internet Traffic Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 6 RTG raw Reliable and Available Wireless WG Rm 7 SEC *** danish DANE AutheNtication for Iot Service = Hardening BOF Rm 8 TSV quic QUIC WG 2130-2230 Session II Rm 3 ART httpapi Building Blocks for HTTP APIs WG Rm 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG Rm 7 SEC saag Security Area Open Meeting Rm 8 TSV taps Transport Services WG 2300-2500 Session III Rm 7 SEC ohttp Oblivious HTTP BOF WEDNESDAY, July 28, 2021 1900-2100 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services BOF Rm 4 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Privacy & Applications Rm 7 SEC tls Transport Layer Security WG 2130-2230 Session II Rm 2 ART uta Using TLS in Applications WG Rm 4 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 5 INT *** drip Drone Remote ID Protocol WG Rm 8 RTG rift Routing In Fat Trees WG Rm 9 SEC *** cose CBOR Object Signing and Encryption WG 2300-2440 IETF Plenary - Plenary THURSDAY, July 29, 2021 1900-2000 Session I Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 OPS v6ops IPv6 Operations WG Rm 7 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvwg Transport Area Working Group WG 2030-2130 Session II Rm 5 IRTF qirg Quantum Internet Research Group Rm 6 RTG rtgarea Routing Area Open Meeting Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 2200-2300 Session III Rm 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 2330-2430 Session IV Rm 4 IRTF panrg Path Aware Networking RG Rm 8 SEC emu EAP Method Update WG Rm 9 SEC *** teep Trusted Execution Environment = Provisioning WG FRIDAY, July 30, 2021 1900-2100 Session I Rm 1 ART webtrans WebTransport WG Rm 2 INT add Adaptive DNS Discovery WG Rm 5 RTG apn Application-aware Networking BOF Rm 6 SEC *** suit Software Updates for Internet of Things = WG 2130-2230 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 IRTF maprg Measurement and Analysis for Protocols Rm 5 RTG detnet Deterministic Networking WG Rm 6 SEC acme Automated Certificate Management = Environment WG Rm 7 SEC privacypass Privacy Pass WG 2300-2500 Session III Rm 1 INT intarea Internet Area Working Group WG Rm 2 IRTF cfrg Crypto Forum Rm 3 IRTF*** dinrg Decentralized Internet Infrastructure Rm 7 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 8 TSV (!) tsvarea Transport Area Open Meeting From nobody Mon Jul 12 07:06:57 2021 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 420D33A1AB5; Mon, 12 Jul 2021 07:06:40 -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: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <162609880022.9188.17988296142764892842@ietfa.amsl.com> Date: Mon, 12 Jul 2021 07:06:40 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-18.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: Mon, 12 Jul 2021 14:06:46 -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 : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Matthew Gillmore Filename : draft-ietf-roll-dao-projection-18.txt Pages : 53 Date : 2021-07-12 Abstract: This document extends RFC 6550 and RFC 6553 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 07:16:25 2021 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 BDD903A19D6 for ; Mon, 12 Jul 2021 07:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.696 X-Spam-Level: X-Spam-Status: No, score=-7.696 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=crhQcyJm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nRHUPC6K 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 XieRgIfDP1z3 for ; Mon, 12 Jul 2021 07:16:19 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529213A215C for ; Mon, 12 Jul 2021 07:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6406; q=dns/txt; s=iport; t=1626099231; x=1627308831; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Vhue3TgnD2hvZVyLMtFLcrLN5MANEzi/jFDDp3YxD2M=; b=crhQcyJmoroT52Rb77JiLSJHcPolHQm6ZZ/XB9bEDq23iox4eawKxKuO xRIuwZU+/9uKtzdVndjGjf4emzhjAdHTniDX99QwFSNGFKjmTHTmip+nm kyQHTNFxfKv6vD/1f62v051TNFMXfcfQFIoWcX1rpBO41ndnIm2abB437 s=; X-IPAS-Result: =?us-ascii?q?A0AWAwAVTexgl4ENJK1agQmBWYFTUX5aNzGIEAOFOYhXg?= =?us-ascii?q?ROOV4IgEogRgS4UgREDVAsBAQENAQE3CgQBAYRUAoJ4AiU2Bw4CBAEBAQEDA?= =?us-ascii?q?gMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohWgNhkcEEy4BATgEDQGBACYBB?= =?us-ascii?q?AEaGoJPAYJVAw4hAQ6dDgGBOgKKH3iBNIEBggcBAQYEBIE1AQMCDkGDIhiCM?= =?us-ascii?q?gmBOoJ7ixccgUlEgRREgWFKg1cBAQIBgSMFARIBAwgEFINLgi6CKRFCDQxEG?= =?us-ascii?q?wsBA0oHAQEgAjU6PDwjHi2RGQgHN40jggSJTZITCoMkBYosimaJNhKDY4FHi?= =?us-ascii?q?haGO5BXlgKMLpNPBIELg3QCBAIEBQIOAQEGgWINJWtbDgdwFRohgmkJRxkOj?= =?us-ascii?q?isNCYNOhRSFSnM4AgYKAQEDCYlxgkYBAQ?= IronPort-PHdr: A9a23:+JxGyhLEU8JG/X8+ONmcuX0yDhhOgF28Fg8Y9pRhjKhBIeyv/JXna UrY4/glzFrERp7S5P8Mje3K+7vhVmoN7dfk0jgCfZVAWgVDhZAQmAotU8+IFUO9K+TlPGQ2G c1YXwpj+He2eUFeBMf5YQjUpXu/pT4fExnyL0x7POPwT4XTlM+wkeu1/s67Xg== IronPort-HdrOrdr: A9a23:HpNib67OpYQst/qJ2QPXwMLXdLJyesId70hD6qkRc202TiX2ra 2TdZgguSMcqQxhPE3I+urwW5VoI0m8yXcd2+B4Vt2ftW/d11dAR7sD0WKN+VPd8lbFh4tgPV MJSdkYNOHN X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,234,1620691200"; d="scan'208";a="722862971" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jul 2021 14:13:50 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 16CEDnHY016776 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 12 Jul 2021 14:13:49 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 12 Jul 2021 09:13:49 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 12 Jul 2021 10:13:48 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 12 Jul 2021 09:13:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R2XWrJgO8hcvKWdp45TuMOtFuAyl9XIp9fhRQ9hKaO/BZ0Fbyvu+eEwecwJBfx3uw/cz8qohgo+IegtlHxoctpAM2oOlpZIP4wXQEz/M3pPPrJ3jY2Icb3z8my8LfYBiW/edLc04zUHpLjoylhAyjCgvPhIWaKWUb7s0QfvRfunkNgPmAqqdkS3zPtHpNPfMknF994vpvyIkdfY9fXOrbyOv1DeC82xZKNeIO6MpVSNKdkio8f5DercsXrHE7su8U8w8TK9vcqvuF0Yf4RMXREo6thnDNnFBjnTBye0TBvkVmjMYp1N+x9bDf9foPJgc5M0O1ksWVQ5X/7gPxTslgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8sUyotRSUOz3ItnqAKb9g2916q6X1Blhj7KMF7eP2kk=; b=Pi0LrWrhpFl6g1QTRSpZ/5MHxSmB/uumPXmd15QqVvGvSe23eWdfxH/mVYPWO32wxH7Zrh73BL+rtnFOyokVgEFd6cKCyUcLFsBiP/cbuyMDqjOAsiXbtdFhWcxHZC3hUx/QHhgmPHaqFa1LYx6rRAON2tw6b6j5tOlXK5phuXBKRC9N2gIEwRa0w0MbBLceyJ8KQJgvK+FNFsIiI7E2VyQ8Q25vTjfEiAkK+mobcBI7JxUslARJRvD4rO/HMsF6oDg7bN+lYjgU4GJRQYwYMe3Y1MoMbQOMfoVhiaob2/R2fXQBte5/PJKQqQnpxkuWMLYK76oIS9ngs5Vvjg47fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8sUyotRSUOz3ItnqAKb9g2916q6X1Blhj7KMF7eP2kk=; b=nRHUPC6KdinyKgdFZOvC7R25ImOIB2MamQ0tEeJijoOUsd9WgluOkKR8I4wm+wNCQJGA3UFOQwofoOWVBVnY7ZevIYFNmViMqgKjBTRVbk/Nn++9++wEQ9NeB+TqPxEj2axvRm7TZCTf11XjRmvC8Rz6FeWw9q/Yi9ZXs83b3P0= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4852.namprd11.prod.outlook.com (2603:10b6:303:9f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Mon, 12 Jul 2021 14:13:47 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1c75:fcc9:2c53:3af6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1c75:fcc9:2c53:3af6%5]) with mapi id 15.20.4308.026; Mon, 12 Jul 2021 14:13:47 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" , Michael Richardson Thread-Topic: Open issues from Michael's late response at adoption call Thread-Index: Add2/q+7Z7Acu3tvSkujMg+r6F8BFw== Date: Mon, 12 Jul 2021 14:13:23 +0000 Deferred-Delivery: Mon, 12 Jul 2021 14:12:38 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 647ca8ef-648a-4046-8b0b-08d9453f43b4 x-ms-traffictypediagnostic: CO1PR11MB4852: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uGQzR/xnLiMiICSuk5U6pNpiZv+fpp9uOBf+8xVd1Pp9g5C5nXnGfL3JLqYonm1QE+KYtEk0in/C7+gMiNc1ICzhrR/xu1zj55thXUvJU+L19+voR8fMcd5JYZfqSV7vUvc2qS7tSZtqQ4JIv7XqXD1irepZkvY42M1fLlTCgQNDlRq0rcmOwIlym+0IHvvRubId28+vLBOIYThiOrJ30PKzGn0LfwK2QRq9Q0xl5+PBm4uU/3uBdnarTCbYn02tFruADDGJ+h3IjdH9fiiG8TeepUVXJ9e2Bn5v+h0kOXO3Ll0wo6/Xc66gnC+flXpWRDaBCjAAH31Xf94/AoTcDHCyYa5s18yNuymCe608jaxDFztIchuNtPVo4rM279wFuEhkfsFWsp9GrRStsTiJaFIaCN4Ef6AVRCDKOGdmTbKAQg68SyvfDo3CEshGJI+OVcg91bNmkhtRzzQEtloNL27sMO6VLHUSJboIihp9ZSGBRts85WJddtIRw37R8CtPEmifX1XuAvTHkVLXloIlNChm6Ewfv+ntjJaOihAcWv+EcMgTuKR5O07yhdpQFhNm138qFChhBweqYdCRJBx1yg4l4iDQvCiTDsu3uEfJ0iypUHGJ8gP6bZoI3ftQ3i5gQVaZTzYPWnj+9G3KIAzLIrvKUz75IcHUtHc9fqL3kvnsNZc6iFwnT5Z+BSAkmbaODKagL0AsIwmfDksCfP8lYA2uxD1Ug65eLz2Wtv+p8gC4sohTmcUfbPoxyj5rUfrKYrra9dCTnij+HW/9cR5I5A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(346002)(136003)(376002)(366004)(33656002)(66574015)(8676002)(38100700002)(66446008)(6506007)(2906002)(9686003)(186003)(478600001)(76116006)(6666004)(8936002)(122000001)(316002)(966005)(110136005)(71200400001)(5660300002)(64756008)(86362001)(66476007)(7696005)(52536014)(55016002)(66556008)(66946007)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TvL4hPgPlixgXti/v3g/mq3rLZ+4dIwL5Ps7KgH3ZcZBA191zQ4mOj37n7?= =?iso-8859-1?Q?hAYc7Lz7KRomN5EQ81I/n7N3ea49+3XRyDGN7MFRR2wWgLJi6EaF4miz1a?= =?iso-8859-1?Q?0k8VZw0f6xEmY4TmLKca0LAa82oadPAWHe80lqjDrFFiKzcaJhiQxQaUaW?= =?iso-8859-1?Q?WGLCeeYHl0JPRAIlNrS8Ienpwwyeo3iDsJCaosru6360jLd2WOKPduLal4?= =?iso-8859-1?Q?P8BIK3KTnmR9sOT8SxybqUP4NfzUrAh4W3+tC15Pxq8sqBPmvgUbo+3wJ/?= =?iso-8859-1?Q?9jswTl0hD2iv5ezTcMdJCgwIiBqzeieXOY+Y2gkgmmoS1ug5H8ohEv4QJ9?= =?iso-8859-1?Q?KWcfLd/i30Q+E3nwE2jGanbBOPuHBPbRSesSyAbi+dCyex3hEXpJYHehho?= =?iso-8859-1?Q?FvRqI/xrRU/5rzyZUrMWJgnZi/9A2bzsWPM3AaWgxMeRenbqxHCIEQcWMp?= =?iso-8859-1?Q?jhM0xVD06ntYSXi4WqOyy56x+zPduZpxGMUupjVuQjW6LrMaLDbjdBEdtt?= =?iso-8859-1?Q?H4J2FVRpMna7iYhKiKqy0eZg07aPnKExhE3viUuDaABKtbwJ31KbiOBinW?= =?iso-8859-1?Q?hA5euzPwtGBwl3ArDOQ9przXrOQ9dSyS6TIYBRKDLxNKiHTdprPJvnhMKQ?= =?iso-8859-1?Q?XyEKHhOQFdKm+Fzx1ayluVjpXLi5ZUSxbudpHwIQVAcXvmL9Uhp66TgUpK?= =?iso-8859-1?Q?VovZFz9NdLVHEwUk/i5PJkr0tDUQwVHvkXS+WgtP+C0F9we1x3KbsaH3ZH?= =?iso-8859-1?Q?t4i1LlkmtrnPXQZNEO5HrJsNVy9eHrqyntbHWzH/A0mh1z8+/X2KS5kmfB?= =?iso-8859-1?Q?OdqXI8MZay6ouQhtC477r2CjgFaEkpZsmC/Qvsk98rjqa/EYZPwXUBktp4?= =?iso-8859-1?Q?ffYLYsgG9QNvMOC7YqYVlRMfe9UbGoz68wsBvdSq0Eb6WFELWBM54Eiu7W?= =?iso-8859-1?Q?HFuIUuUtYRZ8TsX2lq2ZTyyzjNlC7FupvZpmCrPwZnViFOx2aL8a/NSDis?= =?iso-8859-1?Q?PRnSFgDDiXIhNCJj+rvEPGhXl0VtEocTgquLKZ5ontPo0Ij2zfFJpXYoYC?= =?iso-8859-1?Q?wLaYCo+kVqEgHW3N4LzraH+gY/Pppp7JHXZueBqiYxqjtFVTwBAglCx2Ht?= =?iso-8859-1?Q?MHr0u6tgZ7f/M28jjGKYkxfsdK8K7Nga2RUE9Cr37hPveA/23/VUK7zKcz?= =?iso-8859-1?Q?p93j6xmFmtCJ7h7I2RZOJM1dhwpR0VCtopzOTf4NctQEPadEY0Eo4bgqdP?= =?iso-8859-1?Q?e+0CGnQS5SZw8Qu7xL2Roi7EPEpxDg1FsWDEsxs6vCWFwLeRk22UlJhLp1?= =?iso-8859-1?Q?pOouliCN/RfLD+WLYqcJmuMKAAzBhK9Ei99NNvBuGQDZBUKgVnnCaWBmlz?= =?iso-8859-1?Q?cM0c7WLrNE5s/VyxcPRpYvBajkTsANy5JLROhigpECXcjWApjRlJvmZOvp?= =?iso-8859-1?Q?5ynxoivHd54UOhD2?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 647ca8ef-648a-4046-8b0b-08d9453f43b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 14:13:47.0190 (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-CrossTenant-userprincipalname: zVqldkD5+12Yw//s4ETCm0YJ6OT+aaNzFQ2M8PyZSzoevY8qchg07KSlp7PhtmqnCare4nn+Ay6THKeDQWORjg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4852 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [Roll] Open issues from Michael's late response at adoption call 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: Mon, 12 Jul 2021 14:16:25 -0000 Dear all Ines pointed out an active ticket https://trac.ietf.org/trac/roll/ticket/17= 9 and https://trac.ietf.org/trac/roll/ticket/180 against the DAO projection= draft. It was logged at adoption call time and I failed to respond properl= y.=20 This was against https://datatracker.ietf.org/doc/html/draft-thubert-roll-d= ao-projection-03 , water under the bridge so I tried to sort things out and= published https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projec= tion-18 as a result. In more details: > Michael Richardson wrote on 12-24-2016=20 > Hi, I had intended to finish this as part of the adoption call, having pr= eviously read the document, but was late.=A0 These comments are probably mo= re useful now anyway.=A0 I can open tickets as appropriate if chairs direct= .=20 > Let me leave editorial comments to the end of this email.=20 > 1) Didn't we have an errata about default lifetime units when there was n= o configuration option?=20 > No, we didn't.=A0 I wonder if this plagues us everywhere, that 6550 shoul= d have specified a default Lifetime units in the absence of a Configuration= option.=20 I think that was by design. RPL can be used in a great many environments wi= th lots of diversity, from high speed wires in ANIMA to 2Kps LLNs. Couple t= hat with any size of netwoks, with cases of ~10K sometimes. A default value= can be programmed for a particular use case, say Wi-SUN, and in that case = the SDO that leverages RPL will define it for its own purpose. > 2) http://tools.ietf.org/html/rfc6551 reference: "or the RPL routing ext= ensions specified in Routing for Path Calculation in LLNs [RFC6551].=A0 Bas= ed on that information, the root " > huh? the title of 6551 is: Routing Metrics Used for Path Calculation in L= ow-Power and Lossy Networks=20 > so, what exactly did you mean here?=20 I'd read this as: Additional metrics used for routing decision - indirectly= , via the Rank computation by the OF But then I could not find that text in early or current versions, so I gues= s this issue disappeared? > 3) does dao-lifetime eclipse need for no path dao?=20 Same as main RPL. Some users might let the route die if signaling is expens= ive.=20 > 4) resource calculations "but how the root figures the amount of resource= s that are available is out of scope."=20 > I disagree. I would like some mechanism to be in scope.=20 > And you suggest NMS and 6551 later on... which seems to make it in scope.= I'm not sure how 6551 can be used here.=20 We agree. The capabilities draft will do that when we find time to work on = it. > 5) section 4 needs subsections! Too many concepts in one heading.=20 This was " 4. Loose Source Routing in Non-storing Mode ". It is now " A.1.= Loose Source Routing " only 4 paragraphs. The rest was spread as suggeste= d > 6) On the use of a new MOP.=20 > Are we sure that we need a new MOP?=A0 Could we use Non-Storing MOP, with= some indication of which nodes speak DAO-Projection?=A0 Could that work?=20 > Or do you really want to force a forklift upgrade here? Why does the enti= re network need to be aware of this new mode?=20 Agreed, this is gone now > 7) page 8 is too dense!=20 Was split and expanded. I consider that fixed > 8) I just didn't understand the english here.=20 > I think that "last node" needs a better term.=A0 Maybe colour the nodes o= r otherwise mark them and use those terms?=20 > The last node in the segment may have another information to reach the ta= rget(s), such as a connected route or an already installed projected route.= =A0 If it does not have such a route then the node=20 This is gone > 9) running out of resources:=20 > it seems that it ought to be said that the new node might not be one that= the last node had previously talked to.=A0 There is the issue of both rout= ing storage (from storing mode), but also neighbor cache resources.=20 Can't find the related text in any version. But the neighbor cache is creat= ed before the sibling is advertised, so the lack of it os not found at rout= e creation time. > 10) more hard to understand statements...=20 > For the targets that could be located, last node in the segment generates= a DAO to its loose predecessor in the segment as indicated in the list of = Via Information options.=20 > woe!=A0 What?=20 I hope the explanation is better now. The storing mode DAO flows from egres= s to ingress as a the normal DAO flows from leaf to root. > 11) create new section on route cleanup=20 > A NULL lifetime in the Via Information option along the segment is used t= o clean up the state.=20 > needs new 4.x section on cleanup.=20 Please see "7.3.1. Storing-Mode P-Route" in -18. I split as suggested > 12) move / replicate diagrams into this section, and use numbered diagram= s=20 > In the example below, say that there is a lot of traffic to nodes 55=20 > new section, move diagram here.=20 > make figure 5 and 6 more like figure 3, numbered, etc.=20 done > 13) Q: retransmission timers, etc. appropriate for these projected DAO me= ssages?=20 > How do we handle packet loss?=20 Added text " The process continues till the P-DAO is propagated to ingress router o= f the Segment, which answers with a DAO-ACK to the Root. The Root always= =20 expects a DAO-ACK, either from the Track Ingress with a positive statu= s or from any node along the segment with a negative status. If the DAO-= ACK is not received, the Root may retry the DAO with the same TID, or tear down the route. " > 14) Security Considerations will need to be written.=20 > The security threats documents details very specific threats, and indicat= ing if this protocol changes things is important.=A0 Also, some considerati= on SHOULD be given to when A=3D1.=A0 Are the affects of the new flow of con= trol messages?=20 > So for instance Security Considerations should probably consider how proj= ected DAO messages could be abused by=20 > a) rogue nodes b) via replay of messages c) if use of projected DAO messa= ges could in fact deal with any threats?=20 I created a security section in line with that of RFC 9010. I hope and believe that this removes the road block to go for last call.=20 You all keep safe! Pascal From nobody Tue Jul 13 10:15:13 2021 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 E3C403A0E37 for ; Tue, 13 Jul 2021 10:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=googlemail.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 Rj_3AMskixFw for ; Tue, 13 Jul 2021 10:15:07 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 3A5263A0E2D for ; Tue, 13 Jul 2021 10:15:07 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id f4so9067174vsh.11 for ; Tue, 13 Jul 2021 10:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YKZg9+SeGeb/WZCU7Skm0Z5MJ9LTzo4IjYUp1CATrr8=; b=j38NnhfPsw10niYyAlxwE5l3idiAMbSfJWj4SOQ9MEzSHAIbT1cs+tuMtrtoTJxEl2 J70riSzz5yNpvxL1Xz4VAJUrpyW+A+yJ8DSoSsKyL3+qqmUeNpt+ogUjG43FIgqMDVHp RXmR4FLGSYiKmKbHFMuRyVdvmzjTQMBiJhZuQWmtyf7jbwcJU9GkmI+trF6NRWKoBVfS m+KeB4mAyKIqO3PjsDo9ZrBvqSOAzpWi+pSgJ19jIR3CDRMSzgu5lzQ5loGIb2XCeOXO BOIwrzHxN7CLjCLel6X2h8qlauEzFM6T3zAcB9qVOh2efP8OdUBDdaqsFZCzBQqBVQyM gDUg== 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=YKZg9+SeGeb/WZCU7Skm0Z5MJ9LTzo4IjYUp1CATrr8=; b=ThZMU5UMGhot98+uPOKYFzOpzIns4w95RFaxEg9QAN22Y7zXXOxWTkIl+m0wiUMwe1 MDTt0dA860dnO8/th5+TkvVfwElvTdklCY8vnahBVk0kXK03ByaO4Z2JPotT+nDDULrS K/JgOnTAHxIZ69xvBfbBGQyZ2rWMm6GKWsHg0iEL9fN7Rqz7Kl11uzZm5J66CHP5NISC 5Mx4v5pGbFcMmieLYRexmpotN+bt2yfzodGWbvUYOfigkRBpGuenYP6ci7zTmTPlsWNs G8jU++TlVCmI62Mo2nAJxrPItF/VAKCnkRowjPQVkvyBN3UgWonfkAXt5gASQwdGj678 yTlw== X-Gm-Message-State: AOAM5303lmCIiPxkqmonAD/hiM+3VBvwgNOPy/b8mcC/uU7hHooC5t/I jvs5I2ki9rxAZFDc7loqzCjZqrfE7BZo7rH9kzPRhdrn X-Google-Smtp-Source: ABdhPJz4KrKWhrRuuHSVYa7U/bXzb8GUx0IzSOD6XEMo8aq23FkBvV0jhtgtZ/1qqvi8m5rpGHuL2ixEm5skY2Bj5ok= X-Received: by 2002:a05:6102:2155:: with SMTP id h21mr7526491vsg.34.1626196505375; Tue, 13 Jul 2021 10:15:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Tue, 13 Jul 2021 20:14:20 +0300 Message-ID: To: Routing Over Low power and Lossy networks Cc: Michael Richardson Content-Type: multipart/alternative; boundary="00000000000009bb0605c704618f" Archived-At: Subject: Re: [Roll] Open issues from Michael's late response at adoption call 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, 13 Jul 2021 17:15:12 -0000 --00000000000009bb0605c704618f Content-Type: text/plain; charset="UTF-8" Thank you very much Pascal for addressing the open issues. We would like to have one or two deep reviews before WGLC. Dear all, please let us know if you can perform a review to dao-projection draft by 23th July. Thank you very much in advance, Ines. On Mon, Jul 12, 2021 at 5:18 PM Pascal Thubert (pthubert) wrote: > Dear all > > Ines pointed out an active ticket > https://trac.ietf.org/trac/roll/ticket/179 and > https://trac.ietf.org/trac/roll/ticket/180 against the DAO projection > draft. It was logged at adoption call time and I failed to respond > properly. > > This was against > https://datatracker.ietf.org/doc/html/draft-thubert-roll-dao-projection-03 > , water under the bridge so I tried to sort things out and published > https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection-18 > as a result. > > In more details: > > > Michael Richardson wrote on 12-24-2016 > > Hi, I had intended to finish this as part of the adoption call, having > previously read the document, but was late. These comments are probably > more useful now anyway. I can open tickets as appropriate if chairs > direct. > > Let me leave editorial comments to the end of this email. > > > > 1) Didn't we have an errata about default lifetime units when there was > no configuration option? > > No, we didn't. I wonder if this plagues us everywhere, that 6550 should > have specified a default Lifetime units in the absence of a Configuration > option. > > I think that was by design. RPL can be used in a great many environments > with lots of diversity, from high speed wires in ANIMA to 2Kps LLNs. Couple > that with any size of netwoks, with cases of ~10K sometimes. A default > value can be programmed for a particular use case, say Wi-SUN, and in that > case the SDO that leverages RPL will define it for its own purpose. > > > 2) http://tools.ietf.org/html/rfc6551 reference: "or the RPL routing > extensions specified in Routing for Path Calculation in LLNs [RFC6551]. > Based on that information, the root " > > huh? the title of 6551 is: Routing Metrics Used for Path Calculation in > Low-Power and Lossy Networks > > so, what exactly did you mean here? > > I'd read this as: Additional metrics used for routing decision - > indirectly, via the Rank computation by the OF > But then I could not find that text in early or current versions, so I > guess this issue disappeared? > > > > 3) does dao-lifetime eclipse need for no path dao? > > Same as main RPL. Some users might let the route die if signaling is > expensive. > > > 4) resource calculations "but how the root figures the amount of > resources that are available is out of scope." > > I disagree. I would like some mechanism to be in scope. > > And you suggest NMS and 6551 later on... which seems to make it in > scope. I'm not sure how 6551 can be used here. > > We agree. The capabilities draft will do that when we find time to work on > it. > > > 5) section 4 needs subsections! Too many concepts in one heading. > > This was " 4. Loose Source Routing in Non-storing Mode ". It is now " > A.1. Loose Source Routing " only 4 paragraphs. The rest was spread as > suggested > > > 6) On the use of a new MOP. > > Are we sure that we need a new MOP? Could we use Non-Storing MOP, with > some indication of which nodes speak DAO-Projection? Could that work? > > Or do you really want to force a forklift upgrade here? Why does the > entire network need to be aware of this new mode? > > Agreed, this is gone now > > > 7) page 8 is too dense! > > Was split and expanded. I consider that fixed > > > 8) I just didn't understand the english here. > > I think that "last node" needs a better term. Maybe colour the nodes or > otherwise mark them and use those terms? > > The last node in the segment may have another information to reach the > target(s), such as a connected route or an already installed projected > route. If it does not have such a route then the node > > This is gone > > > > 9) running out of resources: > > it seems that it ought to be said that the new node might not be one > that the last node had previously talked to. There is the issue of both > routing storage (from storing mode), but also neighbor cache resources. > > Can't find the related text in any version. But the neighbor cache is > created before the sibling is advertised, so the lack of it os not found at > route creation time. > > > > 10) more hard to understand statements... > > For the targets that could be located, last node in the segment > generates a DAO to its loose predecessor in the segment as indicated in the > list of Via Information options. > > woe! What? > > I hope the explanation is better now. The storing mode DAO flows from > egress to ingress as a the normal DAO flows from leaf to root. > > > > 11) create new section on route cleanup > > A NULL lifetime in the Via Information option along the segment is used > to clean up the state. > > needs new 4.x section on cleanup. > > Please see "7.3.1. Storing-Mode P-Route" in -18. I split as suggested > > > 12) move / replicate diagrams into this section, and use numbered > diagrams > > In the example below, say that there is a lot of traffic to nodes 55 > > new section, move diagram here. > > make figure 5 and 6 more like figure 3, numbered, etc. > > done > > > 13) Q: retransmission timers, etc. appropriate for these projected DAO > messages? > > How do we handle packet loss? > > Added text > " > The process continues till the P-DAO is propagated to ingress router > of > the Segment, which answers with a DAO-ACK to the Root. The Root > always > expects a DAO-ACK, either from the Track Ingress with a positive > status > or from any node along the segment with a negative status. If the > DAO-ACK > is not received, the Root may retry the DAO with the same TID, or tear > down the route. > " > > > > > 14) Security Considerations will need to be written. > > The security threats documents details very specific threats, and > indicating if this protocol changes things is important. Also, some > consideration SHOULD be given to when A=1. Are the affects of the new flow > of control messages? > > So for instance Security Considerations should probably consider how > projected DAO messages could be abused by > > a) rogue nodes b) via replay of messages c) if use of projected DAO > messages could in fact deal with any threats? > > I created a security section in line with that of RFC 9010. > > I hope and believe that this removes the road block to go for last call. > > You all keep safe! > > Pascal > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00000000000009bb0605c704618f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much Pascal for addressing the open issues.= We would like to have one or two deep reviews before WGLC.=C2=A0

<= /div>
Dear all, please let us know if you can perform a review to dao-p= rojection draft by 23th July.=C2=A0

Thank you very= much in advance,

Ines.=C2=A0

On Mon, Jul 12,= 2021 at 5:18 PM Pascal Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org> wrote:
<= /div>
Dear all

Ines pointed out an active ticket https://trac.ietf.org/tr= ac/roll/ticket/179 and https://trac.ietf.org/trac/roll= /ticket/180 against the DAO projection draft. It was logged at adoption= call time and I failed to respond properly.

This was against https://d= atatracker.ietf.org/doc/html/draft-thubert-roll-dao-projection-03 , wat= er under the bridge so I tried to sort things out and published https://datatracker.ietf.org/doc/html/dr= aft-ietf-roll-dao-projection-18 as a result.

In more details:

> Michael Richardson wrote on 12-24-2016
> Hi, I had intended to finish this as part of the adoption call, having= previously read the document, but was late.=C2=A0 These comments are proba= bly more useful now anyway.=C2=A0 I can open tickets as appropriate if chai= rs direct.
> Let me leave editorial comments to the end of this email.


> 1) Didn't we have an errata about default lifetime units when ther= e was no configuration option?
> No, we didn't.=C2=A0 I wonder if this plagues us everywhere, that = 6550 should have specified a default Lifetime units in the absence of a Con= figuration option.

I think that was by design. RPL can be used in a great many environments wi= th lots of diversity, from high speed wires in ANIMA to 2Kps LLNs. Couple t= hat with any size of netwoks, with cases of ~10K sometimes. A default value= can be programmed for a particular use case, say Wi-SUN, and in that case = the SDO that leverages RPL will define it for its own purpose.

> 2) http://tools.ietf.org/html/rfc6551 reference:=C2=A0 &q= uot;or the RPL routing extensions specified in Routing for Path Calculation= in LLNs [RFC6551].=C2=A0 Based on that information, the root "
> huh? the title of 6551 is: Routing Metrics Used for Path Calculation i= n Low-Power and Lossy Networks
> so, what exactly did you mean here?

I'd read this as: Additional metrics used for routing decision - indire= ctly, via the Rank computation by the OF
But then I could not find that text in early or current versions, so I gues= s this issue disappeared?


> 3) does dao-lifetime eclipse need for no path dao?

Same as main RPL. Some users might let the route die if signaling is expens= ive.

> 4) resource calculations "but how the root figures the amount of = resources that are available is out of scope."
> I disagree. I would like some mechanism to be in scope.
> And you suggest NMS and 6551 later on... which seems to make it in sco= pe. I'm not sure how 6551 can be used here.

We agree. The capabilities draft will do that when we find time to work on = it.

> 5) section 4 needs subsections! Too many concepts in one heading.

This was " 4.=C2=A0 Loose Source Routing in Non-storing Mode ". I= t is now " A.1.=C2=A0 Loose Source Routing " only 4 paragraphs. T= he rest was spread as suggested

> 6) On the use of a new MOP.
> Are we sure that we need a new MOP?=C2=A0 Could we use Non-Storing MOP= , with some indication of which nodes speak DAO-Projection?=C2=A0 Could tha= t work?
> Or do you really want to force a forklift upgrade here? Why does the e= ntire network need to be aware of this new mode?

Agreed, this is gone now

> 7) page 8 is too dense!

Was split and expanded. I consider that fixed

> 8) I just didn't understand the english here.
> I think that "last node" needs a better term.=C2=A0 Maybe co= lour the nodes or otherwise mark them and use those terms?
> The last node in the segment may have another information to reach the= target(s), such as a connected route or an already installed projected rou= te.=C2=A0 If it does not have such a route then the node

This is gone


> 9) running out of resources:
> it seems that it ought to be said that the new node might not be one t= hat the last node had previously talked to.=C2=A0 There is the issue of bot= h routing storage (from storing mode), but also neighbor cache resources. <= br>
Can't find the related text in any version. But the neighbor cache is c= reated before the sibling is advertised, so the lack of it os not found at = route creation time.


> 10) more hard to understand statements...
> For the targets that could be located, last node in the segment genera= tes a DAO to its loose predecessor in the segment as indicated in the list = of Via Information options.
> woe!=C2=A0 What?

I hope the explanation is better now. The storing mode DAO flows from egres= s to ingress as a the normal DAO flows from leaf to root.


> 11) create new section on route cleanup
> A NULL lifetime in the Via Information option along the segment is use= d to clean up the state.
> needs new 4.x section on cleanup.

Please see "7.3.1.=C2=A0 Storing-Mode P-Route" in -18. I split as= suggested

> 12) move / replicate diagrams into this section, and use numbered diag= rams
> In the example below, say that there is a lot of traffic to nodes 55 <= br> > new section, move diagram here.
> make figure 5 and 6 more like figure 3, numbered, etc.

done

> 13) Q: retransmission timers, etc. appropriate for these projected DAO= messages?
> How do we handle packet loss?

Added text
"
=C2=A0 =C2=A0 =C2=A0The process continues till the P-DAO is propagated to i= ngress router of
=C2=A0 =C2=A0 =C2=A0the Segment, which answers with a DAO-ACK to the Root. = The Root always
=C2=A0 =C2=A0 =C2=A0expects a DAO-ACK, either from the Track Ingress with a= positive status
=C2=A0 =C2=A0 =C2=A0or from any node along the segment with a negative stat= us. If the DAO-ACK
=C2=A0 =C2=A0 =C2=A0is not received, the Root may retry the DAO with the sa= me TID, or tear
=C2=A0 =C2=A0 =C2=A0down the route.
"



> 14) Security Considerations will need to be written.
> The security threats documents details very specific threats, and indi= cating if this protocol changes things is important.=C2=A0 Also, some consi= deration SHOULD be given to when A=3D1.=C2=A0 Are the affects of the new fl= ow of control messages?
> So for instance Security Considerations should probably consider how p= rojected DAO messages could be abused by
> a) rogue nodes b) via replay of messages c) if use of projected DAO me= ssages could in fact deal with any threats?

I created a security section in line with that of RFC 9010.

I hope and believe that this removes the road block to go for last call.
You all keep safe!

Pascal




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000009bb0605c704618f-- From nobody Tue Jul 27 01:21:21 2021 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 C40ED3A1A7C; Tue, 27 Jul 2021 01:21:11 -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: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <162737407174.5123.16615474156798167054@ietfa.amsl.com> Date: Tue, 27 Jul 2021 01:21:11 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-19.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: Tue, 27 Jul 2021 08:21:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Matthew Gillmore Filename : draft-ietf-roll-dao-projection-19.txt Pages : 53 Date : 2021-07-27 Abstract: This document extends RFC 6550 and RFC 6553 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-19.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 27 01:25:58 2021 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 85C0E3A1A9E for ; Tue, 27 Jul 2021 01:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=mK6x9cXe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZBmnELJJ 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 JscNhCSj_pVR for ; Tue, 27 Jul 2021 01:25:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C0B3A1A95 for ; Tue, 27 Jul 2021 01:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2710; q=dns/txt; s=iport; t=1627374348; x=1628583948; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8OTMovUno2IYK2KZVfkwueF8emj3apradt6lhIVSDTE=; b=mK6x9cXeRKKZvoi1iskk/avshSkyoHFd3whdVnZcxUwzU2HuHG65Wl7I TPnHANliAK6gNkSFpEqivW9Far1AVZWnbrTMQIPKQ99Ta5SuDCgYyuKnO e7PXmuq4jYraacRH1NZ7MDFCuj0rBgGQL4PvqOxN1TzTxBtK8DlohKzJ0 I=; IronPort-PHdr: =?us-ascii?q?A9a23=3ApRKynBWttSzO/xwV9CuN03vYhWfV8K3mAWYlg?= =?us-ascii?q?6HPw5pPf7ituZP4Mx+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANM?= =?us-ascii?q?n1NicgfkwE6RsLQD0r9Ia3rYjA0WsNYWwwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AP12DBqr5+j7VMytvRrq88WgaV5t0LNV00z?= =?us-ascii?q?EX/kB9WHVpm5Oj9vxGzc506farslkssSkb6K690KnpewK6yXcH2/hhAV7EZn?= =?us-ascii?q?ikhILIFvAj0WKG+V3d8kLFh5VgPSkLSdkFNDSdNykesS++2njGLz9C+qjEzE?= =?us-ascii?q?nLv5ai854Fd2gDAMsMg3Ybe2Sm+w9NNXV77PECZfyhD7981kKdkAMsH72G7x?= =?us-ascii?q?c+Loz+juyOsKijTQ8NBhYh5gXLpyiv8qTGHx+R2Qpbey9TwJ85mFK11jDR1+?= =?us-ascii?q?GGibWW2xXc32jc49B9g9360OZOA8SKl4w8NijssAC1f45sMofy+Azd4dvfr2?= =?us-ascii?q?rCouO8+ivIDP4Ds085uVvF+icF7jOQlgrGLUWSk2Nwz0GT/PARDwhKe/apzb?= =?us-ascii?q?gpAScxrXBQ4O2VFMlwrjykX109N2KeoM213am7azh60kWzunYsiugVkjhWVp?= =?us-ascii?q?YfcqZYqcgF8FpSC4poJlO31GkLKpglMCjn3ocaTbpaVQGugkB/hNi3GngjFB?= =?us-ascii?q?aPRUYP/sSTzjhNhXh8i08V3tYWkHsM/I80D8As3ZWLDo140LVVCsMGZ6N0A+?= =?us-ascii?q?kMBcOxF2zWWBrJdGafO07uGq0LM2/E75T3/LI27ue3f4Fg9up8pL3RFFdD8W?= =?us-ascii?q?IicUPnDsODmJVN7xDWWW24GS/gz8lPjqIJ8YEUhICbeRFrbWpe0vdIj89vdv?= =?us-ascii?q?EzaszDca6+WcWTWFcGMbw5qDHDZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWBgDawf9g/5FdJa1agQmBWYFTUQd?= =?us-ascii?q?3WjcxhEeDSAOFOYhfA4pYhRWKRYEuFIERA1QLAQEBDQEBNQwEAQGEWAIXgmY?= =?us-ascii?q?CJTQJDgIEAQEBEgEBBQEBAQIBBgR7E4VoDYZCAQEBBBIREQwBATUCAQsEAgE?= =?us-ascii?q?IEQEDAQEDAiYCAgIfERUCBggCBA4FCBqCUIJVAy8BDpwRAYE6AoofeoEygQG?= =?us-ascii?q?CBwEBBgQEgUpBgzINC4I0AwaBECqCfIQPhmMnHIFJRIFYgmI+giBCAQECARe?= =?us-ascii?q?BDDyDFTaCLoJRU10EUQIUORA7ZTSUckeIcZ49XAqDJoo3imyDPIV6EqZjlgu?= =?us-ascii?q?MNIM0kAscD4RwAgQCBAUCDgEBBoFgO4FZcBUagwpQGQ6SEIUUhUpzOAIGCwE?= =?us-ascii?q?BAwmLDwEB?= X-IronPort-AV: E=Sophos;i="5.84,272,1620691200"; d="scan'208";a="916009115" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2021 08:25:47 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 16R8Pl2B012796 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2021 08:25:47 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 27 Jul 2021 03:25:47 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 27 Jul 2021 03:25:47 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 27 Jul 2021 04:25:46 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mnfAf/xctjGhy4FOv0e58QWAkq7OvadFJdmocCCNPicYWaQfGRJA3djXBoUYSrFqFr3tNm1h6q1cnS7XwWB6TDbp412fy6/iBsULHBuvLPutzqFlniRc2GwYyQ8XAgOnxds2tTgoXK0eosoZe+NvVWwCPn5+hu2rUNaVo8vhqEdNHmUZUecAf8zQLDFeZ+kx98X7R+lnhT5AQtZxbE3iRuRYKYE19T3gF2aQoFKaPW366TN1hR6Mrf+CCFP6QAX8Ou6b9oBPliNRAPzK98ifd5Q2SmxwzdbArjEcSeMdi3yLqf5pE91guYjSkU1NBiFQd2gZ4xPnK3KMvFl8rfTNkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8OTMovUno2IYK2KZVfkwueF8emj3apradt6lhIVSDTE=; b=akgVAcqP2xx15dbzbIAyh/erYZEbUKe+ZQo1ZL/69Mvg7KdJfHjzFTLtPTrbgsmXkgnSkqU5zNgZ1QZTDaDWlE7RY9vafjlLjvglyq6XNlTQqmqXPCW7/8rz2GUJcqCepFyq4xszgRW0b7oD3mqtJ+1bK4rrwHsUlQsH0/qZ52ELt36xNmkbPhrZ9g1v23C0ID/ddG1CKrF7c8HJsFIBptJnCVxJuQpV/VCpYEVjwZ6lmDEkaJK+KgqNUjWORMnS6KSg4wKcYAI8ZETzER8y7NF5D3p/5lelSbArn2KjOgdXnjD2G4A9tpkGvAiuQXLmFhG/cAg5SjUPAOHBcbKvvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8OTMovUno2IYK2KZVfkwueF8emj3apradt6lhIVSDTE=; b=ZBmnELJJpZphCzTu9Ypq6LTia0560JypOHMDj45Fhcx87Ja4Ft8zc9xyPvEu+zpVww2LYOHxhBhROcGAaIZdZFtag52BfsLMhMYdFJ5tbNt3TILLXaLPhWX6Aq2iUSi4k/4VwcDpHBtJpBoN8+MIe99qmkKbQ8h3H8JiVDVY+Ds= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB2064.namprd11.prod.outlook.com (2603:10b6:300:27::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.28; Tue, 27 Jul 2021 08:25:45 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1c75:fcc9:2c53:3af6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1c75:fcc9:2c53:3af6%7]) with mapi id 15.20.4352.031; Tue, 27 Jul 2021 08:25:45 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: New Version Notification for draft-ietf-roll-dao-projection-19.txt Thread-Index: AQHXgsBfMjY47aciXk2meGKUCuagDKtWe1Ew Date: Tue, 27 Jul 2021 08:25:24 +0000 Deferred-Delivery: Tue, 27 Jul 2021 08:24:45 +0000 Message-ID: References: <162737407201.5123.8458419598905408884@ietfa.amsl.com> In-Reply-To: <162737407201.5123.8458419598905408884@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ccc89585-6c8f-4dee-9fbd-08d950d82194 x-ms-traffictypediagnostic: MWHPR11MB2064: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5VwAxxs2zQyxiCCGFkMqIHHzx8d/sTcZvXc7iA28Eqkz7oGaPGah6ViE/nxlQMmHe1CVgb3u1IY8A3G+CM18KPsxgxcAxhI+xE90odgx2LTmMKHRLQ9w4+1HNH9OuIypSJ/u+x6iPwicPum+loGTAMUOs3dnuYawApVfXQ2l16hvq8tG0hYi9b4QPXIv/8X+CyeQtIwW3zHdATLMcrm3/pGCF5esom8ADv/FloON9wITaHD33yIfy/NI4qXRwyg8TFopTgxkAEuXv7us8oKau6F+mkljOG+2DGboXDRjCaMlct54XVMGNyEgL7n/7cCa9S8bz45J2VRShvcPgsQiZGwwX4g+SrjzJOExHkEo0/yiTUqJ7Ikaw9C06AWIXYz+pZWnbFe6IVb+5pgU85HFXuVDRlzn7WJVfgEMm4mRRSgBfLhD156PmbisYzldLDJO8pFmWdgLWN/kkM+MDoVb2aF4r600YURmptc7VwrO6+vM5pcaaKxtHecVpmPKYBY9h+6WGIpUXcBm1DV2fBLNbsylQxQ/sjYH6iQVJKCPonZoKoBZbcnfSLHFZEq5hLUg1/msDm7tQzj5XUzhUcmQy5jaxHC+DpdLUvVz7nG7jkLfqJNDSmPGQ+VCAqh15XxB3SpayKYpWwJKlnRGNDvhukisgzU/XZs931sCXMdLIkN9bmzFqtc/8RzuugsnNHuEDry6wEOdxjfRw1KK0PNq+fpuJ/H3RV+7NUqcB/kQ6sUeFZaVGLiyp9KWIhPhsH5ls6jh1QF+9SP2eRPW7KcitC9uVy96ZFZio0IlsLHdNQ1FMNcU7bhV2eEhLW1Bo5D2 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(376002)(346002)(396003)(136003)(66946007)(2906002)(9686003)(478600001)(66476007)(122000001)(7696005)(6666004)(33656002)(86362001)(71200400001)(52536014)(66574015)(15650500001)(54906003)(186003)(76116006)(66446008)(55016002)(38100700002)(316002)(26005)(83380400001)(966005)(5660300002)(8676002)(64756008)(66556008)(4326008)(6916009)(8936002)(53546011)(6506007)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ek95MUxRYkhoS0lKZDlhTWxIVkpJWW1ocUkyRnJuRHA1WUtpQitDMEZST3Fv?= =?utf-8?B?aDh6Z2tyaUhTOU9SaDVrNTRnQlFYVjMrOEFlSnZRN3JWK2RoN1l4UGx6ZkFH?= =?utf-8?B?Mno0TmxpT1A4TWZFMXRnY3FWYTEwendudXA2TnJxRXFVTWUxZkswd0RLZjRW?= =?utf-8?B?cXRMMzBsWjZQQVp5TzJkSkxTU2haZHdNUFo5WEs4cDJnTGtNNHNIM3dzT3RF?= =?utf-8?B?Q2tUYkUwQzd4cHdhTmxvdFZvdHFPdzhhUVIzYnczYzBvem9CalZaRGQwZ2gr?= =?utf-8?B?YzZXNVhMMmhPb24xS0Rab0JYUlptUGp2NVR5bEl2cVZHYkxodDJucTQrOXRS?= =?utf-8?B?YmJNWGw5OW5VSGZTaE1rMjJwcUVoeXJOTncwY3lNS3NyMk5vY0JueTRQZlly?= =?utf-8?B?RFFvWVNmYStZb3FCb0hqcTc5eDB6TjFlOTFqMDRiYU15dHZ5TVlLSTRRSEd0?= =?utf-8?B?bFBuVmh6RUJKWUEwZDdZQzZRMmwxckRsZjNibkUzc1RGdHpFUzhkK200b2VK?= =?utf-8?B?Nm1BQWZiM0szK2NLKytBNkZVSS9HQTY1YTlqTmFFa1RrQ2hmWXNjVTRjZ0Ux?= =?utf-8?B?OEVIL254UTQ2dGhNaUx0M0NtbXhsN0NuaTU1L1dacWZBcGc4NDRMdjg1d1B2?= =?utf-8?B?RnBEZ3NIWG51QnpLb1lOWDFLcG5VME81clN3OFpPUUpkZCsrQWdvS0UxbXdR?= =?utf-8?B?TUo0N0U0Z2d0VWNtMVBmVnZhMk04RXFpcFZqVjd4VGxDRC9HVUFJaTJyTW1D?= =?utf-8?B?TWNWN09rTzNrZjhiaC9Sc1lzL2xxWDU3UXcxQzhnUXl4cW16NFY4MTVHb2I2?= =?utf-8?B?Q0xMM0xjRERhS2ZHVGZJVlZmR0NrSXYwV2cyL2xYNlJENUw5TXhGcnNIR2kr?= =?utf-8?B?OW1IbEJ4Ky9zU05yRFNHb3pVV25yRDB1amRPdnY3RXArTWcwY2FrRmdtODBS?= =?utf-8?B?WU5xbEJFLzlvQnJCT2szMDV3bm9GR0E1UWhoc0o5U2p3ckVBK2ZIcUo5ZWVS?= =?utf-8?B?MkF0YUFwQ1cwQWV1WktidDEzOUxxZ01OL2VkTUxUSUIyVXBpckFzTnFSTzht?= =?utf-8?B?LzZ6cXpCK1UwZXFjU1MyZ0M0ZHBXODNHNXg0RFJBQ1JVZVo0Wm5VYW1mMFRG?= =?utf-8?B?QjBhRVZScTI4RmY5K3JZZEZPYlhVZ1VzT3FnSWI5eGJRNXdOK2tDSFRyaTRl?= =?utf-8?B?QVR5dlNQUjVwa3Qway9hTEtGbUNtb2JBUnZPY2orYzhXSzkvRnVjRlB6VFg4?= =?utf-8?B?OXlhWnNRZmR0czlLNFBObTFhV0dMZkJWaDllTVh6bU5rbE5oY3k1bVJlRWh0?= =?utf-8?B?VXhwdGRjRmFnVVBiQUlSYlBkUGk3NEdDTW9EdG5DdG9PWHNLbXJVYUhpR3hr?= =?utf-8?B?UFlHQmxsbEs5RkhlTU9wMkR4MUp4bXhmLzdqNmgrbC9CWUxuT3NQUitkSGlo?= =?utf-8?B?a0R0VXBaOFo5eHg2TTJDaEd5WTdBc29RT2dQSHN1MUk3ZWFMaUQwN0NjTk1O?= =?utf-8?B?eXdEYTNodFhxNlNXVEpPZ1FvalZlSkErb2p2a25JN1E3VVFQWUhSODZNQXdW?= =?utf-8?B?VDVKNW9kQ2dGVjNHemo2KzYwZUtzbEsrTnFiZThoQWlmTXRyekMrRHhCdVpU?= =?utf-8?B?QjhCNUpRU2FMZUdiTVpxY1NpeFY1WGY5azNsQVk1WnZZT2NQUjlDaEwwcUJI?= =?utf-8?B?ZEJRb1IzUlQ1bmVXTXJFZXJmMjZJbTh5Vy8zZWN1TVNqWUErTGMzSTBpRm13?= =?utf-8?Q?DurvyShk5ZjrH78v42fwHzj2H7LbktMuFfqnKa+?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ccc89585-6c8f-4dee-9fbd-08d950d82194 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 08:25:45.4370 (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-CrossTenant-userprincipalname: Sf8P+0X3c36WB5/TJtenQEfSOvCZ+I1VPoetycb3BvwrdoSljR1qbGKYS3MGja6daNVIsb/gb5ecD2brMRCNUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2064 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] New Version Notification for draft-ietf-roll-dao-projection-19.txt 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, 27 Jul 2021 08:25:54 -0000 RGVhciBhbGw6DQoNCkEgdmVyeSBzbWFsbCBkaWZmIHRvIHJlbW92ZSBhIGxlZnRvdmVyIGxpbWl0 YXRpb24gZnJvbSBiZWZvcmUgc2VnbWVudHMgd2VyZSBpbnRyb2R1Y2VkLg0KQWxzbyB1cGRhdGVk IHRoZSByZWZlcmVuY2UgdG8gdGhlIFJBVyBhcmNoaXRlY3R1cmUsIG5vdyBXRyBkb2MuDQoNCktl ZXAgc2FmZTsNCg0KUGFzY2FsDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KPiBTZW50OiBtYXJkaSAyNyBqdWlsbGV0IDIwMjEgMTA6MjENCj4gVG86IE1hdHRoZXcgR2ls bG1vcmUgPG1hdHRoZXcuZ2lsbG1vcmVAaXRyb24uY29tPjsgUGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KQ0KPiA8cHRodWJlcnRAY2lzY28uY29tPjsgUmFodWwgQXJ2aW5kIEphZGhhdiA8cmFodWwu aWV0ZkBnbWFpbC5jb20+OyBSYWh1bA0KPiBKYWRoYXYgPHJhaHVsLmlldGZAZ21haWwuY29tPg0K PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC1k YW8tcHJvamVjdGlvbi0xOS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaWV0Zi1yb2xsLWRhby1wcm9qZWN0aW9uLTE5LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4g cmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1pZXRmLXJvbGwtZGFvLXByb2plY3Rpb24N Cj4gUmV2aXNpb246CTE5DQo+IFRpdGxlOgkJUm9vdCBpbml0aWF0ZWQgcm91dGluZyBzdGF0ZSBp biBSUEwNCj4gRG9jdW1lbnQgZGF0ZToJMjAyMS0wNy0yNw0KPiBHcm91cDoJCXJvbGwNCj4gUGFn ZXM6CQk1Mw0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9p ZC9kcmFmdC1pZXRmLXJvbGwtZGFvLQ0KPiBwcm9qZWN0aW9uLTE5LnR4dA0KPiBTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLWRh by0NCj4gcHJvamVjdGlvbi8NCj4gSHRtbDogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1yb2xsLWRhby0NCj4gcHJvamVjdGlvbi0xOS5odG1sDQo+ IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtcm9sbC1kYW8tDQo+IHByb2plY3Rpb24NCj4gRGlmZjogICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtZGFvLQ0KPiBwcm9q ZWN0aW9uLTE5DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIFJG QyA2NTUwIGFuZCBSRkMgNjU1MyB0byBlbmFibGUgYSBSUEwgUm9vdCB0bw0KPiAgICBpbnN0YWxs IGFuZCBtYWludGFpbiBQcm9qZWN0ZWQgUm91dGVzIHdpdGhpbiBpdHMgRE9EQUcsIGFsb25nIGEN Cj4gICAgc2VsZWN0ZWQgc2V0IG9mIG5vZGVzIHRoYXQgbWF5IG9yIG1heSBub3QgaW5jbHVkZSBz ZWxmLCBmb3IgYSBjaG9zZW4NCj4gICAgZHVyYXRpb24uICBUaGlzIHBvdGVudGlhbGx5IGVuYWJs ZXMgcm91dGVzIHRoYXQgYXJlIG1vcmUgb3B0aW1pemVkIG9yDQo+ICAgIHJlc2lsaWVudCB0aGFu IHRob3NlIG9idGFpbmVkIHdpdGggdGhlIGNsYXNzaWNhbCBkaXN0cmlidXRlZA0KPiAgICBvcGVy YXRpb24gb2YgUlBMLCBlaXRoZXIgaW4gdGVybXMgb2YgdGhlIHNpemUgb2YgYSBSb3V0aW5nIEhl YWRlciBvcg0KPiAgICBpbiB0ZXJtcyBvZiBwYXRoIGxlbmd0aCwgd2hpY2ggaW1wYWN0cyBib3Ro IHRoZSBsYXRlbmN5IGFuZCB0aGUNCj4gICAgcGFja2V0IGRlbGl2ZXJ5IHJhdGlvLg0KPiANCj4g DQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCg==