From nobody Tue Feb 2 19:17:09 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9064E3A129F; Tue, 2 Feb 2021 19:17:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <161232222453.23518.104596781073967063@ietfa.amsl.com> Date: Tue, 02 Feb 2021 19:17:04 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-pubsub-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 03:17:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Publish/Subscribe Functionality for LISP Authors : Alberto Rodriguez-Natal Vina Ermagan Albert Cabellos Sharon Barkai Mohamed Boucadair Filename : draft-ietf-lisp-pubsub-08.txt Pages : 12 Date : 2021-02-02 Abstract: This document specifies an extension to the use of Map-Request to enable Publish/Subscribe (PubSub) operation for LISP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-pubsub-08 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-pubsub-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 Tue Feb 2 19:18:29 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839853A12A0; Tue, 2 Feb 2021 19:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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_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=JdRq8N1b; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M/EXIBYN 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 JnWqNrG2ahEW; Tue, 2 Feb 2021 19:18:24 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02343A12A7; Tue, 2 Feb 2021 19:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38731; q=dns/txt; s=iport; t=1612322294; x=1613531894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uCpMzHQAqfEqkCuX2VNNUmJSqLWNyQC6uV03SjJGVKA=; b=JdRq8N1btSVYNoptrjIENL6W6TLmdh+retyFf7rnUQX3COxAVUIKAfky /9vI9wrIn0WXJOjmpLnrXq+/bUMlmESL1suuP1wiNbnpdteMx76y2oGO5 tsrJtEokFi1iiVT8j81jjy9SMxxMTeJQ4T5YwKs9FIWtdum9SsKWNvm65 E=; X-IPAS-Result: =?us-ascii?q?A0D+AAC+FBpgkI0NJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYIPgSMwUX1aMhcaCgGENYNIA44LA48TigaBQoERA08FCwEBAQ0BARgBC?= =?us-ascii?q?goCBAEBhEoCF4FlAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAYY4D?= =?us-ascii?q?YVzAQEBBAEBGwYdAQEMIAsBDwIBCBEDAQIOEwEGAwICAiUKARQJCAIECAYFH?= =?us-ascii?q?QSDBQGBflcDLgEOpS8CiiV2gTKDBQEBBoUZGIISAwaBOIJ3g3gNAYZCJhuCA?= =?us-ascii?q?IERJxyCVj6CXQEBgSoBEgEHAjgNCYJjNIIsgVkQARw+B2MEFAY5DRU5JwECD?= =?us-ascii?q?DMGAggJAQUBBwEQFiCPeBqDMYc7jAs3kUUKgnicAgMfgy+KRIkBiWOCRbFNG?= =?us-ascii?q?IQ4AgQCBAUCDgEBBoElSCFpcHAVOyoBgj5QFwINjiEMDgmDToUUhUR0NwIGA?= =?us-ascii?q?QkBAQMJfIoIAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AC5l6GBXOP6X8aPIEMUQ/o5XtpwzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuflFkOHR9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Zo2a56ngZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,397,1602547200"; d="scan'208,217";a="639808342" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Feb 2021 03:18:13 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 1133IClH022342 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2021 03:18:12 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 2 Feb 2021 21:18:12 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 2 Feb 2021 21:18:12 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 2 Feb 2021 21:18:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l4Fe3KwawKzjGznRD0X8gR9YxKnDUKyF2Bn1fRFaKct5ml8Jqz4inhZhXe9pahPJNPJP8DiDzvwB2TBYYnx7pq9TWA0qcHOk5hMAZpeg9aWFe8GbcC6uy/Gh2y6VjkYCvLFBNISLFzL0w1qR/vvGZZck0Gu1gGVWfA4YuZ68APnghCxRtnYIMcL///gd0UVGig8OJMdwJ5XP/k6lLxOhjMsK0V3r7DjBAQasw42EkI6sifwum6qIImQOZ8S9GFAiNdZunIumytuWotZX+qMyH1sqO87I1+5XUTvp7yi4aYkPgOUKrxzAH10H6TeLL33B+1KNPADgBTbCYrQn3D/w4A== 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=uCpMzHQAqfEqkCuX2VNNUmJSqLWNyQC6uV03SjJGVKA=; b=kvdUDhQziCPLR0O3RTfzdJ9hDgiojQRV4hhECxBwCxQ4oDYrhivOvXepACuIekevceuKUu6OSPFVT2mIDLAtFrbpI+NuP67MtKYgjQZ0paTc4nocFQd+do7bHFFXDBdJLlSx6ZCrrTxNPLWod2TzkyWx4TsE68EmRTTkprIFruQK0L4eTDUCI32FWI9DR2yYq2OTJFkQ4ux7d5Mn6Oe9b8e1uTAxuG6pHeQQfnadw2vYLiZr8ehCCW+FvS1a4vSglFSRQ8bjrDETy98bQSSciKkZtgoluE/B6AZLEdkEnkNyyL8f3nXxxTvCutrkaLzr6wFnJTpaeU72O9lakewUzg== 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=uCpMzHQAqfEqkCuX2VNNUmJSqLWNyQC6uV03SjJGVKA=; b=M/EXIBYNozq/WFaDBXe4ge3CRvCsgeAdsqiCzhTjNDYWiA9YLKnJt2udwlGfvqaLe80TzIwQqUGOG4WOx0GI0LVBzBacRs7KlJBUsxSTs9h/P0Vm1L4a9g5lw+Guuou2+xQB+njpKV4ZVzzakEwXO+0ONMySPdjn/wa5DbSWP9g= Received: from BY5PR11MB4273.namprd11.prod.outlook.com (2603:10b6:a03:1c9::32) by BYAPR11MB2919.namprd11.prod.outlook.com (2603:10b6:a03:8d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.23; Wed, 3 Feb 2021 03:18:10 +0000 Received: from BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::dd55:1bb2:7950:3e38]) by BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::dd55:1bb2:7950:3e38%7]) with mapi id 15.20.3805.027; Wed, 3 Feb 2021 03:18:10 +0000 From: "Alberto Rodriguez-Natal (natal)" To: Eliot Lear CC: "mohamed.boucadair@orange.com" , "lisp-chairs@ietf.org" , "lisp@ietf.org list" Thread-Topic: [lisp] WG Last Call for draft-ietf-lisp-pubsub Thread-Index: AQHW6XyUWyGmycXAq0y5pziP6Yb8G6otY+wAgAAKZQCAAAIvgIAADwoAgAFxKgCAFmybgA== Date: Wed, 3 Feb 2021 03:18:10 +0000 Message-ID: <2DED786D-9FE8-45A9-9C51-E726B69D2FE8@cisco.com> References: <26AD53D1-BF1A-4812-98C6-B092C85409C3@cisco.com> <15144_1610977729_600591C1_15144_61_25_787AE7BB302AE849A7480A190F8B9330315BC1F4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9055BFF5-BAA6-4796-B42A-779F12B47D06@cisco.com> <1976_1610981428_6005A034_1976_310_5_787AE7BB302AE849A7480A190F8B9330315BC2EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63D309EF-96FB-4053-8A80-75A1AFCE4ADD@cisco.com> In-Reply-To: <63D309EF-96FB-4053-8A80-75A1AFCE4ADD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.5.88.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba8699b5-a872-4f4c-6c05-08d8c7f25562 x-ms-traffictypediagnostic: BYAPR11MB2919: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SoATEMJi6EMbAD5ora1HrBWnxaoF1LJxHHFzD9vA3yamfDwE4SNbWBdvY8RznYfSerjvMu0veCLKUECNe76x4cUD33LNUDqOjnMaX7oNDYla6pg6m0PZz3HEnAHdhQtZFZJTCSASZMTB92FmUqPBCQzdIFt5UTt9TkmcWEc9g0BYWWDy4AKrslAhmSkZJcPeALl9GwsNmBE/W5S+x9q8QwrOb2Y41XtCkAbRhtN5blK3+KvLlRxbeTftKPvCii3AlrHT/dX7ofFPWmnyUnGAKKLq/m0LgvdRlMGMqeAAYro/GQ5/3jRmZ11Tzp+q67rxsP0MB3LYknx6+B0e2vTX19iYD/bag9vjpEmeSRF5g3H/cessXNXCunrc1V7f1RxdHBQmJ66GGVmiz72TZN5hIF8mgJKr42zP4N0vG+EPiKmECczjW4FlYDRx5TSYms0F9Z3ELw3VZ7QlE0Ll5GYEEP1vOoaJ3xvKtGluyjeMkJu98DJIGZjoas78uDmOaRXAreTRHaF0y8/B9HnhjKkgIG79dv1rsIj7h8fPk4QY5ex6Rn+RH1uqnxuEu93/CRao0W7oUhfNeLrY16DCgv0O5Nre0u+0/g2XcKH6Gexh9Q3z8tMMcqYSu6EzGDmTQBPzfs7Wz4rfK+Ly1/TXsNUG9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4273.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(39860400002)(366004)(396003)(346002)(316002)(53546011)(8676002)(71200400001)(54906003)(6506007)(2906002)(37006003)(6862004)(166002)(186003)(4326008)(26005)(5660300002)(83380400001)(8936002)(76116006)(66946007)(66556008)(66476007)(6512007)(36756003)(6486002)(966005)(2616005)(33656002)(66446008)(86362001)(6636002)(478600001)(64756008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WFM0ZXNBa011MkJqVzl5N2VhNDk1dm5lQUlZcTgxaE1HdlRqNWFxWWI4R2FJ?= =?utf-8?B?Vm8wTWpVM0FmQVZZck0ybG0xdldMTWhCL3d4WGUzOFl6bU9DNkJwYXlXVnZo?= =?utf-8?B?blgvT1kzTFozWHVDQWFQRTRjRWY3bWxxb1lxUU1uSU13QUsycHQ3ZEhBUnJx?= =?utf-8?B?dnlmbUhFZ09zYkdpc1p6ZFJTZmc1UkZhVHhaQ2JrZDBINmNkYVJRUFpHeW16?= =?utf-8?B?Wkk3U00vNDlhV2dzTW1aZ2YxWEE4R3FXTHlhYlRVT2ZVZ1pOT3UxYkhyeVI4?= =?utf-8?B?ell4eUZiLzNVbzZPMVhQbDlKZTRhRGtrSWRoVTlBVHFKLzB5a2lVMVFJK0s3?= =?utf-8?B?L2tYL3cydWRyOTB0SGtMNUduRHBaWE42WGRZdHB4aUVKYUNJZ0JwTEhubUND?= =?utf-8?B?bGc1WnRJbWlma0c2TTZFRkhxOWt2V0gxWDkzN2hDQUxVZXdiTU1od0NyRTkw?= =?utf-8?B?SWswaEJzd1d5VVAxSnJhV0I2MVg3M2s1cVpuNEc0M1pDYTdEbFR5T2JqRFcw?= =?utf-8?B?NzliTGUzOGxNNlpKRXdVM3d2U3FGdnZsZFhscm1SdVJBUGVLOHRDUXM4Y3Bh?= =?utf-8?B?MDlVSzNkQ1Q5ZzRZWUErV1ZqWGRTblVPaTkxbG5ucEI5c2xETW5Ga0tFanNB?= =?utf-8?B?ZmlXVzZQQ3hkRytxeXpWS29RRnZENFBRNmVwN29vV2JZQ0lLc05MZHRyRUJ2?= =?utf-8?B?bVdIb0VGQ2dsemJVVEJiRk9mQU41Q0dDM2pXWmovSGxxQUVFUlQ5UjczYUg1?= =?utf-8?B?NmtvVkF5a3hzMEdXaUoxbS9POFlQK3Y3RTVDbmJaSHdxbkVLVFVwdHlJcjQ5?= =?utf-8?B?SHZINk9kM2c2NFFnYnZab2VuQVV2V0FHdjQ3STREV1dGN3ptQm81L3U1dmFF?= =?utf-8?B?aG0zdGVZSU01WUpjVUl0ZnNCZU1WN2o2aDhjSFVCL0EwSytJRTRMSGQ1T0tZ?= =?utf-8?B?TkEwdWtpQVNWclBncnVjVTI5NHI5U3RsMk5UWGZ4Sk0yVkw3ZmdIaFlrVWhk?= =?utf-8?B?dEVpdmtwUC9JaHFKdk95VnNnTHE0WmZONUszWU1CczBxRWxndklMajFGMTRZ?= =?utf-8?B?VFdVZnhSTlFFVHNoV0ZjVHdPbFM4UTIvdkNqMFd1K28wc3dRN1NWYXJJYlNx?= =?utf-8?B?NVJ6cnhwd0dpenBtRG0yQmMwMW40YlE1cHRhd2YwaEZRdnVHVTFNUm1naHhX?= =?utf-8?B?YmhLUTJ5aXlHQ01DM0R0MFpYNitHenZOODBqUGhraG9HL1VCNi8zcTdXTmZV?= =?utf-8?B?MktOR1NTMGtUTm5ISnRPM0hWU0tWbkEwdkhQSWU0b0R1MnRWOEIydEl2ZzJ5?= =?utf-8?B?d2k4cXVxTlFyWTFlVmpEcnJrOXRzYW9Xd1Z4Mk1EakExTEFrMUI1RExudGdE?= =?utf-8?B?R3M2cWlUUWZXS0F2bm53cWJtYVRlZUg4VUVqUUtkMGo3bUhzRUhPcEpZYWYv?= =?utf-8?Q?gClpBnRy?= Content-Type: multipart/alternative; boundary="_000_2DED786D9FE845A99C51E726B69D2FE8ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4273.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba8699b5-a872-4f4c-6c05-08d8c7f25562 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2021 03:18:10.0592 (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: BDn4NYqyOHPSuVnJKoa8TX8skRUGfqaFbMHt6DxNTb41NTlQCeoh/iZSdRGkAGeW X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2919 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 03:18:29 -0000 --_000_2DED786D9FE845A99C51E726B69D2FE8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmV3IHZlcnNpb24gaXMgdXAgbm93Lg0KDQpBbGJlcnRvDQoNCkZyb206ICJBbGJlcnRvIFJvZHJp Z3Vlei1OYXRhbCAobmF0YWwpIiA8bmF0YWxAY2lzY28uY29tPg0KRGF0ZTogVHVlc2RheSwgSmFu dWFyeSAxOSwgMjAyMSBhdCAxMjo1MSBQTQ0KVG86IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29t Pg0KQ2M6ICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4sICJsaXNwLWNoYWlyc0BpZXRmLm9yZyIgPGxpc3AtY2hhaXJzQGlldGYub3Jn PiwgImxpc3BAaWV0Zi5vcmcgbGlzdCIgPGxpc3BAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xp c3BdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1saXNwLXB1YnN1Yg0KDQpIaSBFbGlvdCwN Cg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2shIEFzIE1lZCBtZW50aW9uZWQgd2UgaGF2ZSBtYWRl IGEgc21hbGwgY2xhcmlmeWluZyBlZGl0IGluIHRoZSB0ZXh0LiBQbGVhc2UgZmluZCB0aGUgZGlm ZiBhdHRhY2hlZC4NCg0KSeKAmWxsIHdhaXQgYSBiaXQgYmVmb3JlIHNlbmRpbmcgdGhlIG5ldyB2 ZXJzaW9uIGluIGNhc2UgdGhlcmUgYXJlIG90aGVyIHNtYWxsIGNoYW5nZXMgdG8gbWFrZSBkdXJp bmcgdGhlIFdHTEMgcHJvY2Vzcy4NCg0KVGhhbmtzIQ0KQWxiZXJ0bw0KDQpGcm9tOiBsaXNwIDxs aXNwLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAibW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpEYXRlOiBNb25kYXksIEph bnVhcnkgMTgsIDIwMjEgYXQgNjo1MSBBTQ0KVG86IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29t Pg0KQ2M6ICJsaXNwLWNoYWlyc0BpZXRmLm9yZyIgPGxpc3AtY2hhaXJzQGlldGYub3JnPiwgImxp c3BAaWV0Zi5vcmcgbGlzdCIgPGxpc3BAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xpc3BdIFdH IExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1saXNwLXB1YnN1Yg0KDQpSZS0sDQoNClBsZWFzZSBz ZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBFbGlvdCBMZWFyIFttYWlsdG86bGVh ckBjaXNjby5jb21dDQpFbnZvecOpIDogbHVuZGkgMTggamFudmllciAyMDIxIDE0OjU3DQrDgCA6 IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ DQpDYyA6IEx1aWdpIElhbm5vbmUgPGdneEBnaWdpeC5uZXQ+OyBsaXNwLWNoYWlyc0BpZXRmLm9y ZzsgbGlzcEBpZXRmLm9yZyBsaXN0IDxsaXNwQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW2xpc3Bd IFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1saXNwLXB1YnN1Yg0KDQpIaSBNZWQsDQoNCk9r LCBJIG1pc3JlYWQgdGhhdCB0ZXh0IGFzIHRoZSBwcm9jZXNzaW5nIG9mIGFuIGVycm9yIGNvbmRp dGlvbi4NCg0KW01lZF0gV2Ugd2lsbCBjb25zaWRlciB0d2Vha2luZyB0aGF0IHRleHQgZm9yIGJl dHRlciBjbGFyaXR5Lg0KDQogVGhpcyByYWlzZXMgYSBmZXcgcXVlc3Rpb25zOg0KDQpXaGF0IGhh cHBlbnMgaWYgYW4geFRSIHdhbnRzIHRvICphZGQqIHN1YnNjcmlwdGlvbnM/ICBEbyB0aGV5IGp1 c3QgZG8gYW5vdGhlciBtYXAgcmVxdWVzdCB3aXRoIHRoZSBOIGJpdCBzZXQgb24gbmV3IEVJRHM/ DQoNCltNZWRdIFllcy4NCg0KSWYgdGhhdCBzYW1lIHJlcXVlc3QgY29udGFpbnMgRUlEcyB0aGF0 IGhhZCBwcmV2aW91c2x5IGhhZCB0aGUgTiBiaXQgc2V0IGJ1dCBubyBsb25nZXIgZG8/IERvZXMg dGhlIEVUUiBqdXN0IHByb2Nlc3MgaXQgYXMgaXQgd291bGQgaGF2ZSBwcmV2aW91c2x5IGFuZCBr ZWVwIHNlbmRpbmcgbWFwIHVwZGF0ZXMgZm9yIHRob3NlIEVJRHMgb3IgaXMgdGhhdCBhbiBlcnJv cj8NCg0KW01lZF0gRUlEcyB3aXRoIE4tYml0IHVuc2V0IHdpbGwgYmUgaGFuZGxlZCBhcyBwZXIg dGhlIGJhc2UgTElTUCBzcGVjLiBHaXZlbiB0aGF0IHRoZXNlIEVJRHMgdXNlZCB0byBoYXZlIE4t Yml0IHNldCwgdXBkYXRlcyB3aWxsIHN0aWxsIGJlIG5vdGlmaWVkIHRpbGwgdGhlIFRUTCBleHBp cmVzIGZvciB0aGVzZSBFSURzIGFuZCB0aGVuOg0KDQogICBXaGVuIHRoZSBUVEwgZm9yIHRoZSBF SUQtcmVjb3JkDQogICBleHBpcmVzLCB0aGUgRUlELXByZWZpeCBpcyByZW1vdmVkIGZyb20gdGhl IE1hcC1TZXJ2ZXIncyBzdWJzY3JpcHRpb24NCiAgIGNhY2hlLiAgT24gRUlELVJlY29yZCByZW1v dmFsLCB0aGUgTWFwLVNlcnZlciBub3RpZmllcyB0aGUNCiAgIHN1YnNjcmliZXJzIHZpYSBhIE1h cC1Ob3RpZnkgd2l0aCBUVEwgZXF1YWwgMC4NCkVsaW90DQoNCg0KDQoNCk9uIDE4IEphbiAyMDIx LCBhdCAxNDo0OCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCkhpIEVsaW90LCBhbGwsDQoNClRoZSBwcm9j ZWR1cmUgdG8gdW5zdWJzY3JpYmUgaXMgY292ZXJlZCBieSB0aGUgZm9sbG93aW5nOg0KDQogICBJ ZiB0aGUgTWFwLVJlcXVlc3Qgb25seSBoYXMgb25lIElUUi1STE9DIHdpdGggQUZJID0gMCAoaS5l LiwgVW5rbm93bg0KICAgQWRkcmVzcyksIHRoZSBNYXAtU2VydmVyIE1VU1QgcmVtb3ZlIHRoZSBz dWJzY3JpcHRpb24gc3RhdGUgZm9yIHRoYXQNCiAgIHhUUi1JRC4NCg0KV2UgZGlzY3Vzc2VkIGFt b25nIHRoZSBhdXRob3JzIGJhY2sgaW4gMjAxNyB3aGV0aGVyIHRoZSBwcm9jZWR1cmUgc2hvdWxk IGFsbG93IHRvIHNlbGVjdCB0aGUgRUlEcyBmb3Igd2hpY2ggYW4gSVRSIGNhbiB1bnN1YnNjcmli ZSwgYnV0IHRoZSBhZ3JlZW1lbnQgd2FzIHRvIGtlZXAgdGhlIHNwZWMgc2ltcGxlLiBIZW5jZSB0 aGUgYWJvdmUgdGV4dC4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogbGlzcCBbbWFpbHRvOmxpc3At Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBFbGlvdCBMZWFyDQpFbnZvecOpIDogbHVu ZGkgMTggamFudmllciAyMDIxIDE0OjEyDQrDgCA6IEx1aWdpIElhbm5vbmUgPGdneEBnaWdpeC5u ZXQ8bWFpbHRvOmdneEBnaWdpeC5uZXQ+Pg0KQ2MgOiBsaXNwLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86bGlzcC1jaGFpcnNAaWV0Zi5vcmc+OyBsaXNwQGlldGYub3JnPG1haWx0bzpsaXNwQGlldGYu b3JnPiBsaXN0IDxsaXNwQGlldGYub3JnPG1haWx0bzpsaXNwQGlldGYub3JnPj4NCk9iamV0IDog UmU6IFtsaXNwXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbGlzcC1wdWJzdWINCg0KSnVz dCBwb2tpbmcgbXkgbm9zZSBpbiBoZXJlLCB0aGlzIGlzIGEgY29vbCBkcmFmdC4gSSBzYXksIGdv IGZvciBpdC4gIERlcGVuZGluZyBvbiBpbXBsZW1lbnRhdGlvbiwgaXQgbWF5IGFkZHJlc3MgdGhl IHZlcnkgcHJvYmxlbSBJIHdhcyBhdHRlbXB0aW5nIHRvIHNvbHZlIHdpdGggTkVSRDogdGhhdCBm aXJzdCBkcm9wcGVkIHBhY2tldC4NCg0KSSBoYXZlIG9uZSBzbWFsbCBzdWdnZXN0aW9uIGFuZCBh IHF1ZXN0aW9uOg0KDQpUaGUgc3VnZ2VzdGlvbjoNCg0KSXQgd291bGQgYmUgdXNlZnVsIHRvIGRp c2N1c3Mgd2hhdCBzdGF0aXN0aWNzIHNob3VsZCBiZSBrZXB0IHdoZW4gZXhwZXJpbWVudGluZy4g IFNwZWNpZmljYWxseTogbnVtYmVyIG9mIHN1YnNjcmliZXMgKHByaW9yIHRvIG9yIGFmdGVyIHRo ZSBmaXJzdCB0aW1lIG9uZSBzYXcgYW4gRUlEKSwgdGhlIG51bWJlciBvZiBtYXAgdXBkYXRlcyBv dmVyIHRpbWUgKEnigJltIGJldHRpbmcgdGhlcmXigJlzIGEgbG90IG9mIHN0YWJpbGl0eSBvdXQg dGhlcmUsIGJ1dCB0aGF04oCZcyBqdXN0IG1lKSwgbnVtYmVyIG9mIHN1YnNjcmliZXJzLg0KDQpU aGUgcXVlc3Rpb246DQoNCkhvdyB3b3VsZCBhbiB4VFIgVU5zdWJzY3JpYmUgZnJvbSBtYXBwaW5n IG5vdGlmaWNhdGlvbnM/ICBJIHdvdWxkIGltYWdpbmUgdGhpcyB3b3VsZCBhbW91bnQgdG8gYSBu ZXcgbWFwIHJlcXVlc3QgdGhhdCBjbGVhcnMgdGhlIE4gYml0IGZvciBhcHByb3ByaWF0ZSBFSUQt UmVjb3Jkcz8NCg0KRWxpb3QNCg0KDQoNCg0KDQoNCg0KT24gMTMgSmFuIDIwMjEsIGF0IDA4OjE5 LCBMdWlnaSBJYW5ub25lIDxnZ3hAZ2lnaXgubmV0PG1haWx0bzpnZ3hAZ2lnaXgubmV0Pj4gd3Jv dGU6DQoNCkhpIEFsbCwNCg0KVGhlIGF1dGhvcnMgb2YgIGRyYWZ0LWlldGYtbGlzcC1wdWJzdWIg c3VibWl0dGVkIGEgbmV3IHZlcnNpb24gYWRkcmVzc2luZyB0aGUgaXNzdWVzIHJhaXNlZCBkdXJp bmcgU0VDRElSIHJldmlldy4NClRoZSBkb2N1bWVudCBzZWVtcyBtYXR1cmUgYW5kIHN0YWJsZSBh bmQgYXV0aG9ycyBhcmUgYXNraW5nIGZvciBmb3JtYWwgV0cgTGFzdCBDYWxsLg0KDQpUaGlzIGVt YWlsIG9wZW4gdGhlIHVzdWFsIHR3byB3ZWVrcyBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCwgdG8g ZW5kIEphbnVhcnkgMjh0aCwgMjAyMS4NCg0KUGxlYXNlIHJldmlldyB0aGlzIFdHIGRvY3VtZW50 IGFuZCBsZXQgdGhlIFdHIGtub3cgaWYgeW91IGFncmVlIHRoYXQgaXQgaXMgcmVhZHkgdG8gYmUg aGFuZGVkIG92ZXIgdG8gdGhlIEFELg0KSWYgeW91IGhhdmUgb2JqZWN0aW9ucywgcGxlYXNlIHN0 YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBh ZGRyZXNzIHlvdXIgY29uY2VybnMuDQoNCk5PVEU6IHNpbGVuY2UgSVMgTk9UIGNvbnNlbnN1cyEN Cg0KVGhhbmtzDQoNCkx1aWdpICYgSm9lbA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBsaXN0DQpsaXNwQGlldGYub3JnPG1haWx0 bzpsaXNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s aXNwDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQo= --_000_2DED786D9FE845A99C51E726B69D2FE8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+TmV3IHZlcnNpb24gaXMgdXAgbm93LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5B bGJlcnRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtBbGJl cnRvIFJvZHJpZ3Vlei1OYXRhbCAobmF0YWwpJnF1b3Q7ICZsdDtuYXRhbEBjaXNjby5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEphbnVhcnkgMTksIDIwMjEgYXQgMTI6NTEgUE08 YnI+DQo8Yj5UbzogPC9iPkVsaW90IExlYXIgJmx0O2xlYXJAY2lzY28uY29tJmd0Ozxicj4NCjxi PkNjOiA8L2I+JnF1b3Q7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZxdW90OyAmbHQ7bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDssICZxdW90O2xpc3AtY2hhaXJzQGlldGYub3Jn JnF1b3Q7ICZsdDtsaXNwLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O2xpc3BAaWV0Zi5vcmcg bGlzdCZxdW90OyAmbHQ7bGlzcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtsaXNwXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbGlzcC1wdWJzdWI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEVsaW90LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSBmZWVkYmFjayEgQXMgTWVkIG1lbnRpb25lZCB3ZSBo YXZlIG1hZGUgYSBzbWFsbCBjbGFyaWZ5aW5nIGVkaXQgaW4gdGhlIHRleHQuIFBsZWFzZSBmaW5k IHRoZSBkaWZmIGF0dGFjaGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J4oCZbGwgd2FpdCBhIGJpdCBiZWZv cmUgc2VuZGluZyB0aGUgbmV3IHZlcnNpb24gaW4gY2FzZSB0aGVyZSBhcmUgb3RoZXIgc21hbGwg Y2hhbmdlcyB0byBtYWtlIGR1cmluZyB0aGUgV0dMQyBwcm9jZXNzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aGFua3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5BbGJlcnRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5saXNwICZsdDtsaXNwLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJnF1b3Q7ICZsdDttb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkgMTgsIDIwMjEg YXQgNjo1MSBBTTxicj4NCjxiPlRvOiA8L2I+RWxpb3QgTGVhciAmbHQ7bGVhckBjaXNjby5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtsaXNwLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7 bGlzcC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtsaXNwQGlldGYub3JnIGxpc3QmcXVvdDsg Jmx0O2xpc3BAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbGlzcF0gV0cg TGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLWxpc3AtcHVic3ViPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5D aGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5j b21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTggamFudmllciAyMDIxIDE0 OjU3PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOICZsdDtt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gTHVp Z2kgSWFubm9uZSAmbHQ7Z2d4QGdpZ2l4Lm5ldCZndDs7IGxpc3AtY2hhaXJzQGlldGYub3JnOyBs aXNwQGlldGYub3JnIGxpc3QgJmx0O2xpc3BAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+T2JqZXQmbmJz cDs6PC9iPiBSZTogW2xpc3BdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1saXNwLXB1YnN1 Yjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1lZCw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rLCBJIG1pc3Jl YWQgdGhhdCB0ZXh0IGFzIHRoZSBwcm9jZXNzaW5nIG9mIGFuIGVycm9yIGNvbmRpdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+W01lZF0gV2Ugd2lsbCBjb25zaWRlciB0d2Vha2luZyB0aGF0IHRleHQg Zm9yIGJldHRlciBjbGFyaXR5Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1RoaXMgcmFpc2VzIGEgZmV3IHF1ZXN0aW9u czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hhdCBoYXBwZW5zIGlmIGFuIHhUUiB3YW50cyB0byAqYWRkKiBzdWJzY3JpcHRpb25zPyAmbmJz cDtEbyB0aGV5IGp1c3QgZG8gYW5vdGhlciBtYXAgcmVxdWVzdCB3aXRoIHRoZSBOIGJpdCBzZXQg b24gbmV3IEVJRHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFllcy4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhhdCBz YW1lIHJlcXVlc3QgY29udGFpbnMgRUlEcyB0aGF0IGhhZCBwcmV2aW91c2x5IGhhZCB0aGUgTiBi aXQgc2V0IGJ1dCBubyBsb25nZXIgZG8/IERvZXMgdGhlIEVUUiBqdXN0IHByb2Nlc3MgaXQgYXMg aXQgd291bGQgaGF2ZSBwcmV2aW91c2x5IGFuZCBrZWVwIHNlbmRpbmcgbWFwIHVwZGF0ZXMgZm9y IHRob3NlIEVJRHMgb3IgaXMgdGhhdCBhbiBlcnJvcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g RUlEcyB3aXRoIE4tYml0IHVuc2V0IHdpbGwgYmUgaGFuZGxlZCBhcyBwZXIgdGhlIGJhc2UgTElT UCBzcGVjLiBHaXZlbiB0aGF0IHRoZXNlIEVJRHMgdXNlZCB0byBoYXZlIE4tYml0IHNldCwgdXBk YXRlcyB3aWxsIHN0aWxsIGJlIG5vdGlmaWVkIHRpbGwgdGhlIFRUTCBleHBpcmVzDQogZm9yIHRo ZXNlIEVJRHMgYW5kIHRoZW46PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hlbiB0aGUgVFRM IGZvciB0aGUgRUlELXJlY29yZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZXhwaXJlcywgdGhlIEVJRC1wcmVmaXggaXMg cmVtb3ZlZCBmcm9tIHRoZSBNYXAtU2VydmVyJ3Mgc3Vic2NyaXB0aW9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjYWNo ZS4mbmJzcDsgT24gRUlELVJlY29yZCByZW1vdmFsLCB0aGUgTWFwLVNlcnZlciBub3RpZmllcyB0 aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHN1YnNjcmliZXJzIHZpYSBhIE1hcC1Ob3RpZnkgd2l0aCBUVEwgZXF1YWwg MC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5FbGlvdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTggSmFuIDIwMjEsIGF0IDE0OjQ4LCA8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IaSBFbGlvdCwgYWxsLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+VGhlIHByb2NlZHVyZSB0byB1bnN1YnNjcmliZSBpcyBjb3ZlcmVkIGJ5 IHRoZSBmb2xsb3dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgSWYgdGhlIE1hcC1SZXF1ZXN0IG9ubHkgaGFzIG9uZSBJVFItUkxPQyB3aXRoIEFGSSA9IDAg KGkuZS4sIFVua25vd248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFkZHJlc3MpLCB0aGUgTWFw LVNlcnZlciBNVVNUIHJlbW92ZSB0aGUgc3Vic2NyaXB0aW9uIHN0YXRlIGZvciB0aGF0PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj54VFItSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZSBkaXNj dXNzZWQgYW1vbmcgdGhlIGF1dGhvcnMgYmFjayBpbiAyMDE3IHdoZXRoZXI8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aGUg cHJvY2VkdXJlIHNob3VsZA0KIGFsbG93IHRvIHNlbGVjdCB0aGUgRUlEcyBmb3Igd2hpY2ggYW4g SVRSIGNhbiB1bnN1YnNjcmliZSwgYnV0IHRoZSBhZ3JlZW1lbnQgd2FzIHRvIGtlZXAgdGhlIHNw ZWMgc2ltcGxlLiBIZW5jZSB0aGUgYWJvdmUgdGV4dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPmxpc3ANCiBbPGEgaHJlZj0ibWFpbHRvOmxpc3AtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmxpc3AtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPkRlIGxhIHBhcnQgZGU8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkVsaW90IExlYXI8YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+bHVuZGkgMTggamFudmllciAyMDIxIDE0OjEyPGJyPg0KPGI+w4AmbmJzcDs6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5MdWln aSBJYW5ub25lICZsdDs8YSBocmVmPSJtYWlsdG86Z2d4QGdpZ2l4Lm5ldCI+Z2d4QGdpZ2l4Lm5l dDwvYT4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bGlzcC1jaGFpcnNAaWV0Zi5v cmciPmxpc3AtY2hhaXJzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYu b3JnIj5saXNwQGlldGYub3JnPC9hPiBsaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86bGlzcEBpZXRm Lm9yZyI+bGlzcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW2xpc3BdIFdH IExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1saXNwLXB1YnN1Yjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SnVzdCBwb2tpbmcgbXkgbm9zZSBpbiBoZXJlLCB0aGlzIGlzIGEgY29v bCBkcmFmdC4gSSBzYXksIGdvIGZvciBpdC4gJm5ic3A7RGVwZW5kaW5nIG9uIGltcGxlbWVudGF0 aW9uLCBpdCBtYXkgYWRkcmVzcyB0aGUgdmVyeSBwcm9ibGVtIEkgd2FzIGF0dGVtcHRpbmcgdG8g c29sdmUgd2l0aCBORVJEOiB0aGF0IGZpcnN0IGRyb3BwZWQgcGFja2V0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBoYXZlIG9uZSBzbWFsbCBzdWdnZXN0aW9uIGFuZCBhIHF1ZXN0aW9uOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3VnZ2VzdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgd291bGQgYmUgdXNlZnVsIHRvIGRpc2N1c3Mgd2hhdCBzdGF0aXN0aWNzIHNob3Vs ZCBiZSBrZXB0IHdoZW4gZXhwZXJpbWVudGluZy4gJm5ic3A7U3BlY2lmaWNhbGx5OiBudW1iZXIg b2Ygc3Vic2NyaWJlcyAocHJpb3IgdG8gb3IgYWZ0ZXIgdGhlIGZpcnN0IHRpbWUgb25lIHNhdyBh biBFSUQpLCB0aGUgbnVtYmVyIG9mIG1hcCB1cGRhdGVzIG92ZXIgdGltZSAoSeKAmW0gYmV0dGlu ZyB0aGVyZeKAmXMgYSBsb3Qgb2Ygc3RhYmlsaXR5DQogb3V0IHRoZXJlLCBidXQgdGhhdOKAmXMg anVzdCBtZSksIG51bWJlciBvZiBzdWJzY3JpYmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgd291bGQgYW4g eFRSIFVOc3Vic2NyaWJlIGZyb20gbWFwcGluZyBub3RpZmljYXRpb25zPyAmbmJzcDtJIHdvdWxk IGltYWdpbmUgdGhpcyB3b3VsZCBhbW91bnQgdG8gYSBuZXcgbWFwIHJlcXVlc3QgdGhhdCBjbGVh cnMgdGhlIE4gYml0IGZvciBhcHByb3ByaWF0ZSBFSUQtUmVjb3Jkcz88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEzIEphbiAy MDIxLCBhdCAwODoxOSwgTHVpZ2kgSWFubm9uZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdneEBnaWdp eC5uZXQiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmdneEBnaWdpeC5uZXQ8L3NwYW4+PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGwsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgYXV0aG9ycyBvZiAmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDsiPmRyYWZ0LWlldGYtbGlzcC1wdWJzdWImbmJzcDtzdWJtaXR0ZWQg YSBuZXcgdmVyc2lvbiBhZGRyZXNzaW5nIHRoZSBpc3N1ZXMgcmFpc2VkIGR1cmluZyBTRUNESVIg cmV2aWV3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkb2N1bWVudCBzZWVtcyBtYXR1cmUgYW5kIHN0 YWJsZSBhbmQgYXV0aG9ycyBhcmUgYXNraW5nIGZvciBmb3JtYWwgV0cgTGFzdCBDYWxsLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWlsIG9wZW4gdGhlIHVzdWFsIHR3byB3ZWVr cyBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCwgdG8gZW5kIEphbnVhcnkgMjh0aCwgMjAyMS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcmV2aWV3IHRoaXMg V0cgZG9jdW1lbnQgYW5kIGxldCB0aGUgV0cga25vdyBpZiB5b3UgYWdyZWUgdGhhdCBpdCBpcyBy ZWFkeSB0byBiZSBoYW5kZWQgb3ZlciB0byB0aGUgQUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlv dSBoYXZlIG9iamVjdGlvbnMsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhw bGFpbiB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIGNvbmNlcm5zLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5OT1RFOiBzaWxlbmNlIElTIE5PVCBjb25zZW5zdXMhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMEFGQ0QiPjxicj4NCjwvc3Bhbj5MdWlnaSAmYW1wOyBKb2VsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmxpc3AgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxpc3BA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmxpc3BAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bGlzcCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saXNwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48 L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3By ZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3By ZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2DED786D9FE845A99C51E726B69D2FE8ciscocom_-- From nobody Wed Feb 3 07:18:38 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3A93A093D for ; Wed, 3 Feb 2021 07:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.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 0_qFcN4bizZ3 for ; Wed, 3 Feb 2021 07:18:34 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 A2C6C3A08E4 for ; Wed, 3 Feb 2021 07:18:33 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id l12so4846591wmq.2 for ; Wed, 03 Feb 2021 07:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iAagv6NWTSmIK/+JuSWzNZtuObGdFNf8PX+hUhjtpX4=; b=no4Q90rrRGSnpyoTgQwHVCHprVdIizUzR5n11yz6ElE9QkJSPijYvlof2NSdBnE7jR 8/kCxalO1V4xAog971mTcVh1ZLsez8xsYNOJVQRRgmSSltrEgF5Fex1UzUbPo2BOGar4 YhcekIpCEYMBA5Tb0QWR/5CZ3cRTnKF3AW2vVYnmT3zIWCBEf7Xa/C/aDOz8ZiCrBkFy KF0KNG6agYQ1D+WR5ql4yJPvLdFeLoLEqx3zr885ot6fwzECw4UUSyhNLuW6hKYGoi+c MK7VbOSy8ahpF1BPywqejDRugfOIB7S1pgMxopD/nD2j8pF8C2gPTIqQpdKzjMRlbYyw u14w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iAagv6NWTSmIK/+JuSWzNZtuObGdFNf8PX+hUhjtpX4=; b=Ip97imeIkiARXOutXW9vCPmWHddvRmfT7TLuoNQgSHYFvKSf8TrI5EVfvQ5qqw4wjE VH2szR8hSwtnynBRAFp203F6VWsn27a0DA/Y0x02JVfQ12hug6qma1fTFxOmTwZMfHo1 uSYwiql2/P1vbop2/avTvReGUUCOhmrushRoNkkotYCRYBuarsLtqrN4yB70Iu2dCyFQ QyDSdlP0vr2fW5uI2CLM/2eCCC5JhxbnupMteijyt6INzWPImn51y2c/4cxwR41hbDmR vUlBWJf2PkZbO3bAwE7vvrpgLFealT4YZKQrqvbiDBgKpZx3pq/aTv1lFpkdQuFuEzR/ 9lnw== X-Gm-Message-State: AOAM531nU/D2j8c0ocsrs8eYZ2pOLqoxMfDCT7jTPGImKy7WWvEXGA5m AlBdN+4gKbWc5goR/wK3QKWH7KF0KzXazg== X-Google-Smtp-Source: ABdhPJxqwnWygIzUTfDig7ihJJ0RYtUF43WhttpmmRigGHTIbPDzkX/eNC6DYaNKkxX/ztahxdOM1A== X-Received: by 2002:a1c:7409:: with SMTP id p9mr2617934wmc.95.1612365511357; Wed, 03 Feb 2021 07:18:31 -0800 (PST) Received: from ?IPv6:2a01:e0a:1ec:470:69a5:1821:fc12:2895? ([2a01:e0a:1ec:470:69a5:1821:fc12:2895]) by smtp.gmail.com with ESMTPSA id e16sm4109335wrp.24.2021.02.03.07.18.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2021 07:18:30 -0800 (PST) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3033A9A8-6DEE-4ED0-AE65-5E838716B5D9" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 3 Feb 2021 16:18:29 +0100 In-Reply-To: <2DED786D-9FE8-45A9-9C51-E726B69D2FE8@cisco.com> Cc: "lisp-chairs@ietf.org" To: "lisp@ietf.org list" References: <26AD53D1-BF1A-4812-98C6-B092C85409C3@cisco.com> <15144_1610977729_600591C1_15144_61_25_787AE7BB302AE849A7480A190F8B9330315BC1F4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9055BFF5-BAA6-4796-B42A-779F12B47D06@cisco.com> <1976_1610981428_6005A034_1976_310_5_787AE7BB302AE849A7480A190F8B9330315BC2EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63D309EF-96FB-4053-8A80-75A1AFCE4ADD@cisco.com> <2DED786D-9FE8-45A9-9C51-E726B69D2FE8@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 15:18:37 -0000 --Apple-Mail=_3033A9A8-6DEE-4ED0-AE65-5E838716B5D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Alberto, BTW the WG LC ended last week and we received several emails in support = of the document, which means that there is consensus to move the = document forward. Thanks to all those that replied and discussed the document. Ciao L. =20 > On 3 Feb 2021, at 04:18, Alberto Rodriguez-Natal (natal) = wrote: >=20 > New version is up now. > =20 > Alberto > =20 > From: "Alberto Rodriguez-Natal (natal)" > Date: Tuesday, January 19, 2021 at 12:51 PM > To: Eliot Lear > Cc: "mohamed.boucadair@orange.com" , = "lisp-chairs@ietf.org" , "lisp@ietf.org list" = > Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub > =20 > Hi Eliot, > =20 > Thanks for the feedback! As Med mentioned we have made a small = clarifying edit in the text. Please find the diff attached. > =20 > I=E2=80=99ll wait a bit before sending the new version in case there = are other small changes to make during the WGLC process. > =20 > Thanks! > Alberto > =20 > From: lisp on behalf of = "mohamed.boucadair@orange.com" > Date: Monday, January 18, 2021 at 6:51 AM > To: Eliot Lear > Cc: "lisp-chairs@ietf.org" , "lisp@ietf.org = list" > Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub > =20 > Re-, > =20 > Please see inline. > =20 > Cheers, > Med > =20 > De : Eliot Lear [mailto:lear@cisco.com]=20 > Envoy=C3=A9 : lundi 18 janvier 2021 14:57 > =C3=80 : BOUCADAIR Mohamed TGI/OLN > Cc : Luigi Iannone ; lisp-chairs@ietf.org; = lisp@ietf.org list > Objet : Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub > =20 > Hi Med, > =20 > Ok, I misread that text as the processing of an error condition. > =20 > [Med] We will consider tweaking that text for better clarity. > =20 > This raises a few questions: > =20 > What happens if an xTR wants to *add* subscriptions? Do they just do = another map request with the N bit set on new EIDs? > =20 > [Med] Yes. > =20 > If that same request contains EIDs that had previously had the N bit = set but no longer do? Does the ETR just process it as it would have = previously and keep sending map updates for those EIDs or is that an = error? > =20 > [Med] EIDs with N-bit unset will be handled as per the base LISP spec. = Given that these EIDs used to have N-bit set, updates will still be = notified till the TTL expires for these EIDs and then: > =20 > When the TTL for the EID-record > expires, the EID-prefix is removed from the Map-Server's = subscription > cache. On EID-Record removal, the Map-Server notifies the > subscribers via a Map-Notify with TTL equal 0. > Eliot >=20 >=20 >=20 >=20 >> On 18 Jan 2021, at 14:48, mohamed.boucadair@orange.com = wrote: >> =20 >> Hi Eliot, all, >> =20 >> The procedure to unsubscribe is covered by the following: >> =20 >> If the Map-Request only has one ITR-RLOC with AFI =3D 0 (i.e., = Unknown >> Address), the Map-Server MUST remove the subscription state for = that >> xTR-ID. >> =20 >> We discussed among the authors back in 2017 whether the procedure = should allow to select the EIDs for which an ITR can unsubscribe, but = the agreement was to keep the spec simple. Hence the above text. >> =20 >> Cheers, >> Med >> =20 >> De : lisp [mailto:lisp-bounces@ietf.org = ] De la part de Eliot Lear >> Envoy=C3=A9 : lundi 18 janvier 2021 14:12 >> =C3=80 : Luigi Iannone > >> Cc : lisp-chairs@ietf.org ; = lisp@ietf.org list > >> Objet : Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub >> =20 >> Just poking my nose in here, this is a cool draft. I say, go for it. = Depending on implementation, it may address the very problem I was = attempting to solve with NERD: that first dropped packet. >> =20 >> I have one small suggestion and a question: >> =20 >> The suggestion: >> =20 >> It would be useful to discuss what statistics should be kept when = experimenting. Specifically: number of subscribes (prior to or after = the first time one saw an EID), the number of map updates over time = (I=E2=80=99m betting there=E2=80=99s a lot of stability out there, but = that=E2=80=99s just me), number of subscribers. >> =20 >> The question: >> =20 >> How would an xTR UNsubscribe from mapping notifications? I would = imagine this would amount to a new map request that clears the N bit for = appropriate EID-Records? >> =20 >> Eliot >> =20 >> =20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 13 Jan 2021, at 08:19, Luigi Iannone > wrote: >>> =20 >>> Hi All, >>> =20 >>> The authors of draft-ietf-lisp-pubsub submitted a new version = addressing the issues raised during SECDIR review. >>> The document seems mature and stable and authors are asking for = formal WG Last Call. >>> =20 >>> This email open the usual two weeks Working Group Last Call, to end = January 28th, 2021. >>> =20 >>> Please review this WG document and let the WG know if you agree that = it is ready to be handed over to the AD. >>> If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >>> =20 >>> NOTE: silence IS NOT consensus! >>> =20 >>> Thanks >>>=20 >>> Luigi & Joel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp = >> =20 >> = __________________________________________________________________________= _______________________________________________ >> =20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >> =20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >=20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. --Apple-Mail=_3033A9A8-6DEE-4ED0-AE65-5E838716B5D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Alberto,

