From nobody Mon May 4 14:20:00 2020 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 D64EE3A10A7 for ; Mon, 4 May 2020 14:19:58 -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, 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 tmWWu08mSs9H for ; Mon, 4 May 2020 14:19:56 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 BBCB63A0DCA for ; Mon, 4 May 2020 14:19:56 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id z1so596420vsn.11 for ; Mon, 04 May 2020 14:19:56 -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=NjwWskCqQ4BncqCd2u6ZCmRKl0/PzQ5BIFHoVKpZ8Bw=; b=USGtOolXA6cOsoSiWnLu3irP2KJYeZkW6nHiQ93cqNJYJ3AxskQ07DuY05bh4IE7OJ b8RkGfhxWBU+onCli4Tqfz7qocS86f0w1NZc/OvN8GO/0KNzFHeIZlJ4q5RMznTxYHQe eATJ9aB2qiu2eBlCiAw/e8cCdLSA9q4XCJjmSAqjZim6ysIh3ASJR/Vl9KqLdhGiPBIn Gtce611Wd5D+pd2/biI7D+eqK4G3jaxKt47RFXYviVSAfsWTQCExsL1pRpuqkKOE5Gxc MhttCXeygUuVI9pSknJ4+J1uDtxSAzbQoy1bpRILZVlfv8+hZ93wcf6Pu44s9aets89E Q7lw== 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=NjwWskCqQ4BncqCd2u6ZCmRKl0/PzQ5BIFHoVKpZ8Bw=; b=l+D23ZjKyoX85cSWA5VUuurmd1uWcB/4AUt9Lqhkazslv+0k5QRmr90WZENwWt01L+ 4EzIby0GTq3caalCeJ7lulotJ5QhNwMBnlX07qXo/9AIcMP7JjCG3EPejVMpBoBNmhC0 6XA38gCfyLrdAXboDre9QP8ER9/j0YVrQET51qr2t4ggOjizEvMDSvQCBU/7L4wDunwp 4KByo5FkH8tJDtqX2pBUZdC6V0imdXGmAbqImSzPtJQg0vvBTaKXDEqN/kYZkTYk8TWj lNk4allh/HnJ04UK2T4PucZTcsEVtBcmbVv5IZol1NI3apv4Izc8/Jg5hdBS2C6HS4jf dYjA== X-Gm-Message-State: AGi0PubKW466Oi6xwLoxRxphximECU9B1I2m58XSqhPLpgVGM7ePr4+N dhJzTq5cgxgCv+soTvVxgKuMAa7YKTOzsWA8WsqI4gdi34Q= X-Google-Smtp-Source: APiQypKPriKvmDgpsUwVbLDaUm7wc/e54pTSpTcZ5A+JBIbcpb+XO+r/gnBS4hABhPQJIhtKGzGqEliVW6upoKSRhtk= X-Received: by 2002:a67:ea93:: with SMTP id f19mr221662vso.216.1588627195381; Mon, 04 May 2020 14:19:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Tue, 5 May 2020 00:19:18 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000a94ceb05a4d91760" Archived-At: Subject: [Roll] doodle reminder + action points 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, 04 May 2020 21:19:59 -0000 --000000000000a94ceb05a4d91760 Content-Type: text/plain; charset="UTF-8" Dear all, This is a kindly reminder to fill the doodle by May 6th for the next interim meeting https://doodle.com/poll/ntg5b73g4q8df4nt Please find as well the link where the video is recorded: https://github.com/roll-wg/ROLL-Interim-Meeting/blob/master/20200429-IETF107/Link_to_Webex_video_roll_interim_20200429 The resulting etherpad: https://github.com/roll-wg/ROLL-Interim-Meeting/blob/master/20200429-IETF107/Etherpad_Bluesheet_roll_Interim_20200429.txt Action Points from Roll-interim Meeting 20200429: - Pascal: To add unaware-leaves slides to GitHub - Rahul+all: design of new Option and backward compatibility (minute 0:36-0:39) - Rahul+all: design capability extension mechanism (organised in bytes? - get for IANA advice) (minute 0:44-0:46) - Rahul: bring discussion to the ML on new capability for routing resource / neighbor cache. (minute 0:46 -:0:47:23) - Aris+all: NSA - IPv6 compression - (minute 0:55 to 1:08) - ghc, Mopex draft to evaluate mechanism considering sent two DIOs in a row (minute 1:06-1:07) - chairs: WGLC for nsa-extension - chairs: Interim meeting in May, to discuss RPL observations issues, notably "RPL ping" (minute 1:20- 1:27) - Georgios/Dominique: update dis-mods with use case provided by Pascal, check eliding-dio for use cases (minute 1:38 -1:40) - chairs: To get reviews for enrollment-priority Comments welcome, Thank you very much, Ines and Dominique On Wed, Apr 29, 2020 at 7:20 PM Ines Robles wrote: > Dear all, > > Thank you very much for the participation at the today-interim meeting > (ietf 107). We will send shortly the summary with the action points and the > recording link. > > As it was suggested in the meeting, we would like to set another interim > meeting on May. Please fill into the following doodle by May 6th. > > https://doodle.com/poll/ntg5b73g4q8df4nt > > Thank you and best regards, > > Ines and Dominique. > --000000000000a94ceb05a4d91760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

This is = a kindly reminder to fill the doodle by May 6th for the next interim meetin= g=C2=A0




Action Points from Roll-interim Mee= ting 20200429:

- Pascal: To add unaware-leaves slides to GitHub
-= Rahul+all: design of new Option and backward compatibility (minute 0:36-0:= 39)
- Rahul+all: design capability extension mechanism (organised in byt= es? - get for IANA advice) (minute 0:44-0:46)
- Rahul: bring discussion= to the ML on new capability for routing resource / neighbor cache. (minute= 0:46 -:0:47:23)
- Aris+all: NSA - IPv6 compression - (minute 0:55 to 1:= 08) - ghc, Mopex draft to evaluate mechanism considering sent two DIOs in a= row (minute 1:06-1:07)
- chairs: WGLC for nsa-extension
- chairs: In= terim meeting in May, to discuss RPL observations issues, notably "RPL= ping" (minute 1:20- 1:27)
- Georgios/Dominique: update dis-mods w= ith use case provided by Pascal, check eliding-dio for use cases (minute 1:= 38 -1:40)
- chairs: To get reviews for enrollment-priority

Comments welcome,

Thank you very m= uch,

Ines and Dominique

On Wed, Apr 29, 2020= at 7:20 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
Dear all,

=
Thank you very much for the participation at the today-interim meeting= (ietf 107). We will send shortly the summary with the action points and th= e recording link.

As it was suggested in the meeti= ng, we would like to set another interim meeting on May. Please fill into t= he following doodle by May 6th.


Thank you and best rega= rds,

Ines and Dominique.
--000000000000a94ceb05a4d91760-- From nobody Tue May 5 00:40:40 2020 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 B1FC83A15B4 for ; Tue, 5 May 2020 00:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=NEvEq6ce; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=atVGcTRV 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 9FY0gFFs4KIT for ; Tue, 5 May 2020 00:39:08 -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 683183A15B0 for ; Tue, 5 May 2020 00:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9319; q=dns/txt; s=iport; t=1588664348; x=1589873948; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/X2o5SFCzmhFLRrSmuO7ZKcyshaZ2AiDQek0LPg+c2s=; b=NEvEq6ce/pG0fXpym8kYLAYpKk6cYfJutB2k1HIgOH2KlkVHheamMOip vid7QU0tl7+JWOHY5Ua5v5GpVlX7+Imco3EzdkxSP6gr07H1wRmYtGRwI 3HCbBEZuQ+MqJ/wL3tOqAUhZFkHuwgJ01u8AAc2zx9GmBZieW/yZlmWN6 A=; IronPort-PHdr: =?us-ascii?q?9a23=3Ah3zC0hNi/v5F9U1+y08l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8FgBXF7Fe/4wNJK1mHQI9BQUECYF?= =?us-ascii?q?dAoFSKSgFblgvKoQjg0YDizaBbJN3hGOBLhSBEANUCwEBAQwBARgBDgYCBAE?= =?us-ascii?q?BhEQCF4IfJDYHDgIDAQELAQEFAQEBAgEFBG2FVgyFcgIBAwEBEBEdAQEsDA8?= =?us-ascii?q?CAQg/AwICAiULFBECBBMigmMXCgGBfk0DLgEOp34CgTmIYXaBMoMAAQEFgTI?= =?us-ascii?q?BgRaDAQ0Lgg4DBoE4AYJiiWEagUE/gREnDBCBOIEVPoIeSQEBAoEpZ4JlM4I?= =?us-ascii?q?tjnKCV4YaimyQBgqCSIgYiD+HPx2CW4hhkWSPT4Igh3yTSAIEAgQFAg4BAQW?= =?us-ascii?q?BWQYsgVZwFTsqAYI+UBgNVo91AxeBAwEHgkSFFIVCdAI1AgYBBwEBAwl8kUo?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.73,354,1583193600"; d="scan'208,217";a="756456895" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 May 2020 07:39:06 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0457d6lI006747 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 May 2020 07:39:06 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 02:39:06 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 03:39:05 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 5 May 2020 02:39:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YK7ns7dUda2jKXRpAySh6uvFFOW8L9QhuQst37AxrF6rcqMw+GLoYHXlYfrEXYW//nISrUG5gUoovVeLlf9QsvrGsL2YxKq7gw2vhrzyyNYMldckb9old3JB8qW7ckGPpP7I4mYg8YWSGQuub824gKGhmiE2toBMV8z7v702MO5VBTDnRvL9fIXj5FHilq2PTxJ+yJWmW5ypkTZcoUvJd7g9Z+IV5R2rYTmexYbGX3qEyq5KntMllKP/6h5iDnRqTqTjTiH6YYer1sCGLrbcLdEfs8EhhapD2HDRZJyOJLUJNbzGBjb4fOOiTuZ7r2d+tFnC85nofaBW2ycT1/8r2w== 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=/X2o5SFCzmhFLRrSmuO7ZKcyshaZ2AiDQek0LPg+c2s=; b=OqfEEkKMZHSLXw/+8zZdt6vF5eelABRD5wB7Cf4lh4UbLsOAMH2gMTJBR1XviUnhnWAGY6IZtzDyGOHAyQcN68j5sie3hCNtPoFy97k3GADe8ExVau+gk2vNLevJ2JVqiRy8M+VyneS0gn4tQtqVcBagDjHdMDn0ZE3tleK9fIeZsy8XKqZLSuIRjNG+p16mjiehIKn8E2knWtlUHwllzngZ/dCs13Kl3dd40opMGwXEtwOgD6yemktY6pq4xKTBg3Txzlhr2vB4Y5HxHap3u9YT8arI7+9kn1ihPvlmVbZqkwziBKtxLKqTTYEHz84aTO4TyyUqd2pQ0ZIgiUma8g== 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=/X2o5SFCzmhFLRrSmuO7ZKcyshaZ2AiDQek0LPg+c2s=; b=atVGcTRV5bqbikq5xd5xkyoKcWfMDZN4YIf/DcQ137393Jm+27ZWqrE9rZ3ISvs0o6JGES6T2EbMBTZlv2RebLSYl8sI8HMq7Hu6YIXI8I43JWxc5nwbnvmil+2e14LKIk/qC/cVjwPUi90M1u33MHLgIbZkpotqoKzPb46poaw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4663.namprd11.prod.outlook.com (2603:10b6:208:26f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Tue, 5 May 2020 07:39:04 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2958.030; Tue, 5 May 2020 07:39:04 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] doodle reminder + action points Thread-Index: AQHWIlnRhYvLb9ivr0yKgtEF255faaiZG8wR Date: Tue, 5 May 2020 07:39:04 +0000 Message-ID: References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR 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-originating-ip: [2a01:cb1d:4ec:2200:1997:624e:fb74:69bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f3d8e46-4638-47da-dff0-08d7f0c762e0 x-ms-traffictypediagnostic: MN2PR11MB4663: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zwfECV2oDotEMl7oNqZpaAPCKE/JxwM+IVw/4HGrkfoWhs5PqnwsSJ2Pm+GuV9oTm+DOGAr8C7f7msHyBPZ1xKWb4gArkzZmMBKnE+WDCaQN/xq1egDNPpsqBpAFt8wt03uwJgZWOBMOcUHAzyS/oF85cNjK0EDWzCnRmDh7/2yJ8LteV2KrU25sMpmeWAmme7Z3S/zN8nj6kT9uVm0G6gPcnzMa+UOZ1TWvoi2r3JddwWlnq6k2D8qqHhDNsJq1hSBJzXj4ZEszFq9V6D9km/HM7URVk4PuN40yk+UIOBuciE058obzi9sgFGNNiTczkC9A70KV0pSkJ7JoxUqMjqYXEALY+luPdzZHHXUnvdEIeL/Y1D6Q8EyW0VoNB0pwwbog/zwvrMWKEMMn8mtLptc1O6jtirVC/OpdNewZZKeXoPwsBw2SBthDprAAyLzUuhbyK/07Z+JLKhiV6aDDySnaKOfnhD52IeIX7aANMmMdBHAS13WBbWaqtoyQrkPDVKWnlAnskkv3Gt6OpJFhZfuYip5Qsgpttny1RhRLIAXmSWnjPAjpTB5UGOIvrAI5nUcePBrRaEYLL+ib1lk/oEpTrnLeUkR/4MkZQFjAwpcuHxlpSygVNRmi04+BjZ3h x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(366004)(396003)(136003)(376002)(33430700001)(66446008)(64756008)(66476007)(66946007)(66574012)(8676002)(76116006)(2616005)(316002)(8936002)(36756003)(91956017)(2906002)(66556008)(33440700001)(966005)(33656002)(478600001)(86362001)(6512007)(71200400001)(6506007)(53546011)(186003)(6916009)(6486002)(5660300002)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Z/OwpMLMqaH6sr5BUljKoUyZGmT7tL0wGCXxijDgwtxnR/uu1nralweESUjcN3LCWOHQ/w8v+x5tX2tdlsHoKLkYv2ye+nMc5nquV218ATaznFgUmP2QqqCNMo4P/jthcJHaUvSmKvbKefC/LiiouXJbYqrCFSl6EiAZ1cNtT9yZyCvmqOGelSe5jjoawlNmlWhy7NSszj4DBEZv+OMNwHgmuWq8IYOA573ku/SwpBQsCyeDbylWxeQ2IWWuElGKcPtsPRkMWvFjVJ+vbpjWTzXlM5dka/FOi7tnQ2MLslHEn462nuMaPYmQKdxYhUKUGoaHpZCZiQnkEypJyD/aBYHC5ix874dX+LbiMlca+kl0VbeqT6kp1ihPIeg/tR3LzgE7P3Ns4zsEaqp3GOEgl+OrAVkhmgysrcGqFx8sw7+qnAdgTn4HeHXRgg/CI4vGZixMH+C8y21jMBYInWZ5zkbtxMXq7E/g1qi1x4jsU87bJUSHuCed552tt6jfL1FzQ2OnMgwr6a4OGoOAh3F8si/LImlbIIOo8ZRWEC4ka7s3dQ2+dYq/O17uHdy3YEj7wSb16q1PLAE3V4shOHzNhrTa0YnttmWql7M4YdASgroQqZFE/o7Y9zYDuO8FlN5ynjOzg5jDPJejKvDl0Yfq3Ky1zBjtWCdP69MkBxwBARfOcwTBiCo7qKIOQsuWOzbPYILPbD3OAzfCk9p4RVPfxkCMeUm4JwL+cJUFjeD1UBrnBq4wBCbSYRiwCghO+QRq7pmeUAp5uPmlJMrmnzNlTm84beRf+PtuSge4Yz2vc2vMYFb176EkInD1YiLLKZykg2nZh1YlqLDzQyXOBX5r3oF4QTyGl8mC/7H2+Ok5kH0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F81964068CA94D058922AF03A41F4E2Fciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f3d8e46-4638-47da-dff0-08d7f0c762e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 07:39:04.3317 (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: 35xLMYavGqgiN6ya+Hm6E1mAc+vCsWev/wP/43s4EOUw1h6HDE4LkLw3e3fQ756GPGghqrHTftidgB1TM/tXuQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4663 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Roll] doodle reminder + action points 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, 05 May 2020 07:39:11 -0000 --_000_F81964068CA94D058922AF03A41F4E2Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBJbmVzIGFuZCBhbGwNCg0KSSBkaWQgbXkgcGllY2UNCg0KaHR0cHM6Ly9naXRodWIuY29t L3JvbGwtd2cvcm9sbC11bmF3YXJlLWxlYXZlcy9ibG9iL21hc3Rlci9JbGx1c3RyYXRpbmclMjBl bmNhcHN1bGF0aW9uLnBwdHgNCg0KWW91IGFsbCB0YWtlIGNhcmUsDQoNClBhc2NhbA0KDQpMZSA0 IG1haSAyMDIwIMOgIDIzOjIwLCBJbmVzIFJvYmxlcyA8bWFyaWFpbmVzcm9ibGVzPTQwZ29vZ2xl bWFpbC5jb21AZG1hcmMuaWV0Zi5vcmc+IGEgw6ljcml0IDoNCg0K77u/DQpEZWFyIGFsbCwNCg0K VGhpcyBpcyBhIGtpbmRseSByZW1pbmRlciB0byBmaWxsIHRoZSBkb29kbGUgYnkgTWF5IDZ0aCBm b3IgdGhlIG5leHQgaW50ZXJpbSBtZWV0aW5nDQoNCmh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsL250 ZzViNzNnNHE4ZGY0bnQNCg0KUGxlYXNlIGZpbmQgYXMgd2VsbCB0aGUgbGluayB3aGVyZSB0aGUg dmlkZW8gaXMgcmVjb3JkZWQ6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9yb2xsLXdnL1JPTEwtSW50 ZXJpbS1NZWV0aW5nL2Jsb2IvbWFzdGVyLzIwMjAwNDI5LUlFVEYxMDcvTGlua190b19XZWJleF92 aWRlb19yb2xsX2ludGVyaW1fMjAyMDA0MjkNCg0KVGhlIHJlc3VsdGluZyBldGhlcnBhZDogaHR0 cHM6Ly9naXRodWIuY29tL3JvbGwtd2cvUk9MTC1JbnRlcmltLU1lZXRpbmcvYmxvYi9tYXN0ZXIv MjAyMDA0MjktSUVURjEwNy9FdGhlcnBhZF9CbHVlc2hlZXRfcm9sbF9JbnRlcmltXzIwMjAwNDI5 LnR4dA0KDQpBY3Rpb24gUG9pbnRzIGZyb20gUm9sbC1pbnRlcmltIE1lZXRpbmcgMjAyMDA0Mjk6 DQoNCi0gUGFzY2FsOiBUbyBhZGQgdW5hd2FyZS1sZWF2ZXMgc2xpZGVzIHRvIEdpdEh1Yg0KLSBS YWh1bCthbGw6IGRlc2lnbiBvZiBuZXcgT3B0aW9uIGFuZCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IChtaW51dGUgMDozNi0wOjM5KQ0KLSBSYWh1bCthbGw6IGRlc2lnbiBjYXBhYmlsaXR5IGV4dGVu c2lvbiBtZWNoYW5pc20gKG9yZ2FuaXNlZCBpbiBieXRlcz8gLSBnZXQgZm9yIElBTkEgYWR2aWNl KSAobWludXRlIDA6NDQtMDo0NikNCi0gUmFodWw6IGJyaW5nIGRpc2N1c3Npb24gdG8gdGhlIE1M IG9uIG5ldyBjYXBhYmlsaXR5IGZvciByb3V0aW5nIHJlc291cmNlIC8gbmVpZ2hib3IgY2FjaGUu IChtaW51dGUgMDo0NiAtOjA6NDc6MjMpDQotIEFyaXMrYWxsOiBOU0EgLSBJUHY2IGNvbXByZXNz aW9uIC0gKG1pbnV0ZSAwOjU1IHRvIDE6MDgpIC0gZ2hjLCBNb3BleCBkcmFmdCB0byBldmFsdWF0 ZSBtZWNoYW5pc20gY29uc2lkZXJpbmcgc2VudCB0d28gRElPcyBpbiBhIHJvdyAobWludXRlIDE6 MDYtMTowNykNCi0gY2hhaXJzOiBXR0xDIGZvciBuc2EtZXh0ZW5zaW9uDQotIGNoYWlyczogSW50 ZXJpbSBtZWV0aW5nIGluIE1heSwgdG8gZGlzY3VzcyBSUEwgb2JzZXJ2YXRpb25zIGlzc3Vlcywg bm90YWJseSAiUlBMIHBpbmciIChtaW51dGUgMToyMC0gMToyNykNCi0gR2Vvcmdpb3MvRG9taW5p cXVlOiB1cGRhdGUgZGlzLW1vZHMgd2l0aCB1c2UgY2FzZSBwcm92aWRlZCBieSBQYXNjYWwsIGNo ZWNrIGVsaWRpbmctZGlvIGZvciB1c2UgY2FzZXMgKG1pbnV0ZSAxOjM4IC0xOjQwKQ0KLSBjaGFp cnM6IFRvIGdldCByZXZpZXdzIGZvciBlbnJvbGxtZW50LXByaW9yaXR5DQoNCkNvbW1lbnRzIHdl bGNvbWUsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2gsDQoNCkluZXMgYW5kIERvbWluaXF1ZQ0KDQpP biBXZWQsIEFwciAyOSwgMjAyMCBhdCA3OjIwIFBNIEluZXMgUm9ibGVzIDxtYXJpYWluZXNyb2Js ZXNAZ29vZ2xlbWFpbC5jb208bWFpbHRvOm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbT4+ IHdyb3RlOg0KRGVhciBhbGwsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBwYXJ0aWNp cGF0aW9uIGF0IHRoZSB0b2RheS1pbnRlcmltIG1lZXRpbmcgKGlldGYgMTA3KS4gV2Ugd2lsbCBz ZW5kIHNob3J0bHkgdGhlIHN1bW1hcnkgd2l0aCB0aGUgYWN0aW9uIHBvaW50cyBhbmQgdGhlIHJl Y29yZGluZyBsaW5rLg0KDQpBcyBpdCB3YXMgc3VnZ2VzdGVkIGluIHRoZSBtZWV0aW5nLCB3ZSB3 b3VsZCBsaWtlIHRvIHNldCBhbm90aGVyIGludGVyaW0gbWVldGluZyBvbiBNYXkuIFBsZWFzZSBm aWxsIGludG8gdGhlIGZvbGxvd2luZyBkb29kbGUgYnkgTWF5IDZ0aC4NCg0KaHR0cHM6Ly9kb29k bGUuY29tL3BvbGwvbnRnNWI3M2c0cThkZjRudA0KDQpUaGFuayB5b3UgYW5kIGJlc3QgcmVnYXJk cywNCg0KSW5lcyBhbmQgRG9taW5pcXVlLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== --_000_F81964068CA94D058922AF03A41F4E2Fciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpE ZWFyIEluZXMgYW5kIGFsbA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkaWQgbXkgcGllY2U8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9yb2xsLXdnL3JvbGwtdW5hd2FyZS1sZWF2ZXMvYmxvYi9tYXN0ZXIvSWxsdXN0cmF0aW5nJTIw ZW5jYXBzdWxhdGlvbi5wcHR4Ij5odHRwczovL2dpdGh1Yi5jb20vcm9sbC13Zy9yb2xsLXVuYXdh cmUtbGVhdmVzL2Jsb2IvbWFzdGVyL0lsbHVzdHJhdGluZyUyMGVuY2Fwc3VsYXRpb24ucHB0eDwv YT48L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PllvdSBhbGwgdGFrZSBj YXJlLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGFzY2FsPC9kaXY+DQo8L2Rpdj4N CjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkxlIDQgbWFpIDIw MjAgw6AgMjM6MjAsIEluZXMgUm9ibGVzICZsdDttYXJpYWluZXNyb2JsZXM9NDBnb29nbGVtYWls LmNvbUBkbWFyYy5pZXRmLm9yZyZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIi Pu+7vw0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5EZWFyIGFsbCw8YnI+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIGEga2luZGx5IHJlbWluZGVyIHRvIGZpbGwgdGhl IGRvb2RsZSBieSBNYXkgNnRoIGZvciB0aGUgbmV4dCBpbnRlcmltIG1lZXRpbmcmbmJzcDs8L2Rp dj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2Rvb2Rs ZS5jb20vcG9sbC9udGc1YjczZzRxOGRmNG50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kb29k bGUuY29tL3BvbGwvbnRnNWI3M2c0cThkZjRudDwvYT48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+UGxlYXNlIGZpbmQgYXMgd2VsbCB0aGUgbGluayB3aGVyZSB0aGUgdmlk ZW8gaXMgcmVjb3JkZWQ6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vcm9sbC13Zy9ST0xMLUludGVyaW0tTWVldGluZy9ibG9iL21hc3Rl ci8yMDIwMDQyOS1JRVRGMTA3L0xpbmtfdG9fV2ViZXhfdmlkZW9fcm9sbF9pbnRlcmltXzIwMjAw NDI5Ij5odHRwczovL2dpdGh1Yi5jb20vcm9sbC13Zy9ST0xMLUludGVyaW0tTWVldGluZy9ibG9i L21hc3Rlci8yMDIwMDQyOS1JRVRGMTA3L0xpbmtfdG9fV2ViZXhfdmlkZW9fcm9sbF9pbnRlcmlt XzIwMjAwNDI5PC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHJl c3VsdGluZyBldGhlcnBhZDombmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcm9sbC13 Zy9ST0xMLUludGVyaW0tTWVldGluZy9ibG9iL21hc3Rlci8yMDIwMDQyOS1JRVRGMTA3L0V0aGVy cGFkX0JsdWVzaGVldF9yb2xsX0ludGVyaW1fMjAyMDA0MjkudHh0Ij5odHRwczovL2dpdGh1Yi5j b20vcm9sbC13Zy9ST0xMLUludGVyaW0tTWVldGluZy9ibG9iL21hc3Rlci8yMDIwMDQyOS1JRVRG MTA3L0V0aGVycGFkX0JsdWVzaGVldF9yb2xsX0ludGVyaW1fMjAyMDA0MjkudHh0PC9hPjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWN0aW9uIFBvaW50cyBmcm9tIFJvbGwtaW50ZXJp bSBNZWV0aW5nIDIwMjAwNDI5Ojxicj4NCjxicj4NCi0gUGFzY2FsOiBUbyBhZGQgdW5hd2FyZS1s ZWF2ZXMgc2xpZGVzIHRvIEdpdEh1Yjxicj4NCi0gUmFodWwmIzQzO2FsbDogZGVzaWduIG9mIG5l dyBPcHRpb24gYW5kIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgKG1pbnV0ZSAwOjM2LTA6MzkpPGJy Pg0KLSBSYWh1bCYjNDM7YWxsOiBkZXNpZ24gY2FwYWJpbGl0eSBleHRlbnNpb24gbWVjaGFuaXNt IChvcmdhbmlzZWQgaW4gYnl0ZXM/IC0gZ2V0IGZvciBJQU5BIGFkdmljZSkgKG1pbnV0ZSAwOjQ0 LTA6NDYpDQo8YnI+DQotIFJhaHVsOiBicmluZyBkaXNjdXNzaW9uIHRvIHRoZSBNTCBvbiBuZXcg Y2FwYWJpbGl0eSBmb3Igcm91dGluZyByZXNvdXJjZSAvIG5laWdoYm9yIGNhY2hlLiAobWludXRl IDA6NDYgLTowOjQ3OjIzKTxicj4NCi0gQXJpcyYjNDM7YWxsOiBOU0EgLSBJUHY2IGNvbXByZXNz aW9uIC0gKG1pbnV0ZSAwOjU1IHRvIDE6MDgpIC0gZ2hjLCBNb3BleCBkcmFmdCB0byBldmFsdWF0 ZSBtZWNoYW5pc20gY29uc2lkZXJpbmcgc2VudCB0d28gRElPcyBpbiBhIHJvdyAobWludXRlIDE6 MDYtMTowNyk8YnI+DQotIGNoYWlyczogV0dMQyBmb3IgbnNhLWV4dGVuc2lvbjxicj4NCi0gY2hh aXJzOiBJbnRlcmltIG1lZXRpbmcgaW4gTWF5LCB0byBkaXNjdXNzIFJQTCBvYnNlcnZhdGlvbnMg aXNzdWVzLCBub3RhYmx5ICZxdW90O1JQTCBwaW5nJnF1b3Q7IChtaW51dGUgMToyMC0gMToyNykN Cjxicj4NCi0gR2Vvcmdpb3MvRG9taW5pcXVlOiB1cGRhdGUgZGlzLW1vZHMgd2l0aCB1c2UgY2Fz ZSBwcm92aWRlZCBieSBQYXNjYWwsIGNoZWNrIGVsaWRpbmctZGlvIGZvciB1c2UgY2FzZXMgKG1p bnV0ZSAxOjM4IC0xOjQwKTxicj4NCi0gY2hhaXJzOiBUbyBnZXQgcmV2aWV3cyBmb3IgZW5yb2xs bWVudC1wcmlvcml0eTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q29tbWVu dHMgd2VsY29tZSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rIHlvdSB2ZXJ5 IG11Y2gsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbmVzIGFuZCBEb21pbmlxdWU8 L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFdlZCwgQXByIDI5LCAyMDIwIGF0IDc6MjAgUE0g SW5lcyBSb2JsZXMgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJpYWluZXNyb2JsZXNAZ29vZ2xlbWFp bC5jb20iPm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+RGVhciBhbGwsDQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcGFydGljaXBhdGlvbiBhdCB0 aGUgdG9kYXktaW50ZXJpbSBtZWV0aW5nIChpZXRmIDEwNykuIFdlIHdpbGwgc2VuZCBzaG9ydGx5 IHRoZSBzdW1tYXJ5IHdpdGggdGhlIGFjdGlvbiBwb2ludHMgYW5kIHRoZSByZWNvcmRpbmcgbGlu ay48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFzIGl0IHdhcyBzdWdnZXN0ZWQgaW4g dGhlIG1lZXRpbmcsIHdlIHdvdWxkIGxpa2UgdG8gc2V0IGFub3RoZXIgaW50ZXJpbSBtZWV0aW5n IG9uIE1heS4gUGxlYXNlIGZpbGwgaW50byB0aGUgZm9sbG93aW5nIGRvb2RsZSBieSBNYXkgNnRo LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9kb29kbGUu Y29tL3BvbGwvbnRnNWI3M2c0cThkZjRudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZG9vZGxl LmNvbS9wb2xsL250ZzViNzNnNHE4ZGY0bnQ8L2E+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGFuayB5b3UgYW5kIGJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkluZXMgYW5kIERvbWluaXF1ZS48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPlJvbGwgbWFpbGluZyBsaXN0PC9z cGFuPjxicj4NCjxzcGFuPlJvbGxAaWV0Zi5vcmc8L3NwYW4+PGJyPg0KPHNwYW4+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F81964068CA94D058922AF03A41F4E2Fciscocom_-- From nobody Tue May 5 02:33:46 2020 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 C82633A15F8 for ; Tue, 5 May 2020 02:33:42 -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, 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 db0rfAs-Z5NO for ; Tue, 5 May 2020 02:33:38 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 2AB493A00E2 for ; Tue, 5 May 2020 02:33:38 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id i185so308876vki.12 for ; Tue, 05 May 2020 02:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=0A0BP11sv3pkUAwoIhrYS02I2hoFQHSnu9kYwwHhRxE=; b=RonQqG6BFJChhwzopOOZaFmm2JcUMkqG/8d5xiKCgRNhLzwquaAKIwbiGUE+MBt7ZB +Kj64NPlP74ypeH/gktcgsvr2jaehnTANn2+G2bcn+8CoX9GqH5vqJOircsD6n+U6Txt rpW5ZrhX+qWteLBaDRNNTVxXjHpJTcEED07ylh2ZKnitKrfP3aOHMbNNiY9h4gBLnekO v1O0Jsy8b0xP60DseM2LKBbR9OvNF0e/dPBpE7ig6lL2Wrut8RwOsqwJjknk7gdxhX7R 0D7u7ApI4Hodmz1ufqfghguwUjR2uV8uhkrClYzMFUJ0lBLD+0wJF9EmFa17VMuyTukZ gU2w== 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=0A0BP11sv3pkUAwoIhrYS02I2hoFQHSnu9kYwwHhRxE=; b=ZI6B165iIQNotRkBR7XinEqRZzWV3o0/rTLlJ0Z3/bJo+V+q1rc3+vL7J6h5srKWnH TQU6EZLCWn2a0BLXAEdNoXhY5/buuGUzWAtgZd3osHsFrggzHvLRDvtiqDVPSsDbDeMz Vl7iqKMZZ2+9TT1N36b7WbB1V3zWHkkQ9dMMWBpVa8m69MJTJftnhv1bafvm+j+Pf0Ix 9JZEzLHJUGlpERN9Ovdw5Xf27d4d/Bjfjja7ShXp+e+SiYdxITajTZbUVWeIbaCj9Gd8 mfCjyIYBwbYM+oQKb6ovmTb7TVcBuTFuEWFcFF2Ek+/gLkKJwkCmmbVIPI5aop+gTdqM IdeA== X-Gm-Message-State: AGi0Pua9oO5sIayTXEkZFcC2oCDlj7JR0YB5irXjo9uMR8JVd1+Chs+L kE8q/7DvfkZ6MACHOg/oajNXaU9BfyVrV4PHJuCCiw45WK8= X-Google-Smtp-Source: APiQypK2o2K/7U7lpD4LRGNVktCCVtrAMY7/oat0EtN8BI7QJFp/dWVj+iHChYmRYKQNuDZ49XPUqSFKB6arpp47KUs= X-Received: by 2002:a1f:a60b:: with SMTP id p11mr1496908vke.43.1588671216850; Tue, 05 May 2020 02:33:36 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Tue, 5 May 2020 12:33:01 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000008b9bd405a4e35777" Archived-At: Subject: [Roll] Github repo MUST include link to Note-well page 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, 05 May 2020 09:33:43 -0000 --0000000000008b9bd405a4e35777 Content-Type: text/plain; charset="UTF-8" Dear all, draft-ietf-git-using-github-06 states: " "In addition to Working Group policies, notices on repositories MUST include citations for the IETF Note Well (https://www.ietf.org/about/ note-well/ )." Thus, please make sure that your repositories have a link to the Note well. We have done pull requests (based on the enrollment-priority text, - thank you Michael!-) to add the required link into your repos. Also CONTRIBUTING.md [rpl-observations repo] presents a very good explanation. Please update it as desired. Thank you very much, Ines and Dominique. --0000000000008b9bd405a4e35777 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

draft-ietf-git-using-github-0= 6 states: "

"In addition to Working Group policies, notice= s on repositories MUST
include citations for the IETF Note Well (https://www.ietf.org/about/note-well/)."

Thus, please make = sure that your repositories have a link to the Note well.

We have done pull requests (based on the enrollment-priority text,= - thank you Michael!-) to add the required link into your repos. Also CONT= RIBUTING.md [rpl-observations repo] presents a very good explanation.
=

Please update it as desired.

T= hank you very much,

Ines and Dominique.
=



--0000000000008b9bd405a4e35777-- From nobody Tue May 5 04:53:33 2020 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 B7BD73A15F8 for ; Tue, 5 May 2020 04:53:31 -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 KbuePtjLIM79 for ; Tue, 5 May 2020 04:53:29 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 10CBA3A079E for ; Tue, 5 May 2020 04:53:28 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id m24so1024779vsq.10 for ; Tue, 05 May 2020 04:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=mijoyqj1rYOwcoquzYqaai1MD6yiljswuNuwDLMUib0=; b=efe2OgsQrgwppWVLTgNND5uyyxLGe6e+iIzNMrM6stnz5Nyx2Hkxw0fA1cbIfHrhPE KHH9VIdGayV7bEnVOn1/TA7KRpDuMUPYcH5+YRoYrZv70WZKtNTCXY4kGB8Prdwd1P1s Nhzzt/EJf41MuxGoh1hZFPU1bpA/o20C53haExEnrV7OE1LEixmIupwY8MsgYZfquPWn 8nDa5z7TP3Cs2mm8mOikzWJq9LnX5QrDxJMxkZg0q6zhfYWILaRiMddyLIgBNftxsQIh 0Hl4JpnaDQAVioibQcbq22A9uSLtSeij8xnPSog0rdcNNdNkAPKSl8nBB2uOnbBFhV/d 9mNA== 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=mijoyqj1rYOwcoquzYqaai1MD6yiljswuNuwDLMUib0=; b=jMtMLVa6aV9oS011s/6wdI02IO1tjQ68rH0Cc43BWatr/RflMFUgLtxWoXNNImXNTs bzzJ9q9qtdpF/QbJEAfaamYiMOUHSglPWozCmLU0IPDbEX5r3Xr4CclNb55FDrEICILO Kh+mP+osrlgveSxpX4wvVOkLJLcdXbZ8Uwv/koOJbVxVlgEowIWUg3qOye7JVwz4sXkT OJcNnPjdrYA+kY9OWCC/ZKSjyssMiRfhDHjtK4Wsx0gfJoEN0x0L1rMmWQE2i4n1Dpo9 axzrpW0W3Cd2hsTLLR5tTiBzh/gFzMe+aw5K/qH+DCMymTHZ4VFnwHDcdH9Zn/RXV4eK XQZw== X-Gm-Message-State: AGi0PuZuMofpSGanyg0VCDLgHvAX4Q2QzIm8kxDJRBJnNz63e3M1HBBJ aNUbiZ9V+gTa1oPgawf6OHcU74P7ATC94B4CtjGdf1kY4uM= X-Google-Smtp-Source: APiQypJvYOlousP40Q5ToSY3xNEk/szNdO0T9UdaEIVGqtIRL/IReEzEo0rhqPkrZi1T2HcJ+iD7AlLuqju1YZlcbzM= X-Received: by 2002:a67:12c4:: with SMTP id 187mr2281318vss.100.1588679607669; Tue, 05 May 2020 04:53:27 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Tue, 5 May 2020 14:52:51 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000ad578405a4e54b68" Archived-At: Subject: [Roll] Document shepherd for nsa-extension draft 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, 05 May 2020 11:53:32 -0000 --000000000000ad578405a4e54b68 Content-Type: text/plain; charset="UTF-8" Dear all, We are looking for a volunteer to be the document shepherd for : - draft-ietf-roll-nsa-extension Please let us know if you volunteer to be the Shepherd Guide: - https://www.ietf.org/blog/iesg-statement-document-shepherds/ - Document write-up: https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/ - https://trac.ietf.org/trac/rtg/raw-attachment/wiki/WGChairTraining/rtgwg_train_8.pdf - https://tools.ietf.org/html/rfc4858 Thank you very much in advance, Ines and Dominique. --000000000000ad578405a4e54b68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear all,

=C2=A0

We are looking for a volunteer to be the document s<= span style=3D"font-size:10pt;color:black">hepherd for=C2=A0:=C2=A0


-=C2=A0draft-ietf-rol= l-nsa-extension


Please let us know if=C2=A0 you volunteer to be the = Shepherd


Guide:=C2=A0

=C2=A0

Thank you very much in advance,


Ines and Dominique.

--000000000000ad578405a4e54b68-- From nobody Tue May 5 05:01:30 2020 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 069663A1647 for ; Tue, 5 May 2020 05:01:26 -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, 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 agkAsxKdoSoL for ; Tue, 5 May 2020 05:01:23 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 1CEE03A07C6 for ; Tue, 5 May 2020 05:01:22 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id y185so1040931vsy.8 for ; Tue, 05 May 2020 05:01:22 -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=t4WhMv6L/lw9GEC++tzNSE6SSo/RCFbiICdySgvizxI=; b=RSZBe9XLtpmMktTKZSsDD2XpCnSspbHoOKD1+NKWTKLJOuJ8IJRUAlfc/JwbXkU/+5 Dhlj4b1ObmzAocTFWOOm+Kqw+Mw4nm4TyHvXbuSJWNk/YOcnowJ8xhg7W5zYRnFjdrIF 3UXEN2qWwk0oXQm+zU11Ie00BkjCKzFFoAU8Y0zuf7PKf+t+h2XB47rjw7SsCZOnJTf2 z/xoI3082B83Tq0NLRyZelNbCD1y39idU+n3gJhmT6WRY2GyL4UzGjw0isrrr8sHwtkT eul1ctW0CiecDZfaxBhwvygdlPR2svhMtUYqv6oK4T2UIJ5eLNxoDBZIkYUzOCJGHUMz QPTQ== 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=t4WhMv6L/lw9GEC++tzNSE6SSo/RCFbiICdySgvizxI=; b=Rb/p1nLC75/mgdKbo9M7mmU9KZttjqi9y/a7gzC2uv5pAUNhZ35e8lnzoM1HeDrlMV eJV1JfuswjVhhzg2OxnC5k2oL+z7/rRkDZf6mFkOLP4G27GUAMqWVfvRkJ04YlvIDwqZ TZCML5+u9n+IQXLFuVPId4UpUgUMXDYYH0QoxfdVf9ojdVwdjnkDWLy0HvxorOT5Wzm4 muZxJ43V2Cjr4fwj+qqltbe6hZ96+RnlD533i5ubkPw62piO1k0nGJipqrv2wcWxoRzf qE39kwSES/PSkAk9PcJmY9Yoq0cTkCZJ9D+daIAc7ya9nobsELVvcXTQbY70XVbKgB4Q Ux9A== X-Gm-Message-State: AGi0PuaNJhsRnefq0AnM5FYkjxOMmN90PJTepmRT9xCWx0o5pEjE5GYh 8ce59PlJFBOJX54bZhWWLW6hRDDXvZBKONkpyDAdofbJ X-Google-Smtp-Source: APiQypJctbIYpbyXstgjWVCjtEzS+Zkng6k6matmskS6c4rE0mu34ZDcp3CkVf8KlP5+/2HfkVdGNmgMcMXGfJWx5wA= X-Received: by 2002:a67:eed0:: with SMTP id o16mr2194674vsp.170.1588680081322; Tue, 05 May 2020 05:01:21 -0700 (PDT) MIME-Version: 1.0 References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Tue, 5 May 2020 15:00:45 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000e8b74b05a4e56756" Archived-At: Subject: [Roll] Please help filling a Survey on planning for possible online IETF meetings 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, 05 May 2020 12:01:27 -0000 --000000000000e8b74b05a4e56756 Content-Type: text/plain; charset="UTF-8" Dear all, Please find below a Survey to fill to help to organize future IETFs meetings. As states below questions covers important topics for organization. Thank you, Ines and Dominique ---------- Forwarded message --------- * From: *IETF Executive Director *Subject: **Reminder: Survey on planning for possible online IETF meetings* *Date: *May 4, 2020 at 3:03:35 AM EDT *To: *"IETF Announcement List" *Reply-To: *ietf108planning@ietf.org This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to complete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that you explicitly provide. Thank you in advance for your help. -- Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --000000000000e8b74b05a4e56756 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find below a Survey to= fill to help to organize future IETFs meetings.=C2=A0
As states = below questions covers important topics for organization.

Thank you,

Ines and Dominique

---------- Forwarded message ---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: IETF Executive Director <exec-director@ietf.org>
Subject: Reminder: Survey on planning for possible online IETF m= eetings
Date: <= /b>May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announceme= nt List" <ietf-announce@ietf.org>
Reply-To: ietf108planning@ietf.org

This is a reminder that we need the IETF community to help = us plan for the possibility that one or more upcoming IETF meetings in 2020= and possibly 2021 may not be able to go ahead in person.=C2=A0 You can hel= p us with this by filling out the following survey:

https://www.surveymonkey.com/r/5328FFJ

S= o far we have 114 responses and we would ideally like 500 or more.

T= he survey contains the following pages and will take 15-20 minutes to compl= ete:

1. Welcome
2. Online IETF 107 and the subsequent virtual int= erims
3. Replacing a cancelled in-person meeting
4. Online meeting fo= rmat and timezone
5. Replicating humming
6. Replicating the hallway e= nvironment
7. Fees
8. Thanks and anything else

We run the surv= ey in anonymous mode which means that we only see data that you explicitly = provide.

Thank you in advance for your help.

--
Alissa Co= oper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IR= TF Chair

_______________________________________________
IETF-Ann= ounce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/li= stinfo/ietf-announce

=
--000000000000e8b74b05a4e56756-- From nobody Thu May 7 02:28:23 2020 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 487F13A08EC for ; Thu, 7 May 2020 02:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 8pE_mKunl9jO for ; Thu, 7 May 2020 02:28:19 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254093.outbound.protection.outlook.com [40.92.254.93]) (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 857A33A0ADE for ; Thu, 7 May 2020 02:28:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SEJ+ZIrit5zDwkUI9JdFbDYj/rgGbngQ0PgypFKtYmvjzToFRhYdDIzOi4AxOLx/sBUYCOQhjg4/v48/9MOQD5J099XF2Xym4DzRtO8+i1xtytO5OVLBsfc3dujBg+btskF0klLYp+Y3Qi0CMr+gf4AWLMFb+xh3Pfvi1q+d504FiHLfNn2wC9jsPL//nzOeUuMuZqRc4R2R9M39ubAOJon8yt5V87Y/N+XKiPeMGG+KcqZ8hNsohmJ76i7Tc+7H9EW4gU+Pe10YmUcwd+RTjjxMsKHiZHM7/HZ9mBxzJxEw8aPIXT73AMvlcTMARuad+LdLz0rP8qKzkjSOGh6gRg== 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=VooOU4+symWKYqPTIDHaAdCJcyB7QrvzEWXEQMCf6yY=; b=MRPAx1W6i6PtqDGVAz2HVaUDK88wIf7YGL6mxC0xzMkQdm0fvRcRXiVdim4EeN6FNGlnD+RRSJRkpqQ89jhvc980V9KLn+tqmRdC8vzza6cC1FScJtnTedoh7ZvYQp2Nvkuvc3waCtPU3kkvfxyOneoR6xQ+EzLSO5BzPV3L4sTDut9egdcvht3/Ryzfkp8EzyDi1xbf5N3sYrIx+prXOoWS1W+6YQWkz92sKhJnJ4GIdzueW5Y8eygWf/h10yvQNU1rA1rRDPASXMKcoSqoquD8yVeVlS+dVDGNtnE3I6/lY7Fm9uoA1tHsNlql1JNAColV22Bihkbz5ttpWQ55iQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VooOU4+symWKYqPTIDHaAdCJcyB7QrvzEWXEQMCf6yY=; b=maC/1EhxUOYhpq9bOYTMRUEJg+uFARyfTFzXNILt13BgX3XIZCY0Ydb+i1Wa9wgscp8P0q1A7nMpcM14JJ8ITKgk2OYjz5DM7KAblmxGzZ8AqLz5mJYXOosVyXgOmB6TkA8LmC9WNgiQHe5dBbbhTZMhGN+L/exHMymXuu+4DTJ1f9txhIKL+ccImIPAr2uaSp6daI9KsK+Vs3ZZQLzM6n4YGTN/yYjMcT9gkxilLOkd5H/NDb2X/I+8B1um8SNMVHq1B2Dn3h8QosfmVBRqspnbJvZmtTpK0p+zdJtT62LSCJnh6NpqwtJvaO4JvhdcUPZMiC6ZtCXV+KqzkRH/Hg== Received: from PU1APC01FT008.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::45) by PU1APC01HT236.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Thu, 7 May 2020 09:28:17 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.56) by PU1APC01FT008.mail.protection.outlook.com (10.152.252.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Thu, 7 May 2020 09:28:17 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2958.034; Thu, 7 May 2020 09:28:17 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoA== Date: Thu, 7 May 2020 09:28:17 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:28C7E0241B046168CF00EBEB6F1F7ADD6B3948F2FD4F21929C2E3F88C43E7C2C; UpperCasedChecksum:67BDB956AF491892FFAD2440F5792EDEE3B92830424910BE4BFACE7399CA6A30; SizeAsReceived:6631; Count:42 x-tmn: [o75dEADxDuplwO1wOxGvfDOD1h0Y3kFS] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 473d2d4d-30e2-4b8a-ad31-08d7f268f970 x-ms-traffictypediagnostic: PU1APC01HT236: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gdz68K/0WYXr819g6+xCMUSkHYCpX/5N8jAtSbqguHTiK2PcSE0FgxehlE5eSPgiKmwRTlD8IZ+xq0EdASpJREOm0LF3Ro8H0heFWXpMNBlrKrVpmDgc/xTeIhkrT/Sr4ySTA+X1s1y1a4egZe5kTJy4ECIfWrkrfO6HshZtTtVj1bLzb3WWLMoqodxB6KmvpfgOU47MsDujq7QhKtpPhw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: xJlCn8FaPz9/C48lKNHi3nMH9/i+MhkiQ0YSc3AMNjOte+a6nP3xbn6rtOk1LHaPKKiIWKuE5paMaA0iVxrlqwRMRAniR957iZQTT48XxTr+T7tYH5kpPId5NtRdT1pJWDnGVGQYkIlwreWpfMWrFg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 473d2d4d-30e2-4b8a-ad31-08d7f268f970 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 09:28:17.0436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT236 Archived-At: Subject: [Roll] capability handling 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, 07 May 2020 09:28:22 -0000 Hello All,=0A= =0A= We would like to solicit some feedback about two points in context to capab= ilities:=0A= =0A= 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, =0A= a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH)=0A= b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection.=0A= Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case?=0A= =0A= 2. Regarding the use of 'G' (global) flag on per capability basis:=0A= =0A= = From nobody Thu May 7 02:36:54 2020 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 75A9C3A0AEB for ; Thu, 7 May 2020 02:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 KK65-VmQoXEk for ; Thu, 7 May 2020 02:36:48 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255100.outbound.protection.outlook.com [40.92.255.100]) (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 61CE93A0AEA for ; Thu, 7 May 2020 02:36:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/f/2UEaouEYD7oF9vrE/O33pLXj42H9ZZ91egz2ghjG/J5Ddsq+cCQR6GLxdZOTc61ziBPM9fLFWqJGOA+rZXs5sJov/wvQjFg2Ny/wAa+356yAKdDcp0CjjA87uXrFTfgcRHftKi5a6nHgftr/YIrV/3m50GeOFOoQaREZ+Z2PjjKGUBYxmGDwETGme32iagPZO4G6GwE1B7C5cIb7TKpmxqym5t8lJ0Gg4vFuy5NEiOdbFwRnqQmiK6mo7JipYkWTOvvqZzRZwA1Eg1W5ztdcu/4I6TMxHw09i368f0Wq2KDh18CBYQzTPSkoQ/zupwiwRVVqjB+/DS/u0aIoDA== 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=GfGDCn3o5q2McdzoILa+5JhCJIN+u4rSBJxen3oqYH4=; b=HZGt+2UVIVIWvOizdNMHgmpM1H3zm8Q9OB19T5q+kIjrpAR14VKTiRONbMt2J8m7SmrX/2j4dhz64w2ypoQILyaO1gr7y1S7vdB1gUuCWyiFttBQH7bc0Z0L/9KeajWMBfCums7kvmlLAvpdAWRoG9OSJ8hjZPUL5rnLtdFA9OrqAx7DNnd6fGY2PLBAjjf7QWFNQzw7fr8DiLLhNmqQWUcTt7zIzy1krk/VevxfCIDcncFujNr0EIfTcsEVlCSZj175OpSeG61lSGY7z+cC5svhat1vFzNVAvWuRRX1S3q8ylBaFgizPGbfw0YZkg57BKDTjMdctU0lGWrJOoDesg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GfGDCn3o5q2McdzoILa+5JhCJIN+u4rSBJxen3oqYH4=; b=eSYkqEg9QAQW8uLB5PApwRiYVXjPtcPbit/z8rmAixrzKBUFKCQWgv0q0ec5ms3waxjmv+axvzf2o0SG597ymKdYiOE+NjOpAFrKL3dznlZZPwFmawTV6rYlXmh0AVJTp8kuWu9Du3MjtjKrSY4L+VROL3mvhdgDWBjtUUH5NgAF48ybP2VuozCbX5ZB7JEUtYJedyAtGO9vpeD5m04Ym2cqZG3E3uCEmaXxrRzklAUpNKSH6xQgBzNnRwIWBnrhbdCWQ9Zj1YsiMnY96xficjLQqoHX5Dh5JagXOPLdcVrMeJi9LiD9MdrDC6aHoT7P8ykQDUvn9FTsXGtdGCRfuw== Received: from HK2APC01FT033.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::53) by HK2APC01HT069.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::481) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Thu, 7 May 2020 09:36:44 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.248.59) by HK2APC01FT033.mail.protection.outlook.com (10.152.248.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Thu, 7 May 2020 09:36:44 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2958.034; Thu, 7 May 2020 09:36:43 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMe Date: Thu, 7 May 2020 09:36:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:378E9C0143B31C1653968868EE70699B5340158F2456581EEF35BF39B7C8951D; UpperCasedChecksum:A15C3FEFB8C103E7823D715F00561CA19D4406B27D54C3C3F973FA2837E7876F; SizeAsReceived:6832; Count:44 x-tmn: [suwjgCYPvY2gGkcDm/sprn8P1OLdW2dp] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 637e49a5-b180-4619-133c-08d7f26a277b x-ms-traffictypediagnostic: HK2APC01HT069: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6CPMCI4vfDQV2vxp2QAaIRyOAp8m21W3aQRn2uwzvXnJxAIOS/MejS7l14uywgd2zsuPMhEMdGiM35lmRkMzP4xyWfwhrl/21BZLL4vzOSuCprTbBOnS2h1wTqTJLZgab2MBsRg3xZImXc+IidE2XaitQgmW+HumBdJOz2dey1HnayDzha9FwQ4mK4GUBS9bk50bWQEqJzEYq1B4xwhXBQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: EJbhnNPW7Ts1tRkvqOzl3/jAmjLAQ77/pYqLHO8fTkur6ZTuRpnivTdDVNeJ2WJs6kJ67IFFWvlE+vhPH1gC7/mEeQXB5lawpsRR8Y+nzfO4n/EzyqM6xjTLn/Igd7+UxXup3lshG4tG+QFZ4+fj0g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 637e49a5-b180-4619-133c-08d7f26a277b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 09:36:43.8217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT069 Archived-At: Subject: Re: [Roll] capability handling 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, 07 May 2020 09:36:51 -0000 --_000_BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50BM1PR01MB4020INDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable << sorry my last mail was sent incomplete>> Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: Do we need an explicit 'G' flag? We already have a flag (C-copy) whi= ch indicates that nodes have to copy the cap if they don't understand the c= ap. A global capability from the root can be advertised with this bit set. = Nodes understanding this cap will anyways know how to handle and nodes not = understanding it will copy it based on the 'C' flag. Thus not requiring ano= ther 'G' flag. Best, Rahul ________________________________ From: Rahul Jadhav Sent: 07 May 2020 05:28 PM To: Routing Over Low power and Lossy networks Subject: capability handling Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: --_000_BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50BM1PR01MB4020INDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<< sorry my last mail was sent incomplete>>

Hello All,

We would like to solicit some feedback about two points in context to capabil= ities:

1. Capability Instances: Currently the document instantiates two capabilities= viz,
        a) Capability Indicators (which can be used to carry flags such as support= of 6LoRH)
        b) Routing Resource capability which indicates total RIB capacity the node= has. This should be useful for DAO Projection.
        Do you think we should add Neighbor Cache capacity indication as well and = what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:
       Do we need an explicit 'G' flag? We already have a fla= g (C-copy) which indicates that nodes have to copy the cap if they don't un= derstand the cap. A global capability from the root can be advertised with = this bit set. Nodes understanding this cap will anyways know how to handle and nodes not understanding it will copy it bas= ed on the 'C' flag. Thus not requiring another 'G' flag.

Best,
Rahul
From: Rahul Jadhav
Sent: 07 May 2020 05:28 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: capability handling
 
Hello All,

We would like to solicit some feedback about two points in context to capab= ilities:

1. Capability Instances: Currently the document instantiates two capabiliti= es viz,
        a) Capability Indicators (which = can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability w= hich indicates total RIB capacity the node has. This should be useful for D= AO Projection.
        Do you think we should add Neigh= bor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:

       
--_000_BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50BM1PR01MB4020INDP_-- From nobody Thu May 7 09:38:15 2020 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 BB0FB3A0ADC; Thu, 7 May 2020 09:37:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158886943764.3475.6047615644810853641@ietfa.amsl.com> Date: Thu, 07 May 2020 09:37:17 -0700 Archived-At: Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG Virtual Meeting: 2020-05-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, 07 May 2020 16:37:18 -0000 The Routing Over Low power and Lossy networks (roll) Working Group will hold a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC. Agenda: Draft Agenda: New Option and Backward compatibility Compression for control messages? Applicable for nsa-extension RPL Observation topics RPL Ping Additional Items to be determined Information about remote participation: Roll interim May meeting Hosted by ROLL WG Monday, May 25, 2020 6:45 am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada) Meeting number: 611 684 862 Password: vbR9EnBMs98 https://ietf.webex.com/ietf/j.php?MTID=m59fad4e3500688e160f0d772b9f942ac Join by video system Dial 611684862@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 611 684 862 Meeting Information like link to video recording , etc would be located in https://github.com/roll-wg/ROLL-Interim-Meeting From nobody Thu May 7 10:05:38 2020 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 06C5D3A0BBA; Thu, 7 May 2020 10:05:34 -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.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158887113396.30674.6129624326883694124@ietfa.amsl.com> Date: Thu, 07 May 2020 10:05:34 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-aodv-rpl-08.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: Thu, 07 May 2020 17:05:35 -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 : AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-Power and Lossy Networks Authors : Satish Anamalamudi Mingui Zhang Charles E. Perkins S.V.R Anand Bing Liu Filename : draft-ietf-roll-aodv-rpl-08.txt Pages : 27 Date : 2020-05-07 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 (AODV-RPL). 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-08 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 Thu May 7 11:01:28 2020 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 EFCB03A0984 for ; Thu, 7 May 2020 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XWgLg-mTKpV6 for ; Thu, 7 May 2020 11:01:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DF93A0941 for ; Thu, 7 May 2020 11:01:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 992613897F for ; Thu, 7 May 2020 13:59:18 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dUrpCD0TAmZM for ; Thu, 7 May 2020 13:59:18 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 540A33897E for ; Thu, 7 May 2020 13:59:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 654D91D3 for ; Thu, 7 May 2020 14:01:18 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] capability handling 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, 07 May 2020 18:01:25 -0000 --=-=-= Content-Type: text/plain Rahul Jadhav wrote: > We would like to solicit some feedback about two points in context to > capabilities: > 1. Capability Instances: Currently the document instantiates two > capabilities viz, a) Capability Indicators (which can be used to carry > flags such as support of 6LoRH) > b) Routing Resource capability which > indicates total RIB capacity the node has. This should be useful for > DAO Projection. > Do you think we should add Neighbor Cache capacity > indication as well and what would be the use-case? In some implementations the Neighbor Cache and RIB might come from the same pool of resources. Both are lookup /128 and add-header and xmit :-) (BSD systems merged them back in BSD4.4, as an example) If a node runs out of RIB entries, it can't add any more grandchildren. If a node runs out of NC entries, it can't add any more peers: children or parents. It seems that we need to collect both information, but we might need to be clear if they are linked. > Do we need an explicit 'G' flag? We already have a flag (C-copy) > which indicates that nodes have to copy the cap if they don't > understand the cap. A global capability from the root can be > advertised with this bit set. Nodes understanding this cap will > anyways know how to handle and nodes not understanding it will copy > it based on the 'C' flag. Thus not requiring another 'G' flag. I have to think more on this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl60TO4ACgkQgItw+93Q 3WVV3gf8Dyx6fY5b/PIqc87FEKbBoSp3Ge6yglUq9NEIGhQy9TN38qGaP36C2sp6 x9Xo8a+4GlyymPSl+K/BgIvzpq3U6pHi2yAasBA34xkhNypCiHnodooW3jKWgYhk /w/Ay6eTeL0hQnNMigMzMnWk4cXwA52mc5f+yN6QkBE6q0oaMmK3j2WkiNbTGNXE uGVCWu5sxgqZfjL18eamaAC/fsnX0oedyzSwqGRS9ZacTFTR2aOvBPbu7C5EePzI Q0DkoNx5aF/3HHjjTBc9M3yqb9WtNzqif9DGR2dUk/Ls9mLWZJPjuQJnguVVYtNU 9is+MYzA7Xq8WnscrLkjLkPNq9pbsw== =nxbS -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 7 12:39:59 2020 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 734143A0CF4; Thu, 7 May 2020 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 ZD1S7o5YC-tH; Thu, 7 May 2020 12:39:55 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.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 3E6343A0D35; Thu, 7 May 2020 12:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1588880387; bh=1cZ3DGo8cKhme8ktrLgInGUXgLAfrOXvEif8 bCTFTqA=; h=Received:To:Cc:From:Subject:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Language:X-ELNK-Trace:X-Originating-IP; b=kA7uMTMaL57Qw4w7 cQCFo4hpkC12RWHrB1n9eQzFclxbGRuhrlPUhx0L7tIY1wf16vxY+iixqsgSDg18EEP IKWMm5wWVhMV+VOPQ2f2RPVJQJ8pDKs3Do9eIaNxv85hThfjB/bZnr7nr2KRCtqRCTn u0gAezrtsz8951+OZFFl0JX5tn/VTTh1//GBRAM7eY0jzHot2NI6zeOO1CVQG05wWLc VHbgZQQR8qvlMZ/EPtWT7xhgPzSPFxZilBsxUzKqsmJjtj35DPYSyLqimIRneqA39Rr H5KWWhXevMX2fu9aNQXTzhkWQduodcZPT6ccUEVBc1T1wqlTKiTjcnq79w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=i+PBaMNrTUdQeKW7tWxl7pdCTGho/Idba5rupsm+RgxajPjxB9zNl4wN9fjkCr3yqA43N/uHp8NiBQZdih3OxGcKIaKpb7TvGqyoSIoVjG/Qgpksr5VHCHws3hJDperGTSGjldn65frsMUOaZKXcN/8ZRPOPDwkyqP+SxnxFpHgtqa9fFRqSQW+f1BNOg2FzEcjFmLrZj2z5G2RsIl093Vh8D5rE8JjBw4wHSHbACr5Dn+6KBDME12yh/2/l2x5rRIAqOOC8Sv90SRP24+7lM15lukIjoRoOC5rW8S7QarZlQRyamT3wGtB3RRnWCrEnnQv3uiHbiiCDlXU9E7HxXA==; h=Received:To:Cc:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1jWmMz-000BH6-Hf; Thu, 07 May 2020 15:39:45 -0400 To: Routing Over Low power and Lossy networks Cc: "draft-ietf-roll-aodv-rpl@ietf.org" From: Charlie Perkins Message-ID: <1a0bcb47-915e-eb7c-de1b-290ebfa71cba@earthlink.net> Date: Thu, 7 May 2020 12:39:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95b2344327891c75687fc230954e8dc94a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [Roll] Summary of recent changes for draft-ietf-roll-aodv-rpl-08 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, 07 May 2020 19:39:58 -0000 Hello folks, Here is a summary of the changes we have made in version 8 for our draft-ietf-roll-aodv-rpl. Changes from version 07 to version 08    o  Instead of describing the need for routes to "fulfill the       requirements", specify that routes need to "satisfy the Objective       Function".    o  Removed all normative dependencies on [RFC6997]    o  Rewrote Section 10 to avoid duplication of language in cited       specifications.    o  Added Section 11 with text and citations to more fully describe       how implementations determine whether links are symmetric.    o  Modified text comparing AODV-RPL to other protocols to emphasize       the need for AODV-RPL instead of the problems with the other       protocols.    o  Clarified that AODV-RPL uses some of the base RPL specification       but does not require an instance of RPL to run.    o  Improved capitalization, quotation, and spelling variations.    o  Specified behavior upon reception of a RREQ-DIO or RREP-DIO       message for an already existing DODAGID (e.g, Section 6.4).    o  Fixed numerous language issues in IANA Considerations Section 9.    o  For consistency, adjusted several mandates from SHOULD to MUST and       from SHOULD NOT to MUST NOT.    o  Numerous editorial improvements and clarifications. Regards, Charlie P. From nobody Thu May 7 12:47:20 2020 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 030C63A0CB3; Thu, 7 May 2020 12:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 AyMkQsYcFfaQ; Thu, 7 May 2020 12:46:59 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (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 8D1C63A0CAF; Thu, 7 May 2020 12:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1588880818; bh=ROY3xa+WONHJzBJR7TFg/fPnbc2PfCYmEqaN EKvDljE=; h=Received:From:Subject:To:Cc:References:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=R6PG2H+hc8HBSlMts6ZKDm7yYgKAIVHtU XvnO9Ro7UytPmJHcSSZHAAO9aBuOffZyIVGSb+p1fbKV2ZUlukve/FjA8EAAHQWSPDR X/3Y8RzB81M5MFiTiJmfi1Ox7Fi6VyRtF5TyV5ptFv4pOjJHoXY58gmqMAXjGYi2yeK DE4DFyKQBsO7iBcIUEfGTN32qgT0gTeRD/TjXcALc9iMhq7ukieZSK/9zqgfLRBR5FW HFO7jBwOKjt/6S2oRxxwvDSllqgKzwNit/9Gd7mZvH0vHJ35/lPmgGGmAVzY/g5OlIG p15wfTuouGM7h1mZziSuS98+XJMK1eMpZZAMwdH4g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=aNQjU7wSdOtE2EU1ebS4Ry0q33mD6XeUculQ5rxw1yf2EN3CzB+3xKTyXlGKAZQRqioHIMpRtMZK7xKLCuSIwJfPuq7eK1cNAdc8rcSVOAfas+kgbwEOKgFe/IEetu5ZV77a04VtSMIHloVBsjReGksK86kj0Kq2wBQRisKXJRJMD7FiViF3AgPmfYLjONbxcajJFfHWs9wDRtG1qUKXwQoDlOhIuky4au6LNl3SqDb7Yu5hFPAp2EhxhdsttGYu7AnlBFsr7x/huCOW8yqRAfFAw4+vCJOWOZSIwvO35czsmTU8gMI/37+9tuNQg7yyWqFxy41FTsLdDPp73l0y8A==; h=Received:From:Subject:To:Cc:References:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1jWmTx-000BJf-1c; Thu, 07 May 2020 15:46:57 -0400 From: Charlie Perkins To: Routing Over Low power and Lossy networks Cc: "draft-ietf-roll-aodv-rpl@ietf.org" References: <1cfda39e-e9ee-311d-1fa2-fc42742f9e35@earthlink.net> Message-ID: <269f2ccd-5107-7890-814f-9206450e6f65@earthlink.net> Date: Thu, 7 May 2020 12:46:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1cfda39e-e9ee-311d-1fa2-fc42742f9e35@earthlink.net> Content-Type: multipart/alternative; boundary="------------6CDA6795BCDEEBCA33260534" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95fa2609ca147772fbc3b556acfaade95a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [Roll] Part 1: comment resolutions for AD Review of draft-ietf-roll-aodv-rpl-07 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, 07 May 2020 19:47:17 -0000 This is a multi-part message in MIME format. --------------6CDA6795BCDEEBCA33260534 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello folks, Today we have submitted a revised version 8 for our draft-ietf-roll-aodv-rpl.  Here is part 1 showing some resolutions for comments made by our AD for the improvement of draft-ietf-roll-aodv-rpl-07. In addition we have done the following: * rewrite section 8 * rewrite RFC 6997 text for AODV-RPL security behaviors * provide citations for work in the Appendix In a few minutes I will also send email with a summary, in a more compact format, of the changes that we have made to the draft. Regards, Charlie P. -------- Forwarded Message -------- Subject: Fwd: Re: AD Review of draft-ietf-roll-aodv-rpl-07 Date: Wed, 29 Apr 2020 12:35:32 -0700 From: Charlie Perkins To: Alvaro Retana CC: S.V.R Anand , Remy Liubing , Satish Anamalamudi Hello Alvaro, We are preparing a new revision of draft-ietf-roll-aodv-rpl to be released in a day or so.  Here are some resolutions for most of your comments.  The other points have also been addressed as you will see in the new revision. Regards, Charlie P. -------- Forwarded Message -------- Subject: Re: AD Review of draft-ietf-roll-aodv-rpl-07 Date: Sun, 29 Mar 2020 12:51:52 -0700 From: Charlie Perkins To: Satish Anamalamudi , S.V.R Anand , Remy Liubing ... Regards, Charlie P. On 8/1/2019 7:54 AM, Alvaro Retana wrote: > Dear authors: > > I just finished reading this document.  I am excited about the new > functionality, but I have several significant issues/questions about > the document, and a lot of comments (in-line below). > > (1) What is AODV-RPL? > > Reading the document, my impression of AODV-RPL varies between an > enhancement to RPL for Reactive Route Discovery (*maybe* in addition > to the usual proactive routing), to ships-in-the-night reactive-only > protocol that uses some of the RPL concepts (but not exactly sure > which ones).  The different MOP indicates that it is different from > "base" RPL (rfc6550), but it is not clear what the assumptions > are...and which parts are "inherited" from the "base" and which ones > are not used. > > Another way to ask the same question is: What is the relationship of > AODV-RPL to RPL?  What mechanisms are not applicable with the new > MOP?  Is it expected that an instance of RPL will also be running in > the network? > > Please be clear early in the document.  To quote Charlie: "AODV-RPL is > a variation on RPL" [1].  What remains, what changes, etc.. I think the new Introduction goes a long way towards resolving this comment. > > > (2) Document Status (for the Chairs/Shepherd) > > I didn't find a specific discussion in the archive about the status of > this document.  Did one take place?  At this point I am mostly curious > given the similarities with rfc6997 (Experimental) and the fact that > "Future Work" is discussed -- not typical in a Standards Track > document. IOW, why is this document intended to be a Proposed Standard > and not Experimental? In my understanding it is intended to be a Proposed Standard so that implementors have a Standard available (i.e., do not have to rely on Experimental protocols). > > > (3) Replacing rfc6997?? > > This document uses some of the features from rfc6997 (see some > comments about that in-line), which is fine.  The Introduction falls > just short of saying that this work replaces rfc6997.  Should it be > considered a replacement?  I ask mostly in the context of rfc7733 (RPL > in Home and Building) which mandates (MUST) the use of rfc6997.  > Should rfc7733 be Updated?  [I'm just asking the question for it to be > considered...I am not sure of deployments which conform to rfc7733 or > rfc6997...or the impact this would have.] My preference would be for AODV-RPL to replace RFC 6997.  We were requested to include features from RFC 6997, with the understanding that doing so would eliminate the value of implementing RFC 6997. > > > (4) Link checks > > The operation of AODV-RPL depend on link checks (§6.2.1/§6.4) to > determine symmetry and whether it can "fulfill the requirements".  But > these checks are not explained or defined anywhere (are they?) beyond > an *example* in the Appendix.  I think defining the checks is a > critical part of the specification of the mechanism...specially for a > Standards Track protocol. I think this is all about evaluating the Objective Function for the links.  We just have to specify that the router evaluates the Objective Function to see if the link satisfies the Function. ................. > > ... > 14    Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) > > [minor] This is not the clearest title I've ever seen.   Suggestion: > Reactive Route Discovery using RPL (AODV-RPL)    ...or something like > that. > > 15                     draft-ietf-roll-aodv-rpl-07 > > 17Abstract > > 19  Route discovery for symmetric and asymmetric Point-to-Point (P2P) > 20  traffic flows is a desirable feature in Low power and Lossy Networks > 21  (LLNs).  For that purpose, this document specifies a reactive P2P > 22  route discovery mechanism for both hop-by-hop routing and source > 23  routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL > 24  protocol.  Paired Instances are used to construct directional paths, > 25  in case some of the links between source and target node are > 26  asymmetric. > > [minor] s/(AODV) based RPL protocol/(AODV) based RPL protocol (AODV-RPL) How about: AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low- Power and Lossy Networks > > > ... > 1001. Introduction > > [general comment] Avoid mentioning the "negative" of other proposals > and focus on why this work is needed.  IOW, the justification should > not be "because others can't do it". How about replacing the first three paragraphs with the following:    AODV-RPL specifies P2P route discovery, utilizing RPL [RFC6550] (Routing    Protocol for Low-Power and Lossy Networks) with a new MOP (Mode Of    Operation).  Routes are discovered using two multicast messages    to discover routes that may traverse asymmetric links. This promotes    higher route diversity, often reducing interference near root nodes.    More importantly, AODV-RPL can enable applications to run that might    otherwise fail, in networks containing suitable asymmetric routes but    no symmetric routes as would be required by RPL or P2P-RPL [RFC6997].    As an extra benefit, AODV-RPL eliminates the need for address vector    overhead in hop-by-hop mode, significantly reducing the control    packet size. > > [nit] Some of the paragraphs throughout the document are very long and > could be split to better convey the ideas. If you have particular examples in mind please let us know. I'll take a look and see what sticks out. > > 102  RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy > 103  Networks)) is a IPv6 distance vector routing protocol designed to > 104  support multiple traffic flows through a root-based Destination- > 105  Oriented Directed Acyclic Graph (DODAG).  Typically, a router does > 106  not have routing information for most other routers. Consequently, > 107  for traffic between routers within the DODAG (i.e., Point-to-Point > 108  (P2P) traffic) data packets either have to traverse the root in non- > 109  storing mode, or traverse a common ancestor in storing mode.  Such > 110  P2P traffic is thereby likely to traverse longer routes and may > 111  suffer severe congestion near the DAG root (for more information see > 112  [RFC6997], [RFC6998]). > > [nit] s/RPL[RFC6550]/RPL [RFC6550] Done, subject to the above. > > [minor] s/Routing Protocol for LLNs (Low-Power and Lossy > Networks)/Routing Protocol for Low-Power and Lossy Networks    That's > the name of the protocol. Done. > > [nit] s/is a IPv6/is an IPv6 Fixed. > > [minor] "Such P2P traffic is thereby likely to traverse longer routes > and may suffer severe congestion near the DAG root (for more > information see [RFC6997], [RFC6998])."  I see that those other RFCs > also make the statement that congestion is possible, and even longer > routes...but I don't see more information there.  Did I miss it?  If > not, then I don't see the value of those references at this point. > > 114  To discover better paths for P2P traffic flows in RPL, P2P-RPL > 115  [RFC6997] specifies a temporary DODAG where the source acts as a > 116  temporary root.  The source initiates DIOs encapsulating the P2P > 117  Route Discovery option (P2P-RDO) with an address vector for both hop- > 118  by-hop mode (H=1) and source routing mode (H=0). Subsequently, each > 119  intermediate router adds its IP address and multicasts the P2P mode > 120  DIOs, until the message reaches the Target Node, which then sends the > 121  "Discovery Reply" object.  P2P-RPL is efficient for source routing, > 122  but much less efficient for hop-by-hop routing due to the extra > 123  address vector overhead.  However, for symmetric links, when the P2P > 124  mode DIO message is being multicast from the source hop-by-hop, > 125  receiving nodes can infer a next hop towards the source.  When the > 126  Target Node subsequently replies to the source along the established > 127  forward route, receiving nodes determine the next hop towards the > 128  Target Node.  For hop-by-hop routes (H=1) over symmetric links, this > 129  would allow efficient use of routing tables for P2P-RDO messages > 130  instead of the "Address Vector". > > [minor] Expand DIO on first use. Done.  Maybe twice :-) > > [minor] The description above of P2P-RPL seems to include too much > (unnecessary for this document) detail.  It also seems to propose > enhancements (in the last couple of sentences).  Consider simplifying > to something like this: > >    To discover better paths for P2P traffic flows in RPL, P2P-RPL >    [RFC6997] specifies a temporary DODAG where the source acts as a >    temporary root.  P2P-RPL is efficient for source routing, >    but can be much less efficient for hop-by-hop routing due to the >    extra address vector overhead. Done, subject to preference for the shorter Introduction introduction. > > > 132  RPL and P2P-RPL both specify the use of a single DODAG in networks of > 133  symmetric links, where the two directions of a link MUST both satisfy > 134  the constraints of the objective function.  This disallows the use of > 135  asymmetric links which are qualified in one direction.  But, > 136  application-specific routing requirements as defined in IETF ROLL > 137  Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be > 138  satisfied by routing paths using bidirectional asymmetric links.  For > 139  this purpose, [I-D.thubert-roll-asymlink] described bidirectional > 140  asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the > 141  DAG root (DODAGID) is common for two Instances.  This can satisfy > 142  application-specific routing requirements for bidirectional > 143  asymmetric links in core RPL [RFC6550].  Using P2P-RPL twice with > 144  Paired DODAGs, on the other hand, requires two roots: one for the > 145  source and another for the target node due to temporary DODAG > 146  formation.  For networks composed of bidirectional asymmetric links > 147  (see Section 5), AODV-RPL specifies P2P route discovery, utilizing > 148  RPL with a new MoP.  AODV-RPL makes use of two multicast messages to > 149  discover possibly asymmetric routes.  This provides higher route > 150  diversity and can find suitable routes that might otherwise go > 151  undetected by RPL.  AODV-RPL eliminates the need for address vector > 152  overhead in hop-by-hop mode.  This significantly reduces the control > 153  packet size, which is important for Constrained LLN networks.  Both > 154  discovered routes (upward and downward) meet the application specific > 155  metrics and constraints that are defined in the Objective Function > 156  for each Instance [RFC6552].  On the other hand, the point-to-point > 157  nature of routes discovered by AODV-RPL can reduce interference near > 158  the root nodes and also provide routes with fewer hops, likely > 159  improving performance in the network. > > [major] "RPL and P2P-RPL both specify the use of a single DODAG in > networks of symmetric links, where the two directions of a link MUST > both satisfy the constraints of the objective function."  s/MUST/must >   Because you are referring to RPL/P2P-RPL, the MUST is not Normative. > > [minor] s/as defined in IETF ROLL Working Group [RFC5548]/as defined > in [RFC5548] > > [minor] s/application-specific routing requirements...may be satisfied > by routing paths using bidirectional asymmetric > links./application-specific routing requirements may also be satisfied > by routing paths using bidirectional asymmetric links.     I found > just one mention of anything related to asymmetry (in rfc5673)...so I > think adding "also" is important. Fixed. > > [minor] "For this purpose, [I-D.thubert-roll-asymlink] described > bidirectional asymmetric links for RPL [RFC6550] with Paired DODAGs, > for which the DAG root (DODAGID) is common for two Instances.  This > can satisfy application-specific routing requirements for > bidirectional asymmetric links in core RPL [RFC6550]."    I think that > mention to this draft is unnecessary and may be confusing to readers: > the work seems to have been abandoned, and if it satisfies the > requirements, then why do we need something else?  ;-) > > [minor] I would also take out this sentence: "Using P2P-RPL twice..." Done. > > [minor] Expand MoP on first use. BTW, rfc6550 uses MOP (not MoP), > please be consistent. Done. > > [minor] "Both discovered routes (upward and downward) meet the > application specific metrics and constraints that are defined in the > Objective Function for each Instance [RFC6552]."   I didn't find any > talk of application specific metrics in rfc6552. I think the citation was intended for "Objective Function", not Instance.  And anyway the reference should probably be to RFC 6550. > > > ... > 1702. Terminology > > 172  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > 173  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > 174  "OPTIONAL" in this document are to be interpreted as described in > 175  [RFC2119], [RFC8174].  This document uses the following terms: > > [major] Please use the rfc8174 template without modifications. Done. > > > ... > 2643. Overview of AODV-RPL > > [minor] It would be very nice if this overview had forward references > to where the behavior is specified. > > 266  With AODV-RPL, routes from OrigNode to TargNode within the LLN > 267  network are established "on-demand".  In other words, the route > 268  discovery mechanism in AODV-RPL is invoked reactively when OrigNode > 269  has data for delivery to the TargNode but existing routes do not > 270  satisfy the application's requirements.  The routes discovered by > 271  AODV-RPL are not constrained to traverse a common ancestor.  Unlike > 272  RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric > 273  communication paths in networks with bidirectional asymmetric links. > 274  For this purpose, AODV-RPL enables discovery of two routes: namely, > 275  one from OrigNode to TargNode, and another from TargNode to OrigNode. > 276  When possible, AODV-RPL also enables symmetric route discovery along > 277  Paired DODAGs (see Section 5). > > [major] I get the impression that this document is an extension to > RPL, to be used when the existing routes don't meet specific > requirements...at this point the reactive part would kick in.  Is that > a fair characterization? Not really.  AODV-RPL uses some of the base RPL specification but does not require an instance of RPL to run.  I put in some additional clarifying text about this.  I think it also resolves the next comment. > > The document jumps into talking about the extension, but it says > nothing about how the base RPL is used with it...or even if it is.  > Please spend a paragraph explaining that relationship. See the last point of discussion. > > 279  In AODV-RPL, routes are discovered by first forming a temporary DAG > 280  rooted at the OrigNode.  Paired DODAGs (Instances) are constructed > 281  according to the AODV-RPL Mode of Operation (MoP) during route > 282  formation between the OrigNode and TargNode.  The RREQ-Instance is > 283  formed by route control messages from OrigNode to TargNode whereas > 284  the RREP-Instance is formed by route control messages from TargNode > 285  to OrigNode.  Intermediate routers join the Paired DODAGs based on > 286  the rank as calculated from the DIO message. Henceforth in this > 287  document, the RREQ-DIO message means the AODV-RPL mode DIO message > 288  from OrigNode to TargNode, containing the RREQ option (see > 289  Section 4.1).  Similarly, the RREP-DIO message means the AODV-RPL > 290  mode DIO message from TargNode to OrigNode, containing the RREP > 291  option (see Section 4.2).  The route discovered in the RREQ-Instance > 292  is used for transmitting data from TargNode to OrigNode, and the > 293  route discovered in RREP-Instance is used for transmitting data from > 294  OrigNode to TargNode. > > [nit] s/rank/Rank/g   To be consistent with how rfc6550 uses the term. Fixed.  I hope that all instances of "rank" are O.K. to be capitalized. > > 2964. AODV-RPL DIO Options > > 2984.1. AODV-RPL DIO RREQ Option > > 300  OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO > 301  message.  A RREQ-DIO message MUST carry exactly one RREQ option. > > [major] What should a receiver do if more than one RREQ options are > received? I specified that it SHOULD be dropped.  I don't think this is too harsh, even though other solutions are possible. > > 303     0                   1                   2         3 > 304     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 > 305+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 306    |     Type      | Option Length |S|H|X| Compr | L |   MaxRank   | > 307+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 308    |  Orig SeqNo   |             | > 309    +-+-+-+-+-+-+-+-+             | > 310    |             | > 311    |             | > 312    |           Address Vector (Optional, Variable Length)          | > 313    |             | > 314    |             | > 315+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 317            Figure 1: DIO RREQ option format for AODV-RPL MoP > > 319  OrigNode supplies the following information in the RREQ option: > > 321  Type > 322     The type assigned to the RREQ option (see Section 9.2). > > [major] s/Type/Option Type/g That is the name in rfc6550. Fixed. > > [minor] Use TBDx so that it matches the IANA Considerations section.  > The same applies to other places where TBDx can be used. Fixed. > > ... > 348  L > > 350     2-bit unsigned integer determining the duration that a node is > 351     able to belong to the temporary DAG in RREQ-Instance, including > 352     the OrigNode and the TargNode.  Once the time is reached, a node > 353     MUST leave the DAG and stop sending or receiving any more DIOs for > 354     the temporary DODAG.  The definition for the "L" bit is similar to > 355     that found in [RFC6997], except that the values are adjusted to > 356     enable arbitrarily long route lifetime. > > [major] "definition for the "L" bit is similar to that found in > [RFC6997], except that..."   I think that this statement may be > confusing to readers...remove it. Done. > > 358     *  0x00: No time limit imposed. > 359     *  0x01: 16 seconds > 360     *  0x02: 64 seconds > 361     *  0x03: 256 seconds > > 363     L is independent from the route lifetime, which is defined in the > 364     DODAG configuration option.  The route entries in hop-by-hop > 365     routing and states of source routing can still be maintained even > 366     after the DAG expires. > > [??] I don't understand what the last sentence is trying to say.  It > sounds as if the information learned through the DAG can still be used > after the DAG expires...up until the route lifetime expires...is that > it?  Please clarify. How about this: The route entries in hop-by-hop routing     and states of source routing can still be maintained     even after the node no longer maintains DAG connectivity or     messaging. > > > ... > 373  Orig SeqNo > 374     Sequence Number of OrigNode, defined similarly as in AODV > 375     [RFC3561]. > > [major] "similarly as in AODV"  Similarly, or the same??  Note that > this reference could require rfc3561 to be a Normative Reference. Fixed, by deleting the reference.  Would it be useful to make a reference to AODV's sequence number operation in the Introduction? > > I found this text in §6.1, which defines this field.  Which one is > correct?  Suggestion: point to §6.1. > >    Each node maintains a sequence number, which rolls over like a >    lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for >    detailed operation.  When the OrigNode initiates a route discovery >    process, it MUST increase its own sequence number to avoid conflicts >    with previously established routes.  The sequence number is carried >    in the OrigSeqNo field of the RREQ option. Fixed. > > > ... > 382  A node MUST NOT join a RREQ instance if its own rank would equal to > 383  or higher than MaxRank.  Targnode can join the RREQ instance at a > 384  rank whose integer portion is equal to the MaxRank.  A router MUST > 385  discard a received RREQ if the integer part of the advertised rank > 386  equals or exceeds the MaxRank limit.  This definition of MaxRank is > 387  the same as that found in [RFC6997]. > > [minor] s/own rank would equal to/own rank would be equal to > > [nit] s/Targnode/TargNode > > [minor] The second sentence sounds like it contradicts the first one > (where it says that "A node MUST NOT join..."); I think that inverting > the order would help: > >    TargNode can join the RREQ instance at a rank whose integer portion is >    equal to the MaxRank.  Other nodes MUST NOT join a RREQ instance if its >    own rank is equal to or higher than MaxRank. > Done, done, and done. > > [major] "This definition of MaxRank is the same as that found in > [RFC6997]."  True, for the most part: the context of the definition is > different.  Because the definition are not exactly the same, and > MaxRank is defined in this document, please take the sentence out.  I > don't think it adds anything significant. Done. > > > 3894.2. AODV-RPL DIO RREP Option > > 391  TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO > 392  message.  A RREP-DIO message MUST carry exactly one RREP option. > 393  TargNode supplies the following information in the RREP option: > > [major] What should the receiver do if more than one RREP option is > received? How about:           A RREP-DIO message MUST carry exactly one RREP option,     otherwise the message SHOULD be dropped. > > > ... > 441  Shift > 442     6-bit unsigned integer.  This field is used to recover the > 443     original InstanceID (see Section 6.3.3); 0 indicates that the > 444     original InstanceID is used. > > [major] s/InstanceID/RPLInstanceID/g Done. > > 446  Rsv > 447     MUST be initialized to zero and ignored upon reception. > > [major] Do you expect these bits to be assigned by IANA in the future? No, but a future specification could modify the operation. Do we need to say that? > > > ... > 4564.3. AODV-RPL DIO Target Option > > 458  The AODV-RPL Target (ART) Option is based on the Target Option in > 459  core RPL [RFC6550].  The Flags field is replaced by the Destination > 460  Sequence Number of the TargNode and the Prefix Length field is > 461  reduced to 7 bits so that the value is limited to be no greater than > 462  127. > > [minor] What is the name of this option: "AODV-RPL DIO Target Option" > or "AODV-RPL Target Option"?  Please be consistent. Hopefully fixed. > > [??] "the Prefix Length field is reduced to 7 bits so that the value > is limited to be no greater than 127."  Why?  Is there an advantage? > Seriously, I'm curious. Well, I don't think there are any prefixes longer than 127 bits. > > 464  A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO > 465  message MUST carry exactly one ART Option. > > [major] What should a node do if more than one ART Option is received > in a RREP-DIO message? How about:     A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO     message MUST carry exactly one ART Option. Otherwise, the message     SHOULD be dropped. > > 467  OrigNode can include multiple TargNode addresses via multiple AODV- > 468  RPL Target Options in the RREQ-DIO, for routes that share the same > 469  constraints.  This reduces the cost to building only one DODAG. > 470  Furthermore, a single Target Option can be used for different > 471  TargNode addresses if they share the same prefix; in that case the > 472  use of the destination sequence number is not defined in this > 473  document. > > [major] To be clear, what are the "constraints"?  Where are they > defined/signaled?  Are you talking about the contents of the RREQ > Option (S, H, MaxRank...anything else?)?  If so, please point that out > explicitly; "constraints" are mentioned in different places, but I > couldn't find an explicit definition. I changed instances of "fulfill the constraint" to be "satisfy the Objective Function".  I think this resolves the issue. > > [major] "...in that case the use of the destination sequence number is > not defined in this document."   Then that means that this last > feature is not supported...right?  If that's true, then please don't > mention it. Fixed. > > > ... > 511  Target Prefix / Address > 512     (variable-length field) An IPv6 destination address or prefix. > 513     The Prefix Length field contains the number of valid leading bits > 514     in the prefix.  The bits in the Target Prefix / Address field > 515     after the prefix length (if any) MUST be set to zero on > 516     transmission and MUST be ignored on receipt. > > [major] "The bits in the Target Prefix / Address field after the > prefix length (if any)..."   I can see how this "is ok" because the > receiver knows of these trailing bits from the Option Length...*but*, > why even allow it?  Why would the Target Prefix / Address not simply > have a length = Prefix Length? > > BTW, I know that rfc6550 has the same definition.  That doesn't make > it right.  Every extra bit has a cost...prefixes are elided, and here > extra bits are allowed. The only extra bits that are specified are required in order that the option has an integer number of octets.  We do allow prefixes that are not an integer number of octets and so some bits have to be specified as zero. > > > 5185. Symmetric and Asymmetric Routes > > 520  In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode, > 521  R is an intermediate router, and T is the TargNode. If the RREQ-DIO > 522  arrives over an interface that is known to be symmetric, and the 'S' > 523  bit is set to 1, then it remains as 1, as illustrated in Figure 4. > 524  If an intermediate router sends out RREQ-DIO with the 'S' bit set to > 525  1, then all the one-hop links on the route from the OrigNode O to > 526  this router meet the requirements of route discovery, and the route > 527  can be used symmetrically. > > [nit] A couple of places use "S bit", "'S' bit" is used above (and in > most of the document)...please be consistent.   Recommendation: S bit > or S-bit.   [BTW, please apply the same style to the other bits.] Fixed. > > > ... > 552  Upon receiving a RREQ-DIO with the 'S' bit set to 1, a node > 553  determines whether this one-hop link can be used symmetrically, i.e., > 554  both the two directions meet the requirements of data transmission. > 555  If the RREQ-DIO arrives over an interface that is not known to be > 556  symmetric, or is known to be asymmetric, the 'S' bit is set to 0.  If > 557  the 'S' bit arrives already set to be '0', it is set to be '0' on > 558  retransmission (Figure 5).  Therefore, for asymmetric route, there is > 559  at least one hop which doesn't fulfill the constraints in the two > 560  directions.  Based on the 'S' bit received in RREQ-DIO, the TargNode > 561  T determines whether or not the route is symmetric before > 562  transmitting the RREP-DIO message upstream towards the OrigNode O. > > [nit] s/for asymmetric route/for an asymmetric route Fixed. > > 564  The criteria used to determine whether or not each link is symmetric > 565  is beyond the scope of the document, and may be implementation- > 566  specific.  For instance, intermediate routers MAY use local > 567  information (e.g., bit rate, bandwidth, number of cells used in > 568  6tisch), a priori knowledge (e.g. link quality according to previous > 569  communication) or use averaging techniques as appropriate to the > 570  application. > > [major] s/MAY/may   This may is not Normative because there is no > specific action (just examples). > Fixed. > > ... > 6026.1. Route Request Generation > ... > 614  Each node maintains a sequence number, which rolls over like a > 615  lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for > 616  detailed operation.  When the OrigNode initiates a route discovery > 617  process, it MUST increase its own sequence number to avoid conflicts > 618  with previously established routes.  The sequence number is carried > 619  in the OrigSeqNo field of the RREQ option. > > [minor] s/Each node maintains a sequence number...detailed > operation./Each node maintains a sequence number; the operation is > specified in section 7.2 of [RFC6550]. > > ...and take the reference to Perlman83 out.  It is enough for the > specification to be done once; rfc6550 already took care of it. > > [nit] s/OrigSeqNo/Orig SeqNo > Done and done. > > ... > 632  The transmission of RREQ-DIO obeys the Trickle timer. If the > 633  duration specified by the "L" bit has elapsed, the OrigNode MUST > 634  leave the DODAG and stop sending RREQ-DIOs in the related > 635  RPLInstance. > > [minor] "The transmission of RREQ-DIO obeys the Trickle timer."   A > reference would be nice. Fixed. > > > 6376.2. Receiving and Forwarding RREQ messages > > 6396.2.1. General Processing > > 641  Upon receiving a RREQ-DIO, a router which does not belong to the > 642  RREQ-instance goes through the following steps: > > [nit] s/RREQ-instance/RREQ-Instance/g Done. > > [major] What if you do belong to the instance?  I'm assuming that RREQ > can be sent once the DODAG is built...or would what require a > difference RPLInstance? A new RREQ would require a new RPLInstance, I believe. > > 644  Step 1: > > 646     If the 'S' bit in the received RREQ-DIO is set to 1, the router > 647     MUST check the two directions of the link by which the RREQ-DIO is > 648     received.  In case that the downward (i.e. towards the TargNode) > 649     direction of the link can't fulfill the requirements, the link > 650     can't be used symmetrically, thus the 'S' bit of the RREQ-DIO to > 651     be sent out MUST be set as 0.  If the 'S' bit in the received > 652     RREQ-DIO is set to 0, the router only checks into the upward > 653     direction (towards the OrigNode) of the link. > > [major] "the router MUST check the two directions of the link"  How is > the link checked? The router must verify that each direction of the link satisfies the Objective Function.  The verification method depends on the Objective Function and is out of scope for this document. > > [major] "If the 'S' bit...is set to 0..."  The action for when the S > bit is set to 1 was defined using MUST...should this action also > include Normative Language? Done. > > 655     If the upward direction of the link can fulfill the requirements > 656     indicated in the constraint option, and the router's rank would > 657     not exceed the MaxRank limit, the router joins the DODAG of the > 658     RREQ-Instance.  The router that transmitted the received RREQ-DIO > 659     is selected as the preferred parent.  Later, other RREQ-DIO > 660     messages might be received.  How to maintain the parent set, > 661     select the preferred parent, and update the router's rank obeys > 662     the core RPL and the OFs defined in ROLL WG.  In case that the > 663     constraint or the MaxRank limit is not fulfilled, the router MUST > 664     discard the received RREQ-DIO and MUST NOT join the DODAG. > > [major] What is the "constraint option"? Using Objective Function language instead resolves this comment. > > [minor] "How to maintain the parent set, select the preferred parent, > and update the router's rank obeys the core RPL and the OFs defined in > ROLL WG."  If there's no change, then I think this sentence is not > needed.  If you want to keep it, then please reference specific > documents and don't just point to the WG (in fact, don't point to the > WG because the persistent references are documents). Done. =========================================================================== The remainder of the comments will be posted shortly. Regards, Charlie P. --------------6CDA6795BCDEEBCA33260534 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello folks,

Today we have submitted a revised version 8 for our draft-ietf-roll-aodv-rpl.  Here is part 1 showing some resolutions for comments made by our AD for the improvement of draft-ietf-roll-aodv-rpl-07.

In addition we have done the following:
  • rewrite section 8
  • rewrite RFC 6997 text for AODV-RPL security behaviors
  • provide citations for work in the Appendix

In a few minutes I will also send email with a summary, in a more compact format, of the changes that we have made to the draft.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: Fwd: Re: AD Review of draft-ietf-roll-aodv-rpl-07
Date: Wed, 29 Apr 2020 12:35:32 -0700
From: Charlie Perkins <charles.perkins@earthlink.net>
To: Alvaro Retana <aretana.ietf@gmail.com>
CC: S.V.R Anand <anand@ece.iisc.ernet.in>, Remy Liubing <remy.liubing@huawei.com>, Satish Anamalamudi <satishnaidu80@gmail.com>


Hello Alvaro,

We are preparing a new revision of draft-ietf-roll-aodv-rpl to be released in a day or so.  Here are some resolutions for most of your comments.  The other points have also been addressed as you will see in the new revision.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: Re: AD Review of draft-ietf-roll-aodv-rpl-07
Date: Sun, 29 Mar 2020 12:51:52 -0700
From: Charlie Perkins <charles.perkins@earthlink.net>
To: Satish Anamalamudi <satishnaidu80@gmail.com>, S.V.R Anand <anand@ece.iisc.ernet.in>, Remy Liubing <remy.liubing@huawei.com>

...

Regards,
Charlie P.



On 8/1/2019 7:54 AM, Alvaro Retana wrote:
Dear authors:

I just finished reading this document.  I am excited about the new functionality, but I have several significant issues/questions about the document, and a lot of comments (in-line below).

(1) What is AODV-RPL?

Reading the document, my impression of AODV-RPL varies between an enhancement to RPL for Reactive Route Discovery (*maybe* in addition to the usual proactive routing), to ships-in-the-night reactive-only protocol that uses some of the RPL concepts (but not exactly sure which ones).  The different MOP indicates that it is different from "base" RPL (rfc6550), but it is not clear what the assumptions are...and which parts are "inherited" from the "base" and which ones are not used.

Another way to ask the same question is: What is the relationship of AODV-RPL to RPL?  What mechanisms are not applicable with the new MOP?  Is it expected that an instance of RPL will also be running in the network?

Please be clear early in the document.  To quote Charlie: "AODV-RPL is a variation on RPL" [1].  What remains, what changes, etc..

I think the new Introduction goes a long way towards resolving this comment.




(2) Document Status (for the Chairs/Shepherd)

I didn't find a specific discussion in the archive about the status of this document.  Did one take place?  At this point I am mostly curious given the similarities with rfc6997 (Experimental) and the fact that "Future Work" is discussed -- not typical in a Standards Track document.  IOW, why is this document intended to be a Proposed Standard and not Experimental?

In my understanding it is intended to be a Proposed Standard so that implementors have a Standard available (i.e., do not have to rely on Experimental protocols).




(3) Replacing rfc6997??

This document uses some of the features from rfc6997 (see some comments about that in-line), which is fine.  The Introduction falls just short of saying that this work replaces rfc6997.  Should it be considered a replacement?  I ask mostly in the context of rfc7733 (RPL in Home and Building) which mandates (MUST) the use of rfc6997.  Should rfc7733 be Updated?  [I'm just asking the question for it to be considered...I am not sure of deployments which conform to rfc7733 or rfc6997...or the impact this would have.]

My preference would be for AODV-RPL to replace RFC 6997.  We were requested to include features from RFC 6997, with the understanding that doing so would eliminate the value of implementing RFC 6997.




(4) Link checks

The operation of AODV-RPL depend on link checks (§6.2.1/§6.4) to determine symmetry and whether it can "fulfill the requirements".  But these checks are not explained or defined anywhere (are they?) beyond an *example* in the Appendix.  I think defining the checks is a critical part of the specification of the mechanism...specially for a Standards Track protocol.
I think this is all about evaluating the Objective Function for the links.  We just have to specify that the router evaluates the Objective Function to see if the link satisfies the Function.
.................

...
14     Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)

[minor] This is not the clearest title I've ever seen.   Suggestion: Reactive Route Discovery using RPL (AODV-RPL)    ...or something like that.

15                      draft-ietf-roll-aodv-rpl-07

17 Abstract

19   Route discovery for symmetric and asymmetric Point-to-Point (P2P)
20   traffic flows is a desirable feature in Low power and Lossy Networks
21   (LLNs).  For that purpose, this document specifies a reactive P2P
22   route discovery mechanism for both hop-by-hop routing and source
23   routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
24   protocol.  Paired Instances are used to construct directional paths,
25   in case some of the links between source and target node are
26   asymmetric.

[minor] s/(AODV) based RPL protocol/(AODV) based RPL protocol (AODV-RPL)

How about:

 AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-
                    Power and Lossy Networks




...
100 1.  Introduction

[general comment] Avoid mentioning the "negative" of other proposals and focus on why this work is needed.  IOW, the justification should not be "because others can't do it".


How about replacing the first three paragraphs with the following:

   AODV-RPL specifies P2P route discovery, utilizing RPL [RFC6550] (Routing
   Protocol for Low-Power and Lossy Networks) with a new MOP (Mode Of
   Operation).  Routes are discovered using two multicast messages
   to discover routes that may traverse asymmetric links.  This promotes
   higher route diversity, often reducing interference near root nodes.
   More importantly, AODV-RPL can enable applications to run that might
   otherwise fail, in networks containing suitable asymmetric routes but
   no symmetric routes as would be required by RPL or P2P-RPL [RFC6997].
   As an extra benefit, AODV-RPL eliminates the need for address vector
   overhead in hop-by-hop mode, significantly reducing the control
   packet size.



[nit] Some of the paragraphs throughout the document are very long and could be split to better convey the ideas.


If you have particular examples in mind please let us know.  I'll take a look and see what sticks out.



102   RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy
103   Networks)) is a IPv6 distance vector routing protocol designed to
104   support multiple traffic flows through a root-based Destination-
105   Oriented Directed Acyclic Graph (DODAG).  Typically, a router does
106   not have routing information for most other routers.  Consequently,
107   for traffic between routers within the DODAG (i.e., Point-to-Point
108   (P2P) traffic) data packets either have to traverse the root in non-
109   storing mode, or traverse a common ancestor in storing mode.  Such
110   P2P traffic is thereby likely to traverse longer routes and may
111   suffer severe congestion near the DAG root (for more information see
112   [RFC6997], [RFC6998]).

[nit] s/RPL[RFC6550]/RPL [RFC6550]


Done, subject to the above.



[minor] s/Routing Protocol for LLNs (Low-Power and Lossy Networks)/Routing Protocol for Low-Power and Lossy Networks    That's the name of the protocol.

Done.


[nit] s/is a IPv6/is an IPv6
Fixed.


[minor] "Such P2P traffic is thereby likely to traverse longer routes and may suffer severe congestion near the DAG root (for more information see [RFC6997], [RFC6998])."  I see that those other RFCs also make the statement that congestion is possible, and even longer routes...but I don't see more information there.  Did I miss it?  If not, then I don't see the value of those references at this point.

114   To discover better paths for P2P traffic flows in RPL, P2P-RPL
115   [RFC6997] specifies a temporary DODAG where the source acts as a
116   temporary root.  The source initiates DIOs encapsulating the P2P
117   Route Discovery option (P2P-RDO) with an address vector for both hop-
118   by-hop mode (H=1) and source routing mode (H=0).  Subsequently, each
119   intermediate router adds its IP address and multicasts the P2P mode
120   DIOs, until the message reaches the Target Node, which then sends the
121   "Discovery Reply" object.  P2P-RPL is efficient for source routing,
122   but much less efficient for hop-by-hop routing due to the extra
123   address vector overhead.  However, for symmetric links, when the P2P
124   mode DIO message is being multicast from the source hop-by-hop,
125   receiving nodes can infer a next hop towards the source.  When the
126   Target Node subsequently replies to the source along the established
127   forward route, receiving nodes determine the next hop towards the
128   Target Node.  For hop-by-hop routes (H=1) over symmetric links, this
129   would allow efficient use of routing tables for P2P-RDO messages
130   instead of the "Address Vector".

[minor] Expand DIO on first use.

Done.  Maybe twice :-)



[minor] The description above of P2P-RPL seems to include too much (unnecessary for this document) detail.  It also seems to propose enhancements (in the last couple of sentences).  Consider simplifying to something like this:

   To discover better paths for P2P traffic flows in RPL, P2P-RPL
   [RFC6997] specifies a temporary DODAG where the source acts as a
   temporary root.  P2P-RPL is efficient for source routing,
   but can be much less efficient for hop-by-hop routing due to the
   extra address vector overhead.

Done, subject to preference for the shorter Introduction introduction.




132   RPL and P2P-RPL both specify the use of a single DODAG in networks of
133   symmetric links, where the two directions of a link MUST both satisfy
134   the constraints of the objective function.  This disallows the use of
135   asymmetric links which are qualified in one direction.  But,
136   application-specific routing requirements as defined in IETF ROLL
137   Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be
138   satisfied by routing paths using bidirectional asymmetric links.  For
139   this purpose, [I-D.thubert-roll-asymlink] described bidirectional
140   asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the
141   DAG root (DODAGID) is common for two Instances.  This can satisfy
142   application-specific routing requirements for bidirectional
143   asymmetric links in core RPL [RFC6550].  Using P2P-RPL twice with
144   Paired DODAGs, on the other hand, requires two roots: one for the
145   source and another for the target node due to temporary DODAG
146   formation.  For networks composed of bidirectional asymmetric links
147   (see Section 5), AODV-RPL specifies P2P route discovery, utilizing
148   RPL with a new MoP.  AODV-RPL makes use of two multicast messages to
149   discover possibly asymmetric routes.  This provides higher route
150   diversity and can find suitable routes that might otherwise go
151   undetected by RPL.  AODV-RPL eliminates the need for address vector
152   overhead in hop-by-hop mode.  This significantly reduces the control
153   packet size, which is important for Constrained LLN networks.  Both
154   discovered routes (upward and downward) meet the application specific
155   metrics and constraints that are defined in the Objective Function
156   for each Instance [RFC6552].  On the other hand, the point-to-point
157   nature of routes discovered by AODV-RPL can reduce interference near
158   the root nodes and also provide routes with fewer hops, likely
159   improving performance in the network.

[major] "RPL and P2P-RPL both specify the use of a single DODAG in networks of symmetric links, where the two directions of a link MUST both satisfy the constraints of the objective function."  s/MUST/must   Because you are referring to RPL/P2P-RPL, the MUST is not Normative.

[minor] s/as defined in IETF ROLL Working Group [RFC5548]/as defined in [RFC5548]

[minor] s/application-specific routing requirements...may be satisfied by routing paths using bidirectional asymmetric links./application-specific routing requirements may also be satisfied by routing paths using bidirectional asymmetric links.     I found just one mention of anything related to asymmetry (in rfc5673)...so I think adding "also" is important.

Fixed.



[minor] "For this purpose, [I-D.thubert-roll-asymlink] described bidirectional asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the DAG root (DODAGID) is common for two Instances.  This can satisfy application-specific routing requirements for bidirectional asymmetric links in core RPL [RFC6550]."    I think that mention to this draft is unnecessary and may be confusing to readers: the work seems to have been abandoned, and if it satisfies the requirements, then why do we need something else?  ;-)

[minor] I would also take out this sentence: "Using P2P-RPL twice..."
Done.

[minor] Expand MoP on first use.  BTW, rfc6550 uses MOP (not MoP), please be consistent.
Done.

[minor] "Both discovered routes (upward and downward) meet the application specific metrics and constraints that are defined in the Objective Function for each Instance [RFC6552]."   I didn't find any talk of application specific metrics in rfc6552.

I think the citation was intended for "Objective Function", not Instance.  And anyway the reference should probably be to RFC 6550.




...
170 2.  Terminology

172   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
173   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
174   "OPTIONAL" in this document are to be interpreted as described in
175   [RFC2119], [RFC8174].  This document uses the following terms:

[major] Please use the rfc8174 template without modifications.

Done.




...
264 3.  Overview of AODV-RPL

[minor] It would be very nice if this overview had forward references to where the behavior is specified.

266   With AODV-RPL, routes from OrigNode to TargNode within the LLN
267   network are established "on-demand".  In other words, the route
268   discovery mechanism in AODV-RPL is invoked reactively when OrigNode
269   has data for delivery to the TargNode but existing routes do not
270   satisfy the application's requirements.  The routes discovered by
271   AODV-RPL are not constrained to traverse a common ancestor.  Unlike
272   RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric
273   communication paths in networks with bidirectional asymmetric links.
274   For this purpose, AODV-RPL enables discovery of two routes: namely,
275   one from OrigNode to TargNode, and another from TargNode to OrigNode.
276   When possible, AODV-RPL also enables symmetric route discovery along
277   Paired DODAGs (see Section 5).

[major] I get the impression that this document is an extension to RPL, to be used when the existing routes don't meet specific requirements...at this point the reactive part would kick in.  Is that a fair characterization?

Not really.  AODV-RPL uses some of the base RPL specification but does not require an instance of RPL to run.  I put in some additional clarifying text about this.  I think it also resolves the next comment.



The document jumps into talking about the extension, but it says nothing about how the base RPL is used with it...or even if it is.  Please spend a paragraph explaining that relationship.

See the last point of discussion.



279   In AODV-RPL, routes are discovered by first forming a temporary DAG
280   rooted at the OrigNode.  Paired DODAGs (Instances) are constructed
281   according to the AODV-RPL Mode of Operation (MoP) during route
282   formation between the OrigNode and TargNode.  The RREQ-Instance is
283   formed by route control messages from OrigNode to TargNode whereas
284   the RREP-Instance is formed by route control messages from TargNode
285   to OrigNode.  Intermediate routers join the Paired DODAGs based on
286   the rank as calculated from the DIO message.  Henceforth in this
287   document, the RREQ-DIO message means the AODV-RPL mode DIO message
288   from OrigNode to TargNode, containing the RREQ option (see
289   Section 4.1).  Similarly, the RREP-DIO message means the AODV-RPL
290   mode DIO message from TargNode to OrigNode, containing the RREP
291   option (see Section 4.2).  The route discovered in the RREQ-Instance
292   is used for transmitting data from TargNode to OrigNode, and the
293   route discovered in RREP-Instance is used for transmitting data from
294   OrigNode to TargNode.

[nit] s/rank/Rank/g   To be consistent with how rfc6550 uses the term.

Fixed.  I hope that all instances of "rank" are O.K. to be capitalized.



296 4.  AODV-RPL DIO Options

298 4.1.  AODV-RPL DIO RREQ Option

300   OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
301   message.  A RREQ-DIO message MUST carry exactly one RREQ option.

[major] What should a receiver do if more than one RREQ options are received?

I specified that it SHOULD be dropped.  I don't think this is too harsh, even though other solutions are possible.



303      0                   1                   2                   3
304      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
305     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306     |     Type      | Option Length |S|H|X| Compr | L |   MaxRank   |
307     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308     |  Orig SeqNo   |                                               |
309     +-+-+-+-+-+-+-+-+                                               |
310     |                                                               |
311     |                                                               |
312     |           Address Vector (Optional, Variable Length)          |
313     |                                                               |
314     |                                                               |
315     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

317             Figure 1: DIO RREQ option format for AODV-RPL MoP

319   OrigNode supplies the following information in the RREQ option:

321   Type
322      The type assigned to the RREQ option (see Section 9.2).

[major] s/Type/Option Type/g   That is the name in rfc6550.

Fixed.



[minor] Use TBDx so that it matches the IANA Considerations section.  The same applies to other places where TBDx can be used.

Fixed.



...
348   L

350      2-bit unsigned integer determining the duration that a node is
351      able to belong to the temporary DAG in RREQ-Instance, including
352      the OrigNode and the TargNode.  Once the time is reached, a node
353      MUST leave the DAG and stop sending or receiving any more DIOs for
354      the temporary DODAG.  The definition for the "L" bit is similar to
355      that found in [RFC6997], except that the values are adjusted to
356      enable arbitrarily long route lifetime.

[major] "definition for the "L" bit is similar to that found in [RFC6997], except that..."   I think that this statement may be confusing to readers...remove it.

Done.



358      *  0x00: No time limit imposed.
359      *  0x01: 16 seconds
360      *  0x02: 64 seconds
361      *  0x03: 256 seconds

363      L is independent from the route lifetime, which is defined in the
364      DODAG configuration option.  The route entries in hop-by-hop
365      routing and states of source routing can still be maintained even
366      after the DAG expires.

[??] I don't understand what the last sentence is trying to say.  It sounds as if the information learned through the DAG can still be used after the DAG expires...up until the route lifetime expires...is that it?  Please clarify.

How about this:

                     The route entries in hop-by-hop routing
    and states of source routing can still be maintained
    even after the node no longer maintains DAG connectivity or
    messaging.



...
373   Orig SeqNo
374      Sequence Number of OrigNode, defined similarly as in AODV
375      [RFC3561].

[major] "similarly as in AODV"  Similarly, or the same??  Note that this reference could require rfc3561 to be a Normative Reference.

Fixed, by deleting the reference.  Would it be useful to make a reference to AODV's sequence number operation in the Introduction?



I found this text in §6.1, which defines this field.  Which one is correct?  Suggestion: point to §6.1.

   Each node maintains a sequence number, which rolls over like a
   lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for
   detailed operation.  When the OrigNode initiates a route discovery
   process, it MUST increase its own sequence number to avoid conflicts
   with previously established routes.  The sequence number is carried
   in the OrigSeqNo field of the RREQ option.

Fixed.




...
382   A node MUST NOT join a RREQ instance if its own rank would equal to
383   or higher than MaxRank.  Targnode can join the RREQ instance at a
384   rank whose integer portion is equal to the MaxRank.  A router MUST
385   discard a received RREQ if the integer part of the advertised rank
386   equals or exceeds the MaxRank limit.  This definition of MaxRank is
387   the same as that found in [RFC6997].

[minor] s/own rank would equal to/own rank would be equal to

[nit] s/Targnode/TargNode

[minor] The second sentence sounds like it contradicts the first one (where it says that "A node MUST NOT join..."); I think that inverting the order would help:

   TargNode can join the RREQ instance at a rank whose integer portion is
   equal to the MaxRank.  Other nodes MUST NOT join a RREQ instance if its
   own rank is equal to or higher than MaxRank.

Done, done, and done.



[major] "This definition of MaxRank is the same as that found in [RFC6997]."  True, for the most part: the context of the definition is different.  Because the definition are not exactly the same, and MaxRank is defined in this document, please take the sentence out.  I don't think it adds anything significant.

Done.




389 4.2.  AODV-RPL DIO RREP Option

391   TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
392   message.  A RREP-DIO message MUST carry exactly one RREP option.
393   TargNode supplies the following information in the RREP option:

[major] What should the receiver do if more than one RREP option is received?

How about:

          A RREP-DIO message MUST carry exactly one RREP option,
    otherwise the message SHOULD be dropped.



...
441   Shift
442      6-bit unsigned integer.  This field is used to recover the
443      original InstanceID (see Section 6.3.3); 0 indicates that the
444      original InstanceID is used.

[major] s/InstanceID/RPLInstanceID/g

Done.



446   Rsv
447      MUST be initialized to zero and ignored upon reception.

[major] Do you expect these bits to be assigned by IANA in the future?

No, but a future specification could modify the operation.  Do we need to say that?




...
456 4.3.  AODV-RPL DIO Target Option

458   The AODV-RPL Target (ART) Option is based on the Target Option in
459   core RPL [RFC6550].  The Flags field is replaced by the Destination
460   Sequence Number of the TargNode and the Prefix Length field is
461   reduced to 7 bits so that the value is limited to be no greater than
462   127.

[minor] What is the name of this option: "AODV-RPL DIO Target Option" or "AODV-RPL Target Option"?  Please be consistent.

Hopefully fixed.



[??] "the Prefix Length field is reduced to 7 bits so that the value is limited to be no greater than 127."  Why?  Is there an advantage?  Seriously, I'm curious.

Well, I don't think there are any prefixes longer than 127 bits.



464   A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO
465   message MUST carry exactly one ART Option.

[major] What should a node do if more than one ART Option is received in a RREP-DIO message?

How about:

    A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO
    message MUST carry exactly one ART Option. Otherwise, the message
    SHOULD be dropped.


467   OrigNode can include multiple TargNode addresses via multiple AODV-
468   RPL Target Options in the RREQ-DIO, for routes that share the same
469   constraints.  This reduces the cost to building only one DODAG.
470   Furthermore, a single Target Option can be used for different
471   TargNode addresses if they share the same prefix; in that case the
472   use of the destination sequence number is not defined in this
473   document.

[major] To be clear, what are the "constraints"?  Where are they defined/signaled?  Are you talking about the contents of the RREQ Option (S, H, MaxRank...anything else?)?  If so, please point that out explicitly; "constraints" are mentioned in different places, but I couldn't find an explicit definition.

I changed instances of "fulfill the constraint" to be "satisfy the Objective Function".  I think this resolves the issue.



[major] "...in that case the use of the destination sequence number is not defined in this document."   Then that means that this last feature is not supported...right?  If that's true, then please don't mention it.

Fixed.




...
511   Target Prefix / Address
512      (variable-length field) An IPv6 destination address or prefix.
513      The Prefix Length field contains the number of valid leading bits
514      in the prefix.  The bits in the Target Prefix / Address field
515      after the prefix length (if any) MUST be set to zero on
516      transmission and MUST be ignored on receipt.

[major] "The bits in the Target Prefix / Address field after the prefix length (if any)..."   I can see how this "is ok" because the receiver knows of these trailing bits from the Option Length...*but*, why even allow it?  Why would the Target Prefix / Address not simply have a length = Prefix Length?

BTW, I know that rfc6550 has the same definition.  That doesn't make it right.  Every extra bit has a cost...prefixes are elided, and here extra bits are allowed.

The only extra bits that are specified are required in order that the option has an integer number of octets.  We do allow prefixes that are not an integer number of octets and so some bits have to be specified as zero.




518 5.  Symmetric and Asymmetric Routes

520   In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode,
521   R is an intermediate router, and T is the TargNode.  If the RREQ-DIO
522   arrives over an interface that is known to be symmetric, and the 'S'
523   bit is set to 1, then it remains as 1, as illustrated in Figure 4.
524   If an intermediate router sends out RREQ-DIO with the 'S' bit set to
525   1, then all the one-hop links on the route from the OrigNode O to
526   this router meet the requirements of route discovery, and the route
527   can be used symmetrically.

[nit] A couple of places use "S bit", "'S' bit" is used above (and in most of the document)...please be consistent.   Recommendation: S bit or S-bit.   [BTW, please apply the same style to the other bits.]

Fixed.




...
552   Upon receiving a RREQ-DIO with the 'S' bit set to 1, a node
553   determines whether this one-hop link can be used symmetrically, i.e.,
554   both the two directions meet the requirements of data transmission.
555   If the RREQ-DIO arrives over an interface that is not known to be
556   symmetric, or is known to be asymmetric, the 'S' bit is set to 0.  If
557   the 'S' bit arrives already set to be '0', it is set to be '0' on
558   retransmission (Figure 5).  Therefore, for asymmetric route, there is
559   at least one hop which doesn't fulfill the constraints in the two
560   directions.  Based on the 'S' bit received in RREQ-DIO, the TargNode
561   T determines whether or not the route is symmetric before
562   transmitting the RREP-DIO message upstream towards the OrigNode O.

[nit] s/for asymmetric route/for an asymmetric route

Fixed.



564   The criteria used to determine whether or not each link is symmetric
565   is beyond the scope of the document, and may be implementation-
566   specific.  For instance, intermediate routers MAY use local
567   information (e.g., bit rate, bandwidth, number of cells used in
568   6tisch), a priori knowledge (e.g. link quality according to previous
569   communication) or use averaging techniques as appropriate to the
570   application.

[major] s/MAY/may   This may is not Normative because there is no specific action (just examples).

Fixed.



...
602 6.1.  Route Request Generation
...
614   Each node maintains a sequence number, which rolls over like a
615   lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for
616   detailed operation.  When the OrigNode initiates a route discovery
617   process, it MUST increase its own sequence number to avoid conflicts
618   with previously established routes.  The sequence number is carried
619   in the OrigSeqNo field of the RREQ option.

[minor] s/Each node maintains a sequence number...detailed operation./Each node maintains a sequence number; the operation is specified in section 7.2 of [RFC6550].

...and take the reference to Perlman83 out.  It is enough for the specification to be done once; rfc6550 already took care of it.

[nit] s/OrigSeqNo/Orig SeqNo

Done and done.



...
632   The transmission of RREQ-DIO obeys the Trickle timer.  If the
633   duration specified by the "L" bit has elapsed, the OrigNode MUST
634   leave the DODAG and stop sending RREQ-DIOs in the related
635   RPLInstance.

[minor] "The transmission of RREQ-DIO obeys the Trickle timer."   A reference would be nice.

Fixed.




637 6.2.  Receiving and Forwarding RREQ messages

639 6.2.1.  General Processing

641   Upon receiving a RREQ-DIO, a router which does not belong to the
642   RREQ-instance goes through the following steps:

[nit] s/RREQ-instance/RREQ-Instance/g

Done.



[major] What if you do belong to the instance?  I'm assuming that RREQ can be sent once the DODAG is built...or would what require a difference RPLInstance?

A new RREQ would require a new RPLInstance, I believe.



644   Step 1:

646      If the 'S' bit in the received RREQ-DIO is set to 1, the router
647      MUST check the two directions of the link by which the RREQ-DIO is
648      received.  In case that the downward (i.e. towards the TargNode)
649      direction of the link can't fulfill the requirements, the link
650      can't be used symmetrically, thus the 'S' bit of the RREQ-DIO to
651      be sent out MUST be set as 0.  If the 'S' bit in the received
652      RREQ-DIO is set to 0, the router only checks into the upward
653      direction (towards the OrigNode) of the link.

[major] "the router MUST check the two directions of the link"  How is the link checked?

The router must verify that each direction of the link satisfies the Objective Function.  The verification method depends on the Objective Function and is out of scope for this document.



[major] "If the 'S' bit...is set to 0..."  The action for when the S bit is set to 1 was defined using MUST...should this action also include Normative Language?

Done.



655      If the upward direction of the link can fulfill the requirements
656      indicated in the constraint option, and the router's rank would
657      not exceed the MaxRank limit, the router joins the DODAG of the
658      RREQ-Instance.  The router that transmitted the received RREQ-DIO
659      is selected as the preferred parent.  Later, other RREQ-DIO
660      messages might be received.  How to maintain the parent set,
661      select the preferred parent, and update the router's rank obeys
662      the core RPL and the OFs defined in ROLL WG.  In case that the
663      constraint or the MaxRank limit is not fulfilled, the router MUST
664      discard the received RREQ-DIO and MUST NOT join the DODAG.

[major] What is the "constraint option"?

Using Objective Function language instead resolves this comment.



[minor] "How to maintain the parent set, select the preferred parent, and update the router's rank obeys the core RPL and the OFs defined in ROLL WG."  If there's no change, then I think this sentence is not needed.  If you want to keep it, then please reference specific documents and don't just point to the WG (in fact, don't point to the WG because the persistent references are documents).

Done.

===========================================================================

The remainder of the comments will be posted shortly.


Regards,
Charlie P.


--------------6CDA6795BCDEEBCA33260534-- From nobody Thu May 7 12:52:29 2020 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 93E523A0CF3; Thu, 7 May 2020 12:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 QapCztw_5wTS; Thu, 7 May 2020 12:52:23 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.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 2B0943A0CE7; Thu, 7 May 2020 12:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1588881143; bh=qbTXKO2luPxYnVLBh5WpJtXsBHdOFCbhAsho oj6Xmxc=; h=Received:To:Cc:From:Subject:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Language:X-ELNK-Trace:X-Originating-IP; b=U/b3+HEDe2IGoXrh AZ+aMqMPuMbxBxS+zoagx80mOwODV7gG5Z370w86k/rrACudUG/q6aALEPGY4VP0MNy KGZiQ+dvQE+MT1FfZwQuaaLJ6tHkB7dx6RoKZejCfNkBEfHoV7+p/FTXj57XhmU8PaG emtyBvYmYibZNoe4cLF++9S4S0MMKwya+3heYdu6uFHScQh1LeGXxxhm1tf3vg9BzDD jD9NxNpyKc3ucIiAYBQihe7EVBwp9wPjSemJnlV+AwnTMeiJYHenF3c9aeT0lP404oH rI7hhl96D2LUuR0iTHrMWiY7+/czyzBA/89LwZSkfj6UuZ9fENHFLINGrg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=jBil1tsDNIy+90xgZrIUKK4NSrb3DHIYy1vX+M74JI0Liu83pllEEvaGv0ai2wJdju1AmtpEi3M7GHdZJVf8nACdJeZCRJfDOGKPVliSb2dlkRmjD5L9hqWK4wZ6pmb0rqDg1DYjRwaOwQxakEXHx+NRdHSZ2MY7vH7Ij+RLm87Hm1/Pw1cQdF2sQ3IsJemQZSF94+y0jDHq6xFddN464hF0QGH4atvsybLZW6SpLBrEEDHR9nofUw0Gbfb7FHd6p2lPAXNvVKAvNv+t8/g6UdedRwDyMnAXEls9rdDpsBL+NMLed1AWGly0itkdH39vCQqPOx4fyPIYcb1ONwkKzg==; h=Received:To:Cc:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1jWmZC-0006lx-9d; Thu, 07 May 2020 15:52:22 -0400 To: Routing Over Low power and Lossy networks Cc: "draft-ietf-roll-aodv-rpl@ietf.org" From: Charlie Perkins Message-ID: <81fbfde3-df64-311e-392d-7c091a06fd80@earthlink.net> Date: Thu, 7 May 2020 12:52:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95c07a736cb524653e68e9189f9bf973d8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [Roll] Part 2: comment resolutions for AD Review of draft-ietf-roll-aodv-rpl-07 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, 07 May 2020 19:52:27 -0000  Hello folks, Today we have submitted a revised version 8 for our draft-ietf-roll-aodv-rpl.  Here are the rest of some resolutions for comments made by our AD for the improvement of draft-ietf-roll-aodv-rpl-07. Regards, Charlie P. > ... > 672      Step 3: > > 674         If the 'H' bit is set to 1, then the router (TargNode or > 675         intermediate) MUST build the upward route entry accordingly.  The > 676         route entry MUST include at least the following items: Source > 677         Address, InstanceID, Destination Address, Next Hop, Lifetime, and > 678         Sequence Number.  The Destination Address and the InstanceID can > 679         be respectively learned from the DODAGID and the RPLInstanceID of > 680         the RREQ-DIO, and the Source Address is copied from the ART > 681         Option.  The next hop is the preferred parent.  The lifetime is > 682         set according to DODAG configuration and can be extended when the > 683         route is actually used.  The sequence number represents the > 684         freshness of the route entry, and it is copied from the Orig SeqNo > 685         field of the RREQ option.  A route entry with same source and > 686         destination address, same InstanceID, but stale sequence number, > 687         SHOULD be deleted. > > [major] "...MUST build the upward route entry accordingly."  I was going to ask what does "accordingly" mean, but the next sentence indicates what it has to include.  Instead of having two sentences trying to specify the same thing, please collapse them into one. Done. > > [minor] This route is to OrigNode, correct?  Please say so.  I know that it has been mentioned that the RREQ-Instance is used for that -- remind the reader. Done. > > [major] "...the Source Address is copied from the ART Option."   What is the "Source Address"?  I ask because I assumed that it is the address used by the local router to send data to the OrigNode, but the only address in the ART Option is the "Target Prefix".  What am I missing? I used your text as follows:                   ...the Source Address is the address used by the local router to         send data to the OrigNode > > [nit] Please be consistent in how names are used.  For example, the paragraph above uses both "Next Hop" and "next hop" to refer to the same thing. Fixed. > > [minor] "The lifetime is set according to DODAG configuration and can be extended when the route is actually used."  I think that this is a little confusing, because you seem to be talking about route lifetime and not the L (which I interpreted as lifetime too) value in the RREQ Option, right?  Please be specific. Fixed. > > [nit] s/entry with same source/entry with the same source Fixed. > > [major] "A route entry with same source and destination address, same InstanceID, but stale sequence number, SHOULD be deleted."  When would it be ok to not delete the entry?  IOW, why is that not a MUST? Changed to MUST. > > 689         If the 'H' bit is set to 0, an intermediate router MUST include > 690         the address of the interface receiving the RREQ-DIO into the > 691         address vector. > > [major] Step 3 (at least the first paragraph) seems to be about building a route entry.  What is different if the H bit is set to 0?  How is the route entry built? I think that if H=0 there is no route entry, since source routing is to be used. > > [minor] This last paragraph talks about forwarding the RREQ, so perhaps it fits better in the next step. Done, even though Step 4 now discusses more than just forwarding the RREQ. > > 693      Step 4: > > 695         An intermediate router transmits a RREQ-DIO via link-local > 696         multicast.  TargNode prepares a RREP-DIO. > > [minor] "TargNode prepares a RREP-DIO."  Please add a forward reference to §6.3. Done. > > 698    6.2.2.  Additional Processing for Multiple Targets > > 700      If the OrigNode tries to reach multiple TargNodes in a single RREQ- > 701      instance, one of the TargNodes can be an intermediate router to the > 702      others, therefore it SHOULD continue sending RREQ-DIO to reach other > 703      targets.  In this case, before rebroadcasting the RREQ-DIO, a > 704      TargNode MUST delete the Target Option encapsulating its own address, > 705      so that downstream routers with higher ranks do not try to create a > 706      route to this TargetNode. > > [major] "...one of the TargNodes can be an intermediate router to the others, therefore it SHOULD continue sending RREQ-DIO to reach other targets."  When would a TargNode choose not to forward the RREQ?  IOW, why is that not a MUST? Changed to MUST. > > 708      An intermediate router could receive several RREQ-DIOs from routers > 709      with lower ranks in the same RREQ-instance but have different lists > 710      of Target Options.  When rebroadcasting the RREQ-DIO, the > 711      intersection of these lists SHOULD be included.  For example, suppose > 712      two RREQ-DIOs are received with the same RPLInstance and OrigNode. > 713      Suppose further that the first RREQ has (T1, T2) as the targets, and > 714      the second one has (T2, T4) as targets.  Then only T2 needs to be > 715      included in the generated RREQ-DIO.  If the intersection is empty, it > 716      means that all the targets have been reached, and the router SHOULD > 717      NOT send out any RREQ-DIO.  Any RREQ-DIO message with different ART > 718      Options coming from a router with higher rank is ignored. > > [major] "...the intersection of these lists SHOULD be included."  When would a node not include the intersection?  IOW, why is this not a MUST? Changed to MUST. > > [major] "If the intersection is empty...the router SHOULD NOT send out any RREQ-DIO."  When would it be ok to sent the RREQ out? If there are no targets, then it seems like you would never want to.  IOW, why is that not a MUST NOT? Changed to MUST NOT. > > [minor] I'm not sure about the intersection logic above...but maybe I'm missing something.  The example seems to imply that every RREQ should include all outstanding targets (?)...so that comparing the first one (T1, T2) with the second (T2, T4), implies that T1 has been found...is that correct?  If so, then it looks like T4 is still a valid target, but the intersection wouldn't include it.  What am I missing? It is assumed that OrigNode was the eventual origination point for both the example incoming RREQs.  So the inference is that one path discovered a route for T4, and the other path discovered a route for T1, and neither path discovered a route for T2.  And, one might speculate, both paths discovered a route for T3 which isn't mentioned in the example. > > [minor] Related:  The specification above only applies to the period of time between receiving the first RREQ and the initial rebroadcast, right?  IOW, if a RREQ is received and rebroadcast....and then a second RREQ is received (with a different list of targets), then the rebroadcast should not include just the intersection, right? That is correct.  The following text was added to clarify this point:                                                           For the         purposes of determining the intersection with previous incoming         RREQ-DIOs, the intermediate router maintains a record of the         targets that have been requested associated with the RREQ-Instance. > > 720    6.3.  Generating Route Reply (RREP) at TargNode > > 722    6.3.1.  RREP-DIO for Symmetric route > > 724      If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, there is > 725      a symmetric route along which both directions can fulfill the > 726      requirements.  Other RREQ-DIOs might later provide asymmetric upward > 727      routes (i.e.  S=0).  Selection between a qualified symmetric route > 728      and an asymmetric route that might have better performance is > 729      implementation-specific and out of scope.  If the implementation uses > 730      the symmetric route, the TargNode MAY delay transmitting the RREP-DIO > 731      for duration RREP_WAIT_TIME to await a better symmetric route. > > [major] RREP_WAIT_TIME is not defined anywhere. By default it is set to equal 1/4 of the value determined by the L bit. > > [major] "...a better symmetric route."  What makes a route better? I changed the sentence to say lower Rank. > > 733      For a symmetric route, the RREP-DIO message is unicast to the next > 734      hop according to the accumulated address vector (H=0) or the route > 735      entry (H=1).  Thus the DODAG in RREP-Instance does not need to be > 736      built.  The RPLInstanceID in the RREP-Instance is paired as defined > 737      in Section 6.3.3.  In case the 'H' bit is set to 0, the address > 738      vector received in the RREQ-DIO MUST be included in the RREP-DIO. > 739      TargNode increments its current sequence number and uses the > 740      incremented result in the Dest SeqNo in the ART option of the RREQ- > 741      DIO.  The address of the OrigNode MUST be encapsulated in the ART > 742      Option and included in this RREP-DIO message. > > 744    6.3.2.  RREP-DIO for Asymmetric Route > > 746      When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the > 747      TargNode MUST build a DODAG in the RREP-Instance rooted at itself in > 748      order to discover the downstream route from the OrigNode to the > 749      TargNode.  The RREP-DIO message MUST be re-transmitted via link-local > 750      multicast until the OrigNode is reached or MaxRank is exceeded. > > [minor] The previous section talked about delaying the RREP. Should that be considered here too? A similar delay specification has been added. > > 752      The settings of the fields in RREP option and ART option are the same > 753      as for the symmetric route, except for the 'S' bit. > > 755    6.3.3.  RPLInstanceID Pairing > > [minor] Pairing only applied to symmetric routes, right? Please say so. I think it is O.K. to mandate pairing for asymmetric routes. > > 757      Since the RPLInstanceID is assigned locally (i.e., there is no > 758      coordination between routers in the assignment of RPLInstanceID), the > 759      tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely > 760      identify a discovered route.  The upper layer applications may have > 761      different requirements and they can initiate the route discoveries > 762      simultaneously.  Thus between the same pair of OrigNode and TargNode, > 763      there can be multiple AODV-RPL instances.  To avoid any mismatch, the > 764      RREQ-Instance and the RREP-Instance in the same route discovery MUST > 765      be paired somehow, e.g. using the RPLInstanceID. > > [minor] "The upper layer applications may have different requirements and they can initiate the route discoveries simultaneously."  The applications don't initiate route discovery...  Application requirements are mentioned several times in this document, but it is not clear to me how those requirements are reflected in the RREQ. Fixed. > > [major] "..MUST be paired somehow, e.g. using the RPLInstanceID."  There is no clear Normative action here. s/MUST/must I think that the reformulated sentence uses MUST appropriately. > > > ... > 782    6.4.  Receiving and Forwarding Route Reply > > [-] Some of the comments above apply to this section too. I hope they have been addressed but if not please advise. > > > ... > 803         If the constraints are not fulfilled, the router MUST NOT join the > 804         DODAG; the router MUST discard the RREQ-DIO, and does not execute > 805         the remaining steps in this section. > > [nit] s/and does not execute/and not execute Fixed. > > > ... > 813      Step 3: > > 815         If the 'H' bit is set to 1, then the router (OrigNode or > 816         intermediate) MUST build a downward route entry. The route entry > 817         SHOULD include at least the following items: OrigNode Address, > 818         InstanceID, TargNode Address as destination, Next Hop, Lifetime > 819         and Sequence Number.  For a symmetric route, the next hop in the > 820         route entry is the router from which the RREP-DIO is received. > 821         For an asymmetric route, the next hop is the preferred parent in > 822         the DODAG of RREQ-Instance.  The InstanceID in the route entry > 823         MUST be the original RPLInstanceID (after subtracting the Shift > 824         field value).  The source address is learned from the ART Option, > 825         and the destination address is learned from the DODAGID.  The > 826         lifetime is set according to DODAG configuration and can be > 827         extended when the route is actually used.  The sequence number > 828         represents the freshness of the route entry, and is copied from > 829         the Dest SeqNo field of the ART option of the RREP-DIO.  A route > 830         entry with same source and destination address, same InstanceID, > 831         but stale sequence number, SHOULD be deleted. > > [major] The description in §6.2.1 says that the "route entry MUST include...".  Why is SHOULD used in this case?  When is it ok to not include these items?  Should the same apply to §6.2.1? Changed to MUST here also. > > > ... > 851    7.  Gratuitous RREP > > [minor] This section introduces T and O (instead of TargNode/OrigNode) to explain the operation.  That is not a bad thing, but I think that having consistent terminology is a really good thing. Changed to TargNode / OrigNode. > > > ... > 872      In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO > 873      hop-by-hop to T.  The routers along the route SHOULD build new route > 874      entries with the related RPLInstanceID and DODAGID in the downward > 875      direction.  Then T MUST unicast the RREP-DIO hop-by-hop to R, and the > 876      routers along the route SHOULD build new route entries in the upward > 877      direction.  Upon receiving the unicast RREP-DIO, R sends the > 878      gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. > > [major] I don't understand how the "routers along the route" can do anything if the messages are unicast...?? The intention is for the routers along the way to be part of the new RPLInstance and DODAG.  They don't have to change the next hop information. > > 880    8.  Operation of Trickle Timer > > 882      The trickle timer operation to control RREQ-Instance/RREP-Instance > 883      multicast is similar to that in P2P-RPL [RFC6997]. > > [major] "The trickle timer operation...is similar to that in P2P-RPL [RFC6997]."  Similar, or the same?? > > Note that if it is the same, then rfc6997 would have to be a Normative Reference. TODO: rewrite section 8. > > 885    9.  IANA Considerations > > 887    9.1.  New Mode of Operation: AODV-RPL > > 889      IANA is required to assign a new Mode of Operation, named "AODV-RPL" > 890      for Point-to-Point(P2P) hop-by-hop routing under the RPL registry. > 891      The value of TBD1 is assigned from the "Mode of Operation" space > 892      [RFC6550]. > > [major] NEW> >    IANA is asked to assign a new Mode of Operation, named "AODV-RPL" >    for Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation" >    Registry [RFC6550]. > Done. > > 894 +-------------+---------------+---------------+ > 895                 |    Value    |  Description  | Reference   | > 896 +-------------+---------------+---------------+ > 897                 |   TBD1 (5)  |   AODV-RPL    | This document | > 898 +-------------+---------------+---------------+ > > 900                           Figure 6: Mode of Operation > > 902    9.2.  AODV-RPL Options: RREQ, RREP, and Target > > 904      Three entries are required for new AODV-RPL options "RREQ", "RREP" > 905      and "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 (0x0C) > 906      from the "RPL Control Message Options" space [RFC6550]. > > [major] NEW> >    IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and >    "ART", as described in Figure 7 from the "RPL Control Message Options" >    Registry [RFC6550]. > > 908 +-------------+------------------------+---------------+ > 909             |    Value    |        Meaning         | Reference   | > 910 +-------------+------------------------+---------------+ > 911             | TBD2 (0x0A) |      RREQ Option       | This document | > 912 +-------------+------------------------+---------------+ > 913             | TBD3 (0x0B) |      RREP Option       | This document | > 914 +-------------+------------------------+---------------+ > 915             | TBD3 (0x0C) |       ART Option       | This document | > 916 +-------------+------------------------+---------------+ > > 918                           Figure 7: AODV-RPL Options > > 920    10.  Security Considerations > > 922      The security mechanisms defined in section 10 of [RFC6550] and > 923      section 11 of [RFC6997] can also be applied to the control messages > 924      defined in this specification.  The RREQ-DIO and RREP-DIO both have a > 925      secure variant, which provide integrity and replay protection as well > 926      as optional confidentiality and delay protection. > > [major] rfc6997/§11 mostly talks about the processing of the new messages defined there.  How does that apply to this document? > > [major] rfc6997 says that section "10 of [RFC6550] describe RPL's security framework...This security framework can also be used in P2P-RPL after taking into account the constraints specified in Section 11."  How does that apply to this document if both "section 10 of [RFC6550] and section 11 of [RFC6997]" are mentioned above? TODO: Instead of citing RFC 6997, we need to adapt the text to be specific for AODV-RPL messages. > > [minor] §3 talks about the fact that an RREQ-DIO is a DIO message with the rREQ Option (and there's similar text for the RREP-DIO).  However, I think it's confusing to the reader to mention that there are secure variants.  I think that expanding the description (at the end of §3) of what exactly the *-DIO messages are (and that the definition includes the secure variants) would go a long way. Is it O.K. if we note that RREQ and RREP have secure variants, without having to reproduce the entire section? > > 928      AODV-RPL can operate in the three security modes defined in > 929      [RFC6550].  AODV-RPL messages SHOULD use a security mode at least as > 930      strong as the security mode used in RPL. > > [major] "AODV-RPL messages SHOULD use a security mode at least as strong as the security mode used in RPL."  What does that mean? As I asked before, what is the relationship in the network between RPL and AODV-RPL.  I have been assuming that the Options are simply included as an "add-on" to the base RPL already running, but this statement seems to imply that they are completely independent if they can have different security modes.   ?? AODV-RPL does not require RPL to be running.  All routes could be point-to-point.  I think they can be completely independent but still use the same route table.  As you note, this will require some bookkeeping to make sure that route entries discovered by secure messaging are distinguishable from route entries discovered by unsecured messaging. > > 932      o  Unsecured.  In this mode, RREQ-DIO and RREP-DIO are used without > 933         any security fields as defined in section 6.1 of [RFC6550].  The > 934         control messages can be protected by other security mechanisms, > 935         e.g. link-layer security.  This mode SHOULD NOT be used when RPL > 936         is using Preinstalled mode or Authenticated mode (see below). > > [major] There is a Normative contradiction: (above) "This mode SHOULD NOT be used when RPL is using Preinstalled mode or Authenticated mode (see below)." ...and... (below) "Unsecured messages MUST be dropped."  It seems to me that maybe s/SHOULD NOT/MUST NOT Agreed. > > [major] Related:  There's no indication on what should be done with unsecured messages in Authenticated mode.  I'm assuming the same drop action. > > 938      o  Preinstalled.  In this mode, AODV-RPL uses secure RREQ-DIO and > 939         RREP-DIO messages, and a node wishing to join a secured network > 940         will have been pre-configured with a shared key.  A node can use > 941         that key to join the AODV-RPL DODAG as a host or a router. > 942         Unsecured messages MUST be dropped.  This mode SHOULD NOT be used > 943         when RPL is using Authenticated mode. > > [major] When is it ok to use this mode with Authenticated mode?  IOW, why is that not a MUST NOT? Changed to MUST NOT. > > ... > 961    11.  Future Work > > [minor] This section sounds appropriate for an Experimental document and not one in the Standards Track. > > [major] I would expect some of the items below to be specified in a Standards Track document.  For instance, "the initial state of a link" seems pretty basic. Put another way, what should be the settings (for the items mentioned here)? > > 963      There has been some discussion about how to determine the initial > 964      state of a link after an AODV-RPL-based network has begun operation. > 965      The current draft operates as if the links are symmetric until > 966      additional metric information is collected.  The means for making > 967      link metric information is considered out of scope for AODV-RPL.  In > 968      the future, RREQ and RREP messages could be equipped with new fields > 969      for use in verifying link metrics.  In particular, it is possible to > 970      identify unidirectional links; an RREQ received across a > 971      unidirectional link has to be dropped, since the destination node > 972      cannot make use of the received DODAG to route packets back to the > 973      source node that originated the route discovery operation.  This is > 974      roughly the same as considering a unidirectional link to present an > 975      infinite cost metric that automatically disqualifies it for use in > 976      the reverse direction. > > [major] "The current draft operates as if the links are symmetric until additional metric information is collected."  §6 mandates a check to determine the state symmetry.  How is that (unspecified) check related to this text?  It seems to be that it is the same thing; is it? In AODVv2, and to a certain extent in AODV, there is text that goes into some detail about how to determine link symmetry.  That could be adapted for incorporation into AODV-RPL.  Alternatively, and perhaps preferable, we could specify that link symmetry may be determined by procedures that are out of scope for the AODV-RPL specification.  Would that be O.K. We could also change the AODV-RPL document to specify that whether or not a link is symmetric is not assumed to be symmetric by default.  That would be O.K. with me if the determination of link symmetry is out of scope.  For instance, some links could do this at layer 2. > > 978    12.  Contributors > > [minor] In general Contributors are listed list before the Author's Address at the bottom [rfc7322]. Fixed. > > > ... > 1060    Appendix A.  Example: ETX/RSSI Values to select S bit > > [minor] Please expand ETX/RSSI on first mention (§5). Done. > > 1062      We have tested the combination of "RSSI(downstream)" and "ETX > 1063      (upstream)" to determine whether the link is symmetric or asymmetric > 1064      at the intermediate nodes.  The example of how the ETX and RSSI > 1065      values are used in conjuction is explained below: > > [style nit] Don't write in the first person ("We have..."). Fixed. > > [minor] It would be really nice to provide a reference for these tests. TODO: provide a citation. > > [minor] Add references for ETX/RSSI. TODO: provide a citation. > > [nit] s/conjuction/conjunction Fixed. > > > ... > 1083      We tested the operations in this specification by making the > 1084      following experiment, using the above parameters.  In our experiment, > 1085      a communication link is considered as symmetric if the ETX value of > 1086      NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 > 1087      ratio.  This ratio should be taken as a notional metric for deciding > 1088      link symmetric/asymmetric nature, and precise definition of the ratio > 1089      is beyond the scope of the draft.  In general, NodeA can only know > 1090      the ETX value in the direction of NodeA -> NodeB but it has no direct > 1091      way of knowing the value of ETX from NodeB->NodeA.  Using physical > 1092      testbed experiments and realistic wireless channel propagation > 1093      models, one can determine a relationship between RSSI and ETX > 1094      representable as an expression or a mapping table. Such a > 1095      relationship in turn can be used to estimate ETX value at nodeA for > 1096      link NodeB--->NodeA from the received RSSI from NodeB.  Whenever > 1097      nodeA determines that the link towards the nodeB is bi-directional > 1098      asymmetric then the "S" bit is set to "S=0".  Later on, the link from > 1099      NodeA to Destination is asymmetric with "S" bit remains to "0". > > [nit] s/Figure.8/Figure 8 > > [nit] s/within 1:3 ratio/within 1:3 a ratio > > [nit] s/, and precise definition of the ratio is beyond the scope of the draft./.    Not needed, this is just an example. Fixed, fixed, and fixed. > > 1101    Appendix B.  Changelog > > [nit] Add a note to the RFC Editor to remove this section before publication. > Done. Also added a new section about Changes between revisions ...-07 and ...-08. From nobody Fri May 8 05:53:05 2020 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 309EC3A046D for ; Fri, 8 May 2020 05:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 lBg7B-9mnNp7 for ; Fri, 8 May 2020 05:52:56 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253058.outbound.protection.outlook.com [40.92.253.58]) (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 CE9413A041E for ; Fri, 8 May 2020 05:52:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XR2RWtvGO59Mbk5JhxDRF7hUoVD/DkMvJB6SfmvCy/X6bZZZ+0ktn/NRzkOmVOWHCo0pkz7ZrVfaymjmkdNDjqjI8Dq33iy4ROawsIPQ0eSLcVO/qSZfVEzZgbSHjwMXnygyU1WFe561svf4twdqDquAHn3ZwvPrJswbkhzjnh/33sl4GU+YvO4FjL3rw9AgDSX5HEwvbhIOmTN+NKd5pDrcvjZl4ZaG1h/qEhGn4sFxo5uCyFVEJHuclgtvN2IhWm/er0i4rXZAMfxSwTa6fWHAnDe25U1kQfFNt6d5J+xvaVWD970oXpQWzXKveK3AFRX1wtBNo61734fN6tkAJQ== 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=4pPqfVVpCm4LY2MMWLDKawEk5TMh2v4GFwlQsofe2dA=; b=ENmZISO3TzO82evzm2ea+dGUP8xIOkh1pcGhJ4Or38WsXxyLMFAVhhq1UVS3ZLpl8YH1vfKTK2Rx0rOtwn1bd+WbSPZShtPYZvFXyaYTffX4uJEpmXS18EyrLEcnImkiY/8yYitJ6dKnA0vOFyk7CCp5MvMLKsSHUeA5UsfS0nSxcrvQMhAeF+Im9hdwNleCDrvsxuZ7bx1GaPy/qDM1OV57EZPd2hccio1S+lZCHGUXdBOz+HGZzzv7U9nTWEMYHxdYFOoXgUVnHKpaOle6rTCsujso4dY/yZoUGvke2PucWdW8tW4byGcvR1bt306p8ihV0xmLzF12kyLaO4dL+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4pPqfVVpCm4LY2MMWLDKawEk5TMh2v4GFwlQsofe2dA=; b=OGZqlwUQmfMakRQj6hWW2gumByqK6kOAgfIqTqsDwzh5JLT/OFVBySicE3kaaNwqiXRxSgBLmSRaeqzWCRDDRINY57q0qiISbwe77mWxD6ADe89FIgGNw+SlUqR5c6blYtXPfc+oRKx2L8PW8TI1MXutoZANGAodCNGHpj6BOVGF9B8dckRNsanRcsCO2GfZ5Ancrd93GLSJ7eC+JOKyFdzWhvx9R8VvXnot0eDdN5f7+p2iN9eX3X32+iTGQOyfgFb8elAiQl+/A5Klo7rZln6tlUVkdJHYEFOSQIQ4C5pDFFDEi7Bq5Ue3rki9mh65NflXDEcgSB7oHpNHOGLTNQ== Received: from PU1APC01FT035.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::45) by PU1APC01HT029.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::399) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Fri, 8 May 2020 12:52:53 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.58) by PU1APC01FT035.mail.protection.outlook.com (10.152.252.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Fri, 8 May 2020 12:52:52 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2958.034; Fri, 8 May 2020 12:52:52 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKic6mMAgAE5Y88= Date: Fri, 8 May 2020 12:52:52 +0000 Message-ID: References: , <31727.1588874478@localhost> In-Reply-To: <31727.1588874478@localhost> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:81C52B0D249977066F928021C18394A22D4C075D4FFA577943417B915F4818D0; UpperCasedChecksum:0127D78A619059A78E890C3AC5F613BC9253373E6FB046818DBA06AF04D218F9; SizeAsReceived:6828; Count:44 x-tmn: [poy+/NaZM2UZKKeasaqXZ1RKUeorjaBE] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 6d6af4fd-f198-4afb-33dd-08d7f34eb8b8 x-ms-traffictypediagnostic: PU1APC01HT029: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oBX21UeQpG7SdJzYdFX3uG3W2S/+oCUEsINTTv9itQaaDUWeS2V1NgXA08JmHU4dCUpcuZFI6SPageawcSs/SgVEOk6IFCzNlRlfmb6K51Wp1g4ow7isfI2oIgK18/riJBCIdkuWC8rUo/v/62ZHvjrSB1oWndwDdf7x/7mVrrBf1kXF3rtqSw5SpFFxAZjuu6nkcYPsLIY5mOjYxMt6lIuAH8WQ/C+KXV9OzNxentJ9zY6ODiDVxXBpmnWWwBLv x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: 6z45W2t6A55JWs9AOIX17plAeJzAorGrqx1o7OO2DSwKWa1cDphyFI0AGM2rQyVPEGXirf8ChCRf4iQ+v2psAYYRilmd79XR5g1DnFQlnmawcVh9xLg9n/qnMSpVymf/KyQmIz2evhks09uHVriQIg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB40200BA596F107A09BD89DC6A9A20BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d6af4fd-f198-4afb-33dd-08d7f34eb8b8 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 12:52:52.7453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT029 Archived-At: Subject: Re: [Roll] capability handling 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, 08 May 2020 12:53:03 -0000 --_000_BM1PR01MB40200BA596F107A09BD89DC6A9A20BM1PR01MB4020INDP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1pY2hhZWwsDQoNClRoZXJlIHdhcyDigIthbm90aGVyIHBvaW50IHdlIGRpc2N1c3Nl ZCBkdXJpbmcgdGhlIGludGVyaW0gaW4gY29udGV4dCB0byBDYXBhYmlsaXR5IEluZGljYXRvcnM6 IEhvdyB0byBhcnJhbmdlIHRoZSBJbmRpY2F0b3IgYml0cz8NCmEuIFVzaW5nIGxlZnQgdG8gcmln aHQNCmIuIE9yIHVzaW5nIHJpZ2h0IHRvIGxlZnQgKGN1cnJlbnRseSBpbiB0aGUgZHJhZnQgWzFd KQ0KDQpJZiB3ZSB1c2UgcmlnaHQgdG8gbGVmdCB0aGVuIHdlIGNhbiBnaXZlIGV2ZXJ5IGJpdCBh IG51bWJlciwgZm9yIGUuZy4sIGN1cnJlbnRseSB0aGUgJ1QnIGJpdCBpcyAweDEuIFRoZSBsZW5n dGggY2FuIGJlIHNldCBhY2NvcmRpbmdseSBpLmUuIGlmIHRoZSBpbmRpY2F0b3JzIGFyZSBsZXNz IHRoYW4gOCBiaXRzIHRoZW4gdGhlIGxlbmd0aCB3aWxsIGJlIG9uZS4NClRoaXMgaXMgc2ltcGxl ciB0byBoYW5kbGUgaW4gaW1wbGVtZW50YXRpb24gYXMgd2VsbC4gVGhvdWdodHM/DQoNCkJlc3Qs DQpSYWh1bA0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLXJvbGwtY2FwYWJpbGl0aWVzLTAzI3NlY3Rpb24tNS4xLjENCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IFJvbGwgPHJvbGwtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0K U2VudDogMDggTWF5IDIwMjAgMDI6MDEgQU0NClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFu ZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0gY2Fw YWJpbGl0eSBoYW5kbGluZw0KDQoNClJhaHVsIEphZGhhdiA8bnlyYWh1bEBvdXRsb29rLmNvbT4g d3JvdGU6DQogICAgPiBXZSB3b3VsZCBsaWtlIHRvIHNvbGljaXQgc29tZSBmZWVkYmFjayBhYm91 dCB0d28gcG9pbnRzIGluIGNvbnRleHQgdG8NCiAgICA+IGNhcGFiaWxpdGllczoNCg0KICAgID4g MS4gQ2FwYWJpbGl0eSBJbnN0YW5jZXM6IEN1cnJlbnRseSB0aGUgZG9jdW1lbnQgaW5zdGFudGlh dGVzIHR3bw0KICAgID4gY2FwYWJpbGl0aWVzIHZpeiwgYSkgQ2FwYWJpbGl0eSBJbmRpY2F0b3Jz ICh3aGljaCBjYW4gYmUgdXNlZCB0byBjYXJyeQ0KICAgID4gZmxhZ3Mgc3VjaCBhcyBzdXBwb3J0 IG9mIDZMb1JIKQ0KICAgID4gYikgUm91dGluZyBSZXNvdXJjZSBjYXBhYmlsaXR5IHdoaWNoDQog ICAgPiBpbmRpY2F0ZXMgdG90YWwgUklCIGNhcGFjaXR5IHRoZSBub2RlIGhhcy4gVGhpcyBzaG91 bGQgYmUgdXNlZnVsIGZvcg0KICAgID4gREFPIFByb2plY3Rpb24uDQoNCiAgICA+IERvIHlvdSB0 aGluayB3ZSBzaG91bGQgYWRkIE5laWdoYm9yIENhY2hlIGNhcGFjaXR5DQogICAgPiBpbmRpY2F0 aW9uIGFzIHdlbGwgYW5kIHdoYXQgd291bGQgYmUgdGhlIHVzZS1jYXNlPw0KDQpJbiBzb21lIGlt cGxlbWVudGF0aW9ucyB0aGUgTmVpZ2hib3IgQ2FjaGUgYW5kIFJJQiBtaWdodCBjb21lIGZyb20g dGhlIHNhbWUNCnBvb2wgb2YgcmVzb3VyY2VzLiAgQm90aCBhcmUgbG9va3VwIC8xMjggYW5kIGFk ZC1oZWFkZXIgYW5kIHhtaXQgOi0pDQooQlNEIHN5c3RlbXMgbWVyZ2VkIHRoZW0gYmFjayBpbiBC U0Q0LjQsIGFzIGFuIGV4YW1wbGUpDQoNCklmIGEgbm9kZSBydW5zIG91dCBvZiBSSUIgZW50cmll cywgaXQgY2FuJ3QgYWRkIGFueSBtb3JlIGdyYW5kY2hpbGRyZW4uDQpJZiBhIG5vZGUgcnVucyBv dXQgb2YgTkMgZW50cmllcywgIGl0IGNhbid0IGFkZCBhbnkgbW9yZSBwZWVyczogY2hpbGRyZW4g b3IgcGFyZW50cy4NCg0KSXQgc2VlbXMgdGhhdCB3ZSBuZWVkIHRvIGNvbGxlY3QgYm90aCBpbmZv cm1hdGlvbiwgYnV0IHdlIG1pZ2h0IG5lZWQgdG8gYmUNCmNsZWFyIGlmIHRoZXkgYXJlIGxpbmtl ZC4NCg0KICAgID4gICBEbyB3ZSBuZWVkIGFuIGV4cGxpY2l0ICdHJyBmbGFnPyBXZSBhbHJlYWR5 IGhhdmUgYSBmbGFnIChDLWNvcHkpDQogICAgPiAgIHdoaWNoIGluZGljYXRlcyB0aGF0IG5vZGVz IGhhdmUgdG8gY29weSB0aGUgY2FwIGlmIHRoZXkgZG9uJ3QNCiAgICA+ICAgdW5kZXJzdGFuZCB0 aGUgY2FwLiBBIGdsb2JhbCBjYXBhYmlsaXR5IGZyb20gdGhlIHJvb3QgY2FuIGJlDQogICAgPiAg IGFkdmVydGlzZWQgd2l0aCB0aGlzIGJpdCBzZXQuIE5vZGVzIHVuZGVyc3RhbmRpbmcgdGhpcyBj YXAgd2lsbA0KICAgID4gICBhbnl3YXlzIGtub3cgaG93IHRvIGhhbmRsZSBhbmQgbm9kZXMgbm90 IHVuZGVyc3RhbmRpbmcgaXQgd2lsbCBjb3B5DQogICAgPiAgIGl0IGJhc2VkIG9uIHRoZSAnQycg ZmxhZy4gVGh1cyBub3QgcmVxdWlyaW5nIGFub3RoZXIgJ0cnIGZsYWcuDQoNCkkgaGF2ZSB0byB0 aGluayBtb3JlIG9uIHRoaXMuDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNh bmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNvbnN1 bHRpbmcgPS0NCg== --_000_BM1PR01MB40200BA596F107A09BD89DC6A9A20BM1PR01MB4020INDP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KVGhhbmtzIE1pY2hhZWwsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogcmdiKDAsIDAsIDApOyI+DQpUaGVyZSB3YXMmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogcmdiKDAsIDAsIDApOyI+4oCLYW5vdGhlciBwb2ludCB3ZSBkaXNjdXNzZWQgZHVyaW5nIHRo ZSBpbnRlcmltIGluIGNvbnRleHQgdG8gQ2FwYWJpbGl0eSBJbmRpY2F0b3JzOiBIb3cgdG8gYXJy YW5nZSB0aGUgSW5kaWNhdG9yIGJpdHM/PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj b2xvcjogcmdiKDAsIDAsIDApOyI+DQphLiBVc2luZyBsZWZ0IHRvIHJpZ2h0PC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCmIuIE9yIHVzaW5nIHJpZ2h0IHRv IGxlZnQgKGN1cnJlbnRseSBpbiB0aGUgZHJhZnQgWzFdKTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsg Y29sb3I6IHJnYigwLCAwLCAwKTsiPg0KSWYgd2UgdXNlIHJpZ2h0IHRvIGxlZnQgdGhlbiB3ZSBj YW4gZ2l2ZSBldmVyeSBiaXQgYSBudW1iZXIsIGZvciBlLmcuLCBjdXJyZW50bHkgdGhlICdUJyBi aXQgaXMgMHgxLiBUaGUgbGVuZ3RoIGNhbiBiZSBzZXQgYWNjb3JkaW5nbHkgaS5lLiBpZiB0aGUg aW5kaWNhdG9ycyBhcmUgbGVzcyB0aGFuIDggYml0cyB0aGVuIHRoZSBsZW5ndGggd2lsbCBiZSBv bmUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NClRoaXMg aXMgc2ltcGxlciB0byBoYW5kbGUgaW4gaW1wbGVtZW50YXRpb24gYXMgd2VsbC4gVGhvdWdodHM/ PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpCZXN0LDwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpSYWh1bDwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KWzFdJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJvbGwtY2Fw YWJpbGl0aWVzLTAzI3NlY3Rpb24tNS4xLjEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWNhcGFiaWxpdGllcy0wMyNzZWN0aW9uLTUuMS4xPC9h PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImFwcGVuZG9uc2VuZCI+PC9kaXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6 aW5saW5lLWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlG d2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0i Zm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48Yj5Gcm9tOjwvYj4gUm9sbCAmbHQ7cm9s bC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWljaGFlbCBSaWNoYXJkc29uICZs dDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiAwOCBNYXkg MjAyMCAwMjowMSBBTTxicj4NCjxiPlRvOjwvYj4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQg TG9zc3kgbmV0d29ya3MgJmx0O3JvbGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbUm9sbF0gY2FwYWJpbGl0eSBoYW5kbGluZzwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NClJh aHVsIEphZGhhdiAmbHQ7bnlyYWh1bEBvdXRsb29rLmNvbSZndDsgd3JvdGU6PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgV2Ugd291bGQgbGlrZSB0byBzb2xpY2l0IHNvbWUgZmVlZGJhY2sg YWJvdXQgdHdvIHBvaW50cyBpbiBjb250ZXh0IHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgY2FwYWJpbGl0aWVzOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDEuIENh cGFiaWxpdHkgSW5zdGFuY2VzOiBDdXJyZW50bHkgdGhlIGRvY3VtZW50IGluc3RhbnRpYXRlcyB0 d288YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjYXBhYmlsaXRpZXMgdml6LCBhKSBDYXBh YmlsaXR5IEluZGljYXRvcnMgKHdoaWNoIGNhbiBiZSB1c2VkIHRvIGNhcnJ5PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgZmxhZ3Mgc3VjaCBhcyBzdXBwb3J0IG9mIDZMb1JIKTxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGIpIFJvdXRpbmcgUmVzb3VyY2UgY2FwYWJpbGl0eSB3aGlj aDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGluZGljYXRlcyB0b3RhbCBSSUIgY2FwYWNp dHkgdGhlIG5vZGUgaGFzLiBUaGlzIHNob3VsZCBiZSB1c2VmdWwgZm9yPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgREFPIFByb2plY3Rpb24uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgRG8geW91IHRoaW5rIHdlIHNob3VsZCBhZGQgTmVpZ2hib3IgQ2FjaGUgY2FwYWNp dHk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbmRpY2F0aW9uIGFzIHdlbGwgYW5kIHdo YXQgd291bGQgYmUgdGhlIHVzZS1jYXNlPzxicj4NCjxicj4NCkluIHNvbWUgaW1wbGVtZW50YXRp b25zIHRoZSBOZWlnaGJvciBDYWNoZSBhbmQgUklCIG1pZ2h0IGNvbWUgZnJvbSB0aGUgc2FtZTxi cj4NCnBvb2wgb2YgcmVzb3VyY2VzLiZuYnNwOyBCb3RoIGFyZSBsb29rdXAgLzEyOCBhbmQgYWRk LWhlYWRlciBhbmQgeG1pdCA6LSk8YnI+DQooQlNEIHN5c3RlbXMgbWVyZ2VkIHRoZW0gYmFjayBp biBCU0Q0LjQsIGFzIGFuIGV4YW1wbGUpPGJyPg0KPGJyPg0KSWYgYSBub2RlIHJ1bnMgb3V0IG9m IFJJQiBlbnRyaWVzLCBpdCBjYW4ndCBhZGQgYW55IG1vcmUgZ3JhbmRjaGlsZHJlbi48YnI+DQpJ ZiBhIG5vZGUgcnVucyBvdXQgb2YgTkMgZW50cmllcywmbmJzcDsgaXQgY2FuJ3QgYWRkIGFueSBt b3JlIHBlZXJzOiBjaGlsZHJlbiBvciBwYXJlbnRzLjxicj4NCjxicj4NCkl0IHNlZW1zIHRoYXQg d2UgbmVlZCB0byBjb2xsZWN0IGJvdGggaW5mb3JtYXRpb24sIGJ1dCB3ZSBtaWdodCBuZWVkIHRv IGJlPGJyPg0KY2xlYXIgaWYgdGhleSBhcmUgbGlua2VkLjxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IERvIHdlIG5lZWQgYW4gZXhwbGljaXQgJ0cnIGZsYWc/ IFdlIGFscmVhZHkgaGF2ZSBhIGZsYWcgKEMtY29weSk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZuYnNwOyZuYnNwOyB3aGljaCBpbmRpY2F0ZXMgdGhhdCBub2RlcyBoYXZlIHRvIGNvcHkg dGhlIGNhcCBpZiB0aGV5IGRvbid0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsm bmJzcDsgdW5kZXJzdGFuZCB0aGUgY2FwLiBBIGdsb2JhbCBjYXBhYmlsaXR5IGZyb20gdGhlIHJv b3QgY2FuIGJlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsgYWR2ZXJ0 aXNlZCB3aXRoIHRoaXMgYml0IHNldC4gTm9kZXMgdW5kZXJzdGFuZGluZyB0aGlzIGNhcCB3aWxs PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsgYW55d2F5cyBrbm93IGhv dyB0byBoYW5kbGUgYW5kIG5vZGVzIG5vdCB1bmRlcnN0YW5kaW5nIGl0IHdpbGwgY29weTxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IGl0IGJhc2VkIG9uIHRoZSAnQycg ZmxhZy4gVGh1cyBub3QgcmVxdWlyaW5nIGFub3RoZXIgJ0cnIGZsYWcuPGJyPg0KPGJyPg0KSSBo YXZlIHRvIHRoaW5rIG1vcmUgb24gdGhpcy48YnI+DQo8YnI+DQotLTxicj4NCk1pY2hhZWwgUmlj aGFyZHNvbiAmbHQ7bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYSZndDssIFNhbmRlbG1hbiBTb2Z0 d2FyZSBXb3Jrczxicj4NCiZuYnNwOy09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS08YnI+DQo8L2Rp dj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BM1PR01MB40200BA596F107A09BD89DC6A9A20BM1PR01MB4020INDP_-- From nobody Fri May 8 11:05:35 2020 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 740223A0F18 for ; Fri, 8 May 2020 11:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ky8Erxw-dtKu for ; Fri, 8 May 2020 11:05:31 -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 8427B3A0F14 for ; Fri, 8 May 2020 11:05:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 57A1138991 for ; Fri, 8 May 2020 14:03:29 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FAlZQ7MzqiCd for ; Fri, 8 May 2020 14:03:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EFCD3898E for ; Fri, 8 May 2020 14:03:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 91D284E7 for ; Fri, 8 May 2020 14:05:29 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: , <31727.1588874478@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] capability handling 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, 08 May 2020 18:05:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rahul Jadhav wrote: > There was =E2=80=8Banother point we discussed during the interim in c= ontext to > Capability Indicators: How to arrange the Indicator bits? a. Using > left to right b. Or using right to left (currently in the draft [1]) > If we use right to left then we can give every bit a number, for e.g., > currently the 'T' bit is 0x1. The length can be set accordingly i.e. = if > the indicators are less than 8 bits then the length will be one. This > is simpler to handle in implementation as well. Thoughts? (1) If we number from right to left, can we expand the field to be as many = octets are we like? So len=3D3 is just an example? Don't transmit zero bytes. (2) If we number from left to right, then we could number them "bit 0" thro= ugh "bit 7" of byte 0 through 255. The IANA considerations for this might be a bit weird either way. I guess there is a maximum number of octets that we can get into the field anyway, so we declare it to be a field with that many bits and ask IANA to allocate contiguously. The effect is the same: we don't transmit bytes which are zeros, it's just whether we consider those zeros on the left or right. I think that (2) might easier to code because the offset of each flag will not move as the structure gets longer, and it doesn't confuse people into thinking they need 64-bit ints, which then fail on capability #65. (actuall= y #64) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl61n2kACgkQgItw+93Q 3WWmYwf/UWU6ccdP5Lvf6dtqjfGelY6Xx/sPyUZp1xj+cy6ndwD6818ZdrBBVPN8 6ieOmEBCDkPNUCnCsz5rK9Wv+5qzObWC0abhslks/t7icJ411+bbYj93+76vpDLv uM3dzMLgBI28LAtv/5K9yM5kX9lTL4BRBagyW0RkzFxT/tlvYyTbBJWE/d6VIFh1 48+WWneL++wgoIU+rZhhOzDgyNMHnMqcfh+msfD06dwJ2aznDyYw1AvxOLlWaipF 7pfeK3NeQ4nd104jFGSEwfbcIDi17CUre/jUtUXYd5ZS0OhYJPY4e2ISgyGfrkoQ J1qV8YRe1WJpboVX+ZxsEqzeZSoFXA== =xuma -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 9 05:46:27 2020 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 80F2B3A0A4E for ; Sat, 9 May 2020 05:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 3FphCZ0lUzsv for ; Sat, 9 May 2020 05:46:22 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253068.outbound.protection.outlook.com [40.92.253.68]) (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 D9E1C3A0A3C for ; Sat, 9 May 2020 05:46:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ffny90wSfpmJcTsuG28uam0QawVVQDOcC9eIEIsSL84ug331Tve8JKrY8dCBhbcIgpvbsCLu0tGl7UlIUdj/HGnvWP0P+tIQp/RsKpzF5EeSVG/GyCd6mEJkPngx9UmdUuuhSHhwSVJpWim8KnPuinFEbNySTYQc93QxDcfGinwYNhTzq1y1bmtjcwaHbETMedvugcwz8iNs/03CkCk6Rdky2dTCdSOd7Iyh9lA1w4+MUx6CFPSIahOm8eB48t70g9V5Atz/XY0w5ajCCHlNsEzDVxcYftP4inPjWrPaw628iO5ermMt4rV9R6QScyuDlWlyX84/TdIOCR7kxsXWnQ== 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=7mL82512o7AligCvyZkF0HrbpkJhNdjWz8M5hTjLMuE=; b=h0sOjLMBOlzWY/z8FP/TOPra+3gLk+/LjFE5BvLp+Blxb6N3+G0Ayrk9uX3Zutpce6mAaA7TdZ8JBj9C2/SDkZrfCYYFdXKGf8xSvBpaEvoNHEFA6bIE8+1rShr4p2grSMPTuanM4aNBbUhrMyZNc4vcpK/wbY1fCckbNe7CaXMYESyxkwdTnn4CuH1w4Sc1RPyXGLj/tkgwvXVBWpNib/kQvEw3FDT7XFqgPp6vvZQe+i3gO9RQVwqwyeVQln+kxdtsn1sfSu0ZlC8TnLsRYsDxKbg/1n4xnRT5BM6qnBVfWp1JCvTbxVZEeoG5chAfuDXy1zXlGcqJWkzlNjkLeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7mL82512o7AligCvyZkF0HrbpkJhNdjWz8M5hTjLMuE=; b=YlvTLd81f2FfGtbmiJl6OsZ0qhgXvWpuBxIzfWUJU8ZHW+xdwgiXLSn3oB39VMyh9W0bxA1qIZCHxktQbW+sKB4yhm9oW3+y1ERgUTywaVZisvUXkzindj2xUqQOi+XTk/Xbiry+geeo/CETuKbWAFYMh2p5Quf8uqBpfvJfagNo3BNgYNb58uX9HFt/iGpyebD9YmmKmDCfnHFoY6eb/g+DJFOkeJlTshImiemhCiPqui/1wXCOt8yLyUo98TnnBDA/0YRmpJe+jueXOK80P4dxYcLkdCZTa+Cs1DRboBECpfbsicLNWP9iP8XRVbBbYWjx+OckozwgpJaRRRnC4A== Received: from HK2APC01FT037.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::45) by HK2APC01HT183.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Sat, 9 May 2020 12:46:18 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.248.59) by HK2APC01FT037.mail.protection.outlook.com (10.152.248.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Sat, 9 May 2020 12:46:18 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2979.033; Sat, 9 May 2020 12:46:18 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKic6mMAgAE5Y8+AAFodgIABOC3n Date: Sat, 9 May 2020 12:46:18 +0000 Message-ID: References: , <31727.1588874478@localhost> , <25184.1588961129@localhost> In-Reply-To: <25184.1588961129@localhost> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:08DDC697E4F700879533B2858B0F5DCA6EFDD172A9E2EF57A4C7660B4A4CEA63; UpperCasedChecksum:DC9220DAE7CE6E6FD22C0308F2378923D48B74299CB8384180D58D0B78BB980D; SizeAsReceived:6955; Count:44 x-tmn: [P7J7VNbxmCdFeeiTTZh/wBup30/O5iDd] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 30f96988-1523-4bc8-e5bd-08d7f416f841 x-ms-traffictypediagnostic: HK2APC01HT183: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +P4JtN/kPWTFxGRp0hJeq5IE0zB81ySCnDtXweQK1Q+FkN6DGm06A+MWFaL2FnjQu6nlu1BPB4mlQFcR076C+c6wjk9vh2k1pTD5pUdJVglTkoaJIInSl5pI/6hUAVB3TFMkh7t0V/5t5hKDOXL3Qd/NmWCk4RhXaOvdB//gKjuyIukbbp36+YGxWIG3nEGw/RMLVMgDhGwDgE+ovf0sTw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: J0+U77EejR77c+ktJiZG5Dch1WuuJTvE/be67GDZGrRD+XD8SB1e6DEOKpwZnrff5P77l37T50ITVk75Gkzf+bzwBx26c4RBDnPQZrRhKCIiO+vQErmsVO4jSA3hvtdXWGDEsR2R/xD3AEZaKqaC4Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402013BCAA111B49554F286DA9A30BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 30f96988-1523-4bc8-e5bd-08d7f416f841 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2020 12:46:18.6711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT183 Archived-At: Subject: Re: [Roll] capability handling 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, 09 May 2020 12:46:25 -0000 --_000_BM1PR01MB402013BCAA111B49554F286DA9A30BM1PR01MB4020INDP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgY29tbWVudHMgaW5saW5lLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg TWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQpTZW50OiAwOSBNYXkg MjAyMCAwMjowNSBBTQ0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdv cmtzIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtSb2xsXSBjYXBhYmlsaXR5IGhhbmRs aW5nDQoNCg0KUmFodWwgSmFkaGF2IDxueXJhaHVsQG91dGxvb2suY29tPiB3cm90ZToNCiAgICA+ IFRoZXJlIHdhcyDigIthbm90aGVyIHBvaW50IHdlIGRpc2N1c3NlZCBkdXJpbmcgdGhlIGludGVy aW0gaW4gY29udGV4dCB0bw0KICAgID4gQ2FwYWJpbGl0eSBJbmRpY2F0b3JzOiBIb3cgdG8gYXJy YW5nZSB0aGUgSW5kaWNhdG9yIGJpdHM/ICBhLiBVc2luZw0KICAgID4gbGVmdCB0byByaWdodCBi LiBPciB1c2luZyByaWdodCB0byBsZWZ0IChjdXJyZW50bHkgaW4gdGhlIGRyYWZ0IFsxXSkNCg0K ICAgID4gSWYgd2UgdXNlIHJpZ2h0IHRvIGxlZnQgdGhlbiB3ZSBjYW4gZ2l2ZSBldmVyeSBiaXQg YSBudW1iZXIsIGZvciBlLmcuLA0KICAgID4gY3VycmVudGx5IHRoZSAnVCcgYml0IGlzIDB4MS4g VGhlIGxlbmd0aCBjYW4gYmUgc2V0IGFjY29yZGluZ2x5IGkuZS4gaWYNCiAgICA+IHRoZSBpbmRp Y2F0b3JzIGFyZSBsZXNzIHRoYW4gOCBiaXRzIHRoZW4gdGhlIGxlbmd0aCB3aWxsIGJlIG9uZS4g IFRoaXMNCiAgICA+IGlzIHNpbXBsZXIgdG8gaGFuZGxlIGluIGltcGxlbWVudGF0aW9uIGFzIHdl bGwuIFRob3VnaHRzPw0KDQooMSkgSWYgd2UgbnVtYmVyIGZyb20gcmlnaHQgdG8gbGVmdCwgY2Fu IHdlIGV4cGFuZCB0aGUgZmllbGQgdG8gYmUgYXMgbWFueSBvY3RldHMNCiAgICBhcmUgd2UgbGlr ZT8gIFNvIGxlbj0zIGlzIGp1c3QgYW4gZXhhbXBsZT8gIERvbid0IHRyYW5zbWl0IHplcm8gYnl0 ZXMuDQoNCltSSl0gWWVhaCBsZW49MyBpcyBqdXN0IGFuIGV4YW1wbGUuDQoNCigyKSBJZiB3ZSBu dW1iZXIgZnJvbSBsZWZ0IHRvIHJpZ2h0LCB0aGVuIHdlIGNvdWxkIG51bWJlciB0aGVtICJiaXQg MCIgdGhyb3VnaA0KICAgICJiaXQgNyIgb2YgYnl0ZSAwIHRocm91Z2ggMjU1Lg0KDQpUaGUgSUFO QSBjb25zaWRlcmF0aW9ucyBmb3IgdGhpcyBtaWdodCBiZSBhIGJpdCB3ZWlyZCBlaXRoZXIgd2F5 Lg0KSSBndWVzcyB0aGVyZSBpcyBhIG1heGltdW0gbnVtYmVyIG9mIG9jdGV0cyB0aGF0IHdlIGNh biBnZXQgaW50byB0aGUgZmllbGQNCmFueXdheSwgc28gd2UgZGVjbGFyZSBpdCB0byBiZSBhIGZp ZWxkIHdpdGggdGhhdCBtYW55IGJpdHMgYW5kIGFzayBJQU5BIHRvDQphbGxvY2F0ZSBjb250aWd1 b3VzbHkuDQoNClRoZSBlZmZlY3QgaXMgdGhlIHNhbWU6IHdlIGRvbid0IHRyYW5zbWl0IGJ5dGVz IHdoaWNoIGFyZSB6ZXJvcywgaXQncyBqdXN0DQp3aGV0aGVyIHdlIGNvbnNpZGVyIHRob3NlIHpl cm9zIG9uIHRoZSBsZWZ0IG9yIHJpZ2h0Lg0KDQpJIHRoaW5rIHRoYXQgKDIpIG1pZ2h0IGVhc2ll ciB0byBjb2RlIGJlY2F1c2UgdGhlIG9mZnNldCBvZiBlYWNoIGZsYWcgd2lsbA0Kbm90IG1vdmUg YXMgdGhlIHN0cnVjdHVyZSBnZXRzIGxvbmdlciwgYW5kIGl0IGRvZXNuJ3QgY29uZnVzZSBwZW9w bGUgaW50bw0KdGhpbmtpbmcgdGhleSBuZWVkIDY0LWJpdCBpbnRzLCB3aGljaCB0aGVuIGZhaWwg b24gY2FwYWJpbGl0eSAjNjUuIChhY3R1YWxseSAjNjQpDQoNCltSSl0gVGhpcyBwb2ludCBtYWtl cyBzZW5zZS4gSWYgdGhlIGluZGljYXRvcnMgZ28gbW9yZSB0aGFuIChvciBlcSB0bykgNjQgdGhl biB0aGUgb3BlcmF0aW9ucyBhcmUgbm90IHNvIHN0cmFpZ2h0Zm9yd2FyZCB0byBoYW5kbGUuIFdp dGggbGVmdCB0byByaWdodCwgdGhlIGNvbXBsZXhpdHkgaXMgY29uc3RhbnQgcmVnYXJkbGVzcyBv ZiB0aGUgbnVtYmVyIG9mIGJpdHMuDQoNCg== --_000_BM1PR01MB402013BCAA111B49554F286DA9A30BM1PR01MB4020INDP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KUGxlYXNlIGZpbmQgY29tbWVudHMgaW5saW5lLjwvZGl2Pg0KPGRpdiBp ZD0iYXBwZW5kb25zZW5kIj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks SGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4N Cjxicj4NCjwvZGl2Pg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJs b2NrOyB3aWR0aDo5OCUiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250 IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1z aXplOjExcHQiPjxiPkZyb206PC9iPiBSb2xsICZsdDtyb2xsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 IG9uIGJlaGFsZiBvZiBNaWNoYWVsIFJpY2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxt YW4uY2EmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IDA5IE1heSAyMDIwIDAyOjA1IEFNPGJyPg0KPGI+ VG86PC9iPiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9s bEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSb2xsXSBjYXBhYmlsaXR5 IGhhbmRsaW5nPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Qm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQi Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48YnI+DQpSYWh1bCBKYWRoYXYgJmx0O255cmFodWxA b3V0bG9vay5jb20mZ3Q7IHdyb3RlOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRoZXJl IHdhcyDigIthbm90aGVyIHBvaW50IHdlIGRpc2N1c3NlZCBkdXJpbmcgdGhlIGludGVyaW0gaW4g Y29udGV4dCB0bzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IENhcGFiaWxpdHkgSW5kaWNh dG9yczogSG93IHRvIGFycmFuZ2UgdGhlIEluZGljYXRvciBiaXRzPyZuYnNwOyBhLiBVc2luZzxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGxlZnQgdG8gcmlnaHQgYi4gT3IgdXNpbmcgcmln aHQgdG8gbGVmdCAoY3VycmVudGx5IGluIHRoZSBkcmFmdCBbMV0pPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgSWYgd2UgdXNlIHJpZ2h0IHRvIGxlZnQgdGhlbiB3ZSBjYW4gZ2l2 ZSBldmVyeSBiaXQgYSBudW1iZXIsIGZvciBlLmcuLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IGN1cnJlbnRseSB0aGUgJ1QnIGJpdCBpcyAweDEuIFRoZSBsZW5ndGggY2FuIGJlIHNldCBh Y2NvcmRpbmdseSBpLmUuIGlmPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhlIGluZGlj YXRvcnMgYXJlIGxlc3MgdGhhbiA4IGJpdHMgdGhlbiB0aGUgbGVuZ3RoIHdpbGwgYmUgb25lLiZu YnNwOyBUaGlzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaXMgc2ltcGxlciB0byBoYW5k bGUgaW4gaW1wbGVtZW50YXRpb24gYXMgd2VsbC4gVGhvdWdodHM/PGJyPg0KPGJyPg0KKDEpIElm IHdlIG51bWJlciBmcm9tIHJpZ2h0IHRvIGxlZnQsIGNhbiB3ZSBleHBhbmQgdGhlIGZpZWxkIHRv IGJlIGFzIG1hbnkgb2N0ZXRzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSB3ZSBsaWtlPyZu YnNwOyBTbyBsZW49MyBpcyBqdXN0IGFuIGV4YW1wbGU/Jm5ic3A7IERvbid0IHRyYW5zbWl0IHpl cm8gYnl0ZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iUGxhaW5UZXh0Ij5bUkpdIFllYWggbGVuPTMgaXMganVzdCBhbiBleGFtcGxlLjxi cj4NCjxicj4NCigyKSBJZiB3ZSBudW1iZXIgZnJvbSBsZWZ0IHRvIHJpZ2h0LCB0aGVuIHdlIGNv dWxkIG51bWJlciB0aGVtICZxdW90O2JpdCAwJnF1b3Q7IHRocm91Z2g8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7Yml0IDcmcXVvdDsgb2YgYnl0ZSAwIHRocm91Z2ggMjU1Ljxicj4NCjxi cj4NClRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciB0aGlzIG1pZ2h0IGJlIGEgYml0IHdlaXJk IGVpdGhlciB3YXkuPGJyPg0KSSBndWVzcyB0aGVyZSBpcyBhIG1heGltdW0gbnVtYmVyIG9mIG9j dGV0cyB0aGF0IHdlIGNhbiBnZXQgaW50byB0aGUgZmllbGQ8YnI+DQphbnl3YXksIHNvIHdlIGRl Y2xhcmUgaXQgdG8gYmUgYSBmaWVsZCB3aXRoIHRoYXQgbWFueSBiaXRzIGFuZCBhc2sgSUFOQSB0 bzxicj4NCmFsbG9jYXRlIGNvbnRpZ3VvdXNseS48YnI+DQo8YnI+DQpUaGUgZWZmZWN0IGlzIHRo ZSBzYW1lOiB3ZSBkb24ndCB0cmFuc21pdCBieXRlcyB3aGljaCBhcmUgemVyb3MsIGl0J3MganVz dDxicj4NCndoZXRoZXIgd2UgY29uc2lkZXIgdGhvc2UgemVyb3Mgb24gdGhlIGxlZnQgb3Igcmln aHQuPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0ICgyKSBtaWdodCBlYXNpZXIgdG8gY29kZSBiZWNh dXNlIHRoZSBvZmZzZXQgb2YgZWFjaCBmbGFnIHdpbGw8YnI+DQpub3QgbW92ZSBhcyB0aGUgc3Ry dWN0dXJlIGdldHMgbG9uZ2VyLCBhbmQgaXQgZG9lc24ndCBjb25mdXNlIHBlb3BsZSBpbnRvPGJy Pg0KdGhpbmtpbmcgdGhleSBuZWVkIDY0LWJpdCBpbnRzLCB3aGljaCB0aGVuIGZhaWwgb24gY2Fw YWJpbGl0eSAjNjUuIChhY3R1YWxseSAjNjQpPC9kaXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQi Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5bUkpdIFRoaXMgcG9pbnQgbWFr ZXMgc2Vuc2UuIElmIHRoZSBpbmRpY2F0b3JzIGdvIG1vcmUgdGhhbiAob3IgZXEgdG8pIDY0IHRo ZW4gdGhlIG9wZXJhdGlvbnMgYXJlIG5vdCBzbyBzdHJhaWdodGZvcndhcmQgdG8gaGFuZGxlLiBX aXRoIGxlZnQgdG8gcmlnaHQsIHRoZSBjb21wbGV4aXR5IGlzIGNvbnN0YW50IHJlZ2FyZGxlc3Mg b2YgdGhlIG51bWJlciBvZiBiaXRzLjxicj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BM1PR01MB402013BCAA111B49554F286DA9A30BM1PR01MB4020INDP_-- From nobody Mon May 11 06:16:45 2020 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 BC6823A0AAB; Mon, 11 May 2020 06:16:42 -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.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158920300240.23655.9340436289072195358@ietfa.amsl.com> Date: Mon, 11 May 2020 06:16:42 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-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: Mon, 11 May 2020 13:16:43 -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-10.txt Pages : 32 Date : 2020-05-11 Abstract: This document enables 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 source-route header or in terms of path length, which impacts both the latency and the packet delivery ratio. Projected Routes may be installed in either Storing and Non-Storing Modes Instances of the classical RPL operation, resulting in potentially hybrid situations where the mode of some Projected Routes is different from that of the other routes in the RPL Instance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-dao-projection-10 https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-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 Mon May 11 07:39:35 2020 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 8E4EE3A0BA4 for ; Mon, 11 May 2020 07:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HOPpJi03; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=byZU0dVg 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 omhAuIzdw-7K for ; Mon, 11 May 2020 07:39:13 -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 B75AD3A0B97 for ; Mon, 11 May 2020 07:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14474; q=dns/txt; s=iport; t=1589207925; x=1590417525; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=U1TandEun5F1aJdLRfQGdY/snrONhnfV4MjEwUspQOY=; b=HOPpJi03uYhI+gD5sLlJ1hnavlAWyjoP0U7wcr3tMKgBGyQPrq+VrC3k S/3K5O6e98QUoYPESSzvc+WqRcih58gpevGZDxhXFkreZqXnQWTCleXT8 u5/kaKWb8KfFizpY9keTgw+i6n0sfKkxMjYJSbt6x+16jdRxmUE5qyedJ w=; IronPort-PHdr: =?us-ascii?q?9a23=3AiuFTYBKRY/aoBJf5C9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZDwAbYrle/4YNJK1mHgEBCxIMQIJ?= =?us-ascii?q?sAS5RBW9YLyyHagOLMYIRk1SEY4JSA1QLAQEBDAEBLQIEAQGERAKCDiQ4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEFBG2FVgyFcQEBAQEDEhsTAQE4DwIBCBEEAQEoBzIUCQg?= =?us-ascii?q?CBBMIGoMFgX5NAy4Bo1oCgTmIYXSBNIMBAQEFhSMYgg4JgTiCY4JJhxgagUE?= =?us-ascii?q?/gVSCTT6ELAEBAiA0gxGCLY5GiSqafwqCSphFnTqOUZ52AgQCBAUCDgEBBYF?= =?us-ascii?q?pIoFWcBWDJFAYDZBAg3KKVnQ3AgYIAQEDCXyOBwEB?= X-IronPort-AV: E=Sophos;i="5.73,380,1583193600"; d="scan'208,217";a="476775181" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 May 2020 14:38:44 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 04BEciJE026569 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 May 2020 14:38:44 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 May 2020 09:38:44 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 May 2020 10:38:43 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 11 May 2020 09:38:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BXxhKhdmw62ioX/EK26LAsHLjzTm1qTrFfnTkHnNIb53evJ/JqBZFCc2RgQYMDtyhj+A8wTyMd5NItr84pUT6MM/5ebUil5MiFJgwheneCj17uQY4Z2zSsHvpmW0kPSP2HkUpXTdQnue7fKQMp03K6vo54waoZkQ/eHcNNRu0EFqRYhYyjGIZn6G6xku4jmkpal3ZgnJ+JrT1qeHyyK2j5S3wQrH884xPKipVp0iS0i8+pKYiQVhFacCviefmFzlSf7SK+dpDOHGIuBh5X6b1P4Ya+qHFM8QIk4lqS6Fk9JVXwakHKVu8VSxRSD28r/jenml1JIokF+TpE5zffcr9g== 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=Yks6zWrQhfy7Mp0cdZOFVCILQ0X/u4A/j3W8ALuj6lY=; b=Zc+VcUqABTBEv98YZc3lV0Faz2ZgLqwftxVvu31AodbGVn54CrZyEyYTmOBverZDqhSuFKX5gaBDCRY5mcJVIyDS/8rKukNl9LUfGwJGGo7EP3wOutZ22t0hLw8w2QZl2cpXXsyyfJ08MriC7JchLbjIOmVn8OpT0QR2nkkfb4ET6YZIU50bjTwctyBO+O3L7GPWIoesTghl5WVT7w81/IQOKS2kMN1jXGQTTsRdODdIUH2CVLjjD88AcLQ5m5NVu0Wc5CygXnSBioy5z4Nb0UWX04MZCu/oNy6e4PQOe3PpZbAGW/7yfYpzWO7wPtuZ/LQXtKKx9mC9wuo6TgdZ8Q== 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=Yks6zWrQhfy7Mp0cdZOFVCILQ0X/u4A/j3W8ALuj6lY=; b=byZU0dVgjJWgUZcCKur1d+ABM8gJi6ZFt5jSbcCV19VaAehto9ihyJWBKt9rS9xup83p+j7yKwTd4BmzJ3DVLD+Ri4P8kY20P5Eg+xIFydtxzABvIV61Cz97Jgew1CRNOJ0HM7H6UEXchvLBFU0w/3qAKiM5fvqd+dV7FEf5G6A= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4254.namprd11.prod.outlook.com (2603:10b6:208:18f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Mon, 11 May 2020 14:38:41 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2979.033; Mon, 11 May 2020 14:38:41 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMegAacV3A= Date: Mon, 11 May 2020 14:38:14 +0000 Deferred-Delivery: Mon, 11 May 2020 14:37:55 +0000 Message-ID: References: In-Reply-To: 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-originating-ip: [2a01:cb1d:4ec:2200:41a1:12a8:8f5a:bbb0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c64baa0e-e034-4bd8-1fd3-08d7f5b90007 x-ms-traffictypediagnostic: MN2PR11MB4254: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04004D94E2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5MwVLH9MGSYGTd3ZWwpbGGbMd3/3YtGhFJnRD/i0J/qF2wo54Scw76EwkoazhgdLJn7EcqCIoFVGSj/b+jn+LmhGNmg/AzOBNfMbmkgmL1UGIkQj4YL1aMHWYlSN3R2WmyLbncPAKjV+xXWbM7OjofrNW3uCd+QPupXqQWw/zQmWIQhgkK3Q60AYid+TmlXPgkvKoEjrZLZlNBM7gQ4W45iupWCxVpEKo81MED2JhmshRRJSFEgdr6dLybCY0/jCtIg4ddX4aCVbAKXHssDd1uoJh7TDTi4ENpvcFeo+noR4z6RYP5LL+zcsa70VUeaa4jc/eVHiDiNFQaaaBls2PUZXTgnu5ua/OalXxF7KkZXWbxJCidvIUP08DRrbsqfJPtvN56RK3ceuMnf5JsI3KBh6pPdrhxNtuPc1kedLcZTnyr3hqhBkYPLivjmgIWosh8vMm4yQ2IgprT/O/L33ApSbXXpuvKjhH6auJMNFdTXmOXPwRHf/TIsnoIjqW9ScDxHU2p1f55RzWAv9qgpe4w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(366004)(346002)(376002)(33430700001)(53546011)(6506007)(66556008)(64756008)(316002)(7116003)(478600001)(5660300002)(52536014)(8936002)(55016002)(9686003)(2906002)(66946007)(66476007)(86362001)(7696005)(33656002)(33440700001)(66446008)(76116006)(3480700007)(8676002)(6916009)(6666004)(71200400001)(66574014)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Mcc0t4KFeJGhhOCrtzCpci6ZNJYa0xaoWb+KdoavBQZTzbPIYw9MTHEn/k8kBNGooSYC0uHjsJr4lFpBIrocYDx9k96kvYSrF1gqGZiFi4RONug0e+ooZbWjRrLB2nKlEe1jWDdxp3+rfi8fCt3ODdosRpxaZjzgYSuJJ3CMfO+0ZYhQtUws4pxVZYHbQs+TtVn68qCzFrg8SB2cYcCE6vlzfmR8E7krDWSDnGZyqQqIAurqpQ714+7bIpER+GlF0yfIx2MxCSleU57RrX2HCJCBCz9utbXV1OqxW2mScfTcF/vn0ecj/VKRiS1+4B0a4hoqTqUXW3UX7LISXyQy6zksqtoKaSMqtDh+KtKj3N5SSKf7qxC0TC3fa0r3C4ZazexULu2J3OW8GTaaY5zlf5xsdGy3qd/22cqN2VjB+aN3hbS5rnpZZ5J26Car4LRRTztIM2Qwa6huuzzdF+lyeevUVq+uZyaOubi2MFtnF+EnjNse4h8VL7+cK8AEQeTCEnMOmC6SoguEJHJEMN/velx4FHMpqCFHVE1fl4mFbN5iuEJyR3jMRfabLWonZR2y x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565DEA642FD973CD5A52E4ED8A10MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c64baa0e-e034-4bd8-1fd3-08d7f5b90007 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 14:38:41.2627 (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: W6h1tVXaWDaQo/xuYMVTLZZ6LrHh8Mv9BH0UZzKWhqY+R+D5yvPl+DEzMoKYmbw2JH755lDlQh4yw0Pb+OckBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4254 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Roll] capability handling 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, 11 May 2020 14:39:29 -0000 --_000_MN2PR11MB3565DEA642FD973CD5A52E4ED8A10MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul Sorry for being late on this: There are different things we may want to convey: - local/global: indicates whether to forward the bit. Local is a parent pro= perty, Global is a DODAG property. It boils down to your "copy" action so t= o your point we do not need both the G and the copy bits. Note that RPL als= o uses the term "propagate", and I tend to prefer using it again here rathe= r than copy. Then there's the things we define for the configuration which may also appl= y to capabilities: - critical/elective: indicates what to do when the capability is not known;= Ignore this capability vs. drop the message - router/leaf: I'm wondering if we have a case where the node should become= a leaf if there's a capability it does not understand. That would be anoth= er bit. Does that help? Pascal From: Roll On Behalf Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] capability handling << sorry my last mail was sent incomplete>> Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: Do we need an explicit 'G' flag? We already have a flag (C-copy) whi= ch indicates that nodes have to copy the cap if they don't understand the c= ap. A global capability from the root can be advertised with this bit set. = Nodes understanding this cap will anyways know how to handle and nodes not = understanding it will copy it based on the 'C' flag. Thus not requiring ano= ther 'G' flag. Best, Rahul ________________________________ From: Rahul Jadhav Sent: 07 May 2020 05:28 PM To: Routing Over Low power and Lossy networks > Subject: capability handling Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: --_000_MN2PR11MB3565DEA642FD973CD5A52E4ED8A10MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rahul

 

Sorry for being late on this:

 

There are different things we may want to convey:=

- local/global: indicates whether to forward the bit. Local = is a parent property, Global is a DODAG property. It boils down to your = 220;copy” action so to your point we do not need both the G and the copy bits. Note that RPL also uses the term “prop= agate”, and I tend to prefer using it again here rather than copy.

 

Then there’s the things we define for the configuratio= n which may also apply to capabilities:

- critical/elective: indicates what to do when the capabilit= y is not known; Ignore this capability vs. drop the message

- router/leaf: I’m wondering if we have a case where t= he node should become a leaf if there’s a capability it does not unde= rstand. That would be another bit.

 

Does that help?

 

Pascal

 

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37=
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] capabili= ty handling

 

<< sorry my last mail was sent inco= mplete>>

 <= /p>

Hello All,

We would like to solicit some feedback abo= ut two points in context to capabilities:

1. Capability Instances: Currently the doc= ument instantiates two capabilities viz,
       = a) Capability Indicators (which can be used to carry flags such as support= of 6LoRH)
       = b) Routing Resource capability which indicates total RIB capacity the node= has. This should be useful for DAO Projection.
       = Do you think we should add Neighbor Cache capacity indication as well and = what would be the use-case?

2. Regarding the use of 'G' (global) flag = on per capability basis:

       Do we need an = explicit 'G' flag? We already have a flag (C-copy) which indicates that nodes have to copy the cap if they don't understand the cap. A global capa= bility from the root can be advertised with this bit set. Nodes understandi= ng this cap will anyways know how to handle and nodes not understanding it = will copy it based on the 'C' flag. Thus not requiring another 'G' flag.<= /font>

 <= /p>

= Best,

= Rahul

From:= Rahul Jadhav<= br> Sent: 07 May 2020 05:28 PM To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: capability handling=

 

Hello All,

We would like to solicit some feedback about two points in context to capab= ilities:

1. Capability Instances: Currently the document instantiates two capabiliti= es viz,
        a) Capability Indicators (which = can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability w= hich indicates total RIB capacity the node has. This should be useful for D= AO Projection.
        Do you think we should add Neigh= bor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:

       

--_000_MN2PR11MB3565DEA642FD973CD5A52E4ED8A10MN2PR11MB3565namp_-- From nobody Mon May 11 18:09:29 2020 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 7B1803A0C0C for ; Mon, 11 May 2020 18:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 6Dkq5wOK31cP for ; Mon, 11 May 2020 18:09:25 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255091.outbound.protection.outlook.com [40.92.255.91]) (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 B29EF3A0C0F for ; Mon, 11 May 2020 18:09:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SnaWzcjeXnB8zPWvPoo2U5vj6vO1AAsSu231UaV0IW0cDMHgM9MziQiKIkGEdNDhu0GH4qAm1yNc0bf4qohaZnPc3dZYWYX17WQkYMikZQTVDevuS0vwmj8xRHuE2oV8YtDDC/yChlKRee4U9ai/AFHhY7N+kDxtCN0jxR2YrHYhp+tqIxxAyr8/rJHLHe/TMLZWv47Z82ns1/OkVc00ZzX2HiFvHXRcV0+6oM/X67WQGBbfDRz7tbLMQDKa7osR88WEKMEGzsn92vszeZlgtPYBrqlB0Fxw5SwhXRFZAB7M7NFm3/s0KeHWMhivL8BhPmhw80i4nlx0+zG2NbIFJg== 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=kiRHlweXy2zzaQ00kxScmUlk0vBSP7C/8uf0p4KRReY=; b=oVefVUOxPwDaU/S8zrW1fyiYni4Kljvvkc36Sc33HLMDCeB61QikjeBcnBXyyVyl3hmRCiNfglHNc7ugpQ37U8QFCWneBFgMGh/0EBS7ceziaO4CS9PixWwyV6YDiW9XT1EpNPpPqV4/QSC0UlpXxGWVacCc0S1z/5Yz+vj4k/q8xQmNcj/QWMkXHQezf/NbuWZHTzgHXUB+Uiv85cor+a3RHuDPB2ed2fkvBCVl+53vrYT3zOZXBpBWrdDKCj64mFqdmkvuKw6oghHc0KQtRrILfbMjxBgtCCPpWqTIaW+PcGdMa83a3GOBHOR9dw/QjCO7NiWvzg9jQKLnkNFMuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kiRHlweXy2zzaQ00kxScmUlk0vBSP7C/8uf0p4KRReY=; b=jDkfliDNcuLYilHfYIa5I9iXf9LMeeBy+hDGv4j2xVPoDBbuQRpGSzDiZlGhpFn4T2SAtU2UbhLM6RJkwXZO5+w1tokgX6PvNz8UBIciH1Y0yF8Z53u2Nj84jNUymFFwkTXQ9bkWmFk7qnvuo/tS9FDBw1yM6ocL7MAoHlvpePzzjYVrVVLZY/zadunLxrACnXSIGHeHdkb6TaTHUTzAVaENHW8bRHjneXbslqFcOxEj0V0GVP6xvIh/r///DwN3fP2AU6CjuUYfUHNBrVqP70gcHmqeOt2SzwNgdAoPrT690PPizz+Sq3PNV1qp/DSDDpoy81w0AwUpWE537XZ61Q== Received: from SG2APC01FT015.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::44) by SG2APC01HT198.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::284) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Tue, 12 May 2020 01:09:15 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.250.54) by SG2APC01FT015.mail.protection.outlook.com (10.152.250.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Tue, 12 May 2020 01:09:15 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 01:09:14 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMegAacV3CAAK+i/g== Date: Tue, 12 May 2020 01:09:14 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:77EE0130ADD0CEFEA1D1A525DE57394693C4547A809D8ACD51CBC110E71ADCE4; UpperCasedChecksum:19806E335776A3139EB462B34094FC4DF51E653B323B4925D74F81B7DDB7701B; SizeAsReceived:7014; Count:44 x-tmn: [K0/HGN/AL3QMEH/6AyFPfP2W3uWXYUEa] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 8616d3fe-9013-47dc-5b7a-08d7f6111679 x-ms-traffictypediagnostic: SG2APC01HT198: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Sq0bGfN4RYvikSZEaydXfY/KVaUOhNhMXAc2i/Kp21hbep0O5jkyhE/UQaOwRuUoEDWrfEjumT1ghChyrAlZ4z7eFa+cTIg5SOjRjadHt8aGuhXOq5M3GNsjDRhU2hUIwK2/rO4/MtfWq/HuUjHhKoChxF9h6cGEKC2gMrbKDmr+AR/Y0KM4hyV3ZHXZt03EhPUBkMj5ZohoVr+Lvbb3Zg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: P5tVuqplNidzErPJdtXIHNsnI67FiSjxPFBHalCstFNIB0+yeXxBwf5uLihqtJa0LO3zNz6E+gCqfSFwQw08qo4W7ecnOcBv/jDdaTVuQA3dK2PPhSyZZYMfgifEP1z/2NKEB582bYEZDymEuhw9uQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402072594AE73E644D725459A9BE0BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 8616d3fe-9013-47dc-5b7a-08d7f6111679 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 01:09:14.7014 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT198 Archived-At: Subject: Re: [Roll] capability handling 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, 12 May 2020 01:09:27 -0000 --_000_BM1PR01MB402072594AE73E644D725459A9BE0BM1PR01MB4020INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Pascal for the feedback. Please find [RJ] inline below. ________________________________ From: Roll on behalf of Pascal Thubert (pthubert) <= pthubert=3D40cisco.com@dmarc.ietf.org> Sent: 11 May 2020 10:38 PM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] capability handling Hello Rahul Sorry for being late on this: There are different things we may want to convey: - local/global: indicates whether to forward the bit. Local is a parent pro= perty, Global is a DODAG property. It boils down to your =93copy=94 action = so to your point we do not need both the G and the copy bits. Note that RPL= also uses the term =93propagate=94, and I tend to prefer using it again he= re rather than copy. [RJ] So it seems we are aligned. I will remove the 'G' flag in the next rev= . Also will change the term to propagate (aligning with 6550). Then there=92s the things we define for the configuration which may also ap= ply to capabilities: - critical/elective: indicates what to do when the capability is not known;= Ignore this capability vs. drop the message - router/leaf: I=92m wondering if we have a case where the node should beco= me a leaf if there=92s a capability it does not understand. That would be a= nother bit. [RJ] We already have provisions for router/leaf. 'J' (join as "leaf only" i= f cap not understood) and 'C' (copy) flag handle this. Regarding the critic= al/elective bit, I guess we do not have a way for a node to drop a message.= So you are saying, there should be a way for a node to drop the message if= it does not understand it and still be part of the network as a 6LR? Does that help? [RJ] Thanks, it does help greatly. From: Roll On Behalf Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] capability handling << sorry my last mail was sent incomplete>> Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: Do we need an explicit 'G' flag? We already have a flag (C-copy) whi= ch indicates that nodes have to copy the cap if they don't understand the c= ap. A global capability from the root can be advertised with this bit set. = Nodes understanding this cap will anyways know how to handle and nodes not = understanding it will copy it based on the 'C' flag. Thus not requiring ano= ther 'G' flag. Best, Rahul ________________________________ From: Rahul Jadhav Sent: 07 May 2020 05:28 PM To: Routing Over Low power and Lossy networks > Subject: capability handling Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: --_000_BM1PR01MB402072594AE73E644D725459A9BE0BM1PR01MB4020INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks Pascal for the feedback. Please find [RJ] inline below.

From: Roll <roll-bounces= @ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco= .com@dmarc.ietf.org>
Sent: 11 May 2020 10:38 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] capability handling
 

Hello Ra= hul

 

Sorry fo= r being late on this:

 

There ar= e different things we may want to convey:

- local/= global: indicates whether to forward the bit. Local is a parent property, G= lobal is a DODAG property. It boils down to your =93copy=94 action so to yo= ur point we do not need both the G and the copy bits. Note that RPL also uses the term =93propagate=94, and I tend to= prefer using it again here rather than copy.


[RJ] So = it seems we are aligned. I will remove the 'G' flag in the next rev. Also w= ill change the term to propagate (aligning with 6550).

 

Then the= re=92s the things we define for the configuration which may also apply to c= apabilities:

- critic= al/elective: indicates what to do when the capability is not known; Ignore = this capability vs. drop the message

- router= /leaf: I=92m wondering if we have a case where the node should become a lea= f if there=92s a capability it does not understand. That would be another b= it.


[RJ] We = already have provisions for router/leaf. 'J' (join as "leaf only"= if cap not understood) and 'C' (copy) flag handle this. Regarding the crit= ical/elective bit, I guess we do not have a way for a node to drop a message. So you are saying, there should be a way for= a node to drop the message if it does not understand it and still be part = of the network as a 6LR?

 

Does tha= t help?


[RJ] Tha= nks, it does help greatly.

 

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37=
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] capabili= ty handling

 

<< sorry my last mail was sent incomplete>>

 

Hello All,

We would like to solicit some feedback abo= ut two points in context to capabilities:

1. Capability Instances: Currently the doc= ument instantiates two capabilities viz,
       = a) Capability Indicators (which can be used to carry flags such as support= of 6LoRH)
       = b) Routing Resource capability which indicates total RIB capacity the node= has. This should be useful for DAO Projection.
       = Do you think we should add Neighbor Cache capacity indication as well and = what would be the use-case?

2. Regarding the use of 'G' (global) flag = on per capability basis:

       Do we need an explicit 'G' flag? W= e already have a flag (C-copy) which indicates that nodes have to copy the cap if they don't understand the cap. A global capability from the roo= t can be advertised with this bit set. Nodes understanding this cap will an= yways know how to handle and nodes not understanding it will copy it based = on the 'C' flag. Thus not requiring another 'G' flag.

 

Best,

Rahul

From: Rahul Jadhav
Sent: 07 May 2020 05:28 PM To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: capability handling=

 

Hello Al= l,

We would like to solicit some feedback about two points in context to capab= ilities:

1. Capability Instances: Currently the document instantiates two capabiliti= es viz,
        a) Capability Indicators (which = can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability w= hich indicates total RIB capacity the node has. This should be useful for D= AO Projection.
        Do you think we should add Neigh= bor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:

       

--_000_BM1PR01MB402072594AE73E644D725459A9BE0BM1PR01MB4020INDP_-- From nobody Tue May 12 05:54:20 2020 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 2FCEA3A08B9 for ; Tue, 12 May 2020 05:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=b6XbXBiW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T0QYozV4 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 jlCrKllQ6lNO for ; Tue, 12 May 2020 05:54:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6231F3A0899 for ; Tue, 12 May 2020 05:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22308; q=dns/txt; s=iport; t=1589288055; x=1590497655; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3ujA8WSJFUT+MpcC8pJwEkk87+F/4RaaNHbsptEv0jo=; b=b6XbXBiW7xJxBhiBia2RV+Ns4ajggZC4+s7gbb4B7ppkxIhO+LGHWUL/ K690MMQ6V2pzFg3xDRKnfohAdxbLyAlw/shORWd+JLt8/SHo67tWflNFu 8BdCjQcMNa0LV2RlmPLv0XbcXlRISpNXbA2SDK52Txq2vk9hCPlzvFVTf w=; IronPort-PHdr: =?us-ascii?q?9a23=3AU67LlBFOphDgtzs3H10Qs51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QWbXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiDwDGm7pe/4MNJK1mHgEBCxIMQIJ?= =?us-ascii?q?sAS5RBW9YLywKh2ADizKCEZg3glIDVAsBAQEMAQEtAgQBAYREAoIFJDgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQUEbYVWDIVxAQEBAQIBEhsTAQE4BAsCAQgRBAEBIQcHMhQ?= =?us-ascii?q?JCAIEEwgagwWBfk0DDiABA6RPAoE5iGF0gTSDAQEBBYU3GIIOCYE4gmOCSYc?= =?us-ascii?q?YGoFBP4FUgk0+gmcEgUEBAQIgNIMRgi2ORokqmn8KgkqYRYJciGeRd45RnnY?= =?us-ascii?q?CBAIEBQIOAQEFgWkigVZwFYMkUBgNkECDcopWdDcCBggBAQMJfIx3AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,383,1583193600"; d="scan'208,217";a="769420576" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 May 2020 12:54:14 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04CCsE5A010893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 May 2020 12:54:14 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 07:54:14 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 07:54:13 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 12 May 2020 08:54:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xlbh8WSdlql5gZfteC8QHFXCRsvDXAPy21aQzCg47RwPAo/Cf22XgCHndIIPiLjBA8Qp6JkaX98cbeGJcfNRcgCwphFSpMNYpX0I9MZaHrnE/qZuC8+JNa8dkiHYpPaliXLVFcY5EN/1XQ4Jcj6Ig4/uBzTtSePTZAj84dRe2/2GFBl18P8ijveufREpO/g5hmeW/MFm0tb1/TDVzUw0x8ABaPkR5FUKjk6pt/aE6ROPzJGf2hx8605dckQR3hlGTYrbH1hhWvZJkzxIsWof2zhVefOHBqKoZ/xjdG/DmQ54+/n5enM5ZT7NXx/fs7Om6yb2Xx/HFG7XBuAg/7nrUg== 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=c2ul1Nk3Tz9/lng6TQXv/Zt6uRO+LuLqoxAJq7dG4GI=; b=HtsjbB56QH1QNwwgbXtwF/QDylLzXw+04x4WlmRNk0y4jQtFYH+XXub2HQ50sy4LE1okrD7nru6Mh0J8yLvrhpXjGPlFoXg3B+HsEwp9rqotxkOx2q9kFYfsOh/tMKnrYNUvTrHMVFMW7cs4h3gdn838fqRgHPrNVsZdfMeEF8mosizsXHkjcpV1uUOE28m6qehHx2lIYAmp23ACET+GkNEObZ+g/m5s9lU8XHb5dXQw29+PO9RL4tb0gQmYs4tYCgF1s97hJ7TnO7vcF/2vLdDVfAFhRuT31uYBAlV3Ts5cWW/WQ1ODkMhGhfBE5m6hwVqincaDY0go4Qyyzqhivw== 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=c2ul1Nk3Tz9/lng6TQXv/Zt6uRO+LuLqoxAJq7dG4GI=; b=T0QYozV4phbi0B5YZRLMxRgJLbKqVsbsJ46CpbiTE0sJxM9/I1X8FhDAxd1svFOkfbRwDEnUh+V6nuGKNXBoMkg5CqbqYWClXFt7tCgX8m1GvI1G4Yu4jUeCHnOXwrop2ZXN4l+CVwPV0yVz/qdqQ2YGpSVF+ifMIVQNgiVtMLI= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4519.namprd11.prod.outlook.com (2603:10b6:208:26c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Tue, 12 May 2020 12:54:11 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 12:54:11 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMegAacV3CAAK+i/oAAxnYQ Date: Tue, 12 May 2020 12:54:10 +0000 Deferred-Delivery: Tue, 12 May 2020 12:53:37 +0000 Message-ID: References: , In-Reply-To: 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-originating-ip: [90.116.245.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8be0fc61-c06f-4033-072c-08d7f673912a x-ms-traffictypediagnostic: MN2PR11MB4519: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0401647B7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LbbW/B4ArBv615bnliwK3gPNL6zBBATiIwBGLSh/U9CXT+rk8tKSQiA8qD67FVOZRVHndpK6RMWfRNCAHU0BdnX1Zpy+OY+I96ogTk8m5B0ByzDuNrBgd9NyS3FFp+yUhmaXuHmycNxWe6ENsQ8X8HeEUMRDJYbxxs5N0/Vf05drE3laozHrRPxkfoR43Hw7SihTjLQCGyUKU3FAaG67LSZKdKGG/IigAyzppZSx5T+FnnSD0+RSFmomPxOwV3U/M/bog1qsQrPVfA+CRyPI+7T9Qdd6JOV7VAxHZnAUAaZyWW82KfsJpz3P4t/YnRfxcaJdJGjRqipR/swIhGZ0Qlso72xCuJL5SWkwnISF+5DDz33EwVMCd+ZAccuVrq3cOxMh0bs8x4sEBgvq64QTa0tCm6h7edcOiaiVE3vtX2Stcl9zDSba9d3xMXXSIhyDOPCtyEVYqLIzd4GWAdFFgQ/CbqtVfdt668ykAF7ODWHZ0cTXdpH95HM9DfZLxPKYrakfa45iJ8ohjrfGHd9t0w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(33430700001)(7116003)(5660300002)(55016002)(33440700001)(9686003)(316002)(7696005)(53546011)(6506007)(26005)(186003)(6916009)(71200400001)(8676002)(52536014)(76116006)(2906002)(8936002)(66476007)(64756008)(66574014)(3480700007)(66446008)(66946007)(33656002)(478600001)(86362001)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: i08W/8ZsaoyVsyPFyYjfY6N7tvURbOab2uhFV4FjsftzYHKCUuxg0F//8WeDzQgiX+Vqgh6orbDKUruTdxfUh4jZ7m463GYmiHzulMR79XPpzvbYG92DYrw9aUc9DCWHsRmHUHHleMWJ8C0Kphk8dKvnaRcrmyMxKvo1s/bhnSSq2cIVYsZ91ah5QrtdTkgq3gQOm4y7TIp6rGlz/abLG5KjHQaj7puwbeUzNHtcLvpkHFku/ekILKHs/2sdsyeYSl/oFLHZLsg9btTpuWpfd9JQnaUZcVPFGQfx426ghC12XWdrmVPicJiDyxWdUg+mH8xkG2gZ/xqNNDeqO+txnvkv90Awupr9KIcEYY1TgTH2rTfpVDY8DQB+mnB7U8gLdJqUP3SuxSjuy1vXzM9MM10AUsHEcv25q/fZ7UXg3WGXyrQWk4WvP+Ohq0Q7o/hDGb5hy8pwcP/ZesZMHgNWp7gKBpGc2/I81M1KAap2gPKzruKMzkmI26VXOuh21siL x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35655600585A20BB9F802BF9D8BE0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8be0fc61-c06f-4033-072c-08d7f673912a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 12:54:11.2887 (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: NUG5zd4YzyegZsyrT+JPQ2762TB5eiGWFIiJy+1pEIHecQCuFlR5fvW3hfU8RGCIELVmFyEbNh1xd7Gdt6Xb1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4519 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Roll] capability handling 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, 12 May 2020 12:54:18 -0000 --_000_MN2PR11MB35655600585A20BB9F802BF9D8BE0MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul > Regarding the critical/elective bit, I guess we do not have a way for a n= ode to drop a message. So you are saying, there should be a way for a node = to drop the message if it does not understand it and still be part of the n= etwork as a 6LR? I do not have an example but say a DIO requires something that a node does = not understand, and that prevents operation even as a leaf, then we need th= at bit. The problem is that we need to design the infra now - before it is = needed - so we need to cover all cases. Take care, Pascal From: Roll On Behalf Of Rahul Jadhav Sent: mardi 12 mai 2020 03:09 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] capability handling Thanks Pascal for the feedback. Please find [RJ] inline below. ________________________________ From: Roll > on behalf = of Pascal Thubert (pthubert) > Sent: 11 May 2020 10:38 PM To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] capability handling Hello Rahul Sorry for being late on this: There are different things we may want to convey: - local/global: indicates whether to forward the bit. Local is a parent pro= perty, Global is a DODAG property. It boils down to your "copy" action so t= o your point we do not need both the G and the copy bits. Note that RPL als= o uses the term "propagate", and I tend to prefer using it again here rathe= r than copy. [RJ] So it seems we are aligned. I will remove the 'G' flag in the next rev= . Also will change the term to propagate (aligning with 6550). Then there's the things we define for the configuration which may also appl= y to capabilities: - critical/elective: indicates what to do when the capability is not known;= Ignore this capability vs. drop the message - router/leaf: I'm wondering if we have a case where the node should become= a leaf if there's a capability it does not understand. That would be anoth= er bit. [RJ] We already have provisions for router/leaf. 'J' (join as "leaf only" i= f cap not understood) and 'C' (copy) flag handle this. Regarding the critic= al/elective bit, I guess we do not have a way for a node to drop a message.= So you are saying, there should be a way for a node to drop the message if= it does not understand it and still be part of the network as a 6LR? Does that help? [RJ] Thanks, it does help greatly. From: Roll > On Behalf = Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] capability handling << sorry my last mail was sent incomplete>> Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: Do we need an explicit 'G' flag? We already have a flag (C-copy) whi= ch indicates that nodes have to copy the cap if they don't understand the c= ap. A global capability from the root can be advertised with this bit set. = Nodes understanding this cap will anyways know how to handle and nodes not = understanding it will copy it based on the 'C' flag. Thus not requiring ano= ther 'G' flag. Best, Rahul ________________________________ From: Rahul Jadhav Sent: 07 May 2020 05:28 PM To: Routing Over Low power and Lossy networks > Subject: capability handling Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: --_000_MN2PR11MB35655600585A20BB9F802BF9D8BE0MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rahul

 

> Regarding t= he critical/elective bit, I guess we do not have a way for a node to drop a= message. So you are saying, there should be a way for a node to drop the m= essage if it does not understand it and still be part of the network as a 6LR?

 

I do not have an example but say a DIO requires something th= at a node does not understand, and that prevents operation even as a leaf, = then we need that bit. The problem is that we need to design the infra now - before it is needed - so we need to cove= r all cases.

 

Take care,

 

Pascal

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Rahul Jadhav Sent: mardi 12 mai 2020 03:0= 9
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] capabili= ty handling

 

Thanks Pascal for the feedback. = Please find [RJ] inline below.

 <= /p>

From:= Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco..com@dmarc.ietf= .org>
Sent: 11 May 2020 10:38 PM To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: Re: [Roll] capabili= ty handling

 

Hello Rahul

 

Sorry for being late on this:

 

There are different things we may want to convey:

- local/global: indicates whether to forward the bit. Local= is a parent property, Global is a DODAG property. It boils down to your &#= 8220;copy” action so to your point we do not need both the G and the copy bits. Note that RPL also uses the term “prop= agate”, and I tend to prefer using it again here rather than copy.

 

[RJ] So it seems we are aligned. I will remove the 'G' flag= in the next rev. Also will change the term to propagate (aligning with 655= 0).

 

Then there’s the things we define for the configurati= on which may also apply to capabilities:

- critical/elective: indicates what to do when the capabili= ty is not known; Ignore this capability vs. drop the message

- router/leaf: I’m wondering if we have a case where = the node should become a leaf if there’s a capability it does not und= erstand. That would be another bit.

 

[RJ] We already have provisions for router/leaf. 'J' (join = as "leaf only" if cap not understood) and 'C' (copy) flag handle = this. Regarding the critical/elective bit, I guess we do not have a way for a node to drop a message. So you are saying, ther= e should be a way for a node to drop the message if it does not understand = it and still be part of the network as a 6LR?

 

Does that help?

 

[RJ] Thanks, it does help greatly.=

 

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37=
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] capabili= ty handling

 

<< sorry my last mail was sent inc= omplete>>

<= span style=3D"font-size:12.0pt;color:black"> =

Hello All,

We would like to solicit some feedback abo= ut two points in context to capabilities:

1. Capability Instances: Currently the doc= ument instantiates two capabilities viz,
       = a) Capability Indicators (which can be used to carry flags such as support= of 6LoRH)
       = b) Routing Resource capability which indicates total RIB capacity the node= has. This should be useful for DAO Projection.
       = Do you think we should add Neighbor Cache capacity indication as well and = what would be the use-case?

2. Regarding the use of 'G' (global) flag = on per capability basis:

       Do we need an= explicit 'G' flag? We already have a flag (C-copy) which indicates that nodes have to copy the cap if they don't understand the cap. A global capa= bility from the root can be advertised with this bit set. Nodes understandi= ng this cap will anyways know how to handle and nodes not understanding it = will copy it based on the 'C' flag. Thus not requiring another 'G' flag.

<= span style=3D"font-size:12.0pt;color:black"> =

Best,

Rahul

From: Rahul Jadhav=
Sent: 07 May 2020 05:28 PM To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: capability handling=

 

Hello All,

We would like to solicit some feedback about two points in context to capab= ilities:

1. Capability Instances: Currently the document instantiates two capabiliti= es viz,
        a) Capability Indicators (which = can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability w= hich indicates total RIB capacity the node has. This should be useful for D= AO Projection.
        Do you think we should add Neigh= bor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:

       

--_000_MN2PR11MB35655600585A20BB9F802BF9D8BE0MN2PR11MB3565namp_-- From nobody Tue May 12 06:06:47 2020 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 57CE33A092A for ; Tue, 12 May 2020 06:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 F__SgdGMpRPu for ; Tue, 12 May 2020 06:06:41 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253079.outbound.protection.outlook.com [40.92.253.79]) (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 8B9583A0407 for ; Tue, 12 May 2020 06:06:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jaeJ1vJmwcL1AcSP4RNtAjr63ngsmogWo8RThnIGcVAHDOyFUtuEeYM5bE5U9llu2h8Hdr7XUGHkptxlEn3SjMjNxz3AC3ixhKyz4Zhkgf+ZGkEbzgINiUpnID7cv25x9Sn4+6KqWzvwAxHFnEcC6PM9mGwLObI5Yksia+2zQEPigdCVpSBYy+OCz9z1lx9R8hXwMRAjhK3+Z49aR+qxh3duW+8j1Wt2AWvAFE3TI68fz8fwCC6RU26j0UGRDv2cQnOmM//krtji3k/l3ATYy4vqdqQq+vTTV+myl1TDCb4mRZhuZxy7/0Z8ixZwZgUPMwQNpizHlD/QJzDIL0KLuw== 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=HRJDOvSuTy6wN3PlTOcjT41dXlil2Rz/1gdZL30eh44=; b=CMxKQgdDz0mwcfzpWdQeEdUGtHB4X+5NutXejmMhvF2Qsk9aCZxpFK6x4QK2qPOyc2JoO+uGoDVhebd4gSNt0yXR260SGHhCGw+sHfAnakdAKMs208CDDvPsCyV6tKlJmh+OkrypKF+vC7uK5VKeqrTi+4BQragsNXpV7FNfIINNOv40s8xftZXuAIcn4eCWMXHPKEqzXcz419UiHbH7R1yci3TboUCkeOCVC5j/CYaQ6+Qk+bvYlC6fCwZRVNijpCiGSrzcDVcRjJ5fXZgR5wWWOpFL2LNoz1ZWFsEH+6c+1iRK2aU4e1FpTWswitPGZmGDrX4GO8Q+Nn2LEDUjEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HRJDOvSuTy6wN3PlTOcjT41dXlil2Rz/1gdZL30eh44=; b=U9O3sW66ibJ30tQEax2Le/xIim5wFOc+rYgsbU1H+wlgffDwZ06/vkVGHjNtPjOxbjiQlU6+Qrtsg+KPCgR37mTaJJ7QeiGPLTQDYZg34PNTIoFUOJPo9NUpAtquu7Ix755xxWcvftZtiXZlhCVk0neubbwRGeSYpTujIZz0PNaJ3mnqBwGqd4Zgv4Rp5vEKQusGnOlTqv6IEtIPJWqPDUXqeDAIiv5XIjgWxNNiYsgzT6fcMd+8dPeGvF2119K5tcuMtxRoLuFU3hlOEwOrImUiURjTk7Sn30coO0Cp+B0Vw5AP7UPegFZqOHiYKqvW0R6JDOFjb6OAcMMb8tRFPg== Received: from PU1APC01FT046.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::43) by PU1APC01HT069.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::303) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Tue, 12 May 2020 13:06:37 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.56) by PU1APC01FT046.mail.protection.outlook.com (10.152.253.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Tue, 12 May 2020 13:06:37 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 13:06:37 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: capability handling Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMegAacV3CAAK+i/oAAxnYQgAAEXc4= Date: Tue, 12 May 2020 13:06:37 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:651BE267418B0E62608D73FF3E57915D86246B38A1D5FC89BFC34A2B55B7ED36; UpperCasedChecksum:5ED60CD4A5177962D4E63B050AE8E02EB79B5EBF077CC819350FD5F35E1BA5B2; SizeAsReceived:7192; Count:44 x-tmn: [DuCAj++gGaWsWqD9vQIHzNWftjdSmFwZ] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 50212c67-dafd-48c8-bed1-08d7f6754dad x-ms-traffictypediagnostic: PU1APC01HT069: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HVBhwA04INBn2a3VFNYeBu45Mv6gvJmD2PwEicLHhvuTZaZkc6rMOwscm8Zus1qKpbyfTW1Wu2yH0Jrql+vTtDXrkNB4G80QOAzxgNHuWnbPfKxJi52meiImxEcJq8QvrKiwa1EIMG4BBkY/Jb5VEiUP8siK0aweFiCmn71YesgkONBRxejW2wts/OFqVs4lE0BHF+G18FhvpCQNjskxrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: PODKPKVFFIq+CIeiaj/iY461LmCzi01YrqlS0r9zQ11zbg2GgOzMDS96/rYP3ODJI5tuoNpbjbtJqc5jgfPRI5/IMfNktdQh9SDLT46KrhESREi8QsuOtnSjyS5yjLVjMjsUNkT/iSsaVHTTR5CTTg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402073B08B9B7A6121A7D8EAA9BE0BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 50212c67-dafd-48c8-bed1-08d7f6754dad X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 13:06:37.0263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT069 Archived-At: Subject: Re: [Roll] capability handling 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, 12 May 2020 13:06:45 -0000 --_000_BM1PR01MB402073B08B9B7A6121A7D8EAA9BE0BM1PR01MB4020INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Regarding the critical/elective bit, I guess we do not have a way for a n= ode to drop a message. So you are saying, there should be a way for a node = to drop the message if it does not understand it and still be part of the n= etwork as a 6LR? I do not have an example but say a DIO requires something that a node does = not understand, and that prevents operation even as a leaf, then we need th= at bit. The problem is that we need to design the infra now - before it is = needed - so we need to cover all cases. [RJ] Sure, we can provision this. I agree that extending this later will be= a pain because of compatibility issues. Anyways the packet cost is just on= e bit. From: Roll On Behalf Of Rahul Jadhav Sent: mardi 12 mai 2020 03:09 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] capability handling Thanks Pascal for the feedback. Please find [RJ] inline below. ________________________________ From: Roll > on behalf = of Pascal Thubert (pthubert) > Sent: 11 May 2020 10:38 PM To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] capability handling Hello Rahul Sorry for being late on this: There are different things we may want to convey: - local/global: indicates whether to forward the bit. Local is a parent pro= perty, Global is a DODAG property. It boils down to your =93copy=94 action = so to your point we do not need both the G and the copy bits. Note that RPL= also uses the term =93propagate=94, and I tend to prefer using it again he= re rather than copy. [RJ] So it seems we are aligned. I will remove the 'G' flag in the next rev= . Also will change the term to propagate (aligning with 6550). Then there=92s the things we define for the configuration which may also ap= ply to capabilities: - critical/elective: indicates what to do when the capability is not known;= Ignore this capability vs. drop the message - router/leaf: I=92m wondering if we have a case where the node should beco= me a leaf if there=92s a capability it does not understand. That would be a= nother bit. [RJ] We already have provisions for router/leaf. 'J' (join as "leaf only" i= f cap not understood) and 'C' (copy) flag handle this. Regarding the critic= al/elective bit, I guess we do not have a way for a node to drop a message.= So you are saying, there should be a way for a node to drop the message if= it does not understand it and still be part of the network as a 6LR? Does that help? [RJ] Thanks, it does help greatly. From: Roll > On Behalf = Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] capability handling << sorry my last mail was sent incomplete>> Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: Do we need an explicit 'G' flag? We already have a flag (C-copy) whi= ch indicates that nodes have to copy the cap if they don't understand the c= ap. A global capability from the root can be advertised with this bit set. = Nodes understanding this cap will anyways know how to handle and nodes not = understanding it will copy it based on the 'C' flag. Thus not requiring ano= ther 'G' flag. Best, Rahul ________________________________ From: Rahul Jadhav Sent: 07 May 2020 05:28 PM To: Routing Over Low power and Lossy networks > Subject: capability handling Hello All, We would like to solicit some feedback about two points in context to capab= ilities: 1. Capability Instances: Currently the document instantiates two capabiliti= es viz, a) Capability Indicators (which can be used to carry flags such as = support of 6LoRH) b) Routing Resource capability which indicates total RIB capacity t= he node has. This should be useful for DAO Projection. Do you think we should add Neighbor Cache capacity indication as we= ll and what would be the use-case? 2. Regarding the use of 'G' (global) flag on per capability basis: --_000_BM1PR01MB402073B08B9B7A6121A7D8EAA9BE0BM1PR01MB4020INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
> Regarding the critical/elective bit, I guess we do not have a way for a node to drop a message. So you are= saying, there should be a way for a node to drop the message if it does no= t understand it and still be part of the network as a 6LR?

 

I do not= have an example but say a DIO requires something that a node does not unde= rstand, and that prevents operation even as a leaf, then we need that bit. = The problem is that we need to design the infra now - before it is needed - so we need to cover all cases.


[RJ] Sur= e, we can provision this. I agree that extending this later will be a pain = because of compatibility issues. Anyways the packet cost is just one bit.&n= bsp;

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav Sent: mardi 12 mai 2020 03:0= 9
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] capabili= ty handling

 

Thanks Pascal for the feedback. Please find [RJ] inlin= e below.

 

From: Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco..com@dmarc.ietf= ..org>
Sent: 11 May 2020 10:38 PM To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: Re: [Roll] capabili= ty handling

 

Hello Ra= hul

 

Sorry fo= r being late on this:

 

There ar= e different things we may want to convey:

- local/= global: indicates whether to forward the bit. Local is a parent property, G= lobal is a DODAG property. It boils down to your =93copy=94 action so to yo= ur point we do not need both the G and the copy bits. Note that RPL also uses the term =93propagate=94, and I tend to= prefer using it again here rather than copy.

 

[RJ] So = it seems we are aligned. I will remove the 'G' flag in the next rev. Also w= ill change the term to propagate (aligning with 6550).

 

Then the= re=92s the things we define for the configuration which may also apply to c= apabilities:

- critic= al/elective: indicates what to do when the capability is not known; Ignore = this capability vs. drop the message

- router= /leaf: I=92m wondering if we have a case where the node should become a lea= f if there=92s a capability it does not understand. That would be another b= it.

 

[RJ] We = already have provisions for router/leaf. 'J' (join as "leaf only"= if cap not understood) and 'C' (copy) flag handle this. Regarding the crit= ical/elective bit, I guess we do not have a way for a node to drop a message. So you are saying, there should be a way for= a node to drop the message if it does not understand it and still be part = of the network as a 6LR?

 

Does tha= t help?

 

[RJ] Tha= nks, it does help greatly.

 

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav Sent: jeudi 7 mai 2020 11:37=
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] capabili= ty handling

 

<< sorry my last mail was sent incomplete>>

 

Hello All,

We would like to solicit some feedback abo= ut two points in context to capabilities:

1. Capability Instances: Currently the doc= ument instantiates two capabilities viz,
       = a) Capability Indicators (which can be used to carry flags such as support= of 6LoRH)
       = b) Routing Resource capability which indicates total RIB capacity the node= has. This should be useful for DAO Projection.
       = Do you think we should add Neighbor Cache capacity indication as well and = what would be the use-case?

2. Regarding the use of 'G' (global) flag = on per capability basis:

       Do we need an explicit 'G' flag? W= e already have a flag (C-copy) which indicates that nodes have to copy the cap if they don't understand the cap. A global capability from the roo= t can be advertised with this bit set. Nodes understanding this cap will an= yways know how to handle and nodes not understanding it will copy it based = on the 'C' flag. Thus not requiring another 'G' flag.

 

Best,

Rahul

From: Rahul Jadhav
Sent: 07 May 2020 05:28 PM To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: capability handling=

 

Hello Al= l,

We would like to solicit some feedback about two points in context to capab= ilities:

1. Capability Instances: Currently the document instantiates two capabiliti= es viz,
        a) Capability Indicators (which = can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability w= hich indicates total RIB capacity the node has. This should be useful for D= AO Projection.
        Do you think we should add Neigh= bor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:

       

--_000_BM1PR01MB402073B08B9B7A6121A7D8EAA9BE0BM1PR01MB4020INDP_-- From nobody Thu May 14 00:20:42 2020 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 0AA973A0366 for ; Thu, 14 May 2020 00:20:40 -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, 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 AQMSgk4Rtw3O for ; Thu, 14 May 2020 00:20:38 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 EABD53A02C1 for ; Thu, 14 May 2020 00:20:37 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id g15so772033uah.5 for ; Thu, 14 May 2020 00:20:37 -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=evUr9v65Yesz1ulTB4nggDcNilubHSko56xjCsdDzLs=; b=MpveMb+zqL/ePX3X/ljaS4vI4Cw+sMPGUZ3UTgPvkbkq1ysblF/0krLhS8YKidWz/g /s+/a0wwGf68hmchpZn6wSLqstiAZpPDAUJ4zl8dqgE1QWTm4u2eeFwD5w4iTmQzPi0Q Zx1kbSWeE8/TGDNAGRxSx0TQS43DOEzvRt4pAc1G7uUVm8lGWl+Mp325n07FSCKz+SPS dfPUhkgfK9Nha3VJ+qtGQ/llyPzisgL+NCfV+bCEVRe9fc8KzAHE+xyKoHvIf4cR8OyK VBlV+9knVKe11FeBNdlvPKdJNcnONn1umnvvy0LZ//Z2/ztlADT3WeumLV0/wWsnNAd3 ZFVQ== 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=evUr9v65Yesz1ulTB4nggDcNilubHSko56xjCsdDzLs=; b=r86KIbJIEoJ8JYsRQbat4N5AIFOp8s0/T+qJgei/eCveoXvcXq8x9i5hncg/Ro2d32 0kd2AY0C0DQ4AqLzQYrRAf7STDJcsU/EL86CY2gfHemsvZlTvQGFLvtbwVX/5dQXK715 kNMuzsKG+WCEiykshs3XnPCyx/+73AqXprXiSvinsn82FooVy3k1WREkMQnvsAXeh4QL tUGSEAwBVGYc9D1ug1O159TjeSdy0UqksW+qp8dBjeBtsGx+8TUXszHtXIRJlhi2kxJv iLsC1X2IYLTjYp6+q8n4dX2SeZf7VSVXe2kzAxKrk4DleA5rAQMif9B4OxTFPGUjfrUs 2H6w== X-Gm-Message-State: AOAM5335LLI1TXp3RK7vPIsuG7WKcwJObC+vXcxhT/RO8Yy1be54ONJm fZNMvb4LatpXDxnq6ETwPyG0o9u8Qi703FFEMwwJ8R+q X-Google-Smtp-Source: ABdhPJyy7adeQuOwCZxizEKrVBBQkf/7QI3D1LZFCFNBUjFQIF1OgeZbh99u1k4o7KfW9iNJ1MEUPZyA6aetoylKBUQ= X-Received: by 2002:ab0:2a88:: with SMTP id h8mr2724317uar.51.1589440836654; Thu, 14 May 2020 00:20:36 -0700 (PDT) MIME-Version: 1.0 References: <158886943764.3475.6047615644810853641@ietfa.amsl.com> In-Reply-To: <158886943764.3475.6047615644810853641@ietfa.amsl.com> From: Ines Robles Date: Thu, 14 May 2020 10:20:00 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000075dbd805a596881c" Archived-At: Subject: [Roll] WG Virtual Meeting: 2020-05-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, 14 May 2020 07:20:40 -0000 --00000000000075dbd805a596881c Content-Type: text/plain; charset="UTF-8" Dear all, Please let us know the topics that you would like to discuss during the meeting by 19th May. So far we have a draft Agenda (topics resulting from the previous (04-29) interim meeting): - New Option and Backward compatibility - Compression for control messages? Applicable for nsa-extension - RPL Observation topics - RPL Ping You can upload the slides here: https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll The link to the video recording will be available here: https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200525 Webex details can be found below. Thank you and have a nice day, Ines and Dominique ---------- Forwarded message --------- From: IESG Secretary Date: Thu, May 7, 2020 at 7:39 PM Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG Virtual Meeting: 2020-05-25 To: IETF-Announce Cc: The Routing Over Low power and Lossy networks (roll) Working Group will hold a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC. Agenda: Draft Agenda: New Option and Backward compatibility Compression for control messages? Applicable for nsa-extension RPL Observation topics RPL Ping Additional Items to be determined Information about remote participation: Roll interim May meeting Hosted by ROLL WG Monday, May 25, 2020 6:45 am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada) Meeting number: 611 684 862 Password: vbR9EnBMs98 https://ietf.webex.com/ietf/j.php?MTID=m59fad4e3500688e160f0d772b9f942ac Join by video system Dial 611684862@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 611 684 862 Meeting Information like link to video recording , etc would be located in https://github.com/roll-wg/ROLL-Interim-Meeting _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --00000000000075dbd805a596881c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please let us know the topics= that you would like to discuss during the meeting by 19th May.
<= br>
So far we have a draft Agenda (topics resulting from the prev= ious (04-29) interim meeting):
  • New Option and Backward compatibility
  • Compression for control messages? Applicable for nsa-extension
  • RPL Observation topics
  • RPL Ping

The link to the video recording will be available h= ere:=C2=A0https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master= /20200525
Webex details can be found below.

Thank you and have a nice day,

Ines and Do= minique


---------- Forwarded message ---------
From: IESG Secretary <iesg-secretary@ietf.org= >
Date: Thu, May 7, 2020 at 7:39 PM
Subject: [Roll] Rou= ting Over Low power and Lossy networks (roll) WG Virtual Meeting: 2020-05-2= 5
To: IETF-Announce <ietf-a= nnounce@ietf.org>
Cc: <roll@= ietf.org>


The Routing Over Low power and Lossy netw= orks (roll) Working Group will hold
a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC.

Agenda:
Draft Agenda:

New Option and Backward compatibility
Compression for control messages? Applicable for nsa-extension
RPL Observation topics
RPL Ping
Additional Items to be determined


Information about remote participation:
Roll interim May meeting Hosted by ROLL WG=C2=A0 Monday, May 25, 2020 6:45 = am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada)
Meeting number: 611 684 862
Password: vbR9EnBMs98

https://ietf.webex.com/iet= f/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f942ac=C2=A0

Join by video system
Dial 61168486= 2@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.=C2=A0
Join by phone 1-650-479-3208
Call-in toll number (US/Canada)
Access code: 611 684 862

Meeting Information like link to video recording , etc would be located in = https://github.com/roll-wg/ROLL-Interim-Meeting
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000075dbd805a596881c-- From nobody Thu May 14 00:52:20 2020 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 428013A044D for ; Thu, 14 May 2020 00:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Tx35PUCv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=N2GUU3RL 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 7C6duZJCSzvP for ; Thu, 14 May 2020 00:52:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF913A011F for ; Thu, 14 May 2020 00:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23224; q=dns/txt; s=iport; t=1589442736; x=1590652336; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=g2T/xUOxS4TtI+ThOutDlglPUcNtIB/9DNHe2CaRXm0=; b=Tx35PUCvyjbjg8qmLLOSBCduHDgEXXVufqepHjcCZyUdaW5OByiWTn0R Zub28R34SmtA6bUfZZW/08UqO9JyT0KHnCtDdKMIEKuOr4XKmkMbLXL+I KJzBHxGvimNf0P4wl+Q3P5cWtb1AasIiUMaAmvjhOT09CP4OxqM49m9f3 g=; X-IPAS-Result: =?us-ascii?q?A0A9DACm97xe/4YNJK1MFwMBGwEBAQEBAQcBARIBAQQEA?= =?us-ascii?q?QGCB4ElL1EHb1gvLIQlg0YDiyuCEZg3gUKBEANUCwEBAQwBARgBDAgCBAEBh?= =?us-ascii?q?EQCF4F6JDgTAgMBAQEDAgMBAQEBBQEBAQIBBQRthVYMhXEBAQEBAwEBEBEKE?= =?us-ascii?q?wEBJAgMDQICAQgRAwEBARUEDAMDAgICGQwLFAkHAQIEEwgagwWBfk0DLgEOP?= =?us-ascii?q?KYbAoE5iGF2gTKDAQEBBUVtAQMCDkGDQBiCDgMGBYEzgmOCSGmGLhqBQT+BE?= =?us-ascii?q?UOBOIEVPoEEgWMBAQIBARiBDxwNExUJAQwJEQiCRTOCLY4+EoMKhiGbBwqCT?= =?us-ascii?q?YgdiEqHaoJdiGySAI9jiiiTWQIEAgQFAg4BAQWBaSKBVnAVO4JpEz0YDVePa?= =?us-ascii?q?QwXgS+CIIUUhUJ0AjUCBgEHAQEDCXyMKYIfAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AeXZkHBOMBBJEwtdZg/kl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,390,1583193600"; d="scan'208,217";a="465213788" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2020 07:52:14 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 04E7qEt3032291 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 May 2020 07:52:14 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 02:52:14 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 03:52:13 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 14 May 2020 02:52:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kRPa6hAbdYsdbvsMf7OnTGhuzj59Cd7KB4HpQ1Hu0SV3eqUySMsKcjF+8iQQMt/m+EQCqRhlU9gA7xflESQBT+sneP5tVDwO3OGaCqAdPdbPMncwdc+GBi98e2zsb/2cgi30W5nWo/LuBt5lGjsazX0Ws6eD6LE70afnweWlIwnxU7NhdxXJK6ZvesONYkvLh8PNElYcrvS3Um4FYZJVpeHCS3WD8TgChv/cEvrmeSHaB6MdI9qNBLQDnN2mBCjHLpYPvtDgm+4qQwGTLmA/Ln4Pk+2hQKCsf8j0FcLmMGdW2m7P2i4pBSBaPth3/K/zSvBFExWHUAeynpSVxzd8BA== 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=g2T/xUOxS4TtI+ThOutDlglPUcNtIB/9DNHe2CaRXm0=; b=m3zfHegK5MQdRynEMHrHO1WVGXjm6+kfb23sKwvbk4jyC2W1foWGZtVa8bjhChSC+LvVKOTEcqMGI2B0ODk4j4N4KwT5HwudGJ8lPc9ytZpb5hhogNZlTTG3bXVN6db66ro4YjhnMv0YNZlPwpliUOvbNpNfXMucJL2sC9i2FBdX12x+P0skK8hXx6NcwS2JJQnk8ZuZqu1UIf3QLxeQpHYIh3AuIfUkwT2/ozhGYSALZ3eYx+qMAE2OS5KNbmebKoUhNH+7LWY2WdT9XlHycYHmFqAT9zYMuWyigJerDh+mkwfZ7P4sv/O8Fgu3tf1sFW/XPmXNufMCMvEAzvRinw== 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=g2T/xUOxS4TtI+ThOutDlglPUcNtIB/9DNHe2CaRXm0=; b=N2GUU3RL2u5RFb92+XqH3K6wdkFzfLW4KOLujqbDRlj1alEnDAKTXZvq+0wewlel8ww5ws3oQ8IXyVOUMmtMeGgXzGA1M55BMV3Ji8V9QIUbRuYa01CT6UGtnJqkXfBRnkUTA0hLCQuIvco5yQ16EccBXa/nWFye2sZGKzpTA9k= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4533.namprd11.prod.outlook.com (2603:10b6:208:264::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Thu, 14 May 2020 07:52:11 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2979.033; Thu, 14 May 2020 07:52:11 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WG Virtual Meeting: 2020-05-25 Thread-Index: AQHWKcA1jhNtoX5DQ0+gbMadOEuaZainMSxg Date: Thu, 14 May 2020 07:52:11 +0000 Deferred-Delivery: Thu, 14 May 2020 07:50:48 +0000 Message-ID: References: <158886943764.3475.6047615644810853641@ietfa.amsl.com> In-Reply-To: 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-originating-ip: [2a01:cb1d:4ec:2200:a9a3:1062:1942:a99d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50c41c86-31a4-417a-8df6-08d7f7dbb5b6 x-ms-traffictypediagnostic: MN2PR11MB4533: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WKkO2b5D7hkxG7hQXS3qPDJDUg9m7NK/eDBv3TvzxOWxZYB9172OR661eMxla+PWj/7pBanh4lolh8eK5VS2lkgG21vY5Q6z972kMElHgWqyuoKSpcCokBSe7414wEi9mFCNCHqnBpJdx7k6bs+dnq3o5DtSZU7GefsLcDmtRjtwObd6MFdNqmiH8BggR0IIPWOAPXCqUZmuPSevpUv0tCPPkZFX30GuBtqBVeOBZZs2zAitUBNBFBh99L/6+4/Y1YCupFqhxo+IoSwIUtqw00BCDIYRcRbh81+ct4r0GJn0+S6t/WnB4bI2iY/MU4m0BWxcKED8veMXcpMcZqZ0Wnfl+JovH8NIbe9J/gaMiDAIQ2Li6c2scZDfRr5UW9yey1+nlyhHaVbUmaJNyz3SBszMX0xCcnwpi/Te3ZFogdTzJjcntEMtujOjdeVtUPGyM+/LAMyJqUe1eX5t5DmH+6pJsuqiWygzBQInjaRB8TsALpKdB8XRCcGxemob0qVM7tnlXUx/PAt8KGhvroVhXA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(366004)(136003)(39860400002)(396003)(33656002)(66476007)(186003)(52536014)(16799955002)(6506007)(53546011)(316002)(166002)(5660300002)(71200400001)(6916009)(7696005)(9686003)(8936002)(478600001)(64756008)(66446008)(86362001)(55016002)(66556008)(966005)(2906002)(66946007)(8676002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ggbnZYcAj2wLrJL4cUAcOaAOCcafHtxkoYfCJEMEJNsmpCiYM6AuEk4LQgR/I4GJ8a4F06NdNxG/DufpxiLoXPHcy3+1RYdVMLKZL0Y3EAT44aJY7W+u/8o8MR+LDeEGrme3Gd7O7MJjbh8NtxcFj45R1ik5Hu/+Rr1RDOKwrwSavovdH7ocC25LUleyJLuoVmYCkS4KIfPyZ5l3g5W4Vd5XgybDPmd99RH4LyMlw6IYFcMM8mMYz1On1CEc+P/Ruj1DlnSLHHsaxiAmlN3ePvSPMdepMqts1KEmvBk2rQiO3eZe/uzqoIYTu5YZZraOZ3lYLJbgtjAp7ZsE1LjWf45sBX/Oll2mzCqoE+SdVbkT2UmeBJyoBakd08jhoXxoaT0emaaWXy4sLzpJk1073YMGmd+LkXIMCnNVFbbrNwzS8IpKTkmAYV7OdhBQZQs+mWriKd7W7N58U5Z6vHFqTR8ntuLPTgWEaNFumv2lLUKw7O5jkvPCFmDDtMv1EHOMNzT0NexJUv7g+42VPzdIYfqU1P3LRih5ef7QDMAjOALba6dP9QACe5zKoL+z5wcV x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565D5301DCC18B2505E8548D8BC0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50c41c86-31a4-417a-8df6-08d7f7dbb5b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 07:52:11.2974 (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: T7Un1cH1YbNyn7tJETRXRHki2HwS/JkKoLrqUsw7VhHvt/cpYkyP4IgxTwO7tNQhE+wkH+6JZ74LipJCegbyfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4533 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Roll] WG Virtual Meeting: 2020-05-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, 14 May 2020 07:52:18 -0000 --_000_MN2PR11MB3565D5301DCC18B2505E8548D8BC0MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSW5lcw0KDQpJZiB0aW1lIHBlcm1pdHMsIEnigJlkIGxpa2UgdG8gcHJlc2VudCB0aGUg cHJvcG9zZWQgb3BlcmF0aW9uIG9mIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXRodWJlcnQtcm9sbC1lbGlkaW5nLWRpby1pbmZvcm1hdGlvbi8gYW5kIGdldCBjb25maXJt YXRpb24gb2YgdGhlIGludGVyZXN0IG9uIHRoZSB3b3JrIGJ5IHRoZSBXRy4gVG8gZ28gZGVlcGx5 IGluIHRoZSBwcm9wb3NlZCBvcGVyYXRpb24gd2UgcHJvYmFibHkgbmVlZCBhdCBsZWFzdCAyMCBt aW51dGVzLiBUaGVuIHdlIG5lZWQgdG8gY2hhbGxlbmdlIGl0IGFuZCBpbXByb3ZlIHRoZSBkZXNp Z24sIHRoaXMgY291bGQgYmUgc3RhcnRlZCBoZXJlIGFuZCBjb250aW51ZWQgb24gdGhlIE1MLg0K DQpGb3IgbWVtb3J5LCB0aGlzIGRyYWZ0IGlzIHRoZSByZXN1bHQgb2YgYSBwYXN0IGRpc2N1c3Np b24gYXQgYSBST0xMIGludGVyaW0uIFdlIGZvdW5kIHRoYXQgdGhlIERJTyBjb3VsZCBub3QgYmUg bWFkZSBsYXJnZXIgYW5kIGxhcmdlciBmb3JldmVyLCBhbmQgdGhhdCBlbGlkaW5nIG9wdGlvbnMg d291bGQgY2F1c2Ugbm9kZXMgdG8gbWlzcyBjcml0aWNhbCBjaGFuZ2VzLCB3aGljaCBjb3VsZCBo YXZlIG9wZXJhdGlvbmFsIGNvbnNlcXVlbmNlcy4gU28gd2UgZGVjaWRlZCB0aGF0IFJQTHYyIG11 c3QgZW5zdXJlIHRoYXQgYWxsIG5vZGVzIGFyZSBzeW5jaHJvbml6ZWQgb24gY29uZmlndXJhdGlv biBjaGFuZ2VzIGFuZCBjYXBhYmlsaXR5IGV4Y2hhbmdlcy4NCg0KQXMgZm9yIG90aGVyIGRyYWZ0 cywgdGhpcyBpcyBpbmZyYXN0cnVjdHVyZSB3b3JrIHRoYXQgd2UgbmVlZCBiZWZvcmUgdGhlIG5l dyBmZWF0dXJlcyBjb21lIGluLiBJZiB3ZSByZWFjaCBhbiBhZ3JlZW1lbnQgdG8gY29udGludWUg d2l0aCB0aGUgd29yayBJ4oCZbGwgYmUgaGFwcHkgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0IGFuZCBt YWtlIHRoZSBjaGFuZ2VzIHdlIGRlY2lkZSBpbiB0aGUgcGVyc29uYWwgc3VibWlzc2lvbi4NCg0K VGFrZSBjYXJlLA0KDQpQYXNjYWwNCg0KDQpGcm9tOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBJbmVzIFJvYmxlcw0KU2VudDogamV1ZGkgMTQgbWFpIDIwMjAgMDk6 MjANClRvOiByb2xsIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDogW1JvbGxdIFdHIFZpcnR1YWwg TWVldGluZzogMjAyMC0wNS0yNQ0KDQpEZWFyIGFsbCwNCg0KUGxlYXNlIGxldCB1cyBrbm93IHRo ZSB0b3BpY3MgdGhhdCB5b3Ugd291bGQgbGlrZSB0byBkaXNjdXNzIGR1cmluZyB0aGUgbWVldGlu ZyBieSAxOXRoIE1heS4NCg0KU28gZmFyIHdlIGhhdmUgYSBkcmFmdCBBZ2VuZGEgKHRvcGljcyBy ZXN1bHRpbmcgZnJvbSB0aGUgcHJldmlvdXMgKDA0LTI5KSBpbnRlcmltIG1lZXRpbmcpOg0KDQog ICogICBOZXcgT3B0aW9uIGFuZCBCYWNrd2FyZCBjb21wYXRpYmlsaXR5DQogICogICBDb21wcmVz c2lvbiBmb3IgY29udHJvbCBtZXNzYWdlcz8gQXBwbGljYWJsZSBmb3IgbnNhLWV4dGVuc2lvbg0K ICAqICAgUlBMIE9ic2VydmF0aW9uIHRvcGljcw0KICAqICAgUlBMIFBpbmcNCg0KWW91IGNhbiB1 cGxvYWQgdGhlIHNsaWRlcyBoZXJlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRp bmcvaW50ZXJpbS0yMDIwLXJvbGwtMDIvc2Vzc2lvbi9yb2xsDQpUaGUgbGluayB0byB0aGUgdmlk ZW8gcmVjb3JkaW5nIHdpbGwgYmUgYXZhaWxhYmxlIGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9y b2xsLXdnL1JPTEwtSW50ZXJpbS1NZWV0aW5nL3RyZWUvbWFzdGVyLzIwMjAwNTI1DQpXZWJleCBk ZXRhaWxzIGNhbiBiZSBmb3VuZCBiZWxvdy4NCg0KVGhhbmsgeW91IGFuZCBoYXZlIGEgbmljZSBk YXksDQoNCkluZXMgYW5kIERvbWluaXF1ZQ0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdl IC0tLS0tLS0tLQ0KRnJvbTogSUVTRyBTZWNyZXRhcnkgPGllc2ctc2VjcmV0YXJ5QGlldGYub3Jn PG1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4+DQpEYXRlOiBUaHUsIE1heSA3LCAyMDIw IGF0IDc6MzkgUE0NClN1YmplY3Q6IFtSb2xsXSBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBM b3NzeSBuZXR3b3JrcyAocm9sbCkgV0cgVmlydHVhbCBNZWV0aW5nOiAyMDIwLTA1LTI1DQpUbzog SUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5j ZUBpZXRmLm9yZz4+DQpDYzogPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0K DQoNClRoZSBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAocm9sbCkg V29ya2luZyBHcm91cCB3aWxsIGhvbGQNCmEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gMjAy MC0wNS0yNSBmcm9tIDExOjAwIHRvIDEzOjAwIFVUQy4NCg0KQWdlbmRhOg0KRHJhZnQgQWdlbmRh Og0KDQpOZXcgT3B0aW9uIGFuZCBCYWNrd2FyZCBjb21wYXRpYmlsaXR5DQpDb21wcmVzc2lvbiBm b3IgY29udHJvbCBtZXNzYWdlcz8gQXBwbGljYWJsZSBmb3IgbnNhLWV4dGVuc2lvbg0KUlBMIE9i c2VydmF0aW9uIHRvcGljcw0KUlBMIFBpbmcNCkFkZGl0aW9uYWwgSXRlbXMgdG8gYmUgZGV0ZXJt aW5lZA0KDQoNCkluZm9ybWF0aW9uIGFib3V0IHJlbW90ZSBwYXJ0aWNpcGF0aW9uOg0KUm9sbCBp bnRlcmltIE1heSBtZWV0aW5nIEhvc3RlZCBieSBST0xMIFdHICBNb25kYXksIE1heSAyNSwgMjAy MCA2OjQ1IGFtIHwgMiBob3VycyA0NSBtaW51dGVzIHwgKFVUQy0wNDowMCkgRWFzdGVybiBUaW1l IChVUyAmIENhbmFkYSkNCk1lZXRpbmcgbnVtYmVyOiA2MTEgNjg0IDg2Mg0KUGFzc3dvcmQ6IHZi UjlFbkJNczk4DQoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW01OWZh ZDRlMzUwMDY4OGUxNjBmMGQ3NzJiOWY5NDJhYw0KDQpKb2luIGJ5IHZpZGVvIHN5c3RlbQ0KRGlh bCA2MTE2ODQ4NjJAaWV0Zi53ZWJleC5jb208bWFpbHRvOjYxMTY4NDg2MkBpZXRmLndlYmV4LmNv bT4NCllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5n IG51bWJlci4NCkpvaW4gYnkgcGhvbmUgMS02NTAtNDc5LTMyMDgNCkNhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkNCkFjY2VzcyBjb2RlOiA2MTEgNjg0IDg2Mg0KDQpNZWV0aW5nIEluZm9y bWF0aW9uIGxpa2UgbGluayB0byB2aWRlbyByZWNvcmRpbmcgLCBldGMgd291bGQgYmUgbG9jYXRl ZCBpbiBodHRwczovL2dpdGh1Yi5jb20vcm9sbC13Zy9ST0xMLUludGVyaW0tTWVldGluZw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWls aW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== --_000_MN2PR11MB3565D5301DCC18B2505E8548D8BC0MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoxNjE3MjQ4NDk1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTU1NDYwNjM0NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhl bGxvIEluZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SWYgdGltZSBwZXJtaXRzLCBJ4oCZZCBsaWtlIHRvIHByZXNlbnQgdGhlIHBy b3Bvc2VkIG9wZXJhdGlvbiBvZiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10aHViZXJ0LXJvbGwtZWxpZGluZy1kaW8taW5mb3JtYXRpb24vIGFuZCBnZXQgY29uZmlybWF0 aW9uIG9mIHRoZSBpbnRlcmVzdA0KIG9uIHRoZSB3b3JrIGJ5IHRoZSBXRy4gVG8gZ28gZGVlcGx5 IGluIHRoZSBwcm9wb3NlZCBvcGVyYXRpb24gd2UgcHJvYmFibHkgbmVlZCBhdCBsZWFzdCAyMCBt aW51dGVzLiBUaGVuIHdlIG5lZWQgdG8gY2hhbGxlbmdlIGl0IGFuZCBpbXByb3ZlIHRoZSBkZXNp Z24sIHRoaXMgY291bGQgYmUgc3RhcnRlZCBoZXJlIGFuZCBjb250aW51ZWQgb24gdGhlIE1MLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5Gb3IgbWVtb3J5LCB0aGlzIGRyYWZ0IGlzIHRoZSByZXN1bHQgb2YgYSBwYXN0IGRpc2N1c3Np b24gYXQgYSBST0xMIGludGVyaW0uIFdlIGZvdW5kIHRoYXQgdGhlIERJTyBjb3VsZCBub3QgYmUg bWFkZSBsYXJnZXIgYW5kIGxhcmdlciBmb3JldmVyLCBhbmQgdGhhdCBlbGlkaW5nIG9wdGlvbnMg d291bGQNCiBjYXVzZSBub2RlcyB0byBtaXNzIGNyaXRpY2FsIGNoYW5nZXMsIHdoaWNoIGNvdWxk IGhhdmUgb3BlcmF0aW9uYWwgY29uc2VxdWVuY2VzLiBTbyB3ZSBkZWNpZGVkIHRoYXQgUlBMdjIg bXVzdCBlbnN1cmUgdGhhdCBhbGwgbm9kZXMgYXJlIHN5bmNocm9uaXplZCBvbiBjb25maWd1cmF0 aW9uIGNoYW5nZXMgYW5kIGNhcGFiaWxpdHkgZXhjaGFuZ2VzLg0KPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIGZvciBvdGhlciBk cmFmdHMsIHRoaXMgaXMgaW5mcmFzdHJ1Y3R1cmUgd29yayB0aGF0IHdlIG5lZWQgYmVmb3JlIHRo ZSBuZXcgZmVhdHVyZXMgY29tZSBpbi4gSWYgd2UgcmVhY2ggYW4gYWdyZWVtZW50IHRvIGNvbnRp bnVlIHdpdGggdGhlIHdvcmsgSeKAmWxsIGJlIGhhcHB5IHRvIHByb2dyZXNzIHRoZQ0KIGRyYWZ0 IGFuZCBtYWtlIHRoZSBjaGFuZ2VzIHdlIGRlY2lkZSBpbiB0aGUgcGVyc29uYWwgc3VibWlzc2lv bi4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlRha2UgY2FyZSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj4g Um9sbCAmbHQ7cm9sbC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9iPkluZXMgUm9ibGVzPGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gamV1ZGkgMTQg bWFpIDIwMjAgMDk6MjA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86 PC9zcGFuPjwvYj4gcm9sbCAmbHQ7cm9sbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBbUm9sbF0gV0cgVmlydHVh bCBNZWV0aW5nOiAyMDIwLTA1LTI1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5QbGVhc2UgbGV0IHVzIGtub3cgdGhlIHRvcGljcyB0aGF0IHlvdSB3b3VsZCBsaWtlIHRv IGRpc2N1c3MgZHVyaW5nIHRoZSBtZWV0aW5nIGJ5IDE5dGggTWF5LjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5TbyBmYXIgd2UgaGF2ZSBhIGRyYWZ0IEFnZW5kYSAodG9waWNzIHJl c3VsdGluZyBmcm9tIHRoZSBwcmV2aW91cyAoMDQtMjkpIGludGVyaW0gbWVldGluZyk6PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5l dyBPcHRpb24gYW5kIEJhY2t3YXJkIGNvbXBhdGliaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N Cjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5Db21wcmVzc2lvbiBmb3IgY29udHJvbCBtZXNzYWdlcz8gQXBwbGljYWJsZSBmb3IgbnNh LWV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJQTCBPYnNlcnZhdGlvbiB0b3Bp Y3MNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJQTCBQaW5nPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvdSBjYW4gdXBsb2FkIHRoZSBzbGlkZXMgaGVyZTombmJz cDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0y MDIwLXJvbGwtMDIvc2Vzc2lvbi9yb2xsIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvaW50ZXJpbS0yMDIwLXJvbGwtMDIvc2Vzc2lvbi9yb2xsPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ VGhlIGxpbmsgdG8gdGhlIHZpZGVvIHJlY29yZGluZyB3aWxsIGJlIGF2YWlsYWJsZSBoZXJlOiZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9yb2xsLXdnL1JPTEwtSW50ZXJpbS1NZWV0 aW5nL3RyZWUvbWFzdGVyLzIwMjAwNTI1Ij5odHRwczovL2dpdGh1Yi5jb20vcm9sbC13Zy9ST0xM LUludGVyaW0tTWVldGluZy90cmVlL21hc3Rlci8yMDIwMDUyNTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldl YmV4IGRldGFpbHMgY2FuIGJlIGZvdW5kIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5UaGFuayB5b3UgYW5kIGhhdmUgYSBuaWNlIGRheSw8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SW5lcyBhbmQgRG9taW5pcXVlPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0t LS0tLS08YnI+DQpGcm9tOiA8c3Ryb25nPjxiPjxmb250IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklFU0cgU2Vj cmV0YXJ5PC9zcGFuPjwvZm9udD48L2I+PC9zdHJvbmc+ICZsdDs8YSBocmVmPSJtYWlsdG86aWVz Zy1zZWNyZXRhcnlAaWV0Zi5vcmciPmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPC9hPiZndDs8YnI+ DQpEYXRlOiBUaHUsIE1heSA3LCAyMDIwIGF0IDc6MzkgUE08YnI+DQpTdWJqZWN0OiBbUm9sbF0g Um91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgKHJvbGwpIFdHIFZpcnR1 YWwgTWVldGluZzogMjAyMC0wNS0yNTxicj4NClRvOiBJRVRGLUFubm91bmNlICZsdDs8YSBocmVm PSJtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyI+aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KQ2M6ICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBp ZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxicj4NCjxicj4NClRoZSBSb3V0aW5nIE92ZXIgTG93IHBv d2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAocm9sbCkgV29ya2luZyBHcm91cCB3aWxsIGhvbGQ8YnI+ DQphIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIDIwMjAtMDUtMjUgZnJvbSAxMTowMCB0byAx MzowMCBVVEMuPGJyPg0KPGJyPg0KQWdlbmRhOjxicj4NCkRyYWZ0IEFnZW5kYTo8YnI+DQo8YnI+ DQpOZXcgT3B0aW9uIGFuZCBCYWNrd2FyZCBjb21wYXRpYmlsaXR5PGJyPg0KQ29tcHJlc3Npb24g Zm9yIGNvbnRyb2wgbWVzc2FnZXM/IEFwcGxpY2FibGUgZm9yIG5zYS1leHRlbnNpb248YnI+DQpS UEwgT2JzZXJ2YXRpb24gdG9waWNzIDxicj4NClJQTCBQaW5nPGJyPg0KQWRkaXRpb25hbCBJdGVt cyB0byBiZSBkZXRlcm1pbmVkPGJyPg0KPGJyPg0KPGJyPg0KSW5mb3JtYXRpb24gYWJvdXQgcmVt b3RlIHBhcnRpY2lwYXRpb246PGJyPg0KUm9sbCBpbnRlcmltIE1heSBtZWV0aW5nIEhvc3RlZCBi eSBST0xMIFdHJm5ic3A7IE1vbmRheSwgTWF5IDI1LCAyMDIwIDY6NDUgYW0gfCAyIGhvdXJzIDQ1 IG1pbnV0ZXMgfCAoVVRDLTA0OjAwKSBFYXN0ZXJuIFRpbWUgKFVTICZhbXA7IENhbmFkYSkNCjxi cj4NCk1lZXRpbmcgbnVtYmVyOiA2MTEgNjg0IDg2MiA8YnI+DQpQYXNzd29yZDogdmJSOUVuQk1z OTggPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bTU5ZmFkNGUzNTAwNjg4ZTE2MGYwZDc3MmI5Zjk0MmFjIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTU5ZmFkNGUzNTAwNjg4ZTE2 MGYwZDc3MmI5Zjk0MmFjPC9hPiZuYnNwOw0KPGJyPg0KPGJyPg0KSm9pbiBieSB2aWRlbyBzeXN0 ZW0gPGJyPg0KRGlhbCA8YSBocmVmPSJtYWlsdG86NjExNjg0ODYyQGlldGYud2ViZXguY29tIiB0 YXJnZXQ9Il9ibGFuayI+NjExNjg0ODYyQGlldGYud2ViZXguY29tPC9hPg0KPGJyPg0KWW91IGNh biBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLiZu YnNwOyA8YnI+DQpKb2luIGJ5IHBob25lIDEtNjUwLTQ3OS0zMjA4IDxicj4NCkNhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSkgPGJyPg0KQWNjZXNzIGNvZGU6IDYxMSA2ODQgODYyPGJyPg0K PGJyPg0KTWVldGluZyBJbmZvcm1hdGlvbiBsaWtlIGxpbmsgdG8gdmlkZW8gcmVjb3JkaW5nICwg ZXRjIHdvdWxkIGJlIGxvY2F0ZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3JvbGwt d2cvUk9MTC1JbnRlcmltLU1lZXRpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHVi LmNvbS9yb2xsLXdnL1JPTEwtSW50ZXJpbS1NZWV0aW5nPC9hPjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUm9sbCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PlJvbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR11MB3565D5301DCC18B2505E8548D8BC0MN2PR11MB3565namp_-- From nobody Fri May 15 07:45:13 2020 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 2A9A23A0A74 for ; Fri, 15 May 2020 07:45:11 -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, 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 (1024-bit key) header.d=math.unipd.it 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 xP9cm-DBRv5g for ; Fri, 15 May 2020 07:45:09 -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 F40983A0A79 for ; Fri, 15 May 2020 07:45:08 -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 04FEVGo3071118 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 May 2020 14:31:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=math.unipd.it; s=default; t=1589553082; bh=VRRYs9SlZIi6k03JXFK/mlA1ZkqRX7VFdVAUtZZx87k=; h=Date:From:To:Subject; b=QEB5uhcP0VnMMC3GdNsdY3r2XAzg9w64Ht8w/XQKdC9/xcRcg1ibd5y3RalJBRVQH 3QavLCMhq8TWTVk85PokLnMVImi5tVzSqzq+2e/wxDOdIqnepEb0iWq/DCNepT1pzV vE/tK7rwXmnZIRwuYpCDtsqul4aStfvvtSaxgmSg= 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 04FEVGu7054482 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 May 2020 14:31:16 GMT Received: from [91.253.186.219] ([91.253.186.219]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Fri, 15 May 2020 16:31:16 +0200 Date: Fri, 15 May 2020 16:31:11 +0200 Message-ID: <20200515163111.Horde.AMlSrhagUL29aVkfKntfppd@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=5 Fuz1=5 Fuz2=5 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 - DEADLINE EXTENDED] Going Virtual - GOODTECHS 2020 - Special Session in Serious Games to Improve Quality of Life, 14/09 - 16/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, 15 May 2020 14:45:11 -0000 ************************************************************************* * Call for Papers * GoodTechs 2020 * Special Session in Serious Games to Improve Quality of Life * September 14-16, 2020, VIRTUAL CONFERENCE *. Submission by 1 June 2020 (EXTENDED, FIRM) * ************************************************************************* More info at: http://goodtechs.eu/serious-games/ The GoodTechs Steering and Organizing committees, due to the current COVID-19 situation, have decided to make our 2020 Edition fully virtual to eliminate uncertainty and to ensure the health, safety, and well-being of our research community and society in general. The dates of the virtual conference remain the same: September 14-16, 2020. A mechanism for virtual presentation and participation will be provided. More details will be announced in a timely manner, so please stay tuned to the official website for more updates. We also have decided to extend the submission deadline to June 1st, 2020. This deadline is firm! SCOPE ====== Gamification techniques and serious games are often used to capture and maintain user’s attention and motivation. This is particularly important when dealing with young patients or people with special needs. Patient’s collaboration is crucial for doctors to perform a good diagnosis, and to provide an efficient therapy, but it cannot always be taken for granted. Moreover, serious games are proved to be an efficient tool to incentivize people to improve their lifestyle, e.g., making more physical activity. This track will feature new insights, research, and practice on how to design, develop and use gamification and persuasive technologies to create serious games and applications to improve individuals’ Quality of Life (QoL) and behavior, with a particular focus on people with disabilities. The track targets researchers, doctoral students, practitioners and other people interested in presenting, discussing, reflecting and networking on central themes associated with the development and use of serious games and applications to help people with special needs. Papers on both theoretical aspects and design methods of gamification techniques and serious games are welcomed, as well as system prototypes and novel evaluation methods. In addition, the track welcomes full research, work in progress papers and educational cases. Chair: Ombretta Gaggi, Università di Padova, Italy, gaggi[at]math.unipd.it Co-Chair: Antonio Rodà, Università di Padova, Italy, antonio.roda[at]unipd.it TOPICS OF INTEREST ================== Serious game design for better lifestyle promotion Serious games for people with disability Games for Education and Learning Gamification Pervasive Systems Assistive Technologies Persuasive solutions Methods, models, and principles for gamification design Usability and accessibility issues Games for Health and Well-Being Serious Games for social inclusion Serious Games for cultural heritage IMPORTANT DATES ================ Full Paper Submission deadline: 1 June 2020 Notification deadline: 13 July 2020 Follow the submission instructions at: http://goodtechs.eu/submission/ -- 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 May 16 01:41:44 2020 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 1A4913A0955; Sat, 16 May 2020 01:41:38 -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.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158961849800.18021.5069151377902832891@ietfa.amsl.com> Date: Sat, 16 May 2020 01:41:38 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.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, 16 May 2020 08:41:38 -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 : RPL Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Rabi Narayan Sahoo Filename : draft-ietf-roll-capabilities-04.txt Pages : 12 Date : 2020-05-16 Abstract: This draft enables the discovery, advertisement and query of capabilities for RPL nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-capabilities-04 https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-capabilities-04 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 May 16 01:52:00 2020 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 EAE143A0966 for ; Sat, 16 May 2020 01:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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_MSPIKE_H2=-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=outlook.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 czpP_AiFMUZi for ; Sat, 16 May 2020 01:51:58 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254075.outbound.protection.outlook.com [40.92.254.75]) (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 907503A0965 for ; Sat, 16 May 2020 01:51:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ip542cff6heXUDy9QRSEdx/G9SUq/QvuTa5WaVrK9hIMmwWj6PpXfukhrc7GohvVtgwfFx9g/Akg1QfzLJy11qwVkNEIcuGK+kM/7LvnEsgYCRcc39ofRiZpj/6XTEybsmMRdDVTPmxrrBN7xNwQjNr+fVFGMmq1VlioJcwwt3sXM83+9P1qD4xxhwCYxbWnjxL4T2YIvKKNiI7ASaIoS4LrGfD7jOkCng+/ri53bYe6irOsydW/0BuXdJ5DW7RFUJZprnhpNmSbZ33pqTj10VZlGgzg9WcNSCnKG+K8JH/MIeBISVFNxLCkP4iad0RXTm05QV23Fi0xVcfvr9mljw== 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=O7SBAmXYq80Z8i8zJ1482E6DRZyBqo1EqH8oGtBZgKQ=; b=D7ydVVemIGz+lO6xDlKYdlOR6tcc+z7TpOYezJllhQID351GykwK16OC4jOiyZyXoLj8H7r/GwDFoBImPzvoKWHJ5Omm9nFf2iisfc/tGIrNw+NZoWn6wVePLYMVMG+rgkYbUDzvZRp/IfHdBVu3v/q8n8ROEyJoMxRjxE62feZhqtadjx6JsENaTmXA9zSxpYDHxSC8JJB3vnOULPnCpTlR1SCqiS5oLPYoHZKUkny1K4XBhXhOaWAjGo+vfkv5VoaTyMaKzqRO5tUZgsZRIgJJUOLlTVk/Wu8uNz4B4RTXogQGJyAq//0wmxpshsJDImAVFT/v/WiXu/WLIBKxTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O7SBAmXYq80Z8i8zJ1482E6DRZyBqo1EqH8oGtBZgKQ=; b=Txqb3hG6AoohQCO10ktSjA4fS4ZW/ZE4Fk6IGKBSX7fo6KT86nGfdv6JWMHk7X1fukQclOcJkrmMYM9u6PQmLrW97aHeVRLkjY6xT51KXgzU6i2PTCOKfTJLhEK9qIHvVLvvP7rkWvpR4QmPJD8gB1DR2BIyLBxToaV1ZHgVgLhOCevGf/+gCgj0cWKqWN6/YybrqGibqAWns9uJyFw/8M2nqlL9P7Lm1xN3c4wQAn4r9TEdS+FGDD38/ymSkB2fktWD27II7iI/rbXKoW1GgYQ9tBp0A1SqBJASEUTLiwFpoNTaEb69SPcNN9uDu32lRXFnSj/SbZvz4DSBU8OylQ== Received: from SG2APC01FT025.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::4a) by SG2APC01HT017.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::266) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19; Sat, 16 May 2020 08:51:53 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebd::40) by SG2APC01FT025.mail.protection.outlook.com (2a01:111:e400:7ebd::187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Sat, 16 May 2020 08:51:53 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3000.022; Sat, 16 May 2020 08:51:53 +0000 From: Rahul Jadhav To: "roll@ietf.org" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt Thread-Index: AQHWK13zrn+vhchc5EObdNH+ttAbVqiqZh8r Date: Sat, 16 May 2020 08:51:53 +0000 Message-ID: References: <158961849800.18021.5069151377902832891@ietfa.amsl.com> In-Reply-To: <158961849800.18021.5069151377902832891@ietfa.amsl.com> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:664E3F748A82DE37289866787425E44D60DEFB704B341837F829D731BA73B0B9; UpperCasedChecksum:52244A44317C5555679DEB35A9F62B840FD9E3829C859EF7312082F758512F03; SizeAsReceived:6824; Count:44 x-tmn: [arTZhiuIjVy0kdRCKRklU4Hn11BFDe5r] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 418bdd7f-ba49-48b3-b101-08d7f976615e x-ms-traffictypediagnostic: SG2APC01HT017: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gbdhZYBqMIX5BtQOH+EP7R5lGuOG9QB8wj9O/KuY5ZuCx0PBNnTLO3qeQ7AcujgZ98WxXinVaRP14R+NPhCae2ngES9li9C1uT4aFO/hHVwRGymzF6PVQU/7pEMkvk8rCuyITQy6a/0pmk5esJkQBOBWmN7/dddoc+dF88Kjvp0sDj2r840rMmnRHLxyn/X19xRTUI+09DrJg4yGUjMp0bdHLI1o3G4JBq9ajJS0AZM5FYg85bbE/BbvD4c1qFmG x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: k1DPiGM+NZQ6KX7yPHIu/qCdxBjeftwQb42BOpwRHmVKijvcZ80naQr3QjVp7Dy1FOkRA0mLkjAnw81uyjIT7hTUoc0JT6baimbPGKhZRClnbS0xDGM2IaDUj6nu9H7CL2o6TNC6V9EGZbsaOt7qew== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020422CFBBF9205B39DF0E8A9BA0BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 418bdd7f-ba49-48b3-b101-08d7f976615e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2020 08:51:53.0277 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT017 Archived-At: Subject: [Roll] Fw: I-D Action: draft-ietf-roll-capabilities-04.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: Sat, 16 May 2020 08:52:00 -0000 --_000_BM1PR01MB4020422CFBBF9205B39DF0E8A9BA0BM1PR01MB4020INDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The update fixes all the points discussed during interim and subsequent ML = discussions, namely: 1. Flag for ignoring (silently discarding) the message if cap not unders= tood. 2. removal of global flag 3. removal of info present flag. Earlier we had optional length for capa= bilities who do not have any information. Such capabilities are now aggrega= ted as part of 'Capability Indicators'. Thus this bit is no longer required= . 4. The indicator bits are ordered from left to right. Feedback/reviews are appreciated. Thanks. Best, Rahul ________________________________________ From: Roll on behalf of internet-drafts@ietf.org Sent: 16 May 2020 04:41 PM To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : RPL Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Rabi Narayan Sahoo Filename : draft-ietf-roll-capabilities-04.txt Pages : 12 Date : 2020-05-16 Abstract: This draft enables the discovery, advertisement and query of capabilities for RPL nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-capabilities-04 https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-capabilities-04 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_BM1PR01MB4020422CFBBF9205B39DF0E8A9BA0BM1PR01MB4020INDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,

The update fixes all the points discussed during interim and subsequent ML = discussions, namely:

  1. Flag for ignoring (silently discarding) the message if cap not understo= od.
  2. removal of global flag
  3. removal of info present flag. Ea= rlier we had optional length for capabilities who do not have any informati= on. Such capabilities are now aggregated as part of 'Capability Indicators'= . Thus this bit is no longer required.
  4. The indicator bits are order= ed from left to right.
Feedback/reviews are appreciated. Thanks.

Best,
Rahul


________________________________________
From: Roll <roll-bounces@ietf.org> on behalf of internet-drafts@ietf.= org <internet-drafts@ietf.org>
Sent: 16 May 2020 04:41 PM
To: i-d-announce@ietf.org
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.

        Title    &nb= sp;      : RPL Capabilities
        Authors    &= nbsp;    : Rahul Arvind Jadhav
            &nb= sp;            = Pascal Thubert
            &nb= sp;            = Michael Richardson
            &nb= sp;            = Rabi Narayan Sahoo
        Filename    =     : draft-ietf-roll-capabilities-04.txt
        Pages    &nb= sp;      : 12
        Date    &nbs= p;       : 2020-05-16

Abstract:
   This draft enables the discovery, advertisement and query of    capabilities for RPL nodes.


The IETF datatracker status page for this draft is:
= https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/

There are also htmlized versions available at:
htt= ps://tools.ietf.org/html/draft-ietf-roll-capabilities-04
https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-0= 4

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-capabilities-04


Please note that it may take a couple of minutes from the time of submissio= n
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/


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org= /mailman/listinfo/roll
--_000_BM1PR01MB4020422CFBBF9205B39DF0E8A9BA0BM1PR01MB4020INDP_-- From nobody Sat May 16 19:22:42 2020 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 4E1353A0CB7 for ; Sat, 16 May 2020 19:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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_MSPIKE_H2=-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=outlook.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 TaNAGth6L2Sq for ; Sat, 16 May 2020 19:22:39 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254094.outbound.protection.outlook.com [40.92.254.94]) (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 D47513A0CB5 for ; Sat, 16 May 2020 19:22:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZW2uQv019k+2FxHYkMwVuRBtnvj5P0YrSJHB6PGGumYDyjYppW8V9HCrGDh8mMKhgM1PX89BoUEf3wPUJrxDH4GeDJI2lDwEr1dsDqgnjsE4wfQbaGd+N5WiNHpM56tZxlWc7uGsrb4BO+xH0YGYn936RFMRucZ16dVcmbLRkLhDLIucVQ5x3asqisS6xenusRZ3Dd8vo+YXjqksVMHZ/H7auBQKHfbkuytp2W0101xiK3kkDPo6vPmwPLtgNTrj+oy4+zWB9hq3YUYyu0BndXmNLT9T8si96iqxetOknf8+nmUSLiqyAxkmZWA/CW/oLexnpoo/dUbMhOuw37SbIg== 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=4xHqbmo3RxLqYbVB+nx5oetFalO142EkhQEKYhyJ13A=; b=EEqhpcD9/xj/IXoZyE1aM6NdXWDSkyklbpAmeeHAWHyjJKpZyHUwRlqUkWmv+xs/jgB7WsQnDAgzMeC4IwBxHNYgVv/+E3B4cp8BnqGCnoTowS8qEQtlVkf7g5MAAPQ7Njd4+k1QPJM/TU63cSQNKCctcgQNA+sYCNssAjmhVvSypcZGS1nwEBipGuYyQWrwNVwGIwk82QhYD+pJLOUxuek9NWJMXWrTRirG4EXLfN/f2x0eRIAjOFTF0rPDEgOCR4Hrov/FxMql3f0yq+qT5xasUHvYTY7lvBdThtzFGPWkxiDayAIoBVpjbIJuCNtN8F8UfG+C7K6zQ8EiEMdQlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4xHqbmo3RxLqYbVB+nx5oetFalO142EkhQEKYhyJ13A=; b=KNAebHUlgAdfsw61A299wik7c+rutjZfYBy/j464PMofo93W74hnShAPjoD+hfTQnQlvs2OkFcBu1MWNBgtLawuEqirtd1Hz4wSwvUBz8SqEQR9BaH1zI4G1k7KqgyjUlZNaY2cofOk2VapRdR/L06ml3moOLQVckhYSHAL9snyyU8SbKUiX5C0cVEq4BTLc+BXTus9oBCR+U3qHszP2PfB64OTKW+kC7UbFatxMm3ZwupC+4F19/eDRSzu+W0fJhFOn3eg2hq6L1oUXraR65P5OO4bAbZcOCB868KeWSoGl3GPH67OjMQ3YcXZ56VOmcDMkp/ASn9Lc1RnTnZs8Bg== Received: from PU1APC01FT045.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::4d) by PU1APC01HT071.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::397) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19; Sun, 17 May 2020 02:22:34 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebe::47) by PU1APC01FT045.mail.protection.outlook.com (2a01:111:e400:7ebe::288) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Sun, 17 May 2020 02:22:33 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3000.022; Sun, 17 May 2020 02:22:33 +0000 From: Rahul Jadhav To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks , rabi narayan sahoo Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt Thread-Index: AQHV+Hcezq3im2uH30CiF/oY8K2vzahE/ZyggAAFM7yAAAXZkIAABcnzgAAN4ICAZtA3qQ== Date: Sun, 17 May 2020 02:22:33 +0000 Message-ID: References: <158402183564.18056.13091739917212256438@ietfa.amsl.com>, , , In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:9170FCA18B9EA281197B47E8AC6337DB941BB85C7CDD2ABC58CA9A684779E6B7; UpperCasedChecksum:990FB67DBF1D24D97F061F6F6BD782B9035D92E8992EC540F2468075606C828F; SizeAsReceived:7461; Count:44 x-tmn: [4c40XiPzOd1z95jSF2kD3AAMwIKrAXMR] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 8f7ad21e-e802-4e45-c6d9-08d7fa09287d x-ms-traffictypediagnostic: PU1APC01HT071: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f+jxMatT7TJSUszlDey4d1elFa190fSTKFsQ1R97vjf9EkqsA0PPWXY8Fqz82Nr1cRMJdhZhf/s3lAzAXO0wMlROqGFEy2Y1QCkexIywWtyK1VabCJyLM2DOv27xRag39cweSwcT7SfH4LqMi9hKOFMvUTZzRXb9QVfi4CgLwg6JZFZhQiZCchxHzz/1xul6T0zhZOwP2XMp7u3ew5ZZ5whMwY5dV3pofhxXtCtRSQ3SV0Xe+fxsrXmK5gSmkpnk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: BaLeFqar50eqQIiwqUEi4b9dD/rSX5N5zaDEPSz2SCqvnMm8ztSAk26ciR/4zYl+q51oEqfI3VldUOEWAeIpRAVAapBohkU4wdGC8KqwDn2CxeEoGJlnc6Y4nUfSRX87wNVZ9DtXMdNQrAsElAhb9Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402022A09B2743DC25E9AE1CA9BB0BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 8f7ad21e-e802-4e45-c6d9-08d7fa09287d X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2020 02:22:33.6646 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT071 Archived-At: Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.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: Sun, 17 May 2020 02:22:41 -0000 --_000_BM1PR01MB402022A09B2743DC25E9AE1CA9BB0BM1PR01MB4020INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pascal, Revisiting this thread because of some new light [1]. Question is, Can an RPL node in Storing MOP send a DAO with Transit Info Op= tion with Parent Address subfield? Previously, you pointed out RFC6550 section 9.8 which clearly mentions that= "Parent Address in Storing MOP MUST be empty". However, as per Section 9.4, the RFC says, "In order to inject such a (exte= rnal) Target in the RPL network, the router MUST advertise itself as the DO= DAG Parent Address subfield in the Transit..." Essentially Section 9.4 contradicts 9.8 both using MUST clauses. Just for the record, this discussion does not have any impact on the unawar= e-leaves draft. Best, Rahul [1] new light: Rabi actually informed me about section 9.8 in context to an= other offline discussion wrt Storing-Root-Ack. ________________________________ From: Pascal Thubert (pthubert) Sent: 13 March 2020 12:49 AM To: Rahul Jadhav ; Routing Over Low power and Lossy ne= tworks Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hello Rahul RFC 6550 says: =93 9.8. Storing Mode In Storing mode, RPL routes messages Downward by the IPv6 destination address. The following rules apply to nodes that are in Storing mode: 1. The DODAG Parent Address subfield of a Transmit Information option MUST be empty. =93 So even if it is a good idea it requires new specs to override RFC 6550. More below (using P2>) From: Rahul Jadhav Sent: jeudi 12 mars 2020 16:32 To: Pascal Thubert (pthubert) ; Routing Over Low power = and Lossy networks Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Please find below inline answers. Also, I did not get any objection from 6l= o so I added a IANA section that reduces the EARO status range to 0-63, whi= ch solves the issue you raised. [RJ] Yep, that indeed takes care of a major point ??. Please find my [RJ] r= esponses inline. Regarding this statement, "Non-Storing Mode DAO messages are used to signal external routes to the Root, even if the DODAG is operated in Storing Mode." I couldn't find any text which provides reasoning to do so. Why non-storing= mode DAO is needed and why storing mode DAO won't work? Pascal> We need the address of the 6LR to terminate the tunnel and remove t= he artifacts, and the NS signaling will give us that. This is how we remove= d the hassle of hop by hop link local tunnels that was in the old useofrpli= nfo. There is this text which says, "The Non-Storing Mode DAO messaging enables = to advertise the 6LR that serves the RUL and injects the route to the Root.= " This can be achieved even with storing mode DAO with the target as RUL ad= dress and transit information containing parent address as anchor 6LR addre= ss. Pascal > Which is not the normal storing mode signaling. [RJ] Yes, but 6550 does not stop us from doing it. Interestingly, I have a = use-case in my deployment wherein I need to send this parent address info e= ven in storing MOP. It helps the root get the complete network graph even i= n storing mode for visualization purposes (if the admin wants to check how = the network is formed, how many hops etc on the root in storing mode). P2> It does actually, see above It would be an hybrid. The cool thing with NS is that the external prefixes= are not visible inside the RPL domain. Legacy nodes do not have to know th= ey exist. Only the 6LR at the border that inject the external routes and th= e Root are aware and need to know about the new signaling. Using an hybrid = impacts every node. [RJ] The hybrid may not necessarily impact every node. An intermediate 6LR = may decide to ignore that external target in the DAO and that would still b= e ok. In this case, the signaling will work through next common ancestor wh= ich has to capability to hold/process that kind of info. P2> which is still an impact; new code to recognize the =91E=92 flag and de= cide to ignore the address. A legacy node would not do the right thing. Trying to understand the reason because this mode of signaling has implicat= ions (already covered in the draft), particularly that, when the DAG is ope= rating in storing mode, the communication to RUL from other RANs would mand= atorily have to be routed through root only. If we use storing mode DAO the= n this could be optimized. Not sure if I am missing anything? Pascal > Well, yes, we could have done that as well. The path could be opti= mized but * it would mean that the common parent has to encapsulate to the 6LR, whic= h is an additional function there * It would also mean that the network has ot be aware of external routes, w= hich may be too many for the SM tables. [RJ] I am just keen on doing this because it makes things flexible. Anchor = 6LR has both options of sending NS-DAO or storing DAO. Intermediate 6LRs al= so have both options, honor the external target info or ignore it and just = pass it on. P2> I=92m happy to discuss it and see if and how we open RPL in that direct= ion. But for short term we=92re shipping useofrplinfo and RUL with the low = hanging fruit. Pros and cons I guess. We went for the simple and backward compatible way. [RJ] Yes, Backward compatibility may be an issue because intermediate 6LRs = operating in pure storing mode will try to cache the external target and ma= y not be able to do IP-in-IP at their point. However, handling this compati= bility may not be a big challenge. The flexibility this provides is very co= mpelling to me. With DAO projection, we have already entered that zone wher= e the nodes could be hybrid in nature. PT2> with the capability work we=92ll be able to introduce this and more : = ) Take care, Pascal ________________________________ From: Roll > on behalf = of Pascal Thubert (pthubert) > Sent: 12 March 2020 07:38 PM To: Routing Over Low power and Lossy networks > Subject: [Roll] FW: New Version Notification for draft-ietf-roll-unaware-le= aves-10.txt Dear all As discussed with the IOT DIR, this draft is not the gating factor for all = cluster C310. In order to progress I made a full pass on it and fixed a few bugs and misa= lignments with useofrplinfo. I believe the doc is ripe for WGLC. Many thanks Pascal -----Original Message----- From: internet-drafts@ietf.org > Sent: jeudi 12 mars 2020 15:04 To: Michael Richardson = >; Michael C. Richardson >; Pascal Thubert (pthubert) > Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-ietf-roll-unaware-leaves Revision: 10 Title: Routing for RPL Leaves Document date: 2020-03-12 Group: roll Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-ietf-roll-unawar= e-leaves-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-le= aves/ Htmlized: https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-= 10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-roll-unawa= re-leaves Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware= -leaves-10 Abstract: This specification extends RFC6550 and RFC8505 to provide unicast and multicast routing services in a RPL domain to 6LNs that are plain Hosts and do not participate to RPL, and enables the RPL Root to proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_BM1PR01MB402022A09B2743DC25E9AE1CA9BB0BM1PR01MB4020INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Pascal,

Revisiting this thread because of some new light [1].

Question is, Can an RPL node in Storing MOP send a DAO with Transit Info Op= tion with Parent Address subfield?

Previously, you pointed out RFC6550 section 9.8 whi= ch clearly mentions that "Parent Address in Storing MOP MUST be empty&= quot;. 

However, as per Section 9.4, the RFC says, "In order to inject such a = (external) Target in the RPL network, the router MUST advertise itself as t= he DODAG Parent Address subfield in the Transit..."

Essentially Section 9.4 contradicts 9.8 both using MUST clauses.

Just for the record, this discussion does not have any impact on the unawar= e-leaves draft.

Best,
Rahul

[1] new light: Rabi actually informed me about section 9.8 in context to an= other offline discussion wrt Storing-Root-Ack.
From: Pascal Thubert (pthub= ert) <pthubert@cisco.com>
Sent: 13 March 2020 12:49 AM
To: Rahul Jadhav <nyrahul@outlook.com>; Routing Over Low power= and Lossy networks <roll@ietf.org>
Subject: RE: New Version Notification for draft-ietf-roll-unaware-le= aves-10.txt
 

Hello Rahul

 

RFC 6550 says:

 

=93

 

9.8.  Storing Mode

 

 

   In = Storing mode, RPL routes messages Downward by the IPv6 destination

   add= ress.  The following rules apply to nodes that are in Storing

   mod= e:

 

   1.&= nbsp; The DODAG Parent Address subfield of a Transmit Information

  &nbs= p;    option MUST be empty.

 

 

=93

 

So even if it is a good idea it requires new specs to over= ride RFC 6550.

 

More below (using P2>)

 

 

From: Rahul Jadha= v <nyrahul@outlook.com>
Sent: jeudi 12 mars 2020 16:= 32
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; Routing Over Low power and Lossy networks <= ;roll@ietf.org>
Subject: Re: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

=  

 

 

Please find below inline answers. Also, I did not get any objection from 6= lo so I added a IANA section that reduces the EARO status range to 0-63, which solves the issue you raised.

 

[RJ] Yep, that indeed takes care of a major point 😊. Please find my [RJ] responses inline.

 

 

 

Regarding this statement,

"Non-Storing Mode DAO m= essages are used to signal external routes to
   the Root, even if the DODAG is operated in Storing Mode."=

 

I couldn't find any text whi= ch provides reasoning to do so. Why non-storing mode DAO is needed and why = storing mode DAO won't work?

 

Pascal> We need the address of the 6LR to terminate th= e tunnel and remove the artifacts, and the NS signaling will give us that. = This is how we removed the hassle of hop by hop link local tunnels that was in the old useofrplinfo.

 

There is this text which say= s, "The Non-Storing Mode DAO messaging enables to advertise the 6LR th= at serves the RUL and injects the route to the Root." This can be achieved even with storing mode DAO with the targe= t as RUL address and transit information containing parent address as ancho= r 6LR address.

 

Pascal > Which is not the normal storing mode signalin= g. 

 

[RJ] Yes, but 6550 does not stop us from doing it. Intere= stingly, I have a use-case in my deployment wherein I need to send this par= ent address info even in storing MOP. It helps the root get the complete network graph even in storing mode for vis= ualization purposes (if the admin wants to check how the network is formed,= how many hops etc on the root in storing mode).

 

P2> It does actually, see above

 

It would be an hybrid. The cool thing with NS is that the= external prefixes are not visible inside the RPL domain. Legacy nodes do n= ot have to know they exist. Only the 6LR at the border that inject the external routes and the Root are aware and n= eed to know about the new signaling. Using an hybrid impacts every node.

 

[RJ] The hybrid may not necessarily impact every node. An= intermediate 6LR may decide to ignore that external target in the DAO and = that would still be ok. In this case, the signaling will work through next common ancestor which has to capability t= o hold/process that kind of info. 

 

P2> which is still an impact; new code to recognize th= e =91E=92 flag and decide to ignore the address. A legacy node would not do= the right thing.

 

Trying to understand the rea= son because this mode of signaling has implications (already covered in the= draft), particularly that, when the DAG is operating in storing mode, the communication to RUL from other RANs would = mandatorily have to be routed through root only. If we use storing mode DAO= then this could be optimized. Not sure if I am missing anything?

 

Pascal > Well, yes, we could have done that as well. T= he path could be optimized but

*  it would mean that the common parent has to encap= sulate to the 6LR, which is an additional function there

* It would also mean that the network has ot be aware of = external routes, which may be too many for the SM tables.

 

[RJ] I am just keen on doing this because it makes things= flexible. Anchor 6LR has both options of sending NS-DAO or storing DAO. In= termediate 6LRs also have both options, honor the external target info or ignore it and just pass it on.

 

P2> I=92m happy to discuss it and see if and how we op= en RPL in that direction. But for short term we=92re shipping useofrplinfo = and RUL with the low hanging fruit.

 

Pros and cons I guess. We went for the simple and backwar= d compatible way.

 

[RJ] Yes, Backward compatibility may be an issue because = intermediate 6LRs operating in pure storing mode will try to cache the exte= rnal target and may not be able to do IP-in-IP at their point. However, handling this compatibility may not be a big chal= lenge. The flexibility this provides is very compelling to me. With DAO pro= jection, we have already entered that zone where the nodes could be hybrid = in nature.

 

PT2> with the capability work we=92ll be able to intro= duce this and more : )

 

 

Take care,

 

Pascal

From: Roll <= ;roll-bounces@ietf.o= rg> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco..com@dmarc.ietf= .org>
Sent: 12 March 2020 07:38 PM=
To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: [Roll] FW: New Vers= ion Notification for draft-ietf-roll-unaware-leaves-10.txt

 

Dear all

As discussed with the IOT DIR, this draft is not the gating factor for all = cluster C310.
In order to progress I made a full pass on it and fixed a few bugs and misa= lignments with useofrplinfo.

I believe the doc is ripe for WGLC.

Many thanks

Pascal

-----Original Message-----
From: internet-drafts@ietf.org<= /a> <internet-drafts@ietf.or= g>
Sent: jeudi 12 mars 2020 15:04
To: Michael Richardson <mcr= +ietf@sandelman.ca>; Michael C. Richardson <mcr+ietf@sandelman.ca>; Pascal Thube= rt (pthubert) <pthubert@cisco.com<= /a>>
Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt=


A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt
has been successfully submitted by Pascal Thubert and posted to the IETF re= pository.

Name:           draft-iet= f-roll-unaware-leaves
Revision:       10
Title:          Routing for RP= L Leaves
Document date:  2020-03-12
Group:          roll
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-unaware-leaves-10.txt<= /a>
Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-10
Abstract:
   This specification extends RFC6550 and RFC8505 to provide unic= ast and
   multicast routing services in a RPL domain to 6LNs that are pl= ain
   Hosts and do not participate to RPL, and enables the RPL Root = to
   proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its= DODAG.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--_000_BM1PR01MB402022A09B2743DC25E9AE1CA9BB0BM1PR01MB4020INDP_-- From nobody Mon May 18 04:31:05 2020 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 394E33A0B0D for ; Mon, 18 May 2020 04:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.697 X-Spam-Level: X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=ktRJ1roG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MVr3Xz/s 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 ZKqUWIM3ch2P for ; Mon, 18 May 2020 04:30:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465C43A0B09 for ; Mon, 18 May 2020 04:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60302; q=dns/txt; s=iport; t=1589801459; x=1591011059; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=CLfdPicLZ0uoemAapw57mfE3XQ/i0brr1TFnErEfhlg=; b=ktRJ1roGvhNS+S18d3wcPSunWsvklvG2GG+bQdMcKjeYQWV0OjA9BxIN Fkorehg+X7QvbEHULj+9ddEomgtSX3/5PS/vReFdSVd/u1A7gDrgRgC9D HpG/dSOPOAps2e4r38jDw4LmosCheUbmrzJU8bimjZLhv3aun4gMYo9EK I=; IronPort-PHdr: =?us-ascii?q?9a23=3Ahdt2RRwqGDwAEO7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWPt/JwkFvOWoad4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2Yk9IBML5YF6UqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKBAAEccJe/5FdJa1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIHgSUBLiQtB29YLyyDZECBXYFpA4stghGBAYh6jkC?= =?us-ascii?q?BQoEQA1AEAwgBAQEMAQEYAQwIAgQBAYMOgTYCF4IFJDgTAgMBAQsBAQUBAQE?= =?us-ascii?q?CAQUEbYVWDIVxAQEBAQMBAQoGEQoTAQEsCQMLBAIBBgIOAwQBASEBBgMCAgI?= =?us-ascii?q?fBgsUCQgCBAESCBqCfwQCgX5NAy4BDpNekGcCgTmIYXaBMoMBAQEFgTYCDkG?= =?us-ascii?q?Ceg0Lgg4JgTiCY4JIhxcagUE/gRFDghg1PoIeSQEBAgEBGIELBBwEHCUGCYJ?= =?us-ascii?q?eM4Itj2yBc4YiJYpTj1FKCoJQiCaGCYJHgRCBa4Rzgl2BDodikgmOdYFOiWu?= =?us-ascii?q?CSo0NhBECBAIEBQIOAQEFgWkiDIFKcBUaIYJpCUcYDZBADBeDT4UUhUJ0AjU?= =?us-ascii?q?CAwMBBwEBAwl8jj8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,407,1583193600"; d="scan'208,217";a="494821355" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 May 2020 11:30:57 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 04IBUvQ8019844 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 May 2020 11:30:57 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 18 May 2020 06:30:57 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 18 May 2020 06:30:56 -0500 Received: from NAM11-CO1-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.1497.2 via Frontend Transport; Mon, 18 May 2020 06:30:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SqJ3iVLDhy/z/FkhyoF81FkeKhQmybgCGtUFNLuPVMTjDxyElgGApy8wbbGJDn7SUjhAFMXrcNoYo/VQDggOOzsYwlNKV0xeKO0/IBDlXwXQj8+q0fzup00p82bnr9bWGYr3zGonAlUSfpVyDB95Qo2OHi7W2EKaGWmbKnYsGetcRUWULa2uq0/TRxX/6PDIUWnyjth6x9AJ95p50O0s66pq0Ul2rOqmnGlTrEmR4MqW96dha02PdgOYOIq/CzKBjAlbpFpx/apNmRIiNJf3N/y7tCeRhl4vLgSXrw+9ITrFNfwdqHJzRStZCo5d77YImWs3Pj5D8JoVjgKGlL/SdA== 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=CLfdPicLZ0uoemAapw57mfE3XQ/i0brr1TFnErEfhlg=; b=axop9obBCmmA/4MTpSBuwewO6mvhJDPgAKYU5THCfWb2UVczaS/vzC84NwGl6dRXcyy+aLkVs6sirx3JB5EON6EG7jKMtVefsTbxIVQorGKDVsviW3AUPwOo130CqhwAtxfeeguk674dwDAsaLeQjCtJBF88+rqbYnxHPFViI+2w6A0HKTZatiAXkqHgeZO5eIE718FBGQKl6Z4FK1GhfmJX2tXJqu0FDpyqw9/vB06bOB3w+4IR1RPKI5UbfmZMdKtJWZTwhiY5L5M7ZrRmLMiQPZyQIgzwzoHId23C7Mc8AqdzpmMExojPiPA//JUNKCmWlK73roR5yqdaHrVeDA== 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=CLfdPicLZ0uoemAapw57mfE3XQ/i0brr1TFnErEfhlg=; b=MVr3Xz/stbSc6ZOgBy9xwLzdUgIO/xpAbDOv/X6hU/NLPg4cxBWLVHJm3nnmQm/EEIywPpiSTd0PaCGLW/e4HZ0zeuaJWL+mYqq7wLjdmk1kDS9aSR67MsBO6QxwxABHB1AkOpwP9AugrMgXFZXS4yOIrNjt2706friYrebj4w8= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4128.namprd11.prod.outlook.com (2603:10b6:208:139::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.26; Mon, 18 May 2020 11:30:55 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108%6]) with mapi id 15.20.3000.022; Mon, 18 May 2020 11:30:55 +0000 From: "Pascal Thubert (pthubert)" To: Rahul Jadhav , "Routing Over Low power and Lossy networks" , rabi narayan sahoo Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt Thread-Index: AQHV+Hcezq3im2uH30CiF/oY8K2vzahE/ZyggAAFM7yAAAXZkIAABcnzgAAN4ICAZtA3qYACMJ2w Date: Mon, 18 May 2020 11:30:46 +0000 Deferred-Delivery: Mon, 18 May 2020 11:29:59 +0000 Message-ID: References: <158402183564.18056.13091739917212256438@ietfa.amsl.com>, , , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: outlook.com; dkim=none (message not signed) header.d=none;outlook.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:f946:a028:fea9:3d4a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa690f4a-afc3-43af-3258-08d7fb1eedac x-ms-traffictypediagnostic: MN2PR11MB4128: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /ws2B+n+MPS4TkSS7pVoE1Hl20E+/Y3Jx5EYcJm9nmmC+HnBNx/K1JRoQkXnBlV0RyV6BD+MaQhdZrazE4bZNRaB02yYUrWOlgIw6ADvrKbwT0fqity/hyEMvt5IeJODvPjzyecLS00ltbGJaMrf+6PTTIJT6n+FZ/eFj8E2HDdyTeTHk7E52ZjOpCgz976drYYc5IjUITtve+w/tIxL95QcjXYPhW8arSS8lAAxQVVEO0KHYnrMis6z3tqa6V4AwYjWTzjYgOB6Npkru7BOpESIJl6jD0jQ3d1rzxQP+I3Q9T6Hsk/rR5Ld3OmEZTLY6DUa6nu0zOZEh2+qTpt19kPu2AedpDUCbF0nZ4x090cO5EYVoez0RtkNGB0nZ4PIvjBxEHDVLzdUPwrN4rc0LLxXIl3+2NbCfiVBy5tAFonTCw7PhANZn8KxcG46wYdr1YC2ckHruy0RFaugrpjBl+mvQIrtGDjK2jSo++5pdtGhspwibyQb3BMnPX2DuxafEI5Hfu3YH1F2odBdr6aqzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(136003)(376002)(366004)(6666004)(7696005)(15650500001)(86362001)(71200400001)(6506007)(53546011)(966005)(52536014)(186003)(66476007)(64756008)(66556008)(66446008)(5660300002)(8936002)(76116006)(110136005)(8676002)(66946007)(316002)(55016002)(45080400002)(166002)(66574014)(9686003)(33656002)(2906002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 7iwOiSgvQZm8h8g3aP8erzNAEx+o1eJm5S8XTQsoRKV4H1iE/NTrCE7mtsT5/7p0Gy5oLu6l49Th4mtirMqnt9Ssr11cIEUPC6qg5VqQsiZ7thg9WWwH0rNzGaN7HnbG2Ayj7j4zYdQkpS0IGTUWCWqEHHMdyPXdH8Sg6IUeVBdkT4F5bN+btnF6et+6RGr8MrmNHKKNTT3dvtYgQwtoAd2pC2K8CxMb6gNl87YpdBbXnZGNC9fl7STvjE03y/5odmoYb3i9/oRkw5TLdywMFK1qBgZxnP+NDNx0lfjg1CFYcSARo5eGu2PkSghM1GUPXtgG8d8hvX0+ZIOOs0JQ/sGlZTdZczlCuKdW3rmYQfQzpoZIqRr5I4zVx1exFAMjWxp3HaYpTpzQjXoUE5ypJ788ENxxuJ/xxpyHRmNpWm6X877Pc8u6yWn6zcl3yEqyk8yNHEICn+tYW+Fu0Ryqv78Xth5lToduNsM9qZ7tW158/A6tc9R+1kUl6DLSsKB8Vc4fQDbyh3CQ5xPzmptAulX0iDOEXsChbm3d/H0RbZXUeNlq8wpf1Hosz8xvB2ji x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565B875C1A28CA9C4714BBDD8B80MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa690f4a-afc3-43af-3258-08d7fb1eedac X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 11:30:54.9321 (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: qnYxJoVNbdIViCibb6NzcIOT0+OIt76vY8yfuokNn1JPsQeTNJBGRDKHS2/Fk9tZszg7PsC6Mldh0akYkyN8VA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4128 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.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: Mon, 18 May 2020 11:31:02 -0000 --_000_MN2PR11MB3565B875C1A28CA9C4714BBDD8B80MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUmFodWw6DQoNClRoZSBzaG9ydCBhbnN3ZXIgaXMgdGhhdCBiZWNhdXNlIHdlIGludHJv ZHVjZSBub24tc3RvcmluZyBzaWduYWxpbmcgYXQgdGhlIGVkZ2Ugb2YgYSBzdG9yaW5nIG1vZGUg RE9EQUcuDQpZb3UgbWF5IHNlZSBpdCBhcyBhbiBleHRlbnNpb24gb3V0c2lkZSBvZiB0aGUgUlBM IGRvbWFpbiB0aGF0IGlzIGNvdmVyZWQgYnkgdGhlIHJ1bGUgeW91IHBvaW50ZWQgb3V0Lg0KU2Vl IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtdXNlb2ZycGxpbmZv LTM4I3NlY3Rpb24tNC4xDQrigJwNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIFtSRkM2 NTUwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUwPl0gdG8gUkVDT01NRU5EIHRo YXQgZXh0ZXJuYWwNCiAgIHRhcmdldHMgYXJlIGFkdmVydGlzZWQgdXNpbmcgTm9uLVN0b3Jpbmcg TW9kZSBEQU8gbWVzc2FnaW5nIGV2ZW4gaW4gYQ0KICAgU3RvcmluZy1Nb2RlIG5ldHdvcmsuDQoN CuKAnA0KSXMgdGhhdCB5b3VyIGFuc3dlcj8NCg0KVGFrZSBjYXJlLA0KDQpQYXNjYWwNCg0KRnJv bTogUmFodWwgSmFkaGF2IDxueXJhaHVsQG91dGxvb2suY29tPg0KU2VudDogZGltYW5jaGUgMTcg bWFpIDIwMjAgMDQ6MjMNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBj aXNjby5jb20+OyBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9s bEBpZXRmLm9yZz47IHJhYmkgbmFyYXlhbiBzYWhvbyA8cmFiaW5hcmF5YW5zMDgyOEBnbWFpbC5j b20+DQpTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0DQoNCkhpIFBhc2NhbCwNCg0KUmV2aXNpdGluZyB0 aGlzIHRocmVhZCBiZWNhdXNlIG9mIHNvbWUgbmV3IGxpZ2h0IFsxXS4NCg0KUXVlc3Rpb24gaXMs IENhbiBhbiBSUEwgbm9kZSBpbiBTdG9yaW5nIE1PUCBzZW5kIGEgREFPIHdpdGggVHJhbnNpdCBJ bmZvIE9wdGlvbiB3aXRoIFBhcmVudCBBZGRyZXNzIHN1YmZpZWxkPw0KDQpQcmV2aW91c2x5LCB5 b3UgcG9pbnRlZCBvdXQgUkZDNjU1MCBzZWN0aW9uIDkuOCB3aGljaCBjbGVhcmx5IG1lbnRpb25z IHRoYXQgIlBhcmVudCBBZGRyZXNzIGluIFN0b3JpbmcgTU9QIE1VU1QgYmUgZW1wdHkiLg0KDQpI b3dldmVyLCBhcyBwZXIgU2VjdGlvbiA5LjQsIHRoZSBSRkMgc2F5cywgIkluIG9yZGVyIHRvIGlu amVjdCBzdWNoIGEgKGV4dGVybmFsKSBUYXJnZXQgaW4gdGhlIFJQTCBuZXR3b3JrLCB0aGUgcm91 dGVyIE1VU1QgYWR2ZXJ0aXNlIGl0c2VsZiBhcyB0aGUgRE9EQUcgUGFyZW50IEFkZHJlc3Mgc3Vi ZmllbGQgaW4gdGhlIFRyYW5zaXQuLi4iDQoNCkVzc2VudGlhbGx5IFNlY3Rpb24gOS40IGNvbnRy YWRpY3RzIDkuOCBib3RoIHVzaW5nIE1VU1QgY2xhdXNlcy4NCg0KSnVzdCBmb3IgdGhlIHJlY29y ZCwgdGhpcyBkaXNjdXNzaW9uIGRvZXMgbm90IGhhdmUgYW55IGltcGFjdCBvbiB0aGUgdW5hd2Fy ZS1sZWF2ZXMgZHJhZnQuDQoNCkJlc3QsDQpSYWh1bA0KDQpbMV0gbmV3IGxpZ2h0OiBSYWJpIGFj dHVhbGx5IGluZm9ybWVkIG1lIGFib3V0IHNlY3Rpb24gOS44IGluIGNvbnRleHQgdG8gYW5vdGhl ciBvZmZsaW5lIGRpc2N1c3Npb24gd3J0IFN0b3JpbmctUm9vdC1BY2suDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRo dWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+Pg0KU2VudDogMTMgTWFy Y2ggMjAyMCAxMjo0OSBBTQ0KVG86IFJhaHVsIEphZGhhdiA8bnlyYWh1bEBvdXRsb29rLmNvbTxt YWlsdG86bnlyYWh1bEBvdXRsb29rLmNvbT4+OyBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBM b3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtdW5h d2FyZS1sZWF2ZXMtMTAudHh0DQoNCg0KSGVsbG8gUmFodWwNCg0KDQoNClJGQyA2NTUwIHNheXM6 DQoNCg0KDQrigJwNCg0KDQoNCjkuODxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU1 MCNzZWN0aW9uLTkuOD4uICBTdG9yaW5nIE1vZGUNCg0KDQoNCg0KDQogICBJbiBTdG9yaW5nIG1v ZGUsIFJQTCByb3V0ZXMgbWVzc2FnZXMgRG93bndhcmQgYnkgdGhlIElQdjYgZGVzdGluYXRpb24N Cg0KICAgYWRkcmVzcy4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gbm9kZXMgdGhhdCBh cmUgaW4gU3RvcmluZw0KDQogICBtb2RlOg0KDQoNCg0KICAgMS4gIFRoZSBET0RBRyBQYXJlbnQg QWRkcmVzcyBzdWJmaWVsZCBvZiBhIFRyYW5zbWl0IEluZm9ybWF0aW9uDQoNCiAgICAgICBvcHRp b24gTVVTVCBiZSBlbXB0eS4NCg0KDQoNCg0KDQrigJwNCg0KDQoNClNvIGV2ZW4gaWYgaXQgaXMg YSBnb29kIGlkZWEgaXQgcmVxdWlyZXMgbmV3IHNwZWNzIHRvIG92ZXJyaWRlIFJGQyA2NTUwLg0K DQoNCg0KTW9yZSBiZWxvdyAodXNpbmcgUDI+KQ0KDQoNCg0KDQoNCkZyb206IFJhaHVsIEphZGhh diA8bnlyYWh1bEBvdXRsb29rLmNvbTxtYWlsdG86bnlyYWh1bEBvdXRsb29rLmNvbT4+DQpTZW50 OiBqZXVkaSAxMiBtYXJzIDIwMjAgMTY6MzINClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQp IDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+OyBSb3V0aW5n IE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxtYWlsdG86 cm9sbEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0DQoNCg0KDQoNCg0KDQoNCg0K DQpQbGVhc2UgZmluZCBiZWxvdyBpbmxpbmUgYW5zd2Vycy4gQWxzbywgSSBkaWQgbm90IGdldCBh bnkgb2JqZWN0aW9uIGZyb20gNmxvIHNvIEkgYWRkZWQgYSBJQU5BIHNlY3Rpb24gdGhhdCByZWR1 Y2VzIHRoZSBFQVJPIHN0YXR1cyByYW5nZSB0byAwLTYzLCB3aGljaCBzb2x2ZXMgdGhlIGlzc3Vl IHlvdSByYWlzZWQuDQoNCg0KDQpbUkpdIFllcCwgdGhhdCBpbmRlZWQgdGFrZXMgY2FyZSBvZiBh IG1ham9yIHBvaW50IPCfmIouIFBsZWFzZSBmaW5kIG15IFtSSl0gcmVzcG9uc2VzIGlubGluZS4N Cg0KDQoNCg0KDQoNCg0KUmVnYXJkaW5nIHRoaXMgc3RhdGVtZW50LA0KDQoiTm9uLVN0b3Jpbmcg TW9kZSBEQU8gbWVzc2FnZXMgYXJlIHVzZWQgdG8gc2lnbmFsIGV4dGVybmFsIHJvdXRlcyB0bw0K ICAgdGhlIFJvb3QsIGV2ZW4gaWYgdGhlIERPREFHIGlzIG9wZXJhdGVkIGluIFN0b3JpbmcgTW9k ZS4iDQoNCg0KDQpJIGNvdWxkbid0IGZpbmQgYW55IHRleHQgd2hpY2ggcHJvdmlkZXMgcmVhc29u aW5nIHRvIGRvIHNvLiBXaHkgbm9uLXN0b3JpbmcgbW9kZSBEQU8gaXMgbmVlZGVkIGFuZCB3aHkg c3RvcmluZyBtb2RlIERBTyB3b24ndCB3b3JrPw0KDQoNCg0KUGFzY2FsPiBXZSBuZWVkIHRoZSBh ZGRyZXNzIG9mIHRoZSA2TFIgdG8gdGVybWluYXRlIHRoZSB0dW5uZWwgYW5kIHJlbW92ZSB0aGUg YXJ0aWZhY3RzLCBhbmQgdGhlIE5TIHNpZ25hbGluZyB3aWxsIGdpdmUgdXMgdGhhdC4gVGhpcyBp cyBob3cgd2UgcmVtb3ZlZCB0aGUgaGFzc2xlIG9mIGhvcCBieSBob3AgbGluayBsb2NhbCB0dW5u ZWxzIHRoYXQgd2FzIGluIHRoZSBvbGQgdXNlb2ZycGxpbmZvLg0KDQoNCg0KVGhlcmUgaXMgdGhp cyB0ZXh0IHdoaWNoIHNheXMsICJUaGUgTm9uLVN0b3JpbmcgTW9kZSBEQU8gbWVzc2FnaW5nIGVu YWJsZXMgdG8gYWR2ZXJ0aXNlIHRoZSA2TFIgdGhhdCBzZXJ2ZXMgdGhlIFJVTCBhbmQgaW5qZWN0 cyB0aGUgcm91dGUgdG8gdGhlIFJvb3QuIiBUaGlzIGNhbiBiZSBhY2hpZXZlZCBldmVuIHdpdGgg c3RvcmluZyBtb2RlIERBTyB3aXRoIHRoZSB0YXJnZXQgYXMgUlVMIGFkZHJlc3MgYW5kIHRyYW5z aXQgaW5mb3JtYXRpb24gY29udGFpbmluZyBwYXJlbnQgYWRkcmVzcyBhcyBhbmNob3IgNkxSIGFk ZHJlc3MuDQoNCg0KDQpQYXNjYWwgPiBXaGljaCBpcyBub3QgdGhlIG5vcm1hbCBzdG9yaW5nIG1v ZGUgc2lnbmFsaW5nLg0KDQoNCg0KW1JKXSBZZXMsIGJ1dCA2NTUwIGRvZXMgbm90IHN0b3AgdXMg ZnJvbSBkb2luZyBpdC4gSW50ZXJlc3RpbmdseSwgSSBoYXZlIGEgdXNlLWNhc2UgaW4gbXkgZGVw bG95bWVudCB3aGVyZWluIEkgbmVlZCB0byBzZW5kIHRoaXMgcGFyZW50IGFkZHJlc3MgaW5mbyBl dmVuIGluIHN0b3JpbmcgTU9QLiBJdCBoZWxwcyB0aGUgcm9vdCBnZXQgdGhlIGNvbXBsZXRlIG5l dHdvcmsgZ3JhcGggZXZlbiBpbiBzdG9yaW5nIG1vZGUgZm9yIHZpc3VhbGl6YXRpb24gcHVycG9z ZXMgKGlmIHRoZSBhZG1pbiB3YW50cyB0byBjaGVjayBob3cgdGhlIG5ldHdvcmsgaXMgZm9ybWVk LCBob3cgbWFueSBob3BzIGV0YyBvbiB0aGUgcm9vdCBpbiBzdG9yaW5nIG1vZGUpLg0KDQoNCg0K UDI+IEl0IGRvZXMgYWN0dWFsbHksIHNlZSBhYm92ZQ0KDQoNCg0KSXQgd291bGQgYmUgYW4gaHli cmlkLiBUaGUgY29vbCB0aGluZyB3aXRoIE5TIGlzIHRoYXQgdGhlIGV4dGVybmFsIHByZWZpeGVz IGFyZSBub3QgdmlzaWJsZSBpbnNpZGUgdGhlIFJQTCBkb21haW4uIExlZ2FjeSBub2RlcyBkbyBu b3QgaGF2ZSB0byBrbm93IHRoZXkgZXhpc3QuIE9ubHkgdGhlIDZMUiBhdCB0aGUgYm9yZGVyIHRo YXQgaW5qZWN0IHRoZSBleHRlcm5hbCByb3V0ZXMgYW5kIHRoZSBSb290IGFyZSBhd2FyZSBhbmQg bmVlZCB0byBrbm93IGFib3V0IHRoZSBuZXcgc2lnbmFsaW5nLiBVc2luZyBhbiBoeWJyaWQgaW1w YWN0cyBldmVyeSBub2RlLg0KDQoNCg0KW1JKXSBUaGUgaHlicmlkIG1heSBub3QgbmVjZXNzYXJp bHkgaW1wYWN0IGV2ZXJ5IG5vZGUuIEFuIGludGVybWVkaWF0ZSA2TFIgbWF5IGRlY2lkZSB0byBp Z25vcmUgdGhhdCBleHRlcm5hbCB0YXJnZXQgaW4gdGhlIERBTyBhbmQgdGhhdCB3b3VsZCBzdGls bCBiZSBvay4gSW4gdGhpcyBjYXNlLCB0aGUgc2lnbmFsaW5nIHdpbGwgd29yayB0aHJvdWdoIG5l eHQgY29tbW9uIGFuY2VzdG9yIHdoaWNoIGhhcyB0byBjYXBhYmlsaXR5IHRvIGhvbGQvcHJvY2Vz cyB0aGF0IGtpbmQgb2YgaW5mby4NCg0KDQoNClAyPiB3aGljaCBpcyBzdGlsbCBhbiBpbXBhY3Q7 IG5ldyBjb2RlIHRvIHJlY29nbml6ZSB0aGUg4oCYReKAmSBmbGFnIGFuZCBkZWNpZGUgdG8gaWdu b3JlIHRoZSBhZGRyZXNzLiBBIGxlZ2FjeSBub2RlIHdvdWxkIG5vdCBkbyB0aGUgcmlnaHQgdGhp bmcuDQoNCg0KDQpUcnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcmVhc29uIGJlY2F1c2UgdGhpcyBt b2RlIG9mIHNpZ25hbGluZyBoYXMgaW1wbGljYXRpb25zIChhbHJlYWR5IGNvdmVyZWQgaW4gdGhl IGRyYWZ0KSwgcGFydGljdWxhcmx5IHRoYXQsIHdoZW4gdGhlIERBRyBpcyBvcGVyYXRpbmcgaW4g c3RvcmluZyBtb2RlLCB0aGUgY29tbXVuaWNhdGlvbiB0byBSVUwgZnJvbSBvdGhlciBSQU5zIHdv dWxkIG1hbmRhdG9yaWx5IGhhdmUgdG8gYmUgcm91dGVkIHRocm91Z2ggcm9vdCBvbmx5LiBJZiB3 ZSB1c2Ugc3RvcmluZyBtb2RlIERBTyB0aGVuIHRoaXMgY291bGQgYmUgb3B0aW1pemVkLiBOb3Qg c3VyZSBpZiBJIGFtIG1pc3NpbmcgYW55dGhpbmc/DQoNCg0KDQpQYXNjYWwgPiBXZWxsLCB5ZXMs IHdlIGNvdWxkIGhhdmUgZG9uZSB0aGF0IGFzIHdlbGwuIFRoZSBwYXRoIGNvdWxkIGJlIG9wdGlt aXplZCBidXQNCg0KKiAgaXQgd291bGQgbWVhbiB0aGF0IHRoZSBjb21tb24gcGFyZW50IGhhcyB0 byBlbmNhcHN1bGF0ZSB0byB0aGUgNkxSLCB3aGljaCBpcyBhbiBhZGRpdGlvbmFsIGZ1bmN0aW9u IHRoZXJlDQoNCiogSXQgd291bGQgYWxzbyBtZWFuIHRoYXQgdGhlIG5ldHdvcmsgaGFzIG90IGJl IGF3YXJlIG9mIGV4dGVybmFsIHJvdXRlcywgd2hpY2ggbWF5IGJlIHRvbyBtYW55IGZvciB0aGUg U00gdGFibGVzLg0KDQoNCg0KW1JKXSBJIGFtIGp1c3Qga2VlbiBvbiBkb2luZyB0aGlzIGJlY2F1 c2UgaXQgbWFrZXMgdGhpbmdzIGZsZXhpYmxlLiBBbmNob3IgNkxSIGhhcyBib3RoIG9wdGlvbnMg b2Ygc2VuZGluZyBOUy1EQU8gb3Igc3RvcmluZyBEQU8uIEludGVybWVkaWF0ZSA2TFJzIGFsc28g aGF2ZSBib3RoIG9wdGlvbnMsIGhvbm9yIHRoZSBleHRlcm5hbCB0YXJnZXQgaW5mbyBvciBpZ25v cmUgaXQgYW5kIGp1c3QgcGFzcyBpdCBvbi4NCg0KDQoNClAyPiBJ4oCZbSBoYXBweSB0byBkaXNj dXNzIGl0IGFuZCBzZWUgaWYgYW5kIGhvdyB3ZSBvcGVuIFJQTCBpbiB0aGF0IGRpcmVjdGlvbi4g QnV0IGZvciBzaG9ydCB0ZXJtIHdl4oCZcmUgc2hpcHBpbmcgdXNlb2ZycGxpbmZvIGFuZCBSVUwg d2l0aCB0aGUgbG93IGhhbmdpbmcgZnJ1aXQuDQoNCg0KDQpQcm9zIGFuZCBjb25zIEkgZ3Vlc3Mu IFdlIHdlbnQgZm9yIHRoZSBzaW1wbGUgYW5kIGJhY2t3YXJkIGNvbXBhdGlibGUgd2F5Lg0KDQoN Cg0KW1JKXSBZZXMsIEJhY2t3YXJkIGNvbXBhdGliaWxpdHkgbWF5IGJlIGFuIGlzc3VlIGJlY2F1 c2UgaW50ZXJtZWRpYXRlIDZMUnMgb3BlcmF0aW5nIGluIHB1cmUgc3RvcmluZyBtb2RlIHdpbGwg dHJ5IHRvIGNhY2hlIHRoZSBleHRlcm5hbCB0YXJnZXQgYW5kIG1heSBub3QgYmUgYWJsZSB0byBk byBJUC1pbi1JUCBhdCB0aGVpciBwb2ludC4gSG93ZXZlciwgaGFuZGxpbmcgdGhpcyBjb21wYXRp YmlsaXR5IG1heSBub3QgYmUgYSBiaWcgY2hhbGxlbmdlLiBUaGUgZmxleGliaWxpdHkgdGhpcyBw cm92aWRlcyBpcyB2ZXJ5IGNvbXBlbGxpbmcgdG8gbWUuIFdpdGggREFPIHByb2plY3Rpb24sIHdl IGhhdmUgYWxyZWFkeSBlbnRlcmVkIHRoYXQgem9uZSB3aGVyZSB0aGUgbm9kZXMgY291bGQgYmUg aHlicmlkIGluIG5hdHVyZS4NCg0KDQoNClBUMj4gd2l0aCB0aGUgY2FwYWJpbGl0eSB3b3JrIHdl 4oCZbGwgYmUgYWJsZSB0byBpbnRyb2R1Y2UgdGhpcyBhbmQgbW9yZSA6ICkNCg0KDQoNCg0KDQpU YWtlIGNhcmUsDQoNCg0KDQpQYXNjYWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpyb2xsLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRo dWJlcnQ9NDBjaXNjby4uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpwdGh1YmVydD00MGNpc2Nv Li5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KU2VudDogMTIgTWFyY2ggMjAyMCAwNzozOCBQTQ0KVG86 IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3Jn PG1haWx0bzpyb2xsQGlldGYub3JnPj4NClN1YmplY3Q6IFtSb2xsXSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0DQoN Cg0KDQpEZWFyIGFsbA0KDQpBcyBkaXNjdXNzZWQgd2l0aCB0aGUgSU9UIERJUiwgdGhpcyBkcmFm dCBpcyBub3QgdGhlIGdhdGluZyBmYWN0b3IgZm9yIGFsbCBjbHVzdGVyIEMzMTAuDQpJbiBvcmRl ciB0byBwcm9ncmVzcyBJIG1hZGUgYSBmdWxsIHBhc3Mgb24gaXQgYW5kIGZpeGVkIGEgZmV3IGJ1 Z3MgYW5kIG1pc2FsaWdubWVudHMgd2l0aCB1c2VvZnJwbGluZm8uDQoNCkkgYmVsaWV2ZSB0aGUg ZG9jIGlzIHJpcGUgZm9yIFdHTEMuDQoNCk1hbnkgdGhhbmtzDQoNClBhc2NhbA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpTZW50OiBqZXVkaSAxMiBtYXJzIDIwMjAg MTU6MDQNClRvOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWls dG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj47IE1pY2hhZWwgQy4gUmljaGFyZHNvbiA8bWNyK2ll dGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+PjsgUGFzY2FsIFRo dWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNj by5jb20+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJlcnQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVz DQpSZXZpc2lvbjogICAgICAgMTANClRpdGxlOiAgICAgICAgICBSb3V0aW5nIGZvciBSUEwgTGVh dmVzDQpEb2N1bWVudCBkYXRlOiAgMjAyMC0wMy0xMg0KR3JvdXA6ICAgICAgICAgIHJvbGwNClBh Z2VzOiAgICAgICAgICAzMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y b2xsLXVuYXdhcmUtbGVhdmVzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTA8aHR0cHM6Ly90b29scy5p ZXRmLi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTA+DQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LXJvbGwtdW5hd2FyZS1sZWF2ZXMNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwDQoNCkFic3Ry YWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGV4dGVuZHMgUkZDNjU1MCBhbmQgUkZDODUwNSB0 byBwcm92aWRlIHVuaWNhc3QgYW5kDQogICBtdWx0aWNhc3Qgcm91dGluZyBzZXJ2aWNlcyBpbiBh IFJQTCBkb21haW4gdG8gNkxOcyB0aGF0IGFyZSBwbGFpbg0KICAgSG9zdHMgYW5kIGRvIG5vdCBw YXJ0aWNpcGF0ZSB0byBSUEwsIGFuZCBlbmFibGVzIHRoZSBSUEwgUm9vdCB0bw0KICAgcHJveHkg dGhlIEVEQVIvRURBQyBmbG93IG9uIGJlaGFsZiBvZiB0aGUgUlVMcyBhbmQgUkFOcyBpbiBpdHMg RE9EQUcuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== --_000_MN2PR11MB3565B875C1A28CA9C4714BBDD8B80MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KaDMNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTMuNXB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28t c3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUYzNzYzO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnAueG1zb25vcm1hbCwgbGkueG1zb25vcm1hbCwgZGl2Lnhtc29ub3Jt YWwNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29ub3JtYWw7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLnhtc29ub3JtYWwwLCBsaS54bXNvbm9ybWFsMCwgZGl2Lnhtc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOnhfbXNvbm9ybWFsMDsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnAueHhtc29ub3JtYWwsIGxpLnh4bXNvbm9ybWFsLCBkaXYu eHhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eF94bXNvbm9ybWFsOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC54bXNvY2hwZGVmYXVsdCwgbGkueG1zb2NocGRl ZmF1bHQsIGRpdi54bXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp4X21zb2NocGRlZmF1 bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLnhtc29oeXBl cmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29oeXBlcmxpbms7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueG1zb2h5cGVybGlua2ZvbGxvd2VkDQoJ e21zby1zdHlsZS1uYW1lOnhfbXNvaHlwZXJsaW5rZm9sbG93ZWQ7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi54aGVhZGluZzNjaGFyDQoJe21zby1z dHlsZS1uYW1lOnhfaGVhZGluZzNjaGFyOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi54aHRtbHByZWZvcm1hdHRlZGNoYXINCgl7 bXNvLXN0eWxlLW5hbWU6eF9odG1scHJlZm9ybWF0dGVkY2hhcjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4ueGVtYWlsc3R5bGUyMg0KCXttc28tc3R5bGUtbmFtZTp4X2VtYWls c3R5bGUyMjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4ueGVtYWlsc3R5bGUyMw0KCXttc28tc3R5bGUtbmFtZTp4X2VtYWlsc3R5 bGUyMzsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvIFJhaHVsOjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgc2hvcnQgYW5z d2VyIGlzIHRoYXQgYmVjYXVzZSB3ZSBpbnRyb2R1Y2Ugbm9uLXN0b3Jpbmcgc2lnbmFsaW5nIGF0 IHRoZSBlZGdlIG9mIGEgc3RvcmluZyBtb2RlIERPREFHLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WW91IG1heSBzZWUgaXQgYXMgYW4gZXh0 ZW5zaW9uIG91dHNpZGUgb2YgdGhlIFJQTCBkb21haW4gdGhhdCBpcyBjb3ZlcmVkIGJ5IHRoZSBy dWxlIHlvdSBwb2ludGVkIG91dC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcm9sbC11c2VvZnJwbGluZm8tMzgjc2VjdGlvbi00LjEiPg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC11c2VvZnJwbGluZm8tMzgjc2Vj dGlvbi00LjE8L2E+IDxvOnA+DQo8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgWzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUwIiB0aXRsZT0iJnF1b3Q7UlBMOiBJUHY2IFJvdXRp bmcgUHJvdG9jb2wgZm9yIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MmcXVvdDsiPlJGQzY1 NTA8L2E+XQ0KIHRvIFJFQ09NTUVORCB0aGF0IGV4dGVybmFsPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRhcmdldHMgYXJlIGFkdmVydGlzZWQgdXNp bmcgTm9uLVN0b3JpbmcgTW9kZSBEQU8gbWVzc2FnaW5nIGV2ZW4gaW4gYTxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBTdG9yaW5nLU1vZGUgbmV0d29y ay4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPklzIHRoYXQgeW91ciBhbnN3ZXI/PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRha2UgY2FyZSw8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGFzY2FsPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPiBSYWh1bCBKYWRo YXYgJmx0O255cmFodWxAb3V0bG9vay5jb20mZ3Q7DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBkaW1hbmNoZSAxNyBtYWkgMjAyMCAwNDoy Mzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDtwdGh1YmVydEBjaXNjby5jb20mZ3Q7OyBSb3V0 aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9sbEBpZXRmLm9yZyZn dDs7IHJhYmkgbmFyYXlhbiBzYWhvbyAmbHQ7cmFiaW5hcmF5YW5zMDgyOEBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwv Yj4gUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdh cmUtbGVhdmVzLTEwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhp IFBhc2NhbCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJldmlzaXRpbmcgdGhpcyB0aHJl YWQgYmVjYXVzZSBvZiBzb21lIG5ldyBsaWdodCBbMV0uPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxh Y2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5RdWVzdGlvbiBpcywgQ2FuIGFuIFJQTCBub2RlIGluIFN0b3JpbmcgTU9QIHNlbmQgYSBE QU8gd2l0aCBUcmFuc2l0IEluZm8gT3B0aW9uIHdpdGggUGFyZW50IEFkZHJlc3Mgc3ViZmllbGQ/ PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5QcmV2aW91c2x5LCB5b3UgcG9pbnRlZCBvdXQg UkZDNjU1MCBzZWN0aW9uIDkuOCB3aGljaCBjbGVhcmx5IG1lbnRpb25zIHRoYXQgJnF1b3Q7UGFy ZW50IEFkZHJlc3MgaW4gU3RvcmluZyBNT1AgTVVTVCBiZSBlbXB0eSZxdW90Oy4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhvd2V2ZXIsIGFzIHBlciBTZWN0aW9uIDkuNCwgdGhl IFJGQyBzYXlzLCAmcXVvdDtJbiBvcmRlciB0byBpbmplY3Qgc3VjaCBhIChleHRlcm5hbCkgVGFy Z2V0IGluIHRoZSBSUEwgbmV0d29yaywgdGhlIHJvdXRlciBNVVNUIGFkdmVydGlzZSBpdHNlbGYg YXMgdGhlIERPREFHDQogUGFyZW50IEFkZHJlc3Mgc3ViZmllbGQgaW4gdGhlIFRyYW5zaXQuLi4m cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkVzc2VudGlhbGx5IFNlY3Rpb24gOS40 IGNvbnRyYWRpY3RzIDkuOCBib3RoIHVzaW5nIE1VU1QgY2xhdXNlcy48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNv bG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkp1c3QgZm9yIHRoZSByZWNvcmQsIHRoaXMgZGlzY3Vzc2lvbiBkb2VzIG5v dCBoYXZlIGFueSBpbXBhY3Qgb24gdGhlIHVuYXdhcmUtbGVhdmVzIGRyYWZ0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJs YWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+UmFodWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlsxXSBuZXcgbGlnaHQ6IFJh YmkgYWN0dWFsbHkgaW5mb3JtZWQgbWUgYWJvdXQgc2VjdGlvbiA5LjggaW4gY29udGV4dCB0byBh bm90aGVyIG9mZmxpbmUgZGlzY3Vzc2lvbiB3cnQgU3RvcmluZy1Sb290LUFjay48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPg0KPGhyIHNpemU9IjIiIHdp ZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgaWQ9 ImRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjaztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IGNvbG9yPSJibGFjayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+cHRo dWJlcnRAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiAxMyBNYXJjaCAyMDIwIDEyOjQ5IEFNPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IFJhaHVsIEphZGhhdiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm55cmFodWxAb3V0bG9vay5jb20iPm55cmFodWxAb3V0bG9vay5j b208L2E+Jmd0OzsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0 OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBS RTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1s ZWF2ZXMtMTAudHh0PC9zcGFuPjwvZm9udD4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5I ZWxsbyBSYWh1bDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieG1zb25v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPlJGQyA2NTUwIHNheXM6PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCcPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NTUwI3NlY3Rpb24tOS44Ij48Yj48Zm9udCBzaXplPSI0IiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+OS44PC9zcGFuPjwvZm9udD48L2I+ PC9hPjwvc3Bhbj48L2ZvbnQ+PGEgbmFtZT0ieF9zZWN0aW9uLTkuOCI+PC9hPjxiPjxmb250IHNp emU9IjQiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztmb250LXdlaWdodDpib2xkIj4uJm5i c3A7DQogU3RvcmluZyBNb2RlPC9zcGFuPjwvZm9udD48L2I+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29u b3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJbiBT dG9yaW5nIG1vZGUsIFJQTCByb3V0ZXMgbWVzc2FnZXMgRG93bndhcmQgYnkgdGhlIElQdjYgZGVz dGluYXRpb248L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IGFkZHJlc3MuJm5ic3A7IFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gbm9kZXMgdGhh dCBhcmUgaW4gU3RvcmluZzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgbW9kZTo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyAxLiZuYnNwOyBUaGUgRE9EQUcgUGFyZW50IEFkZHJlc3Mgc3ViZmllbGQgb2YgYSBUcmFuc21p dCBJbmZvcm1hdGlvbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1z b25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW9uIE1VU1QgYmUgZW1wdHkuPC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+4oCcPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNv bm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+U28gZXZlbiBpZiBpdCBpcyBhIGdvb2QgaWRlYSBpdCByZXF1aXJl cyBuZXcgc3BlY3MgdG8gb3ZlcnJpZGUgUkZDIDY1NTAuPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TW9yZSBiZWxvdyAodXNpbmcg UDImZ3Q7KQ0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4 bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Inhtc29ub3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwv Zm9udD48L2I+IFJhaHVsIEphZGhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm55cmFodWxAb3V0bG9v ay5jb20iPm55cmFodWxAb3V0bG9vay5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gamV1ZGkgMTIgbWFycyAyMDIwIDE2 OjMyPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+ IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBj aXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7OyBSb3V0aW5nIE92ZXIgTG93IHBv d2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmci PnJvbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNp emU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9InhfZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0ieG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJTZWdv ZSBVSSBFbW9qaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iU2Vnb2UgVUkgRW1vamkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPlBsZWFzZSBmaW5kIGJl bG93IGlubGluZSBhbnN3ZXJzLiBBbHNvLCBJIGRpZCBub3QgZ2V0IGFueSBvYmplY3Rpb24gZnJv bSA2bG8gc28gSSBhZGRlZCBhIElBTkEgc2VjdGlvbiB0aGF0IHJlZHVjZXMgdGhlIEVBUk8gc3Rh dHVzDQogcmFuZ2UgdG8gMC02Mywgd2hpY2ggc29sdmVzIHRoZSBpc3N1ZSB5b3UgcmFpc2VkLjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJTZWdvZSBVSSBFbW9qaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1z ZXJpZiI+W1JKXSBZZXAsIHRoYXQgaW5kZWVkIHRha2VzIGNhcmUgb2YgYSBtYWpvciBwb2ludCZu YnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iU2Vnb2UgVUkgRW1vamkiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEy ODUyMjs8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlNlZ29lIFVJIEVtb2ppIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+Lg0K IFBsZWFzZSBmaW5kIG15IFtSSl0gcmVzcG9uc2VzIGlubGluZS48L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UmVnYXJkaW5nIHRo aXMgc3RhdGVtZW50LDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZx dW90O05vbi1TdG9yaW5nIE1vZGUgREFPIG1lc3NhZ2VzIGFyZSB1c2VkIHRvIHNpZ25hbCBleHRl cm5hbCByb3V0ZXMgdG88YnI+DQombmJzcDsgJm5ic3A7dGhlIFJvb3QsIGV2ZW4gaWYgdGhlIERP REFHIGlzIG9wZXJhdGVkIGluIFN0b3JpbmcgTW9kZS4mcXVvdDs8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj5JIGNvdWxkbid0IGZpbmQgYW55IHRleHQgd2hpY2ggcHJvdmlkZXMgcmVh c29uaW5nIHRvIGRvIHNvLiBXaHkgbm9uLXN0b3JpbmcgbW9kZSBEQU8gaXMgbmVlZGVkIGFuZCB3 aHkgc3RvcmluZyBtb2RlIERBTyB3b24ndCB3b3JrPw0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QYXNjYWwmZ3Q7IFdlIG5l ZWQgdGhlIGFkZHJlc3Mgb2YgdGhlIDZMUiB0byB0ZXJtaW5hdGUgdGhlIHR1bm5lbCBhbmQgcmVt b3ZlIHRoZSBhcnRpZmFjdHMsIGFuZCB0aGUgTlMgc2lnbmFsaW5nIHdpbGwgZ2l2ZSB1cyB0aGF0 LiBUaGlzIGlzIGhvdyB3ZSByZW1vdmVkIHRoZSBoYXNzbGUgb2YgaG9wIGJ5DQogaG9wIGxpbmsg bG9jYWwgdHVubmVscyB0aGF0IHdhcyBpbiB0aGUgb2xkIHVzZW9mcnBsaW5mby48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+VGhlcmUgaXMgdGhpcyB0ZXh0IHdoaWNoIHNheXMsICZx dW90O1RoZSBOb24tU3RvcmluZyBNb2RlIERBTyBtZXNzYWdpbmcgZW5hYmxlcyB0byBhZHZlcnRp c2UgdGhlIDZMUiB0aGF0Jm5ic3A7c2VydmVzIHRoZSBSVUwgYW5kIGluamVjdHMgdGhlIHJvdXRl IHRvIHRoZSBSb290LiZxdW90Ow0KIFRoaXMgY2FuIGJlIGFjaGlldmVkIGV2ZW4gd2l0aCBzdG9y aW5nIG1vZGUgREFPIHdpdGggdGhlIHRhcmdldCBhcyBSVUwgYWRkcmVzcyBhbmQgdHJhbnNpdCBp bmZvcm1hdGlvbiBjb250YWluaW5nIHBhcmVudCBhZGRyZXNzIGFzIGFuY2hvciA2TFIgYWRkcmVz cy48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBhc2NhbCAmZ3Q7IFdoaWNoIGlzIG5vdCB0aGUgbm9y bWFsIHN0b3JpbmcgbW9kZSBzaWduYWxpbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUkpdIFllcywgYnV0IDY1 NTAgZG9lcyBub3Qgc3RvcCB1cyBmcm9tIGRvaW5nIGl0LiBJbnRlcmVzdGluZ2x5LCBJIGhhdmUg YSB1c2UtY2FzZSBpbiBteSBkZXBsb3ltZW50IHdoZXJlaW4gSSBuZWVkIHRvIHNlbmQgdGhpcyBw YXJlbnQgYWRkcmVzcyBpbmZvIGV2ZW4gaW4gc3RvcmluZyBNT1AuIEl0DQogaGVscHMgdGhlIHJv b3QgZ2V0IHRoZSBjb21wbGV0ZSBuZXR3b3JrIGdyYXBoIGV2ZW4gaW4gc3RvcmluZyBtb2RlIGZv ciB2aXN1YWxpemF0aW9uIHB1cnBvc2VzIChpZiB0aGUgYWRtaW4gd2FudHMgdG8gY2hlY2sgaG93 IHRoZSBuZXR3b3JrIGlzIGZvcm1lZCwgaG93IG1hbnkgaG9wcyBldGMgb24gdGhlIHJvb3QgaW4g c3RvcmluZyBtb2RlKS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4 bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAyJmd0OyBJdCBkb2VzIGFjdHVhbGx5LCBzZWUgYWJvdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkl0IHdvdWxkIGJlIGFuIGh5YnJpZC4gVGhlIGNvb2wgdGhpbmcgd2l0aCBOUyBpcyB0 aGF0IHRoZSBleHRlcm5hbCBwcmVmaXhlcyBhcmUgbm90IHZpc2libGUgaW5zaWRlIHRoZSBSUEwg ZG9tYWluLiBMZWdhY3kgbm9kZXMgZG8gbm90IGhhdmUgdG8ga25vdyB0aGV5IGV4aXN0LiBPbmx5 IHRoZSA2TFINCiBhdCB0aGUgYm9yZGVyIHRoYXQgaW5qZWN0IHRoZSBleHRlcm5hbCByb3V0ZXMg YW5kIHRoZSBSb290IGFyZSBhd2FyZSBhbmQgbmVlZCB0byBrbm93IGFib3V0IHRoZSBuZXcgc2ln bmFsaW5nLiBVc2luZyBhbiBoeWJyaWQgaW1wYWN0cyBldmVyeSBub2RlLjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+W1JKXSBU aGUgaHlicmlkIG1heSBub3QgbmVjZXNzYXJpbHkgaW1wYWN0IGV2ZXJ5IG5vZGUuIEFuIGludGVy bWVkaWF0ZSA2TFIgbWF5IGRlY2lkZSB0byBpZ25vcmUgdGhhdCBleHRlcm5hbCB0YXJnZXQgaW4g dGhlIERBTyBhbmQgdGhhdCB3b3VsZCBzdGlsbCBiZSBvay4gSW4gdGhpcyBjYXNlLCB0aGUNCiBz aWduYWxpbmcgd2lsbCB3b3JrIHRocm91Z2ggbmV4dCBjb21tb24gYW5jZXN0b3Igd2hpY2ggaGFz IHRvIGNhcGFiaWxpdHkgdG8gaG9sZC9wcm9jZXNzIHRoYXQga2luZCBvZiBpbmZvLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UDImZ3Q7IHdoaWNoIGlzIHN0aWxsIGFuIGltcGFjdDsgbmV3IGNvZGUgdG8gcmVjb2du aXplIHRoZSDigJhF4oCZIGZsYWcgYW5kIGRlY2lkZSB0byBpZ25vcmUgdGhlIGFkZHJlc3MuIEEg bGVnYWN5IG5vZGUgd291bGQgbm90IGRvIHRoZSByaWdodCB0aGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4eG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+VHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhl IHJlYXNvbiBiZWNhdXNlIHRoaXMgbW9kZSBvZiBzaWduYWxpbmcgaGFzIGltcGxpY2F0aW9ucyAo YWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBkcmFmdCksIHBhcnRpY3VsYXJseSB0aGF0LCB3aGVuIHRo ZSBEQUcgaXMNCiBvcGVyYXRpbmcgaW4gc3RvcmluZyBtb2RlLCB0aGUgY29tbXVuaWNhdGlvbiB0 byBSVUwgZnJvbSBvdGhlciBSQU5zIHdvdWxkIG1hbmRhdG9yaWx5IGhhdmUgdG8gYmUgcm91dGVk IHRocm91Z2ggcm9vdCBvbmx5LiBJZiB3ZSB1c2Ugc3RvcmluZyBtb2RlIERBTyB0aGVuIHRoaXMg Y291bGQgYmUgb3B0aW1pemVkLiBOb3Qgc3VyZSBpZiBJIGFtIG1pc3NpbmcgYW55dGhpbmc/PC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5QYXNjYWwgJmd0OyBXZWxsLCB5ZXMsIHdlIGNvdWxkIGhhdmUgZG9uZSB0aGF0IGFzIHdl bGwuIFRoZSBwYXRoIGNvdWxkIGJlIG9wdGltaXplZCBidXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KiAmbmJzcDtpdCB3b3VsZCBtZWFu IHRoYXQgdGhlIGNvbW1vbiBwYXJlbnQgaGFzIHRvIGVuY2Fwc3VsYXRlIHRvIHRoZSA2TFIsIHdo aWNoIGlzIGFuIGFkZGl0aW9uYWwgZnVuY3Rpb24gdGhlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KiBJdCB3b3VsZCBhbHNvIG1lYW4g dGhhdCB0aGUgbmV0d29yayBoYXMgb3QgYmUgYXdhcmUgb2YgZXh0ZXJuYWwgcm91dGVzLCB3aGlj aCBtYXkgYmUgdG9vIG1hbnkgZm9yIHRoZSBTTSB0YWJsZXMuPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUkpdIEkgYW0ganVz dCBrZWVuIG9uIGRvaW5nIHRoaXMgYmVjYXVzZSBpdCBtYWtlcyB0aGluZ3MgZmxleGlibGUuIEFu Y2hvciA2TFIgaGFzIGJvdGggb3B0aW9ucyBvZiBzZW5kaW5nIE5TLURBTyBvciBzdG9yaW5nIERB Ty4gSW50ZXJtZWRpYXRlIDZMUnMgYWxzbyBoYXZlIGJvdGggb3B0aW9ucywgaG9ub3INCiB0aGUg ZXh0ZXJuYWwgdGFyZ2V0IGluZm8gb3IgaWdub3JlIGl0IGFuZCBqdXN0IHBhc3MgaXQgb24uPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5QMiZndDsgSeKAmW0gaGFwcHkgdG8gZGlzY3VzcyBpdCBhbmQgc2VlIGlmIGFuZCBob3cg d2Ugb3BlbiBSUEwgaW4gdGhhdCBkaXJlY3Rpb24uIEJ1dCBmb3Igc2hvcnQgdGVybSB3ZeKAmXJl IHNoaXBwaW5nIHVzZW9mcnBsaW5mbyBhbmQgUlVMIHdpdGggdGhlIGxvdyBoYW5naW5nIGZydWl0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UHJvcyBhbmQgY29ucyBJIGd1ZXNzLiBXZSB3ZW50IGZvciB0aGUgc2ltcGxlIGFu ZCBiYWNrd2FyZCBjb21wYXRpYmxlIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltSSl0gWWVzLCBCYWNrd2FyZCBjb21w YXRpYmlsaXR5IG1heSBiZSBhbiBpc3N1ZSBiZWNhdXNlIGludGVybWVkaWF0ZSA2TFJzIG9wZXJh dGluZyBpbiBwdXJlIHN0b3JpbmcgbW9kZSB3aWxsIHRyeSB0byBjYWNoZSB0aGUgZXh0ZXJuYWwg dGFyZ2V0IGFuZCBtYXkgbm90IGJlIGFibGUgdG8gZG8gSVAtaW4tSVANCiBhdCB0aGVpciBwb2lu dC4gSG93ZXZlciwgaGFuZGxpbmcgdGhpcyBjb21wYXRpYmlsaXR5IG1heSBub3QgYmUgYSBiaWcg Y2hhbGxlbmdlLiBUaGUgZmxleGliaWxpdHkgdGhpcyBwcm92aWRlcyBpcyB2ZXJ5IGNvbXBlbGxp bmcgdG8gbWUuIFdpdGggREFPIHByb2plY3Rpb24sIHdlIGhhdmUgYWxyZWFkeSBlbnRlcmVkIHRo YXQgem9uZSB3aGVyZSB0aGUgbm9kZXMgY291bGQgYmUgaHlicmlkIGluIG5hdHVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlBUMiZndDsgd2l0aCB0aGUgY2FwYWJpbGl0eSB3b3JrIHdl4oCZbGwgYmUgYWJsZSB0byBpbnRy b2R1Y2UgdGhpcyBhbmQgbW9yZSA6ICk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UYWtl IGNhcmUsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHht c29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0K PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgaWQ9InhfeF9kaXZScGx5RndkTXNnIj4NCjxwIGNs YXNzPSJ4eG1zb25vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjaztmb250LXdl aWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSJibGFjayI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gUm9sbCAmbHQ7PC9zcGFuPjwvZm9udD48YSBocmVmPSJt YWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj5yb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGZv bnQgY29sb3I9ImJsYWNrIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsNCiBvbiBiZWhh bGYgb2YgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7PC9zcGFuPjwvZm9udD48YSBocmVm PSJtYWlsdG86cHRodWJlcnQ9NDBjaXNjby4uY29tQGRtYXJjLmlldGYub3JnIj5wdGh1YmVydD00 MGNpc2NvLi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+PGZvbnQgY29sb3I9ImJsYWNrIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiAxMiBNYXJjaCAyMDIwIDA3OjM4IFBNPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IFJvdXRpbmcgT3ZlciBM b3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzICZsdDs8L3NwYW4+PC9mb250PjxhIGhyZWY9Im1h aWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPjxmb250IGNvbG9yPSJibGFjayI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gW1JvbGxdIEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMC50eHQ8L3Nw YW4+PC9mb250Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgYWxsPGJyPg0K PGJyPg0KQXMgZGlzY3Vzc2VkIHdpdGggdGhlIElPVCBESVIsIHRoaXMgZHJhZnQgaXMgbm90IHRo ZSBnYXRpbmcgZmFjdG9yIGZvciBhbGwgY2x1c3RlciBDMzEwLjxicj4NCkluIG9yZGVyIHRvIHBy b2dyZXNzIEkgbWFkZSBhIGZ1bGwgcGFzcyBvbiBpdCBhbmQgZml4ZWQgYSBmZXcgYnVncyBhbmQg bWlzYWxpZ25tZW50cyB3aXRoIHVzZW9mcnBsaW5mby48YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhl IGRvYyBpcyByaXBlIGZvciBXR0xDLjxicj4NCjxicj4NCk1hbnkgdGhhbmtzPGJyPg0KPGJyPg0K UGFzY2FsPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KU2VudDogamV1ZGkgMTIg bWFycyAyMDIwIDE1OjA0PGJyPg0KVG86IE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiPm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4u Y2E8L2E+Jmd0OzsgTWljaGFlbCBDLiBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNy JiM0MztpZXRmQHNhbmRlbG1hbi5jYSI+bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7 OyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRA Y2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0Ozxicj4NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEw LnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXJv bGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku PGJyPg0KPGJyPg0KTmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzPGJyPg0K UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwPGJyPg0KVGl0 bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJvdXRpbmcgZm9yIFJQTCBMZWF2ZXM8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDIwLTAz LTEyPGJyPg0KR3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJvbGw8YnI+DQpQYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzI8YnI+DQpVUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtdW5h d2FyZS1sZWF2ZXMtMTAudHh0Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0PC9hPjxicj4NClN0YXR1czom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUt bGVhdmVzLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJv bGwtdW5hd2FyZS1sZWF2ZXMvPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYuLm9yZy9odG1sL2Ry YWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMCI+DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwPC9hPjxicj4NCkh0bWxpemVk OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZl cyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcm9s bC11bmF3YXJlLWxlYXZlczwvYT48YnI+DQpEaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtdW5hd2Fy ZS1sZWF2ZXMtMTA8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7IFRo aXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIFJGQzY1NTAgYW5kIFJGQzg1MDUgdG8gcHJvdmlkZSB1 bmljYXN0IGFuZDxicj4NCiZuYnNwOyZuYnNwOyBtdWx0aWNhc3Qgcm91dGluZyBzZXJ2aWNlcyBp biBhIFJQTCBkb21haW4gdG8gNkxOcyB0aGF0IGFyZSBwbGFpbjxicj4NCiZuYnNwOyZuYnNwOyBI b3N0cyBhbmQgZG8gbm90IHBhcnRpY2lwYXRlIHRvIFJQTCwgYW5kIGVuYWJsZXMgdGhlIFJQTCBS b290IHRvPGJyPg0KJm5ic3A7Jm5ic3A7IHByb3h5IHRoZSBFREFSL0VEQUMgZmxvdyBvbiBiZWhh bGYgb2YgdGhlIFJVTHMgYW5kIFJBTnMgaW4gaXRzIERPREFHLjxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLjxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3Jn Ij5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR11MB3565B875C1A28CA9C4714BBDD8B80MN2PR11MB3565namp_-- From nobody Mon May 18 05:03:39 2020 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 1EC793A0B38 for ; Mon, 18 May 2020 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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_MSPIKE_H2=-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=outlook.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 t0tyqOZC9I6h for ; Mon, 18 May 2020 05:03:33 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255022.outbound.protection.outlook.com [40.92.255.22]) (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 2BBCB3A0B37 for ; Mon, 18 May 2020 05:03:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UsZ9+d2LNZU7d+i/yzwCQBAXYXAUTPpr/g5ze4C4Wv3UTUuYJ7oaTe3ZhoJ+7uX0GYbcGM/AkxM6twKKakMA8REP/WlxrbEWbwTBXfdpszL/AIpZDd/FDBAEYdxlExTJfH8UpsCXxi1aZlhkXhfx8feg3WR181xD5E2AS+XEfZuHokQtXI3+x21R4knmlm/vJkHhaQ/0nmcTS3YCV1Ybd7ZaMbDRvv+lcC4YP2V3hztUPHufu7qyiovePsAApr/TMNZ/DqerO5e8Rzz+D0FB7DXV0APKWJjDbCoToMJtkBtfC4e90bGyhRuYEyGZPfs/gjBNq8sVQHk/KztJGWdl3w== 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=ZTv0ZDvfAWcaXFWIE8G95FFGq3GAxbMvyDKgrCvRINI=; b=TuWFUh22/OeCcLaizf188mQCoPlZs5vCAmZ29YVMaRkOqOndMpYe1b9YRRU4eiImFLnIrhXX6sQZ4/xrAq9WPuWd+LVkOwg7Jro2bz0szuws975L+OxG6yJHO0doHnOrVOlmwqSZ5mEQst+wyP167UGlMt3Uu8rgzxxNnDvuuw1AMmqmXI69aFPH6hbTbaw+eIqSvb8dXzx0OjxgjDyCB7PO02ZU6hr/FA/udTjs+MajvBB50W+TuM69ipOBJReerCBCw+9qD0O9clpRH32vRFej4qVSxkDzOBp71zVrEwx5FH+wZIQY56l3zYtHDJ3fSMve9v27wjGLBeVZueyHYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZTv0ZDvfAWcaXFWIE8G95FFGq3GAxbMvyDKgrCvRINI=; b=Vw6+egS4poCUxOErPb+Tl5ZBd7vo+gO3Exx6GDTSu1/QiK+6ZHreuomEkDFaXqvC4BV2dNLjoMoInKteLDcEoTyoZRIGaIr5W+kVOkj6eypT2lIgmZZvIS77Wmrq12kKCsvxVg79ckbXFWGkmC11bgoxyZyzsOXcW8bvoPtXQsA1dDjsiZoJaLiHzgestrbgv4O80osr6ELl90VenhFJ/iW5CG9bgW2K6DrWVfpdJFlvAUsebYd6m8Fw45YGugUL3qmNTxj6qm6Ng823ktmuJsKnZW3EhyufcKsGQLTh6XA2CQrFTWdkFIItRikJk2F4JHQLuanZuiq2oiIE32iL+Q== Received: from SG2APC01FT116.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::4d) by SG2APC01HT072.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::275) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19; Mon, 18 May 2020 12:03:29 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.250.57) by SG2APC01FT116.mail.protection.outlook.com (10.152.250.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Mon, 18 May 2020 12:03:29 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3000.034; Mon, 18 May 2020 12:03:28 +0000 From: Rahul Jadhav To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks , rabi narayan sahoo Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt Thread-Index: AQHV+Hcezq3im2uH30CiF/oY8K2vzahE/ZyggAAFM7yAAAXZkIAABcnzgAAN4ICAZtA3qYACMJ2wgAAIIK4= Date: Mon, 18 May 2020 12:03:28 +0000 Message-ID: References: <158402183564.18056.13091739917212256438@ietfa.amsl.com>, , , , In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1E6E9DD222A06FA14B339573CF80E74C1232E1AACFB6C1761CCB9E55C84AD5E7; UpperCasedChecksum:C1DDAA39FFA9F3F1F7CDF7080E81678B5826748C1E8642AE2C0B4B7E1BF2C324; SizeAsReceived:7646; Count:44 x-tmn: [AVnRsWi2lPE/uroL0LVClBXsKLSDx/kC] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 2239e246-0be8-4713-2165-08d7fb237a1a x-ms-traffictypediagnostic: SG2APC01HT072: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8z3+O15zdNfcUZA9P0rQklMFx5XcVufEMjCyq1gUvg5mLwlc+rLr/Zq/Y+jf19pka4pLlEqQUvFLxs6ov28O3EA7mvXwv6OZxUtUkvkqQffB/wsR24onJ2Ubgf5dYKWdpK/nWoU9UMqHA8bdf09sHqik93Gx3Eow/nchVFswa0ijehubG2flr9/cPTkR4BLvJ008Jt8odt1tLQtj0ungazHepvCPGxexrq+IglZ/mEUuGwHJOsZtcQ1uEkqllYcg x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: auh9GVN5iHZRgkf/Q6wPVO3ohRHeKTDMsN4zVOF47CVfc+YM25osl5ga2AzbmukYpaWUoFMrvtLsApi40WlHsZX/Tv/IH9kGe328ly6KEp6APbHmmGxJXmrxtQ09Df/WnZ+0VGQ/z3R6AbUHfMen4A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB40202FD18C6153E47790C446A9B80BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 2239e246-0be8-4713-2165-08d7fb237a1a X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 12:03:28.6185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT072 Archived-At: Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.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: Mon, 18 May 2020 12:03:37 -0000 --_000_BM1PR01MB40202FD18C6153E47790C446A9B80BM1PR01MB4020INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So even in storing MOP a 6LN/6LR should use non-storing MOP signaling to se= nd the external routes to the root. I guess this is what is done in unaware= -leaves as well. This does answer my question. Many Thanks. For storing-root-ack, Rabi pointed out a case where the 6LN/6LR sends DAO o= n behalf of the unware-RPL node and we were wondering if we could make use = of parent address in storing MOP to signal the root about this external nod= e. I guess even in that case we can refer to unaware-leaves/useofrplinfo ra= tionale and send DAO for external targets directly to the root to keep the = handling consistent (and minimal changes). Thanks, Rahul ________________________________ From: Pascal Thubert (pthubert) Sent: 18 May 2020 07:30 PM To: Rahul Jadhav ; Routing Over Low power and Lossy ne= tworks ; rabi narayan sahoo Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hello Rahul: The short answer is that because we introduce non-storing signaling at the = edge of a storing mode DODAG. You may see it as an extension outside of the RPL domain that is covered by= the rule you pointed out. See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38#section-4.1 =93 This specification updates [RFC6550= ] to RECOMMEND that external targets are advertised using Non-Storing Mode DAO messaging even in a Storing-Mode network. =93 Is that your answer? Take care, Pascal From: Rahul Jadhav Sent: dimanche 17 mai 2020 04:23 To: Pascal Thubert (pthubert) ; Routing Over Low power = and Lossy networks ; rabi narayan sahoo Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hi Pascal, Revisiting this thread because of some new light [1]. Question is, Can an RPL node in Storing MOP send a DAO with Transit Info Op= tion with Parent Address subfield? Previously, you pointed out RFC6550 section 9.8 which clearly mentions that= "Parent Address in Storing MOP MUST be empty". However, as per Section 9.4, the RFC says, "In order to inject such a (exte= rnal) Target in the RPL network, the router MUST advertise itself as the DO= DAG Parent Address subfield in the Transit..." Essentially Section 9.4 contradicts 9.8 both using MUST clauses. Just for the record, this discussion does not have any impact on the unawar= e-leaves draft. Best, Rahul [1] new light: Rabi actually informed me about section 9.8 in context to an= other offline discussion wrt Storing-Root-Ack. ________________________________ From: Pascal Thubert (pthubert) > Sent: 13 March 2020 12:49 AM To: Rahul Jadhav >; Routing= Over Low power and Lossy networks > Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hello Rahul RFC 6550 says: =93 9.8. Storing Mode In Storing mode, RPL routes messages Downward by the IPv6 destination address. The following rules apply to nodes that are in Storing mode: 1. The DODAG Parent Address subfield of a Transmit Information option MUST be empty. =93 So even if it is a good idea it requires new specs to override RFC 6550. More below (using P2>) From: Rahul Jadhav > Sent: jeudi 12 mars 2020 16:32 To: Pascal Thubert (pthubert) >; Routing Over Low power and Lossy networks > Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Please find below inline answers. Also, I did not get any objection from 6l= o so I added a IANA section that reduces the EARO status range to 0-63, whi= ch solves the issue you raised. [RJ] Yep, that indeed takes care of a major point ??. Please find my [RJ] r= esponses inline. Regarding this statement, "Non-Storing Mode DAO messages are used to signal external routes to the Root, even if the DODAG is operated in Storing Mode." I couldn't find any text which provides reasoning to do so. Why non-storing= mode DAO is needed and why storing mode DAO won't work? Pascal> We need the address of the 6LR to terminate the tunnel and remove t= he artifacts, and the NS signaling will give us that. This is how we remove= d the hassle of hop by hop link local tunnels that was in the old useofrpli= nfo. There is this text which says, "The Non-Storing Mode DAO messaging enables = to advertise the 6LR that serves the RUL and injects the route to the Root.= " This can be achieved even with storing mode DAO with the target as RUL ad= dress and transit information containing parent address as anchor 6LR addre= ss. Pascal > Which is not the normal storing mode signaling. [RJ] Yes, but 6550 does not stop us from doing it. Interestingly, I have a = use-case in my deployment wherein I need to send this parent address info e= ven in storing MOP. It helps the root get the complete network graph even i= n storing mode for visualization purposes (if the admin wants to check how = the network is formed, how many hops etc on the root in storing mode). P2> It does actually, see above It would be an hybrid. The cool thing with NS is that the external prefixes= are not visible inside the RPL domain. Legacy nodes do not have to know th= ey exist. Only the 6LR at the border that inject the external routes and th= e Root are aware and need to know about the new signaling. Using an hybrid = impacts every node. [RJ] The hybrid may not necessarily impact every node. An intermediate 6LR = may decide to ignore that external target in the DAO and that would still b= e ok. In this case, the signaling will work through next common ancestor wh= ich has to capability to hold/process that kind of info. P2> which is still an impact; new code to recognize the =91E=92 flag and de= cide to ignore the address. A legacy node would not do the right thing. Trying to understand the reason because this mode of signaling has implicat= ions (already covered in the draft), particularly that, when the DAG is ope= rating in storing mode, the communication to RUL from other RANs would mand= atorily have to be routed through root only. If we use storing mode DAO the= n this could be optimized. Not sure if I am missing anything? Pascal > Well, yes, we could have done that as well. The path could be opti= mized but * it would mean that the common parent has to encapsulate to the 6LR, whic= h is an additional function there * It would also mean that the network has ot be aware of external routes, w= hich may be too many for the SM tables. [RJ] I am just keen on doing this because it makes things flexible. Anchor = 6LR has both options of sending NS-DAO or storing DAO. Intermediate 6LRs al= so have both options, honor the external target info or ignore it and just = pass it on. P2> I=92m happy to discuss it and see if and how we open RPL in that direct= ion. But for short term we=92re shipping useofrplinfo and RUL with the low = hanging fruit. Pros and cons I guess. We went for the simple and backward compatible way. [RJ] Yes, Backward compatibility may be an issue because intermediate 6LRs = operating in pure storing mode will try to cache the external target and ma= y not be able to do IP-in-IP at their point. However, handling this compati= bility may not be a big challenge. The flexibility this provides is very co= mpelling to me. With DAO projection, we have already entered that zone wher= e the nodes could be hybrid in nature. PT2> with the capability work we=92ll be able to introduce this and more : = ) Take care, Pascal ________________________________ From: Roll > on behalf = of Pascal Thubert (pthubert) > Sent: 12 March 2020 07:38 PM To: Routing Over Low power and Lossy networks > Subject: [Roll] FW: New Version Notification for draft-ietf-roll-unaware-le= aves-10.txt Dear all As discussed with the IOT DIR, this draft is not the gating factor for all = cluster C310. In order to progress I made a full pass on it and fixed a few bugs and misa= lignments with useofrplinfo. I believe the doc is ripe for WGLC. Many thanks Pascal -----Original Message----- From: internet-drafts@ietf.org > Sent: jeudi 12 mars 2020 15:04 To: Michael Richardson = >; Michael C. Richardson >; Pascal Thubert (pthubert) > Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-ietf-roll-unaware-leaves Revision: 10 Title: Routing for RPL Leaves Document date: 2020-03-12 Group: roll Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-ietf-roll-unawar= e-leaves-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-le= aves/ Htmlized: https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-= 10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-roll-unawa= re-leaves Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware= -leaves-10 Abstract: This specification extends RFC6550 and RFC8505 to provide unicast and multicast routing services in a RPL domain to 6LNs that are plain Hosts and do not participate to RPL, and enables the RPL Root to proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_BM1PR01MB40202FD18C6153E47790C446A9B80BM1PR01MB4020INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
So even in storing MOP a 6LN/6LR should use non-sto= ring MOP signaling to send the external routes to the root. I guess this is= what is done in unaware-leaves as well.

= This does answer my question. Many Thanks.
=
= For storing-root-ack, Rabi pointed out a case where the 6LN/6LR sends DAO on behalf of the unware-RPL node and we= were wondering if we could make use of parent address in storing MOP to si= gnal the root about this external node. I guess even in that case we can re= fer to unaware-leaves/useofrplinfo rationale and send DAO for external targets directly to the root to keep t= he handling consistent (and minimal changes).
=
= Thanks,
= Rahul
From: Pascal Thubert (pthub= ert) <pthubert@cisco.com>
Sent: 18 May 2020 07:30 PM
To: Rahul Jadhav <nyrahul@outlook.com>; Routing Over Low power= and Lossy networks <roll@ietf.org>; rabi narayan sahoo <rabinaray= ans0828@gmail.com>
Subject: RE: New Version Notification for draft-ietf-roll-unaware-le= aves-10.txt
 

Hello Rahul:

 

The short answer is that because we introduce non-storing = signaling at the edge of a storing mode DODAG.

You may see it as an extension outside of the RPL domain t= hat is covered by the rule you pointed out.

See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38#section-4.1=

=93

   Thi= s specification updates [RFC6550] to RECOMMEND that external

   tar= gets are advertised using Non-Storing Mode DAO messaging even in a

   Sto= ring-Mode network.

 

=93

Is that your answer?

 

Take care,

 

Pascal

 

From: Rahul Jadha= v <nyrahul@outlook.com>
Sent: dimanche 17 mai 2020 0= 4:23
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; Routing Over Low power and Lossy networks <= ;roll@ietf.org>; rabi narayan sahoo <rabinarayans0828@gmail.com> Subject: Re: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

= Hi Pascal,

=  

= Revisiting this thread becaus= e of some new light [1].

=  

= Question is, Can an RPL node = in Storing MOP send a DAO with Transit Info Option with Parent Address subf= ield?

=  

= Previously, you pointed out R= FC6550 section 9.8 which clearly mentions that "Parent Address in Stor= ing MOP MUST be empty". 

=  

= However, as per Section 9.4, = the RFC says, "In order to inject such a (external) Target in the RPL = network, the router MUST advertise itself as the DODAG Parent Address subfield in the Transit..."

=  

= Essentially Section 9.4 contr= adicts 9.8 both using MUST clauses.

=  

= Just for the record, this dis= cussion does not have any impact on the unaware-leaves draft.=

=  

= Best,

= Rahul

=  

= [1] new light: Rabi actually = informed me about section 9.8 in context to another offline discussion wrt = Storing-Root-Ack.

From: Pascal Th= ubert (pthubert) <pthubert@cisco.c= om>
Sent: 13 March 2020 12:49 AM=
To: Rahul Jadhav <nyrahul@outlook.com>; Routing Over L= ow power and Lossy networks <roll@ietf.= org>
Subject: RE: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

Hello Rahul

 

RFC 6550 says:

 

=93

 

9.8<= /b>.  Storing Mode

 

 

   In = Storing mode, RPL routes messages Downward by the IPv6 destination

   add= ress.  The following rules apply to nodes that are in Storing

   mod= e:

 

   1.&= nbsp; The DODAG Parent Address subfield of a Transmit Information

  &nbs= p;    option MUST be empty.

 

 

=93

 

So even if it is a good idea it requires new specs to ove= rride RFC 6550.

 

More below (using P2>)

 

 

From: Rahul Jadha= v <nyrahul@outlook.com>
Sent: jeudi 12 mars 2020 16:= 32
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; Rou= ting Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

 

 

 

😊. Please find my [RJ] responses inline.

 

 

 

Regarding this statement,

"Non-Storing Mode DAO = messages are used to signal external routes to
   the Root, even if the DODAG is operated in Storing Mode."=

 

I couldn't find any text wh= ich provides reasoning to do so. Why non-storing mode DAO is needed and why= storing mode DAO won't work?

 

Pascal> We need the address of the 6LR to terminate t= he tunnel and remove the artifacts, and the NS signaling will give us that.= This is how we removed the hassle of hop by hop link local tunnels that was in the old useofrplinfo.

 

There is this text which sa= ys, "The Non-Storing Mode DAO messaging enables to advertise the 6LR t= hat serves the RUL and injects the route to the Root." This can be achieved even with storing mode DAO with the targe= t as RUL address and transit information containing parent address as ancho= r 6LR address.

 

Pascal > Which is not the normal storing mode signali= ng. 

 

[RJ] Yes, but 6550 does not stop us from doing it. Inter= estingly, I have a use-case in my deployment wherein I need to send this pa= rent address info even in storing MOP. It helps the root get the complete network graph even in storing mode for vis= ualization purposes (if the admin wants to check how the network is formed,= how many hops etc on the root in storing mode).

 

P2> It does actually, see above

 

It would be an hybrid. The cool thing with NS is that th= e external prefixes are not visible inside the RPL domain. Legacy nodes do = not have to know they exist. Only the 6LR at the border that inject the external routes and the Root are aware and n= eed to know about the new signaling. Using an hybrid impacts every node.

 

[RJ] The hybrid may not necessarily impact every node. A= n intermediate 6LR may decide to ignore that external target in the DAO and= that would still be ok. In this case, the signaling will work through next common ancestor which has to capability t= o hold/process that kind of info. 

 

P2> which is still an impact; new code to recognize t= he =91E=92 flag and decide to ignore the address. A legacy node would not d= o the right thing.

 

Trying to understand the re= ason because this mode of signaling has implications (already covered in th= e draft), particularly that, when the DAG is operating in storing mode, the communication to RUL from other RANs wou= ld mandatorily have to be routed through root only. If we use storing mode = DAO then this could be optimized. Not sure if I am missing anything?=

 

Pascal > Well, yes, we could have done that as well. = The path could be optimized but

*  it would mean that the common parent has to enca= psulate to the 6LR, which is an additional function there

* It would also mean that the network has ot be aware of= external routes, which may be too many for the SM tables.

 

[RJ] I am just keen on doing this because it makes thing= s flexible. Anchor 6LR has both options of sending NS-DAO or storing DAO. I= ntermediate 6LRs also have both options, honor the external target info or ignore it and just pass it on.

 

P2> I=92m happy to discuss it and see if and how we o= pen RPL in that direction. But for short term we=92re shipping useofrplinfo= and RUL with the low hanging fruit.

 

Pros and cons I guess. We went for the simple and backwa= rd compatible way.

 

[RJ] Yes, Backward compatibility may be an issue because= intermediate 6LRs operating in pure storing mode will try to cache the ext= ernal target and may not be able to do IP-in-IP at their point. However, handling this compatibility may not be a big chal= lenge. The flexibility this provides is very compelling to me. With DAO pro= jection, we have already entered that zone where the nodes could be hybrid = in nature.

 

PT2> with the capability work we=92ll be able to intr= oduce this and more : )

 

 

Take care,

 

Pascal

From:<= /span> Roll &l= t;roll-bounces@ietf.= org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco..com@dmarc.ietf= .org>
Sent: 12 March 2020 07:38 PM=
To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: [Roll] FW: New Vers= ion Notification for draft-ietf-roll-unaware-leaves-10.txt

 

Dear all

As discussed with the IOT DIR, this draft is not the gating factor for all = cluster C310.
In order to progress I made a full pass on it and fixed a few bugs and misa= lignments with useofrplinfo.

I believe the doc is ripe for WGLC.

Many thanks

Pascal

-----Original Message-----
From: internet-drafts@ietf.org<= /a> <internet-drafts@ietf.or= g>
Sent: jeudi 12 mars 2020 15:04
To: Michael Richardson <mcr= +ietf@sandelman.ca>; Michael C. Richardson <mcr+ietf@sandelman.ca>; Pascal Thube= rt (pthubert) <pthubert@cisco.com<= /a>>
Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt=


A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt
has been successfully submitted by Pascal Thubert and posted to the IETF re= pository.

Name:           draft-iet= f-roll-unaware-leaves
Revision:       10
Title:          Routing for RP= L Leaves
Document date:  2020-03-12
Group:          roll
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-unaware-leaves-10.txt<= /a>
Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-10
Abstract:
   This specification extends RFC6550 and RFC8505 to provide unic= ast and
   multicast routing services in a RPL domain to 6LNs that are pl= ain
   Hosts and do not participate to RPL, and enables the RPL Root = to
   proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its= DODAG.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--_000_BM1PR01MB40202FD18C6153E47790C446A9B80BM1PR01MB4020INDP_-- From nobody Wed May 20 02:00:53 2020 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 E19B23A3B88 for ; Wed, 20 May 2020 02:00:51 -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, 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 09ylhBuJNUdB for ; Wed, 20 May 2020 02:00:49 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 4D42C3A3B80 for ; Wed, 20 May 2020 02:00:49 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id 134so587503vky.2 for ; Wed, 20 May 2020 02:00:49 -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=VWGgRKnwiVx58gCBau6SVoNPxtLswb+E3sifuXZTDrs=; b=Kqy7RGuRYe1ka/MkYZqASCAuG64E/JKwxMdnEB1Ygq6Fe61sOXlDA9oMIaX0khwUv0 jXNOCrGMXTEXjV8ZD05A8qcTbiS4cfX6VLJMCbzCmoiFVYB0JVdF4uqS4RkDrspZSDIR Tp/2HsEbW/srptwLf+iEVkJ9ehQhFZVcQk1WmmDC+9EWIpC4QSy8+ElYkA51OzskRpZZ v/lXqkGA1TBnKoaG8tnYPj3OH/AAgG9Xym0JilMfEIo30epWfqDl+KcGqSM4/LX2xKLa 6Cj5jaG475wI3Gdxn8sJn3I8uKaaGtp762/rII5tx7OsJj4g5FajDCMF0LXD6Lovg0iT es1w== 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=VWGgRKnwiVx58gCBau6SVoNPxtLswb+E3sifuXZTDrs=; b=jHUp7SVgBV0JEvZzs4cqNNJ7KvnzvK2F4cYImMF726AHzD0n5L2z1OmpWOB5uoNC+8 lvR0WGtltRfRWis2SH45/KFuhetv0uFZcPIastmp81cX4Y7Mj8Zdfn5YNJ4cyM0tpWrt jgsaohVkzkoSbtWH1O7TG0l1YbEQ1dTEJkIvCXv/MIRxGSiT2V4RgckTPx+YBfOgPmNE PcD7JrtK1LtBaf6TVJvzt3mDuLeAvXbuE4oQ1qJ7ngJJmAAzdDICTYgE10f5Y85GcJ3G ZBSLk3qyIyB1USOD0+3znyEdXlYgzPSoMZojmv3QyZz+dWGbaAllq+ncHRlWqbZwnE3R RXJQ== X-Gm-Message-State: AOAM533hqZxjuG1bsCA8DVw1BPPiMT+FdorYc6JEqmZYk5ssdf/G7c/Q 8YDYuJ+7/u4Zldoy+Fl8+JV2QqIVkKw1Wls7JQDDTj02bss= X-Google-Smtp-Source: ABdhPJz4IPPnovUjJ8mrTQoohmNbU1aJmnV+8Qz7FTbJVwnVc4LKgiSGY4XuLA7j/DEpqfe/lKy0+5hE1Ey01t33/yA= X-Received: by 2002:a1f:1bc3:: with SMTP id b186mr2926415vkb.95.1589965247967; Wed, 20 May 2020 02:00:47 -0700 (PDT) MIME-Version: 1.0 References: <158886943764.3475.6047615644810853641@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Wed, 20 May 2020 12:00:11 +0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000cf776505a610a1bb" Archived-At: Subject: Re: [Roll] WG Virtual Meeting: 2020-05-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: Wed, 20 May 2020 09:00:52 -0000 --000000000000cf776505a610a1bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find below the agenda to the Monday 25th Interim meeting. https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agenda-= interim-2020-roll-02-roll-01.txt 11:00 - 11:10 [10 min] WG Status --IETF 108: Meeting Format (when we meet? how much time, slots?) -- Ines/Dominique 11:10 - 11:30 [20 min] draft-thubert-roll-eliding-dio-information -- Pascal 11:30 - 11:50 [20 min] New Option and Backward compatibility -- Everyone 11:50 - 12:10 [20 min] Compression for control messages? Applicable for nsa-extension --- Everyone 12:10 - 12:30 [20 min] RPL Observation topics -- Everyone 12:30 - 12:50 [20 min] RPL Ping -- Everyone 12:50 -13:00 [10 min] Open Floor -- Everyone Please use https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll if you want to upload some slides for topic presentation Comments welcome, Thank you and best regards, Ines and Dominique On Thu, May 14, 2020 at 10:52 AM Pascal Thubert (pthubert) wrote: > Hello Ines > > > > If time permits, I=E2=80=99d like to present the proposed operation of > https://datatracker.ietf.org/doc/draft-thubert-roll-eliding-dio-informati= on/ > and get confirmation of the interest on the work by the WG. To go deeply = in > the proposed operation we probably need at least 20 minutes. Then we need > to challenge it and improve the design, this could be started here and > continued on the ML. > > > > For memory, this draft is the result of a past discussion at a ROLL > interim. We found that the DIO could not be made larger and larger foreve= r, > and that eliding options would cause nodes to miss critical changes, whic= h > could have operational consequences. So we decided that RPLv2 must ensure > that all nodes are synchronized on configuration changes and capability > exchanges. > > > > As for other drafts, this is infrastructure work that we need before the > new features come in. If we reach an agreement to continue with the work > I=E2=80=99ll be happy to progress the draft and make the changes we decid= e in the > personal submission. > > > > Take care, > > > > Pascal > > > > > > *From:* Roll *On Behalf Of *Ines Robles > *Sent:* jeudi 14 mai 2020 09:20 > *To:* roll > *Subject:* [Roll] WG Virtual Meeting: 2020-05-25 > > > > Dear all, > > > > Please let us know the topics that you would like to discuss during the > meeting by 19th May. > > > > So far we have a draft Agenda (topics resulting from the previous (04-29) > interim meeting): > > - New Option and Backward compatibility > - Compression for control messages? Applicable for nsa-extension > - RPL Observation topics > - RPL Ping > > > > You can upload the slides here: > https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll > > The link to the video recording will be available here: > https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200525 > > Webex details can be found below. > > > > Thank you and have a nice day, > > > > Ines and Dominique > > > > ---------- Forwarded message --------- > From: *IESG Secretary* > Date: Thu, May 7, 2020 at 7:39 PM > Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG > Virtual Meeting: 2020-05-25 > To: IETF-Announce > Cc: > > > > The Routing Over Low power and Lossy networks (roll) Working Group will > hold > a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC. > > Agenda: > Draft Agenda: > > New Option and Backward compatibility > Compression for control messages? Applicable for nsa-extension > RPL Observation topics > RPL Ping > Additional Items to be determined > > > Information about remote participation: > Roll interim May meeting Hosted by ROLL WG Monday, May 25, 2020 6:45 am = | > 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada) > Meeting number: 611 684 862 > Password: vbR9EnBMs98 > > https://ietf.webex.com/ietf/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f942a= c > > Join by video system > Dial 611684862@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > Join by phone 1-650-479-3208 > Call-in toll number (US/Canada) > Access code: 611 684 862 > > Meeting Information like link to video recording , etc would be located i= n > https://github.com/roll-wg/ROLL-Interim-Meeting > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000cf776505a610a1bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find = below the agenda to the Monday 25th Interim meeting.

https://datatracker.ietf.or= g/meeting/interim-2020-roll-02/materials/agenda-interim-2020-roll-02-roll-0= 1.txt

11:00 - 11:10=C2=A0[10 min] WG Statu= s --IETF 108: Meeting Format (when we meet? how much time, slots?) --=C2=A0= Ines/Dominique
11:10 - 11:30 [20 min] draft-thubert-roll-eliding-dio-inf= ormation -- Pascal
11:30 - 11:50=C2=A0=C2=A0[20 min] New Option a= nd Backward compatibility=C2=A0 -- Everyone
11:50 - 12:10=C2=A0=C2=A0[20= min] Compression for control messages? Applicable for nsa-extension --- Ev= eryone
12:10 - 12:30=C2=A0=C2=A0[20 min] RPL Observation topics -- Every= one
12:30 - 12:50=C2=A0=C2=A0[20 min] RPL Ping -- Everyone
12:50 -13:= 00=C2=A0=C2=A0[10 min] Open Floor=C2=A0 --=C2=A0Everyone

=
Please use=C2=A0https://datatracker.ietf.org/meeting/int= erim-2020-roll-02/session/roll if you want to upload some slides for to= pic presentation

Comments welcome,

<= /div>
Thank you and best regards,

Ines and Dom= inique



On Thu, May 14, 2020 at 10:52 AM = Pascal Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org> wrote:

Hello Ines

=C2=A0

If time permits, I=E2=80=99d like to present the proposed oper= ation of https://datatracker.ietf.org/doc/d= raft-thubert-roll-eliding-dio-information/ and get confirmation of the = interest on the work by the WG. To go deeply in the proposed operation we probably = need at least 20 minutes. Then we need to challenge it and improve the desi= gn, this could be started here and continued on the ML.

=C2=A0

For memory, this draft is the result of a past discussion at a= ROLL interim. We found that the DIO could not be made larger and larger fo= rever, and that eliding options would cause nodes to miss critical changes, which could have operational consequ= ences. So we decided that RPLv2 must ensure that all nodes are synchronized= on configuration changes and capability exchanges.

=C2=A0

As for other drafts, this is infrastructure work that we need = before the new features come in. If we reach an agreement to continue with = the work I=E2=80=99ll be happy to progress the draft and make the changes we decide in the personal submission.

=C2=A0

Take care,

=C2=A0

Pascal

=C2=A0

=C2=A0

=C2=A0

Dear all,

=C2=A0

Please let us know the topics that you would like to discuss d= uring the meeting by 19th May.

=C2=A0

So far we have a draft Agenda (topics resulting from the previ= ous (04-29) interim meeting):

  • New Option= and Backward compatibility
  • Compressio= n for control messages? Applicable for nsa-extension
  • RPL Observ= ation topics
  • RPL Ping

=C2=A0

The link to the video recording will be available here:=C2=A0<= a href=3D"https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200= 525" target=3D"_blank">https://github.com/roll-wg/ROLL-Interim-Meeting/tree= /master/20200525

Webex details can be found below.<= /p>

=C2=A0

Thank you and have a nice day,

=C2=A0

Ines and Dominique

=C2=A0

---------- Forwarded message ---------
From: IESG Secretary <iesg-secretary@ietf.org>=
Date: Thu, May 7, 2020 at 7:39 PM
Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG Virtual= Meeting: 2020-05-25
To: IETF-Announce <ietf-announce@ietf.org>
Cc: <roll@ietf.org>



The Routing Over Low power and Lossy networks (roll) Working Group will hol= d
a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC.

Agenda:
Draft Agenda:

New Option and Backward compatibility
Compression for control messages? Applicable for nsa-extension
RPL Observation topics
RPL Ping
Additional Items to be determined


Information about remote participation:
Roll interim May meeting Hosted by ROLL WG=C2=A0 Monday, May 25, 2020 6:45 = am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada)
Meeting number: 611 684 862
Password: vbR9EnBMs98

https://ietf.webex.com/ietf/j.php?MTID=3Dm59f= ad4e3500688e160f0d772b9f942ac=C2=A0

Join by video system
Dial 61168486= 2@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.=C2=A0
Join by phone 1-650-479-3208
Call-in toll number (US/Canada)
Access code: 611 684 862

Meeting Information like link to video recording , etc would be located in = https://github.com/roll-wg/ROLL-Interim-Meeting

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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000cf776505a610a1bb-- From nobody Wed May 20 04:45:46 2020 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 9D75A3A08EA for ; Wed, 20 May 2020 04:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=imt-atlantique.fr 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 X1zzjAH8FP2C for ; Wed, 20 May 2020 04:45:41 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF893A08CC for ; Wed, 20 May 2020 04:45:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 5FECF80CB4; Wed, 20 May 2020 13:45:38 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id b4YkD7LWpG3k; Wed, 20 May 2020 13:45:33 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id CBABE819C2; Wed, 20 May 2020 13:45:33 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr CBABE819C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1589975133; bh=ihI+ptTI+Ge6FhA/yP9lKQbtr0DuWZNpDLqpoTNuWz8=; h=Mime-Version:From:Date:Message-Id:To; b=DwGT97sDL8Ge+st9a0nEoYSziuvsVmPlJ8VEzGlOdIpoxxpMyCztlW9ytC/cxdhzH azOFWurOGzxDtDLuLQYgR4JDsY3bWMp80vue8YbbIHDWG3BKJnkqGiKBVoGrAqPIwx jLDKG7FpkqEXGn9L5AfHsg35YXlPkXzei+YJ1bVo= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id La__pQgmA4pn; Wed, 20 May 2020 13:45:33 +0200 (CEST) Received: from [IPv6:2a01:e0a:170:d730:9fe:1c09:70d1:d436] (unknown [IPv6:2a01:e0a:170:d730:9fe:1c09:70d1:d436]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 9BEB980CB4; Wed, 20 May 2020 13:45:33 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B1B5841C-A537-46D2-A8F3-A5D999D01FAE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Georgios Z. Papadopoulos" In-Reply-To: Date: Wed, 20 May 2020 13:45:33 +0200 Cc: Routing Over Low power and Lossy networks Message-Id: <1363BF1C-EC0B-46A3-93D9-5FEA24609D0B@imt-atlantique.fr> References: <158961849800.18021.5069151377902832891@ietfa.amsl.com> To: nyrahul@outlook.com, Rahul Jadhav X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.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: Wed, 20 May 2020 11:45:45 -0000 --Apple-Mail=_B1B5841C-A537-46D2-A8F3-A5D999D01FAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Rahul, Many thanks for the updated version. I went through it today, and yes, it is in much more better shape now. Below you will find my comments on this version :=20 High level comments :=20 - Section 2.1, second paragraph : =E2=80=9CA router may use capabilities = carried in DIO message as additional metrics/constraints.=E2=80=9D.=20 [GP]: One may ask : what prevents to have multiple metrics in DIO = messages, without using the capabilities? - Section 4.1, first sentence : =E2=80=9CA node MUST drop or discard the = message silently having an unknown capability with =E2=80=99D=E2=80=99 = (discard) flag set.=E2=80=9D [GP]: This sentence is not clear to me. Why a node would send an unknown = to itself D flag to its neighbors. Could you please rephrase it? - Section 4.1.1, second paragraph : =E2=80=9CIf the node is operating as = 6LR and subsequently it receives a capability which it doesn=E2=80=99t = understand with =E2=80=99J=E2=80=99 flag set, then the node has to = switch itself to 6LN mode.=E2=80=9D [GP]: This part is not clear to me. Why a 6LR should switch? I mean, = simply because a neighbor node sends a DIO control packet with J that it = does not understand? What is the ultimate objective by doing so? - Setion 5.2 : I liked very much your description and justifications = here.=20 [GP]: Do you think would be possible to add here an example/figure with = a simple topology to visualise the procedure. Minor comments/typos/rephrasing :=20 - [GP]: 1. Introduction, page 2, second paragraph, first sentence : = =E2=80=9CThis document adds a notion of capabilities using which the = nodes in the network=E2=80=9D =E2=80=94> "This document adds a notion of = capabilities using which nodes in the network=E2=80=9D? (without THE = nodes?) - [GP]: 1. Introduction, page 2, second paragraph : =E2=80=9CMode of = operation=E2=80=9D, you already defined it earlier in the previous = paragraph, you may write directly MOP, or keep o from operation in = capital. - [GP]: Section 2.1, 1st paragraph : Mode of Operation (MOP), you define = it for the second time in the document. - Section 4.1.1, 1st sentence : =E2=80=9COn receiving a capability it = does not support=E2=80=9D [GP]: You mean the following : A non-RPL node on receiving a capability = that it does not support - [GP]: Next paragraph : doesn=E2=80=99t understand with =E2=80=98J=E2=80=99= =E2=80=94> does not - In the same Section, last paragraph : =E2=80=9CCapabilities are used = to indicate a feature that is supported by the node. Capabilities are = not meant for configuration management for=E2=80=9D [GP]: Maybe these sentences you should put move on section what is = capabilities? - [GP]: At the end of this paragraph : ./>, you might need to recompile = it :-) =E2=80=94 =E2=80=94=20 Best, and stay safe, Georgios > On May 16, 2020, at 10:51, Rahul Jadhav wrote: >=20 > Dear all, >=20 > The update fixes all the points discussed during interim and = subsequent ML discussions, namely: >=20 > Flag for ignoring (silently discarding) the message if cap not = understood. > removal of global flag > removal of info present flag. Earlier we had optional length for = capabilities who do not have any information. Such capabilities are now = aggregated as part of 'Capability Indicators'.. Thus this bit is no = longer required. > The indicator bits are ordered from left to right. > Feedback/reviews are appreciated. Thanks. >=20 > Best, > Rahul >=20 >=20 > ________________________________________ > From: Roll on behalf of = internet-drafts@ietf.org > Sent: 16 May 2020 04:41 PM > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt >=20 > 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. >=20 > Title : RPL Capabilities > Authors : Rahul Arvind Jadhav > Pascal Thubert > Michael Richardson > Rabi Narayan Sahoo > Filename : draft-ietf-roll-capabilities-04.txt > Pages : 12 > Date : 2020-05-16 >=20 > Abstract: > This draft enables the discovery, advertisement and query of > capabilities for RPL nodes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-roll-capabilities-04 = > https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-04 = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-capabilities-04 = >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll = --Apple-Mail=_B1B5841C-A537-46D2-A8F3-A5D999D01FAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Rahul,

Many thanks for the updated = version.
I went through it today, and yes, it is in = much more better shape now.

Below you will find my comments on this version = : 

High level comments : 
- = Section 2.1, second paragraph : =E2=80=9CA router may use capabilities = carried in DIO message as additional = metrics/constraints.=E2=80=9D. 
[GP]: One may = ask : what prevents to have multiple metrics in DIO messages, = without using the capabilities?

- Section 4.1, first sentence : =E2=80=9C= A node MUST drop or discard the message silently having an unknown = capability with =E2=80=99D=E2=80=99 (discard) flag set.=E2=80=9D
[GP]: This sentence is not clear to me. Why a node = would send an unknown to itself D flag to its neighbors. Could you = please rephrase it?

- Section 4.1.1, second paragraph : =E2=80=9CIf the node is = operating as 6LR and subsequently it receives a capability which it = doesn=E2=80=99t understand with =E2=80=99J=E2=80=99 flag set, then the = node has to switch itself to 6LN mode.=E2=80=9D
[GP]: This part is not clear to me. Why a 6LR should = switch? I mean, simply because a neighbor node sends a DIO control = packet with J that it does not understand? What is the ultimate = objective by doing so?

- Setion 5.2 : I liked very much your description and = justifications here. 
[GP]: Do you = think would be possible to add here an example/figure with a simple = topology to visualise the procedure.

Minor = comments/typos/rephrasing : 
- [GP]: 1. = Introduction, page 2, second paragraph, first sentence : =E2=80=9CThis = document adds a notion of capabilities using which the nodes in the = network=E2=80=9D =E2=80=94> "This document adds a notion of = capabilities using which nodes in the network=E2=80=9D? (without THE = nodes?)

- = [GP]: 1. Introduction, page 2, second paragraph : =E2=80=9CMode of = operation=E2=80=9D, you already defined it earlier in the previous = paragraph, you may write directly MOP, or keep o from operation in = capital.

- = [GP]: Section 2.1, 1st paragraph : Mode of Operation (MOP), you define = it for the second time in the document.

- Section 4.1.1, 1st sentence : =E2=80=9C= On receiving a capability it does not support=E2=80=9D
[GP]: You mean the following : A non-RPL node on = receiving a capability that it does not support

- [GP]: Next paragraph : doesn=E2=80=99t = understand with =E2=80=98J=E2=80=99 =E2=80=94> does not

- In the same Section, = last paragraph : =E2=80=9CCapabilities are used to indicate a feature = that is supported by the node.  Capabilities are not meant for = configuration management for=E2=80=9D
[GP]: Maybe these sentences you should put move on = section what is capabilities?

- [GP]: At the end of this paragraph : = ./>, you might need to recompile it :-)


=E2=80= =94 =E2=80=94 
Best, and stay safe,
Georgios


On May 16, 2020, at 10:51, Rahul Jadhav <nyrahul@outlook.com>= wrote:

Dear = all,

The update fixes all the points = discussed during interim and subsequent ML discussions, = namely:

  1. Flag for ignoring (silently discarding) the message if cap = not understood.
  2. removal of global flag
  3. removal of info present flag. Earlier we had optional length = for capabilities who do not have any information. Such capabilities are = now aggregated as part of 'Capability Indicators'.. Thus this bit is no = longer required.
  4. The indicator bits are ordered from = left to right.
Feedback/reviews are = appreciated. Thanks.

Best,
Rahul


________________________________________
From: = Roll <roll-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
Sent: 16 May = 2020 04:41 PM
To: i-d-announce@ietf.org
Cc: roll@ietf.org
Subject: [Roll] I-D Action: = draft-ietf-roll-capabilities-04.txt

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           : RPL = Capabilities
        = Authors         : Rahul Arvind = Jadhav
          &nb= sp;            = ;   Pascal Thubert
          &nb= sp;            = ;   Michael Richardson
          &nb= sp;            = ;   Rabi Narayan Sahoo
        = Filename        : = draft-ietf-roll-capabilities-04.txt
        = Pages           : = 12
        = Date            : = 2020-05-16

Abstract:
   This draft enables the discovery, advertisement = and query of
   capabilities for RPL nodes.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/<= /a>

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-roll-capabilities-04=
https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilit= ies-04

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-capabilitie= s-04


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/


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

= --Apple-Mail=_B1B5841C-A537-46D2-A8F3-A5D999D01FAE-- From nobody Wed May 20 05:23:29 2020 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 9B3133A0923 for ; Wed, 20 May 2020 05:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 mB8tnqon2O7j for ; Wed, 20 May 2020 05:23:24 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254022.outbound.protection.outlook.com [40.92.254.22]) (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 A047C3A0924 for ; Wed, 20 May 2020 05:23:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4b3/uZ5tKVrqW9CYYpsO3M18eJHfzIs3idLZ88i9plmAbimr6/4dtcKKXifYpkl7mxThTBH97otDuSGqhrKDp3X3SS3Wpp0c/duNHcLu66MbjaG3PMEeMWV7xcn8MjTwSYCeQDFiGeCWkwjMW/ofiVMzxID0W9zdgTLkNi4xq0QO+vWxl3wt4XV5m6NJD5y0SJp3/C9OtZBf0wC3J5pZ2FF14GNj1gm8fYCrykMlXlGpifBSh3JRWcguV2uPQ1ABdqsDBqfO9qW1Z6WI0bwgTfSCvGyVHsfevXF5iPcsYGEqHb17yGCa/9USuFOyniCL/mvVRxi4/io2s4y1UNoZA== 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=AaHJbLoFctsclFB2b1zOrTpvHYoQPgHhx2E/lMu6CJI=; b=CsVnIWVfYVNEJiM/wA5Z0xGNfChJaP3ZBtWJkiA7WdAEeXVwfxtupLBaKZPVE2mi97YxyiddoUKLUpwyvO7kwFHRIz72K5THxUTA9GuriIPjv1UNp/8LKQ1IbgctY0aCg1imSS20NWnwvGq0oWRVsQmrMyg3GPPGhEzEf695yzPFny80FBFkKe8Lp46LKvfHO/2otJqm9QSdLeu5kiDutqAjbDg4EDSOr5xFWa/DzdQjRs4R6KBpWqaEMFa9in7I9sNil5Edzk9YQj9AuZyhAyeA30leHvghNrszX8tc+UOw2nUu04VZGSQYjq6Juv+ZKpRhjd53bwUf5Yt1g3xVYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AaHJbLoFctsclFB2b1zOrTpvHYoQPgHhx2E/lMu6CJI=; b=O6xsF1ZGZIbTjnoeRH7DIFRJO1JJ6ucZ7FjqNnPk30XFpShzeOXw13kytS4FqXatZ4pKR3ev6xH6VN+W/PovSXI8wrkhGeLuw1hMN5w8vnkQqdrNEUqX64Rw4pcRFCc8gNvr1IfToDimOhvLNjI9c2siMyT+TKImuhyoho4iXN6rnkVapkEDtHCxQhytfxaT8yguV0Zq46qx0FaSQ3rLpU4DVK0/sVyDhQ0tf+diELRy0T46Caguh0yU/4IJHhOpxB922uZeTR6cUqRUBKDxc7R8tViXoXE47hwTDXvfjr4VQXA9Arv6scuhWOl9CVz6IoG9KA2H6059pSxF7n/Uwg== Received: from SG2APC01FT044.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::46) by SG2APC01HT155.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::483) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19; Wed, 20 May 2020 12:23:20 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebd::51) by SG2APC01FT044.mail.protection.outlook.com (2a01:111:e400:7ebd::239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Wed, 20 May 2020 12:23:19 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3000.034; Wed, 20 May 2020 12:23:19 +0000 From: Rahul Jadhav To: "Georgios Z. Papadopoulos" , Rahul Jadhav CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt Thread-Index: AQHWLpw9diGZYLfMm0qdFPHkjICT4aiw36iy Date: Wed, 20 May 2020 12:23:19 +0000 Message-ID: References: <158961849800.18021.5069151377902832891@ietfa.amsl.com> , <1363BF1C-EC0B-46A3-93D9-5FEA24609D0B@imt-atlantique.fr> In-Reply-To: <1363BF1C-EC0B-46A3-93D9-5FEA24609D0B@imt-atlantique.fr> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:73FBAAD6962E718155BA540BFD0A70B4B31D57B9718E10636F4946F58A3C97FB; UpperCasedChecksum:EF0DBBFF1E308A2FE4423B3BF03BA6D1FC19771EFBC32DF13121601713C58456; SizeAsReceived:7115; Count:45 x-tmn: [TdDYXhcAdxl15FBhPQn+AXFPxB6cK6VC] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 99043e83-f2de-4bb0-4e48-08d7fcb894ef x-ms-traffictypediagnostic: SG2APC01HT155: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G4aRN30NlI20qjh/vhTjWKFqljOW0wKhakIV/yLnm5ZNpAqAU+TgkffKKjd/ZS1EGTgsTlbUUmg4BosLrRUpPyo8UHKpkplAphECsMaOROSoGYC2XaCnpaPgBPcKkG3wlRQWG58QlHEqEBcTB8WW+bUhquMALeHGK+TwsmbEecbIfANqvjunR029cWqa2+DcC+kMBrUJ0c4nOD/Ft2SU+9aTOEltdNKfYLtmcowrQ0zLWg8Otm6U51p1Y441hdSL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: ZVd/fK15YFuV5Q/c7MYQIeLL42dhmtB4S5TeYV4kbyzhiRi/3Mi3UxwNAqoL77U4cYYsEg/B3SmiCuhoa6aKhzEqDs9dS21YOZ3nWYGE03QeTkZ+E285N5F7dfyfCuDycf8uhyNy0rJtWxJYP5/4Hw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402038551375947D3DD87872A9B60BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 99043e83-f2de-4bb0-4e48-08d7fcb894ef X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 12:23:19.7828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT155 Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.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: Wed, 20 May 2020 12:23:27 -0000 --_000_BM1PR01MB402038551375947D3DD87872A9B60BM1PR01MB4020INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you very much Georgios for the review. Greatly helps. Please find my responses inline. Best, Rahul ________________________________ From: Georgios Z. Papadopoulos Sent: 20 May 2020 07:45 PM To: nyrahul@outlook.com ; Rahul Jadhav Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt Hello Rahul, Many thanks for the updated version. I went through it today, and yes, it is in much more better shape now. Below you will find my comments on this version : High level comments : - Section 2.1, second paragraph : =93A router may use capabilities carried = in DIO message as additional metrics/constraints.=94. [GP]: One may ask : what prevents to have multiple metrics in DIO messages,= without using the capabilities? [RJ] Metrics/Constraints particularly aid the nodes to make a decision on t= he preferred parent selection. While capabilities are (possibly optional) f= eatures supported by the nodes. A 6LN/6LR may decide to use the parent node= supporting a specific capability as compared to other upstream 6LRs. But t= he ultimate aim of capabilities may not necessarily be to make routing deci= sions. Take the case of 6LoRH. This cannot be signaled as a metric/constrai= nt. Another important difference is that routing metrics/constraints only flow = downstream in DIO messages. Capabilities may go in either direction and can= be queried. - Section 4.1, first sentence : =93A node MUST drop or discard the message = silently having an unknown capability with =92D=92 (discard) flag set.=94 [GP]: This sentence is not clear to me. Why a node would send an unknown to= itself D flag to its neighbors. Could you please rephrase it? [RJ] The case is that a node receives a capability from other node for e.g= ., in a DIO message with D flag set. If the node does not understand this c= ap then it should discard the DIO. As an example, a node may decide to send= a cap with D flag set because it wants only the nodes who understand this = cap to be in its sub-dodag. - Section 4.1.1, second paragraph : =93If the node is operating as 6LR and = subsequently it receives a capability which it doesn=92t understand with = =92J=92 flag set, then the node has to switch itself to 6LN mode.=94 [GP]: This part is not clear to me. Why a 6LR should switch? I mean, simply= because a neighbor node sends a DIO control packet with J that it does not= understand? What is the ultimate objective by doing so? [RJ] If a node receives a DIO with cap which it does not understand and has= J flag set then it can join only as 6LN to this parent. As an example, con= sider 6LORH again. It may be possible to support 6LoRH in a network in whic= h only the leaves don't understand 6LoRH. In this case, a root may send a c= ap with 6LoRH enabled with J flag set such that any node which doesn't unde= rstand this cap joins only as a leaf. - Setion 5.2 : I liked very much your description and justifications here. [GP]: Do you think would be possible to add here an example/figure with a s= imple topology to visualise the procedure. [RJ]: I think It is possible to explain this in detail, especially consider= ing PDAO as an example. Btw, most of this description comes from Rabi (than= ks to him). Minor comments/typos/rephrasing : - [GP]: 1. Introduction, page 2, second paragraph, first sentence : =93This= document adds a notion of capabilities using which the nodes in the networ= k=94 =97> "This document adds a notion of capabilities using which nodes in= the network=94? (without THE nodes?) - [GP]: 1. Introduction, page 2, second paragraph : =93Mode of operation=94= , you already defined it earlier in the previous paragraph, you may write d= irectly MOP, or keep o from operation in capital. - [GP]: Section 2.1, 1st paragraph : Mode of Operation (MOP), you define it= for the second time in the document. - Section 4.1.1, 1st sentence : =93On receiving a capability it does not su= pport=94 [GP]: You mean the following : A non-RPL node on receiving a capability tha= t it does not support - [GP]: Next paragraph : doesn=92t understand with =91J=92 =97> does not - In the same Section, last paragraph : =93Capabilities are used to indicat= e a feature that is supported by the node. Capabilities are not meant for = configuration management for=94 [GP]: Maybe these sentences you should put move on section what is capabili= ties? - [GP]: At the end of this paragraph : ./>, you might need to recompile it = :-) [RJ] Many thanks for the detailed read/review. Will incorporate all these f= ixes in next rev. =97 =97 Best, and stay safe, Georgios On May 16, 2020, at 10:51, Rahul Jadhav > wrote: Dear all, The update fixes all the points discussed during interim and subsequent ML = discussions, namely: 1. Flag for ignoring (silently discarding) the message if cap not unders= tood. 2. removal of global flag 3. removal of info present flag. Earlier we had optional length for capa= bilities who do not have any information. Such capabilities are now aggrega= ted as part of 'Capability Indicators'.. Thus this bit is no longer require= d. 4. The indicator bits are ordered from left to right. Feedback/reviews are appreciated. Thanks. Best, Rahul ________________________________________ From: Roll > on behalf = of internet-drafts@ietf.org > Sent: 16 May 2020 04:41 PM To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : RPL Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Rabi Narayan Sahoo Filename : draft-ietf-roll-capabilities-04.txt Pages : 12 Date : 2020-05-16 Abstract: This draft enables the discovery, advertisement and query of capabilities for RPL nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-capabilities-04 https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-capabilities-04 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_BM1PR01MB402038551375947D3DD87872A9B60BM1PR01MB4020INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thank you very much Georgios for the review. Greatly helps.

Please find my responses inline.

Best,
Rahul


From: Georgios Z. Papadopou= los <georgios.papadopoulos@imt-atlantique.fr>
Sent: 20 May 2020 07:45 PM
To: nyrahul@outlook.com <nyrahul@outlook.com>; Rahul Jadhav &l= t;rahul.ietf@gmail.com>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt<= /font>
 
Hello Rahul,

Many thanks for the updated version.
I went through it today, and yes, it is in much more better= shape now.

Below you will find my comments on this version : 

High level comments : 
- Section 2.1, second paragraph : =93A router may use capab= ilities carried in DIO message as additional metrics/constraints.=94. =
[GP]: One may ask : what prevents to have multiple met= rics in DIO messages, without using the capabilities?

[RJ] Metrics/Constraints particularly aid the nodes to make= a decision on the preferred parent selection. While capabilities are (poss= ibly optional) features supported by the nodes. A 6LN/6LR may decide to use= the parent node supporting a specific capability as compared to other upstream 6LRs. But the ultimate aim of cap= abilities may not necessarily be to make routing decisions. Take the case o= f 6LoRH. This cannot be signaled as a metric/constraint.
Another important difference is that routing metrics/constr= aints only flow downstream in DIO messages. Capabilities may go in either d= irection and can be queried.

- Section 4.1, first sentence : =93A node MUST drop or disc= ard the message silently having an unknown capability with =92D=92 (discard= ) flag set.=94
[GP]: This sentence is not clear to me. Why a node wou= ld send an unknown to itself D flag to its neighbors. Could you please reph= rase it?
[RJ] The case is that a node receives a capability from oth= er node  for e.g., in a DIO message with D flag set. If the node does = not understand this cap then it should discard the DIO. As an example, a no= de may decide to send a cap with D flag set because it wants only the nodes who understand this cap to be in its s= ub-dodag.

- Section 4.1.1, second paragraph : =93If the node is opera= ting as 6LR and subsequently it receives a capability which it doesn=92t un= derstand with =92J=92 flag set, then the node has to switch itself to 6LN m= ode.=94
[GP]: This part is not clear to me. Why a 6LR should s= witch? I mean, simply because a neighbor node sends a DIO control packet wi= th J that it does not understand? What is the ultimate objective by doing s= o?
[RJ] If a node receives a DIO with cap which it does not un= derstand and has J flag set then it can join only as 6LN to this parent. As= an example, consider 6LORH again. It may be possible to support 6LoRH in a= network in which only the leaves don't understand 6LoRH. In this case, a root may send a cap with 6LoRH ena= bled with J flag set such that any node which doesn't understand this cap j= oins only as a leaf.

- Setion 5.2 : I liked very much your description and justi= fications here. 
[GP]: Do you think would be possible to add here an ex= ample/figure with a simple topology to visualise the procedure.
[RJ]: I think It is possible to explain this in detail, esp= ecially considering PDAO as an example. Btw, most of this description comes= from Rabi (thanks to him).

Minor comments/typos/rephrasing : 
- [GP]: 1. Introduction, page 2, second paragraph, first se= ntence : =93This document adds a notion of capabilities using which the nod= es in the network=94 =97> "This document adds a notion of capabilit= ies using which nodes in the network=94? (without THE nodes?)

- [GP]: 1. Introduction, page 2, second paragraph : =93Mode= of operation=94, you already defined it earlier in the previous paragraph,= you may write directly MOP, or keep o from operation in capital.

- [GP]: Section 2.1, 1st paragraph : Mode of Operation (MOP= ), you define it for the second time in the document.

- Section 4.1.1, 1st sentence : =93On receiving a capabilit= y it does not support=94
[GP]: You mean the following : A non-RPL node on recei= ving a capability that it does not support

- [GP]: Next paragraph : doesn=92t understand with =91J=92 = =97> does not

- In the same Section, last paragraph : =93Capabilities are= used to indicate a feature that is supported by the node.  Capabiliti= es are not meant for configuration management for=94
[GP]: Maybe these sentences you should put move on sec= tion what is capabilities?

- [GP]: At the end of this paragraph : ./>, you might ne= ed to recompile it :-)

[RJ] Many thanks for the detailed read/review. Will incorpo= rate all these fixes in next rev.


=97 =97 
Best, and stay safe,
Georgios


On May 16, 2020, at 10:51, Rahul Jadhav <nyrahul@outlook.com> wrote:

Dear all,

The update fixes all the points discussed during interim and subsequent ML = discussions, namely:

  1. Flag for ignoring (silently discarding) the message if cap n= ot understood.
  2. removal of global flag
  3. removal of info present flag. Earlier we had optional length for capabilit= ies who do not have any information. Such capabilities are now aggregated a= s part of 'Capability Indicators'.. Thus this bit is no longer required.
  4. The indicator bits are ordered from left to right.
    5. Feedback/reviews are appreciated. Thanks.

    Best,
    Rahul


________________________________________
From: Roll <roll-bou= nces@ietf.org> on behalf of internet-drafts@ietf= .org <interne= t-drafts@ietf.org>
Sent: 16 May 2020 04:41 PM
To: i-d-announce@ietf.o= rg
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.

        Title    &nb= sp;      : RPL Capabilities
        Authors    &= nbsp;    : Rahul Arvind Jadhav
            &nb= sp;            = Pascal Thubert
            &nb= sp;            = Michael Richardson
            &nb= sp;            = Rabi Narayan Sahoo
        Filename    =     : draft-ietf-roll-capabilities-04.txt
        Pages    &nb= sp;      : 12
        Date    &nbs= p;       : 2020-05-16

Abstract:
   This draft enables the discovery, advertisement and query of    capabilities for RPL nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-capabilities-04
https://datatracker.ietf.org/doc/html/draft-ietf-roll-cap= abilities-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-capabil= ities-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.o= rg/internet-drafts/


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

--_000_BM1PR01MB402038551375947D3DD87872A9B60BM1PR01MB4020INDP_-- From nobody Wed May 20 06:18:09 2020 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 47AA23A0990 for ; Wed, 20 May 2020 06:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=bVwY43UX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OVToCNQg 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 UzCawx4F6Yqx for ; Wed, 20 May 2020 06:18:02 -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 328003A0953 for ; Wed, 20 May 2020 06:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74672; q=dns/txt; s=iport; t=1589980682; x=1591190282; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Wxg5Ee+f0kBvT1htN1i4154usJxWhZXTCd+EdrhdRxU=; b=bVwY43UXCYVA+r1TP/NyUzxEsZPh8oby2MVwhWB5Q+0WUeToSTDdRlWY QfNZ+mP48PwSw5SroZVcgboAOORGzYbeyHs9ojIGewl/hlaU/CuNfzW6U Ah80Lwm1zzfV5Ab58f9ic03UthCohabXradmEpMT2SbB+XZ1EXyQRWAoe Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AQ4lKuhMgfsiJklU4G5El6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw93ljUQYHc7PECgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8Hje1nVpX705jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/DwDILMVe/4wNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCB4ElAS4jLgdvWC8sg2RAgV2BaQOLLoIRgQGIeI5CgUKBEAN?= =?us-ascii?q?QBQMIAQEBDAEBGAEMCAIEAQGDDoE2AheBeCQ4EwIDAQELAQEFAQEBAgEFBG2?= =?us-ascii?q?FVgyFcQEBAQEDAQEKBggJChMBASwJAwsEAgEGAg4DBAEBIQEGAwICAh8GCxQ?= =?us-ascii?q?JCAIEARIIGoJ/BAKBfk0DLgEOl2uQZwKBOYhhdoEygwEBAQWBNgIOQYMnDQu?= =?us-ascii?q?CDgmBOIJjgkiHFxqBQT+BEUOCGDU+gh5JAQECAQEYgQsEHAQcJQYJgl4zgi2?= =?us-ascii?q?PcYFzhiQliliPVkoKglOIJ4YLgkqBEIFshHWCYoESh2mSF456gU6JbYJLjRC?= =?us-ascii?q?EEgIEAgQFAg4BAQWBaSIMgUpwFRohgmkJRxgNkEAMF4NPhRSFQnQCNQIDAwE?= =?us-ascii?q?HAQEDCXyMPwEB?= X-IronPort-AV: E=Sophos;i="5.73,414,1583193600"; d="scan'208,217";a="481985716" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 May 2020 13:18:00 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 04KDI0UF007168 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2020 13:18:00 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 May 2020 08:18:00 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 May 2020 08:17:59 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 20 May 2020 09:17:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YejQc+IqT3J3IrdEMOuHFYTjZcpVCAm5T2hLg8J2uGBvgjsqPhc1MJPFXXSdGY9nyUlrzUkmxtIuNxpp402Zc/HVs0ng8f4UNNBOvcUefykt/3FFFOwUYaucqjp+7TrzqCg3NI1xCnXzQBg4sCY6dAiGjscH8KLTZjbGYE/BG0iDz8SfK566b3cecwSqGLCQG0AsLj4y8lTQiCtBNHFZpiKQcv+pF1jZq6nm8zbf5h1xrliOONQqx5FJpRhZbBtGZeI10vly6Nu64G8gW5+hkTpLr//Hp89SerTHPUp9IPRYiNiQaMPeIsgvLQ5hCZg3JSdjLI3moBTbDTDxSD4/Ew== 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=Wxg5Ee+f0kBvT1htN1i4154usJxWhZXTCd+EdrhdRxU=; b=Xey3KL1qcD9WUbgAxC1xIa/QsfwbGYKl6CbjdO6+uXAYipJCfQwSBrQubIKEFeV0UdHKn+UAaDlWWmafh0Cnm8IYpaX8EHa0HLd9hs/6/yueF1mIgKCyudj0B3coWM0jS+LYsl6TQfpMXYPI8ivP9IUpBd6cozfxbKJqOGdfHdPiNPrIRqZKQViFdDxxeGJXxzGX3Lxuks85DPOj9BdCB9nbYzFONV0BCVJMMDMB3WtSTeEx7Coi3cBcb189cw3fy0f+VvG3Aw1BCxhehRwOgmlgjv2wP5kQXqRwSC4wTdMqujAugBx8CKPBtLEDcac06YitMDQZk95ohfG89Jdr7w== 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=Wxg5Ee+f0kBvT1htN1i4154usJxWhZXTCd+EdrhdRxU=; b=OVToCNQgEom/xpYoMlwoh7ynk39gqTr7Yif7dREzwc1/43xO5+G4oVeZAnDqtTumfCqPU76gua8LoaPuPHQXirdmRxBCVk4UthaagTVnD+QBOlATs5TXFLpDUhNlI4fi4V7xDB88B8VC/HLkp7c5zyfD/9cNAJG5kQREyxmVj+k= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3632.namprd11.prod.outlook.com (2603:10b6:208:ec::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.27; Wed, 20 May 2020 13:16:44 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108%6]) with mapi id 15.20.3000.034; Wed, 20 May 2020 13:16:44 +0000 From: "Pascal Thubert (pthubert)" To: Rahul Jadhav , "Routing Over Low power and Lossy networks" , rabi narayan sahoo Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt Thread-Index: AQHV+Hcezq3im2uH30CiF/oY8K2vzahE/ZyggAAFM7yAAAXZkIAABcnzgAAN4ICAZtA3qYACMJ2wgAAIIK6AAzrx8A== Date: Wed, 20 May 2020 13:16:34 +0000 Deferred-Delivery: Wed, 20 May 2020 13:16:32 +0000 Message-ID: References: <158402183564.18056.13091739917212256438@ietfa.amsl.com>, , , , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: outlook.com; dkim=none (message not signed) header.d=none;outlook.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:319f:9119:bb6a:229d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01c6ffbf-f417-433d-d358-08d7fcc00ae9 x-ms-traffictypediagnostic: MN2PR11MB3632: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04097B7F7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T2VPnKb5PkBx0Z4GjmQb7wh3vGT5/WwogjGz6XAqhjd2OPBFJWxVOPwyU7Deri8WBmvBZfoyA3PXYMFyJ0h8td1JY55uzOlD8wQ3uK6OYacVddM8cYlz7na6DNCxEQbPJh2rtHEtEYo1A9XmNKzi9dYQNg0JaGEEj3xAG9EP5XCZwKrDUopqtHJeIDMohNq975476xjLyH/0K7RGQCdYNjGwZS0s1qtwqakxBGx6MtU1+91zHyO5O7Hm5YfUuqRCvMldFE9RVSl7PDpr23Ktpuxm4EJcAZQwIunM8uKPcm3kIfPRS5FHXB65Q2iTpI9Swbc+a0N/ZGihhnZSbEjkxla4hSXVZ1DMJtiO8qwsvp9DjPBdnTTnDNVYM95yCeEPy3aAAJkrXJcQ4lsXKsH9WzBAqCVu/rkC4zBizJwrszw5SIs+g9f8AIzu5cuvPH/MyN5POCZ2aub5kxjVC/mv0eVcUSyY+2fOWN8lWrOHRmSugAtgDN9KgHQRNMh9ElX8vn5ee0FYR7S94NqLkg7Qqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(136003)(366004)(39860400002)(45080400002)(8676002)(8936002)(5660300002)(478600001)(966005)(9686003)(55016002)(2906002)(30864003)(33656002)(186003)(15650500001)(66574014)(166002)(316002)(86362001)(71200400001)(64756008)(7696005)(66556008)(76116006)(53546011)(66476007)(66946007)(6506007)(52536014)(6666004)(110136005)(66446008)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: dRA/Z4p3aoRVet/vKFh/6PG8RO5OgMVhtwTgrODkGuL/4MS3jGDsRDRd9BDnTNq9/KYu8LK3h+29NuhvKRyXyjwhfTDHhxv4ihSbxcuQI6irmIywVL7Q5JN+y2eexPhhVDS3WNe6pNNiUAz75vzL36VLBZtvGE34bXOKwC4DvTMX+IpfBYlv9Quu2NK2cfHAS/Wtfe0ClKlNNGkHVxxNXl5IXYdK8H1wQWisidOmdihhaEIrVCO8ofi89IsTnJP0y72teJND4h1C8hNdb4/JR4FoBFcHPoge2TbRGojlpzgcUxFU2y14RdfhILyoMKepRJHpW1emo86Vb/vJXtiUdUKbSBORXeRu88mVfdltTK3xBsMgYZduq5rcqz8Zw1OkEx71mhug86jMPSSUBXsFLGMTJftRPkodUji7xa7lGCpkHZhR1o7llYhERYVyj9zK/8xabGlu1pZ0vaMwVm5CQsKITfCMF9KGXslTg+1aBFuPwXNiNt+RIs4tIlT7fyL0+wjTphbe1pi6JnPiMD3e4m975mrPYL9+J9VIijq2WvYdiyDg2PyL6zV9t7HJdf8V x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565CC15E506F4692CABC524D8B60MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 01c6ffbf-f417-433d-d358-08d7fcc00ae9 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 13:16:44.2341 (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: 07wuPSaGg+vCbR3fPYVmItNK5oeUCoWbxWuOWk8ZTb2zortBK60SoyiJ4cqrxP4ZwKgyhmHi5hRrnfc3xMKJRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3632 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.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: Wed, 20 May 2020 13:18:07 -0000 --_000_MN2PR11MB3565CC15E506F4692CABC524D8B60MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUmFodWwNCg0KQSB2ZXJ5IGludGVyZXN0aW5nIGNvbW1lbnQuDQoNClllcywgdGhlIDZM UiBpcyBleHBlY3RlZCB0byBkbyB3aGF04oCZcyBuZWNlc3NhcnkgdG8gYmVzdCBzZXJ2ZSB0aGUg UlBMIHVuYXdhcmUgbGVhZi4NCg0KVGhlIFJVTCBpcyBub3QgYXdhcmUgb2YgUlBMIHNvIGl0IGNh bm5vdCBrbm93IHdoZXRoZXIgdGhlIDZMUiBpcyBkb2luZyBzdG9yaW5nLXJvb3QtYWNrIG9yIGV2 ZW4gdGFsa2luZyBSUEwgYXQgYWxsIGZvciB0aGF0IG1hdHRlci4NCg0KV2hhdCBtYWtlcyBzZW5z ZSBpcyB0aGF0IG9uIHRoZSBmaXJzdCByZWdpc3RyYXRpb24sIHRoZSA2TFIgKG9wdGlvbmFsbHkp IHdhaXRzIGZvciB0aGUgc3RvcmluZy1yb290LWFjayBiZWZvcmUgaXQgc2VuZHMgdGhlIE5BKEVB Uk8pIGJhY2suIFRoaXMgY2hhbmdlIG9mIHRoZSBmbG93IHdvdWxkIGJlIGluZGljYXRlZCBpbiB5 b3VyIHN0b3Jpbmctcm9vdC1hY2sgZHJhZnQuDQoNCkRvZXMgdGhhdCB3b3JrPw0KDQpQYXNjYWwN Cg0KDQpGcm9tOiBSYWh1bCBKYWRoYXYgPG55cmFodWxAb3V0bG9vay5jb20+DQpTZW50OiBsdW5k aSAxOCBtYWkgMjAyMCAxNDowMw0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHVi ZXJ0QGNpc2NvLmNvbT47IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtz IDxyb2xsQGlldGYub3JnPjsgcmFiaSBuYXJheWFuIHNhaG9vIDxyYWJpbmFyYXlhbnMwODI4QGdt YWlsLmNvbT4NClN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMC50eHQNCg0KU28gZXZlbiBpbiBzdG9yaW5nIE1P UCBhIDZMTi82TFIgc2hvdWxkIHVzZSBub24tc3RvcmluZyBNT1Agc2lnbmFsaW5nIHRvIHNlbmQg dGhlIGV4dGVybmFsIHJvdXRlcyB0byB0aGUgcm9vdC4gSSBndWVzcyB0aGlzIGlzIHdoYXQgaXMg ZG9uZSBpbiB1bmF3YXJlLWxlYXZlcyBhcyB3ZWxsLg0KDQpUaGlzIGRvZXMgYW5zd2VyIG15IHF1 ZXN0aW9uLiBNYW55IFRoYW5rcy4NCg0KRm9yIHN0b3Jpbmctcm9vdC1hY2ssIFJhYmkgcG9pbnRl ZCBvdXQgYSBjYXNlIHdoZXJlIHRoZSA2TE4vNkxSIHNlbmRzIERBTyBvbiBiZWhhbGYgb2YgdGhl IHVud2FyZS1SUEwgbm9kZSBhbmQgd2Ugd2VyZSB3b25kZXJpbmcgaWYgd2UgY291bGQgbWFrZSB1 c2Ugb2YgcGFyZW50IGFkZHJlc3MgaW4gc3RvcmluZyBNT1AgdG8gc2lnbmFsIHRoZSByb290IGFi b3V0IHRoaXMgZXh0ZXJuYWwgbm9kZS4gSSBndWVzcyBldmVuIGluIHRoYXQgY2FzZSB3ZSBjYW4g cmVmZXIgdG8gdW5hd2FyZS1sZWF2ZXMvdXNlb2ZycGxpbmZvIHJhdGlvbmFsZSBhbmQgc2VuZCBE QU8gZm9yIGV4dGVybmFsIHRhcmdldHMgZGlyZWN0bHkgdG8gdGhlIHJvb3QgdG8ga2VlcCB0aGUg aGFuZGxpbmcgY29uc2lzdGVudCAoYW5kIG1pbmltYWwgY2hhbmdlcykuDQoNClRoYW5rcywNClJh aHVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNjby5j b20+Pg0KU2VudDogMTggTWF5IDIwMjAgMDc6MzAgUE0NClRvOiBSYWh1bCBKYWRoYXYgPG55cmFo dWxAb3V0bG9vay5jb208bWFpbHRvOm55cmFodWxAb3V0bG9vay5jb20+PjsgUm91dGluZyBPdmVy IExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxA aWV0Zi5vcmc+PjsgcmFiaSBuYXJheWFuIHNhaG9vIDxyYWJpbmFyYXlhbnMwODI4QGdtYWlsLmNv bTxtYWlsdG86cmFiaW5hcmF5YW5zMDgyOEBnbWFpbC5jb20+Pg0KU3ViamVjdDogUkU6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEw LnR4dA0KDQoNCkhlbGxvIFJhaHVsOg0KDQoNCg0KVGhlIHNob3J0IGFuc3dlciBpcyB0aGF0IGJl Y2F1c2Ugd2UgaW50cm9kdWNlIG5vbi1zdG9yaW5nIHNpZ25hbGluZyBhdCB0aGUgZWRnZSBvZiBh IHN0b3JpbmcgbW9kZSBET0RBRy4NCg0KWW91IG1heSBzZWUgaXQgYXMgYW4gZXh0ZW5zaW9uIG91 dHNpZGUgb2YgdGhlIFJQTCBkb21haW4gdGhhdCBpcyBjb3ZlcmVkIGJ5IHRoZSBydWxlIHlvdSBw b2ludGVkIG91dC4NCg0KU2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXJvbGwtdXNlb2ZycGxpbmZvLTM4I3NlY3Rpb24tNC4xDQoNCuKAnA0KDQogICBUaGlzIHNwZWNp ZmljYXRpb24gdXBkYXRlcyBbUkZDNjU1MDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NjU1MD5dIHRvIFJFQ09NTUVORCB0aGF0IGV4dGVybmFsDQoNCiAgIHRhcmdldHMgYXJlIGFkdmVy dGlzZWQgdXNpbmcgTm9uLVN0b3JpbmcgTW9kZSBEQU8gbWVzc2FnaW5nIGV2ZW4gaW4gYQ0KDQog ICBTdG9yaW5nLU1vZGUgbmV0d29yay4NCg0KDQoNCuKAnA0KDQpJcyB0aGF0IHlvdXIgYW5zd2Vy Pw0KDQoNCg0KVGFrZSBjYXJlLA0KDQoNCg0KUGFzY2FsDQoNCg0KDQpGcm9tOiBSYWh1bCBKYWRo YXYgPG55cmFodWxAb3V0bG9vay5jb208bWFpbHRvOm55cmFodWxAb3V0bG9vay5jb20+Pg0KU2Vu dDogZGltYW5jaGUgMTcgbWFpIDIwMjAgMDQ6MjMNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJl cnQpIDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+OyBSb3V0 aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxtYWls dG86cm9sbEBpZXRmLm9yZz4+OyByYWJpIG5hcmF5YW4gc2Fob28gPHJhYmluYXJheWFuczA4MjhA Z21haWwuY29tPG1haWx0bzpyYWJpbmFyYXlhbnMwODI4QGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBS ZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1s ZWF2ZXMtMTAudHh0DQoNCg0KDQpIaSBQYXNjYWwsDQoNCg0KDQpSZXZpc2l0aW5nIHRoaXMgdGhy ZWFkIGJlY2F1c2Ugb2Ygc29tZSBuZXcgbGlnaHQgWzFdLg0KDQoNCg0KUXVlc3Rpb24gaXMsIENh biBhbiBSUEwgbm9kZSBpbiBTdG9yaW5nIE1PUCBzZW5kIGEgREFPIHdpdGggVHJhbnNpdCBJbmZv IE9wdGlvbiB3aXRoIFBhcmVudCBBZGRyZXNzIHN1YmZpZWxkPw0KDQoNCg0KUHJldmlvdXNseSwg eW91IHBvaW50ZWQgb3V0IFJGQzY1NTAgc2VjdGlvbiA5Ljggd2hpY2ggY2xlYXJseSBtZW50aW9u cyB0aGF0ICJQYXJlbnQgQWRkcmVzcyBpbiBTdG9yaW5nIE1PUCBNVVNUIGJlIGVtcHR5Ii4NCg0K DQoNCkhvd2V2ZXIsIGFzIHBlciBTZWN0aW9uIDkuNCwgdGhlIFJGQyBzYXlzLCAiSW4gb3JkZXIg dG8gaW5qZWN0IHN1Y2ggYSAoZXh0ZXJuYWwpIFRhcmdldCBpbiB0aGUgUlBMIG5ldHdvcmssIHRo ZSByb3V0ZXIgTVVTVCBhZHZlcnRpc2UgaXRzZWxmIGFzIHRoZSBET0RBRyBQYXJlbnQgQWRkcmVz cyBzdWJmaWVsZCBpbiB0aGUgVHJhbnNpdC4uLiINCg0KDQoNCkVzc2VudGlhbGx5IFNlY3Rpb24g OS40IGNvbnRyYWRpY3RzIDkuOCBib3RoIHVzaW5nIE1VU1QgY2xhdXNlcy4NCg0KDQoNCkp1c3Qg Zm9yIHRoZSByZWNvcmQsIHRoaXMgZGlzY3Vzc2lvbiBkb2VzIG5vdCBoYXZlIGFueSBpbXBhY3Qg b24gdGhlIHVuYXdhcmUtbGVhdmVzIGRyYWZ0Lg0KDQoNCg0KQmVzdCwNCg0KUmFodWwNCg0KDQoN ClsxXSBuZXcgbGlnaHQ6IFJhYmkgYWN0dWFsbHkgaW5mb3JtZWQgbWUgYWJvdXQgc2VjdGlvbiA5 LjggaW4gY29udGV4dCB0byBhbm90aGVyIG9mZmxpbmUgZGlzY3Vzc2lvbiB3cnQgU3RvcmluZy1S b290LUFjay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVy dEBjaXNjby5jb20+Pg0KU2VudDogMTMgTWFyY2ggMjAyMCAxMjo0OSBBTQ0KVG86IFJhaHVsIEph ZGhhdiA8bnlyYWh1bEBvdXRsb29rLmNvbTxtYWlsdG86bnlyYWh1bEBvdXRsb29rLmNvbT4+OyBS b3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxt YWlsdG86cm9sbEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0DQoNCg0KDQpIZWxs byBSYWh1bA0KDQoNCg0KUkZDIDY1NTAgc2F5czoNCg0KDQoNCuKAnA0KDQoNCg0KOS44PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUwI3NlY3Rpb24tOS44Pi4gIFN0b3JpbmcgTW9k ZQ0KDQoNCg0KDQoNCiAgIEluIFN0b3JpbmcgbW9kZSwgUlBMIHJvdXRlcyBtZXNzYWdlcyBEb3du d2FyZCBieSB0aGUgSVB2NiBkZXN0aW5hdGlvbg0KDQogICBhZGRyZXNzLiAgVGhlIGZvbGxvd2lu ZyBydWxlcyBhcHBseSB0byBub2RlcyB0aGF0IGFyZSBpbiBTdG9yaW5nDQoNCiAgIG1vZGU6DQoN Cg0KDQogICAxLiAgVGhlIERPREFHIFBhcmVudCBBZGRyZXNzIHN1YmZpZWxkIG9mIGEgVHJhbnNt aXQgSW5mb3JtYXRpb24NCg0KICAgICAgIG9wdGlvbiBNVVNUIGJlIGVtcHR5Lg0KDQoNCg0KDQoN CuKAnA0KDQoNCg0KU28gZXZlbiBpZiBpdCBpcyBhIGdvb2QgaWRlYSBpdCByZXF1aXJlcyBuZXcg c3BlY3MgdG8gb3ZlcnJpZGUgUkZDIDY1NTAuDQoNCg0KDQpNb3JlIGJlbG93ICh1c2luZyBQMj4p DQoNCg0KDQoNCg0KRnJvbTogUmFodWwgSmFkaGF2IDxueXJhaHVsQG91dGxvb2suY29tPG1haWx0 bzpueXJhaHVsQG91dGxvb2suY29tPj4NClNlbnQ6IGpldWRpIDEyIG1hcnMgMjAyMCAxNjozMg0K VG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tPj47IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5l dHdvcmtzIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxl YXZlcy0xMC50eHQNCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBmaW5kIGJlbG93IGlubGluZSBh bnN3ZXJzLiBBbHNvLCBJIGRpZCBub3QgZ2V0IGFueSBvYmplY3Rpb24gZnJvbSA2bG8gc28gSSBh ZGRlZCBhIElBTkEgc2VjdGlvbiB0aGF0IHJlZHVjZXMgdGhlIEVBUk8gc3RhdHVzIHJhbmdlIHRv IDAtNjMsIHdoaWNoIHNvbHZlcyB0aGUgaXNzdWUgeW91IHJhaXNlZC4NCg0KDQoNCltSSl0gWWVw LCB0aGF0IGluZGVlZCB0YWtlcyBjYXJlIG9mIGEgbWFqb3IgcG9pbnQg8J+Yii4gUGxlYXNlIGZp bmQgbXkgW1JKXSByZXNwb25zZXMgaW5saW5lLg0KDQoNCg0KDQoNCg0KDQpSZWdhcmRpbmcgdGhp cyBzdGF0ZW1lbnQsDQoNCiJOb24tU3RvcmluZyBNb2RlIERBTyBtZXNzYWdlcyBhcmUgdXNlZCB0 byBzaWduYWwgZXh0ZXJuYWwgcm91dGVzIHRvDQogICB0aGUgUm9vdCwgZXZlbiBpZiB0aGUgRE9E QUcgaXMgb3BlcmF0ZWQgaW4gU3RvcmluZyBNb2RlLiINCg0KDQoNCkkgY291bGRuJ3QgZmluZCBh bnkgdGV4dCB3aGljaCBwcm92aWRlcyByZWFzb25pbmcgdG8gZG8gc28uIFdoeSBub24tc3Rvcmlu ZyBtb2RlIERBTyBpcyBuZWVkZWQgYW5kIHdoeSBzdG9yaW5nIG1vZGUgREFPIHdvbid0IHdvcms/ DQoNCg0KDQpQYXNjYWw+IFdlIG5lZWQgdGhlIGFkZHJlc3Mgb2YgdGhlIDZMUiB0byB0ZXJtaW5h dGUgdGhlIHR1bm5lbCBhbmQgcmVtb3ZlIHRoZSBhcnRpZmFjdHMsIGFuZCB0aGUgTlMgc2lnbmFs aW5nIHdpbGwgZ2l2ZSB1cyB0aGF0LiBUaGlzIGlzIGhvdyB3ZSByZW1vdmVkIHRoZSBoYXNzbGUg b2YgaG9wIGJ5IGhvcCBsaW5rIGxvY2FsIHR1bm5lbHMgdGhhdCB3YXMgaW4gdGhlIG9sZCB1c2Vv ZnJwbGluZm8uDQoNCg0KDQpUaGVyZSBpcyB0aGlzIHRleHQgd2hpY2ggc2F5cywgIlRoZSBOb24t U3RvcmluZyBNb2RlIERBTyBtZXNzYWdpbmcgZW5hYmxlcyB0byBhZHZlcnRpc2UgdGhlIDZMUiB0 aGF0IHNlcnZlcyB0aGUgUlVMIGFuZCBpbmplY3RzIHRoZSByb3V0ZSB0byB0aGUgUm9vdC4iIFRo aXMgY2FuIGJlIGFjaGlldmVkIGV2ZW4gd2l0aCBzdG9yaW5nIG1vZGUgREFPIHdpdGggdGhlIHRh cmdldCBhcyBSVUwgYWRkcmVzcyBhbmQgdHJhbnNpdCBpbmZvcm1hdGlvbiBjb250YWluaW5nIHBh cmVudCBhZGRyZXNzIGFzIGFuY2hvciA2TFIgYWRkcmVzcy4NCg0KDQoNClBhc2NhbCA+IFdoaWNo IGlzIG5vdCB0aGUgbm9ybWFsIHN0b3JpbmcgbW9kZSBzaWduYWxpbmcuDQoNCg0KDQpbUkpdIFll cywgYnV0IDY1NTAgZG9lcyBub3Qgc3RvcCB1cyBmcm9tIGRvaW5nIGl0LiBJbnRlcmVzdGluZ2x5 LCBJIGhhdmUgYSB1c2UtY2FzZSBpbiBteSBkZXBsb3ltZW50IHdoZXJlaW4gSSBuZWVkIHRvIHNl bmQgdGhpcyBwYXJlbnQgYWRkcmVzcyBpbmZvIGV2ZW4gaW4gc3RvcmluZyBNT1AuIEl0IGhlbHBz IHRoZSByb290IGdldCB0aGUgY29tcGxldGUgbmV0d29yayBncmFwaCBldmVuIGluIHN0b3Jpbmcg bW9kZSBmb3IgdmlzdWFsaXphdGlvbiBwdXJwb3NlcyAoaWYgdGhlIGFkbWluIHdhbnRzIHRvIGNo ZWNrIGhvdyB0aGUgbmV0d29yayBpcyBmb3JtZWQsIGhvdyBtYW55IGhvcHMgZXRjIG9uIHRoZSBy b290IGluIHN0b3JpbmcgbW9kZSkuDQoNCg0KDQpQMj4gSXQgZG9lcyBhY3R1YWxseSwgc2VlIGFi b3ZlDQoNCg0KDQpJdCB3b3VsZCBiZSBhbiBoeWJyaWQuIFRoZSBjb29sIHRoaW5nIHdpdGggTlMg aXMgdGhhdCB0aGUgZXh0ZXJuYWwgcHJlZml4ZXMgYXJlIG5vdCB2aXNpYmxlIGluc2lkZSB0aGUg UlBMIGRvbWFpbi4gTGVnYWN5IG5vZGVzIGRvIG5vdCBoYXZlIHRvIGtub3cgdGhleSBleGlzdC4g T25seSB0aGUgNkxSIGF0IHRoZSBib3JkZXIgdGhhdCBpbmplY3QgdGhlIGV4dGVybmFsIHJvdXRl cyBhbmQgdGhlIFJvb3QgYXJlIGF3YXJlIGFuZCBuZWVkIHRvIGtub3cgYWJvdXQgdGhlIG5ldyBz aWduYWxpbmcuIFVzaW5nIGFuIGh5YnJpZCBpbXBhY3RzIGV2ZXJ5IG5vZGUuDQoNCg0KDQpbUkpd IFRoZSBoeWJyaWQgbWF5IG5vdCBuZWNlc3NhcmlseSBpbXBhY3QgZXZlcnkgbm9kZS4gQW4gaW50 ZXJtZWRpYXRlIDZMUiBtYXkgZGVjaWRlIHRvIGlnbm9yZSB0aGF0IGV4dGVybmFsIHRhcmdldCBp biB0aGUgREFPIGFuZCB0aGF0IHdvdWxkIHN0aWxsIGJlIG9rLiBJbiB0aGlzIGNhc2UsIHRoZSBz aWduYWxpbmcgd2lsbCB3b3JrIHRocm91Z2ggbmV4dCBjb21tb24gYW5jZXN0b3Igd2hpY2ggaGFz IHRvIGNhcGFiaWxpdHkgdG8gaG9sZC9wcm9jZXNzIHRoYXQga2luZCBvZiBpbmZvLg0KDQoNCg0K UDI+IHdoaWNoIGlzIHN0aWxsIGFuIGltcGFjdDsgbmV3IGNvZGUgdG8gcmVjb2duaXplIHRoZSDi gJhF4oCZIGZsYWcgYW5kIGRlY2lkZSB0byBpZ25vcmUgdGhlIGFkZHJlc3MuIEEgbGVnYWN5IG5v ZGUgd291bGQgbm90IGRvIHRoZSByaWdodCB0aGluZy4NCg0KDQoNClRyeWluZyB0byB1bmRlcnN0 YW5kIHRoZSByZWFzb24gYmVjYXVzZSB0aGlzIG1vZGUgb2Ygc2lnbmFsaW5nIGhhcyBpbXBsaWNh dGlvbnMgKGFscmVhZHkgY292ZXJlZCBpbiB0aGUgZHJhZnQpLCBwYXJ0aWN1bGFybHkgdGhhdCwg d2hlbiB0aGUgREFHIGlzIG9wZXJhdGluZyBpbiBzdG9yaW5nIG1vZGUsIHRoZSBjb21tdW5pY2F0 aW9uIHRvIFJVTCBmcm9tIG90aGVyIFJBTnMgd291bGQgbWFuZGF0b3JpbHkgaGF2ZSB0byBiZSBy b3V0ZWQgdGhyb3VnaCByb290IG9ubHkuIElmIHdlIHVzZSBzdG9yaW5nIG1vZGUgREFPIHRoZW4g dGhpcyBjb3VsZCBiZSBvcHRpbWl6ZWQuIE5vdCBzdXJlIGlmIEkgYW0gbWlzc2luZyBhbnl0aGlu Zz8NCg0KDQoNClBhc2NhbCA+IFdlbGwsIHllcywgd2UgY291bGQgaGF2ZSBkb25lIHRoYXQgYXMg d2VsbC4gVGhlIHBhdGggY291bGQgYmUgb3B0aW1pemVkIGJ1dA0KDQoqICBpdCB3b3VsZCBtZWFu IHRoYXQgdGhlIGNvbW1vbiBwYXJlbnQgaGFzIHRvIGVuY2Fwc3VsYXRlIHRvIHRoZSA2TFIsIHdo aWNoIGlzIGFuIGFkZGl0aW9uYWwgZnVuY3Rpb24gdGhlcmUNCg0KKiBJdCB3b3VsZCBhbHNvIG1l YW4gdGhhdCB0aGUgbmV0d29yayBoYXMgb3QgYmUgYXdhcmUgb2YgZXh0ZXJuYWwgcm91dGVzLCB3 aGljaCBtYXkgYmUgdG9vIG1hbnkgZm9yIHRoZSBTTSB0YWJsZXMuDQoNCg0KDQpbUkpdIEkgYW0g anVzdCBrZWVuIG9uIGRvaW5nIHRoaXMgYmVjYXVzZSBpdCBtYWtlcyB0aGluZ3MgZmxleGlibGUu IEFuY2hvciA2TFIgaGFzIGJvdGggb3B0aW9ucyBvZiBzZW5kaW5nIE5TLURBTyBvciBzdG9yaW5n IERBTy4gSW50ZXJtZWRpYXRlIDZMUnMgYWxzbyBoYXZlIGJvdGggb3B0aW9ucywgaG9ub3IgdGhl IGV4dGVybmFsIHRhcmdldCBpbmZvIG9yIGlnbm9yZSBpdCBhbmQganVzdCBwYXNzIGl0IG9uLg0K DQoNCg0KUDI+IEnigJltIGhhcHB5IHRvIGRpc2N1c3MgaXQgYW5kIHNlZSBpZiBhbmQgaG93IHdl IG9wZW4gUlBMIGluIHRoYXQgZGlyZWN0aW9uLiBCdXQgZm9yIHNob3J0IHRlcm0gd2XigJlyZSBz aGlwcGluZyB1c2VvZnJwbGluZm8gYW5kIFJVTCB3aXRoIHRoZSBsb3cgaGFuZ2luZyBmcnVpdC4N Cg0KDQoNClByb3MgYW5kIGNvbnMgSSBndWVzcy4gV2Ugd2VudCBmb3IgdGhlIHNpbXBsZSBhbmQg YmFja3dhcmQgY29tcGF0aWJsZSB3YXkuDQoNCg0KDQpbUkpdIFllcywgQmFja3dhcmQgY29tcGF0 aWJpbGl0eSBtYXkgYmUgYW4gaXNzdWUgYmVjYXVzZSBpbnRlcm1lZGlhdGUgNkxScyBvcGVyYXRp bmcgaW4gcHVyZSBzdG9yaW5nIG1vZGUgd2lsbCB0cnkgdG8gY2FjaGUgdGhlIGV4dGVybmFsIHRh cmdldCBhbmQgbWF5IG5vdCBiZSBhYmxlIHRvIGRvIElQLWluLUlQIGF0IHRoZWlyIHBvaW50LiBI b3dldmVyLCBoYW5kbGluZyB0aGlzIGNvbXBhdGliaWxpdHkgbWF5IG5vdCBiZSBhIGJpZyBjaGFs bGVuZ2UuIFRoZSBmbGV4aWJpbGl0eSB0aGlzIHByb3ZpZGVzIGlzIHZlcnkgY29tcGVsbGluZyB0 byBtZS4gV2l0aCBEQU8gcHJvamVjdGlvbiwgd2UgaGF2ZSBhbHJlYWR5IGVudGVyZWQgdGhhdCB6 b25lIHdoZXJlIHRoZSBub2RlcyBjb3VsZCBiZSBoeWJyaWQgaW4gbmF0dXJlLg0KDQoNCg0KUFQy PiB3aXRoIHRoZSBjYXBhYmlsaXR5IHdvcmsgd2XigJlsbCBiZSBhYmxlIHRvIGludHJvZHVjZSB0 aGlzIGFuZCBtb3JlIDogKQ0KDQoNCg0KDQoNClRha2UgY2FyZSwNCg0KDQoNClBhc2NhbA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBSb2xsIDxyb2xsLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydD00MGNpc2NvLi5jb21AZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOnB0aHViZXJ0PTQwY2lzY28uLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTZW50 OiAxMiBNYXJjaCAyMDIwIDA3OjM4IFBNDQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQg TG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogW1JvbGxdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYt cm9sbC11bmF3YXJlLWxlYXZlcy0xMC50eHQNCg0KDQoNCkRlYXIgYWxsDQoNCkFzIGRpc2N1c3Nl ZCB3aXRoIHRoZSBJT1QgRElSLCB0aGlzIGRyYWZ0IGlzIG5vdCB0aGUgZ2F0aW5nIGZhY3RvciBm b3IgYWxsIGNsdXN0ZXIgQzMxMC4NCkluIG9yZGVyIHRvIHByb2dyZXNzIEkgbWFkZSBhIGZ1bGwg cGFzcyBvbiBpdCBhbmQgZml4ZWQgYSBmZXcgYnVncyBhbmQgbWlzYWxpZ25tZW50cyB3aXRoIHVz ZW9mcnBsaW5mby4NCg0KSSBiZWxpZXZlIHRoZSBkb2MgaXMgcmlwZSBmb3IgV0dMQy4NCg0KTWFu eSB0aGFua3MNCg0KUGFzY2FsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pj4NClNlbnQ6IGpldWRpIDEyIG1hcnMgMjAyMCAxNTowNA0KVG86IE1pY2hhZWwgUmljaGFyZHNv biA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+Pjsg TWljaGFlbCBDLiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitp ZXRmQHNhbmRlbG1hbi5jYT4+OyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBj aXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVz LTEwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVy dCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBk cmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMNClJldmlzaW9uOiAgICAgICAxMA0KVGl0bGU6 ICAgICAgICAgIFJvdXRpbmcgZm9yIFJQTCBMZWF2ZXMNCkRvY3VtZW50IGRhdGU6ICAyMDIwLTAz LTEyDQpHcm91cDogICAgICAgICAgcm9sbA0KUGFnZXM6ICAgICAgICAgIDMyDQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcm9s bC11bmF3YXJlLWxlYXZlcy0xMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC11bmF3 YXJlLWxlYXZlcy0xMDxodHRwczovL3Rvb2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9s bC11bmF3YXJlLWxlYXZlcy0xMD4NCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcw0KRGlmZjog ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJv bGwtdW5hd2FyZS1sZWF2ZXMtMTANCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24g ZXh0ZW5kcyBSRkM2NTUwIGFuZCBSRkM4NTA1IHRvIHByb3ZpZGUgdW5pY2FzdCBhbmQNCiAgIG11 bHRpY2FzdCByb3V0aW5nIHNlcnZpY2VzIGluIGEgUlBMIGRvbWFpbiB0byA2TE5zIHRoYXQgYXJl IHBsYWluDQogICBIb3N0cyBhbmQgZG8gbm90IHBhcnRpY2lwYXRlIHRvIFJQTCwgYW5kIGVuYWJs ZXMgdGhlIFJQTCBSb290IHRvDQogICBwcm94eSB0aGUgRURBUi9FREFDIGZsb3cgb24gYmVoYWxm IG9mIHRoZSBSVUxzIGFuZCBSQU5zIGluIGl0cyBET0RBRy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlz dA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K --_000_MN2PR11MB3565CC15E506F4692CABC524D8B60MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkg TGlnaHQiOw0KCXBhbm9zZS0xOjIgMTUgMyAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAy IDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxp bms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5I ZWFkaW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWls eToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUYzNzYzO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAueG1zb25vcm1hbCwgbGkueG1z b25vcm1hbCwgZGl2Lnhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29ub3JtYWw7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLnhtc29ub3JtYWwwLCBsaS54 bXNvbm9ybWFsMCwgZGl2Lnhtc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOnhfbXNvbm9ybWFs MDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAueHhtc29ub3JtYWws IGxpLnh4bXNvbm9ybWFsLCBkaXYueHhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eF94bXNv bm9ybWFsOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC54eG1zb25v cm1hbDAsIGxpLnh4bXNvbm9ybWFsMCwgZGl2Lnh4bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTp4X3htc29ub3JtYWwwOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC54eHhtc29ub3JtYWwsIGxpLnh4eG1zb25vcm1hbCwgZGl2Lnh4eG1zb25vcm1hbA0KCXttc28t c3R5bGUtbmFtZTp4X3h4bXNvbm9ybWFsOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KcC54eG1zb2NocGRlZmF1bHQsIGxpLnh4bXNvY2hwZGVmYXVsdCwgZGl2Lnh4bXNv Y2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp4X3htc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC54bXNvY2hwZGVmYXVsdCwgbGkueG1zb2No cGRlZmF1bHQsIGRpdi54bXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp4X21zb2NocGRl ZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLnhtc29o eXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29oeXBlcmxpbms7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueG1zb2h5cGVybGlua2ZvbGxvd2Vk DQoJe21zby1zdHlsZS1uYW1lOnhfbXNvaHlwZXJsaW5rZm9sbG93ZWQ7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi54aGVhZGluZzNjaGFyDQoJe21z by1zdHlsZS1uYW1lOnhfaGVhZGluZzNjaGFyOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0 IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjM3NjM7fQ0Kc3Bhbi54aHRtbHByZWZvcm1hdHRlZGNo YXINCgl7bXNvLXN0eWxlLW5hbWU6eF9odG1scHJlZm9ybWF0dGVkY2hhcjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLnh4bXNvaHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnhfeG1z b2h5cGVybGluazsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi54eG1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnhfeG1zb2h5cGVy bGlua2ZvbGxvd2VkOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4ueHhoZWFkaW5nM2NoYXINCgl7bXNvLXN0eWxlLW5hbWU6eF94aGVhZGluZzNjaGFy Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7 fQ0Kc3Bhbi54eGh0bWxwcmVmb3JtYXR0ZWRjaGFyDQoJe21zby1zdHlsZS1uYW1lOnhfeGh0bWxw cmVmb3JtYXR0ZWRjaGFyOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi54eGVt YWlsc3R5bGUyMg0KCXttc28tc3R5bGUtbmFtZTp4X3hlbWFpbHN0eWxlMjI7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnh4ZW1h aWxzdHlsZTIzDQoJe21zby1zdHlsZS1uYW1lOnhfeGVtYWlsc3R5bGUyMzsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ueGVtYWls c3R5bGUzMw0KCXttc28tc3R5bGUtbmFtZTp4X2VtYWlsc3R5bGUzMzsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTQxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkhlbGxvIFJhaHVsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkEgdmVyeSBpbnRlcmVzdGluZyBjb21tZW50Lg0KPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlll cywgdGhlIDZMUiBpcyBleHBlY3RlZCB0byBkbyB3aGF04oCZcyBuZWNlc3NhcnkgdG8gYmVzdCBz ZXJ2ZSB0aGUgUlBMIHVuYXdhcmUgbGVhZi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIFJVTCBpcyBub3QgYXdhcmUgb2YgUlBM IHNvIGl0IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIDZMUiBpcyBkb2luZyBzdG9yaW5nLXJvb3Qt YWNrIG9yIGV2ZW4gdGFsa2luZyBSUEwgYXQgYWxsIGZvciB0aGF0IG1hdHRlci4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XaGF0 IG1ha2VzIHNlbnNlIGlzIHRoYXQgb24gdGhlIGZpcnN0IHJlZ2lzdHJhdGlvbiwgdGhlIDZMUiAo b3B0aW9uYWxseSkgd2FpdHMgZm9yIHRoZSBzdG9yaW5nLXJvb3QtYWNrIGJlZm9yZSBpdCBzZW5k cyB0aGUgTkEoRUFSTykgYmFjay4gVGhpcyBjaGFuZ2Ugb2YgdGhlIGZsb3cgd291bGQgYmUgaW5k aWNhdGVkDQogaW4geW91ciA8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFj ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3 aGl0ZSI+c3RvcmluZy1yb290LWFjazwvc3Bhbj48L2ZvbnQ+IGRyYWZ0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RG9lcyB0aGF0IHdvcms/PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBhc2Nh bDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPiBS YWh1bCBKYWRoYXYgJmx0O255cmFodWxAb3V0bG9vay5jb20mZ3Q7DQo8YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBsdW5kaSAxOCBtYWkgMjAy MCAxNDowMzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+ PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDtwdGh1YmVydEBjaXNjby5jb20mZ3Q7 OyBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9sbEBpZXRm Lm9yZyZndDs7IHJhYmkgbmFyYXlhbiBzYWhvbyAmbHQ7cmFiaW5hcmF5YW5zMDgyOEBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9z cGFuPjwvYj4gUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xs LXVuYXdhcmUtbGVhdmVzLTEwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlNvIGV2ZW4gaW4gc3RvcmluZyBNT1AgYSA2TE4vNkxSIHNob3VsZCB1c2Ugbm9uLXN0b3Jp bmcgTU9QIHNpZ25hbGluZyB0byBzZW5kIHRoZSBleHRlcm5hbCByb3V0ZXMgdG8gdGhlIHJvb3Qu IEkgZ3Vlc3MgdGhpcyBpcyB3aGF0IGlzIGRvbmUgaW4gdW5hd2FyZS1sZWF2ZXMNCiBhcyB3ZWxs LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5UaGlzIGRvZXMg YW5zd2VyIG15IHF1ZXN0aW9uLiBNYW55IFRoYW5rcy48L3NwYW4+PC9mb250Pjxmb250IHNpemU9 IjMiIGNvbG9yPSJibGFjayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5Gb3Igc3Rv cmluZy1yb290LWFjaywgUmFiaSBwb2ludGVkIG91dCBhIGNhc2Ugd2hlcmUgdGhlIDZMTi82TFIg c2VuZHMgREFPIG9uIGJlaGFsZiBvZiB0aGUgdW53YXJlLVJQTCBub2RlIGFuZCB3ZSB3ZXJlIHdv bmRlcmluZyBpZg0KIHdlIGNvdWxkIG1ha2UgdXNlIG9mIHBhcmVudCBhZGRyZXNzIGluIHN0b3Jp bmcgTU9QIHRvIHNpZ25hbCB0aGUgcm9vdCBhYm91dCB0aGlzIGV4dGVybmFsIG5vZGUuIEkgZ3Vl c3MgZXZlbiBpbiB0aGF0IGNhc2Ugd2UgY2FuIHJlZmVyIHRvIHVuYXdhcmUtbGVhdmVzL3VzZW9m cnBsaW5mbyByYXRpb25hbGUgYW5kIHNlbmQgREFPIGZvciBleHRlcm5hbCB0YXJnZXRzIGRpcmVj dGx5IHRvIHRoZSByb290IHRvIGtlZXAgdGhlIGhhbmRsaW5nIGNvbnNpc3RlbnQNCiAoYW5kIG1p bmltYWwgY2hhbmdlcykuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2si PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+VGhhbmtzLDwvc3Bhbj48L2ZvbnQ+PGZv bnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2s7YmFja2dy b3VuZDp3aGl0ZSI+UmFodWw8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFj ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+DQo8aHIgc2l6ZT0iMiIgd2lk dGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBpZD0i ZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBj b2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZv bnQgY29sb3I9ImJsYWNrIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBQYXNjYWwgVGh1YmVy dCAocHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIj5wdGh1 YmVydEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TZW50Ojwvc3Bhbj48L2I+IDE4IE1heSAyMDIwIDA3OjMwIFBNPGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IFJhaHVsIEphZGhhdiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm55cmFodWxAb3V0bG9vay5jb20iPm55cmFodWxAb3V0bG9vay5jb208 L2E+Jmd0OzsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0Ozxh IGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs7IHJhYmkg bmFyYXlhbiBzYWhvbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhYmluYXJheWFuczA4MjhAZ21haWwu Y29tIj5yYWJpbmFyYXlhbnMwODI4QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwLnR4dDwv c3Bhbj48L2ZvbnQ+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGVsbG8gUmFodWw6PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VGhlIHNob3J0IGFuc3dlciBpcyB0aGF0IGJlY2F1c2Ugd2UgaW50cm9kdWNlIG5vbi1zdG9y aW5nIHNpZ25hbGluZyBhdCB0aGUgZWRnZSBvZiBhIHN0b3JpbmcgbW9kZSBET0RBRy48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Zb3UgbWF5 IHNlZSBpdCBhcyBhbiBleHRlbnNpb24gb3V0c2lkZSBvZiB0aGUgUlBMIGRvbWFpbiB0aGF0IGlz IGNvdmVyZWQgYnkgdGhlIHJ1bGUgeW91IHBvaW50ZWQgb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlZQ0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC11c2VvZnJwbGluZm8tMzgjc2Vj dGlvbi00LjEiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC11 c2VvZnJwbGluZm8tMzgjc2VjdGlvbi00LjE8L2E+IDxvOnA+DQo8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCcPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gdXBkYXRl cyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NTAiIHRpdGxlPSIm cXVvdDtSUEw6IElQdjYgUm91dGluZyBQcm90b2NvbCBmb3IgTG93LVBvd2VyIGFuZCBMb3NzeSBO ZXR3b3JrcyZxdW90OyI+UkZDNjU1MDwvYT5dDQogdG8gUkVDT01NRU5EIHRoYXQgZXh0ZXJuYWw8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRhcmdl dHMgYXJlIGFkdmVydGlzZWQgdXNpbmcgTm9uLVN0b3JpbmcgTW9kZSBEQU8gbWVzc2FnaW5nIGV2 ZW4gaW4gYTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgU3RvcmluZy1Nb2RlIG5ldHdvcmsuDQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JcyB0aGF0IHlvdXIgYW5zd2VyPzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlRha2UgY2FyZSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inht c29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJv bTo8L3NwYW4+PC9mb250PjwvYj4gUmFodWwgSmFkaGF2ICZsdDs8YSBocmVmPSJtYWlsdG86bnly YWh1bEBvdXRsb29rLmNvbSI+bnlyYWh1bEBvdXRsb29rLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBkaW1hbmNoZSAx NyBtYWkgMjAyMCAwNDoyMzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzo8L3NwYW4+PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWls dG86cHRodWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0OzsgUm91dGlu ZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0OzxhIGhyZWY9Im1haWx0bzpy b2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs7IHJhYmkgbmFyYXlhbiBzYWhvbyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJhYmluYXJheWFuczA4MjhAZ21haWwuY29tIj5yYWJpbmFyYXlh bnMwODI4QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwLnR4dDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+SGkgUGFzY2FsLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0i YmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5SZXZpc2l0aW5nIHRoaXMgdGhyZWFkIGJlY2F1c2Ugb2Ygc29tZSBuZXcgbGlnaHQg WzFdLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RdWVzdGlvbiBpcywgQ2FuIGFuIFJQ TCBub2RlIGluIFN0b3JpbmcgTU9QIHNlbmQgYSBEQU8gd2l0aCBUcmFuc2l0IEluZm8gT3B0aW9u IHdpdGggUGFyZW50IEFkZHJlc3Mgc3ViZmllbGQ/PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIzIiBj b2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlByZXZpb3VzbHksIHlvdSBwb2ludGVkIG91dCBSRkM2NTUwIHNlY3Rpb24gOS44IHdoaWNo IGNsZWFybHkgbWVudGlvbnMgdGhhdCAmcXVvdDtQYXJlbnQgQWRkcmVzcyBpbiBTdG9yaW5nIE1P UCBNVVNUIGJlIGVtcHR5JnF1b3Q7LiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29s b3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2si IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Ib3dldmVyLCBhcyBwZXIgU2VjdGlvbiA5LjQsIHRoZSBSRkMgc2F5cywgJnF1b3Q7SW4gb3Jk ZXIgdG8gaW5qZWN0IHN1Y2ggYSAoZXh0ZXJuYWwpIFRhcmdldCBpbiB0aGUgUlBMIG5ldHdvcmss IHRoZSByb3V0ZXIgTVVTVCBhZHZlcnRpc2UgaXRzZWxmIGFzIHRoZQ0KIERPREFHIFBhcmVudCBB ZGRyZXNzIHN1YmZpZWxkIGluIHRoZSBUcmFuc2l0Li4uJnF1b3Q7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBz aXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjMiIGNv bG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkVzc2VudGlhbGx5IFNlY3Rpb24gOS40IGNvbnRyYWRpY3RzIDkuOCBib3Ro IHVzaW5nIE1VU1QgY2xhdXNlcy48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SnVzdCBm b3IgdGhlIHJlY29yZCwgdGhpcyBkaXNjdXNzaW9uIGRvZXMgbm90IGhhdmUgYW55IGltcGFjdCBv biB0aGUgdW5hd2FyZS1sZWF2ZXMgZHJhZnQuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xv cj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkJlc3QsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJ4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5SYWh1bDwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48Zm9u dCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5bMV0gbmV3IGxpZ2h0OiBSYWJpIGFjdHVhbGx5IGlu Zm9ybWVkIG1lIGFib3V0IHNlY3Rpb24gOS44IGluIGNvbnRleHQgdG8gYW5vdGhlciBvZmZsaW5l IGRpc2N1c3Npb24gd3J0IFN0b3JpbmctUm9vdC1BY2suPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4NCjxociBzaXplPSIxIiB3aWR0aD0iOTglIiBhbGln bj0iY2VudGVyIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlGd2RN c2ciPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2s7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBjb2xvcj0i YmxhY2siPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVy dCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6 PC9zcGFuPjwvYj4gMTMgTWFyY2ggMjAyMCAxMjo0OSBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBSYWh1bCBKYWRoYXYgJmx0OzxhIGhyZWY9 Im1haWx0bzpueXJhaHVsQG91dGxvb2suY29tIj5ueXJhaHVsQG91dGxvb2suY29tPC9hPiZndDs7 IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzICZsdDs8YSBocmVmPSJt YWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwLnR4 dDwvc3Bhbj48L2ZvbnQ+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxsbyBSYWh1 bDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UkZDIDY1NTAgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM2NTUwI3NlY3Rpb24tOS44Ij48Yj48Zm9udCBzaXplPSI0IiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+OS44PC9zcGFuPjwvZm9udD48L2I+PC9h Pjwvc3Bhbj48L2ZvbnQ+PGEgbmFtZT0ieF94X3NlY3Rpb24tOS44Ij48L2E+PGI+PGZvbnQgc2l6 ZT0iNCIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPi4mbmJz cDsNCiBTdG9yaW5nIE1vZGU8L3NwYW4+PC9mb250PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inh4bXNv bm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElu IFN0b3JpbmcgbW9kZSwgUlBMIHJvdXRlcyBtZXNzYWdlcyBEb3dud2FyZCBieSB0aGUgSVB2NiBk ZXN0aW5hdGlvbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieHhtc29u b3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGFkZHJlc3MuJm5ic3A7IFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gbm9kZXMg dGhhdCBhcmUgaW4gU3RvcmluZzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IG1vZGU6PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inh4bXNv bm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyAxLiZuYnNwOyBUaGUgRE9EQUcgUGFyZW50IEFkZHJlc3Mgc3ViZmllbGQgb2YgYSBU cmFuc21pdCBJbmZvcm1hdGlvbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wdGlvbiBNVVNUIGJlIGVt cHR5Ljwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4bXNv bm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U28gZXZlbiBpZiBpdCBpcyBhIGdvb2QgaWRl YSBpdCByZXF1aXJlcyBuZXcgc3BlY3MgdG8gb3ZlcnJpZGUgUkZDIDY1NTAuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Nb3Jl IGJlbG93ICh1c2luZyBQMiZndDspDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Inh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj4gUmFodWwgSmFkaGF2ICZsdDs8YSBocmVmPSJtYWls dG86bnlyYWh1bEBvdXRsb29rLmNvbSI+bnlyYWh1bEBvdXRsb29rLmNvbTwvYT4mZ3Q7DQo8YnI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBqZXVk aSAxMiBtYXJzIDIwMjAgMTY6MzI8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86PC9zcGFuPjwvYj4gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDs7IFJv dXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzICZsdDs8YSBocmVmPSJtYWls dG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEwLnR4dDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4eG1zb25vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4 bXNvbm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ4X3hfZGl2UnBseUZ3ZE1zZyI+ DQo8cCBjbGFzcz0ieHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IlNlZ29lIFVJIEVtb2ppIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2Vnb2UgVUkgRW1vamkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNh bnMtc2VyaWYiPlBsZWFzZSBmaW5kIGJlbG93IGlubGluZSBhbnN3ZXJzLiBBbHNvLCBJIGRpZCBu b3QgZ2V0IGFueSBvYmplY3Rpb24gZnJvbSA2bG8gc28gSSBhZGRlZCBhIElBTkEgc2VjdGlvbiB0 aGF0IHJlZHVjZXMgdGhlIEVBUk8NCiBzdGF0dXMgcmFuZ2UgdG8gMC02Mywgd2hpY2ggc29sdmVz IHRoZSBpc3N1ZSB5b3UgcmFpc2VkLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IlNlZ29lIFVJ IEVtb2ppIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj5bUkpdIFllcCwgdGhhdCBpbmRlZWQgdGFr ZXMgY2FyZSBvZiBhIG1ham9yIHBvaW50Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJT ZWdvZSBVSSBFbW9qaSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVt b2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIyOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i U2Vnb2UgVUkgRW1vamkiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBF bW9qaSZxdW90OyxzYW5zLXNlcmlmIj4uDQogUGxlYXNlIGZpbmQgbXkgW1JKXSByZXNwb25zZXMg aW5saW5lLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4 eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+UmVnYXJkaW5nIHRoaXMgc3RhdGVtZW50LDwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtOb24tU3RvcmluZyBNb2RlIERBTyBt ZXNzYWdlcyBhcmUgdXNlZCB0byBzaWduYWwgZXh0ZXJuYWwgcm91dGVzIHRvPGJyPg0KJm5ic3A7 ICZuYnNwO3RoZSBSb290LCBldmVuIGlmIHRoZSBET0RBRyBpcyBvcGVyYXRlZCBpbiBTdG9yaW5n IE1vZGUuJnF1b3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5JIGNvdWxkbid0 IGZpbmQgYW55IHRleHQgd2hpY2ggcHJvdmlkZXMgcmVhc29uaW5nIHRvIGRvIHNvLiBXaHkgbm9u LXN0b3JpbmcgbW9kZSBEQU8gaXMgbmVlZGVkIGFuZCB3aHkgc3RvcmluZyBtb2RlIERBTyB3b24n dCB3b3JrPw0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29u b3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlBhc2NhbCZndDsgV2UgbmVlZCB0aGUgYWRkcmVzcyBvZiB0aGUg NkxSIHRvIHRlcm1pbmF0ZSB0aGUgdHVubmVsIGFuZCByZW1vdmUgdGhlIGFydGlmYWN0cywgYW5k IHRoZSBOUyBzaWduYWxpbmcgd2lsbCBnaXZlIHVzIHRoYXQuIFRoaXMgaXMgaG93IHdlIHJlbW92 ZWQgdGhlIGhhc3NsZSBvZiBob3AgYnkNCiBob3AgbGluayBsb2NhbCB0dW5uZWxzIHRoYXQgd2Fz IGluIHRoZSBvbGQgdXNlb2ZycGxpbmZvLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj ayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPlRoZXJlIGlzIHRoaXMgdGV4dCB3aGljaCBzYXlzLCAmcXVvdDtUaGUgTm9uLVN0b3Jpbmcg TW9kZSBEQU8gbWVzc2FnaW5nIGVuYWJsZXMgdG8gYWR2ZXJ0aXNlIHRoZSA2TFIgdGhhdCZuYnNw O3NlcnZlcyB0aGUgUlVMIGFuZCBpbmplY3RzIHRoZSByb3V0ZSB0byB0aGUgUm9vdC4mcXVvdDsN CiBUaGlzIGNhbiBiZSBhY2hpZXZlZCBldmVuIHdpdGggc3RvcmluZyBtb2RlIERBTyB3aXRoIHRo ZSB0YXJnZXQgYXMgUlVMIGFkZHJlc3MgYW5kIHRyYW5zaXQgaW5mb3JtYXRpb24gY29udGFpbmlu ZyBwYXJlbnQgYWRkcmVzcyBhcyBhbmNob3IgNkxSIGFkZHJlc3MuPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlBhc2NhbCAmZ3Q7IFdoaWNoIGlzIG5vdCB0aGUgbm9ybWFsIHN0b3JpbmcgbW9kZSBz aWduYWxpbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4 eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltSSl0gWWVzLCBidXQgNjU1MCBkb2VzIG5vdCBzdG9w IHVzIGZyb20gZG9pbmcgaXQuIEludGVyZXN0aW5nbHksIEkgaGF2ZSBhIHVzZS1jYXNlIGluIG15 IGRlcGxveW1lbnQgd2hlcmVpbiBJIG5lZWQgdG8gc2VuZCB0aGlzIHBhcmVudCBhZGRyZXNzIGlu Zm8gZXZlbiBpbiBzdG9yaW5nIE1PUC4gSXQNCiBoZWxwcyB0aGUgcm9vdCBnZXQgdGhlIGNvbXBs ZXRlIG5ldHdvcmsgZ3JhcGggZXZlbiBpbiBzdG9yaW5nIG1vZGUgZm9yIHZpc3VhbGl6YXRpb24g cHVycG9zZXMgKGlmIHRoZSBhZG1pbiB3YW50cyB0byBjaGVjayBob3cgdGhlIG5ldHdvcmsgaXMg Zm9ybWVkLCBob3cgbWFueSBob3BzIGV0YyBvbiB0aGUgcm9vdCBpbiBzdG9yaW5nIG1vZGUpLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5QMiZndDsgSXQgZG9lcyBhY3R1YWxseSwgc2VlIGFib3ZlPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkl0IHdv dWxkIGJlIGFuIGh5YnJpZC4gVGhlIGNvb2wgdGhpbmcgd2l0aCBOUyBpcyB0aGF0IHRoZSBleHRl cm5hbCBwcmVmaXhlcyBhcmUgbm90IHZpc2libGUgaW5zaWRlIHRoZSBSUEwgZG9tYWluLiBMZWdh Y3kgbm9kZXMgZG8gbm90IGhhdmUgdG8ga25vdyB0aGV5IGV4aXN0LiBPbmx5IHRoZSA2TFINCiBh dCB0aGUgYm9yZGVyIHRoYXQgaW5qZWN0IHRoZSBleHRlcm5hbCByb3V0ZXMgYW5kIHRoZSBSb290 IGFyZSBhd2FyZSBhbmQgbmVlZCB0byBrbm93IGFib3V0IHRoZSBuZXcgc2lnbmFsaW5nLiBVc2lu ZyBhbiBoeWJyaWQgaW1wYWN0cyBldmVyeSBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUkpdIFRoZSBoeWJyaWQg bWF5IG5vdCBuZWNlc3NhcmlseSBpbXBhY3QgZXZlcnkgbm9kZS4gQW4gaW50ZXJtZWRpYXRlIDZM UiBtYXkgZGVjaWRlIHRvIGlnbm9yZSB0aGF0IGV4dGVybmFsIHRhcmdldCBpbiB0aGUgREFPIGFu ZCB0aGF0IHdvdWxkIHN0aWxsIGJlIG9rLiBJbiB0aGlzIGNhc2UsIHRoZQ0KIHNpZ25hbGluZyB3 aWxsIHdvcmsgdGhyb3VnaCBuZXh0IGNvbW1vbiBhbmNlc3RvciB3aGljaCBoYXMgdG8gY2FwYWJp bGl0eSB0byBob2xkL3Byb2Nlc3MgdGhhdCBraW5kIG9mIGluZm8uJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAy Jmd0OyB3aGljaCBpcyBzdGlsbCBhbiBpbXBhY3Q7IG5ldyBjb2RlIHRvIHJlY29nbml6ZSB0aGUg 4oCYReKAmSBmbGFnIGFuZCBkZWNpZGUgdG8gaWdub3JlIHRoZSBhZGRyZXNzLiBBIGxlZ2FjeSBu b2RlIHdvdWxkIG5vdCBkbyB0aGUgcmlnaHQgdGhpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+VHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHJlYXNv biBiZWNhdXNlIHRoaXMgbW9kZSBvZiBzaWduYWxpbmcgaGFzIGltcGxpY2F0aW9ucyAoYWxyZWFk eSBjb3ZlcmVkIGluIHRoZSBkcmFmdCksIHBhcnRpY3VsYXJseSB0aGF0LCB3aGVuIHRoZSBEQUcg aXMNCiBvcGVyYXRpbmcgaW4gc3RvcmluZyBtb2RlLCB0aGUgY29tbXVuaWNhdGlvbiB0byBSVUwg ZnJvbSBvdGhlciBSQU5zIHdvdWxkIG1hbmRhdG9yaWx5IGhhdmUgdG8gYmUgcm91dGVkIHRocm91 Z2ggcm9vdCBvbmx5LiBJZiB3ZSB1c2Ugc3RvcmluZyBtb2RlIERBTyB0aGVuIHRoaXMgY291bGQg YmUgb3B0aW1pemVkLiBOb3Qgc3VyZSBpZiBJIGFtIG1pc3NpbmcgYW55dGhpbmc/PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlBhc2NhbCAmZ3Q7IFdlbGwsIHllcywgd2UgY291bGQgaGF2ZSBkb25lIHRoYXQgYXMgd2VsbC4g VGhlIHBhdGggY291bGQgYmUgb3B0aW1pemVkIGJ1dDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KiAmbmJzcDtpdCB3b3VsZCBtZWFuIHRo YXQgdGhlIGNvbW1vbiBwYXJlbnQgaGFzIHRvIGVuY2Fwc3VsYXRlIHRvIHRoZSA2TFIsIHdoaWNo IGlzIGFuIGFkZGl0aW9uYWwgZnVuY3Rpb24gdGhlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiogSXQgd291bGQgYWxzbyBtZWFuIHRo YXQgdGhlIG5ldHdvcmsgaGFzIG90IGJlIGF3YXJlIG9mIGV4dGVybmFsIHJvdXRlcywgd2hpY2gg bWF5IGJlIHRvbyBtYW55IGZvciB0aGUgU00gdGFibGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUkpdIEkgYW0ganVz dCBrZWVuIG9uIGRvaW5nIHRoaXMgYmVjYXVzZSBpdCBtYWtlcyB0aGluZ3MgZmxleGlibGUuIEFu Y2hvciA2TFIgaGFzIGJvdGggb3B0aW9ucyBvZiBzZW5kaW5nIE5TLURBTyBvciBzdG9yaW5nIERB Ty4gSW50ZXJtZWRpYXRlIDZMUnMgYWxzbyBoYXZlIGJvdGggb3B0aW9ucywNCiBob25vciB0aGUg ZXh0ZXJuYWwgdGFyZ2V0IGluZm8gb3IgaWdub3JlIGl0IGFuZCBqdXN0IHBhc3MgaXQgb24uPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlAyJmd0OyBJ4oCZbSBoYXBweSB0byBkaXNjdXNzIGl0IGFuZCBzZWUgaWYgYW5kIGhv dyB3ZSBvcGVuIFJQTCBpbiB0aGF0IGRpcmVjdGlvbi4gQnV0IGZvciBzaG9ydCB0ZXJtIHdl4oCZ cmUgc2hpcHBpbmcgdXNlb2ZycGxpbmZvIGFuZCBSVUwgd2l0aCB0aGUgbG93IGhhbmdpbmcgZnJ1 aXQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1z b25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlByb3MgYW5kIGNvbnMgSSBndWVzcy4gV2Ugd2VudCBmb3IgdGhlIHNpbXBs ZSBhbmQgYmFja3dhcmQgY29tcGF0aWJsZSB3YXkuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltSSl0gWWVzLCBCYWNrd2Fy ZCBjb21wYXRpYmlsaXR5IG1heSBiZSBhbiBpc3N1ZSBiZWNhdXNlIGludGVybWVkaWF0ZSA2TFJz IG9wZXJhdGluZyBpbiBwdXJlIHN0b3JpbmcgbW9kZSB3aWxsIHRyeSB0byBjYWNoZSB0aGUgZXh0 ZXJuYWwgdGFyZ2V0IGFuZCBtYXkgbm90IGJlIGFibGUgdG8gZG8gSVAtaW4tSVANCiBhdCB0aGVp ciBwb2ludC4gSG93ZXZlciwgaGFuZGxpbmcgdGhpcyBjb21wYXRpYmlsaXR5IG1heSBub3QgYmUg YSBiaWcgY2hhbGxlbmdlLiBUaGUgZmxleGliaWxpdHkgdGhpcyBwcm92aWRlcyBpcyB2ZXJ5IGNv bXBlbGxpbmcgdG8gbWUuIFdpdGggREFPIHByb2plY3Rpb24sIHdlIGhhdmUgYWxyZWFkeSBlbnRl cmVkIHRoYXQgem9uZSB3aGVyZSB0aGUgbm9kZXMgY291bGQgYmUgaHlicmlkIGluIG5hdHVyZS48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UFQyJmd0OyB3aXRoIHRoZSBjYXBhYmlsaXR5IHdvcmsgd2XigJlsbCBiZSBhYmxl IHRvIGludHJvZHVjZSB0aGlzIGFuZCBtb3JlIDogKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4eG1zb25vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlRha2UgY2FyZSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Inh4eG1zb25vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0ieHh4bXNvbm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4NCjxociBzaXplPSIxIiB3aWR0aD0iOTglIiBhbGln bj0iY2VudGVyIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGlkPSJ4X3hfeF9kaXZScGx5 RndkTXNnIj4NCjxwIGNsYXNzPSJ4eHhtc29ub3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGNvbG9y PSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2s7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBj b2xvcj0iYmxhY2siPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IFJvbGwgJmx0Ozwvc3Bhbj48 L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZyI+cm9sbC1ib3VuY2Vz QGlldGYub3JnPC9hPjxmb250IGNvbG9yPSJibGFjayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mZ3Q7DQogb24gYmVoYWxmIG9mIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0Ozwvc3Bh bj48L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0PTQwY2lzY28uLmNvbUBkbWFyYy5pZXRm Lm9yZyI+cHRodWJlcnQ9NDBjaXNjby4uY29tQGRtYXJjLmlldGYub3JnPC9hPjxmb250IGNvbG9y PSJibGFjayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gMTIgTWFyY2ggMjAyMCAwNzoz OCBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9i PiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7PC9zcGFuPjwv Zm9udD48YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT48Zm9u dCBjb2xvcj0iYmxhY2siPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtSb2xsXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1s ZWF2ZXMtMTAudHh0PC9zcGFuPjwvZm9udD4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJ4eHhtc29ub3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inh4eG1zb25vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkRlYXIgYWxsPGJyPg0KPGJyPg0KQXMgZGlzY3Vzc2VkIHdpdGggdGhlIElPVCBESVIsIHRo aXMgZHJhZnQgaXMgbm90IHRoZSBnYXRpbmcgZmFjdG9yIGZvciBhbGwgY2x1c3RlciBDMzEwLjxi cj4NCkluIG9yZGVyIHRvIHByb2dyZXNzIEkgbWFkZSBhIGZ1bGwgcGFzcyBvbiBpdCBhbmQgZml4 ZWQgYSBmZXcgYnVncyBhbmQgbWlzYWxpZ25tZW50cyB3aXRoIHVzZW9mcnBsaW5mby48YnI+DQo8 YnI+DQpJIGJlbGlldmUgdGhlIGRvYyBpcyByaXBlIGZvciBXR0xDLjxicj4NCjxicj4NCk1hbnkg dGhhbmtzPGJyPg0KPGJyPg0KUGFzY2FsPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJy Pg0KU2VudDogamV1ZGkgMTIgbWFycyAyMDIwIDE1OjA0PGJyPg0KVG86IE1pY2hhZWwgUmljaGFy ZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiPm1jciYj NDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OzsgTWljaGFlbCBDLiBSaWNoYXJkc29uICZsdDs8 YSBocmVmPSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSI+bWNyJiM0MztpZXRmQHNh bmRlbG1hbi5jYTwvYT4mZ3Q7OyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVm PSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0Ozxi cj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xs LXVuYXdhcmUtbGVhdmVzLTEwLnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0PGJyPg0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1yb2xsLXVu YXdhcmUtbGVhdmVzPGJyPg0KUmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDEwPGJyPg0KVGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvdXRpbmcgZm9yIFJQTCBMZWF2ZXM8YnI+DQpEb2N1bWVudCBk YXRlOiZuYnNwOyAyMDIwLTAzLTEyPGJyPg0KR3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvbGw8YnI+DQpQYWdlczombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzI8YnI+DQpVUkw6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0Ij4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTAudHh0 PC9hPjxicj4NClN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMvPC9hPjxicj4NCkh0bWxpemVkOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYuLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlcy0xMCI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTEw PC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt cm9sbC11bmF3YXJlLWxlYXZlcyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZlczwvYT48YnI+DQpEaWZmOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1yb2xsLXVu YXdhcmUtbGVhdmVzLTEwIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMTA8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJy Pg0KJm5ic3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIFJGQzY1NTAgYW5kIFJG Qzg1MDUgdG8gcHJvdmlkZSB1bmljYXN0IGFuZDxicj4NCiZuYnNwOyZuYnNwOyBtdWx0aWNhc3Qg cm91dGluZyBzZXJ2aWNlcyBpbiBhIFJQTCBkb21haW4gdG8gNkxOcyB0aGF0IGFyZSBwbGFpbjxi cj4NCiZuYnNwOyZuYnNwOyBIb3N0cyBhbmQgZG8gbm90IHBhcnRpY2lwYXRlIHRvIFJQTCwgYW5k IGVuYWJsZXMgdGhlIFJQTCBSb290IHRvPGJyPg0KJm5ic3A7Jm5ic3A7IHByb3h5IHRoZSBFREFS L0VEQUMgZmxvdyBvbiBiZWhhbGYgb2YgdGhlIFJVTHMgYW5kIFJBTnMgaW4gaXRzIERPREFHLjxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGJyPg0KPGJyPg0KPGJy Pg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4NCjxicj4NClRoZSBJRVRGIFNl Y3JldGFyaWF0PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_MN2PR11MB3565CC15E506F4692CABC524D8B60MN2PR11MB3565namp_-- From nobody Wed May 20 19:07:49 2020 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 99A763A0864 for ; Wed, 20 May 2020 19:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 en_eCIPbadx8 for ; Wed, 20 May 2020 19:07:42 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254032.outbound.protection.outlook.com [40.92.254.32]) (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 618023A077E for ; Wed, 20 May 2020 19:07:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VSH+H9DqexiAhyAuwt/0WmWsBNwd5khlC8Q4b5j3JVOgbOa1hIENSqM4L/kY2/OlyGx/GYcC9b78UysnbgO12i+6bC1xs4qnHOXslhvsgDqF3l+tSMSQQ8SjIOXrzIuyqyiUx4iJa96SO75UPVRB7Cf+BIiJV97RqGr1svx+cPeHB7FOX0gjZabuBarUY4Wxf4ckAvgmdzFatqhQD4wN/9b++dnugMmrSRVRPk+1vGMmfcJ62isKU3+DejcupI6Ql8MBYrOskWFodbWayYIoqR2DZmfC7/GlGidL9Bo6XqTGpEH88BCk/TOj49Kp1YSfgBOk20FzLfAerr9Wq21JNg== 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=vARmzApXkv0pf5yjn9gKfSPBBSgVHZ47VmOBJVE37UE=; b=ftHGmkb7SpGbB0oV21msPV4U9qg2N63r640VHOiFi/h7EYnP9KTpwoZjlnFjlH1NTOG8THaJG4DYacjDR0dZrYOPadEHH03L8w5j1c9buD4nmvRDIl11nzC3l52g8MOe3SkYJwp6bvsZwLh/m39WenyyMhQfYjmYIfQM1nCDoH0wCt5oK/JKceeusiTlAfAJvsUA0Nz5n+quKKs2xpBAceLm8QaaJnAK63rPKfTG/bAWAzHTZfF/uZg+KfbJbA495tHatNb92Emuij0pet2kzTv/rT1g7/iE3iQdZ6Vih4fV25mgN6CW5WFwZbK8jvJTD1M0NfZwJDsTYH9RVnbkGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vARmzApXkv0pf5yjn9gKfSPBBSgVHZ47VmOBJVE37UE=; b=albs5lW653v+3gsSYiRaO7OZYk0JlMkpGpOA94rosH3MrG5m86ey2uv92xQkPGBobffYvp3R0DzLaEks10GL7+spRUeL3b7oq9Vi3b8APL8kMirHDXigwqeuPBUlRRg3XRY4zpKtT66VhOFimTeVxknLSnBvw/dJXcXvTK+wDCN31Lgz+iAPJQJ4msUMEAUL/147SZUKApJxRJfC49i3hWx+C9Lgo5sUfrEpHX+gVbT7jtD4DvvYjZ581frfZkqCcT+syZEaRoy8lGJfsNjkadthLO8sZCo5dO4KEOFv/9YxwxXEq2EB3jRfpLCrE8vnfqiOWQWJCSMkoR6Q9vDEYg== Received: from PU1APC01FT043.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::47) by PU1APC01HT239.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::504) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Thu, 21 May 2020 02:07:37 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.57) by PU1APC01FT043.mail.protection.outlook.com (10.152.253.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Thu, 21 May 2020 02:07:37 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3021.020; Thu, 21 May 2020 02:07:37 +0000 From: Rahul Jadhav To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks , rabi narayan sahoo Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt Thread-Index: AQHV+Hcezq3im2uH30CiF/oY8K2vzahE/ZyggAAFM7yAAAXZkIAABcnzgAAN4ICAZtA3qYACMJ2wgAAIIK6AAzrx8IAA1gLD Date: Thu, 21 May 2020 02:07:37 +0000 Message-ID: References: <158402183564.18056.13091739917212256438@ietfa.amsl.com>, , , , , In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:46AA08E6EA1EE58D153A95CB045FB3D9804E87315635C0A8BC298D89FB4F983B; UpperCasedChecksum:3DF35F13EC045DC08D643DDABB9EF37BF9D2B7E49F4DF584E4C49F38ED90AC50; SizeAsReceived:7820; Count:44 x-tmn: [8foQ3fRl9nc+6TXehb6xEgd2wOBJfPTl] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 5963558a-7b43-4dcc-4150-08d7fd2bbc11 x-ms-traffictypediagnostic: PU1APC01HT239: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yskO6dHtWw8KSvG5rvaMMmaGBTxZobbOW02qxt1ab47tBF3Ne1vHJQjZVTUeZKnBEeUeoHJhR/H6MsbqWtuj7ztQ9B1+L5gtcltbpue9etQBAdTmGNMncGEHlwS0ATI6HWSK468r7nKQmDSYtGvrMLv2O+5uIm8gpEyy7nPmVuDNh5N3pCb/MXZVCZZ5AMQqO9QLg+lJx2Sc62sFhrfzRvbw0FvZz2Xch+TlG41GfVKaUzdGRSs7r32qhGV05AIB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: zJgC4fBjxNh8lFf0BPMqJ5Ra8frYb3ekqWSdh1adNrDdgv678uqnRJHpFjsSGlCDXpKqu6Am3Fzpjntp1h5kUnxBm8w5SNzwiVXeAJZTW6rEtqqJvIGIkEE1hF4nH+i6Iy1MfxCuAcDNVlZSa/VdfA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020EB3F03EBEB9CA376B9F9A9B70BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 5963558a-7b43-4dcc-4150-08d7fd2bbc11 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2020 02:07:37.6373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT239 Archived-At: Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.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: Thu, 21 May 2020 02:07:46 -0000 --_000_BM1PR01MB4020EB3F03EBEB9CA376B9F9A9B70BM1PR01MB4020INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, the storing-root-ack can clarify the change in flow for NA(EARO) for R= ULs. Have raised an issue to follow-up on this: https://github.com/nyrahul/roll-root-ack/issues/1 Thanks, Rahul ________________________________ From: Pascal Thubert (pthubert) Sent: 20 May 2020 09:16 PM To: Rahul Jadhav ; Routing Over Low power and Lossy ne= tworks ; rabi narayan sahoo Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hello Rahul A very interesting comment. Yes, the 6LR is expected to do what=92s necessary to best serve the RPL una= ware leaf. The RUL is not aware of RPL so it cannot know whether the 6LR is doing stor= ing-root-ack or even talking RPL at all for that matter. What makes sense is that on the first registration, the 6LR (optionally) wa= its for the storing-root-ack before it sends the NA(EARO) back. This change= of the flow would be indicated in your storing-root-ack draft. Does that work? Pascal From: Rahul Jadhav Sent: lundi 18 mai 2020 14:03 To: Pascal Thubert (pthubert) ; Routing Over Low power = and Lossy networks ; rabi narayan sahoo Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt So even in storing MOP a 6LN/6LR should use non-storing MOP signaling to se= nd the external routes to the root. I guess this is what is done in unaware= -leaves as well. This does answer my question. Many Thanks. For storing-root-ack, Rabi pointed out a case where the 6LN/6LR sends DAO o= n behalf of the unware-RPL node and we were wondering if we could make use = of parent address in storing MOP to signal the root about this external nod= e. I guess even in that case we can refer to unaware-leaves/useofrplinfo ra= tionale and send DAO for external targets directly to the root to keep the = handling consistent (and minimal changes). Thanks, Rahul ________________________________ From: Pascal Thubert (pthubert) > Sent: 18 May 2020 07:30 PM To: Rahul Jadhav >; Routing= Over Low power and Lossy networks >; r= abi narayan sahoo > Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hello Rahul: The short answer is that because we introduce non-storing signaling at the = edge of a storing mode DODAG. You may see it as an extension outside of the RPL domain that is covered by= the rule you pointed out. See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38#section-4.1 =93 This specification updates [RFC6550= ] to RECOMMEND that external targets are advertised using Non-Storing Mode DAO messaging even in a Storing-Mode network. =93 Is that your answer? Take care, Pascal From: Rahul Jadhav > Sent: dimanche 17 mai 2020 04:23 To: Pascal Thubert (pthubert) >; Routing Over Low power and Lossy networks >; rabi narayan sahoo > Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hi Pascal, Revisiting this thread because of some new light [1]. Question is, Can an RPL node in Storing MOP send a DAO with Transit Info Op= tion with Parent Address subfield? Previously, you pointed out RFC6550 section 9.8 which clearly mentions that= "Parent Address in Storing MOP MUST be empty". However, as per Section 9.4, the RFC says, "In order to inject such a (exte= rnal) Target in the RPL network, the router MUST advertise itself as the DO= DAG Parent Address subfield in the Transit..." Essentially Section 9.4 contradicts 9.8 both using MUST clauses. Just for the record, this discussion does not have any impact on the unawar= e-leaves draft. Best, Rahul [1] new light: Rabi actually informed me about section 9.8 in context to an= other offline discussion wrt Storing-Root-Ack. ________________________________ From: Pascal Thubert (pthubert) > Sent: 13 March 2020 12:49 AM To: Rahul Jadhav >; Routing= Over Low power and Lossy networks > Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Hello Rahul RFC 6550 says: =93 9.8. Storing Mode In Storing mode, RPL routes messages Downward by the IPv6 destination address. The following rules apply to nodes that are in Storing mode: 1. The DODAG Parent Address subfield of a Transmit Information option MUST be empty. =93 So even if it is a good idea it requires new specs to override RFC 6550. More below (using P2>) From: Rahul Jadhav > Sent: jeudi 12 mars 2020 16:32 To: Pascal Thubert (pthubert) >; Routing Over Low power and Lossy networks > Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10= .txt Please find below inline answers. Also, I did not get any objection from 6l= o so I added a IANA section that reduces the EARO status range to 0-63, whi= ch solves the issue you raised. [RJ] Yep, that indeed takes care of a major point ??. Please find my [RJ] r= esponses inline. Regarding this statement, "Non-Storing Mode DAO messages are used to signal external routes to the Root, even if the DODAG is operated in Storing Mode." I couldn't find any text which provides reasoning to do so. Why non-storing= mode DAO is needed and why storing mode DAO won't work? Pascal> We need the address of the 6LR to terminate the tunnel and remove t= he artifacts, and the NS signaling will give us that. This is how we remove= d the hassle of hop by hop link local tunnels that was in the old useofrpli= nfo. There is this text which says, "The Non-Storing Mode DAO messaging enables = to advertise the 6LR that serves the RUL and injects the route to the Root.= " This can be achieved even with storing mode DAO with the target as RUL ad= dress and transit information containing parent address as anchor 6LR addre= ss. Pascal > Which is not the normal storing mode signaling. [RJ] Yes, but 6550 does not stop us from doing it. Interestingly, I have a = use-case in my deployment wherein I need to send this parent address info e= ven in storing MOP. It helps the root get the complete network graph even i= n storing mode for visualization purposes (if the admin wants to check how = the network is formed, how many hops etc on the root in storing mode). P2> It does actually, see above It would be an hybrid. The cool thing with NS is that the external prefixes= are not visible inside the RPL domain. Legacy nodes do not have to know th= ey exist. Only the 6LR at the border that inject the external routes and th= e Root are aware and need to know about the new signaling. Using an hybrid = impacts every node. [RJ] The hybrid may not necessarily impact every node. An intermediate 6LR = may decide to ignore that external target in the DAO and that would still b= e ok. In this case, the signaling will work through next common ancestor wh= ich has to capability to hold/process that kind of info. P2> which is still an impact; new code to recognize the =91E=92 flag and de= cide to ignore the address. A legacy node would not do the right thing. Trying to understand the reason because this mode of signaling has implicat= ions (already covered in the draft), particularly that, when the DAG is ope= rating in storing mode, the communication to RUL from other RANs would mand= atorily have to be routed through root only. If we use storing mode DAO the= n this could be optimized. Not sure if I am missing anything? Pascal > Well, yes, we could have done that as well. The path could be opti= mized but * it would mean that the common parent has to encapsulate to the 6LR, whic= h is an additional function there * It would also mean that the network has ot be aware of external routes, w= hich may be too many for the SM tables. [RJ] I am just keen on doing this because it makes things flexible. Anchor = 6LR has both options of sending NS-DAO or storing DAO. Intermediate 6LRs al= so have both options, honor the external target info or ignore it and just = pass it on. P2> I=92m happy to discuss it and see if and how we open RPL in that direct= ion. But for short term we=92re shipping useofrplinfo and RUL with the low = hanging fruit. Pros and cons I guess. We went for the simple and backward compatible way. [RJ] Yes, Backward compatibility may be an issue because intermediate 6LRs = operating in pure storing mode will try to cache the external target and ma= y not be able to do IP-in-IP at their point. However, handling this compati= bility may not be a big challenge. The flexibility this provides is very co= mpelling to me. With DAO projection, we have already entered that zone wher= e the nodes could be hybrid in nature. PT2> with the capability work we=92ll be able to introduce this and more : = ) Take care, Pascal ________________________________ From: Roll > on behalf = of Pascal Thubert (pthubert) > Sent: 12 March 2020 07:38 PM To: Routing Over Low power and Lossy networks > Subject: [Roll] FW: New Version Notification for draft-ietf-roll-unaware-le= aves-10.txt Dear all As discussed with the IOT DIR, this draft is not the gating factor for all = cluster C310. In order to progress I made a full pass on it and fixed a few bugs and misa= lignments with useofrplinfo. I believe the doc is ripe for WGLC. Many thanks Pascal -----Original Message----- From: internet-drafts@ietf.org > Sent: jeudi 12 mars 2020 15:04 To: Michael Richardson = >; Michael C. Richardson >; Pascal Thubert (pthubert) > Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-ietf-roll-unaware-leaves Revision: 10 Title: Routing for RPL Leaves Document date: 2020-03-12 Group: roll Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-ietf-roll-unawar= e-leaves-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-le= aves/ Htmlized: https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-= 10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-roll-unawa= re-leaves Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware= -leaves-10 Abstract: This specification extends RFC6550 and RFC8505 to provide unicast and multicast routing services in a RPL domain to 6LNs that are plain Hosts and do not participate to RPL, and enables the RPL Root to proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_BM1PR01MB4020EB3F03EBEB9CA376B9F9A9B70BM1PR01MB4020INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes, the storing-root-ack can clarify the change in flow for NA(EARO) for R= ULs.
Have raised an issue to follow-up on this:

Thanks,
Rahul
From: Pascal Thubert (pthub= ert) <pthubert@cisco.com>
Sent: 20 May 2020 09:16 PM
To: Rahul Jadhav <nyrahul@outlook.com>; Routing Over Low power= and Lossy networks <roll@ietf.org>; rabi narayan sahoo <rabinaray= ans0828@gmail.com>
Subject: RE: New Version Notification for draft-ietf-roll-unaware-le= aves-10.txt
 

Hello Rahul

 

A very interesting comment.

 

Yes, the 6LR is expected to do what=92s necessary to best = serve the RPL unaware leaf.

 

The RUL is not aware of RPL so it cannot know whether the = 6LR is doing storing-root-ack or even talking RPL at all for that matter.

 

What makes sense is that on the first registration, the 6L= R (optionally) waits for the storing-root-ack before it sends the NA(EARO) = back. This change of the flow would be indicated in your storing-root-ack= draft.

 

Does that work?

 

Pascal

 

 

From: Rahul Jadha= v <nyrahul@outlook.com>
Sent: lundi 18 mai 2020 14:0= 3
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; Routing Over Low power and Lossy networks <= ;roll@ietf.org>; rabi narayan sahoo <rabinarayans0828@gmail.com> Subject: Re: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

= So even in storing MOP a 6LN/= 6LR should use non-storing MOP signaling to send the external routes to the= root. I guess this is what is done in unaware-leaves as well.

=  

= This does a= nswer my question. Many Thanks.

=  

= For storing= -root-ack, Rabi pointed out a case where the 6LN/6LR sends DAO on behalf of= the unware-RPL node and we were wondering if we could make use of parent address in storing MOP to signal the root a= bout this external node. I guess even in that case we can refer to unaware-= leaves/useofrplinfo rationale and send DAO for external targets directly to= the root to keep the handling consistent (and minimal changes).

=  

= Thanks,

= Rahul

From: Pascal Th= ubert (pthubert) <pthubert@cisco.c= om>
Sent: 18 May 2020 07:30 PM To: Rahul Jadhav <nyrahul@outlook.com>; Routing Over L= ow power and Lossy networks <roll@ietf.= org>; rabi narayan sahoo <rabinarayans0828@gmail.com>
Subject: RE: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

Hello Rahul:

 

The short answer is that because we introduce non-storing= signaling at the edge of a storing mode DODAG.

You may see it as an extension outside of the RPL domain = that is covered by the rule you pointed out.

See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38#section-4.1=

=93

   Thi= s specification updates [RFC6550] to RECOMMEND that external

   tar= gets are advertised using Non-Storing Mode DAO messaging even in a

   Sto= ring-Mode network.

 

=93

Is that your answer?

 

Take care,

 

Pascal

 

From: Rahul Jadha= v <nyrahul@outlook.com>
Sent: dimanche 17 mai 2020 0= 4:23
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; Rou= ting Over Low power and Lossy networks <roll@ietf.org>; rabi narayan sahoo <rabinarayans0828@gmail.com>
Subject: Re: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

Hi Pascal,

 

Revisiting this thread becau= se of some new light [1].

 

Question is, Can an RPL node= in Storing MOP send a DAO with Transit Info Option with Parent Address sub= field?

 

Previously, you pointed out = RFC6550 section 9.8 which clearly mentions that "Parent Address in Sto= ring MOP MUST be empty". 

 

However, as per Section 9.4,= the RFC says, "In order to inject such a (external) Target in the RPL= network, the router MUST advertise itself as the DODAG Parent Address subfield in the Transit..."

 

Essentially Section 9.4 cont= radicts 9.8 both using MUST clauses.

 

Just for the record, this di= scussion does not have any impact on the unaware-leaves draft.

 

Best,

Rahul

 

[1] new light: Rabi actually= informed me about section 9.8 in context to another offline discussion wrt= Storing-Root-Ack.

From: Pascal T= hubert (pthubert) <pthubert@cisco.= com>
Sent: 13 March 2020 12:49 AM=
To: Rahul Jadhav <nyrahul@outlook.com>; Routing Over L= ow power and Lossy networks <roll@ietf.= org>
Subject: RE: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

Hello Rahul

 

RFC 6550 says:

 

=93

 

9.8= .  Storing Mode

 

 

   In= Storing mode, RPL routes messages Downward by the IPv6 destination<= /font>

   ad= dress.  The following rules apply to nodes that are in Storing<= /font>

   mo= de:

 

   1.=   The DODAG Parent Address subfield of a Transmit Information

  &nb= sp;    option MUST be empty.

 

 

=93

 

So even if it is a good idea it requires new specs to ov= erride RFC 6550.

 

More below (using P2>)

 

 

From: Rahul Jadha= v <nyrahul@outlook.com>
Sent: jeudi 12 mars 2020 16:= 32
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; Rou= ting Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: New Version Not= ification for draft-ietf-roll-unaware-leaves-10.txt

 

 

 

 

Please find below inline answers. Also, I did not get any objection from= 6lo so I added a IANA section that reduces the EARO status range to 0-63, which solves the issue you raised.

 

[RJ] Yep, that indeed takes care of a major point 😊. Please find my [RJ] responses inline.

 

 

 

Regarding this statement,<= /span>

"Non-Storing Mode DAO= messages are used to signal external routes to
   the Root, even if the DODAG is operated in Storing Mode."=

 

I couldn't find any text w= hich provides reasoning to do so. Why non-storing mode DAO is needed and wh= y storing mode DAO won't work?

 

Pascal> We need the address of the 6LR to terminat= e the tunnel and remove the artifacts, and the NS signaling will give us th= at. This is how we removed the hassle of hop by hop link local tunnels that was in the old useofrplinfo.<= /p>

 

There is this text which s= ays, "The Non-Storing Mode DAO messaging enables to advertise the 6LR = that serves the RUL and injects the route to the Root." This can be achieved even with storing mode DAO with the targe= t as RUL address and transit information containing parent address as ancho= r 6LR address.

 

Pascal > Which is not the normal storing mode sign= aling. 

 

[RJ] Yes, but 6550 does not stop us from doing it. In= terestingly, I have a use-case in my deployment wherein I need to send this= parent address info even in storing MOP. It helps the root get the complete network graph even in storing mode for = visualization purposes (if the admin wants to check how the network is form= ed, how many hops etc on the root in storing mode).

 

P2> It does actually, see above

 

It would be an hybrid. The cool thing with NS is that= the external prefixes are not visible inside the RPL domain. Legacy nodes = do not have to know they exist. Only the 6LR at the border that inject the external routes and the Root are aware and n= eed to know about the new signaling. Using an hybrid impacts every node.

 

[RJ] The hybrid may not necessarily impact every node= . An intermediate 6LR may decide to ignore that external target in the DAO = and that would still be ok. In this case, the signaling will work through next common ancestor which has to capabili= ty to hold/process that kind of info. 

 

P2> which is still an impact; new code to recogniz= e the =91E=92 flag and decide to ignore the address. A legacy node would no= t do the right thing.

 

Trying to understand the r= eason because this mode of signaling has implications (already covered in t= he draft), particularly that, when the DAG is operating in storing mode, the communication to RUL from other RANs wou= ld mandatorily have to be routed through root only. If we use storing mode = DAO then this could be optimized. Not sure if I am missing anything?=

 

Pascal > Well, yes, we could have done that as wel= l. The path could be optimized but

*  it would mean that the common parent has to e= ncapsulate to the 6LR, which is an additional function there<= /p>

* It would also mean that the network has ot be aware= of external routes, which may be too many for the SM tables.=

 

[RJ] I am just keen on doing this because it makes th= ings flexible. Anchor 6LR has both options of sending NS-DAO or storing DAO= . Intermediate 6LRs also have both options, honor the external target info or ignore it and just pass it on.

 

P2> I=92m happy to discuss it and see if and how w= e open RPL in that direction. But for short term we=92re shipping useofrpli= nfo and RUL with the low hanging fruit.

 

Pros and cons I guess. We went for the simple and bac= kward compatible way.

 

[RJ] Yes, Backward compatibility may be an issue beca= use intermediate 6LRs operating in pure storing mode will try to cache the = external target and may not be able to do IP-in-IP at their point. However, handling this compatibility may not be a= big challenge. The flexibility this provides is very compelling to me. Wit= h DAO projection, we have already entered that zone where the nodes could b= e hybrid in nature.

 

PT2> with the capability work we=92ll be able to i= ntroduce this and more : )

 

 

Take care,

 

Pascal

From:= Roll &= lt;roll-bounces@ietf= .org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco..com@dmarc.ietf= .org>
Sent: 12 March 2020 07:38 PM=
To: Routing Over Low power a= nd Lossy networks <roll@i= etf.org>
Subject: [Roll] FW: New Vers= ion Notification for draft-ietf-roll-unaware-leaves-10.txt

 

Dear all

As discussed with the IOT DIR, this draft is not the gating factor for all = cluster C310.
In order to progress I made a full pass on it and fixed a few bugs and misa= lignments with useofrplinfo.

I believe the doc is ripe for WGLC.

Many thanks

Pascal

-----Original Message-----
From: internet-drafts@ietf.org<= /a> <internet-drafts@ietf.or= g>
Sent: jeudi 12 mars 2020 15:04
To: Michael Richardson <mcr= +ietf@sandelman.ca>; Michael C. Richardson <mcr+ietf@sandelman.ca>; Pascal Thube= rt (pthubert) <pthubert@cisco.com<= /a>>
Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt=


A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt
has been successfully submitted by Pascal Thubert and posted to the IETF re= pository.

Name:           draft-iet= f-roll-unaware-leaves
Revision:       10
Title:          Routing for RP= L Leaves
Document date:  2020-03-12
Group:          roll
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-unaware-leaves-10.txt<= /a>
Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-10
Abstract:
   This specification extends RFC6550 and RFC8505 to provide unic= ast and
   multicast routing services in a RPL domain to 6LNs that are pl= ain
   Hosts and do not participate to RPL, and enables the RPL Root = to
   proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its= DODAG.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--_000_BM1PR01MB4020EB3F03EBEB9CA376B9F9A9B70BM1PR01MB4020INDP_-- From nobody Wed May 20 23:24:13 2020 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 25EE93A0404 for ; Wed, 20 May 2020 23:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 dDeweKvR88FT for ; Wed, 20 May 2020 23:24:11 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254060.outbound.protection.outlook.com [40.92.254.60]) (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 C4C003A0400 for ; Wed, 20 May 2020 23:24:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=alYuJ3s1n5GIO4xH9El+WgQLxdBQGtO/o243PLLLD3ZjS+t+sDPjKEhw5M++juuYLJr+2XRm5TaJ5Np1GpVaA8Top+wyK4d7wURuyq7GMNLOVOWQkkZ9u6uAIcvcjB3xd7hie+Ex7N01AVU2NHeO8iVxXGnhGX5oaLFeanUHilI81flIjWDuAOMeaW/c3cjYn1QhhFT9S2HeLCVTuYNxW/bTxRYDxc2T91W4XboZVR9S70CMGPxM+FDH+G/FHuePWadC6WOb5ZLwvdHf6o/TNzq4S/YoqJ/BJI9J6hZ8EEJ53tdLyl4kdSRosU9Y3sT+JTHKpPbQP7LjS5du1ApuDg== 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=Q7euSnvBvgQJ+BkWdM+vlVYRncf2eDnK6GBUBBL/m/I=; b=OBBubwjpVjlpS9n4yyMkXBRsgrqet1sh280vsAkZ+5p1DtBxQwSih7NVcbzATGfBVuaP3S2GNVW+SUJje6XrLJgyqQ9sB4Jii39TmCpAVro6huS289viacrDxAl3SEoDBEyL9pqwmGg30OOgId+6Fp35JViF344HTqo7oyC9QykeJcj9fSiapT6GccTpHHuJdINGQbfYLVKvftq2TjRrmoG+selFqvu6NPB9USDfP2trmS/zkaerf248I53bSJZXpUTARaEr+f2hxvsh3AQ70QMsXeytMJcpWKiUAo1BMFpGUFyMBEfsb4KnHASODp5+vfqBnkOXyT+yX14EAZOgXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7euSnvBvgQJ+BkWdM+vlVYRncf2eDnK6GBUBBL/m/I=; b=bzNf4o9p31PzhqoRBUT3suqgs/2+c3j8Kp1Hl8FFFsivMpJT+Mb0/MFdUw4CxKskNqBtr2STaYnsN8xQq6ayeN2nRkBAaJfVMUih//VQHoGFtIpCuauikwe0KQNhnihIxspGmX4y43Cve9MjT6jUzni6M1rZ2twS+pstihyvokL4Tv42qEvu9WXXMQ5gJYiSoUZ51CNdrKQHxntjQxmQSL40x16f5OhALQ0zMkzBM+UT0HjFgOLyOoEd9yWrKMxGru7mpSIrHGL63DqZFRlYmGXEJveMTBuSlGQeF6/ax15zf2AFIOZKryiZ8utb1cKNYNQAogPMFqccQUkga3DENA== Received: from PU1APC01FT042.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::44) by PU1APC01HT212.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Thu, 21 May 2020 06:24:08 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.51) by PU1APC01FT042.mail.protection.outlook.com (10.152.253.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Thu, 21 May 2020 06:24:08 +0000 Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3021.020; Thu, 21 May 2020 06:24:08 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: term for async msg - storing-rootack Thread-Index: AQHWLzY9XhGoqjVWd0eZK9P4fmVklQ== Date: Thu, 21 May 2020 06:24:08 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:8095D0834B094EBBC613A7DD81DEE1507AC01B95A87A03D783B93DDD1062819A; UpperCasedChecksum:A55683D095F46049BAE680EB2E6E95DDDBD4C7E2760B684837A51B4AD948C73D; SizeAsReceived:6667; Count:42 x-tmn: [HCxGS3a+5L/qVRctl/Czfc4gl+OOEPRV] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: b1a15c33-aa49-4588-3235-08d7fd4f919b x-ms-traffictypediagnostic: PU1APC01HT212: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7qZvfmtknuFZ4mNEEokcSHnrkvfchVrmMjmcvxVeKwj4V6TSUZt1T/1BROvy6MUOLpQTXX/PLJJykUHnxHDfLrD8x/gJS0eqka69P4ASOEDZLDlO8nV8w58W/Bp5pfh2jhcCIFz+kMAwYjmLAa/pxhav5hJqjxfaT6HLfTSA5uat6ZyrQRCsTJl/kZZOi5fU6K3uX9auLuIJpjYNf3UgzQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: xJ1upAGr8uQVWDZuT+S+n4iVOSoSjAOsQmSf7RF/RP9iJgWa+ibjNMgMObspQzz7rsWdEBArBvIB+kWi7vCaMJ13D2m5uveymLDAtxYqLHE5NLThdYVuUSP3AUgCh64IXp06GMr4UQMvi7+rRYppvw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB40204DF7ED2661CDB4C4B267A9B70BM1PR01MB4020INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: b1a15c33-aa49-4588-3235-08d7fd4f919b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2020 06:24:08.2805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT212 Archived-At: Subject: [Roll] term for async msg - storing-rootack 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, 21 May 2020 06:24:12 -0000 --_000_BM1PR01MB40204DF7ED2661CDB4C4B267A9B70BM1PR01MB4020INDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, This is about using an appropriate name/term for the message sent from root= to the node. The draft targets this msg as an indication for e2e path esta= blishment for the node. However, this primitive will be useful for capabili= ty query/indication. In storing MOP this will be the only message which is = directly addressed to the node from the root. Currently, the draft calls it DAO-ACK and is not a good term. Another term that is suggested is RootACK. Shall we call it an ACK at all? RPL-Ping is another term. Suggestions are welcome. Hoping to use the term finalized here in the inter= im slides. Thanks, Rahul --_000_BM1PR01MB40204DF7ED2661CDB4C4B267A9B70BM1PR01MB4020INDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,

This is about using an appropriate name/term for the message sent from root= to the node. The draft targets this msg as an indication for e2e path esta= blishment for the node. However, this primitive will be useful for capabili= ty query/indication. In storing MOP this will be the only message which is directly addressed to the node = from the root.

Currently, the draft calls it DAO-ACK and is not a good term.
Another term that is suggested is RootACK. Shall we call it an ACK at all?<= /div>
RPL-Ping is another term.

Suggestions are welcome. Hoping to use the term finalized here in the inter= im slides.

Thanks,
Rahul
--_000_BM1PR01MB40204DF7ED2661CDB4C4B267A9B70BM1PR01MB4020INDP_-- From nobody Thu May 21 02:04:37 2020 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 7E2823A0B11; Thu, 21 May 2020 02:04:17 -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.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <159005185745.21705.3273280642815991728@ietfa.amsl.com> Date: Thu, 21 May 2020 02:04:17 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-rpl-observations-04.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: Thu, 21 May 2020 09:04:18 -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 : RPL Observations Authors : Rahul Arvind Jadhav Rabi Narayan Sahoo Yuefeng Wu Filename : draft-ietf-roll-rpl-observations-04.txt Pages : 20 Date : 2020-05-21 Abstract: This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04 https://datatracker.ietf.org/doc/html/draft-ietf-roll-rpl-observations-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-rpl-observations-04 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 Thu May 21 02:54:56 2020 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 06E1E3A0B78; Thu, 21 May 2020 02:54:54 -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.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <159005489396.7108.14555927762638325057@ietfa.amsl.com> Date: Thu, 21 May 2020 02:54:54 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-05.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: Thu, 21 May 2020 09:54:54 -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 : RPL Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Rabi Narayan Sahoo Filename : draft-ietf-roll-capabilities-05.txt Pages : 12 Date : 2020-05-21 Abstract: This draft enables the discovery, advertisement and query of capabilities for RPL nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-capabilities-05 https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-capabilities-05 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 Thu May 21 22:30:42 2020 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 E80423A0EBD for ; Thu, 21 May 2020 22:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=alMcYn+z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UPuv5cgK 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 RU7PiGnrt2Rk for ; Thu, 21 May 2020 22:30:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7283A0EBA for ; Thu, 21 May 2020 22:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6323; q=dns/txt; s=iport; t=1590125437; x=1591335037; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lhl6BcpHc84iZSc+PS9XAIv1T3UPIIfNahMg77+MtkY=; b=alMcYn+zG5YT82SOau9hSq3B03shelVK9jgJbRzeBLlouU5XB0NQfjo1 DhhEvAIQnCk7isttKqd9jdtWk6lFoCp3Hu6L1Fm4QaEHncMjJt2gaNEhg JIHid6ZMGbdy7hPvYhGC593WewUL0DpB+p4esGvEPqmvNmFgKRuKSZFV6 U=; IronPort-PHdr: =?us-ascii?q?9a23=3AQKvvCRQbMTs8GI67ZGGUJoT6VNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqCAA/Ysde/51dJa1mHgEBCxIMgXw?= =?us-ascii?q?LgSUvIy4Hb1gvLIQkg0YDoRSEZoJSA1ULAQEBDAEBGAEKCgIEAQGERAIXgX8?= =?us-ascii?q?kNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVyAgEDAQEQER0BASwMDwIBCAQ+AgI?= =?us-ascii?q?CJQslAgQTIoJ/BAEBgX5NAy4BDqM8AoE5iGF2gTKDAQEBBYJJgmkYgg4DBoE?= =?us-ascii?q?4gmOCSIcXGoFBP4E4HIIfLj6CZwEBhHkzgi2RZIYkJZp4CoJTmFIdmWuECoU?= =?us-ascii?q?DpRCEEgIEAgQFAg4BAQWBaCMMgUpwFTsqAYI+UBgNkECDcoUUhUJ0NwIGAQc?= =?us-ascii?q?BAQMJfItQAQE?= X-IronPort-AV: E=Sophos;i="5.73,420,1583193600"; d="scan'208,217";a="762187785" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 May 2020 05:30:36 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 04M5UaAI017706 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 May 2020 05:30:36 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 22 May 2020 00:30:36 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 22 May 2020 00:30:35 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 22 May 2020 00:30:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AW6eFO2NaoL1ewCBIvhygiH1+nwlcEi1F2TZG0cPxPa5fOZepkd6/gBwy1Bg4h4jDtnEMnuW4Q8/PwHUSlhlKbGkYh5c4n3/vDPu7lkgT4/cxcyIEGaogWuP4i1aejuO9FAnGBSHgiaHDrGWNFLByltaay0Tm9FpPDjjzo+GzPsLWNcsFoq42DJ4nS7P+V4aQQP2jxdsYX+4IySRDw6tfkGc8apxsCrKtElVGMfewxpd3YC3MGxI9JEbSLizX19X18XgtB/zNmdg1j/Xut6hVClABTnhYvkFP1KZ6t7rBkwhqqAR/OntOmgysyDHjW6U+cf78Ul93AB0qxxG4x8g8A== 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=lhl6BcpHc84iZSc+PS9XAIv1T3UPIIfNahMg77+MtkY=; b=KkhICArbIutQ1nkFrxinyQqhOMTxRFLeRZeCg+MmDb6WfeB9WyCstSC9FQr5jXpRl4Cd3odH1kMlgs8z2DpZMvwFwewSY1rXAAu2cS39DEv2iOU3OgQLVj/8Q1tWTkKeoISejO83LuWmmTSCevqwzl7vLSuLm+lT4dKQRAVPBD/Gz7dTlFI3P/y+bNsCGO8fBch1UrqNn8SHcAtQwDYI3GihDl11mJUTDNHwJ2idJb5f837YHZj/g3f0jMIefROUd0/yuTzdQ/VnQrp+BhqVBC0BZmKZR6aoWyxoy9u6rx27PVqgBpl8BweLsZgJxt9fPv0tD7nTokOsyKqmawEuhQ== 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=lhl6BcpHc84iZSc+PS9XAIv1T3UPIIfNahMg77+MtkY=; b=UPuv5cgKZqL39NOfBDK3IAOD54Qi9Jv6ovSfvcRpCCF65L9JN2/E+MYPrdp6w+GKkxqVbUMp8BsAL0ckZRuYphPwnBo0btbfsakLX6JN9lJUIRSwNPlFgGhFSdW/gfMywSJZKOgkX1t38Gm8ZWS36J1PXoQo7i1fzuxamrXzCkc= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.26; Fri, 22 May 2020 05:30:34 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108%6]) with mapi id 15.20.3021.026; Fri, 22 May 2020 05:30:34 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] term for async msg - storing-rootack Thread-Index: AQHWLzY9XhGoqjVWd0eZK9P4fmVklaizlc9G Date: Fri, 22 May 2020 05:30:34 +0000 Message-ID: <617E9429-BD80-44A2-B2A4-2B8D6A5519EE@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR 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-originating-ip: [2a01:cb1d:4ec:2200:a566:c4dd:414b:ac46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 174e72ca-61a1-470a-e0d6-08d7fe11406b x-ms-traffictypediagnostic: MN2PR11MB3565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04111BAC64 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gwOE6Y3mS8t0bKgOmTMzlgYmn1FbUe4iCLllRa3T4MDucupCi015g2j5e6bN9t0GT4hynThVe5FixRp5YtM9MzL3WGp5Xupx0r+GTMpN7eL0ghoFb1HMUvxkMzg+ANCM9tqa9uinivKlT4Ixt4VBUvlFMaURoUFNFOMV8QF+S52k8NJ9z5I4vGLO7+8kPlfR4/Wj63434Yau9lq+4Y0xO7EuhNbzbAw/CgJIBkbAMNfrZRQc8h75VilFx1m7aC1O8IvRYHFAWAfJC72pziff8UHheT9spcnkzaEw10NgYAWKCJgaaIBZOExEV0ENfxdyEG5Cuv2Z0/7HUnEl392Xpq3tsvKYKEIpm/YifBA4zsGAFKu6TMq31IyYaUg/zwj8YK1Gn4F016AXSbBrVUHav3YGVZgu19o+hkvqVHtlaUss5C8YYPlulCSah8JCgZhxqTB1eDILP+gkoBiZsafxog== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(346002)(396003)(376002)(8676002)(2616005)(2906002)(186003)(66476007)(6916009)(66574014)(76116006)(91956017)(71200400001)(66556008)(66446008)(64756008)(6486002)(66946007)(6506007)(36756003)(316002)(8936002)(5660300002)(966005)(33656002)(6512007)(86362001)(45080400002)(478600001)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: D65pUZw+Wkw3k+BVDgbnrzh+/vZX+linDpQGufePSPAthJiKO3QZ4TbSkfNNPtRzDvIoMTy83caA50hNaxAc+jY4+yP1cUjNd4voqZOCfHyZhMXGxXx4+R+B3tMNsLFm4/3NQPnZvCRTYNtF4Vvq5z98SGeRPbBgH0NwewdrhBbfna8/NbljCzX9b4dTMfBNy+IuMom/gYcsrWYOKKk2qq8wv7lWd89Y7CZWmA/+pVzkz5CD8jssp431NmTd3ngtkyNNVcEnOzhzC+ooBGgvODhq9bIlHIdjywtpvFoCxNHkdj7vsRbtIqQT+fAPZlROIjbD2uTZv0RmTJWD1SD24T2ejrFzc/XRLOKXxSRh8zJzJO1utIoYSI6Q1HzeK4QJw1k7J7yv3h5Oy5t68NR60Z/JA0BVFhCg4jcMwgSEUUy2pWVjSjPxPNIoQ1Q9Imuin0n2QAqDtW8XTo3iQ19/YaKRFI2Yh+099ifbv6iJBj+k5fR3kGJUYOR4fEktufkeirrZuSSVYMKjWEbQx/7FqavK5M2umr4T3xBad+zz5TM5MiviUQTTeskug3CHODAn x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_617E9429BD8044A2B2A42B8D6A5519EEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 174e72ca-61a1-470a-e0d6-08d7fe11406b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 05:30:34.4245 (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: 5BVhNMpAgkAR46azm/e5prnBxO3xN5+uQHhUCV+J9qasZ0fKd6j1durSGcT6D08ljJYIR0Z8sAgNRPsq1NX7jg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3565 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Roll] term for async msg - storing-rootack 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, 22 May 2020 05:30:40 -0000 --_000_617E9429BD8044A2B2A42B8D6A5519EEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUmFodWwNCg0KVGhlIGNsb3Nlc3QgdG8gd2hhdCB0aGUgbWVzc2FnZSBpcyByZWFsbHkg aW50ZW5kZWQgdG8gZG8gdGhlIGJldHRlciwgbGlrZSBuYW1pbmcgYSBmdW5jdGlvbiBpbiBDLiBX aGF0IGlzIHRoaXMgZm9yPw0KDQpJIHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBhbiBpbmRpY2F0aW9u IHRoYXQgdGhlIHBhdGggaXMgYXZhaWxhYmxlLg0KDQpOb3cgd2UgbmVlZCB0byB0aGluayB0aGF0 IHRoZSBtZXNzYWdlIGlzIG9ubHkgbmVlZGVkIGlmIHRoZXJlIGlzIG5vIG90aGVyIG1lc3NhZ2Ug dGhhdCB3b3VsZCBjb21lIGRvd24gYW55d2F5IGxpa2UgYSBEQVIgc2FjIGZvciBhdHRhY2hlZCBu b2RlcyBvciBzb21lIHVwcGVyIGxheWVyIHRoaW5nLg0KDQpXZSBhbHNvIG5lZWQgdG8gd29uZGVy IGFib3V0IGtlZXAgYWxpdmUuDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCkxlIDIxIG1haSAy MDIwIMOgIDA4OjI0LCBSYWh1bCBKYWRoYXYgPG55cmFodWxAb3V0bG9vay5jb20+IGEgw6ljcml0 IDoNCg0K77u/DQpIZWxsbyBBbGwsDQoNClRoaXMgaXMgYWJvdXQgdXNpbmcgYW4gYXBwcm9wcmlh dGUgbmFtZS90ZXJtIGZvciB0aGUgbWVzc2FnZSBzZW50IGZyb20gcm9vdCB0byB0aGUgbm9kZS4g VGhlIGRyYWZ0IHRhcmdldHMgdGhpcyBtc2cgYXMgYW4gaW5kaWNhdGlvbiBmb3IgZTJlIHBhdGgg ZXN0YWJsaXNobWVudCBmb3IgdGhlIG5vZGUuIEhvd2V2ZXIsIHRoaXMgcHJpbWl0aXZlIHdpbGwg YmUgdXNlZnVsIGZvciBjYXBhYmlsaXR5IHF1ZXJ5L2luZGljYXRpb24uIEluIHN0b3JpbmcgTU9Q IHRoaXMgd2lsbCBiZSB0aGUgb25seSBtZXNzYWdlIHdoaWNoIGlzIGRpcmVjdGx5IGFkZHJlc3Nl ZCB0byB0aGUgbm9kZSBmcm9tIHRoZSByb290Lg0KDQpDdXJyZW50bHksIHRoZSBkcmFmdCBjYWxs cyBpdCBEQU8tQUNLIGFuZCBpcyBub3QgYSBnb29kIHRlcm0uDQpBbm90aGVyIHRlcm0gdGhhdCBp cyBzdWdnZXN0ZWQgaXMgUm9vdEFDSy4gU2hhbGwgd2UgY2FsbCBpdCBhbiBBQ0sgYXQgYWxsPw0K UlBMLVBpbmcgaXMgYW5vdGhlciB0ZXJtLg0KDQpTdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4gSG9w aW5nIHRvIHVzZSB0aGUgdGVybSBmaW5hbGl6ZWQgaGVyZSBpbiB0aGUgaW50ZXJpbSBzbGlkZXMu DQoNClRoYW5rcywNClJhaHVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K --_000_617E9429BD8044A2B2A42B8D6A5519EEciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBSYWh1bCZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGNsb3Nlc3QgdG8g d2hhdCB0aGUgbWVzc2FnZSBpcyByZWFsbHkgaW50ZW5kZWQgdG8gZG8gdGhlIGJldHRlciwgbGlr ZSBuYW1pbmcgYSBmdW5jdGlvbiBpbiBDLiBXaGF0IGlzIHRoaXMgZm9yPzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgYW4gaW5kaWNhdGlvbiB0 aGF0IHRoZSBwYXRoIGlzIGF2YWlsYWJsZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pk5vdyB3ZSBuZWVkIHRvIHRoaW5rIHRoYXQgdGhlIG1lc3NhZ2UgaXMgb25seSBuZWVkZWQgaWYg dGhlcmUgaXMgbm8gb3RoZXIgbWVzc2FnZSB0aGF0IHdvdWxkIGNvbWUgZG93biBhbnl3YXkgbGlr ZSBhIERBUiBzYWMgZm9yIGF0dGFjaGVkIG5vZGVzIG9yIHNvbWUgdXBwZXIgbGF5ZXIgdGhpbmcu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XZSBhbHNvIG5lZWQgdG8gd29uZGVyIGFi b3V0IGtlZXAgYWxpdmUuPGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PlRha2UgY2Fy ZSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGRpcj0ibHRyIj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5MZSAyMSBtYWkgMjAy MCDDoCAwODoyNCwgUmFodWwgSmFkaGF2ICZsdDtueXJhaHVsQG91dGxvb2suY29tJmd0OyBhIMOp Y3JpdCZuYnNwOzo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7Ij4NCkhlbGxvIEFsbCw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29s b3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7Ij4NClRoaXMgaXMgYWJvdXQgdXNpbmcgYW4gYXBwcm9wcmlhdGUgbmFt ZS90ZXJtIGZvciB0aGUgbWVzc2FnZSBzZW50IGZyb20gcm9vdCB0byB0aGUgbm9kZS4gVGhlIGRy YWZ0IHRhcmdldHMgdGhpcyBtc2cgYXMgYW4gaW5kaWNhdGlvbiBmb3IgZTJlIHBhdGggZXN0YWJs aXNobWVudCBmb3IgdGhlIG5vZGUuIEhvd2V2ZXIsIHRoaXMgcHJpbWl0aXZlIHdpbGwgYmUgdXNl ZnVsIGZvciBjYXBhYmlsaXR5IHF1ZXJ5L2luZGljYXRpb24uIEluIHN0b3JpbmcNCiBNT1AgdGhp cyB3aWxsIGJlIHRoZSBvbmx5IG1lc3NhZ2Ugd2hpY2ggaXMgZGlyZWN0bHkgYWRkcmVzc2VkIHRv IHRoZSBub2RlIGZyb20gdGhlIHJvb3QuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdi KDAsIDAsIDApOyI+DQpDdXJyZW50bHksIHRoZSBkcmFmdCBjYWxscyBpdCBEQU8tQUNLIGFuZCBp cyBub3QgYSBnb29kIHRlcm0uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJy aSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7Ij4NCkFub3RoZXIgdGVybSB0aGF0IGlzIHN1Z2dlc3RlZCBpcyBSb290QUNLLiBTaGFs bCB3ZSBjYWxsIGl0IGFuIEFDSyBhdCBhbGw/PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7Ij4NClJQTC1QaW5nIGlzIGFub3RoZXIgdGVybS48L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NClN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21l LiBIb3BpbmcgdG8gdXNlIHRoZSB0ZXJtIGZpbmFsaXplZCBoZXJlIGluIHRoZSBpbnRlcmltIHNs aWRlcy48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NClRoYW5r cyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KUmFodWw8 L2Rpdj4NCjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxicj4NCjxzcGFuPlJvbGwgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFu PlJvbGxAaWV0Zi5vcmc8L3NwYW4+PGJyPg0KPHNwYW4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_617E9429BD8044A2B2A42B8D6A5519EEciscocom_-- From nobody Mon May 25 01:19:21 2020 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 CAB853A0D18 for ; Mon, 25 May 2020 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 WlpSg63ADxAM for ; Mon, 25 May 2020 01:19:15 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 AF9A83A0D16 for ; Mon, 25 May 2020 01:19:15 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id o26so9475386vsr.10 for ; Mon, 25 May 2020 01:19:15 -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=PLC+FZjnFiVgjBzTyth4Y0cFBPquKDxsfpx83m1yQ3U=; b=mmCEVZG8nboKYhy+WNyCyRdpyWS+97jslChxlud5Co0rlfksgDxhqnmtK11eV4vd6N mEjuWsRA1/018i3ysozJXVXv7+S6ozgKWq6aCdDu3qaTcg+Z/Nb5EMBVEIaA1fmlV1jr N9GdF/b8NSYgqbU/NKk4o7esFhyOeODa5QrIVKuOQisSiK3/1JR8rXVHznJyWqdiB2O/ 5k9L9xXKOtG/l8lt6LcybUHAo4/BWmAtn8dTOGhTOtuwIIfsPY0pvkm50VhYPX0zQGiZ acDQFaofPwe7hjW29US/CQPEIqi977aXbH7NUH0W1qd+niW53Xk9Pp4n80G/2V0NuCBo lFYg== 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=PLC+FZjnFiVgjBzTyth4Y0cFBPquKDxsfpx83m1yQ3U=; b=QMHrA4DRAg8q1PxAQ6P0i5ektQL2Uesm4ekw3g0ipWirCB17Q+u2/yNEWTuRl/Oh8y 58be/ddoVX5G82Rs9Hyz+wzeWjkGgJkNWmmxYNunjBZxzcL65vMYN+gQZJBZiyGXnh0m FVgRibXVZNx9uf2b6M/d1d+O8snsHBBTFNbmx+LRcA7/3B3eqbGRbMJVwxUAns5/nyPL ZvmSRwCSwa7VNzMpZnKqEXMbdA7F+gRyZz1m3dQ3vDEZcJfN7lNes0rBwOEKy9pJzNAB 2sNv+OXH1NTJpmGneHbvEiLGEdd6JLvobAHoZ6O2JPm5U/WhlIScM+oC+nqa4L7UQbTN d8ww== X-Gm-Message-State: AOAM530FgGu5Taw4VqOnFAm9RAhwDZ7QlhjIJ3OI3Otre4mMYvc2Zgwv gV33Id2zlCOsT60OyAfUlkCb8CbWurYHI/ZFhRd/tilw X-Google-Smtp-Source: ABdhPJxhF5Gl7Yy/dOP4kPg+NXJckOIZEqvoLunBwE+ej1HEi6dCGg6/1A1yeUbYULFuwDk0XX5eL0stkJGyWJk1JvM= X-Received: by 2002:a67:12c4:: with SMTP id 187mr17778127vss.100.1590394753352; Mon, 25 May 2020 01:19:13 -0700 (PDT) MIME-Version: 1.0 References: <158886943764.3475.6047615644810853641@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Mon, 25 May 2020 11:18:37 +0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000053872905a674a23c" Archived-At: Subject: Re: [Roll] WG Virtual Meeting: 2020-05-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: Mon, 25 May 2020 08:19:19 -0000 --00000000000053872905a674a23c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find below information about the Today ROLL Interim Meeting: 1. Materials: https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll Where you can find: 1.1 Proposed Agenda: https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agenda-= interim-2020-roll-02-roll-01.txt 1.2 Complete Set of Slides: https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/slides-= interim-2020-roll-02-sessa-completeset-roll-interim-20200525 2. Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-roll-interim-20200525 - Bluesheets: The Etherpad is working as blueesheet, so please remember to add your name and affiliation. Please consider volunteer as minute-taker. 3- Jabber room: roll@jabber.ietf.org. Information for setting https://www.ietf.org/how/meetings/jabber/ 4. Please note that we aim to record the meeting. The link to the video recording is going to be available here https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200525 5. Webex details: Note that the webex will open 15 minutes before, in case that the presenters want to test screen-sharing, audio, video features. We aim to have the meeting in two hours, however the webex is going to be open still 30 minutes more in case that some discussion requires more time or if someone wants to discuss with the chairs after the meeting, etc. Roll interim May meeting Hosted by ROLL WG Monday, May 25, 2020 6:45 am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada) Meeting number: 611 684 862 Password: vbR9EnBMs98 https://ietf.webex.com/ietf/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f942ac Join by video system Dial 611684862@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 611 684 862 Comments welcome! :) Thank you, Ines and Dominique On Wed, May 20, 2020 at 12:00 PM Ines Robles wrote: > Dear all, > > Please find below the agenda to the Monday 25th Interim meeting. > > > https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agend= a-interim-2020-roll-02-roll-01.txt > > 11:00 - 11:10 [10 min] WG Status --IETF 108: Meeting Format (when we meet= ? > how much time, slots?) -- Ines/Dominique > 11:10 - 11:30 [20 min] draft-thubert-roll-eliding-dio-information -- Pasc= al > 11:30 - 11:50 [20 min] New Option and Backward compatibility -- Everyon= e > 11:50 - 12:10 [20 min] Compression for control messages? Applicable for > nsa-extension --- Everyone > 12:10 - 12:30 [20 min] RPL Observation topics -- Everyone > 12:30 - 12:50 [20 min] RPL Ping -- Everyone > 12:50 -13:00 [10 min] Open Floor -- Everyone > > Please use > https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll if > you want to upload some slides for topic presentation > > Comments welcome, > > Thank you and best regards, > > Ines and Dominique > > > > On Thu, May 14, 2020 at 10:52 AM Pascal Thubert (pthubert) 40cisco.com@dmarc.ietf.org> wrote: > >> Hello Ines >> >> >> >> If time permits, I=E2=80=99d like to present the proposed operation of >> https://datatracker.ietf.org/doc/draft-thubert-roll-eliding-dio-informat= ion/ >> and get confirmation of the interest on the work by the WG. To go deeply= in >> the proposed operation we probably need at least 20 minutes. Then we nee= d >> to challenge it and improve the design, this could be started here and >> continued on the ML. >> >> >> >> For memory, this draft is the result of a past discussion at a ROLL >> interim. We found that the DIO could not be made larger and larger forev= er, >> and that eliding options would cause nodes to miss critical changes, whi= ch >> could have operational consequences. So we decided that RPLv2 must ensur= e >> that all nodes are synchronized on configuration changes and capability >> exchanges. >> >> >> >> As for other drafts, this is infrastructure work that we need before the >> new features come in. If we reach an agreement to continue with the work >> I=E2=80=99ll be happy to progress the draft and make the changes we deci= de in the >> personal submission. >> >> >> >> Take care, >> >> >> >> Pascal >> >> >> >> >> >> *From:* Roll *On Behalf Of *Ines Robles >> *Sent:* jeudi 14 mai 2020 09:20 >> *To:* roll >> *Subject:* [Roll] WG Virtual Meeting: 2020-05-25 >> >> >> >> Dear all, >> >> >> >> Please let us know the topics that you would like to discuss during the >> meeting by 19th May. >> >> >> >> So far we have a draft Agenda (topics resulting from the previous (04-29= ) >> interim meeting): >> >> - New Option and Backward compatibility >> - Compression for control messages? Applicable for nsa-extension >> - RPL Observation topics >> - RPL Ping >> >> >> >> You can upload the slides here: >> https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll >> >> The link to the video recording will be available here: >> https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200525 >> >> Webex details can be found below. >> >> >> >> Thank you and have a nice day, >> >> >> >> Ines and Dominique >> >> >> >> ---------- Forwarded message --------- >> From: *IESG Secretary* >> Date: Thu, May 7, 2020 at 7:39 PM >> Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG >> Virtual Meeting: 2020-05-25 >> To: IETF-Announce >> Cc: >> >> >> >> The Routing Over Low power and Lossy networks (roll) Working Group will >> hold >> a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC. >> >> Agenda: >> Draft Agenda: >> >> New Option and Backward compatibility >> Compression for control messages? Applicable for nsa-extension >> RPL Observation topics >> RPL Ping >> Additional Items to be determined >> >> >> Information about remote participation: >> Roll interim May meeting Hosted by ROLL WG Monday, May 25, 2020 6:45 am >> | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada) >> Meeting number: 611 684 862 >> Password: vbR9EnBMs98 >> >> https://ietf.webex.com/ietf/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f942= ac >> >> >> Join by video system >> Dial 611684862@ietf.webex.com >> You can also dial 173.243.2.68 and enter your meeting number. >> Join by phone 1-650-479-3208 >> Call-in toll number (US/Canada) >> Access code: 611 684 862 >> >> Meeting Information like link to video recording , etc would be located >> in https://github.com/roll-wg/ROLL-Interim-Meeting >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > --00000000000053872905a674a23c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find below inform= ation about the Today ROLL Interim Meeting:

1. Materials: ht= tps://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll
Where you can find:

1.1 Proposed Agenda:

https://datatracker.ietf.org/meeting/interi= m-2020-roll-02/materials/agenda-interim-2020-roll-02-roll-01.txt
1.2 Complete Set of Slides: https://datatracker.ietf.org/meeting/interim-202= 0-roll-02/materials/slides-interim-2020-roll-02-sessa-completeset-roll-inte= rim-20200525


2. Etherpad: https://etherpad.ietf.org:9009/= p/notes-ietf-roll-interim-20200525
=C2=A0
=C2=A0- Bluesheets: The= Etherpad is working as blueesheet, so please remember to add your name =C2= =A0and affiliation.=C2=A0Please consider volunteer as minute-taker.

= 3- Jabber room: roll@jabber.ietf.or= g. Information for setting https://www.ietf.org/how/meetings/jabber/

4. Please n= ote that we aim to record the meeting. The link to the video recording is g= oing to be available here https://github.com/roll-wg/ROLL-Interim-Mee= ting/tree/master/20200525

5. Webex details:

Note that th= e webex will open 15 minutes before, in case that the presenters want to te= st screen-sharing, audio, video =C2=A0features. We aim to have the meeting = in two hours, however the webex is going to be open still 30 minutes more i= n case that some discussion requires more time or if someone wants to discu= ss with the chairs after the meeting, etc.

Roll interim May meeting=
Hosted by ROLL WG

Monday, May 25, 2020 6:45 am | 2 hours 45 minu= tes | (UTC-04:00) Eastern Time (US & Canada)
Meeting number: 611 684= 862
Password: vbR9EnBMs98
https://ietf.webex.com/ietf/j.= php?MTID=3Dm59fad4e3500688e160f0d772b9f942ac

Join by video syste= m
Dial 611684862@ietf.webex.= com
You can also dial 173.243.2.68 and enter your meeting number.
Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Acc= ess code: 611 684 862

Comments welcome! :)

Thank you,

= Ines and Dominique

On Wed, May 20, 2020 at 12:00 PM Ines Robles <mariainesrobles@googlemail.c= om> wrote:
Dear all,

Please fin= d below the agenda to the Monday 25th Interim meeting.

=

11:00 - 11:10=C2= =A0[10 min] WG Status --IETF 108: Meeting Format (when we meet? how much ti= me, slots?) --=C2=A0Ines/Dominique
11:10 - 11:30 [20 min] draft-thubert-= roll-eliding-dio-information -- Pascal
11:30 - 11:50=C2=A0=C2=A0[= 20 min] New Option and Backward compatibility=C2=A0 -- Everyone
11:50 - = 12:10=C2=A0=C2=A0[20 min] Compression for control messages? Applicable for = nsa-extension --- Everyone
12:10 - 12:30=C2=A0=C2=A0[20 min] RPL Observa= tion topics -- Everyone
12:30 - 12:50=C2=A0=C2=A0[20 min] RPL Ping -- Ev= eryone
12:50 -13:00=C2=A0=C2=A0[10 min] Open Floor=C2=A0 --=C2=A0Everyon= e

Please use=C2=A0ht= tps://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll if= you want to upload some slides for topic presentation

=
Comments welcome,

Thank you and best regards,=

Ines and Dominique


<= /div>

On Thu, May 14, 2020 at 10:52 AM Pascal Thubert (pthubert) <pthuber= t=3D40cisco= .com@dmarc.ietf.org> wrote:

Hello Ines

=C2=A0

If time permits, I=E2=80=99d like to present the proposed oper= ation of https://datatracker.ietf.org/doc/d= raft-thubert-roll-eliding-dio-information/ and get confirmation of the = interest on the work by the WG. To go deeply in the proposed operation we probably = need at least 20 minutes. Then we need to challenge it and improve the desi= gn, this could be started here and continued on the ML.

=C2=A0

For memory, this draft is the result of a past discussion at a= ROLL interim. We found that the DIO could not be made larger and larger fo= rever, and that eliding options would cause nodes to miss critical changes, which could have operational consequ= ences. So we decided that RPLv2 must ensure that all nodes are synchronized= on configuration changes and capability exchanges.

=C2=A0

As for other drafts, this is infrastructure work that we need = before the new features come in. If we reach an agreement to continue with = the work I=E2=80=99ll be happy to progress the draft and make the changes we decide in the personal submission.

=C2=A0

Take care,

=C2=A0

Pascal

=C2=A0

=C2=A0

=C2=A0

Dear all,

=C2=A0

Please let us know the topics that you would like to discuss d= uring the meeting by 19th May.

=C2=A0

So far we have a draft Agenda (topics resulting from the previ= ous (04-29) interim meeting):

  • New Option= and Backward compatibility
  • Compressio= n for control messages? Applicable for nsa-extension
  • RPL Observ= ation topics
  • RPL Ping

=C2=A0

The link to the video recording will be available here:=C2=A0<= a href=3D"https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200= 525" target=3D"_blank">https://github.com/roll-wg/ROLL-Interim-Meeting/tree= /master/20200525

Webex details can be found below.<= /p>

=C2=A0

Thank you and have a nice day,

=C2=A0

Ines and Dominique

=C2=A0

---------- Forwarded message ---------
From: IESG Secretary <iesg-secretary@ietf.org>=
Date: Thu, May 7, 2020 at 7:39 PM
Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG Virtual= Meeting: 2020-05-25
To: IETF-Announce <ietf-announce@ietf.org>
Cc: <roll@ietf.org>



The Routing Over Low power and Lossy networks (roll) Working Group will hol= d
a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC.

Agenda:
Draft Agenda:

New Option and Backward compatibility
Compression for control messages? Applicable for nsa-extension
RPL Observation topics
RPL Ping
Additional Items to be determined


Information about remote participation:
Roll interim May meeting Hosted by ROLL WG=C2=A0 Monday, May 25, 2020 6:45 = am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada)
Meeting number: 611 684 862
Password: vbR9EnBMs98

https://ietf.webex.com/ietf/j.php?MTID=3Dm59f= ad4e3500688e160f0d772b9f942ac=C2=A0

Join by video system
Dial 61168486= 2@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.=C2=A0
Join by phone 1-650-479-3208
Call-in toll number (US/Canada)
Access code: 611 684 862

Meeting Information like link to video recording , etc would be located in = https://github.com/roll-wg/ROLL-Interim-Meeting

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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000053872905a674a23c-- From nobody Mon May 25 17:34:15 2020 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 2AD7D3A07D6 for ; Mon, 25 May 2020 17:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-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=outlook.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 ADiFRKUtJ88R for ; Mon, 25 May 2020 17:34:10 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254076.outbound.protection.outlook.com [40.92.254.76]) (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 28F903A07D1 for ; Mon, 25 May 2020 17:34:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m0j87/YgHBkf1pn6sVAODiiMQaBENPt9g8yO/WPXKLFaWUojcYDZWu9HsXTANxbofFvw1G9N9qc6XFwUoUwoA4GJQCDMmIRsMRzWCM5Ds3FnC2TlrQIG10m7gG+d9MYJT/WeRulToTvtHLTUZltZ1cvy2choxmwd37hggMKTC6laaOh0UYOT15ft73E30HoH82LTs3pd4t+NoIMDeN84CiQI7Llg0OXrOyYdzOa4W0S/n0PW7TKDe8SPULiZy3sjffqDbtzpzhUAl33lQ2Q58C+z4Qg722GVJJkevr6wB9LYOONaMfPTpuPOqgaikoIADDQOq9xuaB9fv4UZ/WO2PA== 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=Q83XOEnrCBWdw76leV0qQOKFTfnjbHe1DKsjQMD6WyY=; b=kxrxhahifltE+aUI0teUjfLG6M3FHEbidb+iPfhFmQR9qrU3fUXLUtKlSwMSnwTwIrgSINDuXYnpMbCJZMJaBj5gR9r9m9dq+XX3GGsTzyl2ykAaoqz7yXxi191/b+pBOtqyVv8qZX4x6MWe7KcBoaBOZVnPLe1dmOrSqA7SB6Ti6UBoSfi2ejulWFDCPC7jRGvg1ZZoxSNmpD8oLegoDUG51EfEk/2bsGus552C7A73NZHNRDL3ylW63cBIMAsL4jx+gpoxzV1QS7xOCFBYfy3ARFlWhiIuqFSebHsi585a5adRktKNnNN17h2yyvkD/lHnSmgSizbkQH3oH3dEvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q83XOEnrCBWdw76leV0qQOKFTfnjbHe1DKsjQMD6WyY=; b=GFxudHGRuFHlygQ/W9N0ivJXzphxJM0+goHeeVrPrqmtzrJk0Y0fWRFCHquDSaeuvMTXUbmLBx9lILnSeL5CmNtjN1b8E/kNcuYEpWiCQ1aszCu2MRKS4OwuKxVjcaJBY598+q1j9Et+PQnOfjgm5SHpMffn+eKakuhItip8IqN5mD47wdMB5aaWt3mUEg0OFMaBcPeS39FjCUkfv0FAJsWWoc6mTWojpovs9oXFnP9w9YFwLyubuS6BOR37YK63cMVtS7hRofJ8kWwBlE0WE+k41isk6YyuG73EH1FFjNYl28ZdeI6fWSSsmD/EHiQKX/NtMMhXhNPjVvlwuXqRGg== Received: from SG2APC01FT047.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::52) by SG2APC01HT102.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Tue, 26 May 2020 00:34:07 +0000 Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebd::43) by SG2APC01FT047.mail.protection.outlook.com (2a01:111:e400:7ebd::428) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Tue, 26 May 2020 00:34:07 +0000 Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564]) by MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564%7]) with mapi id 15.20.3021.029; Tue, 26 May 2020 00:34:07 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: extended use of ROLL-WG Github org Thread-Index: AQHWMvJUV87JxxCmtEaOtrqFsLyaRw== Date: Tue, 26 May 2020 00:34:07 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:BC6CF38DD95B61798D586C321D6ACA61E12B697324B1E388E12ECC9392384061; UpperCasedChecksum:EC233106715BA669079782067C8356B4D6BA27F0E65C93FA79BF6A6AF32E93B8; SizeAsReceived:6666; Count:42 x-tmn: [bS5FF2vB4i4EIecJwQ6GNe/Ny1iSxjUQ] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 0ea44f36-008a-427d-f092-08d8010c8036 x-ms-traffictypediagnostic: SG2APC01HT102: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 66TphFP8poax/05SgsSeTEGF8ZEuJWTtJ72gL21zka5aPFaga/xVhRMPC3ttUfV7V5j4UM/97I36I1LOVxTtNJx/J9cWzhMkSxZyMkxev+XRe6cs3DP9fL9l3FyBcHuI6V969/1AhnYwNzTO+r+SH1WZV2vm3gF8SnTyJU0z93LYrZxysQnjhQI8i3PwrXImI+W+o5bBfwSHRrnEz/E+Sg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: 97Low2rq6UGgx+56PmrBAPIycnM5QaBMc33YGQhlNq8FZ3faLvpRqUFcyJaWjVwRaCmcGmGKyXOjuMXq0V9G7UU3NY0yih8z8Kz7w/7jV21oLMMQETcLVxg7Gpm91waBUHm8sKFV0npTv1e8Aj7Jvw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MAXPR01MB2493BB668503806358D9EC16A9B00MAXPR01MB2493INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0ea44f36-008a-427d-f092-08d8010c8036 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 00:34:07.4065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT102 Archived-At: Subject: [Roll] extended use of ROLL-WG Github org 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, 26 May 2020 00:34:12 -0000 --_000_MAXPR01MB2493BB668503806358D9EC16A9B00MAXPR01MB2493INDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess roll-wg GitHub org is serving us well. Question: Can we have a common resource repo where we can keep additional d= ata such as sample pcaps? The pcap can be tagged with relevant info {releva= nt draft/rfc, description, pcap-src} etc. Thought of keeping the pcaps in i= ndividual draft repo but there is no repo for RFC6550. * example1: aggregated-targets-DAO.pcap aggregated-targets-DAO.md contains {Draft/RFC=3D{RFC6550}, Description=3D"P= rovides a sample RPL DAO message with aggregated targets in a DAO", pcap-sr= c=3D"field-deployment"} * example2: ghc-compressed-rpl.pcap ghc-compressed-DAO.md contains {Draft/RFC=3D{RFC6550, RFC7400}, Description= =3D"GHC compressed RPL pcap", pcap-src=3D"simulation"} Is there any other WG doing the same? (to copy the format) Regards, Rahul --_000_MAXPR01MB2493BB668503806358D9EC16A9B00MAXPR01MB2493INDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I guess roll-wg GitHub org is serving us well.

Question: Can we have a common resource repo where we can keep additional d= ata such as sample pcaps? The pcap can be tagged with relevant info {releva= nt draft/rfc, description, pcap-src} etc. Thought of keeping the pcaps in i= ndividual draft repo but there is no repo for RFC6550.
    1. example1: aggregated-targets-DAO.pcap
      aggregated-targets-DAO.m= d contains {Draft/RFC=3D{RFC6550}, Description=3D"Provides= a sample RPL DAO message with aggregated targets in a DAO", pcap-src=3D"field-deployment"} 
    2. exa= mple2: ghc-compressed-rpl.pcap
      ghc-compressed-DAO.md contains {Draft/RFC=3D{RFC6550, RFC7400}, Description=3D"GHC compressed RPL pcap", pcap-src=3D&q= uot;simulation"}
Is there any other WG doing the same? (to copy= the format)

Regards,
Rahul
--_000_MAXPR01MB2493BB668503806358D9EC16A9B00MAXPR01MB2493INDP_-- From nobody Mon May 25 17:49:31 2020 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 357593A086B for ; Mon, 25 May 2020 17:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 DEQKw-ipYI4l for ; Mon, 25 May 2020 17:49:25 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DA33A086A for ; Mon, 25 May 2020 17:49:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 811C8389DA for ; Mon, 25 May 2020 20:47:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wWTy10GNqa80 for ; Mon, 25 May 2020 20:47:06 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 44DAF389D9 for ; Mon, 25 May 2020 20:47:06 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B88624BE for ; Mon, 25 May 2020 20:49:21 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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 Date: Mon, 25 May 2020 20:49:21 -0400 Message-ID: <24433.1590454161@localhost> Archived-At: Subject: Re: [Roll] extended use of ROLL-WG Github org 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, 26 May 2020 00:49:30 -0000 Rahul Jadhav wrote: > I guess roll-wg GitHub org is serving us well. > Question: Can we have a common resource repo where we can keep > additional data such as sample pcaps? The pcap can be tagged with > relevant info {relevant draft/rfc, description, pcap-src} etc. Thought > of keeping the pcaps in individual draft repo but there is no repo for > RFC6550. Yes. https://github.com/roll-wg/rpl-samples I will need to add permissions to you. I trivial search didn't find the right account. Probably should create a team. From nobody Sun May 31 13:12:21 2020 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 112223A0D21 for ; Sun, 31 May 2020 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 Vn9kzpbC6K9s for ; Sun, 31 May 2020 13:12:16 -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 8D37D3A0D1E for ; Sun, 31 May 2020 13:12:16 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id o2so1585389vsr.0 for ; Sun, 31 May 2020 13:12:16 -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=pEPlLgjnzmutLxxcnxCSMjeS8DW+8FLTyao6AjbYIlk=; b=CE+XaDaYUrHsJpoo6CLDBUDAhHuxaVotIkFdauP0v1pABBq5A/FOa+Wd+enZqN3aK0 uepi3oq+d6TXteRApi5M+ObbVzCy93UsHu1tFkr/9ShzF75IwoKW6z+pUwjc7TDCvuxU so6LzI+3fSUWTfnVNqZyATJ44BEJ2qeUDF4udGxIq3Y4WHEbzzY38x3NUUiU/Whr0ahv GY+CniaRUGKgOHOUh6jFiu1DPVrObjG5uvTjCsjRMxRAn8rUxCZNhyes/f/pEoVSMePa xMwd3gThcSlHfWjXFE/nMjTtyCW7UIcQcU5WpCkL/ywgkBHig1krIf9rs2orq9A0/BU5 EgTw== 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=pEPlLgjnzmutLxxcnxCSMjeS8DW+8FLTyao6AjbYIlk=; b=Dij6tJHOCe++asSgfJxf24doFK/3SFHZXY0AE2JC4S/Iabc7LVO24P8ROFmdsXt4zv Sb3smYgyBmTi/Gwlqd9iXKCRN+jM57++4iuCK93ZCR5RsFtq4PcoKIS2jhm6Lh213u+i L5kPxyIhAchg7VmjzWDBLnZB/RIK0YOUULGynAd7TV6swiH3BYpllHcYsFOmSj0bmmFw MeoxkB+6DUTsiCJJyB95pzVvHjMqakFcBveEdC+oOcG6Z5L6wfSuUYY6NR8py93VweWJ LNHI4oPa8QJDZY/DX3aqJV1q36dozUEKwWwu6Sn4uOZVVoLfBXZZ4XBhaBmt2uZA3Ofu 2J0A== X-Gm-Message-State: AOAM530Nv7Ayh1OYPkNB3RJm6LMBtaJALy4qumq3pgEoAyGWKPmRhxqs 1ei8zf+yotHFMMteaRR+RgHsCJ9V4UltEd1ORVq1dmKd X-Google-Smtp-Source: ABdhPJzU5QF2tL0BLVa4G872S83p7qUDMDe6Cw2CKKo0zI0YCKbZxUU1fWDVAFy0PDolDFFNiGWbfPr58KGT1KdS0dM= X-Received: by 2002:a05:6102:3ce:: with SMTP id n14mr12158462vsq.113.1590955935145; Sun, 31 May 2020 13:12:15 -0700 (PDT) MIME-Version: 1.0 References: <158886943764.3475.6047615644810853641@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Sun, 31 May 2020 23:11:39 +0300 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000005e38cd05a6f74bd3" Archived-At: Subject: Re: [Roll] WG Virtual Meeting: 2020-05-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: Sun, 31 May 2020 20:12:19 -0000 --0000000000005e38cd05a6f74bd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find the link to the video of the meeting on 20200525: https://github.com/roll-wg/ROLL-Interim-Meeting/blob/master/20200525/LinkTo= VideoRecording - Note that all IETF Interim meetings are posted in Youtube. Conclusions/Action Points of the meeting: -- IETF 108: Form with questions related to -- meeting during IETF 108/meeting after IETF108-- to be sent shortly. -- Backward compatibility and New Options: Proposition 2 "Use second higher order bit of Option Type to indicate 'X' extended Option Flag": More flexible than Proposition 1, need more examples to discuss, to be included into MOPEX draft, Use Core-Flags as base: Critical, Elective and Safte-to-Forward. [minute 0:20 to minute 0:27] -- Compression of Control Messages: The mechanism to be developed do not need to include information into nsa-extension, thus nsa-extension can move forward. No objections [minute 0:37 to minute 0:43] -- RPL-Observations: Important document to track the development of RPLv2 -- Draft-thubert-roll-eliding-dio-information: Please read and send your review to the ML. -- RootAck: Are there dependencies with unaware-leaves draft? [minute 1:39 to minutes 1:41] Handling Capability Query: Keep separte messages RootCapQuery and CapResponse [minute 1:47 to minute 1:50] --Open Floor: Good to have an interim meeting in June. Minutes: https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/minutes= -interim-2020-roll-02-202005251100.txt Comments welcome, Thank you, Ines and Dominique On Mon, May 25, 2020 at 11:18 AM Ines Robles wrote: > Dear all, > > Please find below information about the Today ROLL Interim Meeting: > > 1. Materials: > https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll > > Where you can find: > > 1.1 Proposed Agenda: > > > https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agend= a-interim-2020-roll-02-roll-01.txt > > 1.2 Complete Set of Slides: > https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/slide= s-interim-2020-roll-02-sessa-completeset-roll-interim-20200525 > > > 2. Etherpad: > https://etherpad.ietf.org:9009/p/notes-ietf-roll-interim-20200525 > > - Bluesheets: The Etherpad is working as blueesheet, so please remember > to add your name and affiliation. Please consider volunteer as > minute-taker. > > 3- Jabber room: roll@jabber.ietf.org. Information for setting > https://www.ietf.org/how/meetings/jabber/ > > 4. Please note that we aim to record the meeting. The link to the video > recording is going to be available here > https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200525 > > 5. Webex details: > > Note that the webex will open 15 minutes before, in case that the > presenters want to test screen-sharing, audio, video features. We aim to > have the meeting in two hours, however the webex is going to be open stil= l > 30 minutes more in case that some discussion requires more time or if > someone wants to discuss with the chairs after the meeting, etc. > > Roll interim May meeting > Hosted by ROLL WG > > Monday, May 25, 2020 6:45 am | 2 hours 45 minutes | (UTC-04:00) Eastern > Time (US & Canada) > Meeting number: 611 684 862 > Password: vbR9EnBMs98 > https://ietf.webex.com/ietf/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f942a= c > > Join by video system > Dial 611684862@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > > Join by phone > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 611 684 862 > > Comments welcome! :) > > Thank you, > > Ines and Dominique > > On Wed, May 20, 2020 at 12:00 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Please find below the agenda to the Monday 25th Interim meeting. >> >> >> https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agen= da-interim-2020-roll-02-roll-01.txt >> >> 11:00 - 11:10 [10 min] WG Status --IETF 108: Meeting Format (when we >> meet? how much time, slots?) -- Ines/Dominique >> 11:10 - 11:30 [20 min] draft-thubert-roll-eliding-dio-information -- >> Pascal >> 11:30 - 11:50 [20 min] New Option and Backward compatibility -- Everyo= ne >> 11:50 - 12:10 [20 min] Compression for control messages? Applicable for >> nsa-extension --- Everyone >> 12:10 - 12:30 [20 min] RPL Observation topics -- Everyone >> 12:30 - 12:50 [20 min] RPL Ping -- Everyone >> 12:50 -13:00 [10 min] Open Floor -- Everyone >> >> Please use >> https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll >> if you want to upload some slides for topic presentation >> >> Comments welcome, >> >> Thank you and best regards, >> >> Ines and Dominique >> >> >> >> On Thu, May 14, 2020 at 10:52 AM Pascal Thubert (pthubert) > 40cisco.com@dmarc.ietf.org> wrote: >> >>> Hello Ines >>> >>> >>> >>> If time permits, I=E2=80=99d like to present the proposed operation of >>> https://datatracker.ietf.org/doc/draft-thubert-roll-eliding-dio-informa= tion/ >>> and get confirmation of the interest on the work by the WG. To go deepl= y in >>> the proposed operation we probably need at least 20 minutes. Then we ne= ed >>> to challenge it and improve the design, this could be started here and >>> continued on the ML. >>> >>> >>> >>> For memory, this draft is the result of a past discussion at a ROLL >>> interim. We found that the DIO could not be made larger and larger fore= ver, >>> and that eliding options would cause nodes to miss critical changes, wh= ich >>> could have operational consequences. So we decided that RPLv2 must ensu= re >>> that all nodes are synchronized on configuration changes and capability >>> exchanges. >>> >>> >>> >>> As for other drafts, this is infrastructure work that we need before th= e >>> new features come in. If we reach an agreement to continue with the wor= k >>> I=E2=80=99ll be happy to progress the draft and make the changes we dec= ide in the >>> personal submission. >>> >>> >>> >>> Take care, >>> >>> >>> >>> Pascal >>> >>> >>> >>> >>> >>> *From:* Roll *On Behalf Of *Ines Robles >>> *Sent:* jeudi 14 mai 2020 09:20 >>> *To:* roll >>> *Subject:* [Roll] WG Virtual Meeting: 2020-05-25 >>> >>> >>> >>> Dear all, >>> >>> >>> >>> Please let us know the topics that you would like to discuss during the >>> meeting by 19th May. >>> >>> >>> >>> So far we have a draft Agenda (topics resulting from the previous >>> (04-29) interim meeting): >>> >>> - New Option and Backward compatibility >>> - Compression for control messages? Applicable for nsa-extension >>> - RPL Observation topics >>> - RPL Ping >>> >>> >>> >>> You can upload the slides here: >>> https://datatracker.ietf.org/meeting/interim-2020-roll-02/session/roll >>> >>> The link to the video recording will be available here: >>> https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200525 >>> >>> Webex details can be found below. >>> >>> >>> >>> Thank you and have a nice day, >>> >>> >>> >>> Ines and Dominique >>> >>> >>> >>> ---------- Forwarded message --------- >>> From: *IESG Secretary* >>> Date: Thu, May 7, 2020 at 7:39 PM >>> Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG >>> Virtual Meeting: 2020-05-25 >>> To: IETF-Announce >>> Cc: >>> >>> >>> >>> The Routing Over Low power and Lossy networks (roll) Working Group will >>> hold >>> a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC. >>> >>> Agenda: >>> Draft Agenda: >>> >>> New Option and Backward compatibility >>> Compression for control messages? Applicable for nsa-extension >>> RPL Observation topics >>> RPL Ping >>> Additional Items to be determined >>> >>> >>> Information about remote participation: >>> Roll interim May meeting Hosted by ROLL WG Monday, May 25, 2020 6:45 a= m >>> | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada) >>> Meeting number: 611 684 862 >>> Password: vbR9EnBMs98 >>> >>> https://ietf.webex.com/ietf/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f94= 2ac >>> >>> >>> Join by video system >>> Dial 611684862@ietf.webex.com >>> You can also dial 173.243.2.68 and enter your meeting number. >>> Join by phone 1-650-479-3208 >>> Call-in toll number (US/Canada) >>> Access code: 611 684 862 >>> >>> Meeting Information like link to video recording , etc would be located >>> in https://github.com/roll-wg/ROLL-Interim-Meeting >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> --0000000000005e38cd05a6f74bd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the link to the video of the = meeting on 20200525:

https://github.com/r= oll-wg/ROLL-Interim-Meeting/blob/master/20200525/LinkToVideoRecording -= Note that all IETF Interim meetings are posted in Youtube.

Conclusi= ons/Action Points of the meeting:

-- IETF 108: Form with questions r= elated to -- meeting during IETF 108/meeting after IETF108-- to be sent sho= rtly.

-- Backward compatibility and New Options:
Proposition 2"Use second higher order bit of Option Type to indicate 'X' e= xtended Option Flag": More flexible than Proposition 1, need more exam= ples to discuss, to be included into MOPEX draft, Use Core-Flags as base: C= ritical, Elective and Safte-to-Forward. =C2=A0[minute 0:20 to minute 0:27]<= br>
-- Compression of Control Messages: The mechanism to be developed = =C2=A0do not need to include information into nsa-extension, thus nsa-exten= sion can move forward. No objections [minute 0:37 to minute 0:43]

--= RPL-Observations: Important document to track the development of RPLv2
=

-- Draft-thubert-roll-eliding-dio-information: Please read and send= your review to the ML.

=C2=A0-- RootAck:
Are there dependencies = with unaware-leaves draft? [minute 1:39 to minutes 1:41]
Handling Capabi= lity Query: Keep separte messages RootCapQuery and CapResponse [minute 1:47= to minute 1:50]

--Open Floor: Good to have an interim meeting in Ju= ne.

Minutes: http= s://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/minutes-int= erim-2020-roll-02-202005251100.txt

Comments welcome,

Than= k you,

Ines and Dominique

On Mon, May 25, 2020 at 11:18 AM Ines = Robles <mariainesroble= s@googlemail.com> wrote:
Dear all,

Please f= ind below information about the Today ROLL Interim Meeting:

1. Mater= ials: https://datatracker.ietf.org/meeting/interi= m-2020-roll-02/session/roll

Where you can find:

1.1 Prop= osed Agenda:

https://datatracker.ietf.org/meeting/interim-2020-roll-02/material= s/agenda-interim-2020-roll-02-roll-01.txt

1.2 Complete Set of Sl= ides: https://datatracker.ietf.org/meeting/interim-2020-rol= l-02/materials/slides-interim-2020-roll-02-sessa-completeset-roll-interim-2= 0200525


2. Etherpad: https://etherpad.i= etf.org:9009/p/notes-ietf-roll-interim-20200525
=C2=A0
=C2=A0- Bl= uesheets: The Etherpad is working as blueesheet, so please remember to add = your name =C2=A0and affiliation.=C2=A0Please consider volunteer as minute-t= aker.

3- Jabber room: roll@jabber.ietf.org. Information for setting https://www.ietf= .org/how/meetings/jabber/

4. Please note that we aim to record = the meeting. The link to the video recording is going to be available here = https://github.com/roll-wg/ROLL-Interim-Meeting/tre= e/master/20200525

5. Webex details:

Note that the webex = will open 15 minutes before, in case that the presenters want to test scree= n-sharing, audio, video =C2=A0features. We aim to have the meeting in two h= ours, however the webex is going to be open still 30 minutes more in case t= hat some discussion requires more time or if someone wants to discuss with = the chairs after the meeting, etc.

Roll interim May meeting
Host= ed by ROLL WG

Monday, May 25, 2020 6:45 am | 2 hours 45 minutes | (U= TC-04:00) Eastern Time (US & Canada)
Meeting number: 611 684 862
= Password: vbR9EnBMs98
https://ietf.webex.= com/ietf/j.php?MTID=3Dm59fad4e3500688e160f0d772b9f942ac

Join by = video system
Dial 611684862@ietf.webex.com
You can also dial 173.243.2.68 and = enter your meeting number.

Join by phone
1-650-479-3208 Call-in t= oll number (US/Canada)
Access code: 611 684 862

Comments welcome!= :)

Thank you,

Ines and Dominique

On Wed, May 20, 2020 at = 12:00 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Dear all,

Please find below the agenda to the M= onday 25th Interim meeting.



Please use=C2=A0https://datatracker.ietf.or= g/meeting/interim-2020-roll-02/session/roll if you want to upload some = slides for topic presentation

Comments welcome,

Thank you and best regards,

Ines and Dominique



On Thu, May 14, 2020= at 10:52 AM Pascal Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org&g= t; wrote:

Hello Ines

=C2=A0

If time permits, I=E2=80=99d like to present the proposed oper= ation of https://datatracker.ietf.org/doc/d= raft-thubert-roll-eliding-dio-information/ and get confirmation of the = interest on the work by the WG. To go deeply in the proposed operation we probably = need at least 20 minutes. Then we need to challenge it and improve the desi= gn, this could be started here and continued on the ML.

=C2=A0

For memory, this draft is the result of a past discussion at a= ROLL interim. We found that the DIO could not be made larger and larger fo= rever, and that eliding options would cause nodes to miss critical changes, which could have operational consequ= ences. So we decided that RPLv2 must ensure that all nodes are synchronized= on configuration changes and capability exchanges.

=C2=A0

As for other drafts, this is infrastructure work that we need = before the new features come in. If we reach an agreement to continue with = the work I=E2=80=99ll be happy to progress the draft and make the changes we decide in the personal submission.

=C2=A0

Take care,

=C2=A0

Pascal

=C2=A0

=C2=A0

=C2=A0

Dear all,

=C2=A0

Please let us know the topics that you would like to discuss d= uring the meeting by 19th May.

=C2=A0

So far we have a draft Agenda (topics resulting from the previ= ous (04-29) interim meeting):

  • New Option= and Backward compatibility
  • Compressio= n for control messages? Applicable for nsa-extension
  • RPL Observ= ation topics
  • RPL Ping

=C2=A0

The link to the video recording will be available here:=C2=A0<= a href=3D"https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200= 525" target=3D"_blank">https://github.com/roll-wg/ROLL-Interim-Meeting/tree= /master/20200525

Webex details can be found below.<= /p>

=C2=A0

Thank you and have a nice day,

=C2=A0

Ines and Dominique

=C2=A0

---------- Forwarded message ---------
From: IESG Secretary <iesg-secretary@ietf.org>=
Date: Thu, May 7, 2020 at 7:39 PM
Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG Virtual= Meeting: 2020-05-25
To: IETF-Announce <ietf-announce@ietf.org>
Cc: <roll@ietf.org>



The Routing Over Low power and Lossy networks (roll) Working Group will hol= d
a virtual interim meeting on 2020-05-25 from 11:00 to 13:00 UTC.

Agenda:
Draft Agenda:

New Option and Backward compatibility
Compression for control messages? Applicable for nsa-extension
RPL Observation topics
RPL Ping
Additional Items to be determined


Information about remote participation:
Roll interim May meeting Hosted by ROLL WG=C2=A0 Monday, May 25, 2020 6:45 = am | 2 hours 45 minutes | (UTC-04:00) Eastern Time (US & Canada)
Meeting number: 611 684 862
Password: vbR9EnBMs98

https://ietf.webex.com/ietf/j.php?MTID=3Dm59f= ad4e3500688e160f0d772b9f942ac=C2=A0

Join by video system
Dial 61168486= 2@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.=C2=A0
Join by phone 1-650-479-3208
Call-in toll number (US/Canada)
Access code: 611 684 862

Meeting Information like link to video recording , etc would be located in = https://github.com/roll-wg/ROLL-Interim-Meeting

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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--0000000000005e38cd05a6f74bd3-- From nobody Sun May 31 13:14:16 2020 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 00AB83A0D92 for ; Sun, 31 May 2020 13:14:15 -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, 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 bU2CNO7hawn6 for ; Sun, 31 May 2020 13:14:13 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 359C33A0D90 for ; Sun, 31 May 2020 13:14:13 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id k13so1741033vsm.13 for ; Sun, 31 May 2020 13:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Sybl+Urf8+3BH+zU6yi1Nr6Zib5KLokKId64jBPAx2Q=; b=ZTPAdPsFO8z9ua4GzZxnvwF1fa+cTqBhp3lgZ3XcUFwmiYDi3NY7JPbTVuGlNo/YUJ 4jfjxti8x+iGMnB/IPZz0P9QcUbLRqLc5x97OpB+5EazgmYML+XqImZ/4J6GPPyIm4D9 2Dol6HzK7PC7VSb+BSV9WPW+csMOtemBHEZW7W1o28RLI4GIQ3dLtcTLaweYkf6pQLru LIGOLKbRYhFCNmOnjsbZAe7Iz8w+DMkbvqOcEjHsvwlG/ir+i/wxYDPnQM/ZnXOqMhcf nAIERdByGLTlIM295DiRkkmVJ0aePYWVoBJEm6OA6t8lX/Kt8QGYiZDQcCuOMkaqpBoa ve+g== 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=Sybl+Urf8+3BH+zU6yi1Nr6Zib5KLokKId64jBPAx2Q=; b=oQfz7YJMqO0SyK61cPS8ggzqSWJ8Qq65p7Y6xMpjKGyNuwjkA4qh02+RwffnukMM0e nCev9WcvdDfDR867vBJFjD08N/fg0jfxUgWH7koAKvZsVj+dwcuQR4DfIhWYnsqcxbc2 0FUlEEpZNfJmZxR8W0Bssc97ojGQtONkxE5t9DQnWoKtllX72bwtgbdEt77CJxx2JHMF pYq+KGJuLANqRQsVS4E+A6gGMd+F53Grvv99HEAkJoxh6moJj6PMstcdJnG3v39ZS+91 FV27hgXvGv1p0r7dQL9QNxDmjsEYxaPYAxbFG4FRMeqT9G5/pbDJyTwBmuXjqbv4CZY4 GVoA== X-Gm-Message-State: AOAM531ScEZJVfm+lNgnem3+6zro2I7TciinbGUGQBCAX9N90eDpsBeB WD+7BESkbZwSlkJzzMoK/2PLt8F2ETxspUqPxuvoKv4l X-Google-Smtp-Source: ABdhPJxx51L+cmPCuR3OsZnn43wCBlXbxmTvCeqF64n53EHLG5TwytDVXaZmDr6nAYjEPsUtmBPaj8rN7ZZbeJYhrT4= X-Received: by 2002:a67:7789:: with SMTP id s131mr12877061vsc.216.1590956051977; Sun, 31 May 2020 13:14:11 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Sun, 31 May 2020 23:13:36 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000054dc6f05a6f752d7" Archived-At: Subject: [Roll] ROLL Interim June - Please feel the doodle by 5th June- 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: Sun, 31 May 2020 20:14:15 -0000 --00000000000054dc6f05a6f752d7 Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the link to the doodle for the Interim Meeting in June. Please fill it by 05th June. https://doodle.com/poll/sg879nzrkbnd6x2b Thank you in advance, Ines and Dominique. --00000000000054dc6f05a6f752d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find below the link to the doodle = for the Interim Meeting in June. Please fill it by 05th June.

https://doodle.com/poll/sg87= 9nzrkbnd6x2b

Thank you in advance,

Ines and Dominique.
--00000000000054dc6f05a6f752d7--