BTW the WG LC ended last week and we received several emails = in support of the document, which means that there is consensus to move = the document forward.

Thanks to all those that replied and discussed the = document.

Ciao

L.
 

On 3 Feb = 2021, at 04:18, Alberto Rodriguez-Natal (natal) <natal@cisco.com> = wrote:

New version is up = now.
 
Alberto
 
From: "Alberto Rodriguez-Natal (natal)" <natal@cisco.com>
Date: Tuesday, January 19, = 2021 at 12:51 PM
To: Eliot Lear <lear@cisco.com>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "lisp-chairs@ietf.org" = <lisp-chairs@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
Subject: Re: [lisp] WG Last = Call for draft-ietf-lisp-pubsub
 
Hi Eliot,
 
Thanks for the feedback! As Med mentioned we have made a = small clarifying edit in the text. Please find the diff = attached.
 
I=E2=80=99ll wait a bit = before sending the new version in case there are other small changes to = make during the WGLC process.
 
Thanks!
Alberto
 
From: lisp <lisp-bounces@ietf.org> on behalf of "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Date: Monday, January 18, = 2021 at 6:51 AM
To: Eliot Lear <lear@cisco.com>
Cc: "lisp-chairs@ietf.org" = <lisp-chairs@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
Subject: Re: [lisp] WG Last = Call for draft-ietf-lisp-pubsub
 
Re-,
 
Please see = inline.
 
Cheers,
Med
 
De : Eliot Lear [mailto:lear@cisco.com] 
Envoy=C3=A9 : lundi 18 janvier 2021 = 14:57
=C3=80 : BOUCADAIR Mohamed TGI/OLN = <mohamed.boucadair@orange.com>
Cc : Luigi Iannone <ggx@gigix.net>; lisp-chairs@ietf.org; = lisp@ietf.org list = <lisp@ietf.org>
Objet : Re: [lisp] WG Last Call for = draft-ietf-lisp-pubsub
 
Hi Med,
 
Ok, I misread that text as the processing of an error = condition.
 
[Med] We will consider = tweaking that text for better clarity.
 
 This raises a few questions:
 
What happens if an xTR wants to *add* = subscriptions?  Do they just do another map request with the N bit = set on new EIDs?
 
[Med] Yes.
 
If that same request contains EIDs that = had previously had the N bit set but no longer do? Does the ETR just = process it as it would have previously and keep sending map updates for = those EIDs or is that an error?
 
[Med] EIDs with N-bit unset will be handled as per the base = LISP spec. Given that these EIDs used to have N-bit set, updates will = still be notified till the TTL expires for these EIDs and = then:
 
   When the = TTL for the EID-record
   expires, = the EID-prefix is removed from the Map-Server's subscription
   cache.  On EID-Record removal, the = Map-Server notifies the
   = subscribers via a Map-Notify with TTL equal 0.
Eliot




On 18 Jan 2021, at 14:48, mohamed.boucadair@orange.com wrote:
 
Hi Eliot, = all,
 
The procedure to unsubscribe is covered by the = following:
 
   If the Map-Request only has one = ITR-RLOC with AFI =3D 0 (i.e., Unknown
   Address), the Map-Server MUST remove = the subscription state for that
   xTR-ID.
 
We discussed = among the authors back in 2017 whether the procedure should allow to select the EIDs for which an = ITR can unsubscribe, but the agreement was to keep the spec simple. = Hence the above text.
 
Cheers,
Med
 
De : lisp [mailto:lisp-bounces@ietf.org] De la part = de Eliot Lear
Envoy=C3=A9 : lundi 18 janvier 2021 = 14:12
=C3=80 : Luigi Iannone <ggx@gigix.net>
Cc : lisp-chairs@ietf.org; lisp@ietf.org list <lisp@ietf.org>
Objet : Re: [lisp] WG Last Call for = draft-ietf-lisp-pubsub
 
Just poking my nose in = here, this is a cool draft. I say, go for it.  Depending on = implementation, it may address the very problem I was attempting to = solve with NERD: that first dropped packet.
 
I have one small suggestion and a = question:
 
The suggestion:
 
It would be useful to discuss what = statistics should be kept when experimenting.  Specifically: number = of subscribes (prior to or after the first time one saw an EID), the = number of map updates over time (I=E2=80=99m betting there=E2=80=99s a = lot of stability out there, but that=E2=80=99s just me), number of = subscribers.
 
The question:
 
How would an xTR UNsubscribe from = mapping notifications?  I would imagine this would amount to a new = map request that clears the N bit for appropriate EID-Records?
 
Eliot
 
 





On 13 Jan 2021, at 08:19, Luigi Iannone <ggx@gigix.net> wrote:
 
Hi All,
 
The authors of  draft-ietf-lisp-pubsub submitted a new version = addressing the issues raised during SECDIR review.
The document seems mature and stable and = authors are asking for formal WG Last Call.
 
This email open the usual two weeks = Working Group Last Call, to end January 28th, 2021.
 
Please = review this WG document and let the WG know if you agree that it is = ready to be handed over to the AD.
If you have objections, = please state your reasons why, and explain what it would take to address = your concerns.
 
NOTE: silence IS NOT consensus!
 
Thanks

Luigi & Joel
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
 
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
pas =
etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange =
decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they =
should not be distributed, used or copied without authorisation.
If =
you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is =
not liable for messages that have been modified, changed or =
falsified.
Thank you.
 
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
pas =
etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange =
decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they =
should not be distributed, used or copied without authorisation.
If =
you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is =
not liable for messages that have been modified, changed or =
falsified.
Thank you.

= --Apple-Mail=_3033A9A8-6DEE-4ED0-AE65-5E838716B5D9-- From nobody Wed Feb 3 07:25:26 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4013A098D for ; Wed, 3 Feb 2021 07:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.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 UwCmKAjGqAVi for ; Wed, 3 Feb 2021 07:25:23 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 744CD3A0990 for ; Wed, 3 Feb 2021 07:25:23 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id z6so24756097wrq.10 for ; Wed, 03 Feb 2021 07:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=9oH7T0f+4jkEvCqGT4UiqUERYPB+UwSP0DtOL7GWdcI=; b=pfzBkT+6OAhZvb1ZhCSgyn106pNO/iD67wisecB7oeKHXB8BdiNuyGEmKSca4iA7W+ 7gWQjwfUwMOHFOOldtZliV5jnmUaDZX1BgdczvGu23bxM1po5FJUgeFXtxN+NnQZtEu7 ekrOo0RveZuNXO6rkrNbz2J8lYngBPBU6bG87jwgpVQmDr68JDP28VIV4FTYXaXBmxEt /tnj5ZeffGzfbXv44szRDyeHa4LdU+4gUjxmZOZ42F15EMBFeYy8ZtbDw5XjisgRcX9k W8R2djsKvZYcMqrZdt9mY6l9omDfHFoAY3kWsWm1xoTPnVm0hVctde7OONH2+w0t6v/L B7ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=9oH7T0f+4jkEvCqGT4UiqUERYPB+UwSP0DtOL7GWdcI=; b=jceouDF38QRqlcIW0CDuPb78N7RlStaVnN4Mn1txi7dpP2lWIiSiGIZKfdPUdjkPZq xkzh9d7Z/VAa6uPd3MTRaziGpLIR5uEgHORzjRcYAt4hvuE/qarPTb664wCRWQPCG4qI fiFC/Dyf91OP+vaRiMYhOFTq04nIz+4qrB9MjGh2Z07VP0PDHuKxePfWs6hr81UMCPID 3rE7QzYCffeIHlO4tu9wc9GsfNmXeWbv0G1lvnntGNwS+FcXp4gP/JyagGb+o1Gbkinc 4HgwoMV+77LNo9UP+kTd/ikPZC5+xiBjiqjRZouy4SF76X2r196X+kVjkgpO+izz3s4c ohqA== X-Gm-Message-State: AOAM5327SVUmR4SSlbCZi0yV/WHbZyw7Gp4I25obotNem+5A9Ux3rC1/ x2AzC2a35E5sQlUBWwWsCJXC453ykgoj/A== X-Google-Smtp-Source: ABdhPJzoYfBTb2yAkpywSOxDmP84q6Qj6FHy6zJuktu3xfZDbPViBrTUaaRfY7qRQnrBhEbTsDf8ng== X-Received: by 2002:a5d:6a02:: with SMTP id m2mr4154167wru.364.1612365921215; Wed, 03 Feb 2021 07:25:21 -0800 (PST) Received: from ?IPv6:2a01:e0a:1ec:470:69a5:1821:fc12:2895? ([2a01:e0a:1ec:470:69a5:1821:fc12:2895]) by smtp.gmail.com with ESMTPSA id k4sm4498504wrm.53.2021.02.03.07.25.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2021 07:25:19 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_9D2E6134-8138-4F7D-BB58-D332B31B12FD" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Wed, 3 Feb 2021 16:25:19 +0100 Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 15:25:25 -0000 --Apple-Mail=_9D2E6134-8138-4F7D-BB58-D332B31B12FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, The authors of draft-ietf-lisp-nexagon submitted the current version = back in October solving issues raised during SECDIR review. No further comments have been raised and the authors consider the = document stable and ready for WG Last Call. This email open the usual two weeks Working Group Last Call, to end = February 17th, 2021. Please review this WG document and let the WG know if you agree that it = is ready to be handed over to the AD. If you have objections, please state your reasons why, and explain what = it would take to address your concerns. NOTE: silence IS NOT consensus! Thanks Luigi & Joel= --Apple-Mail=_9D2E6134-8138-4F7D-BB58-D332B31B12FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

The= authors of  draft-ietf-lisp-nexagon = submitted the current version back in October solving issues raised = during SECDIR review.
No further comments have been raised and = the authors consider the document stable and ready for  WG Last = Call.

This email = open the usual two weeks Working Group Last Call, to end February 17th, = 2021.

Please review this WG document and let the WG know if you = agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and = explain what it would take to address your concerns.

NOTE: silence IS NOT = consensus!

Thanks

Luigi & = Joel
= --Apple-Mail=_9D2E6134-8138-4F7D-BB58-D332B31B12FD-- From nobody Wed Feb 3 09:57:31 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787D73A0CC4 for ; Wed, 3 Feb 2021 09:57:30 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=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=getnexar.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 YIAeHX_5uEFW for ; Wed, 3 Feb 2021 09:57:26 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 2ADA13A09BD for ; Wed, 3 Feb 2021 09:57:26 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id b3so239909wrj.5 for ; Wed, 03 Feb 2021 09:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=b9nE6WFkQ7qLfGgdWiMzTQaqpR/riD7xe4N4mWkZ0S8=; b=TruCeNIfnbjZ8wJDWlyO7bDBscQt8JoR6Z+13TvrNkoYm0V5w0u1lvkMPR8oBQ7lj9 LN/DICnis/iMm8JzuwChHfb5eWpPJ6EPiVWGTEnaQD7Iz4BHvTe3wSAA7e0h0fhiX1Km QtWZN4oQBAUH3YZAmy3gELSIcaxtu7+xAy8cw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=b9nE6WFkQ7qLfGgdWiMzTQaqpR/riD7xe4N4mWkZ0S8=; b=ohjCCO3pE9pUZpXruosdqtka8lX6i1i4ucA5zPDlUror1sUMwccj2NeUkeHuWRUKCW fHDZZkLv/hhwzsjyIJW0/HUNK+HXvRysAHizC+bCW6d6ZhoUKkPrAGZDHEbCzRXQHzwD vFqho/LFQSYhyrm3swxPnK5DofR+sBmZvohJDdPuvkTbSkK1ScRdgiweGuOsRW6VCbPM nnVn1Fz4tU2E4/yaEbm55vR6JF5JSvKcLhr2m8vj/vczSb8Y4NufdGdpPHHfzuHG226O CCUXx3FHjzkBJsr5xYRfDGuQST8VmgvfH51PoSC9QMdW7Oq0I1jS1CuHjpeCohk2qHD+ I0PQ== X-Gm-Message-State: AOAM532QzYVW3agy/JeB3M1sKHlh+QK58YLnNpPGoGxGhKks35fM2dfw Yvo2Rx2EgO8zmoRSChIJJ3o+8J1fIf+71ntz X-Google-Smtp-Source: ABdhPJxQkxSWSo31yTNOBWB7GyFlJFDl/H+i+ehchJ/dVudWn0FXVou5H40fhDJTaR7IWVpLd+sz/w== X-Received: by 2002:a5d:44ce:: with SMTP id z14mr4918244wrr.330.1612375044629; Wed, 03 Feb 2021 09:57:24 -0800 (PST) Received: from ?IPv6:2a02:14c:338:8200:15fd:b27e:4cce:a546? ([2a02:14c:338:8200:15fd:b27e:4cce:a546]) by smtp.gmail.com with ESMTPSA id j185sm3731640wma.1.2021.02.03.09.57.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Feb 2021 09:57:23 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E0016309-588D-4C7D-A7D8-8D5D4B2001B1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Sharon Barkai In-Reply-To: Date: Wed, 3 Feb 2021 19:57:22 +0200 Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org Message-Id: References: To: Luigi Iannone X-Mailer: iPhone Mail (18C66) Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 17:57:31 -0000 --Apple-Mail-E0016309-588D-4C7D-A7D8-8D5D4B2001B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Luigi Joel. We are working to add LISP based digital-twin interface for road segments to= the AECC auto-edge. The roll of this interface is to throttle the pipes: ca= r access to edge, edge to cloud by: 1. Recording car EID data-handles in tile EID ledgers for selective uploads p= er quota 2. Aggregating coalescing filtering uploads per tile for reduced feed to clo= ud applications This is hard to do with an IETF draft so very much appreciate show of suppor= t even though its the 2nd such poll...=20 --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 3, 2021, at 17:25, Luigi Iannone wrote: >=20 > =EF=BB=BFHi All, >=20 > The authors of draft-ietf-lisp-nexagon submitted the current version back= in October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the document= stable and ready for WG Last Call. >=20 > This email open the usual two weeks Working Group Last Call, to end Februa= ry 17th, 2021. >=20 > Please review this WG document and let the WG know if you agree that it is= ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain what it= would take to address your concerns. >=20 > NOTE: silence IS NOT consensus! >=20 > Thanks >=20 > Luigi & Joel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-E0016309-588D-4C7D-A7D8-8D5D4B2001B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Luigi Joel.

We= are working to add LISP based digital-twin interface for road segments to t= he AECC auto-edge. The roll of this interface is to throttle the pipes: car a= ccess to edge, edge to cloud by:

1. Recording car E= ID data-handles in tile EID ledgers for selective uploads per quota
2. Aggregating coalescing filtering uploads per tile for reduced feed to c= loud applications

This is hard to do with an IETF d= raft so very much appreciate show of support even though its the 2nd such po= ll... 

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

On Feb 3, 2021, at 17:25, Luigi Iannone <ggx@gigix.net> wrot= e:

=EF=BB= =BF
The auth= ors of  draft-ietf-lisp-nexagon submitted th= e current version back in October solving issues raised during SECDIR review= .
No further comments ha= ve been raised and the authors consider the document stable and ready for &n= bsp;WG Last Call.

This email open the usual two= weeks Working Group Last Call, to end February 17th, 2021.

=
Please review this WG document and let t= he WG know if you agree that it is ready to be handed over to the AD.
<= /div>
If you have objections, please state your reasons why, a= nd explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!
<= div class=3D"">
Thanks

= Luigi & Joel
___________________________________= ____________
lisp mailing list
lisp@ietf.org=
https://www.ietf.org/mailman/listinfo/lisp
=
= --Apple-Mail-E0016309-588D-4C7D-A7D8-8D5D4B2001B1-- From nobody Thu Feb 4 07:49:38 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80E3A15ED; Thu, 4 Feb 2021 07:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_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=Y1aurbyl; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=WV11Hmhf 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 haWpSocHpEjL; Thu, 4 Feb 2021 07:49:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815133A15E8; Thu, 4 Feb 2021 07:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11263; q=dns/txt; s=iport; t=1612453775; x=1613663375; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8XAdn5jNvOxqSnQgblRavIqyh6T3AkxCI9qaCBmA0cA=; b=Y1aurbyl3NfA9h4SUZeGUhB+inT+jH0bXMBalGuu2ACB/flpOj2ODsMn I3DVSKIRAD79fl7HS/mg5nWFF97leGQKIx0IPbwHbpHAsZxDe3rE9nuqq uvvjfcWa0oxHE/hv+Mv/cXJ1mn8zGvygP+7CYRmcyr77/8yyTgPYMdYVt k=; X-Files: smime.p7s : 3013 X-IPAS-Result: =?us-ascii?q?A0B1AAALFhxgmIwNJK1fAxwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?X4EAQELAYFSUX0sLjYxCgGENYNIA44MA5QmhHOBQoERA1QLAQEBCgMBARgBC?= =?us-ascii?q?goCBAEBhEoCgXwCJTcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBh?= =?us-ascii?q?jYNhXMBAQEDAQEBGwYdAQEsCwEECwIBCBgqAgICJQslAgQOBQ6DGAGCVQMOE?= =?us-ascii?q?Q8BAwulWAKKJXaBMoMFAQEGhSEYggsHAwaBOAGBUoEkg3cPhkMmG4FBP4ERJ?= =?us-ascii?q?xyBQYEVPoJdAQECgSgBEgEEHBgKDBqCUjSCLIFZEHItGgwEUyI5NlIBLqgmk?= =?us-ascii?q?UYKgnqEY4JqlDUDH4MuikaSZYJGsSeBDINyAgICAgQFAg4BAQaBJUciLD1wc?= =?us-ascii?q?BU7KgGCPj4SFwINjiEMDgmDToUUhUV0AgE0AgYBCQEBAwl8iFSBNAGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A867XtxWBhYOU0pTcv+/ayDE4/mHV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+Huf5BgvDd9aHtRWJG5oyO4zgOc51JAh?= =?us-ascii?q?kCj8he3wktG9WMBkCzKvn2Jzc7E8JPWB4AnTm7PEFZFdy4awjUpXu/vjIXEw?= =?us-ascii?q?/0cwt4OuqzHZTd3Iy70umo8MjVZANFzDO2fbJ1KkCwqgPc/skbiIdvMOA/0B?= =?us-ascii?q?zM93BJYO9Rg2hvIAGe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,401,1602547200"; d="p7s'?scan'208,217";a="681248104" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Feb 2021 15:49:34 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 114FnYJI013364 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2021 15:49:34 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Feb 2021 09:49:34 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 4 Feb 2021 09:49:34 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 4 Feb 2021 09:49:33 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NgvYXywKLYFhYMJdGS0VkkYeEPLxlgYAnFE6kFJ8XlXpCwvtm7Kti+S3bYVOIhkgmhOHGEcfzpLMcOlrT8AXOXQHvAeO8JXluHfkPy1HkaZ6iS3moWMB9fz5kay3iF2to88uzV05EqCByuac35+XQY+eXOosLZMlwRhsbQ7cPrWGDJlUWk/9ccbhLrKVHECq8/jwJFt9+7jj11Np2EnfCnZV080GDrJLvwZYn9puiU6O9JU1ytiNkPUjvoLw3XWPxo347yz3OUZUu/J/EeInAvy3J9RsElACtcMv/Q3M/MNG1+F/hHB7puBS6v/GhhGkR89TMS8oG6MYmBLV7hwduA== 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=OBdjXGEI2CrAcWnxiI8Yemyugfxt2NYGpF7FYO7iDeg=; b=R2ch/javqt2qUond/JJs5ktKXRaJHcQIEsAug99wfcHY3yzb3k5Ic1Xhlzg5gTEVMEW73w/WVbP9gjDGxmBlOWnxGwsMZSXhKpxMh2/yS2e/meB9JhYuT87Ra6RkEVzrCRD+wmTE9vU2ZkqguQd81NiDRsv0Le5ayt4rWPidfQq0E6T6m8ojZetEBmmSI89q5p9wVybwOc75wZsuMizg0jhtKmDUDYIjjrfxlrEi9pFkGqPb6j5KoXnIr2iri3jCuh7nHOaPFQ6APk8Qz4VANGILpx7StahyAjVp0/LdZNqNPtbW7yKfG3Geza0FKyvJlyuVGqfUsUKmSye2T5b98Q== 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=OBdjXGEI2CrAcWnxiI8Yemyugfxt2NYGpF7FYO7iDeg=; b=WV11HmhfUvuxeFYnvMFoWtKDUFiUlh5fkCcP15/p1fy/IYJ181Mf8dCbLSN9ln97dvmgYsG0eOUj0IcAxpUhc+4FVJKTpvHa6vOnOKDePF4Bkha4baBPN3oPVJZI2f6CNZf92YgOOaIldpgRcPXyy5qAGgVsRLdvjHj9zRrhNPc= Received: from BYAPR11MB2838.namprd11.prod.outlook.com (2603:10b6:a02:cc::33) by BYAPR11MB3557.namprd11.prod.outlook.com (2603:10b6:a03:b4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.24; Thu, 4 Feb 2021 15:49:30 +0000 Received: from BYAPR11MB2838.namprd11.prod.outlook.com ([fe80::cab:ae56:a9d0:a669]) by BYAPR11MB2838.namprd11.prod.outlook.com ([fe80::cab:ae56:a9d0:a669%4]) with mapi id 15.20.3805.027; Thu, 4 Feb 2021 15:49:30 +0000 From: "Lori Jakab (lojakab)" To: Sharon Barkai CC: Luigi Iannone , "lisp-chairs@ietf.org" , "lisp@ietf.org list" Thread-Topic: [lisp] WG Last Call for draft-ietf-lisp-nexagon Thread-Index: AQHW+kDXsjK17JCXakmtJV4EHSjdnKpGt4kAgAFulgA= Date: Thu, 4 Feb 2021 15:49:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [46.97.168.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 159fd3cf-1976-4de0-76cb-08d8c92475e2 x-ms-traffictypediagnostic: BYAPR11MB3557: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1YIA2k0xg1RS3ThK2GuViNZpG8bTRlZka35PRCkf1wVE4pnY593ml9m1BqEWorSTzV7wAZCOx/UveCtHwmbmSl+mR9pV4I67T18xrykTByUSN5y9dzEPV8711cREeLceXrqZXzkrq629BGbspkCudmXLKvF/tWUOVNNDkZ19XFpkx27B/USS2GfaxDCkh6/EfQ2UuNoaX/OEmJ0LTIWfJ5EX95aYDUqKh5tgwB6saCdxQGXDUDCXb3vUzYgo8lFF7/rHRh7Od7oLaGCkdG0EiAfGe0crayfCc3Pbat/NxAZ7NxVhPcRrdk2UZu+i5fZ/BvpccbnVi5TtAkzfXNXOd/75l8o7P/n9058LCL14lXR6wJ45+sIr9OHD/GC8+RFlNLDilmij+cq4vx2xYK6CwTsLgZNCTSlCZwn4DG3njHEC2HRdNeuQUWF850e/45lQ7GaBOT1eXbR2nJDFqzZ2bGPnrMd8J1nCcpUWL2UgJHTHWGmdfN3p2VN4ylcH4AI5DIyfcxrTVCGdFfAwEFoNJqo1wI30qzyERcOR4D/HL+1j6M1Cb4m2PDcJitwKwGt7H6d3Xor1CcMmuS5pNB+uzQ2MjFFuKhYvOse7row6VM8A7tz9/mrsj4EVWOohRTKUkQLf7wNPxQGW2wBznSGvFA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2838.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(346002)(366004)(39860400002)(66476007)(26005)(91956017)(4326008)(5660300002)(66946007)(66446008)(54906003)(76116006)(66616009)(2616005)(83380400001)(478600001)(316002)(99936003)(186003)(53546011)(33656002)(2906002)(6512007)(71200400001)(6506007)(6486002)(8936002)(64756008)(86362001)(166002)(36756003)(8676002)(66556008)(966005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q1BNVElBTmZQWHo4N2dEaERrdnJGdkhUNGZUdXlac0c4b0cvaktLeEc0Qkt0?= =?utf-8?B?aGtMczB4RWhiZ0pEdFoxNlVYNndObEpWRDlRbHZXL2hVMWdrazkrYjNnNk4y?= =?utf-8?B?TGNmeTg0dTVXODd2elZyTWljcnpseFJGNmFScU8wK1o3S2ZPYzA5V0k1aFhx?= =?utf-8?B?ZkY1R3RnZ0RoSENvTlhNT0l6UWZVY0VwSndYSzFxSERFZk1JaGk3U3RQYktM?= =?utf-8?B?c1BvbDBIZWsreFc1aUY1TXFCWThpaTFxR0ZJSXlQT0VYc2dDTEVDSkN4anhI?= =?utf-8?B?M0Q0empiOTVPT1cwZ1ZjU2ZuOFJzRHNXNStBNUxpZzk5QXh6d2ZENWZLdVAx?= =?utf-8?B?MXc0ODhBTWFKY3ZJam9DbVBxaWViVnJKK3hpQWYxSDF2RGdVOGNNM0c2K3pE?= =?utf-8?B?cjhlN3F6ZllxL054cWpteWRsZkJ1MWVCc2Fub0JGNWhHMjJvdnNvN1B4MmpW?= =?utf-8?B?aWljTWxiRmt2c1dvMm8zQmx5cDFxL1paNmtCMVZIeDF6VExnRlQ2elFsRDVy?= =?utf-8?B?SkgxWVhwYUhSRkVvVjVBY1BOTkp5eE9FZFQ4TXVqSjBPMHJiaEpXN3hmZ01m?= =?utf-8?B?VmFxMXdEY2RmQmdFVXRRRHh0SlppTkJ2citoRWZOV1RoLzlpR0U0dFNkbS9w?= =?utf-8?B?Nkg3YUVIYlJnSGdrZEVpRDJpcVRSTk1nZU5WWkhQRFh0cGs5TWlNN2hScjRh?= =?utf-8?B?cXRvSkZqK2xJNGo1RzYwRVRFTldTYkN6V05ZZUpBTTJ6MVFDT2dvWGlDaGVK?= =?utf-8?B?dEdzRTFoN1MvWTZySFFLbDlrQTloZGFsd1ZkYnovdU1GZXNRUE03UnRQOGp3?= =?utf-8?B?VjVnbFlwSlpwRVA4SUc3dEZxYWt3azJIVGhqS3kwSzYrRUN5bWVJY1Awamcw?= =?utf-8?B?NDdVRlBJVHZHTzdITUxMZjdCN08rbkhuWUpKT2cvZlo1SDNXbDRNNjl1UDRy?= =?utf-8?B?czZGem1CK0xuUGRkaDZqRklwN3c0OXI3TUFvb3RMTEUrbzdPSHVwZnVsc1cw?= =?utf-8?B?OTN6cTZCMmdvSGkrazIzdGFvZjBnVVhBbmE3ZGZYaFlrYmtwYXZBZFl2Qk5q?= =?utf-8?B?cnZsRjBQMzVVZktucC95TWdVeS9TVG42YVF6RDhuTFZ6WVpyb1N5TFk1TmxT?= =?utf-8?B?VGhxN0ZVV2VESVBYTWJWL1lTMUwyRnpWdEs2dGtzK2R0d214QkhXbm96ZVZI?= =?utf-8?B?ZzVlYXNJU3hNUVZDV2RNNjdxZ2prdmVYT0VuZTNFeWV5aWJqbHZTRmo4bjA2?= =?utf-8?B?MnF5SHpteWZvcGxXTnlCYjZDejR4MlNHcWVIMU1iajF0WFlOWm1qNkkyWVRy?= =?utf-8?B?YXJ2Sys1TjQ2ZGY2N2tnSHFMZk5SY3FDVEZWMHM0QzlmSy9yMTdOb1JiOVNI?= =?utf-8?B?aE9PMVFHMk1ibUlyQ2FseG92QjVtRURmR3I2VkwvcEs0WFFZN29Lb0FBZVl1?= =?utf-8?B?K0JBOXNHQ0ExTnFHcFgrZmdhdDFYLy92eVJZaTRBPT0=?= Content-Type: multipart/signed; boundary="Apple-Mail=_D020F5A0-8C37-403B-9125-F69E63D03F69"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2838.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 159fd3cf-1976-4de0-76cb-08d8c92475e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2021 15:49:30.5977 (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: bN/ZcbtIMQO5poevG4AHZGE3p97TTle0T+TJGAgPfqHLuePu9FevbDBwNJZfsldUq51tmoQ43jh9j3WNMv+DAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3557 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 15:49:37 -0000 --Apple-Mail=_D020F5A0-8C37-403B-9125-F69E63D03F69 Content-Type: multipart/alternative; boundary="Apple-Mail=_180B7882-C2F9-41EA-AAA0-B065C53F6C05" --Apple-Mail=_180B7882-C2F9-41EA-AAA0-B065C53F6C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I think the document is ready to be handed to the AD. Best regards, -Lori > On Feb 3, 2021, at 6:57 PM, Sharon Barkai = wrote: >=20 > Thank you Luigi Joel. >=20 > We are working to add LISP based digital-twin interface for road = segments to the AECC auto-edge. The roll of this interface is to = throttle the pipes: car access to edge, edge to cloud by: >=20 > 1. Recording car EID data-handles in tile EID ledgers for selective = uploads per quota > 2. Aggregating coalescing filtering uploads per tile for reduced feed = to cloud applications >=20 > This is hard to do with an IETF draft so very much appreciate show of = support even though its the 2nd such poll...=20 >=20 > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 >=20 >> On Feb 3, 2021, at 17:25, Luigi Iannone wrote: >>=20 >> =EF=BB=BFHi All, >>=20 >> The authors of draft-ietf-lisp-nexagon submitted the current version = back in October solving issues raised during SECDIR review. >> No further comments have been raised and the authors consider the = document stable and ready for WG Last Call. >>=20 >> This email open the usual two weeks Working Group Last Call, to end = February 17th, 2021. >>=20 >> Please review this WG document and let the WG know if you agree that = it is ready to be handed over to the AD. >> If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >>=20 >> NOTE: silence IS NOT consensus! >>=20 >> Thanks >>=20 >> Luigi & Joel >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_180B7882-C2F9-41EA-AAA0-B065C53F6C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = think the document is ready to be handed to the AD.

Best regards,
-Lori

On Feb 3, 2021, at 6:57 PM, = Sharon Barkai <sharon.barkai=3D40getnexar.com@dmarc.ietf.org> = wrote:

Thank you Luigi Joel.

We are working to add = LISP based digital-twin interface for road segments to the AECC = auto-edge. The roll of this interface is to throttle the pipes: car = access to edge, edge to cloud by:

1. Recording car EID data-handles in = tile EID ledgers for selective uploads per quota
2. = Aggregating coalescing filtering uploads per tile for reduced feed to = cloud applications

This is hard to do with an IETF draft so very much appreciate = show of support even though its the 2nd such poll... 

--szb
Cell: +972.53.2470068
WhatsApp: = +1.650.492.0794

On Feb 3, 2021, at = 17:25, Luigi Iannone <ggx@gigix.net> wrote:

=EF=BB=BFHi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in = October solving issues raised during SECDIR = review.
No further comments have been raised and the = authors consider the document stable and ready for  WG Last = Call.

This email open the usual two weeks Working Group Last Call, to = end February 17th, 2021.

Please review this WG = document and let the WG know if you agree that it is ready to be handed = over to the AD.
If you have objections, = please state your reasons why, and explain what it would take to address = your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi = & Joel
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
________________________________= _______________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

= --Apple-Mail=_180B7882-C2F9-41EA-AAA0-B065C53F6C05-- --Apple-Mail=_D020F5A0-8C37-403B-9125-F69E63D03F69 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCRkw ggRuMIIDVqADAgECAgphEIBtAAAAAAAOMA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoTDUNpc2Nv IFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0xNDA0MDQyMDI0MThaFw0y OTA1MTQyMDI1NDJaMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrffhZMUxX7I1bNxrllCgSV5d5MRWeM DMcG4KsfbV83Knvn7aOtgH8RyPOC6+6fUNnJvz2hL7s8EQc177il2VFO2bD3U6CUgCwskmWtEG+h hmtfQAqZpVBEGpBNz+ZM+0YGjUjjB9fhrWPX1egnABW/bgeyQ7tlBi999lldmxLFLH2960SwUuHC /B7tnVn3HZOnqzGmQkI5J9OBYsZULCaM2z0U0KiOFeoopBv+vaw8nk3W1UyvjMv/S58FbA9xgTIk Ye0Zq77qcbRojLvI9OSLP3dTon4VnnML41d0XoPS6JPGzDSRDAKXndcHk3VUtF+DLAIXqLCQZXfZ UuTuIncCAwEAAaOCAYcwggGDMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBSflTa0jl3VS8MK wacpk0NRBv2JUTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBQn88gVHm6aAgkWrSugiWBf2nsvqjBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY3JsL2NyY2EyMDQ4LmNy bDBQBggrBgEFBQcBAQREMEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3Vy aXR5L3BraS9jZXJ0cy9jcmNhMjA0OC5jZXIwXAYDVR0gBFUwUzBRBgorBgEEAQkVARUAMEMwQQYI KwYBBQUHAgEWNWh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9wb2xpY2llcy9pbmRl eC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQA+Tr4jGkYCjV5r24oCNAtjm+UBPCZdjHCyJOtgXuyK hGQuG1kVo2ca4Rbj/eBNfUSaIyjS7bb3oh/nRM3tbeqGIVQorGxhvPvIZVAEQIoqi/yfbhie9cU+ paKpHACucaYXu0kyS0pYE5NMNun3Lw3ogOs4XVR5yoVSpKTiVnfTDQchTpwkMgzivqXDcS1OiDfU 8C9WaEZHRWtdUIgl9zoppPGIQa1TflcxhirW4GeH2FOrgaN1d77bIcg6R7RpJ9Xu3/f01nGNunrR cy993c2meJQoZcOJd15C6ugHwhAxeXY6QXYgkY8KQVCCGwkpshEgbwPrC+I/Itb6P7hGq7awMIIE ozCCA4ugAwIBAgIKAYYRx23NwDrdDTANBgkqhkiG9w0BAQsFADAsMQ4wDAYDVQQKEwVDaXNjbzEa MBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwHhcNMTkwMzEzMTgyNTQyWhcNMjEwMzEyMTkzNTQy WjCBlzEdMBsGA1UEAxMUTG9yaSBKYWthYiAobG9qYWthYikxFDASBgNVBAsTC0Npc2NvIFVzZXJz MRIwEAYDVQQLEwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZ EwVjaXNjbzEgMB4GCSqGSIb3DQEJAQwRbG9qYWthYkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCDkXcmrKngendb7VcUw/hoaXNxTzoz/UjJbu4CD1p/s8FPUfsUMYvH CelMq9cifSn4AmxhWnaYPdLFHeeIu6n6LfDuPui11/sftDdJfze8A5Q3QR1X6JD4s9RFsBhH9Vbu a6yitnB+bRSy8pdTGkn/g91MsLa7FbuHqyawqt2AdC6Ne6P3i48qki6HQbuqKCEn/simZun7R/oY /GRzJhGXuioqbP6jE1bnZqJ8pxPCg/VZZBEJ7sJHmVU5iL1jdOl7Pi1EPOeWI55AVtjGKghMvhqJ 5vD5SjzPbiE4I/PhfqO1+tnkDTcqOej6O6u5INKOdy9BKp0P/SJ1OcEHsTZxAgMBAAGjggFZMIIB VTAOBgNVHQ8BAf8EBAMCBPAwDAYDVR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUH MAKGMGh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggr BgEFBQcwAYYgaHR0cDovL3BraWN2cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2 tI5d1UvDCsGnKZNDUQb9iVEwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lz Y28uY29tL2ZpbGUvY2VjYS5jcmwwHAYDVR0RBBUwE4ERbG9qYWthYkBjaXNjby5jb20wHQYDVR0O BBYEFJLqY/qB8+2JyoYKf7OTyjjLBrtoMB8GA1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwME MA0GCSqGSIb3DQEBCwUAA4IBAQCXNHnJzt8g+ndjIffvgHeWSxwZnBLBwj4Q7O4xwUA4P/+dm6DN sxGt6xxzZmr5H+UhpvJ0weTHZRCB3clW0o+1ytfnRGYSWEakPoioyM6e8eZzjaCUo7Fe90LJrVpy 0axxl15+RHXpG1wXsU2Ze3EOWccOwdD+Accu6xpeFfYtVaRLTrzdGLZglBUSgppPtyqLs6nvsQf+ jFc6kGVv0yXqIomqGnjp3O3eWovRzZ9clQhi0oc+yv6Mn2HFYzVXBhWk/7igzN/oiFYRjNBa5n0c WF3t8pnqPrqXBrFlbY2C/UFwDcGJaXPkfrkk51UpP4Ha9ARlMKuum4VE3L9/y2yFMYICajCCAmYC AQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGEcdt zcA63Q0wDQYJYIZIAWUDBAIBBQCgggEBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIxMDIwNDE1NDkyNlowLwYJKoZIhvcNAQkEMSIEILnycFZWkBWkeDVQy4VlDcgw 5ESEfYvt4AmdY+4vrfN4MEkGCSsGAQQBgjcQBDE8MDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNV BAMTEUNpc2NvIEVtcGxveWVlIENBAgoBhhHHbc3AOt0NMEsGCyqGSIb3DQEJEAILMTygOjAsMQ4w DAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGEcdtzcA63Q0wDQYJ KoZIhvcNAQEBBQAEggEAJXk63gY4tKGVvXHquzgw/bSf43tgyXpspHb+kzE4PMpGhbngGC5D65f5 qCNozS08nd+S+470ZutObQEI5FR1in5XGMz9nU4GNMCxBSNi6VJNateiV9mDC8Xv8uFQtxDYli0h 9Qk4DEc3RdBNTUy177y8vKmjmDEyw1pNkZtgTh3oyvDEnJj+WzUeXvp5YdNSPfBekn/1mi7D056j H8OD8d57n/TQmXjv4bDSt46DHRKx55Hny3LFEuC6x23dIM5P6qUy0Ag2lsi3+oJTLNNsXV2O/C4I FwRl9ROmWiccBmME0BW4hA5p073Bs75C8VUjd9kDNLpSIT3NzGcUFEGYHwAAAAAAAA== --Apple-Mail=_D020F5A0-8C37-403B-9125-F69E63D03F69-- From nobody Fri Feb 5 02:26:49 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9F63A0B93; Fri, 5 Feb 2021 02:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 j45h20i8ZERe; Fri, 5 Feb 2021 02:26:44 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6090D3A0B91; Fri, 5 Feb 2021 02:26:42 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 115AQaOR006278; Fri, 5 Feb 2021 11:26:36 +0100 Received: from [10.8.0.18] (gw-4-vpn.ac.upc.es [147.83.30.81]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id D08C2132; Fri, 5 Feb 2021 11:26:30 +0100 (CET) To: Luigi Iannone , "lisp@ietf.org list" Cc: lisp-chairs@ietf.org References: From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: Date: Fri, 5 Feb 2021 11:26:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FB45B4863263C9278CE01180" Content-Language: en-AU Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 10:26:48 -0000 This is a multi-part message in MIME format. --------------FB45B4863263C9278CE01180 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done. Some comments and questions that I have when reading the document are the following ones: In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them. "/EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs? "/EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network./": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR? Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section? I think that more references need to be added to the document like the DIAMETER RFC. I hope these comments could help to improve the document. Best regards Albert López On 3/2/21 16:25, Luigi Iannone wrote: > Hi All, > > The authors of draft-ietf-lisp-nexagon submitted the current version > back in October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the > document stable and ready for  WG Last Call. > > This email open the usual two weeks Working Group Last Call, to end > February 17th, 2021. > > Please review this WG document and let the WG know if you agree that > it is ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain > what it would take to address your concerns. > > NOTE: silence IS NOT consensus! > > Thanks > > Luigi & Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------FB45B4863263C9278CE01180 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi all,

After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done.

Some comments and questions that I have when reading the document are the following ones:

In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them.

"EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs?

"EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network.": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?

Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section?

I think that more references need to be added to the document like the DIAMETER RFC.

I hope these comments could help to improve the document.

Best regards

Albert López




On 3/2/21 16:25, Luigi Iannone wrote:
Hi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.

Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--------------FB45B4863263C9278CE01180-- From nobody Fri Feb 5 04:31:13 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365203A0D63; Fri, 5 Feb 2021 04:31:11 -0800 (PST) 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, MIME_QP_LONG_LINE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_p_Uh72AVkK; Fri, 5 Feb 2021 04:31:09 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 BECCE3A0D62; Fri, 5 Feb 2021 04:31:08 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id u14so5763239wmq.4; Fri, 05 Feb 2021 04:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=1OFSI938VI2fLtUY6GP0Fj5WD6Sa5AvkcgmDnlZsDng=; b=lZIy5PSj+FB1tV2yTJwFLupikat02o9pfJ/urGQRlbnFk/ETGgYDHri2Vv9bxnjD8G X9U2pgcg6i+Xved1te4TIrmoeyRoX3KfxQ9DV7wHbUyNeNMDJqrJnkAJY7kBp2qC0tNx i7tsb7I7eKHmGdETzmNpwhsqqg/pXDPEOAYbkFEU0keOU05fHxTifau90Efi/LP3U0c4 5cPWRHMELBqNYepg2sU8iC3xQ1Gecmsl4ViOZCKxvwZMPNraWSazgjWdM7qe+piQSS3W HbOzvXmk/Q12P8JX5AC6Kxh6hqjTD8I8g3GPeYtKA5RFAZSkpkqowuLRq5WzWxA/3ts2 JJrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=1OFSI938VI2fLtUY6GP0Fj5WD6Sa5AvkcgmDnlZsDng=; b=Dv1DnaMQCdHL6mff9IDp/hjqQUG4nODxUyWNcG9RQPR65u0qbLURFtkv7AGaNegCQy v/Lxuslh38AdEgqV6ty4XQbgtFCd/oWfNoGH+AG7BvnXmMwK/RyuSkq9/3m/SYREeEwA hbGU+eig3btpLr7mB+hXJDhtjr0wjg9iirlqgJqHtsIg/x8FAz98L/2ASzqQZVs1BAZv T6LfXhyILhWux05HGSgZFOkfualTx6g1CDEDfre1M7WxAIrKKuOx1LLXkAQhOtWuKw2x h0qQCVRhWm3C7l0hhzBwHbqNLlFFWk5b0ATPYIJxw64kmKr3XzD23J37/sDCaygMIxh1 oGlQ== X-Gm-Message-State: AOAM532Lr9hvSgtJVeCp+Pzw4+4MHmxSvgHoqMzRDkgg8sDqOanW4c+3 vRfmBJ1txRKGEaKKcYfOmnNVDFKDuw== X-Google-Smtp-Source: ABdhPJzVTddQV/IbFvKeqRPDCezLipPAqs1BfwJu/Rxm6t/PmgnltbiV5lqX+iiYGmKA6tJmH2PDKQ== X-Received: by 2002:a1c:3587:: with SMTP id c129mr3421251wma.76.1612528266823; Fri, 05 Feb 2021 04:31:06 -0800 (PST) Received: from ?IPv6:2a02:14c:338:8200:9082:925e:6ebd:1c64? ([2a02:14c:338:8200:9082:925e:6ebd:1c64]) by smtp.gmail.com with ESMTPSA id b7sm13365869wrs.50.2021.02.05.04.31.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Feb 2021 04:31:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E5E7E8AC-8AF0-4CE2-B27B-2D6D30CDE55C Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Sharon In-Reply-To: Date: Fri, 5 Feb 2021 14:31:05 +0200 Cc: Luigi Iannone , "lisp@ietf.org list" , lisp-chairs@ietf.org Message-Id: <52F090EE-746D-417F-B9A4-573E72CDB512@gmail.com> References: To: =?utf-8?Q?Albert_L=C3=B3pez?= X-Mailer: iPhone Mail (18C66) Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 12:31:11 -0000 --Apple-Mail-E5E7E8AC-8AF0-4CE2-B27B-2D6D30CDE55C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Albert. These are very good comments. See inline: --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 5, 2021, at 12:26, Albert L=C3=B3pez wrote: >=20 > =EF=BB=BF > Hi all, >=20 > After reading the draft, I believe it is a really good idea, but I think t= hat the document needs more work to be done. >=20 > Some comments and questions that I have when reading the document are the f= ollowing ones: >=20 > In section 6, the structure of a "Nexgon packet" is introduced with the Ne= xgon header but no description is provided of the fields of this header. Aft= er reading the document you can deduce the use of some of these fields but n= ot all of them.=20 I will add more text on the nexagon header. In principle these are: Type: we specify two types only here kv, kv, kv... basic and default use v, k, k, k .. for large area with same value proprietary extensions add more types Gzip: is a flag if the k,v where zipped. In close by tiles the compression is high Reserved: Pair count: how many kv are we sending, in kv kv or v kkk form=20 >=20 > "EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR= (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no mo= re information is provided about option1 and option2. The scenario is clear f= or me when we have one EdgeRTR between client-XTR and server-XTR but when we= have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't under= stand when to use it and the process to implement it. Is it using ELPs? The LISP default is option1 clients and servers are not homed to the same RT= R. This is for example in a MEC or Wavelength type deployment. In this optio= n the servers EID are registered in the mapping with the RLOC of their RTR. T= he ServerXTR is just a tunnel to the RTR and does not participate in the lis= p control plane. The clientXTR and ServerXTR solve NAT traversal between mob= ile and edge providers. We left the door open to a more distributed implementation for example by ce= ll towers or RSU. In this case there is only one RTR between clients and ser= vers. >=20 > "EdgeRTRs do not register MobilityClients=E2=80=99 EIDs at the mapping ser= vice as these are temporary-renewed while using the mobility network.": Does= the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know t= he Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register,= can we consider the EdgeRTR as the MS of the Client-xTR? At this point we do not allow unicast between clients, only publish clients t= o servers, and signal free feed servers to clients. >=20 > Is there any mechanism contemplated for the MobilityClient to change the a= ssociated EdgeRTRs? for instance repeating the procedure explained in sectio= n 4 when changing to a new H3.9 section? >=20 Yes clients can repeat AAA procedure and are supposed to renew AAA. > I think that more references need to be added to the document like the DIA= METER RFC. >=20 Will add > I hope these comments could help to improve the document. >=20 They do. I will clarify the language and send update as soon as all inputs a= re in. Thank you for devoting the time and attention.=20 > Best regards >=20 > Albert L=C3=B3pez >=20 >=20 >=20 >=20 >> On 3/2/21 16:25, Luigi Iannone wrote: >> Hi All, >>=20 >> The authors of draft-ietf-lisp-nexagon submitted the current version bac= k in October solving issues raised during SECDIR review. >> No further comments have been raised and the authors consider the documen= t stable and ready for WG Last Call. >>=20 >> This email open the usual two weeks Working Group Last Call, to end Febru= ary 17th, 2021. >>=20 >> Please review this WG document and let the WG know if you agree that it i= s ready to be handed over to the AD. >> If you have objections, please state your reasons why, and explain what i= t would take to address your concerns. >>=20 >> NOTE: silence IS NOT consensus! >>=20 >> Thanks >>=20 >> Luigi & Joel >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-E5E7E8AC-8AF0-4CE2-B27B-2D6D30CDE55C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Albert. These are very good comme= nts. See inline:

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

On Feb 5, 2021, at 12:26, Albert L=C3=B3pez <alopez@ac.upc= .edu> wrote:

=EF=BB=BF =20 =20 =20
Hi all,

After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done.

Some comments and questions that I have when reading the document are the following ones:

In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them.
I will add more text on the nexagon header. In principle these a= re:

Type: we specify two types only here
= kv, kv, kv... basic and default use
v, k, k, k .. for large area w= ith same value
proprietary extensions add more types
Gzip: is a flag if the k,v where zipped.
In close by t= iles the compression is high

Reserved:
Pair count: how many kv are we sending,
in kv kv or v= kkk form 


"EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs?

The LISP default i= s option1 clients and servers are not homed to the same RTR. This is for exa= mple in a MEC or Wavelength type deployment. In this option the servers EID a= re registered in the mapping with the RLOC of their RTR. The ServerXTR is ju= st a tunnel to the RTR and does not participate in the lisp control plane. T= he clientXTR and ServerXTR solve NAT traversal between mobile and edge provi= ders.

We left the door open to a more distributed i= mplementation for example by cell towers or RSU. In this case there is only o= ne RTR between clients and servers.


"EdgeRTRs do not register MobilityClients=E2=80=99 EIDs at the mappin= g service as these are temporary-renewed while using the mobility network.": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?

At this point we do not allow unicast between clients, only publish client= s to servers, and signal free feed servers to clients.

Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section?


Y= es clients can repeat AAA procedure and are supposed to renew AAA.

I think that more references need to be added to the document like the DIAMETER RFC.



<= /div>Will add

I hope these comments could help to improve the document.


They do. I will clarify the language and send= update as soon as all inputs are in.
Thank you for devoting the t= ime and attention. 

Best regards

Albert L=C3=B3pez




On 3/2/21 16:25, Luigi Iannone wrote:
=
Hi All,

The authors of  = draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.

Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

_______________________________=
________________
lisp mailing list
lisp@iet=
f.org
https://www.ietf.org/mailman/listinfo/lisp

=20 _______________________________________________
lisp m= ailing list
lisp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/lisp
= --Apple-Mail-E5E7E8AC-8AF0-4CE2-B27B-2D6D30CDE55C-- From nobody Mon Feb 8 02:05:15 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3723A156D; Mon, 8 Feb 2021 02:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 X6JoMzl0B6Zj; Mon, 8 Feb 2021 02:05:11 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 44C733A1569; Mon, 8 Feb 2021 02:05:09 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 118A55Xv027205; Mon, 8 Feb 2021 11:05:05 +0100 Received: from [192.168.1.129] (174.131.14.37.dynamic.jazztel.es [37.14.131.174]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 191331DF4; Mon, 8 Feb 2021 11:05:00 +0100 (CET) To: Sharon Cc: Luigi Iannone , "lisp@ietf.org list" , lisp-chairs@ietf.org References: <52F090EE-746D-417F-B9A4-573E72CDB512@gmail.com> From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: <122a75a5-1a95-dcdb-8ab3-e957f1d13975@ac.upc.edu> Date: Mon, 8 Feb 2021 11:04:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <52F090EE-746D-417F-B9A4-573E72CDB512@gmail.com> Content-Type: multipart/alternative; boundary="------------ECAF1C9A19D01919E11183D4" Content-Language: en-AU Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 10:05:14 -0000 This is a multi-part message in MIME format. --------------ECAF1C9A19D01919E11183D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Sharon, Thanks for your clarifications. I have some questions inline. On 5/2/21 13:31, Sharon wrote: > Thank you Albert. These are very good comments. See inline: > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > >> On Feb 5, 2021, at 12:26, Albert López wrote: >> >>  >> Hi all, >> >> After reading the draft, I believe it is a really good idea, but I >> think that the document needs more work to be done. >> >> Some comments and questions that I have when reading the document are >> the following ones: >> >> In section 6, the structure of a "Nexgon packet" is introduced with >> the Nexgon header but no description is provided of the fields of >> this header. After reading the document you can deduce the use of >> some of these fields but not all of them. > > I will add more text on the nexagon header. In principle these are: > > Type: we specify two types only here > kv, kv, kv... basic and default use > v, k, k, k .. for large area with same value > proprietary extensions add more types > > Gzip: is a flag if the k,v where zipped. > In close by tiles the compression is high > > Reserved: > > Pair count: how many kv are we sending, > in kv kv or v kkk form > >> >> "/EdgeRTRs then re-encapsulates annotation packets either to remote >> EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" >> but I think no more information is provided about option1 and >> option2. The scenario is clear for me when we have one EdgeRTR >> between client-XTR and server-XTR but when we have to reencapsulate >> packets from EdgeRTR to another EdgeRTR I don't understand when to >> use it and the process to implement it. Is it using ELPs? > > The LISP default is option1 clients and servers are not homed to the > same RTR. This is for example in a MEC or Wavelength type deployment. > In this option the servers EID are registered in the mapping with the > RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does > not participate in the lisp control plane. The clientXTR and ServerXTR > solve NAT traversal between mobile and edge providers. So, if I understood correctly, the serverXTR is registering its EID (H3.r9) to the mapping system using the RLOC of its associated RTR. This process is done through Encap Map-Register of the serverXTR through the RTR or It is the serverXTR who is sending directly a Map-Register to the mapping system?  How does the RTR knows the the real RLOC of the serverXTR? is statically configured? or is learned through an Encap Map-Register? > > We left the door open to a more distributed implementation for example > by cell towers or RSU. In this case there is only one RTR between > clients and servers. > >> >> "/EdgeRTRs do not register MobilityClients’ EIDs at the mapping >> service as these are temporary-renewed while using the mobility >> network./": Does the Client-XTR send Map Registers to the EdgeRTR? If >> not, how does it know the Client-xTR's RLOCs and its changes?. >> Otherwise, If it sends Map-Register, can we consider the EdgeRTR as >> the MS of the Client-xTR? > > At this point we do not allow unicast between clients, only publish > clients to servers, and signal free feed servers to clients. If no registration process exists of the MobilityClients' EID, how does the edgeRTR knows the MobilityClient's RLOC that should be used to send the multicast packets? (Specially if a change of RLOC is produced) Best regards Albert >> >> Is there any mechanism contemplated for the MobilityClient to change >> the associated EdgeRTRs? for instance repeating the procedure >> explained in section 4 when changing to a new H3.9 section? >> > > Yes clients can repeat AAA procedure and are supposed to renew AAA. >> >> I think that more references need to be added to the document like >> the DIAMETER RFC. >> > > > Will add >> >> I hope these comments could help to improve the document. >> > > They do. I will clarify the language and send update as soon as all > inputs are in. > Thank you for devoting the time and attention. > >> Best regards >> >> Albert López >> >> >> >> >> On 3/2/21 16:25, Luigi Iannone wrote: >>> Hi All, >>> >>> The authors of draft-ietf-lisp-nexagon submitted the current version >>> back in October solving issues raised during SECDIR review. >>> No further comments have been raised and the authors consider the >>> document stable and ready for  WG Last Call. >>> >>> This email open the usual two weeks Working Group Last Call, to end >>> February 17th, 2021. >>> >>> Please review this WG document and let the WG know if you agree that >>> it is ready to be handed over to the AD. >>> If you have objections, please state your reasons why, and explain >>> what it would take to address your concerns. >>> >>> NOTE: silence IS NOT consensus! >>> >>> Thanks >>> >>> Luigi & Joel >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp --------------ECAF1C9A19D01919E11183D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Sharon,

Thanks for your clarifications. I have some questions inline.

On 5/2/21 13:31, Sharon wrote:
Thank you Albert. These are very good comments. See inline:

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

On Feb 5, 2021, at 12:26, Albert López <alopez@ac.upc.edu> wrote:


Hi all,

After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done.

Some comments and questions that I have when reading the document are the following ones:

In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them.

I will add more text on the nexagon header. In principle these are:

Type: we specify two types only here
kv, kv, kv... basic and default use
v, k, k, k .. for large area with same value
proprietary extensions add more types

Gzip: is a flag if the k,v where zipped.
In close by tiles the compression is high

Reserved:

Pair count: how many kv are we sending,
in kv kv or v kkk form 


"EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs?

The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers.
So, if I understood correctly, the serverXTR is registering its EID (H3.r9) to the mapping system using the RLOC of its associated RTR. This process is done through Encap Map-Register of the serverXTR through the RTR or It is the serverXTR who is sending directly a Map-Register to the mapping system?  How does the RTR knows the the real RLOC of the serverXTR? is statically configured? or is learned through an Encap Map-Register?

We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers.


"EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network.": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?

At this point we do not allow unicast between clients, only publish clients to servers, and signal free feed servers to clients.

If no registration process exists of the MobilityClients' EID, how does the edgeRTR knows the MobilityClient's RLOC that should be used to send the multicast packets? (Specially if a change of RLOC is produced)

Best regards

Albert


Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section?


Yes clients can repeat AAA procedure and are supposed to renew AAA.

I think that more references need to be added to the document like the DIAMETER RFC.



Will add

I hope these comments could help to improve the document.


They do. I will clarify the language and send update as soon as all inputs are in.
Thank you for devoting the time and attention. 

Best regards

Albert López




On 3/2/21 16:25, Luigi Iannone wrote:
Hi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.

Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--------------ECAF1C9A19D01919E11183D4-- From nobody Mon Feb 8 04:44:28 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3053A16B7 for ; Mon, 8 Feb 2021 04:44:27 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=getnexar.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 oGaLeGSHRwWe for ; Mon, 8 Feb 2021 04:44:24 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 7411D3A16F8 for ; Mon, 8 Feb 2021 04:44:24 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id m1so13124762wml.2 for ; Mon, 08 Feb 2021 04:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=8Dt1xommnzRWGlbA4USA3fHEl+hQh1lbnNGMKPhCGWU=; b=aTo0K/QvaNKrKEmoRdBH2O7c3S1S4UYtTYRpSSYyFOnN1LctLw3NzrU3D0y7cgydKP xhNKINBeqPJ1L0sNCP1F81FBpIJnmVqbKRtor3gU5UrXAdgsr12zEKE1ZJJ/id3Sn9CC pEOSd+lOeKiRNgYRJYgVk8rIe7SC9aCCqRcOU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=8Dt1xommnzRWGlbA4USA3fHEl+hQh1lbnNGMKPhCGWU=; b=bFnYfA9D1OH6Vgzuk1CCa+X+EQQIujIx9mv79ktVTcRc8mL9HKf+cGo+jBRakHjTu8 tIwFUKKc1LNQJ3kdLzVW4Y0eirAmTNIy4eSq7HCp3VWDw6k+CJOgeGYV22zPK7ZRZ79J MuEZp85nDE9gi4wyUc1f3NCS4sEOHVWsy0k6Pd931xjMpdtaD0LenoxgCUBxWwRKFxEP BSble6lxA8boKkqEmip4JO1SVRYLIeWTXM5a8tZjOc1A0pElXpPIA0vR1BrTbZyhbhLi IIs+8zHAqb05FpvC7phn7hccRBF31cFWWdf0J/cOqmnYCDm0EdXe76/FBJiVbckRlqSa BDdw== X-Gm-Message-State: AOAM5309Cxo7kXSD4ABRpn72US5Mpb1SJSAFNmhDosuys+Q2szBWpqCZ 8YBnkHYuZwJoufQexzkiIROrQA== X-Google-Smtp-Source: ABdhPJz3r8kV5F3D5HJgy32iof9t/MJXeS/LJ4I/W8i6xbR2dnidEHhGWjs3P+cWHOFRJ9UhyAuerA== X-Received: by 2002:a1c:7d41:: with SMTP id y62mr14259716wmc.139.1612788262204; Mon, 08 Feb 2021 04:44:22 -0800 (PST) Received: from ?IPv6:2a02:14c:2049:1c00:1c:9bd8:9c1d:13b2? ([2a02:14c:2049:1c00:1c:9bd8:9c1d:13b2]) by smtp.gmail.com with ESMTPSA id w11sm7723252wmi.37.2021.02.08.04.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 04:44:21 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-2F477FF5-D0EC-4D90-9947-F1200DC5C813 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Sharon Barkai In-Reply-To: <122a75a5-1a95-dcdb-8ab3-e957f1d13975@ac.upc.edu> Date: Mon, 8 Feb 2021 14:44:20 +0200 Cc: Sharon , lisp-chairs@ietf.org, "lisp@ietf.org list" Message-Id: <5721B1C9-D7D4-4C4E-832F-2280C05693A6@getnexar.com> References: <122a75a5-1a95-dcdb-8ab3-e957f1d13975@ac.upc.edu> To: =?utf-8?Q?Albert_L=C3=B3pez?= X-Mailer: iPhone Mail (18C66) Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 12:44:27 -0000 --Apple-Mail-2F477FF5-D0EC-4D90-9947-F1200DC5C813 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Albert for pointing out these possible confusion points. Answering in= line .. But first would like to clarify the exact subset of LISP we leverage for the= Nexagon mobility network. 1. The MobilityClients and H3Services use the LISP XTR network over tunnels t= o mitigate multi-access-provider multi-edge-provider challenges such as NAT o= r multi-tenancy in clusters or edge device OS. =20 The simplest choice is to use data-path LISP tunnels:=20 -ClientXTR -ServerXTR=20 But these do not participate in the mapping control plane. Mapping System / \ sXTR=3DRTR1 :::::::::: RTR2=3DcXTR 2. Nexagon is a mobility geospatial pub-sub network, road-segments are abstr= acted to EIDH3Services which are administratively provisioned based on load/= availability to RTRs and the mapping system accordingly. Their global RLOC i= s their RTR (RTRs in multi homing). Clients subscribe to these geospatial feed using MLD and SignalFree Mcast, w= hich means their RTRs subscribe for them to (s,g) feeds. Their RTRs are assi= gned by AAA. The AAA provisioning is done both at the client and the RTR. Th= e RTR does mcast replication to to all the clients it is homing and that hav= e MLD subscribed through them to (s,g) or (location, theme) mcast feeds. After they subscribe, some of the clients may also publish geospatial detect= ions, depending on their EID credentials (rw/ro). When they do the RTR RLOC o= f the H3Service (this time as dest EID) is gleaned into the map-cache of the= client RTR - which is subscribed to that H3EIDService as a feed (source). Clients may NOT talk to each-other or learn each other's EIDs. The Nexagon n= etwork overlay is strictly brokered.=20 If the above computes, welcome any suggestion that prevents reading the draf= t differently. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 8, 2021, at 12:05, Albert L=C3=B3pez wrote: >=20 > =EF=BB=BF > Hi Sharon, >=20 > Thanks for your clarifications. I have some questions inline. >=20 >> On 5/2/21 13:31, Sharon wrote: >> Thank you Albert. These are very good comments. See inline: >>=20 >> --szb >> Cell: +972.53.2470068 >> WhatsApp: +1.650.492.0794 >>=20 >>> On Feb 5, 2021, at 12:26, Albert L=C3=B3pez wrote: >>>=20 >>> =EF=BB=BF >>> Hi all, >>>=20 >>> After reading the draft, I believe it is a really good idea, but I think= that the document needs more work to be done. >>>=20 >>> Some comments and questions that I have when reading the document are th= e following ones: >>>=20 >>> In section 6, the structure of a "Nexgon packet" is introduced with the N= exgon header but no description is provided of the fields of this header. Af= ter reading the document you can deduce the use of some of these fields but n= ot all of them.=20 >>=20 >> I will add more text on the nexagon header. In principle these are: >>=20 >> Type: we specify two types only here >> kv, kv, kv... basic and default use >> v, k, k, k .. for large area with same value >> proprietary extensions add more types >>=20 >> Gzip: is a flag if the k,v where zipped. >> In close by tiles the compression is high >>=20 >> Reserved: >>=20 >> Pair count: how many kv are we sending, >> in kv kv or v kkk form=20 >>=20 >>>=20 >>> "EdgeRTRs then re-encapsulates annotation packets either to remote EdgeR= TR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no m= ore information is provided about option1 and option2. The scenario is clear= for me when we have one EdgeRTR between client-XTR and server-XTR but when w= e have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't unde= rstand when to use it and the process to implement it. Is it using ELPs? >>=20 >> The LISP default is option1 clients and servers are not homed to the same= RTR. This is for example in a MEC or Wavelength type deployment. In this op= tion the servers EID are registered in the mapping with the RLOC of their RT= R. The ServerXTR is just a tunnel to the RTR and does not participate in the= lisp control plane. The clientXTR and ServerXTR solve NAT traversal between= mobile and edge providers. > So, if I understood correctly, the serverXTR is registering its EID (H3.r9= ) to the mapping system using the RLOC of its associated RTR. Right > This process is done through Encap Map-Register of the serverXTR through t= he RTR or It is the serverXTR who is sending directly a Map-Register to the m= apping system? Provisioned > How does the RTR knows the the real RLOC of the serverXTR? is statically= configured? or is learned through an Encap Map-Register?=20 Through gleaning the feed from the server it signal-free subscribed to >>=20 >> We left the door open to a more distributed implementation for example by= cell towers or RSU. In this case there is only one RTR between clients and s= ervers. >>=20 >>>=20 >>> "EdgeRTRs do not register MobilityClients=E2=80=99 EIDs at the mapping s= ervice as these are temporary-renewed while using the mobility network.": Do= es the Client-XTR send Map Registers to the EdgeRTR? If not, how does it kno= w the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Regist= er, can we consider the EdgeRTR as the MS of the Client-xTR? >>=20 >> At this point we do not allow unicast between clients, only publish clien= ts to servers, and signal free feed servers to clients. > If no registration process exists of the MobilityClients' EID, how does th= e edgeRTR knows the MobilityClient's RLOC that should be used to send the mu= lticast packets? (Specially if a change of RLOC is produced) >=20 The clientXTR and its RTR are co-providioned. The client must MLD report to a channel to ensure=20 - its RTR signal-free registers=20 - its RTR replicates to it=20 > Best regards >=20 > Albert >=20 >>>=20 >>> Is there any mechanism contemplated for the MobilityClient to change the= associated EdgeRTRs? for instance repeating the procedure explained in sect= ion 4 when changing to a new H3.9 section? >>>=20 >>=20 >> Yes clients can repeat AAA procedure and are supposed to renew AAA. >>> I think that more references need to be added to the document like the D= IAMETER RFC. >>>=20 >>=20 >>=20 >> Will add >>> I hope these comments could help to improve the document. >>>=20 >>=20 >> They do. I will clarify the language and send update as soon as all input= s are in. >> Thank you for devoting the time and attention.=20 >>=20 >>> Best regards >>>=20 >>> Albert L=C3=B3pez >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/2/21 16:25, Luigi Iannone wrote: >>>> Hi All, >>>>=20 >>>> The authors of draft-ietf-lisp-nexagon submitted the current version b= ack in October solving issues raised during SECDIR review. >>>> No further comments have been raised and the authors consider the docum= ent stable and ready for WG Last Call. >>>>=20 >>>> This email open the usual two weeks Working Group Last Call, to end Feb= ruary 17th, 2021. >>>>=20 >>>> Please review this WG document and let the WG know if you agree that it= is ready to be handed over to the AD. >>>> If you have objections, please state your reasons why, and explain what= it would take to address your concerns. >>>>=20 >>>> NOTE: silence IS NOT consensus! >>>>=20 >>>> Thanks >>>>=20 >>>> Luigi & Joel >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-2F477FF5-D0EC-4D90-9947-F1200DC5C813 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Albert for pointing out these possib= le confusion points. Answering inline ..
But first would like to clarify= the exact subset of LISP we leverage for the Nexagon mobility network.

1. The MobilityClients and H3Services use the LISP XTR n= etwork over tunnels to mitigate multi-access-provider multi-edge-provider ch= allenges such as NAT or multi-tenancy in clusters or edge device OS.  <= /div>

The simplest choice is to use data-path LISP tunnel= s: 
-ClientXTR
-ServerXTR 
But these= do not participate in the mapping control plane.

&= nbsp;             Mapping System
&nb= sp;                   /   &= nbsp;            \
sXTR=3DRTR1 :::::= ::::: RTR2=3DcXTR

2. Nexagon is a mobility geospati= al pub-sub network, road-segments are abstracted to EIDH3Services which are a= dministratively provisioned based on load/availability to RTRs and the mappi= ng system accordingly. Their global RLOC is their RTR (RTRs in multi homing)= .

Clients subscribe to these geospatial feed using M= LD and SignalFree Mcast, which means their RTRs subscribe for them to (s,g) f= eeds. Their RTRs are assigned by AAA. The AAA provisioning is done both at t= he client and the RTR. The RTR does mcast replication to to all the clients i= t is homing and that have MLD subscribed through them to (s,g) or (location,= theme) mcast feeds.

After they subscribe, some of t= he clients may also publish geospatial detections, depending on their EID cr= edentials (rw/ro). When they do the RTR RLOC of the H3Service (this time as d= est EID) is gleaned into the map-cache of the client RTR - which is subscrib= ed to that H3EIDService as a feed (source).

Clients= may NOT talk to each-other or learn each other's EIDs. The Nexagon network o= verlay is strictly brokered. 

If the above com= putes, welcome any suggestion that prevents reading the draft differently.

--szb
Cell: +972.53.2470068
What= sApp: +1.650.492.0794

On Feb 8, 2021, at 12:05, Albert L=C3=B3pez <alopez@ac.upc.edu> wr= ote:

=EF= =BB=BF =20 =20 =20
Hi Sharon,

Thanks for your clarifications. I have some questions inline.

On 5/2/21 13:31, Sharon wrote:
Thank you Albert. These are very good comments. See inline:

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

On Feb 5, 2021, at 12:26, Albert L=C3=B3pe= z <alopez@ac.upc.edu> wrote:

=EF=BB=BF
Hi all,

After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done.

Some comments and questions that I have when reading the document are the following ones:

In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them.

I will add more text on the nexagon header. In principle these are:

Type: we specify two types only here
kv, kv, kv... basic and default use
v, k, k, k .. for large area with same value
proprietary extensions add more types

Gzip: is a flag if the k,v where zipped.
In close by tiles the compression is high

Reserved:

Pair count: how many kv are we sending,
in kv kv or v kkk form 


"EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs?

The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers.
So, if I understood correctly, the serverXTR is registering its EID (H3.r9) to the mapping system using the RLOC of its associated RTR.

Right

This process is done through Encap Map-Register of the serverXTR through the RTR or It is the serverXTR who is sending directly a Map-Register to the mapping system?

Provisioned

  How= does the RTR knows the the real RLOC of the serverXTR? is statically configured? or is learned through an Encap Map-Register?

Through gleaning the feed from the server it signal-free subscribed to

We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers.


"EdgeRTRs do not register MobilityClients=E2=80=99 EIDs at the mapping service as these are temporary-renewed while using the mobility network.": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?

At this point we do not allow unicast between clients, only publish clients to servers, and signal free feed servers to clients.

If no registration process exists of the MobilityClients' EID, how does the edgeRTR knows the MobilityClient's RLOC that should be used to send the multicast packets? (Specially if a change of RLOC is produced)


The clientXTR a= nd its RTR are co-providioned.
The client must MLD report to a cha= nnel to ensure 
- its RTR signal-free registers 
- its RTR replicates to it 

Best regards

Albert


Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section?


Yes clients can repeat AAA procedure and are supposed to renew AAA.

I think that more references need to be added to the document like the DIAMETER RFC.



Will add

I hope these comments could help to improve the document.


They do. I will clarify the language and send update as soon as all inputs are in.
Thank you for devoting the time and attention. 

Best regards

Albert L=C3=B3pez




On 3/2/21 16:25, Luigi Iannone wrote:
Hi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.

Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

_________________________=
______________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/li=
sp

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

=20 _______________________________________________
lisp m= ailing list
lisp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/lisp
= --Apple-Mail-2F477FF5-D0EC-4D90-9947-F1200DC5C813-- From nobody Mon Feb 8 22:50:13 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B63A119B; Mon, 8 Feb 2021 22:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 0o0iztpNI107; Mon, 8 Feb 2021 22:50:07 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 72EBD3A1199; Mon, 8 Feb 2021 22:50:06 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 1196o3A5011878; Tue, 9 Feb 2021 07:50:03 +0100 Received: from [10.8.0.14] (gw-5-vpn.ac.upc.es [147.83.30.82]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 1EEF4276; Tue, 9 Feb 2021 07:49:58 +0100 (CET) To: Sharon Barkai Cc: Sharon , lisp-chairs@ietf.org, "lisp@ietf.org list" References: <122a75a5-1a95-dcdb-8ab3-e957f1d13975@ac.upc.edu> <5721B1C9-D7D4-4C4E-832F-2280C05693A6@getnexar.com> From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: <202e1b6b-b8eb-d841-c687-309f32fc5343@ac.upc.edu> Date: Tue, 9 Feb 2021 07:49:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5721B1C9-D7D4-4C4E-832F-2280C05693A6@getnexar.com> Content-Type: multipart/alternative; boundary="------------68DC38941C7A83DF9C792112" Content-Language: ca Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 06:50:12 -0000 This is a multi-part message in MIME format. --------------68DC38941C7A83DF9C792112 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for your explanations. Now it is more clear to me. Best regards Albert On 8/2/21 13:44, Sharon Barkai wrote: > Thanks Albert for pointing out these possible confusion points. > Answering inline .. > But first would like to clarify the exact subset of LISP we leverage > for the Nexagon mobility network. > > 1. The MobilityClients and H3Services use the LISP XTR network over > tunnels to mitigate multi-access-provider multi-edge-provider > challenges such as NAT or multi-tenancy in clusters or edge device OS. > > The simplest choice is to use data-path LISP tunnels: > -ClientXTR > -ServerXTR > But these do not participate in the mapping control plane. > >               Mapping System >                     /                \ > sXTR=RTR1 :::::::::: RTR2=cXTR > > 2. Nexagon is a mobility geospatial pub-sub network, road-segments are > abstracted to EIDH3Services which are administratively provisioned > based on load/availability to RTRs and the mapping system accordingly. > Their global RLOC is their RTR (RTRs in multi homing). > > Clients subscribe to these geospatial feed using MLD and SignalFree > Mcast, which means their RTRs subscribe for them to (s,g) feeds. Their > RTRs are assigned by AAA. The AAA provisioning is done both at the > client and the RTR. The RTR does mcast replication to to all the > clients it is homing and that have MLD subscribed through them to > (s,g) or (location, theme) mcast feeds. > > After they subscribe, some of the clients may also publish geospatial > detections, depending on their EID credentials (rw/ro). When they do > the RTR RLOC of the H3Service (this time as dest EID) is gleaned into > the map-cache of the client RTR - which is subscribed to that > H3EIDService as a feed (source). > > Clients may NOT talk to each-other or learn each other's EIDs. The > Nexagon network overlay is strictly brokered. > > If the above computes, welcome any suggestion that prevents reading > the draft differently. > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > >> On Feb 8, 2021, at 12:05, Albert López wrote: >> >>  >> Hi Sharon, >> >> Thanks for your clarifications. I have some questions inline. >> >> On 5/2/21 13:31, Sharon wrote: >>> Thank you Albert. These are very good comments. See inline: >>> >>> --szb >>> Cell: +972.53.2470068 >>> WhatsApp: +1.650.492.0794 >>> >>>> On Feb 5, 2021, at 12:26, Albert López wrote: >>>> >>>>  >>>> Hi all, >>>> >>>> After reading the draft, I believe it is a really good idea, but I >>>> think that the document needs more work to be done. >>>> >>>> Some comments and questions that I have when reading the document >>>> are the following ones: >>>> >>>> In section 6, the structure of a "Nexgon packet" is introduced with >>>> the Nexgon header but no description is provided of the fields of >>>> this header. After reading the document you can deduce the use of >>>> some of these fields but not all of them. >>> >>> I will add more text on the nexagon header. In principle these are: >>> >>> Type: we specify two types only here >>> kv, kv, kv... basic and default use >>> v, k, k, k .. for large area with same value >>> proprietary extensions add more types >>> >>> Gzip: is a flag if the k,v where zipped. >>> In close by tiles the compression is high >>> >>> Reserved: >>> >>> Pair count: how many kv are we sending, >>> in kv kv or v kkk form >>> >>>> >>>> "/EdgeRTRs then re-encapsulates annotation packets either to remote >>>> EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" >>>> but I think no more information is provided about option1 and >>>> option2. The scenario is clear for me when we have one EdgeRTR >>>> between client-XTR and server-XTR but when we have to reencapsulate >>>> packets from EdgeRTR to another EdgeRTR I don't understand when to >>>> use it and the process to implement it. Is it using ELPs? >>> >>> The LISP default is option1 clients and servers are not homed to the >>> same RTR. This is for example in a MEC or Wavelength type >>> deployment. In this option the servers EID are registered in the >>> mapping with the RLOC of their RTR. The ServerXTR is just a tunnel >>> to the RTR and does not participate in the lisp control plane. The >>> clientXTR and ServerXTR solve NAT traversal between mobile and edge >>> providers. >> So, if I understood correctly, the serverXTR is registering its EID >> (H3.r9) to the mapping system using the RLOC of its associated RTR. > > Right > >> This process is done through Encap Map-Register of the serverXTR >> through the RTR or It is the serverXTR who is sending directly a >> Map-Register to the mapping system? > > Provisioned > >>   How does the RTR knows the the real RLOC of the serverXTR? is >> statically configured? or is learned through an Encap Map-Register? > > Through gleaning the feed from the server it signal-free subscribed to > >>> >>> We left the door open to a more distributed implementation for >>> example by cell towers or RSU. In this case there is only one RTR >>> between clients and servers. >>> >>>> >>>> "/EdgeRTRs do not register MobilityClients’ EIDs at the mapping >>>> service as these are temporary-renewed while using the mobility >>>> network./": Does the Client-XTR send Map Registers to the EdgeRTR? >>>> If not, how does it know the Client-xTR's RLOCs and its changes?. >>>> Otherwise, If it sends Map-Register, can we consider the EdgeRTR as >>>> the MS of the Client-xTR? >>> >>> At this point we do not allow unicast between clients, only publish >>> clients to servers, and signal free feed servers to clients. >> >> If no registration process exists of the MobilityClients' EID, how >> does the edgeRTR knows the MobilityClient's RLOC that should be used >> to send the multicast packets? (Specially if a change of RLOC is >> produced) >> > > The clientXTR and its RTR are co-providioned. > The client must MLD report to a channel to ensure > - its RTR signal-free registers > - its RTR replicates to it >> >> Best regards >> >> Albert >> >>>> >>>> Is there any mechanism contemplated for the MobilityClient to >>>> change the associated EdgeRTRs? for instance repeating the >>>> procedure explained in section 4 when changing to a new H3.9 section? >>>> >>> >>> Yes clients can repeat AAA procedure and are supposed to renew AAA. >>>> >>>> I think that more references need to be added to the document like >>>> the DIAMETER RFC. >>>> >>> >>> >>> Will add >>>> >>>> I hope these comments could help to improve the document. >>>> >>> >>> They do. I will clarify the language and send update as soon as all >>> inputs are in. >>> Thank you for devoting the time and attention. >>> >>>> Best regards >>>> >>>> Albert López >>>> >>>> >>>> >>>> >>>> On 3/2/21 16:25, Luigi Iannone wrote: >>>>> Hi All, >>>>> >>>>> The authors of draft-ietf-lisp-nexagon submitted the current >>>>> version back in October solving issues raised during SECDIR review. >>>>> No further comments have been raised and the authors consider the >>>>> document stable and ready for  WG Last Call. >>>>> >>>>> This email open the usual two weeks Working Group Last Call, to >>>>> end February 17th, 2021. >>>>> >>>>> Please review this WG document and let the WG know if you agree >>>>> that it is ready to be handed over to the AD. >>>>> If you have objections, please state your reasons why, and explain >>>>> what it would take to address your concerns. >>>>> >>>>> NOTE: silence IS NOT consensus! >>>>> >>>>> Thanks >>>>> >>>>> Luigi & Joel >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp --------------68DC38941C7A83DF9C792112 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks for your explanations. Now it is more clear to me.

Best regards

Albert

On 8/2/21 13:44, Sharon Barkai wrote:
Thanks Albert for pointing out these possible confusion points. Answering inline ..
But first would like to clarify the exact subset of LISP we leverage for the Nexagon mobility network.

1. The MobilityClients and H3Services use the LISP XTR network over tunnels to mitigate multi-access-provider multi-edge-provider challenges such as NAT or multi-tenancy in clusters or edge device OS.  

The simplest choice is to use data-path LISP tunnels: 
-ClientXTR
-ServerXTR 
But these do not participate in the mapping control plane.

              Mapping System
                    /                \
sXTR=RTR1 :::::::::: RTR2=cXTR

2. Nexagon is a mobility geospatial pub-sub network, road-segments are abstracted to EIDH3Services which are administratively provisioned based on load/availability to RTRs and the mapping system accordingly. Their global RLOC is their RTR (RTRs in multi homing).

Clients subscribe to these geospatial feed using MLD and SignalFree Mcast, which means their RTRs subscribe for them to (s,g) feeds. Their RTRs are assigned by AAA. The AAA provisioning is done both at the client and the RTR. The RTR does mcast replication to to all the clients it is homing and that have MLD subscribed through them to (s,g) or (location, theme) mcast feeds.

After they subscribe, some of the clients may also publish geospatial detections, depending on their EID credentials (rw/ro). When they do the RTR RLOC of the H3Service (this time as dest EID) is gleaned into the map-cache of the client RTR - which is subscribed to that H3EIDService as a feed (source).

Clients may NOT talk to each-other or learn each other's EIDs. The Nexagon network overlay is strictly brokered. 

If the above computes, welcome any suggestion that prevents reading the draft differently.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

On Feb 8, 2021, at 12:05, Albert López <alopez@ac.upc.edu> wrote:


Hi Sharon,

Thanks for your clarifications. I have some questions inline.

On 5/2/21 13:31, Sharon wrote:
Thank you Albert. These are very good comments. See inline:

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

On Feb 5, 2021, at 12:26, Albert López <alopez@ac.upc.edu> wrote:


Hi all,

After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done.

Some comments and questions that I have when reading the document are the following ones:

In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them.

I will add more text on the nexagon header. In principle these are:

Type: we specify two types only here
kv, kv, kv... basic and default use
v, k, k, k .. for large area with same value
proprietary extensions add more types

Gzip: is a flag if the k,v where zipped.
In close by tiles the compression is high

Reserved:

Pair count: how many kv are we sending,
in kv kv or v kkk form 


"EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs?

The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers.
So, if I understood correctly, the serverXTR is registering its EID (H3.r9) to the mapping system using the RLOC of its associated RTR.

Right

This process is done through Encap Map-Register of the serverXTR through the RTR or It is the serverXTR who is sending directly a Map-Register to the mapping system?

Provisioned

  How does the RTR knows the the real RLOC of the serverXTR? is statically configured? or is learned through an Encap Map-Register?

Through gleaning the feed from the server it signal-free subscribed to


We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers.


"EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network.": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?

At this point we do not allow unicast between clients, only publish clients to servers, and signal free feed servers to clients.

If no registration process exists of the MobilityClients' EID, how does the edgeRTR knows the MobilityClient's RLOC that should be used to send the multicast packets? (Specially if a change of RLOC is produced)


The clientXTR and its RTR are co-providioned.
The client must MLD report to a channel to ensure 
- its RTR signal-free registers 
- its RTR replicates to it 

Best regards

Albert


Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section?


Yes clients can repeat AAA procedure and are supposed to renew AAA.

I think that more references need to be added to the document like the DIAMETER RFC.



Will add

I hope these comments could help to improve the document.


They do. I will clarify the language and send update as soon as all inputs are in.
Thank you for devoting the time and attention. 

Best regards

Albert López




On 3/2/21 16:25, Luigi Iannone wrote:
Hi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.

Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--------------68DC38941C7A83DF9C792112-- From nobody Tue Feb 9 06:54:12 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0AC3A0D79 for ; Tue, 9 Feb 2021 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.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 6qZ0LvREr_lM for ; Tue, 9 Feb 2021 06:54:08 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 C76253A0D97 for ; Tue, 9 Feb 2021 06:54:07 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id u14so22279300wri.3 for ; Tue, 09 Feb 2021 06:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:cc:to:message-id; bh=Jo1ECEEzTtGqUk3yjKAMWxHQEBamHodPE/AUxAzC8jA=; b=HOF0nJqydX2wjbV/YDK2mY3LGQGDPoRlar9wFOsCe6Zzo2fRVX+ZMF7E8k172hL7SU u/QBB6lfmXyF+EANHKSg5qsrltk63xmnnCYNT4Izs6sOUunScWt+6cCa24VoGtT1XpQI 01JD/PdIoLHCIMmMjaBPYZv/eOxdOQGTfD+6ZkWBa4H9GiiK7fUbrlO2YKI+vbOGeNRG DLewdvNnnKVl8JEcBb/OEXphdN1rZwrh29KtVL/XoKPDDeywj/ipqKRgTLaRBisc1uEe xnmG9tL00IU9PaCrBnSI0CCLTIQmIgGql/7F7ljrev5j/CZ1HDByzvS8QxkPti0uohCM FnRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=Jo1ECEEzTtGqUk3yjKAMWxHQEBamHodPE/AUxAzC8jA=; b=LbzIKMDsIUcmgaYuHl/u+uyxU8esTsNz8gPI52tB2TwVY0aaM+U1+HtAdA/h8L7P5s 2yUjGDDQQNl68xTh/CpviEE8m4zXdAfUqUR3hwfEzlz557vTisw1/6UeXGIRJilskspR BWBhGEMduu5iq8Msi4tQAVEoxbxreSMXgi9XdlFnJYu6fi5nA7VFPQ+blQgwBk9E6EIr dYj8Lucgjm8Z87KY+2BM9t2yn/bTg/b8vSE5aEBJyv7GjeG0w08yt8iuR0GXGIwaRRva Lfo0ltMLj7BiLlrU5CS+klJuUHDukB6JSezgYev1mz5B9jqDXttPIhyyT8EpqhdhHfib WoHQ== X-Gm-Message-State: AOAM532mbATH4BZdi1XwHUoajdaq1NJC9TY+8aID+8F7GQtCFhyavbvf ukylOeCWl4r51LflVrwODeT83vwgNR5HMQ== X-Google-Smtp-Source: ABdhPJykD8KzUoWAjey8nyMJ5PbwOlJ40EWhrVzJAIjdVSz58lqogdagoSbkuc3jfS7MtyE1OCV+DA== X-Received: by 2002:a5d:4806:: with SMTP id l6mr26602657wrq.389.1612882445503; Tue, 09 Feb 2021 06:54:05 -0800 (PST) Received: from ?IPv6:2a01:e0a:1ec:470:e997:23fb:b292:6f76? ([2a01:e0a:1ec:470:e997:23fb:b292:6f76]) by smtp.gmail.com with ESMTPSA id j40sm4617574wmp.47.2021.02.09.06.54.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 06:54:04 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_673FE647-939B-4A5A-A413-2D0EDA8CB695" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 9 Feb 2021 15:54:03 +0100 References: <161257290585.16296.10283421370309856637@ietfa.amsl.com> Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" Message-Id: <5D2270EA-972C-414D-9EE9-1F737FA6666F@gigix.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [lisp] Call for Agenda Items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 14:54:10 -0000 --Apple-Mail=_673FE647-939B-4A5A-A413-2D0EDA8CB695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, The preliminary agenda is out and it seems that we are meeting on = Friday. While the agenda may still change it is about time to call for agenda = items. Please if you want a slot send a message to the chairs by February 23rd = at latest (we will publish a draft agenda on February 24th). Thanks Ciao L. =20 > Begin forwarded message: >=20 > From: IETF Agenda > Subject: IETF 110 Preliminary Agenda > Date: 6 February 2021 at 01:55:06 CET > To: "IETF Announcement List" > Cc: ietf@ietf.org, 110all@ietf.org > Reply-To: support@ietf.org >=20 > The IETF 110 Preliminary Agenda has been posted. The final agenda will = be published on Friday, February 12, 2021. >=20 > https://datatracker.ietf.org/meeting/110/agenda.html > https://datatracker.ietf.org/meeting/110/agenda.txt >=20 > The preliminary agenda includes all planned WG, RG, and BoF sessions. = We are still finalizing details for a few of our usual meeting-adjacent = events, so please look out for further details about those. Information = about side meeting signups will be available when the final agenda is = posted. >=20 > Please note the agenda times are listed in CET (UTC +1) by default. = You may select which time zone is displayed on the HTML version of the = agenda with a menu on the right side of the page. Choose =E2=80=9CMeeting = Timezone=E2=80=9D for CET, =E2=80=9CLocal Timezone=E2=80=9D for your own = current time zone, =E2=80=9CUTC=E2=80=9D for UTC, or choose any other = time zone from the drop down list.=20 >=20 >=20 > IETF 110 Information: https://www.ietf.org/how/meetings/110/ > Register online at: https://registration.ietf.org/110/ >=20 > Don=E2=80=99t forget to register for these exciting IETF 110 events! >=20 >=20 > Hackathon=20 > Signup: https://registration.ietf.org/110/new/hackathon/ > More information: = https://www.ietf.org/how/runningcode/hackathons/110-hackathon/ > Keep up to date by subscribing to:=20 > https://www.ietf.org/mailman/listinfo/hackathon >=20 > Code Sprint > Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110SprintSignUp > More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110Sprint >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_673FE647-939B-4A5A-A413-2D0EDA8CB695 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks,

The = preliminary agenda is out and it seems that we are meeting on = Friday.

While = the agenda may still change it is about time to call for agenda = items.

Please = if you want a slot send a message to the chairs by February 23rd at = latest (we will publish a draft agenda on February 24th).

Thanks

Ciao

L.
   

Begin = forwarded message:

From: = IETF Agenda <agenda@ietf.org>
Subject: = IETF 110 = Preliminary Agenda
Date: = 6 February 2021 at 01:55:06 = CET
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org, 110all@ietf.org
Reply-To: = support@ietf.org

The= IETF 110 Preliminary Agenda has been posted. The final agenda will be = published on Friday, February 12, 2021.

https://datatracker.ietf.org/meeting/110/agenda.html
https://datatracker.ietf.org/meeting/110/agenda.txt

The preliminary agenda includes all planned = WG, RG, and BoF sessions. We are still finalizing details for a few of = our usual meeting-adjacent events, so please look out for further = details about those. Information about side meeting signups will be = available when the final agenda is posted.

Please note the agenda times are listed in CET (UTC +1) by = default. You may select which time zone is displayed on the HTML version = of the agenda with a menu on the right side of the page. Choose = =E2=80=9CMeeting Timezone=E2=80=9D for CET, =E2=80=9CLocal Timezone=E2=80=9D= for your own current time zone, =E2=80=9CUTC=E2=80=9D for UTC, or = choose any other time zone from the drop down list.


IETF 110 Information: = https://www.ietf.org/how/meetings/110/
Register online at: = https://registration.ietf.org/110/

Don=E2=80=99= t forget to register for these exciting IETF 110 events!

Hackathon
Signup: = https://registration.ietf.org/110/new/hackathon/
More = information: = https://www.ietf.org/how/runningcode/hackathons/110-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110Sprint

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail=_673FE647-939B-4A5A-A413-2D0EDA8CB695-- From nobody Tue Feb 9 07:51:34 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3B3A0E7F; Tue, 9 Feb 2021 07:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 YOjuWerIUQBd; Tue, 9 Feb 2021 07:51:28 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1D73A0E82; Tue, 9 Feb 2021 07:51:27 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 119FpPx8021841; Tue, 9 Feb 2021 16:51:25 +0100 Received: from [192.168.68.111] (249.red-81-32-161.dynamicip.rima-tde.net [81.32.161.249]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 6E46B193; Tue, 9 Feb 2021 16:51:20 +0100 (CET) To: Luigi Iannone , "lisp@ietf.org list" Cc: lisp-chairs@ietf.org References: From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: <26fec308-9059-17ab-9899-9c2a9c0e6984@ac.upc.edu> Date: Tue, 9 Feb 2021 16:51:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9BBA0908E76028FEE2D4BDE6" Content-Language: en-US Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 15:51:33 -0000 This is a multi-part message in MIME format. --------------9BBA0908E76028FEE2D4BDE6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, As a co-author I believe this document is ready to hand it to the AD. Thanks, Jordi El 3/2/21 a les 16:25, Luigi Iannone ha escrit: > Hi All, > > The authors of draft-ietf-lisp-nexagon submitted the current version > back in October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the > document stable and ready for  WG Last Call. > > This email open the usual two weeks Working Group Last Call, to end > February 17th, 2021. > > Please review this WG document and let the WG know if you agree that > it is ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain > what it would take to address your concerns. > > NOTE: silence IS NOT consensus! > > Thanks > > Luigi & Joel > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------9BBA0908E76028FEE2D4BDE6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,

As a co-author I believe this document is ready to hand it to the AD.

Thanks,

Jordi

El 3/2/21 a les 16:25, Luigi Iannone ha escrit:
Hi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 17th, 2021.

Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--------------9BBA0908E76028FEE2D4BDE6-- From nobody Thu Feb 11 12:26:10 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216DA3A190C; Thu, 11 Feb 2021 12:26:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Cc: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, db3546@att.com, The IESG , Luigi Iannone , ggx@gigix.net, rfc-editor@rfc-editor.org, lisp@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161307516211.1403.1794025281733383001@ietfa.amsl.com> Date: Thu, 11 Feb 2021 12:26:02 -0800 Archived-At: Subject: [lisp] Protocol Action: 'The Locator/ID Separation Protocol (LISP)' to Proposed Standard (draft-ietf-lisp-rfc6830bis-36.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 20:26:02 -0000 The IESG has approved the following document: - 'The Locator/ID Separation Protocol (LISP)' (draft-ietf-lisp-rfc6830bis-36.txt) as Proposed Standard This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ Technical Summary This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. Working Group Summary The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related on including some features/improvements not present in RFC 6830. On the organization of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document there has been quite some discussion. This document was previously reviewed by the IESG, due to the technical changes which have been made, it was Last Called again and re-balloted. Document Quality There are several independent implementations of the LISP data-plane. Personnel Who is the Document Shepherd for this document? Luigi Iannone Who is the Responsible Area Director? Deborah Brungard From nobody Thu Feb 11 12:30:22 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3B3A1922; Thu, 11 Feb 2021 12:30:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Cc: lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com, The IESG , Luigi Iannone , ggx@gigix.net, draft-ietf-lisp-rfc6833bis@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161307541784.5722.15506256232903499937@ietfa.amsl.com> Date: Thu, 11 Feb 2021 12:30:17 -0800 Archived-At: Subject: [lisp] Protocol Action: 'Locator/ID Separation Protocol (LISP) Control-Plane' to Proposed Standard (draft-ietf-lisp-rfc6833bis-30.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 20:30:18 -0000 The IESG has approved the following document: - 'Locator/ID Separation Protocol (LISP) Control-Plane' (draft-ietf-lisp-rfc6833bis-30.txt) as Proposed Standard This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ Technical Summary This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. Working Group Summary The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related on including some features/improvements not present in RFC 6833 and adding text that originally was in the LISP data-plane document. On the organization of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document, there has been quite some discussion. This document was previously reviewed by the IESG, due to the technical changes which have been made, it was Last Called again and re-balloted. Document Quality There are at least three independent implementations of the LISP control-plane. Personnel Who is the Document Shepherd for this document? Luigi Iannone Who is the Responsible Area Director? Deborah Brungard From nobody Fri Feb 12 16:36:50 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC433A1171; Fri, 12 Feb 2021 16:33:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: db3546@att.com, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640888.31337.13108048823200937471@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:28 -0800 Archived-At: Subject: [lisp] lisp - Requested session has been scheduled for IETF 110 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:37 -0000 Dear Luigi Iannone, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lisp Session 1 (2:00 requested) Friday, 12 March 2021, Session I 1300-1500 Room Name: Room 5 size: 505 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/lisp.ics Request Information: --------------------------------------------------------- Working Group Name: Locator/ID Separation Protocol Area Name: Routing Area Session Requester: Luigi Iannone Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: Chair Conflict: rtgwg nvo3 i2rs grow sfc pim intarea lsr lsvr detnet maprg Technology Overlap: mboned icnrg irtfopen idr spring bier tsvwg Key Participant Conflict: bess People who must be present: Deborah Brungard Joel M. Halpern Luigi Iannone Padma Pillay-Esnault Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Feb 13 03:33:57 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB543A0F4D; Sat, 13 Feb 2021 03:33:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <161321603218.26243.15386779394640378871@ietfa.amsl.com> Date: Sat, 13 Feb 2021 03:33:52 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-nexagon-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 11:33:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Network-Hexagons: H3-LISP GeoState & Mobility Network Authors : Sharon Barkai Bruno Fernandez-Ruiz S ZionB Rotem Tamir Alberto Rodriguez-Natal Fabio Maino Albert Cabellos-Aparicio Dino Farinacci Filename : draft-ietf-lisp-nexagon-07.txt Pages : 19 Date : 2021-02-13 Abstract: This document specifies use of H3 and LISP to publish-subscribe and reflect the real-time state and status of public road segments by: - Tile-by-tile IPv6 addressable digital-twin of each road-segment - Tile by tile, indexed annotation of streets & curbs in near real time - Sharing hazards, blockages, parking, weather, maintenance, inventory.. - Brokering MobilityClients producing and consuming geo-state information - Reflected in geo-spatial IP multicast channels to subscribed clients The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-nexagon/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-nexagon-07 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-nexagon-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 13 03:44:05 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6CB3A0FED for ; Sat, 13 Feb 2021 03:44:03 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=getnexar.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 wma-GdYfpofT for ; Sat, 13 Feb 2021 03:44:01 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 A597C3A0FEF for ; Sat, 13 Feb 2021 03:44:01 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id v7so2830650eds.10 for ; Sat, 13 Feb 2021 03:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ssJAHtuE5ZX4WpjZhMfehjHjp+L6SyAQ7mTXE6KypA8=; b=IaxF+bhXCKzA1rQ6iiOaTFE0Vo53OgC1ivSUGCi+kAQu0XQOYooDd+OiaWdNVKhz2H YH0nfOBSOSHVdVWW76QpnRWQvn/F29VvJykoDWs9B4lKrj0nnfnX1ubJh0ERZV9gHzVr CZ9eYolxfepEfFqRp2U5vBL/X5n04weLoQJ8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ssJAHtuE5ZX4WpjZhMfehjHjp+L6SyAQ7mTXE6KypA8=; b=JiYIhhKrzZF3cvOGyOh/C9LNSmeHCBkQrKbU+/qXctdmY9ObekGh7WVANMeM4RpZug Gt3lCCQ906pYCxi60pNlW9znp939R2UedFDBh3W9V4vHK1CsOM7quN40Olyt4HLHH8WG 8VAxjD7OZKpFPY2GgTVhO0AaYKlZpvRTWwECrv1kV+szM1cxLeE84FVLS+2pYKQKpc+z sadyAL3xzSP4zsvbXJ9DRmJB3Ucs6MXjs112zXpPd6ikQ+MCVVKxGcvp4aJzRE67YIUM F8+E4i/4kfKWaStwTryRhNKo/uN5QZ0p6Oo9SyJkNXyCxW0asXX7YJGp4WWlxBM44ugV rbOg== X-Gm-Message-State: AOAM532lqqiyS10XK84shGy/W7ziVkxhx6i0VMPKaaqQ4GikqNQHSF+1 LNsXfBKD7pPloaFn32+AhyardxVknwaxxPKNBxMzXreVXCLXLBy6ijJJNLMkAtW8MDD6wPp0Rsw fLReE6Cj6OcSbASDsjysMFi6ByYQqNesXBQTBmGvHo9qtmx7V4pdgJ9CYivQ0kQSGV8w= X-Google-Smtp-Source: ABdhPJwVUMkjw71pAfzrox2Uzj8dDuwp0oMzxrwvb04jUptTwgT7qEEgbw65y/Dwl9RPKsveGPlYsg== X-Received: by 2002:aa7:d58b:: with SMTP id r11mr7426776edq.241.1613216639733; Sat, 13 Feb 2021 03:43:59 -0800 (PST) Received: from ?IPv6:2001:4df4:398:e400:11c8:4fba:7088:5d2a? ([2001:4df4:398:e400:11c8:4fba:7088:5d2a]) by smtp.gmail.com with ESMTPSA id v9sm7512016ejd.92.2021.02.13.03.43.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 03:43:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Sharon Barkai In-Reply-To: <161321603218.26243.15386779394640378871@ietfa.amsl.com> Date: Sat, 13 Feb 2021 13:43:56 +0200 Cc: lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <161321603218.26243.15386779394640378871@ietfa.amsl.com> To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-07.txt Last Call X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 11:44:03 -0000 The bellow submission addresses point raised during WGLC - clear how H3EIDServices -> EdgeRTR RLOC mapping is set - clear the text of the LISP-Nexagon header fields: type, gzip, count - add reference to DIAMETER RFC used to AAA MobilityEIDClients With that and if there are no more comments hopefully we can conclude = LISP-NEXAGON WGLC Special thanks to Albert who pointed out these items. > On Feb 13, 2021, at 13:33, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol WG of = the IETF. >=20 > Title : Network-Hexagons: H3-LISP GeoState & Mobility = Network > Authors : Sharon Barkai > Bruno Fernandez-Ruiz > S ZionB > Rotem Tamir > Alberto Rodriguez-Natal > Fabio Maino > Albert Cabellos-Aparicio > Dino Farinacci > Filename : draft-ietf-lisp-nexagon-07.txt > Pages : 19 > Date : 2021-02-13 >=20 > Abstract: > This document specifies use of H3 and LISP to publish-subscribe and = reflect > the real-time state and status of public road segments by: > - Tile-by-tile IPv6 addressable digital-twin of each road-segment > - Tile by tile, indexed annotation of streets & curbs in near real = time > - Sharing hazards, blockages, parking, weather, maintenance, = inventory.. > - Brokering MobilityClients producing and consuming geo-state = information > - Reflected in geo-spatial IP multicast channels to subscribed = clients >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-nexagon/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-nexagon-07 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-nexagon-07 >=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 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Feb 14 15:16:47 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC83A3A0D38; Sun, 14 Feb 2021 15:16:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <161334460179.29003.15060209319855031708@ietfa.amsl.com> Date: Sun, 14 Feb 2021 15:16:41 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-mn-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 23:16:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP Mobile Node Authors : Dino Farinacci Darrel Lewis David Meyer Chris White Filename : draft-ietf-lisp-mn-09.txt Pages : 25 Date : 2021-02-14 Abstract: This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-mn-09 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-mn-09 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 Feb 22 14:16:38 2021 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9D83A20ED; Mon, 22 Feb 2021 14:16:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <161403219415.19435.2994591973695983372@ietfa.amsl.com> Date: Mon, 22 Feb 2021 14:16:34 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-yang-15.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 22:16:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP YANG Model Authors : Vina Ermagan Alberto Rodriguez-Natal Florin Coras Carl Moberg Reshad Rahman Albert Cabellos-Aparicio Fabio Maino Filename : draft-ietf-lisp-yang-15.txt Pages : 82 Date : 2021-02-22 Abstract: This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-yang-15 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-yang-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-yang-15 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 Tue Feb 23 23:17:23 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADAE3A0CE1 for ; Tue, 23 Feb 2021 23:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=gigix-net.20150623.gappssmtp.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 r9HXjOB4OfsL for ; Tue, 23 Feb 2021 23:17:20 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 81C473A0CDD for ; Tue, 23 Feb 2021 23:17:20 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id t15so802525wrx.13 for ; Tue, 23 Feb 2021 23:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nRK4vobGLHoUUGsQNmBiNFCbBRrBUu0Rxnz/fKe9NOk=; b=fHGCWQoxO0COq0uQQfgSfjofFci0jl8wk925VKH+jHoatzl68XbrEmgWAWphJq9vzI S3XvzjWy7VRMfKuv696UJbzrK6ZIYt4/y8BhPUqLV4dFJDr5isYA7h0oQ0IAVN/Dj9PQ RDM41mXLtXZqtvGKvWzqJ/HP6BFYaK4qb0ZFBsdkQ12e1zfM7S10v5O0i9d16daSXbWy 0xKnrEIND643NMLW3ip7gJzIb7WFMJtPs+n4ZX9XNB7WDTWX/BRcgDAYg6tHaDScmTSf 9gUegTw62d+7n/oQcGxZF1W936/cBLJ2ohoxbmpdP2Lh6x8xBxkK3tdszAD85rOVIL5z jq7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nRK4vobGLHoUUGsQNmBiNFCbBRrBUu0Rxnz/fKe9NOk=; b=fqDNfm20AUO3curadxU/IUSQKVR07ZCX7XIVFAgYN2IneC2kfzSfdhXSa+EvgNTYmk UtseK22q51pVYUavmYgt5yB+aLMSToF81+0nzwH5yaZsCqGT+t/V1Q/aFqFSaccy+ln1 jGpbfXHesCF6GljgJu9/Vc34NDa1bxq4ngF0zfYXD1B4T7QYp/4DJHmFxHjIZ+JegMSv VuuGaAxG57lDhW0F8LHMyOBaNYVKq/maeflCXf013CcX2DLamNwnh65Pi7ge/5GaIqLd DrK0xDoU/WI4nOP7/8GnHuMg4CvPhAulBGSswXyoWnUq/GA8ly9QWoxvkKQISpDZoHUw LqLg== X-Gm-Message-State: AOAM530AmpCvdtVSe4F/Ry1px3lJ5nKWWDIoU+U5PLlhxyjWYJSU+7Pf Uq3ocOFPDDzxglbujnU/CfH+LKgeIDBYUw== X-Google-Smtp-Source: ABdhPJzYns/uQ9OvVzI8Gmz7SaDeeG0Gkrs78gubUKRCD9kGXFI2bjDIXk+zboyZMb+IYE3V/G8aqg== X-Received: by 2002:a5d:58fb:: with SMTP id f27mr29682702wrd.119.1614151037343; Tue, 23 Feb 2021 23:17:17 -0800 (PST) Received: from ?IPv6:2a01:e0a:1ec:470:c879:4ed9:8503:c90e? ([2a01:e0a:1ec:470:c879:4ed9:8503:c90e]) by smtp.gmail.com with ESMTPSA id s124sm1286663wms.40.2021.02.23.23.17.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 23:17:16 -0800 (PST) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F9348B7F-7E2D-46F3-A57F-4F20C740FC42" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Feb 2021 08:17:15 +0100 In-Reply-To: Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" References: X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 07:17:22 -0000 --Apple-Mail=_F9348B7F-7E2D-46F3-A57F-4F20C740FC42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, while this document has gathered attention during face to face meetings, = we received very few email in support of WG LC! In order to gather more consensus we prefer to extend the Last Call = period by two weeks, to end by March 10th.=20 Please speak up and state whether or not this document is ready to be = published. Ciao Luigi & Joel =20 > On 3 Feb 2021, at 16:25, Luigi Iannone wrote: >=20 > Hi All, >=20 > The authors of draft-ietf-lisp-nexagon submitted the current version = back in October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the = document stable and ready for WG Last Call. >=20 > This email open the usual two weeks Working Group Last Call, to end = February 17th, 2021. >=20 > Please review this WG document and let the WG know if you agree that = it is ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >=20 > NOTE: silence IS NOT consensus! >=20 > Thanks >=20 > Luigi & Joel --Apple-Mail=_F9348B7F-7E2D-46F3-A57F-4F20C740FC42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks,

while this document has gathered attention during face to = face meetings, we received very few email in support of WG LC!

In order to gather more = consensus we prefer to extend the Last Call period by two weeks, to end = by March 10th. 

Please = speak up and state whether or not this document is ready to be = published.

Ciao

Luigi & Joel
 

On 3 Feb = 2021, at 16:25, Luigi Iannone <ggx@gigix.net> wrote:

Hi All,

The authors of =  draft-ietf-lisp-nexagon submitted the current version back in = October solving issues raised during SECDIR = review.
No further comments have been raised and the = authors consider the document stable and ready for  WG Last = Call.

This email open the usual two weeks Working Group Last Call, to = end February 17th, 2021.

Please review this WG = document and let the WG know if you agree that it is ready to be handed = over to the AD.
If you have objections, = please state your reasons why, and explain what it would take to address = your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi = & Joel

= --Apple-Mail=_F9348B7F-7E2D-46F3-A57F-4F20C740FC42-- From nobody Wed Feb 24 02:44:55 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407A13A138F for ; Wed, 24 Feb 2021 02:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=gigix-net.20150623.gappssmtp.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 8ycNM1MRH7nj for ; Wed, 24 Feb 2021 02:44:52 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 DBA743A138E for ; Wed, 24 Feb 2021 02:44:51 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id k66so1397455wmf.1 for ; Wed, 24 Feb 2021 02:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pJHfXxJNTQ17qpwCK9Y5/7ksuFIwm628u56CFbMZk/0=; b=hDK+dkYm/zITrwEnbvuhVZPq1oB2Via8gDxN3sL8w1CJvZETuyfgRK9nItcPYSREVW fKNumomrSoAgXWWp96b1MTbR737KAUmLArlm0ymVZtD+b4Eenn/V6x3XQSA/erjFUOzU CG0iovRQy8WB1ryx32LECklLRFgwmwcQbgupVo+GVe2rDya2+GaPyac9T1oTl9nIcB4Q Uhgy5tGttgA6qR899hqcw6KeYtkrZkEfwbI7tD/tyI9wUN1iz76hz91QKrSjfqNhgdmK s8WZhwaIDPGz+uDeZNN0SLn6XjdO3bd868w4Jo5KI3WR1PwqPEZ7CwuvXVhhsgC8LAXD kiRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pJHfXxJNTQ17qpwCK9Y5/7ksuFIwm628u56CFbMZk/0=; b=Y+4HoiXy36MmLmAr9znrijxkEIsnYAewhK6MRPI5LmMdlMMwmKdmwP73Z0dXJTOvDw T76Mi/FOp6DXG83bvTVtV5u7KreGj4bO9B1+S9DKZqN08aVl4cVDydR7PR9uecPaNJY2 +OGg1kPkRupDVAL4RjMzpdw160YhR7rSNUq0eOjsRi5GPXFsd8eGp4XtIuZAzd9OiBLF Tt0dswiTHJkEfuWDLbDnvi/RRjGNH3OD9fwbtc/YivDjDf4Ef6A7W8NRLJ8m8Ohja6t8 duKJwLFdUdoPdcDC0AZ3o9cCZll3V/Sy/G73zhskWq2cVFvXTcxagdtZ5fzVlELpFEii yr2w== X-Gm-Message-State: AOAM530EdjaxmDIaDqfL6/ET6Z2JzFTfga3TnsJi9crjseZXEEuBWnaA 0+RzUDGltNiv1AtbD8DDJXb/hEOhvbgRFg== X-Google-Smtp-Source: ABdhPJw/lTV/s2apx/se+/cn2nrvSM/Q6uejJzrcXKWNQivjA8l9PTU0inoHlcgb2FscdoKOSnOZcA== X-Received: by 2002:a1c:4603:: with SMTP id t3mr3169633wma.135.1614163489986; Wed, 24 Feb 2021 02:44:49 -0800 (PST) Received: from ?IPv6:2a01:e0a:1ec:470:c879:4ed9:8503:c90e? ([2a01:e0a:1ec:470:c879:4ed9:8503:c90e]) by smtp.gmail.com with ESMTPSA id v6sm2714286wrx.32.2021.02.24.02.44.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Feb 2021 02:44:48 -0800 (PST) From: Luigi Iannone Message-Id: <2F26C9C2-5180-4506-8DAB-E5D5FE242B2C@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_D1545067-7A10-44E2-8798-4CF7F2022432" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Feb 2021 11:44:47 +0100 In-Reply-To: <5D2270EA-972C-414D-9EE9-1F737FA6666F@gigix.net> Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" References: <161257290585.16296.10283421370309856637@ietfa.amsl.com> <5D2270EA-972C-414D-9EE9-1F737FA6666F@gigix.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [lisp] Call for Agenda Items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 10:44:54 -0000 --Apple-Mail=_D1545067-7A10-44E2-8798-4CF7F2022432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, either I have a mail problem or there is not that much to discuss in the = next IETF. As you can see below the agenda is pretty empty. Please let us know ASAP if you want a slot. Thanks Ciao Joel & Luigi CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Luigi Iannone ( ggx AT gigix.net ) SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com ) AGENDA Session 1/1 (120 Minutes) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Friday, March 21, 2021 12:00 - 14:00 (UTC), Session I, 120 Minutes (20:00 - 22:00 Beijing) (13:00 - 15:00 Paris) (7:00 - 9:00 New York)=20 (4:00 - 6:00 San Francisco) Room 6: = https://meetings.conf.meetecho.com/ietf110/?group=3Dlisp&short=3D&item=3D1= - Administration Halpern/Iannone - Agenda Bashing - Status reports for WG drafts 10 Minutes (Cumulative Time: 10 Minutes) o WG Items - LISP Yang Model - = https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/ 10 Minutes (Cumulative Time: 20 Minutes) Alberto Rodriguez Natal Cabellos o Non WG Items - Overflow Time/ Discussion 100 Minutes (Cumulative Time: 120 Minutes) > On 9 Feb 2021, at 15:54, Luigi Iannone wrote: >=20 > Folks, >=20 > The preliminary agenda is out and it seems that we are meeting on = Friday. >=20 > While the agenda may still change it is about time to call for agenda = items. >=20 > Please if you want a slot send a message to the chairs by February = 23rd at latest (we will publish a draft agenda on February 24th). >=20 > Thanks >=20 > Ciao >=20 > L. > =20 >=20 >> Begin forwarded message: >>=20 >> From: IETF Agenda > >> Subject: IETF 110 Preliminary Agenda >> Date: 6 February 2021 at 01:55:06 CET >> To: "IETF Announcement List" > >> Cc: ietf@ietf.org , 110all@ietf.org = >> Reply-To: support@ietf.org >>=20 >> The IETF 110 Preliminary Agenda has been posted. The final agenda = will be published on Friday, February 12, 2021. >>=20 >> https://datatracker.ietf.org/meeting/110/agenda.html = >> https://datatracker.ietf.org/meeting/110/agenda.txt >>=20 >> The preliminary agenda includes all planned WG, RG, and BoF sessions. = We are still finalizing details for a few of our usual meeting-adjacent = events, so please look out for further details about those. Information = about side meeting signups will be available when the final agenda is = posted. >>=20 >> Please note the agenda times are listed in CET (UTC +1) by default. = You may select which time zone is displayed on the HTML version of the = agenda with a menu on the right side of the page. Choose =E2=80=9CMeeting = Timezone=E2=80=9D for CET, =E2=80=9CLocal Timezone=E2=80=9D for your own = current time zone, =E2=80=9CUTC=E2=80=9D for UTC, or choose any other = time zone from the drop down list.=20 >>=20 >>=20 >> IETF 110 Information: https://www.ietf.org/how/meetings/110/ >> Register online at: https://registration.ietf.org/110/ >>=20 >> Don=E2=80=99t forget to register for these exciting IETF 110 events! >>=20 >>=20 >> Hackathon=20 >> Signup: https://registration.ietf.org/110/new/hackathon/ >> More information: = https://www.ietf.org/how/runningcode/hackathons/110-hackathon/ >> Keep up to date by subscribing to:=20 >> https://www.ietf.org/mailman/listinfo/hackathon >>=20 >> Code Sprint >> Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110SprintSignUp >> More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110Sprint >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 --Apple-Mail=_D1545067-7A10-44E2-8798-4CF7F2022432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

either= I have a mail problem or there is not that much to discuss in the next = IETF.

As you = can see below the agenda is pretty empty.

Please let us know ASAP if you want a = slot.

Thanks

Ciao

Joel & Luigi




CHAIR(s):=  Joel Halpern ( jmh AT joelhalpern.com )
    =             Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Padma = Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA

Session 1/1 (120 = Minutes)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

Friday, March 21, = 2021
12:00 - 14:00 (UTC), Session I, 120 = Minutes
(20:00 - 22:00 Beijing)
(13:00 - 15:00 Paris)
(7:00 - 9:00 New = York) 
(4:00 - 6:00 San Francisco)
Room 6: https://meetings.conf.meetecho.com/ietf110/?group=3Dlisp&sh= ort=3D&item=3D1

- Administration
    = Halpern/Iannone
    - Agenda = Bashing
    - Status reports for WG = drafts
10 Minutes = (Cumulative Time: 10 Minutes)



o WG Items

- LISP Yang Model - https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/
  10 Minutes (Cumulative Time: 20 = Minutes)
  Alberto Rodriguez Natal =  Cabellos


o Non WG Items


- Overflow Time/ Discussion
  100 = Minutes (Cumulative Time: 120 Minutes)




On 9 Feb 2021, at 15:54, Luigi Iannone <ggx@gigix.net> = wrote:

Folks,

The preliminary agenda = is out and it seems that we are meeting on Friday.

While the agenda may = still change it is about time to call for agenda items.

Please if you want a = slot send a message to the chairs by February 23rd at latest (we will = publish a draft agenda on February 24th).

Thanks

Ciao

L.
   

Begin = forwarded message:

From: IETF Agenda <agenda@ietf.org>
Subject: IETF 110 Preliminary Agenda
Date: 6 February 2021 at 01:55:06 CET
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org, 110all@ietf.org
Reply-To: = support@ietf.org

The= IETF 110 Preliminary Agenda has been posted. The final agenda will be = published on Friday, February 12, 2021.

https://datatracker.ietf.org/meeting/110/agenda.html
https://datatracker.ietf.org/meeting/110/agenda.txt

The preliminary agenda includes all planned = WG, RG, and BoF sessions. We are still finalizing details for a few of = our usual meeting-adjacent events, so please look out for further = details about those. Information about side meeting signups will be = available when the final agenda is posted.

Please note the agenda times are listed in CET (UTC +1) by = default. You may select which time zone is displayed on the HTML version = of the agenda with a menu on the right side of the page. Choose = =E2=80=9CMeeting Timezone=E2=80=9D for CET, =E2=80=9CLocal Timezone=E2=80=9D= for your own current time zone, =E2=80=9CUTC=E2=80=9D for UTC, or = choose any other time zone from the drop down list.


IETF 110 Information: = https://www.ietf.org/how/meetings/110/
Register online at: = https://registration.ietf.org/110/

Don=E2=80=99= t forget to register for these exciting IETF 110 events!

Hackathon
Signup: = https://registration.ietf.org/110/new/hackathon/
More = information: = https://www.ietf.org/how/runningcode/hackathons/110-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF110Sprint

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


= --Apple-Mail=_D1545067-7A10-44E2-8798-4CF7F2022432-- From nobody Wed Feb 24 07:35:58 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C6B3A1727; Wed, 24 Feb 2021 07:35:57 -0800 (PST) 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, MIME_QP_LONG_LINE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnVQ8rliI9fA; Wed, 24 Feb 2021 07:35:55 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 36AA43A172B; Wed, 24 Feb 2021 07:35:54 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id d2so1560204pjs.4; Wed, 24 Feb 2021 07:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=6QiQVZuiAXpbutkFIpNIAI8iCAJoz6+daU0dNZaTeV4=; b=lUMptXM8bEuGZFhdJTZ0qMUuxysHlK85m6Aq3kLrxMknH7WIJfiF606MDrczrnO7u/ ejQkOBNyNfVdn+S1f+1X2ShwS7ID3CHmVG82CGa1qr+VfUmAJ5Ej+Iz2mOTrWBNya2U7 HPG0cCNfquCxZ1yQP6au+UYkQn5FX4cPcFMiaj0C9ED/Epb6Am3kvBWRZeduTu2iLGiU AxXKCg781Hh/9xqkrbRkbhal88I8gog21/0PEb6fg2A85m253GZTTHS2eLCd6HQ1OeE8 Eg8390ME8cDG6vKvi4J5+NPi48rpHULLT4QIWJGKLSS+qwJV3EtdSx+FMksaHGH6xA6U uB3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=6QiQVZuiAXpbutkFIpNIAI8iCAJoz6+daU0dNZaTeV4=; b=snvuBugxDPtw+K6GgfHTjZDwnZoxi9CAaE0aYrHIykdHzJogXz1cdjBjVCpRrs5VKF zmL6sPJZDdaZtJSYS5GdhtE+bocTyEEF6cojlLQ/+/+orgzqymIpIr1D1iuSWimzk4Xv 72MzRshha/WCibhFsdbzPutL0vqnEoiCEGz22Hd/d4h8cI01tCwXvF0/XXEAnmQXJ/QC ZQfZ7+rgKROEPLX2ZOJ7nTq76+Bd07rDdrcpsJFn36uTN3DErZIpfNFPjscgi/VcQLLl hNp4ukQ97RKN3O7VqvrzbBbqvEYArBEUyUbQzfopkqxnaPlaT6Bu0tAiIFc9NDTscb2a gi9A== X-Gm-Message-State: AOAM531V/+RLXDk8rW05w9+HmZVQXiABuyI3xg7orwI/sXT28kwR4bEd jQt3+R/IMcGMOo/4FpydsRg7aaykE+LVKQ== X-Google-Smtp-Source: ABdhPJweuQyfmYCpOxAPIAXAV4cxMF9k9T8gmqcemwMaheCB0CywqN1lX3qYri2ynN1KPTh8QvuaxA== X-Received: by 2002:a17:902:b711:b029:e3:71f1:e08e with SMTP id d17-20020a170902b711b02900e371f1e08emr8372475pls.18.1614180953260; Wed, 24 Feb 2021 07:35:53 -0800 (PST) Received: from ?IPv6:2601:646:9600:af10:c5df:1a9b:321b:590? ([2601:646:9600:af10:c5df:1a9b:321b:590]) by smtp.gmail.com with ESMTPSA id y123sm3204089pfb.122.2021.02.24.07.35.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Feb 2021 07:35:52 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-8275BC3F-35E0-4CEC-B65E-6B6150084B92 Content-Transfer-Encoding: 7bit From: Dino Farinacci Mime-Version: 1.0 (1.0) Date: Wed, 24 Feb 2021 07:35:50 -0800 Message-Id: <529C8F1C-4E23-4071-A4F0-03671CEFB0C8@gmail.com> References: Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org In-Reply-To: To: Luigi Iannone X-Mailer: iPhone Mail (18D52) Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 15:35:57 -0000 --Apple-Mail-8275BC3F-35E0-4CEC-B65E-6B6150084B92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support the document. It=E2=80=99s the third time I have sent support for i= t during its course of development.=20 Dino > On Feb 23, 2021, at 11:17 PM, Luigi Iannone wrote: >=20 > =EF=BB=BFFolks, >=20 > while this document has gathered attention during face to face meetings, w= e received very few email in support of WG LC! >=20 > In order to gather more consensus we prefer to extend the Last Call period= by two weeks, to end by March 10th.=20 >=20 > Please speak up and state whether or not this document is ready to be publ= ished. >=20 > Ciao >=20 > Luigi & Joel > =20 >=20 >> On 3 Feb 2021, at 16:25, Luigi Iannone wrote: >>=20 >> Hi All, >>=20 >> The authors of draft-ietf-lisp-nexagon submitted the current version bac= k in October solving issues raised during SECDIR review. >> No further comments have been raised and the authors consider the documen= t stable and ready for WG Last Call. >>=20 >> This email open the usual two weeks Working Group Last Call, to end Febru= ary 17th, 2021. >>=20 >> Please review this WG document and let the WG know if you agree that it i= s ready to be handed over to the AD. >> If you have objections, please state your reasons why, and explain what i= t would take to address your concerns. >>=20 >> NOTE: silence IS NOT consensus! >>=20 >> Thanks >>=20 >> Luigi & Joel >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-8275BC3F-35E0-4CEC-B65E-6B6150084B92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I support the document. It= =E2=80=99s the third time I have sent support for it during its course of de= velopment. 

Dino
=

On Feb 23, 2021, at 11:17 PM,= Luigi Iannone <ggx@gigix.net> wrote:

=EF=BB=BFFolks,

while this document has gathered attention duri= ng face to face meetings, we received very few email in support of WG LC!

In order to gather m= ore consensus we prefer to extend the Last Call period by two weeks, to end b= y March 10th. 

Please spea= k up and state whether or not this document is ready to be published.
<= div>
Ciao

Luigi= & Joel
 

On 3 Feb 2021, at 16:25, Luigi Iannone <ggx@gigix.net> wrote:
=
H= i All,

The authors of  draft-ietf-lisp-nexagon submitted the current versio= n back in October solving issues raised during SECDIR review.<= /div>
N= o further comments have been raised and the authors consider the document st= able and ready for  WG Last Call.

This email open the usual two weeks Working Group L= ast Call, to end February 17th, 2021.

Please review this WG docu= ment and let the WG know if you agree that it is ready to be handed over to t= he AD.
If you have objections, please state your r= easons why, and explain what it would take to address your concerns.

NOTE: silence IS NOT cons= ensus!

Thanks

Luigi & Joel
=
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
<= /body>= --Apple-Mail-8275BC3F-35E0-4CEC-B65E-6B6150084B92-- From nobody Wed Feb 24 07:56:48 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE353A1751; Wed, 24 Feb 2021 07:56:47 -0800 (PST) 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=NoBHdwbO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AfOhQEB8 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 KkzzA3FZ0dFY; Wed, 24 Feb 2021 07:56:44 -0800 (PST) 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 89E9E3A16E7; Wed, 24 Feb 2021 07:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12447; q=dns/txt; s=iport; t=1614182204; x=1615391804; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h/Y8vfAdg7HZ/xnLdvGP488Xg4FBUU001hZk1D4BkYs=; b=NoBHdwbOkzIKq58snRqtXdMJw/0WZyJVm0H6lsddVOlMsdj7RgLpOiAg HVWzDSqzkIyO3ieLhE2XvWGFAgvUcCfkmfjjGpae/NoYuFQgInHaJz6Qi CcUOA4zGZ7aeIwXW5aGPXJRj9tA1rD0SbpQJ9hqif4OoRb8tLvnB0zOyd 0=; X-IPAS-Result: =?us-ascii?q?A0BjAAATdjZg/51dJa1iHAEBAQEBAQcBARIBAQQEAQGBe?= =?us-ascii?q?wcBAQsBgSIwUQd2WjYxCgGENoNIA4RZYIg0JQOULYRzgS4UgREDVAsBAQENA?= =?us-ascii?q?QEyAgQBAYRNAheBYAIlNAkOAgMBAQEDAgMBAQEBBQEBAQIBBgRxhWENhkQBA?= =?us-ascii?q?QEEHQYdAQE3AQ8CAQgOAwMBAigDAgICMBQJCAIEAQ0FgmsBgX5XAy4BS6N7A?= =?us-ascii?q?ooldoEygwQBAQaCTIJCGIISCYE4AYJ1hAYBAYZEJhyBQUKBEScMEIJXPoQJA?= =?us-ascii?q?RIBQRaCYDSCK4FZEFtEJgRDMm9SAS6MHogTh0eeGgqCfJBDhTSGIwMfgzSKT?= =?us-ascii?q?ZMAgkmUTKITAgICAgQFAg4BAQaBIzE6Z3BwFTsqAYI+UBcCDY4fg2+KWXM4A?= =?us-ascii?q?gYBCQEBAwl8iggBMF4BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AlVjojxyutyQZRXnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/psg17ZG4PW96EMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK0MEdUCID4akGB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,203,1610409600"; d="scan'208,217";a="651499551" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Feb 2021 15:56:43 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 11OFuhvN031244 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2021 15:56:43 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 24 Feb 2021 09:56:43 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 24 Feb 2021 09:56:42 -0600 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; Wed, 24 Feb 2021 10:56:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IJZK5eiXBuyIIPMgMGHiQXzaZN5HnFQdIja3/bOB7vr9J6Tb/f/CrpC5L9tJYfQBwe+76uRVS+8Z6E0bKXBRnDqUWPxsGbF8D/rHX2AC6wq5UDC3Xk7ZS8d498GdlRu7DiYXIeMw7uzgbPIvQzqJWR7Lm3xuW3XkHWYCrHXbCc8VGHdSje2MR/R4rlFSpozmSyHuMxOet+ZTvPgpP906Bu7m7k0ca7tVhGbvqYj2z3ZFD+Z1CQZfF2FaWpxqi37cGVxdigYNy6WZX78V8wu9CgEwO/flPAhQts6Qr2kCMHq2SbTgpP6YMjTRexJbFFvogJh1P4IM1iVpzlI/7GiCBw== 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=h/Y8vfAdg7HZ/xnLdvGP488Xg4FBUU001hZk1D4BkYs=; b=HKAydv1Ci9OnkyD7uf0q5xJqhO3zSAu7USCTYIotZlqwqFFI3FZfYw6MJmwgkATxPhEEDddu2XkqXry4sSogEM2avR12Fx5ZTGoEXpMH7/9sErH1tNjL01I+61bvn4K1+Yd+b5RMxfZRX1VHVOE2ta99y0Lmni7NyXxdkKyiEnUvvDHZ8AB8dIiGcDNOa9jFKWtZM8ArvAFocAwrqLLLpclmm0VbYNc12IQ3PCfhwdZDsT6zKNbB8bb6KL/qaBpw5nbInZLao3/7YlOfF00/OBuXm30Xb5WQu88/MQTpfHyABKnT6A3mNef/RO90AwQXttHcsjLbzT34G1LUE20nKQ== 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=h/Y8vfAdg7HZ/xnLdvGP488Xg4FBUU001hZk1D4BkYs=; b=AfOhQEB8p/T2KZM3xQUiHaATwImHmAb2UAm/Yx+IRlJSGYudnkOeG4hVB6kRe2/Q8+XIUl+pVPtxq/w8CaxaM7DLPFs7P2E4UApo0NmvzZmCnmaqehn1aryiPO0CxFOiCuP7nc4ab5wXCgcKaw5bPsPXJMZRrwk87vJbtWxIZrg= Received: from BY5PR11MB4369.namprd11.prod.outlook.com (2603:10b6:a03:1cb::25) by SJ0PR11MB4880.namprd11.prod.outlook.com (2603:10b6:a03:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.31; Wed, 24 Feb 2021 15:56:41 +0000 Received: from BY5PR11MB4369.namprd11.prod.outlook.com ([fe80::90d9:cb57:c3a3:3d34]) by BY5PR11MB4369.namprd11.prod.outlook.com ([fe80::90d9:cb57:c3a3:3d34%5]) with mapi id 15.20.3868.034; Wed, 24 Feb 2021 15:56:41 +0000 From: "Fabio Maino (fmaino)" To: Luigi Iannone , "lisp@ietf.org list" CC: "lisp-chairs@ietf.org" Thread-Topic: [lisp] WG Last Call for draft-ietf-lisp-nexagon Thread-Index: AQHW+kDXLVSdt1SEQUe8IDr4FJ5aeKpnBaWAgAALBAA= Date: Wed, 24 Feb 2021 15:56:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: gigix.net; dkim=none (message not signed) header.d=none;gigix.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [75.25.137.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 275a7e46-a8b7-410c-bcaa-08d8d8dcc6e0 x-ms-traffictypediagnostic: SJ0PR11MB4880: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5A7vRgnJnJ42lfLmepDXQwIUf9Pzfxq1kpKL1I0HRnewHi6RC55/WyR/BETGLxtatF4pzkA2QBRts2bxykDd5OCmvN0fltdP0L7qlGbTpZUIuS+b3/FXG2IcxEpcYObWQxWucAIh0JRCjCL0smos77w9YMADKmKZPemvwGhYbT0Rn2ooiAa3oz0lM9ecagudUuIxdkUdMlyqB9BfMlI7pi3qyxcMxUZe21+8EPBP7rZJbQal59pooMH0jbSkrssO2IR4VwFboNQQsf3MenOsbO9G7ycRBZvF4MjN/IkoYXUHX/PBmoFz02kpRmo4ayQcbldz998JYz3qgC7mf1Z4Ch1T6XrcM9dQFs0O3ErgHmczNA4bIDFNIe4j6ajd2EaYDhrCuCXoqIRDiyf3+DsN38RH2i6+Xw8s60bH6I+P2OXGKbHo60h9owsT7xUsW55/v1PAwCOo19nq5F5/VJq2ySvQUGysTvseFwSEZIcoIlnpkT6XRam0WYbcMxC0mJVDm12qCxBUdBWU62j5s+2cMm9u47x44V2M6n070pS9G0zjex4aaIPYxlb6YOwEZJ+gW6eMAZyNcz0uD6Cz5Kj0CQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4369.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(396003)(39860400002)(376002)(316002)(66946007)(66476007)(4326008)(5660300002)(33656002)(83380400001)(86362001)(8936002)(2906002)(71200400001)(66556008)(6506007)(64756008)(110136005)(6512007)(66446008)(6486002)(36756003)(478600001)(26005)(76116006)(2616005)(8676002)(186003)(53546011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?b1hhbEpIbi9FaFRxb2hkZ2xiVmlPNk01TE9MbVhCeVBCUjJmWTNOclB1MW5k?= =?utf-8?B?U3Y5cHlhM1BkMDEvSFd0OUxKam93bXRSRHFzb1J2ckkxeDZGY0dsdUVMVGVI?= =?utf-8?B?U3dHQm1CTGtBc0xFMm1tQk5RdEovcDN1cG9JcXFkOUJGWGZzVHVNSmFCYTgr?= =?utf-8?B?a0dKVUZ6L1dKc0R5STU5OUJMaVhHUXFCa0U5Z1NRVmlReFBBOHlucCsxN1hP?= =?utf-8?B?ZmlMQ1UvNHIzOHpRNi9BTVErdXlIZ2djOGRaVTNGRWhITFdsZTJsekw1Y2Zq?= =?utf-8?B?ajE1WlNSR1EwRVZnZGd3NDl5aENvZGJBSHhiMHBTVVRpUDMyS053R1B0VU5z?= =?utf-8?B?dWdCOXE5VFFkd0lpUDVFM3FIc3pydlhVQVNrcFBuRlQzUnhDVXF4TGU4aEl3?= =?utf-8?B?aHh6TVNoQ2RDRjVQd0ZIMTFSZmZ5c25VOUtmaEJ4M3drMFQ2RmhBMCtNbjNY?= =?utf-8?B?d3poZnBWNnNBMUlXcWx3NGdQYXRYM0lIS3oxcmMwQ1JnMFhkSWdrRUxodlJv?= =?utf-8?B?cXFMck1WK1VJZU9VK2VibnZrNFJ2Y1J5dnZxZUhaWElYeW9USUFPNUh4Y2tD?= =?utf-8?B?OWtBYWRSa1luYTVlR09uejR2a3VGdDJwVU1zMWhhRFZjUUlvanJWdDMrL3Bw?= =?utf-8?B?UUlpQWJkTk5Hemdob0l4aUdxVjVWYzJwQVczVjErcWdZL05PVk12bitjZ252?= =?utf-8?B?WUJGL1BpY2docXlEYkFPZHpncGdCNExsSGJDY1VVNVpEb3lPVCtVWkY3S1Jo?= =?utf-8?B?LzdpVGxkSnlIWjBXTm5TWDRsYzVpY2tFL3o5U3pkSUsxQitZajRTQUlFZXFj?= =?utf-8?B?SDI2Y3hjcWtSMzNWUG1ZcEJlMG5uV0czT0EwOWp4eWtSMndac3FZM2RoTWRy?= =?utf-8?B?UEJwTjZqNTZSZkFSYjZjZE04Skc5d0phYklCQWF1bngwMXFDY25Za285VVhu?= =?utf-8?B?bHQwNU9BZTNhM1VtMTF1T1FqVENBV0F1dkJvL2tDYlVYaHA1c2xKRGIwVDF2?= =?utf-8?B?Qm5jSGF6WmVvSVVKenViOGphTG9adTdQK0t1blJiS0dVWHZmOXlGTXEvMDJ0?= =?utf-8?B?bldKZThiZlJFalNLYWczcGJ0aVNRbWNORlRrNDdaa0dJSlB2enEvNjBmSk5t?= =?utf-8?B?cW5ETDhWTmNsbTc2WmFkZ0RmVW9iRzJTWjFKWHRrY09WcTJUQ0VqSTF0ckV1?= =?utf-8?B?UVR0RTNOeGdoajczOVR3MGVZZVdnMGs0MUlJek9LT1lUa0FNQit5OFpBdWZu?= =?utf-8?B?U3d3ZTBuVmx0VG5nSkRrVEUwM1lxZmovd2d4U0xQQW1yZHNWa0JBaU5uZDZ5?= =?utf-8?B?VmlhNDJ3aXV0YVZFaVl3ZncyaGpLM3RxS2duNXg0ZytwTU9IMURGSEN0T1dk?= =?utf-8?B?UGluNktnVlhJclFrV3krZTRWeUMzL1RjREJCR3hDa1ZpQnBXQ2VqeFZvbHd6?= =?utf-8?B?bFhVSkJWTW5PUnZtcVZvTE9hRFdHOEJvQTNWQ2E0M1I0ZDVyd2dsNi9pVm1I?= =?utf-8?B?bEZvRVA5eVY2YWVmZDVrdUlaaHZnN0tTQ25CQXlBK1RVV281NDV2REZ0OEJZ?= =?utf-8?B?N3hESWxpdnpyRjNQWWllOHFKWGdWQjliSW1mVDV4eUwweDJYV25za2pCbFA1?= =?utf-8?B?VjA3Z2hKYXM4VGFSOVpyUHlGQ1hmUzdWVU5aeHZmYjAxN2F6LzFnNERSSFVw?= =?utf-8?B?Tnpydnc4UUdZd0xocEFuaG43SmtjY0pKVG1mVitxQXE4SjgvcU1kYnJndWVj?= =?utf-8?B?UENkWHo3bTFHT0dvR21hNlFhQ1QwWVQyQU1RVGZsZm1xVm9sR2wwYXFFSlAx?= =?utf-8?B?aVlhSGdKa0xkNnpRVkphdz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C47D62C223054BD3800805C1E112191Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4369.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 275a7e46-a8b7-410c-bcaa-08d8d8dcc6e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 15:56:41.3147 (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: Yo0b25p6iG9cuybj5xqqQ6jzu6EUTiFcVsFU7sC04esNpj0TVuZS3yuUpjtBB6MR46GbRd9lYW8vCqXKGivrPA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4880 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 15:56:47 -0000 --_000_C47D62C223054BD3800805C1E112191Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYW4gYXV0aG9yLCBJIHN1cHBvcnQgdGhlIGRvY3VtZW50Lg0KDQpJIHRoaW5rIGl04oCZcyBh IHZlcnkgaW50ZXJlc3RpbmcgdXNlIGNhc2UsICB0aGF0IHNob3dzIGhvdyBMSVNQIGNhbiBzdXBw b3J0IGEgZ2xvYmFsIGdlby1sb2NhbGl6YXRpb24gaW5kZXggaW5mcmFzdHJ1Y3R1cmUuIEEgZ29v ZCBleGFtcGxlIG9mIGhvdyBhIGZhc3QsIHNjYWxhYmxlIGxvb2t1cCBpbmZyYXN0cnVjdHVyZSBj YW4gc3VwcG9ydCwgdXAgdG8gYSBjZXJ0YWluIGV4dGVudCwgIHVzZSBjYXNlcyB0aGF0IGFyZSB0 eXBpY2FsbHkgY29uc2lkZXJlZCB0aGUgZG9tYWluIG9mIHBlZXItdG8tcGVlciBhcmNoaXRlY3R1 cmVzLg0KDQpUaGUgZG9jdW1lbnQgYXJ0aWN1bGF0ZXMgdGhlIHBlY3VsaWFyaXRpZXMgb2YgdGhl IHVzZSBjYXNlLCBwcm92aWRpbmcgYSBndWlkZSBvbiBob3cgdG8gbGV2ZXJhZ2UgdGhlIEgzIGdl b3NwYXRpYWwgIGluZGV4aW5nIHN5c3RlbSBvbiB0b3Agb2YgTElTUC4NCg0KRmFiaW8NCg0KRnJv bTogbGlzcCA8bGlzcC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTHVpZ2kgSWFubm9u ZSA8Z2d4QGdpZ2l4Lm5ldD4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIzLCAyMDIxIGF0IDEx OjE3IFBNDQpUbzogImxpc3BAaWV0Zi5vcmcgbGlzdCIgPGxpc3BAaWV0Zi5vcmc+DQpDYzogImxp c3AtY2hhaXJzQGlldGYub3JnIiA8bGlzcC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W2xpc3BdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1saXNwLW5leGFnb24NCg0KRm9sa3Ms DQoNCndoaWxlIHRoaXMgZG9jdW1lbnQgaGFzIGdhdGhlcmVkIGF0dGVudGlvbiBkdXJpbmcgZmFj ZSB0byBmYWNlIG1lZXRpbmdzLCB3ZSByZWNlaXZlZCB2ZXJ5IGZldyBlbWFpbCBpbiBzdXBwb3J0 IG9mIFdHIExDIQ0KDQpJbiBvcmRlciB0byBnYXRoZXIgbW9yZSBjb25zZW5zdXMgd2UgcHJlZmVy IHRvIGV4dGVuZCB0aGUgTGFzdCBDYWxsIHBlcmlvZCBieSB0d28gd2Vla3MsIHRvIGVuZCBieSBN YXJjaCAxMHRoLg0KDQpQbGVhc2Ugc3BlYWsgdXAgYW5kIHN0YXRlIHdoZXRoZXIgb3Igbm90IHRo aXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkLg0KDQpDaWFvDQoNCkx1aWdpICYg Sm9lbA0KDQoNCg0KT24gMyBGZWIgMjAyMSwgYXQgMTY6MjUsIEx1aWdpIElhbm5vbmUgPGdneEBn aWdpeC5uZXQ8bWFpbHRvOmdneEBnaWdpeC5uZXQ+PiB3cm90ZToNCg0KSGkgQWxsLA0KDQpUaGUg YXV0aG9ycyBvZiAgZHJhZnQtaWV0Zi1saXNwLW5leGFnb24gc3VibWl0dGVkIHRoZSBjdXJyZW50 IHZlcnNpb24gYmFjayBpbiBPY3RvYmVyIHNvbHZpbmcgaXNzdWVzIHJhaXNlZCBkdXJpbmcgU0VD RElSIHJldmlldy4NCk5vIGZ1cnRoZXIgY29tbWVudHMgaGF2ZSBiZWVuIHJhaXNlZCBhbmQgdGhl IGF1dGhvcnMgY29uc2lkZXIgdGhlIGRvY3VtZW50IHN0YWJsZSBhbmQgcmVhZHkgZm9yICBXRyBM YXN0IENhbGwuDQoNClRoaXMgZW1haWwgb3BlbiB0aGUgdXN1YWwgdHdvIHdlZWtzIFdvcmtpbmcg R3JvdXAgTGFzdCBDYWxsLCB0byBlbmQgRmVicnVhcnkgMTd0aCwgMjAyMS4NCg0KUGxlYXNlIHJl dmlldyB0aGlzIFdHIGRvY3VtZW50IGFuZCBsZXQgdGhlIFdHIGtub3cgaWYgeW91IGFncmVlIHRo YXQgaXQgaXMgcmVhZHkgdG8gYmUgaGFuZGVkIG92ZXIgdG8gdGhlIEFELg0KSWYgeW91IGhhdmUg b2JqZWN0aW9ucywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdo YXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuDQoNCk5PVEU6IHNpbGVu Y2UgSVMgTk9UIGNvbnNlbnN1cyENCg0KVGhhbmtzDQoNCkx1aWdpICYgSm9lbA0KDQo= --_000_C47D62C223054BD3800805C1E112191Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToy IDAgNSAzIDAgMCAwIDIgMCA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFzIGFuIGF1 dGhvciwgSSBzdXBwb3J0IHRoZSBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+SSB0aGluayBpdOKAmXMgYSB2ZXJ5IGludGVyZXN0aW5nIHVzZSBj YXNlLCAmbmJzcDt0aGF0IHNob3dzIGhvdyBMSVNQIGNhbiBzdXBwb3J0IGEgZ2xvYmFsIGdlby1s b2NhbGl6YXRpb24gaW5kZXggaW5mcmFzdHJ1Y3R1cmUuIEEgZ29vZCBleGFtcGxlIG9mIGhvdyBh IGZhc3QsIHNjYWxhYmxlIGxvb2t1cCBpbmZyYXN0cnVjdHVyZSBjYW4gc3VwcG9ydCwgdXAgdG8g YQ0KIGNlcnRhaW4gZXh0ZW50LCAmbmJzcDt1c2UgY2FzZXMgdGhhdCBhcmUgdHlwaWNhbGx5IGNv bnNpZGVyZWQgdGhlIGRvbWFpbiBvZiBwZWVyLXRvLXBlZXIgYXJjaGl0ZWN0dXJlcy4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhlIGRvY3VtZW50IGFydGlj dWxhdGVzIHRoZSBwZWN1bGlhcml0aWVzIG9mIHRoZSB1c2UgY2FzZSwgcHJvdmlkaW5nIGEgZ3Vp ZGUgb24gaG93IHRvIGxldmVyYWdlIHRoZSBIMyBnZW9zcGF0aWFsICZuYnNwO2luZGV4aW5nIHN5 c3RlbSBvbiB0b3Agb2YgTElTUC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+RmFiaW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+bGlzcCAmbHQ7bGlzcC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhh bGYgb2YgTHVpZ2kgSWFubm9uZSAmbHQ7Z2d4QGdpZ2l4Lm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+VHVlc2RheSwgRmVicnVhcnkgMjMsIDIwMjEgYXQgMTE6MTcgUE08YnI+DQo8Yj5UbzogPC9i PiZxdW90O2xpc3BAaWV0Zi5vcmcgbGlzdCZxdW90OyAmbHQ7bGlzcEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90O2xpc3AtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtsaXNwLWNo YWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtsaXNwXSBXRyBMYXN0 IENhbGwgZm9yIGRyYWZ0LWlldGYtbGlzcC1uZXhhZ29uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Rm9sa3MsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPndoaWxlIHRoaXMgZG9jdW1lbnQgaGFzIGdhdGhlcmVkIGF0dGVudGlvbiBk dXJpbmcgZmFjZSB0byBmYWNlIG1lZXRpbmdzLCB3ZSByZWNlaXZlZCB2ZXJ5IGZldyBlbWFpbCBp biBzdXBwb3J0IG9mIFdHIExDITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPkluIG9yZGVyIHRvIGdhdGhlciBtb3JlIGNvbnNlbnN1cyB3ZSBwcmVmZXIgdG8g ZXh0ZW5kIHRoZSBMYXN0IENhbGwgcGVyaW9kIGJ5IHR3byB3ZWVrcywgdG8gZW5kIGJ5IE1hcmNo IDEwdGguJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBsZWFz ZSBzcGVhayB1cCBhbmQgc3RhdGUgd2hldGhlciBvciBub3QgdGhpcyBkb2N1bWVudCBpcyByZWFk eSB0byBiZSBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkx1aWdpICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiAzIEZlYiAyMDIxLCBhdCAx NjoyNSwgTHVpZ2kgSWFubm9uZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdneEBnaWdpeC5uZXQiPmdn eEBnaWdpeC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+SGkgQWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5U aGUgYXV0aG9ycyBvZiAmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDsiPmRyYWZ0LWlldGYtbGlzcC1uZXhhZ29uIHN1Ym1pdHRlZCB0aGUgY3Vy cmVudCB2ZXJzaW9uIGJhY2sgaW4gT2N0b2JlciBzb2x2aW5nIGlzc3VlcyByYWlzZWQgZHVyaW5n IFNFQ0RJUiByZXZpZXcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk5vIGZ1cnRoZXIgY29t bWVudHMgaGF2ZSBiZWVuIHJhaXNlZCBhbmQgdGhlIGF1dGhvcnMgY29uc2lkZXIgdGhlIGRvY3Vt ZW50IHN0YWJsZSBhbmQgcmVhZHkgZm9yICZuYnNwO1dHIExhc3QgQ2FsbC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGVtYWlsIG9wZW4gdGhlIHVz dWFsIHR3byB3ZWVrcyBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCwgdG8gZW5kIEZlYnJ1YXJ5IDE3 dGgsIDIwMjEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5QbGVhc2UgcmV2aWV3IHRoaXMgV0cgZG9jdW1lbnQgYW5kIGxldCB0aGUg V0cga25vdyBpZiB5b3UgYWdyZWUgdGhhdCBpdCBpcyByZWFkeSB0byBiZSBoYW5kZWQgb3ZlciB0 byB0aGUgQUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JZiB5b3UgaGF2ZSBvYmplY3Rp b25zLCBwbGVhc2Ugc3RhdGUgeW91ciByZWFzb25zIHdoeSwgYW5kIGV4cGxhaW4gd2hhdCBpdCB3 b3VsZCB0YWtlIHRvIGFkZHJlc3MgeW91ciBjb25jZXJucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5OT1RFOiBzaWxlbmNlIElTIE5PVCBjb25zZW5zdXMh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRo YW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFG Q0QiPjxicj4NCjwvc3Bhbj5MdWlnaSAmYW1wOyBKb2VsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C47D62C223054BD3800805C1E112191Cciscocom_-- From nobody Wed Feb 24 08:13:09 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2773A177F; Wed, 24 Feb 2021 08:13:07 -0800 (PST) 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=OnP/kXio; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cb4q1elR 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 TvxWbs0dooXp; Wed, 24 Feb 2021 08:13:04 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453E13A1782; Wed, 24 Feb 2021 08:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20149; q=dns/txt; s=iport; t=1614183154; x=1615392754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nwkACcl25meszn6yQCNx1cU0tfkLwIP+TMJ/MNWXojs=; b=OnP/kXioGlSVNfXkHiYtq/JWCf3oTXSsl3cpiQ/658qD2V8Zn04BrZUX ufunFuwMrGnmDGCRdfDh/1COmDyp2Kn9VNyw6ogl7YMrBa9HQxrE21Tqe G9s0ocFFNxyiFzk1Z3XVoxJmjNz+Qkm6CXVxTU9B0vpHAQdZdmaUb2VTB 4=; X-IPAS-Result: =?us-ascii?q?A0BzDwCheTZgkJxdJa1iHQEBAQEJARIBBQUBgg+BU1F9W?= =?us-ascii?q?jYxCgGENoNIA4U5iFkDgxmRFIRzglMDVAsBAQENAQEdAQoKAgQBAYQJRAIXg?= =?us-ascii?q?WACJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgNhkQBAQEEAQEbB?= =?us-ascii?q?h0BASwLAQ8CAQgOAwMBAigDAgICJQsUCQgCBA4FgmsBgX5XAy4BDqREAoold?= =?us-ascii?q?oEygwQBAQaBMwEDAQ9BRIJIDQuCEgmBOIJ2gmuBGwEBhkQmHIFBQoERJxyCV?= =?us-ascii?q?z6CXQEBAQEBARWBJAEBNwkNCQiCWDSCK4JKPio4GQEBWAMLCx80PTCQOheDQ?= =?us-ascii?q?YdHnhoKgnyEKoUUklwDH4M0gTSESoRPBI9IgQKEe6ADkguEUQIEAgQFAg4BA?= =?us-ascii?q?QaBayGBWXAVOyoBggoBATIJRxcCDY4fGYNWhFk7hUQBcwI2AgYBCQEBAwl8i?= =?us-ascii?q?ggBgQ4BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AehBK5BZF72AqwWltABO+/YP/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaTD4TW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,203,1610409600"; d="scan'208,217";a="669366809" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Feb 2021 16:12:33 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 11OGCXW2018373 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2021 16:12:33 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 24 Feb 2021 10:12:32 -0600 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 24 Feb 2021 10:12:32 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 24 Feb 2021 10:12:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nREZyF55n0BG6MXj6bcLvSi6eKZcuD3EWpkSWwBJ72LKkfJae7SjHD3+Y0HNlJs88Uhubt5q6jhwMOH3iPMLXcUTUcAqyyRCKzPD0MUryZqqpxoZ6aUSqDpeUOU0DhmrRX/83+ATXlRx0PnjeP6OvXHIK3CK5hVtiPbeBWDTbWImtjMJHM02+Tt3k8fvNRj/zXUJRB+Lg7wNecrSpzCO5UsYM+3TqqU/KA9QJE/LoCThXPlodwnC/wOOCWWkXBbFZtEPY49dyLd/50rINpX8lWNDlaE2jqDoVnQNWNm91hB+jnFmIBPnc4IiexXKMjwqDJoYQ2VSL4g6CaFf9B75Nw== 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=nwkACcl25meszn6yQCNx1cU0tfkLwIP+TMJ/MNWXojs=; b=m8Yb1HqAu1jYo6YuX/oB9+svmAnodNvJP/7lfahvnC2HKBwuWbWImgfLYvt787VJtCYkiK+8vd7AAGAO6acTcWmsp805IDtw8bDBp3CilvsMI2u6HD0xAPLUOMeXDD9SCjP7Bm4yhdgiDMP3cv2SuDAFmMZGiWq3DRVF0ZMM4L7O0vSsHCidZFSHCPbNmQvfsooU+Tc856yKu/eyDurkUKUynTLc8LLrDy+eZ/IFUiccFedySrhfWa47zV1Dqbmx3RUVqNethkdSyvSTAZkHCp7UPYYpGG/+0o+ySzxLldY5E6NxGG9pYQZ4S39CSK2XsU7ow/Evfpo0HEDlX0pafg== 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=nwkACcl25meszn6yQCNx1cU0tfkLwIP+TMJ/MNWXojs=; b=cb4q1elRVq1sTV8JBKLdNBbwdFvwmVSFOYmDQDiEWXnr6sY55jyEU5W7tdla4FE9Hkpd9MD8QPweWCGi4UMkYcLvok18waEESvyTF4XRZduaM1t7clanTy2QfbVHavE3dmXDUaVMWjOrFM+xk1+Fr7EqFD4adscpqhHAjk3IpC4= Received: from BY5PR11MB4227.namprd11.prod.outlook.com (2603:10b6:a03:1c3::17) by SJ0PR11MB4912.namprd11.prod.outlook.com (2603:10b6:a03:2ae::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.31; Wed, 24 Feb 2021 16:12:31 +0000 Received: from BY5PR11MB4227.namprd11.prod.outlook.com ([fe80::e4f7:3da8:b227:4302]) by BY5PR11MB4227.namprd11.prod.outlook.com ([fe80::e4f7:3da8:b227:4302%5]) with mapi id 15.20.3868.034; Wed, 24 Feb 2021 16:12:31 +0000 From: "Victor Moreno (vimoreno)" To: Luigi Iannone CC: "lisp@ietf.org list" , "lisp-chairs@ietf.org" Thread-Topic: [lisp] Call for Agenda Items Thread-Index: AQHW/vOdSHdwNVQfGE2ilBNl5MdNuqpnNjyAgABbkcM= Date: Wed, 24 Feb 2021 16:12:31 +0000 Message-ID: <0BC891E4-7EDC-4FD5-B624-CEF044328F8D@cisco.com> References: <161257290585.16296.10283421370309856637@ietfa.amsl.com> <5D2270EA-972C-414D-9EE9-1F737FA6666F@gigix.net>, <2F26C9C2-5180-4506-8DAB-E5D5FE242B2C@gigix.net> In-Reply-To: <2F26C9C2-5180-4506-8DAB-E5D5FE242B2C@gigix.net> Accept-Language: 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: [75.80.27.117] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3bea890-bf04-4e53-fb73-08d8d8defd3a x-ms-traffictypediagnostic: SJ0PR11MB4912: x-ms-exchange-minimumurldomainage: gigix.net#4243 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V5slQmixg35Mywq/G9CMpm7+TEPAknLursgTLPesu8HxGOxXxzo3mKD4WT91NtX/eU9NAix0fG2w/Ekc4C1P8lPchkEXwSyBZQsoemXrSIEH3n0QnViIQ3j80i/3yecv8+xh7WxRNjYSc8/kCkrbin9MLWLhdgtosY7BMqhenylFpGNfxkU/O3q+cQb6rFEvXLzBubKviau37uRWHFkIMVCB7fcGIYxboqvvLiqgxR6BHVjTYGahxHquq0cMLvz9daqEL7zgyQFSckRILOVf+DGuWl1sNl683BG7iblKP7CLGdDENNk1HjVSbUixDKi4moPP2a5PsfHZeqri1uy9o3qvMesc9TQPTbzDkHkaaYxET+m9JbL747zjTTz3NXmo4Hh63khBHLrUQPqagqXzu1C12gfb+sBfytBXJq99X1k7Kzym1gkCe9XCt63Dqu28mSmRNJm0McYYRErFNQXlFHqRM4GnWDgfZqrY2MsTNqaLdg9TCmh7DJI7te80xF33hTPGYTZO4TJb3qaUHOShyfAwhmgcKSihMx1QSM8E1eh4R7rRFEXtDSOe8yRSGjnEZa8M+mJYX5GI0tCWroirMWri2NCWPUB7LKQlNRaZrfvzmvb0pMor1DBhGk+qaPSjNwQDqL+Tx3IlbDGj+Zd+iA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4227.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(396003)(366004)(136003)(376002)(2906002)(71200400001)(8676002)(86362001)(186003)(36756003)(166002)(6512007)(8936002)(2616005)(21615005)(26005)(66476007)(64756008)(83380400001)(66556008)(54906003)(76116006)(66446008)(5660300002)(6916009)(6486002)(53546011)(4326008)(6506007)(478600001)(66946007)(966005)(316002)(33656002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?dXNVeVljOUVnQU41QjFiTlF1YjlBTWFWakFTK2xQdDYzWEl1TFlmd1RzbXdV?= =?utf-8?B?Rk00UFpKMGVUWFMzNFFmKys0WjVNeVlOcmFicXFMZzdwcmU1TkFEQlhXbE9O?= =?utf-8?B?VTczWDR6VXlVR04yYXE5YWVRbDkwWkd3dFFxVFQ2bFFFNUlRRitQYzZpVkJD?= =?utf-8?B?VEVTd1k4d1VPRnF2TXJWY2dHYTg1MFE2V0RMTUZ4ckh6RUM2aXA1ZEtpemU1?= =?utf-8?B?QjM4bXhVSGFiTDB1MmNIUDFOSHVvUENCaURSNUxsMVFiWWVteVRlYWgxQ1VQ?= =?utf-8?B?M2YvQzFDWUw2ekVKYlJxNTFkQTFVWWtvcDVEaEdtekhhV2xEMC85NGFiVllr?= =?utf-8?B?aktDOEdUdndFMWpucFJ4cDVmSFp0SWZjN0thc2N0WWZQdGVBZHByOUhmYy82?= =?utf-8?B?ZVpYQUlQbWViVW5NYzltTndIWk5SZzFCZUFLNEdiRjZ5TjErTjkxZWNaTm1W?= =?utf-8?B?ak84dHZTQmVpUkl6azJJa3RVQ0ZNZjVHTFUxelo3OG5NZHZibEgzVEV2cmJo?= =?utf-8?B?OXljSHhESXBJNU9JSDVLZzBRRGRSbktkcDdEclF1RlhBOGR5ZXZueHpIczJk?= =?utf-8?B?SWZzVVI1LzRkQnB1cjBwVXBNOVlmRGlLYUZtcXJ5M3hjYWk2T3lMNzNQczFt?= =?utf-8?B?bjNZNlB1UHVZaFJsOFlPQ2RSV2xoZS9WUEMvdFczdlVzYjRnMk03cHZMcVdj?= =?utf-8?B?U1QyOGFPTGNFRnFsMEsvRHFlZ1I2Vk9hK0NJaldHdkRmSm1KR3lwY0o2a0pC?= =?utf-8?B?S1diNU14L1U3d2RYRkdFb3F2VzVVMmQ2aC9wVjZ3MDJsV2JPQkZaSUpTQ0tV?= =?utf-8?B?UG1WM1ZzaDRqQ0JFU0V5eldVRnBTNStBUVM3UDBYVkJLY2xYN29oQXlzQzNY?= =?utf-8?B?MGsvd09FcUNqRGJlWVBtN3J6NFQ2U3VVRHYyM1JCUFg3SDErZEVyVkhOWFov?= =?utf-8?B?UjVNUHd4a3ltS2VBVHdTM1B5N0NvVFBFYUpFSldvZ3lqYktQK05KR09CL1I0?= =?utf-8?B?ay9ZWHZCcHBaaWdrWXI2a2ZveWJydjVHUEpDZDVjcXpPalNSeHg2Nm9FNk84?= =?utf-8?B?c1hXb3hyNUNTNmJqWVIvZGRlNmU4OFMyNDF1bVBrcm1jSGxBSFRic1lYVzlT?= =?utf-8?B?K20xOGEvQ3hySFJjbUdZeXBvaU9wZmpKNENNT2ZhdmUxZFBpZHlwV0c5ZW1O?= =?utf-8?B?MjBkekhUaElNVURIQ2IveG5YMFduRVNxTGdKRjdsY1liNEE0N0ZpWW44VFNi?= =?utf-8?B?RjZkZms0TmVUL2p4S2sxMkVYU2duTWR2a1pxL3FtSE9PZnNhem1ReUhIN0dx?= =?utf-8?B?Y1k4emRIY2o0N2R6MzgrV252d0c0R2VUOUt6VUtPbkVuYXhtc2pRLzNuZ21q?= =?utf-8?B?ME1VVEt5SHdybVJmMDY3QjJpNmU0SmsyRkZEczdpVWlYcW1Cd3F6cXR0cEd6?= =?utf-8?B?OU1pak5zL05yM2pFOWpmcThEczNzWFlpbnZkZlRZN3VTNm1KaFV5MUJTVGdQ?= =?utf-8?B?bkN6T0luaW54SWE4UGxDU0lXdktaOFd2WEZWR3JtZFV3U3NIeXlCRXcwMTlY?= =?utf-8?B?ak0wdEJIeXIxSXF1RVd1cCt1TkxHeUFxa0NVYVpyeWFWNDhVZjZuZTVTdWky?= =?utf-8?B?bVc3aTBrcWlYckhUMkM2SHVINTBSK0Z3VU9qbTdSa2ViRndLUHFJWW1SdlZs?= =?utf-8?B?aUk2dlhwSUJONDd6Nm10bVJNSHl1RzllWWc4UmM4Kzl1aUZ2cE9mRXBGZFFu?= =?utf-8?Q?XMRzzvKmcrDtFC8Jwqz+U5aBPfpSQwTcKfzSHrx?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0BC891E47EDC4FD5B624CEF044328F8Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4227.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3bea890-bf04-4e53-fb73-08d8d8defd3a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 16:12:31.5046 (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: 6ZzondfrCm+aa65fHvgebe5f1JJgPDxzhM6yypWyJX+wHU7Syk3t3m/aBwQQMoAdhFYeIpVa/xDU2EEAb2/ZBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4912 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [lisp] Call for Agenda Items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 16:13:08 -0000 --_000_0BC891E47EDC4FD5B624CEF044328F8Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTHVpZ2ksDQoNCldlIHNob3VsZCBzcGVuZCBzb21lIHRpbWUgb24gdGhlIHViZXJsYXkgdG9w aWMuIENhbiB5b3UgcGxlYXNlIGFkZCBpdCB0byB0aGUgYWdlbmRhPw0KDQpTZW50IGZyb20gbXkg aVBob25lDQoNCk9uIEZlYiAyNCwgMjAyMSwgYXQgMjo0NSBBTSwgTHVpZ2kgSWFubm9uZSA8Z2d4 QGdpZ2l4Lm5ldD4gd3JvdGU6DQoNCu+7vyBBbGwsDQoNCmVpdGhlciBJIGhhdmUgYSBtYWlsIHBy b2JsZW0gb3IgdGhlcmUgaXMgbm90IHRoYXQgbXVjaCB0byBkaXNjdXNzIGluIHRoZSBuZXh0IElF VEYuDQoNCkFzIHlvdSBjYW4gc2VlIGJlbG93IHRoZSBhZ2VuZGEgaXMgcHJldHR5IGVtcHR5Lg0K DQpQbGVhc2UgbGV0IHVzIGtub3cgQVNBUCBpZiB5b3Ugd2FudCBhIHNsb3QuDQoNClRoYW5rcw0K DQpDaWFvDQoNCkpvZWwgJiBMdWlnaQ0KDQoNCg0KDQpDSEFJUihzKTogIEpvZWwgSGFscGVybiAo IGptaCBBVCBqb2VsaGFscGVybi5jb208aHR0cDovL2pvZWxoYWxwZXJuLmNvbT4gKQ0KICAgICAg ICAgICAgICAgIEx1aWdpIElhbm5vbmUgKCBnZ3ggQVQgZ2lnaXgubmV0PGh0dHA6Ly9naWdpeC5u ZXQ+ICkNCg0KU0VDUkVUQVJZOiBQYWRtYSBQaWxsYXktRXNuYXVsdCAoIHBhZG1hLmlldGYgQVQg Z21haWwuY29tPGh0dHA6Ly9nbWFpbC5jb20+ICkNCg0KDQpBR0VOREENCg0KU2Vzc2lvbiAxLzEg KDEyMCBNaW51dGVzKQ0KPS09LT0tPS09LT0tPS09LT0tDQoNCkZyaWRheSwgTWFyY2ggMjEsIDIw MjENCjEyOjAwIC0gMTQ6MDAgKFVUQyksIFNlc3Npb24gSSwgMTIwIE1pbnV0ZXMNCigyMDowMCAt IDIyOjAwIEJlaWppbmcpDQooMTM6MDAgLSAxNTowMCBQYXJpcykNCig3OjAwIC0gOTowMCBOZXcg WW9yaykNCig0OjAwIC0gNjowMCBTYW4gRnJhbmNpc2NvKQ0KUm9vbSA2OiBodHRwczovL21lZXRp bmdzLmNvbmYubWVldGVjaG8uY29tL2lldGYxMTAvP2dyb3VwPWxpc3Amc2hvcnQ9Jml0ZW09MQ0K DQotIEFkbWluaXN0cmF0aW9uDQogICAgSGFscGVybi9JYW5ub25lDQogICAgLSBBZ2VuZGEgQmFz aGluZw0KICAgIC0gU3RhdHVzIHJlcG9ydHMgZm9yIFdHIGRyYWZ0cw0KMTAgTWludXRlcyAoQ3Vt dWxhdGl2ZSBUaW1lOiAxMCBNaW51dGVzKQ0KDQoNCg0KbyBXRyBJdGVtcw0KDQotIExJU1AgWWFu ZyBNb2RlbCAtIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlz cC15YW5nLw0KICAxMCBNaW51dGVzIChDdW11bGF0aXZlIFRpbWU6IDIwIE1pbnV0ZXMpDQogIEFs YmVydG8gUm9kcmlndWV6IE5hdGFsICBDYWJlbGxvcw0KDQoNCm8gTm9uIFdHIEl0ZW1zDQoNCg0K LSBPdmVyZmxvdyBUaW1lLyBEaXNjdXNzaW9uDQogIDEwMCBNaW51dGVzIChDdW11bGF0aXZlIFRp bWU6IDEyMCBNaW51dGVzKQ0KDQoNCg0KDQpPbiA5IEZlYiAyMDIxLCBhdCAxNTo1NCwgTHVpZ2kg SWFubm9uZSA8Z2d4QGdpZ2l4Lm5ldDxtYWlsdG86Z2d4QGdpZ2l4Lm5ldD4+IHdyb3RlOg0KDQpG b2xrcywNCg0KVGhlIHByZWxpbWluYXJ5IGFnZW5kYSBpcyBvdXQgYW5kIGl0IHNlZW1zIHRoYXQg d2UgYXJlIG1lZXRpbmcgb24gRnJpZGF5Lg0KDQpXaGlsZSB0aGUgYWdlbmRhIG1heSBzdGlsbCBj aGFuZ2UgaXQgaXMgYWJvdXQgdGltZSB0byBjYWxsIGZvciBhZ2VuZGEgaXRlbXMuDQoNClBsZWFz ZSBpZiB5b3Ugd2FudCBhIHNsb3Qgc2VuZCBhIG1lc3NhZ2UgdG8gdGhlIGNoYWlycyBieSBGZWJy dWFyeSAyM3JkIGF0IGxhdGVzdCAod2Ugd2lsbCBwdWJsaXNoIGEgZHJhZnQgYWdlbmRhIG9uIEZl YnJ1YXJ5IDI0dGgpLg0KDQpUaGFua3MNCg0KQ2lhbw0KDQpMLg0KDQoNCkJlZ2luIGZvcndhcmRl ZCBtZXNzYWdlOg0KDQpGcm9tOiBJRVRGIEFnZW5kYSA8YWdlbmRhQGlldGYub3JnPG1haWx0bzph Z2VuZGFAaWV0Zi5vcmc+Pg0KU3ViamVjdDogSUVURiAxMTAgUHJlbGltaW5hcnkgQWdlbmRhDQpE YXRlOiA2IEZlYnJ1YXJ5IDIwMjEgYXQgMDE6NTU6MDYgQ0VUDQpUbzogIklFVEYgQW5ub3VuY2Vt ZW50IExpc3QiIDxpZXRmLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppZXRmLWFubm91bmNlQGll dGYub3JnPj4NCkNjOiBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiwgMTEwYWxs QGlldGYub3JnPG1haWx0bzoxMTBhbGxAaWV0Zi5vcmc+DQpSZXBseS1Ubzogc3VwcG9ydEBpZXRm Lm9yZzxtYWlsdG86c3VwcG9ydEBpZXRmLm9yZz4NCg0KVGhlIElFVEYgMTEwIFByZWxpbWluYXJ5 IEFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQuIFRoZSBmaW5hbCBhZ2VuZGEgd2lsbCBiZSBwdWJsaXNo ZWQgb24gRnJpZGF5LCBGZWJydWFyeSAxMiwgMjAyMS4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzExMC9hZ2VuZGEuaHRtbA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nLzExMC9hZ2VuZGEudHh0DQoNClRoZSBwcmVsaW1pbmFyeSBhZ2VuZGEgaW5j bHVkZXMgYWxsIHBsYW5uZWQgV0csIFJHLCBhbmQgQm9GIHNlc3Npb25zLiBXZSBhcmUgc3RpbGwg ZmluYWxpemluZyBkZXRhaWxzIGZvciBhIGZldyBvZiBvdXIgdXN1YWwgbWVldGluZy1hZGphY2Vu dCBldmVudHMsIHNvIHBsZWFzZSBsb29rIG91dCBmb3IgZnVydGhlciBkZXRhaWxzIGFib3V0IHRo b3NlLiBJbmZvcm1hdGlvbiBhYm91dCBzaWRlIG1lZXRpbmcgc2lnbnVwcyB3aWxsIGJlIGF2YWls YWJsZSB3aGVuIHRoZSBmaW5hbCBhZ2VuZGEgaXMgcG9zdGVkLg0KDQpQbGVhc2Ugbm90ZSB0aGUg YWdlbmRhIHRpbWVzIGFyZSBsaXN0ZWQgaW4gQ0VUIChVVEMgKzEpIGJ5IGRlZmF1bHQuIFlvdSBt YXkgc2VsZWN0IHdoaWNoIHRpbWUgem9uZSBpcyBkaXNwbGF5ZWQgb24gdGhlIEhUTUwgdmVyc2lv biBvZiB0aGUgYWdlbmRhIHdpdGggYSBtZW51IG9uIHRoZSByaWdodCBzaWRlIG9mIHRoZSBwYWdl LiBDaG9vc2Ug4oCcTWVldGluZyBUaW1lem9uZeKAnSBmb3IgQ0VULCDigJxMb2NhbCBUaW1lem9u ZeKAnSBmb3IgeW91ciBvd24gY3VycmVudCB0aW1lIHpvbmUsIOKAnFVUQ+KAnSBmb3IgVVRDLCBv ciBjaG9vc2UgYW55IG90aGVyIHRpbWUgem9uZSBmcm9tIHRoZSBkcm9wIGRvd24gbGlzdC4NCg0K DQpJRVRGIDExMCBJbmZvcm1hdGlvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdz LzExMC8NClJlZ2lzdGVyIG9ubGluZSBhdDogaHR0cHM6Ly9yZWdpc3RyYXRpb24uaWV0Zi5vcmcv MTEwLw0KDQpEb27igJl0IGZvcmdldCB0byByZWdpc3RlciBmb3IgdGhlc2UgZXhjaXRpbmcgSUVU RiAxMTAgZXZlbnRzIQ0KDQoNCkhhY2thdGhvbg0KU2lnbnVwOiBodHRwczovL3JlZ2lzdHJhdGlv bi5pZXRmLm9yZy8xMTAvbmV3L2hhY2thdGhvbi8NCk1vcmUgaW5mb3JtYXRpb246IGh0dHBzOi8v d3d3LmlldGYub3JnL2hvdy9ydW5uaW5nY29kZS9oYWNrYXRob25zLzExMC1oYWNrYXRob24vDQpL ZWVwIHVwIHRvIGRhdGUgYnkgc3Vic2NyaWJpbmcgdG86DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2hhY2thdGhvbg0KDQpDb2RlIFNwcmludA0KU2lnbnVwOiBodHRwczov L3RyYWMudG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWV0ZmRiL3dpa2kvSUVURjExMFNwcmludFNpZ25V cA0KTW9yZSBpbmZvcm1hdGlvbjogaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3JnL3Rvb2xzL2ll dGZkYi93aWtpL0lFVEYxMTBTcHJpbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCklFVEYtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91 bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYt YW5ub3VuY2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0K --_000_0BC891E47EDC4FD5B624CEF044328F8Dciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI aSBMdWlnaSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIHNob3VsZCBzcGVuZCBzb21lIHRp bWUgb24gdGhlIHViZXJsYXkgdG9waWMuIENhbiB5b3UgcGxlYXNlIGFkZCBpdCB0byB0aGUgYWdl bmRhPzxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj4N CjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIEZlYiAyNCwg MjAyMSwgYXQgMjo0NSBBTSwgTHVpZ2kgSWFubm9uZSAmbHQ7Z2d4QGdpZ2l4Lm5ldCZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vyBBbGwsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5laXRoZXIgSSBoYXZlIGEgbWFpbCBwcm9ibGVtIG9y IHRoZXJlIGlzIG5vdCB0aGF0IG11Y2ggdG8gZGlzY3VzcyBpbiB0aGUgbmV4dCBJRVRGLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMg eW91IGNhbiBzZWUgYmVsb3cgdGhlIGFnZW5kYSBpcyBwcmV0dHkgZW1wdHkuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QbGVhc2UgbGV0 IHVzIGtub3cgQVNBUCBpZiB5b3Ugd2FudCBhIHNsb3QuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3M8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNpYW88L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkpvZWwgJmFt cDsgTHVpZ2k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DSEFJUihzKTogJm5ic3A7Sm9lbCBIYWxwZXJuICggam1o IEFUIDxhIGhyZWY9Imh0dHA6Ly9qb2VsaGFscGVybi5jb20iIGNsYXNzPSIiPg0Kam9lbGhhbHBl cm4uY29tPC9hPiApPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTHVpZ2kgSWFubm9uZSAoIGdneCBBVCA8 YSBocmVmPSJodHRwOi8vZ2lnaXgubmV0IiBjbGFzcz0iIj4NCmdpZ2l4Lm5ldDwvYT4gKTwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U0VD UkVUQVJZOiBQYWRtYSBQaWxsYXktRXNuYXVsdCAoIHBhZG1hLmlldGYgQVQgPGEgaHJlZj0iaHR0 cDovL2dtYWlsLmNvbSIgY2xhc3M9IiI+DQpnbWFpbC5jb208L2E+ICk8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BR0VOREE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNlc3Npb24gMS8xICgxMjAgTWludXRlcyk8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PS09LT0tPS09LT0tPS09LT0tPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5GcmlkYXksIE1hcmNoIDIx LCAyMDIxPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEyOjAwIC0gMTQ6MDAgKFVUQyksIFNlc3Npb24g SSwgMTIwIE1pbnV0ZXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KDIwOjAwIC0gMjI6MDAgQmVpamlu Zyk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KDEzOjAwIC0gMTU6MDAgUGFyaXMpPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPig3OjAwIC0gOTowMCBOZXcgWW9yaykmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+KDQ6MDAgLSA2OjAwIFNhbiBGcmFuY2lzY28pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJvb20g NjogPGEgaHJlZj0iaHR0cHM6Ly9tZWV0aW5ncy5jb25mLm1lZXRlY2hvLmNvbS9pZXRmMTEwLz9n cm91cD1saXNwJmFtcDtzaG9ydD0mYW1wO2l0ZW09MSIgY2xhc3M9IiI+DQpodHRwczovL21lZXRp bmdzLmNvbmYubWVldGVjaG8uY29tL2lldGYxMTAvP2dyb3VwPWxpc3AmYW1wO3Nob3J0PSZhbXA7 aXRlbT0xPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+LSBBZG1pbmlzdHJhdGlvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7IEhhbHBlcm4vSWFubm9uZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7 IC0gQWdlbmRhIEJhc2hpbmc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAtIFN0 YXR1cyByZXBvcnRzIGZvciBXRyBkcmFmdHM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+MTAgTWlu dXRlcw0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij48L3NwYW4+KEN1bXVsYXRpdmUgVGltZTogMTAgTWludXRlcyk8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ byBXRyBJdGVtczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+LSBMSVNQIFlhbmcgTW9kZWwgLSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxpc3AteWFuZy8iIGNsYXNzPSIiPg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1saXNwLXlhbmcvPC9hPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgMTAgTWludXRlcyAoQ3VtdWxhdGl2ZSBUaW1lOiAyMCBN aW51dGVzKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgQWxiZXJ0byBSb2RyaWd1ZXogTmF0 YWwgJm5ic3A7Q2FiZWxsb3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5v IE5vbiBXRyBJdGVtczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gT3Zl cmZsb3cgVGltZS8gRGlzY3Vzc2lvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgMTAwIE1p bnV0ZXMgKEN1bXVsYXRpdmUgVGltZTogMTIwIE1pbnV0ZXMpPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA5 IEZlYiAyMDIxLCBhdCAxNTo1NCwgTHVpZ2kgSWFubm9uZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdn eEBnaWdpeC5uZXQiIGNsYXNzPSIiPmdneEBnaWdpeC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpGb2xrcywNCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBwcmVs aW1pbmFyeSBhZ2VuZGEgaXMgb3V0IGFuZCBpdCBzZWVtcyB0aGF0IHdlIGFyZSBtZWV0aW5nIG9u IEZyaWRheS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPldoaWxlIHRoZSBhZ2VuZGEgbWF5IHN0aWxsIGNoYW5nZSBpdCBpcyBhYm91dCB0 aW1lIHRvIGNhbGwgZm9yIGFnZW5kYSBpdGVtcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBsZWFzZSBpZiB5b3Ugd2FudCBhIHNsb3Qg c2VuZCBhIG1lc3NhZ2UgdG8gdGhlIGNoYWlycyBieSBGZWJydWFyeSAyM3JkIGF0IGxhdGVzdCAo d2Ugd2lsbCBwdWJsaXNoIGEgZHJhZnQgYWdlbmRhIG9uIEZlYnJ1YXJ5IDI0dGgpLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtz PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5DaWFvPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5MLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDs8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1h cmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zeXN0ZW0tZm9udCwgJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssIEhlbHZldGljYSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPklFVEYgQWdlbmRhICZsdDs8YSBocmVm PSJtYWlsdG86YWdlbmRhQGlldGYub3JnIiBjbGFzcz0iIj5hZ2VuZGFAaWV0Zi5vcmc8L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBw eDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1m b250LCAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SUVURiAxMTAgUHJlbGltaW5hcnkg QWdlbmRhPC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2lu LWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0 LXN5c3RlbS1mb250LCAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RGF0ZToNCjwvYj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+NiBGZWJydWFyeSAyMDIxIGF0IDAxOjU1OjA2 IENFVDxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6 IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3Rl bS1mb250LCAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywgSGVsdmV0aWNhLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+VG86DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZxdW90O0lFVEYgQW5ub3VuY2VtZW50IExpc3QmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIiBjbGFzcz0iIj5pZXRm LWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDss IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkNjOg0KPC9iPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZl dGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YSBocmVmPSJtYWls dG86aWV0ZkBpZXRmLm9yZyIgY2xhc3M9IiI+aWV0ZkBpZXRmLm9yZzwvYT4sDQo8YSBocmVmPSJt YWlsdG86MTEwYWxsQGlldGYub3JnIiBjbGFzcz0iIj4xMTBhbGxAaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsICZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij48YiBjbGFzcz0iIj5SZXBseS1UbzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOnN1cHBvcnRAaWV0Zi5vcmciIGNsYXNz PSIiPnN1cHBvcnRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGhlIElFVEYgMTEwIFBy ZWxpbWluYXJ5IEFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQuIFRoZSBmaW5hbCBhZ2VuZGEgd2lsbCBi ZSBwdWJsaXNoZWQgb24gRnJpZGF5LCBGZWJydWFyeSAxMiwgMjAyMS48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRp bmcvMTEwL2FnZW5kYS5odG1sIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTEwL2FnZW5kYS5odG1sPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMTAvYWdlbmRhLnR4dCIgY2xhc3M9IiI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzExMC9hZ2VuZGEudHh0PC9hPjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBwcmVsaW1pbmFyeSBhZ2VuZGEgaW5jbHVk ZXMgYWxsIHBsYW5uZWQgV0csIFJHLCBhbmQgQm9GIHNlc3Npb25zLiBXZSBhcmUgc3RpbGwgZmlu YWxpemluZyBkZXRhaWxzIGZvciBhIGZldyBvZiBvdXIgdXN1YWwgbWVldGluZy1hZGphY2VudCBl dmVudHMsIHNvIHBsZWFzZSBsb29rIG91dCBmb3IgZnVydGhlciBkZXRhaWxzIGFib3V0IHRob3Nl LiBJbmZvcm1hdGlvbiBhYm91dCBzaWRlIG1lZXRpbmcgc2lnbnVwcyB3aWxsIGJlIGF2YWlsYWJs ZQ0KIHdoZW4gdGhlIGZpbmFsIGFnZW5kYSBpcyBwb3N0ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhlIGFnZW5kYSB0aW1lcyBhcmUgbGlzdGVkIGluIENFVCAo VVRDICsxKSBieSBkZWZhdWx0LiBZb3UgbWF5IHNlbGVjdCB3aGljaCB0aW1lIHpvbmUgaXMgZGlz cGxheWVkIG9uIHRoZSBIVE1MIHZlcnNpb24gb2YgdGhlIGFnZW5kYSB3aXRoIGEgbWVudSBvbiB0 aGUgcmlnaHQgc2lkZSBvZiB0aGUgcGFnZS4gQ2hvb3NlIOKAnE1lZXRpbmcgVGltZXpvbmXigJ0g Zm9yIENFVCwg4oCcTG9jYWwgVGltZXpvbmXigJ0gZm9yIHlvdXIgb3duIGN1cnJlbnQNCiB0aW1l IHpvbmUsIOKAnFVUQ+KAnSBmb3IgVVRDLCBvciBjaG9vc2UgYW55IG90aGVyIHRpbWUgem9uZSBm cm9tIHRoZSBkcm9wIGRvd24gbGlzdC4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCklFVEYgMTEwIEluZm9ybWF0aW9uOiBodHRwczovL3d3dy5pZXRmLm9yZy9o b3cvbWVldGluZ3MvMTEwLzxiciBjbGFzcz0iIj4NClJlZ2lzdGVyIG9ubGluZSBhdDogaHR0cHM6 Ly9yZWdpc3RyYXRpb24uaWV0Zi5vcmcvMTEwLzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkRvbuKAmXQgZm9yZ2V0IHRvIHJlZ2lzdGVyIGZvciB0aGVzZSBleGNpdGluZyBJRVRGIDExMCBl dmVudHMhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGFja2F0 aG9uIDxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9Indo aXRlLXNwYWNlOnByZSI+PC9zcGFuPlNpZ251cDogaHR0cHM6Ly9yZWdpc3RyYXRpb24uaWV0Zi5v cmcvMTEwL25ldy9oYWNrYXRob24vPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+TW9yZSBpbmZvcm1hdGlvbjog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L3J1bm5pbmdjb2RlL2hhY2thdGhvbnMvMTEwLWhhY2th dGhvbi88YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5LZWVwIHVwIHRvIGRhdGUgYnkgc3Vic2NyaWJpbmcgdG86 DQo8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0 ZS1zcGFjZTpwcmUiPjwvc3Bhbj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2hhY2thdGhvbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNvZGUgU3ByaW50PGJyIGNs YXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+U2lnbnVwOiBodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWV0 ZmRiL3dpa2kvSUVURjExMFNwcmludFNpZ25VcDxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJB cHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPk1vcmUgaW5mb3Jt YXRpb246IGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy90b29scy9pZXRmZGIvd2lraS9JRVRG MTEwU3ByaW50PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpJRVRGLUFubm91bmNl IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCklFVEYtQW5ub3VuY2VAaWV0Zi5vcmc8YnIgY2xh c3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3Vu Y2U8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+bGlzcCBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyPg0KPHNwYW4+bGlzcEBpZXRmLm9yZzwvc3Bhbj48YnI+DQo8c3Bhbj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8L3NwYW4+PGJyPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0BC891E47EDC4FD5B624CEF044328F8Dciscocom_-- From nobody Fri Feb 26 05:58:53 2021 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7D3A0B53 for ; Fri, 26 Feb 2021 05:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=gigix-net.20150623.gappssmtp.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 cOmejqbHAopg for ; Fri, 26 Feb 2021 05:58:50 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 745673A0B21 for ; Fri, 26 Feb 2021 05:58:50 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id k66so7894674wmf.1 for ; Fri, 26 Feb 2021 05:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=QF3meuGK6XXmnQwE8rQh4QZK8VfyhJwToDeLVxcrDZg=; b=1Ta5ciNlzIsrLSkCYWRSPE5mpweuWLmhll2DwIv8GUBavpWiB/yFB7CdTGYeOG6I8t Dval0F3m1SiOCZzDj42TYTKgowI8aTjbedFT5MWdgWYNjvVDvvWRZfmoK6kl0kDpHq3J /OUqXrkGVVzg6WyyvTFKn8i0H5C4m8F3CnyNtBeQH6vvL8d/PgSOLK+U1mnIdNYLwcO0 DQNuheMTkFZIW7zMT2F+0McpqksNvy8y9lMB/qqTrDAUEcJkMv92TNVBQ5qkLOCIP6ab Wt454h/aAtqfFb75JGp0IFdjfL3JstY+Ak4XAlOkw2xwiixOf9m18ZrrG2LFpc7Lk42s QQNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=QF3meuGK6XXmnQwE8rQh4QZK8VfyhJwToDeLVxcrDZg=; b=Hlhnon2BaKn0Mlae0I4HTYRY7Cx+lXoiLLBWd2ZIXL+hbzAGy4UJyjxp2B+gOHHcpn R/jCQxDrB5cvvesuHtr32moSucIgpaFOw6oYdhIbnUYdqKhzoKhdobYoXwh46MQdFv8V A5NBeD6imKCTYMHq+9bDCHEN+Ep11hITS3AM8diYFaf9nY6RGv5obGpneQwDhtPToKSm Mpw+A5RIgFLLRA+n2coAEu5zUu9yeRiDQXVRppLq29W6jzCJBHBMqr3EdA0B87VSayY1 h8PuMmfESIS0+l/oAEDt6O8BeKXGY/ZrCHiOpPwflgNkvykhjGf+etOtY2UoDn96/E4n O5HA== X-Gm-Message-State: AOAM5339RzUBCQk4q9Jkp8c0B/Qg6TxaN8J3KdQJrliTDpOX4OhNifgj eNeIZxgdLoR1Lt4gMGZyUZzUQ8N+9xafUw== X-Google-Smtp-Source: ABdhPJxs05BTjI2Ngf11CuDDsuNMjhIFBC97qRgaHSQe+fOEB4ryVfPjsckdmegPKNDZ76hybs9NbA== X-Received: by 2002:a05:600c:21cb:: with SMTP id x11mr3062954wmj.189.1614347928320; Fri, 26 Feb 2021 05:58:48 -0800 (PST) Received: from ?IPv6:2a01:e0a:1ec:470:4460:df99:76ba:9bcb? ([2a01:e0a:1ec:470:4460:df99:76ba:9bcb]) by smtp.gmail.com with ESMTPSA id f7sm13203177wre.78.2021.02.26.05.58.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 05:58:47 -0800 (PST) From: Luigi Iannone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Fri, 26 Feb 2021 14:58:47 +0100 Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [lisp] LISP WG Meeting Cancelled X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 13:58:52 -0000 Folks, Joel and myself decided that the WG deserves a break after the bis = documents, so be cancel the meeting. There were not many requests for agenda item. In the meantime, we will push forward all documents that are on hold = behind the bis documents, namely: lisp-sec 6834bis lisp-lcaf Furthermore, we need to resume the work on other important documents = like lisp-mn and we need a nat traversal solution. We have still work to do :-) @Alberto: can you send an email summarising the update on the YANG = document? We do not necessarily need to wait until IETF 111. @Sharon: no need for an update on the nexagon document, the LC is in = good shape. Submit lisp-fix so that we can discuss it on the mailing = list. @Victor: Uberlay is a very interesting thing, we really need a draft to = work on. The sooner the better ;-) Enjoy the other meetings of IETF 110 Ciao Luigi & Joel =20=