From nobody Thu Feb 1 00:54:09 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EC81318C6 for ; Thu, 1 Feb 2018 00:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 GD8wdcBUM9ON for ; Thu, 1 Feb 2018 00:54:04 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E44461318DC for ; Thu, 1 Feb 2018 00:53:35 -0800 (PST) Received: from LIUXD (unknown [218.241.103.83]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIPCF1XJa+4vOAA--.22935S3; Thu, 01 Feb 2018 16:53:25 +0800 (CST) From: "Yu Fu" To: Cc: "'Keyur Patel'" References: In-Reply-To: Date: Thu, 1 Feb 2018 16:53:23 +0800 Message-ID: <006c01d39b3a$1e0b45a0$5a21d0e0$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01D39B7D.2C2E85A0" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AQHTluQNJn3dcRDtwUy6KH7GaOzx4KOPPxzQ X-CM-TRANSID: AQAAf0AZIPCF1XJa+4vOAA--.22935S3 X-Coremail-Antispam: 1UD129KBjvdXoW7Jr4kZFWUuF1UXry3CrWkCrg_yoWxurXE93 y5KF95JFW5AFsrAF45Jw4akayFq390qFyDAFWDGF97GF95ZrsxKrZ293y2v3sIqw4xuFnr G343KF1Ykay5JjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbSxYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS 6ryj6rWUMc02F40E57IF67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42 I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE 4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r43MxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCj r7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6x IIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAI w20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aV CY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUc3C7UUUUU X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 08:54:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006D_01D39B7D.2C2E85A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, =20 This document adds support for HTTPS URIs in a TAL. =20 I support the adoption =20 Cheers =20 Yu =20 From: sidrops-bounces@ietf.org [mailto:sidrops-bounces@ietf.org] On = Behalf Of Keyur Patel Sent: Saturday, January 27, 2018 4:27 AM To: sidrops@ietf.org Subject: [Sidrops] WG Adoption call for = draft-tbruijnzeels-sidrops-https-tal-00.txt =20 Hi Folks, =20 The authors have requested SIDROPS working group adoption call of = =E2=80=9CResource Public Key Infrastructure (RPKI) Trust Anchor = Locator=E2=80=9D, = https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt. =20 Please send your comments to the list. This adoption call will conclude = on Feb 9 2018. =20 Regards, Chris & Keyur =20 =20 ------=_NextPart_000_006D_01D39B7D.2C2E85A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

This document adds support for HTTPS URIs in a = TAL.

 

I support the adoption

 

Cheers

 

Yu

 

From:= = sidrops-bounces@ietf.org [mailto:sidrops-bounces@ietf.org] On Behalf = Of Keyur Patel
Sent: Saturday, January 27, 2018 4:27 = AM
To: sidrops@ietf.org
Subject: [Sidrops] WG = Adoption call for = draft-tbruijnzeels-sidrops-https-tal-00.txt

 

Hi = Folks,

 

The = authors have requested SIDROPS working group adoption call of = =E2=80=9CResource Public Key Infrastructure (RPKI) Trust Anchor = Locator=E2=80=9D,  https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.t= xt.

 

Please = send your comments to the list. This adoption call will conclude on Feb = 9 2018.

 

Regards,

Chris = & Keyur

 

 

------=_NextPart_000_006D_01D39B7D.2C2E85A0-- From nobody Thu Feb 1 07:29:53 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093DB12711B for ; Thu, 1 Feb 2018 07:29:52 -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_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=nistgov.onmicrosoft.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 szeEr4tyZ_7O for ; Thu, 1 Feb 2018 07:29:49 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4FA1314EE for ; Thu, 1 Feb 2018 07:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tRyun4ij0ehT8Q8wN8fgJEoNWk7xD6bInGrRYl2M4Dw=; b=Vge2SGVM/JxALnR5v/at0d2FlChg2I10Kb9qmYNh4yVpfGVeH/+Du1G2iZZLaTEtLMMZ4hQeIZ3f/kATo5GZ5KjIpOJrCjDmsRzUKLeLRqtfutqcctcMsp4wqgZsRHq606o6Iwbe3QmLdsJdKdNPdGViaJdRUo0kPmGIsJcC/AU= Received: from BN6PR09MB2131.namprd09.prod.outlook.com (10.173.160.147) by BN6PR09MB2131.namprd09.prod.outlook.com (10.173.160.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 1 Feb 2018 15:29:47 +0000 Received: from BN6PR09MB2131.namprd09.prod.outlook.com ([10.173.160.147]) by BN6PR09MB2131.namprd09.prod.outlook.com ([10.173.160.147]) with mapi id 15.20.0444.016; Thu, 1 Feb 2018 15:29:47 +0000 From: "Borchert, Oliver (Fed)" To: Keyur Patel , "sidrops@ietf.org" Thread-Topic: WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt Thread-Index: AQHTluQNJn3dcRDtwUy6KH7GaOzx4KOPtPvg Date: Thu, 1 Feb 2018 15:29:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-originating-ip: [129.6.140.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR09MB2131; 6:649DxnxihkNPkkEIIlmik0UMaM8WDs7f8yztoDxdx33V7L1aaVjS83GC7Af66sQ/RbSRN+CnX/LmnOXYXUohdJhnKasFb6B+wJiLvP5oeOsRsTNn7HLzqzTTEnu3LzOHB5A4c1bpxd4c2kqaK55EC6lOFYaWRQslp4bU6FZ9UCR6EgQ6ShAaReWONBGKMNas24Cw3expl2cy6FKNMX2v5BuYZNKdH8l/Rjd4lpHj/BkEJtoJ7DbjJ0wQOH/vidMB+mzlgd2AJAjFjqvbQ/uMjQ2wDIJySh18LxQsHSIfu8afhHYTypDPSh4IbBsZI7mf1vRJhFshNsnKZf3mzRm5hWATIISWKr1lqKpl6j1k9ByprCyPTPOfq+UAKE+rWbJk; 5:31HbyCiH94oAoPIC7SBQob4i7yVMNIWBMyWfoZhitACwOc8yeV2Tv0nxWqjQQW6UyFQMSG9zPOIC0Gus8Gt20hfK4YN7kg/adswGal/wf9cn9GLLJcVh3aPFx8Jr8iUdcn6iPGcrBINqf8cG4bjEZmDSUjbAtJt+QIZrH+/iPn8=; 24:DIaP3v9hEk6ji7M9QoGCpvvPHClJgPxA/20MHg2cHPa7dTRlE+EGE0baYOPa7vwLt/a7Ba3iuj8JY6y+W3Mry8lVUDNw33yQmk5r4yLIWVQ=; 7:qwUsuqnOrSemMIffvOx39BsGF8A72EqLnxNClPXJuuaDosiOxmHsKdjp8iQtGbD2X7//0UUVQ5KK5LaRQOVfd9TEUcweBDDXQiAPUvXowjuXW8JZ0fjB1PNpR2zqUfeS6mq4bI9j4IvLyeGEEjjg0yz9MM+Po6lrjk6iH/I+AaeIXocxc4oTx938IKKkyU5ivFWbN344kgrgfbrl31ln/65c4hmjEph/ObM/viykvB5YhCgq6/1M21SysBT2ESNO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 56439936-6411-47e5-47ab-08d56988a0dc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN6PR09MB2131; x-ms-traffictypediagnostic: BN6PR09MB2131: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR09MB2131; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB2131; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39380400002)(366004)(39860400002)(346002)(189003)(199004)(30584003)(606006)(106356001)(3660700001)(2501003)(6506007)(316002)(3280700002)(236005)(25786009)(53546011)(6246003)(229853002)(53936002)(5660300001)(76176011)(102836004)(105586002)(99286004)(7696005)(478600001)(14454004)(2900100001)(6306002)(6116002)(3846002)(97736004)(790700001)(966005)(186003)(110136005)(68736007)(33656002)(54896002)(86362001)(81166006)(74316002)(66066001)(77096007)(2950100002)(2906002)(81156014)(9686003)(8676002)(55016002)(8936002)(26005)(7736002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB2131; H:BN6PR09MB2131.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: z5KVWy44xMliXeeZIOx8yfvoLejDTF6XIZyQoOAruPO8go5DUGqxChYToVIzjaSEUG6JUdAZbZbITYO+9iL6BQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR09MB21314C8289227B29247A9DBB98FA0BN6PR09MB2131namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 56439936-6411-47e5-47ab-08d56988a0dc X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 15:29:47.6177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB2131 Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 15:29:52 -0000 --_000_BN6PR09MB21314C8289227B29247A9DBB98FA0BN6PR09MB2131namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIGFuZCBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQsDQpPbGl2ZXINCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0 dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KKFBob25lKSAzMDEuOTc1LjQ4NTYgLCAo RmF4KSAzMDEuOTc1LjYyMzgNCg0KDQoNCkZyb206IFNpZHJvcHMgW21haWx0bzpzaWRyb3BzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZXl1ciBQYXRlbA0KU2VudDogRnJpZGF5LCBK YW51YXJ5IDI2LCAyMDE4IDM6MjcgUE0NClRvOiBzaWRyb3BzQGlldGYub3JnDQpTdWJqZWN0OiBb U2lkcm9wc10gV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtdGJydWlqbnplZWxzLXNpZHJvcHMt aHR0cHMtdGFsLTAwLnR4dA0KDQpIaSBGb2xrcywNCg0KVGhlIGF1dGhvcnMgaGF2ZSByZXF1ZXN0 ZWQgU0lEUk9QUyB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgb2Yg4oCcUmVzb3VyY2UgUHVi bGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUlBLSSkgVHJ1c3QgQW5jaG9yIExvY2F0b3LigJ0sICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRicnVpam56ZWVscy1zaWRyb3BzLWh0dHBz LXRhbC0wMC50eHQ8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmlkJTJGZHJhZnQtdGJydWlqbnpl ZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4dCZkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hl cnQlNDBuaXN0LmdvdiU3QzIzNTQxMGU3YzNlZjQ2NWMyYzQ5MDhkNTY0ZmIzNGExJTdDMmFiNWQ4 MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjUyNTk1MjQzODY3ODQyMiZz ZGF0YT1ZdFBDRU5EOVpNTlVVM3AzWERaMFJQeHZWdFpkYWZEQ1VTTTRublBiREJJJTNEJnJlc2Vy dmVkPTA+Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGlzIGFk b3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBGZWIgOSAyMDE4Lg0KDQpSZWdhcmRzLA0KQ2hy aXMgJiBLZXl1cg0KDQoNCg== --_000_BN6PR09MB21314C8289227B29247A9DBB98FA0BN6PR09MB2131namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg Ymdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgcmVhZCBhbmQgc3VwcG9ydCBhZG9wdGlvbiBv ZiB0aGlzIGRyYWZ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbGl2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+T2xpdmVy IEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4oUGhvbmUpIDMwMS45NzUuNDg1NiAsIChGYXgpIDMwMS45 NzUuNjIzODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4gU2lkcm9wcyBbbWFpbHRvOnNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+S2V5dXIgUGF0ZWw8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKYW51YXJ5IDI2LCAyMDE4IDM6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IHNpZHJvcHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1NpZHJvcHNdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRy YWZ0LXRicnVpam56ZWVscy1zaWRyb3BzLWh0dHBzLXRhbC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SGkgRm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5UaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBTSURST1BTIHdvcmtpbmcgZ3JvdXAgYWRvcHRp b24gY2FsbCBvZiDigJxSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSBU cnVzdCBBbmNob3IgTG9jYXRvcuKAnSwgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRm Lm9yZyUyRmlkJTJGZHJhZnQtdGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4dCZh bXA7ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0MyMzU0MTBlN2Mz ZWY0NjVjMmM0OTA4ZDU2NGZiMzRhMSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVj JTdDMSU3QzAlN0M2MzY1MjU5NTI0Mzg2Nzg0MjImYW1wO3NkYXRhPVl0UENFTkQ5Wk1OVVUzcDNY RFowUlB4dlZ0WmRhZkRDVVNNNG5uUGJEQkklM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtdGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4 dDwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVhc2Ug c2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBj b25jbHVkZSBvbiBGZWIgOSAyMDE4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hyaXMgJmFtcDsgS2V5dXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR09MB21314C8289227B29247A9DBB98FA0BN6PR09MB2131namp_-- From nobody Thu Feb 1 10:49:39 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F28C12E049; Thu, 1 Feb 2018 10:49:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151751097300.24475.14917315480902104354@ietfa.amsl.com> Date: Thu, 01 Feb 2018 10:49:33 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:49:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers Authors : Thomas King Christoph Daniel Kopp Aristidis Lambrianidis Arnaud Fenioux Filename : draft-ietf-sidrops-validating-bgp-speaker-00.txt Pages : 9 Date : 2018-02-01 Abstract: This document defines a new BGP transitive extended community, as well as its usage, to signal prefix origin validation results from an RPKI Origin validating BGP speaker to other BGP peers. Upon reception of prefix origin validation results, peers can use this information in their local routing decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-validating-bgp-speaker/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-validating-bgp-speaker-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-validating-bgp-speaker-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 1 16:15:25 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E5212D86D for ; Thu, 1 Feb 2018 16:15:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xmqbIX_g4GWm for ; Thu, 1 Feb 2018 16:15:21 -0800 (PST) Received: from out20-15.mail.aliyun.com (out20-15.mail.aliyun.com [115.124.20.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD47126DFF for ; Thu, 1 Feb 2018 16:15:19 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.5345581|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03305; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.AgQrhyk_1517530515; Received: from 192.168.216.94(mailfrom:madi@rpstir.net fp:202.173.9.211) by smtp.aliyun-inc.com(10.147.42.22); Fri, 02 Feb 2018 08:15:15 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: Date: Fri, 2 Feb 2018 08:15:14 +0800 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Keyur Patel X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 00:15:24 -0000 I support adoption of this document and will take part in discussions on = it as a developer of RPKI relying party software. Di > =D4=DA 2018=C4=EA1=D4=C227=C8=D5=A3=AC04:27=A3=ACKeyur Patel = =D0=B4=B5=C0=A3=BA >=20 > Hi Folks, > =20 > The authors have requested SIDROPS working group adoption call of = =A1=B0Resource Public Key Infrastructure (RPKI) Trust Anchor Locator=A1=B1= , = https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt. > =20 > Please send your comments to the list. This adoption call will = conclude on Feb 9 2018. > =20 > Regards, > Chris & Keyur > =20 > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Feb 2 13:29:41 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF41312D853 for ; Fri, 2 Feb 2018 13:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0_VCsJg5MV8F for ; Fri, 2 Feb 2018 13:29:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B4D9B12D873 for ; Fri, 2 Feb 2018 13:29:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ehitt-0001DD-LG for sidrops@ietf.org; Fri, 02 Feb 2018 21:29:37 +0000 Date: Sat, 03 Feb 2018 06:29:36 +0900 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] wglc requested X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 21:29:40 -0000 may i be pushy and request a wglc on draft-ietf-sidrops-ov-clarify? heas and i lost too much time yesterday chasing this problem. randy From nobody Sun Feb 4 15:48:04 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993671243F6 for ; Sun, 4 Feb 2018 15:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.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 inlsmnU17sBb for ; Sun, 4 Feb 2018 15:48:00 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0084.outbound.protection.outlook.com [104.47.124.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47621120725 for ; Sun, 4 Feb 2018 15:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/oR/1LXhPDV0wSNUafFI2VyyGp2g/7uUHcpmGKUyzt4=; b=jYjhzJwnvwb3HSwjSCLgECBKfO0e2Pw5moyEr3m/YMnRtL8vEZrZSBK+xMKEux2kBCh4IU0gWOSugUPZCCKKv+MWGHsntrqmcvaAYeZrSI/Agu8oGyc/zQic/2VaKGga936KtQ6I2C/tQwROsrbsYKzv2n9SdSJz2DjPSvMDHCw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=tomh@apnic.net; Received: from tomh-laptop (203.119.0.128) by SG2PR04MB0757.apcprd04.prod.outlook.com (2a01:111:e400:5209::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Sun, 4 Feb 2018 23:47:56 +0000 Received: from tomh by tomh-laptop with local (Exim 4.89) (envelope-from ) id 1eiU0d-0004SN-F5 for sidrops@ietf.org; Mon, 05 Feb 2018 09:47:43 +1000 Date: Mon, 5 Feb 2018 09:47:43 +1000 From: Tom Harrison To: sidrops@ietf.org Message-ID: <20180204234743.GC3612@tomh-laptop> Mail-Followup-To: sidrops@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-Originating-IP: [203.119.0.128] X-ClientProxiedBy: ME2PR01CA0016.ausprd01.prod.outlook.com (2603:10c6:201:15::28) To SG2PR04MB0757.apcprd04.prod.outlook.com (2a01:111:e400:5209::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 51512728-7279-4ca9-9ade-08d56c29b76b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:SG2PR04MB0757; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0757; 3:DiDpgmUWFuN3K69QmB5qFJQ6li8kPEiDX1wyDF/oIgeBW4jMAFmfV0ZfQS9bWXW/GajwAW8Bl0Evh9BZzGl61x97xq0XzXH3kA0JXQZHLjj6j95IkyaEf3VSNbHFyHkIqMRx8HhCRTmpdkMYl7p1r3I+czsthz7DAVzk5/s4zk9dxaLj3WVCZyEx6FKOJ3E58cRIsUODZRudMTyXlY7+5j2Z1m46UeICHpbt31V3lkIb3AAo5jhsG+U06FZWyc7a; 25:FOixfYSgSLJKurfDAvOLYIHfILFb0rZ5azOBSJuZWceZIce3tEoWn8jmADXhIp3nrHZ6Ccw4ygiBpW0gMXSsZmTAaypYnEwDpegXH1oDWkQgQnHHuEnsuuyFQHIWMw41wT2cvnQNLrvgq9PlyDoNumt+Jb6lm5ecV2kyr+CkQJFkcjpY1JbIK053uEnBXP6wD+oav1N8jYQOHGXkC4waO0MlLGmNpo4GejbVjSm/17DCECToHhfWf0Abm2WsUMMFQ5cXbkoB1S1Wmp5prbursE0+VTTt/9VaRexyC5dHFVLMkVjw2dkGYEvlVLRS8ShZblAEqP6HKRdyHfzPIbmAZw==; 31:GtlQT7Oe3mtw1H2JP6p8GmquePUrxV+9ssDHLq1HzWQO3ICOPt0KFFxQAu9zMKRag2OlGBuSJIVey5F/XiugrbG6eKB0oW5v6hLRedjyn76PlEwECiXB08f1yrvS2xVc1hK79YVkCZA5VVBRVUEhW7QTkDT4HFODC0bKMJu5sXkrjSGhQqOxfRtJYjknoAFGKm+iFwdDpU8+xGfO0FZC11k3M2mhe0fNBvL19hd7yHI= X-MS-TrafficTypeDiagnostic: SG2PR04MB0757: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(145661691156799); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:SG2PR04MB0757; BCL:0; PCL:0; RULEID:; SRVR:SG2PR04MB0757; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0757; 4:0yY8aclMwEhlj2I5LXM+qOwmxAYJZTbnA7FWe9RgCztfJT7DLwtu37jKLrDxujk9qPRlekcykZEI6brFa6pyFvXqdylzxwZiWcU8xJlEI2wq1hx1zcxns+RsMWtb7KfHtQ8H1MBLUdDogikpVSt5k6UotE4Rf9XkW1lIhorJfOBo0ACvKtTCBsVRGGmQekJKYncdGRbGOS4/tis+RQ78qkyc7MTy6TP++8x2pMnBgnKO4BddxJNUmNLbjmiB0YF7DaZNEBGqQHRS0imgr3TBfbzZ80U8TGWU0Syplmzd3Omsp2ipSzPpp8ICJ6FHc7nSVu5RIZBCuw4dfJ+mNrj+LgIox6CoE3BGKd0wSr9O56M= X-Forefront-PRVS: 05739BA1B5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7916004)(396003)(39380400002)(376002)(346002)(366004)(39830400003)(189003)(199004)(6116002)(3846002)(2906002)(23726003)(6306002)(9686003)(53936002)(386003)(316002)(33896004)(9746002)(58126008)(83506002)(59450400001)(52116002)(106356001)(66066001)(81166006)(46656002)(8676002)(26005)(2351001)(2361001)(105586002)(1076002)(305945005)(9786002)(50466002)(5660300001)(33656002)(8936002)(81156014)(122856001)(57986006)(33716001)(68736007)(7736002)(97736004)(47776003)(6916009)(186003)(16586007)(83796002)(86362001)(478600001)(966005)(18370500001)(107986001); DIR:OUT; SFP:1101; SCL:1; SRVR:SG2PR04MB0757; H:tomh-laptop; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SG2PR04MB0757; 23:OczNnPaoWdCA29CNqnGW/BkRWsBp/Ncjvqfrwozcn?= =?us-ascii?Q?adQ12WKIviRkpyDVpePtW51jj1q22diQ9nVDtCVHzzg9r/PlxuaSCpAGMPPI?= =?us-ascii?Q?XYtRi+v8Xy4zEiHuXnoohq9q/+Kg6PY2rh+QHTw0osojrbFsikg2mIr0qVoN?= =?us-ascii?Q?boSSrCkvoPuPkuT/yCsEDhaveIkV6ldC/GHhe3yqYJuMB6ksGFbbmdJQzrEs?= =?us-ascii?Q?6aMDbWfT+UWtAlj98w+dPdLw4VL17FbY7aJqrP/ttPwSrpIaqX1ZnzMoXZyK?= =?us-ascii?Q?bZYxSFY88/DAGCL83P+P+Qu9mvmrb0ELpMxlWNlVdCJP7GI7Q0WChsIAyKNX?= =?us-ascii?Q?NZanJZ3MMqz9k1knj9zCMsV7xIVLnJ9QZw5UX1jS7GfjywMPielvTmHhsart?= =?us-ascii?Q?JreMr8XZMUVqZOBOaHL+7VMRcu6nVNxp0gYexoHyjIgiKE4E520ltvZsKMg7?= =?us-ascii?Q?m6WnJEiJz9jOwOnop2P0Ho/BWb08UGyfZ7S2Jh0V3uDQMkydmzfYEbXWfiQe?= =?us-ascii?Q?1QcNEMM7B2i3ZGTJy8xyvN5NeOyIhJ+JjQDCjslKAIH0n7GIHWmjC2I/NDpx?= =?us-ascii?Q?TnxbeuiN5o0e1i0Ya4xk+Umn3CAUwbHtojNAFKZddDr5kSIgclMMEqGIKLyL?= =?us-ascii?Q?Ik0CMKRzNELywm458IRdMrIiWZP6EkJQ7Q2VKFljyeAXhknQEMA+xNxtFgkz?= =?us-ascii?Q?XWyLsldprUFH6Ui+mI+BeAQCsp4V5McPzKhb2Js2IMkQNdMTUzP534MfdEX/?= =?us-ascii?Q?DXho4D79B18jk+bOGb8yADwgknmWL7IO5sOdM5IPvmnHe7II0hnFVCYajLXt?= =?us-ascii?Q?e6MM6gvmLfj2fetuAVq3XYMXAr0JEqnT7cgeJCBeVBGT9e6tqyNAiDz0Z6K3?= =?us-ascii?Q?7WHM0oeIJP5CU/EAmuAJgJABw4/9x5r9z3aJttnO6Lw4kNXGg6fd6UgyqZF3?= =?us-ascii?Q?EBXYfmF35neMJOWMeX3PLVN44W/PYVUAsgclOvjNQhWCsbx/Ucd6Nzb1i09P?= =?us-ascii?Q?yJugLab/DIJ4Vth1+u3LFIh+2F31IU6WUyz2XcjFMuJoPbggXIqm6uVqEIbo?= =?us-ascii?Q?ZqU2cRE+0jTrO7e0qiBzDsGHlvAF2TogmmbjEPPBoBDnqsvPBz85/Or0vQpH?= =?us-ascii?Q?t06UGm42hFE4EhJuHXceyp5WVTiXUPIc9piGUY90IztjisfDLWPb9yxjqHGM?= =?us-ascii?Q?liC45W/8A0HykqB/KfF2dREc7PirudhQA+JktrVwUZ+7Nv23hNU5OVV0eyTy?= =?us-ascii?Q?j59irR2XFBFL8M6ZBlfoqMZHyP+VC9E1p/BMDRJAiGxwrqUpTai9Idu5ZyNF?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0757; 6:k20+jhdXHO6u+f90VFl75nmoAFgW4jgeJ0ARYYvai0Wm/5k2hLrYtAYfsWzDCPvlOO5FONi/EL7q/T5miqsNXsjyWKdX77ng7bqzDQ8NYOvPzdxU8uuEBN7nWy/Mt4fQKZqMWarewwshyjS2VYGpEhOelNsTwhT+/O5a/GzOhmoMceY5/8ZLTJ1++LM1tVP9NxXqT8pbs1DcprIM80F+5oNW5JFsrYto4yXwY8iBguNoAHlxzfw/tsTJowSj8BgXKpjyG1yomL/5Ai7DCfmgIsROFxaOC2G/49sdXbIKpqMGRKxURySU1kQkggTodO7G26MkrWs2TwWGV41JmwoNncdHHZqVr9SRJApYBkw+Hsg=; 5:pg4K97JKoaFCk75RIwUhhPmhQxhJJ5fMrJm3FIxWkkgyhWKdXMOjqGV4iWNzx/KX0p0n4o5V1+QM7HqpXyLFxyAt2LknZO8ZugVKBMdpbyVbi32HFeoyxiqHtb3cS0djZGQ1gfF7ZYY6IhXWhcTpXuiZGIEdUy6+VE/o4IB1Mjo=; 24:WILtKQSTekCyHsDbxyO9izwoGeSMOEv6xy16qvrHPbK+Ag6a/Y3C5CX51t2afwAJZ6gTDEh/ApmyRtC30XqUorG8NU8ticF3NCYdaHfW7L8=; 7:U5r/CHxK/D5KC+8jA9kQj4hfnbgpn02GvvD0+5N9M0y51XcKecynz9Tu4JMh9wDnZN33ZnQbQdqfjFLTBO4L70J7TpJjIsU52Ltr/U3fEQ/GoSeZthuUmkLIM3grw6KjkJ0Q5xanMUlJMMY18LJGOb+UsEKQIbwVwpoxEGIcYhI2CjbcCgNWvF59iPUIL0DG55/My0ulS6r2flvk/opYLjXAhZ71gGKeTorlhmLcMUY2WcQFMCdYSqUtlivfkQQP SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2018 23:47:56.8284 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 51512728-7279-4ca9-9ade-08d56c29b76b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR04MB0757 Archived-At: Subject: [Sidrops] APNIC's deprecated TAs have been removed X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 23:48:04 -0000 The trust anchors that were deprecated as part of APNIC's single trust anchor process have been removed from APNIC's RPKI repository. Relying party software that is configured with these trust anchors will now begin issuing warnings about their absence. This does not affect ROA validation outcomes: all existing ROAs were re-homed as part of the single trust anchor process, and no new ROAs have been issued under the deprecated trust anchors since that time. See https://www.apnic.net/community/security/resource-certification/#st-anchor for more information. -Tom From nobody Wed Feb 7 10:37:32 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66931270B4; Wed, 7 Feb 2018 10:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Z_GAFDNpQSab; Wed, 7 Feb 2018 10:37:28 -0800 (PST) Received: from deliverix-glo-01.ams-ix.net (deliverix-glo-01.ams-ix.net [185.55.136.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2DD1270FC; Wed, 7 Feb 2018 10:37:28 -0800 (PST) Received: from [91.200.19.243] (unknown [91.200.19.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alam394) by deliverix-glo-01.ams-ix.net (Postfix) with ESMTPSA id 41F8920162; Wed, 7 Feb 2018 19:37:26 +0100 (CET) Message-ID: <5A7B4764.8070308@ams-ix.net> Date: Wed, 07 Feb 2018 19:37:24 +0100 From: Aris Lambrianidis User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: sidrops@ietf.org CC: draft-ietf-sidrops-validating-bgp-speaker@ietf.org References: <151751097300.24475.14917315480902104354@ietfa.amsl.com> In-Reply-To: <151751097300.24475.14917315480902104354@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:37:31 -0000 Greetings everyone, Might we again solicit feedback on the draft? It is an evolution of draft-ietf-sidr-route-server-rpki-light, with the following *key* changes: 1. It now discusses BGP speakers instead of IXP route servers Reason: The draft can be applicable to any network operator instead of just IXPs. 2. It introduces a new EBGP Prefix Origin Validation Extended Community (instead of re-using the BGP Prefix Origin Validation State Extended Community as described in RFC8097). Reason: This new community includes the AS number of the validating BGP speaker in its Global Administrator field, a crucial piece of information for troubleshooting. Many thanks to the valuable feedback so far on and off this list for bringing the draft to its current state. Kind regards, Aris internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers > Authors : Thomas King > Christoph > Daniel Kopp > Aristidis Lambrianidis > Arnaud Fenioux > Filename : draft-ietf-sidrops-validating-bgp-speaker-00.txt > Pages : 9 > Date : 2018-02-01 > > Abstract: > This document defines a new BGP transitive extended community, as > well as its usage, to signal prefix origin validation results from an > RPKI Origin validating BGP speaker to other BGP peers. Upon > reception of prefix origin validation results, peers can use this > information in their local routing decision process. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-validating-bgp-speaker/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-validating-bgp-speaker-00 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-validating-bgp-speaker-00 > > > 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/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Feb 7 11:04:50 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B826512D811 for ; Wed, 7 Feb 2018 11:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 vSOW3O43lnhq for ; Wed, 7 Feb 2018 11:04:47 -0800 (PST) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (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 F357E1277BB for ; Wed, 7 Feb 2018 11:04:46 -0800 (PST) Received: by mail-wm0-f41.google.com with SMTP id r71so5155556wmd.1 for ; Wed, 07 Feb 2018 11:04:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8VZj0eFjEecY3d5zToSohOnIc4cyiVKd1rkM7BUy57w=; b=WcBXJYD1qIL9+dZrdntTvfmTHJVXvDrlORMq9lAkL+DrfXNdQJiCnCg6TzvsSUVgd+ Q5G1aWsAyylnIANKnnacYfJKOhDE5hKse8PY435L2S3hc3SDd7AofkzgtlYhxA9h6Lly F5uTJmh/H2K/m0DK0HYOB0MxxThcB/sWhz5KlLnFMFeXN1L3bPNurHIRwXu24CxzhzPJ EvILl3ZFAVTzfvoyBx4sdBmDAm6THtzO1vEKKH3I2ccOCaFnSHQZTrjZ3G5/NI0zHnuq aApyc+M/t6izjNMpcVqyAurYTUXPoB8nQY12W8BjA6kEFC5O9yVJ4zZV7aBMl53l5e8l e62g== X-Gm-Message-State: APf1xPBd6wvutUhulZfvRdWjEA8mxLl+7OcBI50ZYKXAX1Y4Y6IMnNdF uIRmv9BCJVXuJ3O5wVWoEI6bIMc4IDU= X-Google-Smtp-Source: AH8x227J1mMHpiHDWz1uGbYg+JnfeNlvsbhCK/D9XJXZSaxJG5aJLHoZ9DSdgoIJOyREh+Bdi3Er2A== X-Received: by 10.80.146.211 with SMTP id l19mr9523706eda.152.1518030284783; Wed, 07 Feb 2018 11:04:44 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id c5sm1549730ede.30.2018.02.07.11.04.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 11:04:43 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 0a38a0ca; Wed, 7 Feb 2018 19:04:42 +0000 (UTC) Date: Wed, 7 Feb 2018 19:04:42 +0000 From: Job Snijders To: Aris Lambrianidis Cc: sidrops@ietf.org, draft-ietf-sidrops-validating-bgp-speaker@ietf.org Message-ID: <20180207190442.GS5974@vurt.meerval.net> References: <151751097300.24475.14917315480902104354@ietfa.amsl.com> <5A7B4764.8070308@ams-ix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A7B4764.8070308@ams-ix.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 19:04:50 -0000 Hi, I think a much safer mode of operation for BGP speakers is to reject invalid announcements, rather than "tag with extended bgp community & propagate". Merely tagging announcements with some community and hoping the remote peer will take some action on the community seems a bit silly... I'd suggest to remove "Simple tagging" and "Prioritizing and Tagging" from Section 3. And remove "2 - Lookup result = invalid" from Table 1 in Section 4. Kind regards, Job On Wed, Feb 07, 2018 at 07:37:24PM +0100, Aris Lambrianidis wrote: > Greetings everyone, > > Might we again solicit feedback on the draft? It is an evolution of > draft-ietf-sidr-route-server-rpki-light, with the > following *key* changes: > > 1. It now discusses BGP speakers instead of IXP route servers > > Reason: The draft can be applicable to any network operator instead of > just IXPs. > > 2. It introduces a new EBGP Prefix Origin Validation Extended Community > (instead of re-using the > BGP Prefix Origin Validation State Extended Community as described in > RFC8097). > > Reason: This new community includes the AS number of the validating BGP > speaker in its Global Administrator > field, a crucial piece of information for troubleshooting. > > Many thanks to the valuable feedback so far on and off this list for > bringing the draft to its current state. > > Kind regards, > Aris > > internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the SIDR Operations WG of the IETF. > > > > Title : Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers > > Authors : Thomas King > > Christoph > > Daniel Kopp > > Aristidis Lambrianidis > > Arnaud Fenioux > > Filename : draft-ietf-sidrops-validating-bgp-speaker-00.txt > > Pages : 9 > > Date : 2018-02-01 > > > > Abstract: > > This document defines a new BGP transitive extended community, as > > well as its usage, to signal prefix origin validation results from an > > RPKI Origin validating BGP speaker to other BGP peers. Upon > > reception of prefix origin validation results, peers can use this > > information in their local routing decision process. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-validating-bgp-speaker/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sidrops-validating-bgp-speaker-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-validating-bgp-speaker-00 > > > > > > 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/ > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Feb 7 12:28:27 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7612778E for ; Wed, 7 Feb 2018 12:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 C7YgTLQ9lJHF for ; Wed, 7 Feb 2018 12:28:13 -0800 (PST) Received: from sonic306-27.consmr.mail.ne1.yahoo.com (sonic306-27.consmr.mail.ne1.yahoo.com [66.163.189.89]) (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 7B3FB12751F for ; Wed, 7 Feb 2018 12:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1518035291; bh=txhD6wZtWyr6LQvs52m1oEblvLP1m3fXZFplMYvAo5I=; h=Date:Subject:From:To:From:Subject; b=e2iNvYbH9v3myTjdnEiqNRxc2w16ZL2KXkDkl0Hkq/pPVKfSW3GOwUcslGCo7TWiqjUcxPe6NXWyjYVLjG1NUBooMN1B86ayyIYvpejzDEK1VxVNYaRhA3szv1RdCZio688o9+uXQlGxuwAqXIfJ2fjDSOlETx4S/zSFdxNN0b41uXCYhEXK05azErnwpkloHbCkJKgNwB5NlZOxsrnoS0baMZFrSDjWj1jArQOL6ReD0RnaZR5BPvME8dH7ODn87FZE2vjL6zMnojJ8eCJtbWXRRf36tjvOoN5ifYm7XG7qTnxWvp4+M95qdUHLQjOMEpeLTXZQN8R3QZGy4E+5tQ== X-YMail-OSG: 8cSCFZIVM1nrbCLJUk8Ai0u31vQUVrKn30C.9Iz8RbpbhCtbwg2oBjoHdLTNMTE ugQBc334Wg5bTuBTGJQNahN3FPZkfVW_r4Ghg0JwB.K72J1xRrj5dlj0J2t7au93FtG66jyuJOw5 PSSUtsnNBXNwmlwQG_5OD1enXebXj7WC6xagZl81h.IgqH27WykZERN.oUThirVaFXulDP8u4YH7 2NH2GXe.Gm_QmOmydOuG0_Q54jFhLIuy5pwGwPwxcwwtlziAN6NAU.iqKJOT.F7AbH7Gb9PUv3wp YaDKfVXo.0myUB2IWSHO7AUaRmTV4ypaq8SzY70nDv_ACwl3sOVRMh1WhQPz0_ur8l7bxRMxzkJZ Nr8iv3ixMBwvYid7DBolFokLl5ol.LsmftbJbfpwuo01Fkt77jTy7rwSnWsl1epA72x6GLLZxAj9 URWlLuA2_h0GeZ6AsYtToWqN1GBeRzkw_qjK374kaE_4Fi7bwnzXlkt18Mgn9QqWw3V5nO5WMwgM WTVgXh3mhgcnQvNcQLEJG5m06YLvBv0rBB15HhDOQWyFFiA9aPOcId0oxxBze8PIHi0A- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 7 Feb 2018 20:28:11 +0000 Received: from smtp108.biz.mail.ne1.yahoo.com (EHLO [10.0.0.12]) ([98.138.60.14]) by smtp413.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 3f1995dd11f0f273948744ffedbbbee3 for ; Wed, 07 Feb 2018 20:28:11 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Wed, 07 Feb 2018 12:28:08 -0800 From: Mehmet Adalier To: Message-ID: <722F3CB0-3262-4596-8A1B-3CBCB867921F@contoso.com> Thread-Topic: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3600851291_1109176933" Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:28:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3600851291_1109176933 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I have reviewed in detail the draft https://tools.ietf.org/html/draft-borch= ert-sidrops-bgpsec-algs-rfc8208-bis-00 I support that the document be adopted by the sidrops working-group as a wo= rk item. I=E2=80=99ll be happy to help as needed, Mehmet Adalier Antara Teknik LLC =20 --B_3600851291_1109176933 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable --B_3600851291_1109176933-- From nobody Wed Feb 7 12:35:37 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDE312D863 for ; Wed, 7 Feb 2018 12:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 DUD_ccFBM0v0 for ; Wed, 7 Feb 2018 12:35:33 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 6187112778E for ; Wed, 7 Feb 2018 12:35:33 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id c128so2866995qkb.4 for ; Wed, 07 Feb 2018 12:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nhy0s1jNe28VQe4w2UNeieLPZMIB6RQktqD+uwHqrSk=; b=eAx/cPmI12VvaJA9LHn9cwbw9T7a1RH9FpZsyO6gSvcZzGMAJ509HHC46D3FwmJFqL rqT2BIDT5UOGh9AIEO0UbjUuRwGoaFj3FYiHopzvM8aGPZMfbI69fMN17QJUW9jGRZdB Wds5JLyaMyHIRXvp7DdsT105ec11LQimDRjdc= 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=nhy0s1jNe28VQe4w2UNeieLPZMIB6RQktqD+uwHqrSk=; b=RF7TU+dZuSAi41+0/p4turO2cEZOKmxX2QmK0zdV+WlQ45W5Fzt3gjUGKHAhGV6USD Vwsscdo+2v5LuI9bhLOnIXDJBLoN8azV+e6DyuTNbtQsErAcmtoluusWvbOB2M4TKWSD ZzAfd7BdxZlxzizeQkTPKxDWhCiCHBFqAHmhZ+9pu0Kd8PEtEJNR4mKw0FbqI3uJtod8 jshXfd1Fcihuz68MdIbRfznh8SLJ7ngpj5F5UGfzH5GgJztjxj6y2BQf+L/iNdEd3s3u dxW76ail5D5jTIIVP14cRIS45l8yd5q1rCksJjt2WSokMHUHy7QY6njSU6ElJXcx0vus Ji/Q== X-Gm-Message-State: APf1xPCRLP+9v5Vdlq+XI37HFn+WBojEg2K6LAzky+ksySnsEO2ICdv4 I8c+9dIU1VwoWDlE0fpD9lYXAe5zSA4= X-Google-Smtp-Source: AH8x226mtRWW0eNG8YWTLXiyGKoQD2xlMhNNm7STWzM+oOP3H79BgB2YN49fuGWxHZoByUymENVNyQ== X-Received: by 10.55.120.66 with SMTP id t63mr10577200qkc.345.1518035732605; Wed, 07 Feb 2018 12:35:32 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id q6sm1672710qkj.31.2018.02.07.12.35.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 12:35:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Wed, 7 Feb 2018 15:35:29 -0500 Cc: sidrops@ietf.org, sidrops-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A7DD287-CD74-4735-AF0A-676501036200@sn3rd.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:35:35 -0000 I=E2=80=99m obviously biased, but would like to get on the record as for = adopting anyway. spt > On Jan 30, 2018, at 13:38, Christopher Morrow = wrote: >=20 > Howdy WG folks, >=20 > Oliver has done some work to further his presented material from = Singapore: > "Extending RFC82088 by adding Experimental/Documentation algorithm = IDs" >=20 > This is reflected in the subject draft/-bis for RFC8208. Can we please = take 2 weeks (ending: 02/13/2018 - Feb 13, 2018) to read/review/comment = and consider if this document should be adopted by the sidrops = working-group as a work item? >=20 > Draft:=20 > = https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-algs-rfc8208-bis= -00 >=20 > thanks! > -chris > sidrops-chair-02 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Feb 7 13:12:03 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B373B12D7F1 for ; Wed, 7 Feb 2018 13:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inconcepts-biz.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 eKaU_13u8Xoi for ; Wed, 7 Feb 2018 13:12:00 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 A89C012785F for ; Wed, 7 Feb 2018 13:12:00 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id x203so1455699vkx.10 for ; Wed, 07 Feb 2018 13:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inconcepts-biz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=7lbEdi4sIpOaDlMYCBSb4TAUlfB4tziTahGGb44zjrA=; b=0T2pkXc8ZNZj/uxzkMMZZLh/kPAwAIUAWBlR0fsAmAnIf0u3DSld3RlPumLXv1dITe UiozwEsl4mvY6hPH5GU7i4JRQQkG0W5LXCDVMcBBt2rrHNAhK82D0BeAKTjYOsAjCJbT DMjf+Up7X/Bt1jtzOBw28PM+1K9bkuajyUhWTqQQsXv2J6z4cMsh1geI0wYkSRNebjlf N6rclIxgFUvyG53CrjnX7mhxy2YQ0R+BSGJCMtHDe6HyTf2Zj1kNAPOCK4zklT8R6D5S bVRIY2z1A4gHc6IsWtLmMY7m4hij0xIdKMkPpe018YZ+P4rqtmbybNdT3FVEaoN4dTAc aNlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7lbEdi4sIpOaDlMYCBSb4TAUlfB4tziTahGGb44zjrA=; b=leH1HiXwzm9wPi6uo7dOhTIENhbqI55Z56gRzZnYh4tOd8YFQ69tURCe7Z2xdg+py+ ZLdxikjsLpdI08q8sEI1osg3+nBIoRqXTDcNwSDUyKEVLL64iE1/tBFy1UND960ig6We SsdCaxhqcHrz1IB6n7tgfvN4l01Rzbk8vVV0Gljl4NBP4H6vxAw0OgDUabvuvRrvkqwH y8NyGrIZGLDJR9UPyyeY8cGPq/B7qp4omtP6Ka6Fz9mNroX4YQJ6P914oZvYIFZ8DfbE K3esSfOJxga3xxYSezmxjyObTVzfb+SEinl9oM/lKLUTCKZlzX36dUIy657dR+wi4DrD JgHQ== X-Gm-Message-State: APf1xPD6jtEgQiuChar6iUHZQPFFgxJ6V5SMeR8wC3LHD/mSiESjsmL5 F76oWoZU6Zh8NK9CjmkSEBATFRlh6DQ2NtiYzBJgmP1K X-Google-Smtp-Source: AH8x226wp+UxMeQTDzJQVrXJSCDiq4w3SQSNK/x7p8Il5dbxoUya9doDEQLsukR9Gg0rPE1IbPU8Cb8ZcyNaKCt0ufM= X-Received: by 10.31.87.69 with SMTP id l66mr6666289vkb.132.1518037919428; Wed, 07 Feb 2018 13:11:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.61.151 with HTTP; Wed, 7 Feb 2018 13:11:58 -0800 (PST) X-Originating-IP: [74.130.6.149] From: Jeff Wheeler Date: Wed, 7 Feb 2018 16:11:58 -0500 Message-ID: To: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:12:02 -0000 A colleague brought the recent draft titled "Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers" to my attention. The authors clearly recognize a hazard of implementing this draft -- trusting the claimed validation state received from an eBGP neighbor. The draft makes this explicit in both sections 5.2 (..receiving the .. extended community) and section 7 (security considerations.) Rather than depend on neighboring networks to configure their devices appropriately, the draft introduces what I believe is a novel / unique handling for an extcomm, namely, it is transitive yet only for one hop, and has to be deleted instead of propagated to any neighbors. This requirement seems like a significant obstacle to implementation. It also sets up an incorrect expectation that you should be able to trust if you receive this extcomm that you got it from the directly-adjacent BGP neighbor, and not from a distant device. This won't be true until the neighbor updates his software, and normally in BGP, we would expect a Capability to be signaled so implementations have explicit knowledge of neighbors' relevant BGP features. The draft does not call for a Capability. In light of all this, I think a Well-Known BGP Community makes more sense than an extcomm. Operators are already familiar with signaling and filtering them and this would avoid the need for vendors to write code for the special propagation scope of the proposed extcomm. I further believe this draft might be misguided as a whole, but I imagine the authors, being IXPs, may have their members to answer to; and are perhaps trying to create transition tools to satisfy everyone. My colleague reminded me that you must actively mess yourself up to cause your IP address space to fail RPKI validation. Perhaps it is unwise for IXP route-servers to propagate invalid routes. -- Jeff S Wheeler From nobody Thu Feb 8 02:24:55 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C081250B8; Thu, 8 Feb 2018 02:24:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151808548929.17020.986674692273846423@ietfa.amsl.com> Date: Thu, 08 Feb 2018 02:24:49 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 10:24:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers Authors : Thomas King Christoph Dietzel Daniel Kopp Aristidis Lambrianidis Arnaud Fenioux Filename : draft-ietf-sidrops-validating-bgp-speaker-01.txt Pages : 9 Date : 2018-02-08 Abstract: This document defines a new BGP transitive extended community, as well as its usage, to signal prefix origin validation results from an RPKI Origin validating BGP speaker to other BGP peers. Upon reception of prefix origin validation results, peers can use this information in their local routing decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-validating-bgp-speaker/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-validating-bgp-speaker-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-validating-bgp-speaker-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-validating-bgp-speaker-01 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 13 16:15:01 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10B612D942; Tue, 13 Feb 2018 16:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR5EIhmkeXgn; Tue, 13 Feb 2018 16:14:57 -0800 (PST) Received: from mail.mikesoffice.com (v6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D84012EABF; Tue, 13 Feb 2018 16:14:52 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 729B114769B; Tue, 13 Feb 2018 16:14:51 -0800 (PST) From: Michael Baer To: sidrops@ietf.org, sidrops-chairs@ietf.org X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 00:14:59 -0000 I've read through the draft, believe it to be useful for BGPsec development and support it for being added as a work item. -Mike > Christopher Morrow Tue, 30 January 2018 > 18:38 UTCShow header > Howdy WG folks, > Oliver has done some work to further his presented material from Singapore: > "Extending RFC82088 by adding Experimental/Documentation algorithm IDs" > This is reflected in the subject draft/-bis for RFC8208. Can we please take > 2 weeks (ending: 02/13/2018 - Feb 13, 2018) to read/review/comment and > consider if this document should be adopted by the sidrops working-group as > a work item? > Draft: > https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-algs-rfc8208-bis-00 > thanks! > -chris > sidrops-chair-02 -- Michael Baer baerm@tislabs.com Senior Software Engineer From nobody Wed Feb 14 14:23:05 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AD51201FA for ; Wed, 14 Feb 2018 14:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 r51gHW65v0R3 for ; Wed, 14 Feb 2018 14:22:52 -0800 (PST) Received: from deliverix-glo-01.ams-ix.net (smtp.ams-ix.net [IPv6:2001:67c:1a8:a101::72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E2B12D88E for ; Wed, 14 Feb 2018 14:22:51 -0800 (PST) Received: from [192.168.1.67] (178-84-101-197.dynamic.upc.nl [178.84.101.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alam394) by deliverix-glo-01.ams-ix.net (Postfix) with ESMTPSA id 1A546204FE; Wed, 14 Feb 2018 23:22:50 +0100 (CET) Message-ID: <5A84B6B8.50207@ams-ix.net> Date: Wed, 14 Feb 2018 23:22:48 +0100 From: Aris Lambrianidis User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: Jeff Wheeler CC: sidrops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:23:01 -0000 Thank you for your comments, Jeff. I see two prongs in your email, a technical one (signalling method) and a "political" one (for lack of a better term), i.e. whether this draft is misguided in principle. Let me put aside the technical component in this email because I think it's a matter of aligning the draft with the wisdom of the community, which can happen relatively easily if we first agree on what we're trying to solve (i.e. the political issue). What the draft is trying to accomplish is to standardize the way certain operators, primarily IXPs, signal ROA status to their customers by way of a BGP community. Putting it another way, if there is no common understanding on how to do this, we run the risk of operators implementing this in an ad hoc way, which increases operational overhead on both the operator signaling such RPKI data, as well as their customers. This is already a problematic reality for numerous IXP offerings, such as statistics and telemetry. If I am correct in detecting an "outsourcing security is bad" element when you mention the draft potentially being misguided, I would argue that yes, I see your point, but I believe it's generally better to allow for such a decision to be made by the customers themselves. Signalling ROA status in route servers is already happening (France IX, AMS-IX), for better or worse. The question then now becomes, does the community want to consolidate into one way of doing things or not. I also have to point out that people are outsourcing security in many levels already, implicitly, when they use commodity software, such as operating systems, and hardware, such as routers and switches. This is just another level. Any time any one is using an Intel or AMD processor, or any processor not of their own making, they are outsourcing security, I hope you agree. Let me also point out that in theory, forwarding "invalid" prefixes is bad. However, our own operational experience so far has shown that most ROA invalid prefixes are due to misconfiguration rather than malicious intent. Kind regards, Aris Jeff Wheeler wrote: > A colleague brought the recent draft titled "Signaling Prefix Origin > Validation Results from an RPKI Origin Validating BGP Speaker to BGP > Peers" to my attention. > > > The authors clearly recognize a hazard of implementing this draft -- > trusting the claimed validation state received from an eBGP neighbor. > The draft makes this explicit in both sections 5.2 (..receiving the .. > extended community) and section 7 (security considerations.) > > Rather than depend on neighboring networks to configure their devices > appropriately, the draft introduces what I believe is a novel / unique > handling for an extcomm, namely, it is transitive yet only for one > hop, and has to be deleted instead of propagated to any neighbors. > > This requirement seems like a significant obstacle to implementation. > > It also sets up an incorrect expectation that you should be able to > trust if you receive this extcomm that you got it from the > directly-adjacent BGP neighbor, and not from a distant device. This > won't be true until the neighbor updates his software, and normally in > BGP, we would expect a Capability to be signaled so implementations > have explicit knowledge of neighbors' relevant BGP features. The > draft does not call for a Capability. > > In light of all this, I think a Well-Known BGP Community makes more > sense than an extcomm. Operators are already familiar with signaling > and filtering them and this would avoid the need for vendors to write > code for the special propagation scope of the proposed extcomm. > > > I further believe this draft might be misguided as a whole, but I > imagine the authors, being IXPs, may have their members to answer to; > and are perhaps trying to create transition tools to satisfy everyone. > My colleague reminded me that you must actively mess yourself up to > cause your IP address space to fail RPKI validation. > > Perhaps it is unwise for IXP route-servers to propagate invalid routes. > From nobody Wed Feb 14 14:40:05 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03B11201FA; Wed, 14 Feb 2018 14:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 B-xccE6fggHP; Wed, 14 Feb 2018 14:40:01 -0800 (PST) Received: from deliverix-glo-01.ams-ix.net (deliverix-glo-01.ams-ix.net [185.55.136.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDA81271FD; Wed, 14 Feb 2018 14:39:54 -0800 (PST) Received: from [192.168.1.67] (178-84-101-197.dynamic.upc.nl [178.84.101.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alam394) by deliverix-glo-01.ams-ix.net (Postfix) with ESMTPSA id 4352F204FE; Wed, 14 Feb 2018 23:39:52 +0100 (CET) Message-ID: <5A84BAB6.8020406@ams-ix.net> Date: Wed, 14 Feb 2018 23:39:50 +0100 From: Aris Lambrianidis User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: Job Snijders CC: sidrops@ietf.org, draft-ietf-sidrops-validating-bgp-speaker@ietf.org References: <151751097300.24475.14917315480902104354@ietfa.amsl.com> <5A7B4764.8070308@ams-ix.net> <20180207190442.GS5974@vurt.meerval.net> In-Reply-To: <20180207190442.GS5974@vurt.meerval.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/alternative; boundary="------------090208040902060201060801" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:40:04 -0000 This is a multi-part message in MIME format. --------------090208040902060201060801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Job, Job Snijders wrote: > Hi, > > I think a much safer mode of operation for BGP speakers is to reject > invalid announcements, rather than "tag with extended bgp community & > propagate". If RPKI adoption and know-how was widespread, I would agree. Sadly, this is not the operational reality as I see it. The draft tries to be inclusive in its options as to promote RPKI adoption, but as stated in a previous email of mine, this is just one of its goals. >From a standardization standpoint (the other goal), offering less options on how operators deploy the validating bgp speaker means less probability of widespread adoption, thereby defeating its purpose. Furthermore, if we were to go directly with the safer mode of operation, we would lose operators who are on the fence about RPKI and its usefulness and who want to maintain more granular control on what they receive before pulling the proverbial killswitch, taking into account what was mentioned in the first paragraph. If it helps, I see the draft as an analogy to the migration steps taken with any new technology, i.e. installing firewalls or proxies in one's network. Typically they are first being placed in "bypass/monitoring" mode, and then they are configured to filter/drop traffic, after confidence of their operation has been gained. The draft in no way prohibits, and arguably even encourages, operators to offer different options for different customers. Customers who feel confident in the validating BGP speaker can simply select to reject invalid announcements. Kind regards, Aris --------------090208040902060201060801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Job,

Job Snijders wrote:
Hi,

I think a much safer mode of operation for BGP speakers is to reject
invalid announcements, rather than "tag with extended bgp community &
propagate".
If RPKI adoption and know-how was widespread, I would agree. Sadly, this is not the
operational reality as I see it. The draft tries to be inclusive in its options as to
promote RPKI adoption, but as stated in a previous email of mine, this is just one of its goals.

>From a standardization standpoint (the other goal), offering less options on how operators deploy the
validating bgp speaker means less probability of widespread adoption, thereby
defeating its purpose.

Furthermore, if we were to go directly with the safer mode of operation,
we would lose operators who are on the fence about RPKI and its usefulness and
who want to maintain more granular control on what they receive before pulling the proverbial
killswitch, taking into account what was mentioned in the first paragraph.

If it helps, I see the draft as an analogy to the migration steps taken with any new technology, i.e. installing
firewalls or proxies in one's network. Typically they are first being placed in "bypass/monitoring"
mode, and then they are configured to filter/drop traffic, after confidence of their operation has been gained.

The draft in no way prohibits, and arguably even encourages, operators to offer different options for different customers.
Customers who feel confident in the validating BGP speaker can simply select to reject invalid announcements.

Kind regards,
Aris
 --------------090208040902060201060801-- From nobody Wed Feb 14 16:41:41 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488B01270AC for ; Wed, 14 Feb 2018 16:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 F2mH2A8LI3_U for ; Wed, 14 Feb 2018 16:39:49 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D65126CF9 for ; Wed, 14 Feb 2018 16:39:49 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 0695B1CAE4A for ; Wed, 14 Feb 2018 16:39:18 -0800 (PST) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by c8a.amsl.com (Postfix) with ESMTPSA id D8DE51CAE48 for ; Wed, 14 Feb 2018 16:39:17 -0800 (PST) Received: by mail-io0-f169.google.com with SMTP id k80so15750251ioe.13 for ; Wed, 14 Feb 2018 16:39:49 -0800 (PST) X-Gm-Message-State: APf1xPA5an2g7+cGt6XEGmJBzNZMc3thTY98PZLwwxAeFWBfX5ursdEN hmFzQzikRmKj6VAS+81uWwqwbooLvM6GGx9taFs= X-Google-Smtp-Source: AH8x224s0VK7lgxxtLhJkyDBz4V+cUoBt7djrZhIdgWwEkYPnjLnUi40jTjRDucGTx6XqicEb4IvoYPSMhqBTKZNi6w= X-Received: by 10.107.35.84 with SMTP id j81mr1378683ioj.226.1518655189040; Wed, 14 Feb 2018 16:39:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.1.68 with HTTP; Wed, 14 Feb 2018 16:39:28 -0800 (PST) From: Glen Date: Wed, 14 Feb 2018 16:39:28 -0800 X-Gmail-Original-Message-ID: Message-ID: To: sidrops@ietf.org Content-Type: multipart/alternative; boundary="001a1141ba4614459505653577e2" Archived-At: X-Mailman-Approved-At: Wed, 14 Feb 2018 16:41:40 -0800 Subject: [Sidrops] Possible missed messages on this list X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 00:39:51 -0000 --001a1141ba4614459505653577e2 Content-Type: text/plain; charset="UTF-8" Possible missed messages on this list Dear list participants - An upgrade to the IETF's custom mail processing software today resulted in some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours. We invite you to check the mail archives for this list, at: https://mailarchive.ietf.org/arch/search/?email_list=sidrops to ensure that you have received all the relevant messages for this list today. We apologize for the inconvenience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --001a1141ba4614459505653577e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a1141ba4614459505653577e2-- From nobody Thu Feb 15 05:39:38 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAE712DA04 for ; Thu, 15 Feb 2018 05:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 6gFOavPwQtbg for ; Thu, 15 Feb 2018 05:39:35 -0800 (PST) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 78BC912DA09 for ; Thu, 15 Feb 2018 05:39:35 -0800 (PST) Received: by mail-wm0-f50.google.com with SMTP id j21so1213586wmh.1 for ; Thu, 15 Feb 2018 05:39:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yUeLVwHUVz9Kkd3IzuB0s4D8iuHTM+7paISd4IQ8oRU=; b=K/dILUClSJLlF75V4zxhh1DORxn1SNxIlrbV7H9y3IkiN8eDOEEyOSzGnuyPWxgYVN tjmabMw4T4/u9EaZ5aZnq7a7K/qOMmGNiNRHVhW3EhZG1Yh6UGgRRMx3MI1noY/TL5So IvC/DjIYl49/E834teVXk1Em3fQYTmGOeyiwf+GdfojyOx6tZ5dDN+ZzNUXPHcQWJDhK nkdx2x2L3xCg3BvutcIKjPEi5IoPrlorw6uWEHkaq99BPktCE5s+qyonCKKtph7tQUJz 8Wqamhv763j4XU/AK87qYBs9u2hOAg0A0zkraP4NPwIU87HpN0PDZLtrsLdlrIYSTnrA ZuVg== X-Gm-Message-State: APf1xPB58KVYXTs2o5fuIGX0Jxo+d15uBFv7yoWY2Pi8HuH8XroecUXT U4vvviSMa3x3V9R/DAAbiKX3gDQvbmI= X-Google-Smtp-Source: AH8x227Yr3c6dLl7XHcXZszWpkFq+DOi9La1bAuujJkz0tFdY3ATUJBf5CkApwYjaKjguHr1VR7VIQ== X-Received: by 10.80.153.143 with SMTP id m15mr3352317edb.145.1518701973775; Thu, 15 Feb 2018 05:39:33 -0800 (PST) Received: from localhost ([2001:67c:208c:10:2cf2:185e:db44:f1cb]) by smtp.gmail.com with ESMTPSA id p55sm7604112edc.15.2018.02.15.05.39.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 05:39:32 -0800 (PST) Date: Thu, 15 Feb 2018 14:39:31 +0100 From: Job Snijders To: Aris Lambrianidis Cc: Jeff Wheeler , sidrops@ietf.org Message-ID: <20180215133931.GB1193@hanna.meerval.net> References: <5A84B6B8.50207@ams-ix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A84B6B8.50207@ams-ix.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:39:37 -0000 On Wed, Feb 14, 2018 at 11:22:48PM +0100, Aris Lambrianidis wrote: > Let me also point out that in theory, forwarding "invalid" prefixes is > bad. However, our own operational experience so far has shown that > most ROA invalid prefixes are due to misconfiguration rather than > malicious intent. A major consideration is that all IXP route servers only offer a _partial_ view on the global routing table, nobody ever single-homes behind an IXP route server. So, if the IXP route server does _not_ propagate invalid prefixes to its participants, operationally speaking the 'worst' thing that can happen is that alternative paths are used via either bilateral peering or other arrangements. If anything, if people depend on keeping their traffic on the IX with the help of the RS, there is an actual monetary incentive to repair the misconfigured ROAs. If anything, IXPs should take a leading role in deploying RPKI Origin Validation - this draft proposes the opposite: a watering down that justifies propagation of bad announcements. By merely tagging the invalid prefixes with a community, the sender of those BGP announcements has significantly visiblity into problem, since the sender of such announcements won't see the 'invalid community' themselves. I think in context of IXP Route Servers it is very detrimental to the Internet community's overall effort to improve routing security if invalid malicious announcements are distributed alongside these 'misconfigurations', and the propagation of misconfigurations is deemed more important than blocking of incorrect announcements. Given the prevalence of routing incidents and the critical effects they have on business continuity, I'm concerned that time is wasted on actively lowering the bar ('rpki-light' aka 'draft-ietf-sidrops-validating-bgp-speaker') rather than spending time on setting higher standards. ESPECIALLY given the position of route servers in the routing ecosystem. If we consider a misconfigured RPKI ROA an 'error', favoring strict error handling (dropping) over attempting error recovery is an effective technique for ensuring that faults receive attention. Kind regards, Job From nobody Thu Feb 15 05:44:26 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6C712DA08 for ; Thu, 15 Feb 2018 05:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 LZwXCjo5oyO5 for ; Thu, 15 Feb 2018 05:44:23 -0800 (PST) Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) (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 1315712420B for ; Thu, 15 Feb 2018 05:44:22 -0800 (PST) Received: by mail-wm0-f47.google.com with SMTP id j199so925938wmj.2 for ; Thu, 15 Feb 2018 05:44:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=96ctgLYQ17bkoA7C1NjQPf8veEDijN0hf6UPoPLBO6I=; b=acN+hKsAYKnEbZDja7zg3Zk3zrklmKdWKU0OaZ58/tbkXGNLJJwdFFxcrPZ4E17fVR euwhMCRfPxiWMd0S70s7mZRctQKliIu03jRr5o6CpSOEJFkxLJx3gYqT1OSBLZRwLbSf HZTjFwT3CHe3kU2R5uzFPDh25ybmQ0JIuygFY5yrBTcaznP+dtda8yyjnGWBfeYvm2yA F0MvYJ96fJQ4VfNB/QFtSV983Gb+nCLLOsHQ5hFaKf8dMo4xtOc97y+2ucyTo9IG6ZG9 liOzRQjmMyj+ztF8/LhXf7XmcevFc55uZcHk2dC2YNf/rphujPDlOm0ADZvIgdr8BZaD YdDw== X-Gm-Message-State: APf1xPB9e9S31fCZ0C1nim1tUHaIchCOsAB43glYyyhTl1XrhRviOjVF sT7b0srqBrqjujn6DTb3q7rpLQ== X-Google-Smtp-Source: AH8x2242yL/z5v7/g469XuPJvofumx/DN5/uZnR6jxhJOLhJ2sIaqsqqs0NxprczwQTFKzM44TSWCg== X-Received: by 10.80.151.106 with SMTP id d39mr3428547edb.79.1518702261235; Thu, 15 Feb 2018 05:44:21 -0800 (PST) Received: from localhost ([2001:67c:208c:10:2cf2:185e:db44:f1cb]) by smtp.gmail.com with ESMTPSA id l5sm518255eda.82.2018.02.15.05.44.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 05:44:20 -0800 (PST) Date: Thu, 15 Feb 2018 14:44:18 +0100 From: Job Snijders To: Aris Lambrianidis Cc: Jeff Wheeler , sidrops@ietf.org Message-ID: <20180215134418.GC1193@hanna.meerval.net> References: <5A84B6B8.50207@ams-ix.net> <20180215133931.GB1193@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180215133931.GB1193@hanna.meerval.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:44:25 -0000 On Thu, Feb 15, 2018 at 02:39:31PM +0100, Job Snijders wrote: > On Wed, Feb 14, 2018 at 11:22:48PM +0100, Aris Lambrianidis wrote: > > Let me also point out that in theory, forwarding "invalid" prefixes is > > bad. However, our own operational experience so far has shown that > > most ROA invalid prefixes are due to misconfiguration rather than > > malicious intent. > > A major consideration is that all IXP route servers only offer a > _partial_ view on the global routing table, nobody ever single-homes > behind an IXP route server. So, if the IXP route server does _not_ > propagate invalid prefixes to its participants, operationally speaking > the 'worst' thing that can happen is that alternative paths are used via > either bilateral peering or other arrangements. If anything, if people > depend on keeping their traffic on the IX with the help of the RS, there > is an actual monetary incentive to repair the misconfigured ROAs. If > anything, IXPs should take a leading role in deploying RPKI Origin > Validation - this draft proposes the opposite: a watering down that > justifies propagation of bad announcements. > > By merely tagging the invalid prefixes with a community, the sender of > those BGP announcements has significantly visiblity into problem, since > the sender of such announcements won't see the 'invalid community' > themselves. Oops, some words were missing from the above paragraph: By merely tagging the invalid prefixes with a community, the sender of those BGP announcements has significantly less visiblity into the problem, since the sender of such announcements won't see the 'invalid community' themselves. > I think in context of IXP Route Servers it is very detrimental to the > Internet community's overall effort to improve routing security if > invalid malicious announcements are distributed alongside these > 'misconfigurations', and the propagation of misconfigurations is deemed > more important than blocking of incorrect announcements. > > Given the prevalence of routing incidents and the critical effects they > have on business continuity, I'm concerned that time is wasted on > actively lowering the bar ('rpki-light' aka 'draft-ietf-sidrops-validating-bgp-speaker') > rather than spending time on setting higher standards. > > ESPECIALLY given the position of route servers in the routing ecosystem. > If we consider a misconfigured RPKI ROA an 'error', favoring strict > error handling (dropping) over attempting error recovery is an effective > technique for ensuring that faults receive attention. > > Kind regards, > > Job From nobody Thu Feb 15 09:37:48 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D835812D0C3 for ; Thu, 15 Feb 2018 09:37:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inconcepts-biz.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 YB5E4pIhQ8kt for ; Thu, 15 Feb 2018 09:37:43 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 C36D11289B0 for ; Thu, 15 Feb 2018 09:37:43 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id a17so175364uak.13 for ; Thu, 15 Feb 2018 09:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inconcepts-biz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vx14UPTcI0QNKDKjl1tMEga4IIllxzZDFuufpVpgtlY=; b=WHIvNOexrLmCaGgJA5AkVdL2LcvwedGL3NpCokk/iOv6KW1UiX2tMPZsVFLxZKvMDc UdOvvn/1y71f8JDtuncl8xw2c5bj9TEW84S1C+YOMrJQHhQNqlnb9g8zX3ea2lC82/Ji XMcWacAyfzmuOQaKRY10bqo/DRS8HHhifpNYqV7dJBneJm2BbXtpuDLG17fWAur67yBP wXzhrQ3XMKNy3ozqnIakASh46gqorSD6QRPzAo9d0WGJ5fq6TjlHi6TlIwNXIdTSySiS fKtcWWWFn5oFsW3AM6kiHNf0gY97N8U2Dp3zhgW9hpvnzHbRdJLgjBIPMPyBCcdWtlot Xz7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vx14UPTcI0QNKDKjl1tMEga4IIllxzZDFuufpVpgtlY=; b=iDXaa1RX1EgI/9KuBVNPcRRGVZCToHfuaNzLvKVHXxgM9E3Q46WrvrjGL26Lzb5GR4 4HPXc62kKURGE4MS7u3VWQg4VOBPSBXEzoaD5gPwgt2G2OnpmOxpsQE0rMutk0XA7yO2 mCjALaPmW+ZCPSnuzSucF/TrDnKoMmkd5/KwUjqK7NlpoEt1Gt2k9sbXiK3H6AeqAf1a ciHABvwcdTdcrht5Yqf/dA6wC5wVmYiODg/bd5Ujxm8o9qTdYMHd7XRGzbdvQtUqbdCF SCpgKGAnyEBga5rJYY96lfPqOJ89RKkP3VZCTEY8CMYqAuxJy1/5ViWjIMEvzqjCKj+F WyPA== X-Gm-Message-State: APf1xPD6IGQ3cmn4U72h6MRzGtGj36/vrUarFMFstE6BZSAJon5pMHpM PGTzWdHYIig0yFFDrhHl1krvoiRICywaz6HJ96/Fuipo X-Google-Smtp-Source: AH8x226i7rDZhmhAOrxwxiciDaosQDk7aFuk5ReXhd+z/TWS/BYcHB0C5gPCT0EP5qE1xOB6bz2+fNgjhH39QwcO8t8= X-Received: by 10.176.1.194 with SMTP id 60mr2680657ual.135.1518716262835; Thu, 15 Feb 2018 09:37:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.33.68 with HTTP; Thu, 15 Feb 2018 09:37:42 -0800 (PST) X-Originating-IP: [74.130.6.149] In-Reply-To: <5A84B6B8.50207@ams-ix.net> References: <5A84B6B8.50207@ams-ix.net> From: Jeff Wheeler Date: Thu, 15 Feb 2018 12:37:42 -0500 Message-ID: To: Aris Lambrianidis Cc: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 17:37:46 -0000 On Wed, Feb 14, 2018 at 5:22 PM, Aris Lambrianidis wrote: > I see two prongs in your email, a technical one (signalling method) and > a "political" one (for > lack of a better term), i.e. whether this draft is misguided in principle. I think your draft has a fair chance of progressing because it's clear some IXPs (and their members) want route-servers to propagate invalid paths, and if they are going to keep doing that, it is easy to understand why the IXPs feel obligated to signal it somehow. Once you decided to signal it, a standard is sensible. Basically, I see you are cutting your own hand. I think that's stupid but I support your plan to standardize the type of knife you use. You're going to spill blood anyway; your members must be demanding it. For the above reason, I would rather focus on the implementation details. I'd like to reiterate that the new propagation scope defined by your draft is a change to the existing, standardized behavior of BGP Extended Communities. The nature of this change almost dictates that you also specify a BGP Capability Code and define a behavior for what you should do when receiving one of these extcomm from a neighbor that has not signaled the capability (probably drop the extcomm since its origin is unknown at that point?) So now you have a new parameter in the connection process (no big deal) and new code when parsing and propagating extcomms. In fact, you might as well define some kind of router-hops-limit and as-hops-limit for extcomms because the implementation cost (in software) of that is essentially the same as what you've already proposed and the new kind of scope would have other uses to operators. So the current draft is more complex than it really needs to be. A lot of implementation obstacles can be removed by simply using a BGP Well-Known Community. If operators want to use your idea they will need to configure their router, but they would not need to wait on their vendor for new software. On your side, you are already using a community to signal so this clearly works fine. I understand the long-term advantage hoped for by limiting the propagation scope, but I think it is a more ambitious and costly plan than the authors realize. I ask them to back off from the extcomm, or in the alternative, approach it as a new propagation behavior to extcomms which can then be re-used. -- Jeff S Wheeler From nobody Thu Feb 15 14:48:50 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9412D96C for ; Thu, 15 Feb 2018 14:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27hvr3l0RjZm for ; Thu, 15 Feb 2018 14:48:47 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70DA127871 for ; Thu, 15 Feb 2018 14:48:46 -0800 (PST) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w1FMmfF6063509 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2018 22:48:42 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <5A860E47.1010003@foobar.org> Date: Thu, 15 Feb 2018 22:48:39 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.22 (Macintosh/20171208) MIME-Version: 1.0 To: Aris Lambrianidis CC: Jeff Wheeler , sidrops@ietf.org References: <5A84B6B8.50207@ams-ix.net> In-Reply-To: <5A84B6B8.50207@ams-ix.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 22:48:50 -0000 Aris Lambrianidis wrote: > I see two prongs in your email, a technical one (signalling method) and > a "political" one (for > lack of a better term), i.e. whether this draft is misguided in principle. >From the bigger picture point of view, this draft is about trying to make rpki accessible to operators, and builds on ideas first presented in draft-ietf-sidr-origin-validation-signaling / RFC8097, which applies to iBGP-only routing environments. Stepping back a bit and looking at this problem, on almost every bgp routing platform, rpki policy hooks have been implemented in a way which makes deployment of rpki quite straightforward. These hooks rarely constitute more than a couple of lines for cache configuration, and simple grammatical constructions for rpki policy matching. In other words, the router side of things is pretty easy. The single item which makes rpki deployment troublesome is operating an rpki cache or set of caches. If you want to deploy RPKI validation caches, there are several options available: some of the RIRs already provide a hosted rpki validator service, and RIPE NCC provides open source software with a GUI. rpki-validator v2 is available now, and v3 is in the works with a planned release date some time this month. I.e. this is software which is used already in operational environments, and which is under full development support. This means that the bar for pushing out a full rpki deployment using actual caches is not very high in practice. In the one case, all you need is to create an online account and the whole lot is done for you, albeit using an infrastructure which you probably wouldn't want to use as a long term arrangement due to the fragility of depending on off-net infrastructure (conversely noting that the rpki cache validation mechanism is designed to be tolerant of situations where the cache is unavailable). In the other case, you need a VM or a deployment of VMs and an amount of time and patience which is going to end up being directly proportional to the scale of the deployment that you want to build out. Neither option involves rocket science, but both will provide real RPKI, bells and whistles attached. draft-ietf-sidrops-validating-bgp-speaker proposes to replace actual RPKI with a synthetic flagging mechanism. What's lost here is: cryptographic authenticity, all the rpki validation policy hooks on routers, and because this draft addresses ebgp rather than ibgp, we have the extra complication that any upstream processing which involves multiple bgp paths will also involve bgp best path selection, i.e. the upstream is necessarily getting into the business of making implicit routing decisions for the downstream without providing any of the hooks that the downstream bgp speaker might want to use. In one sense, this draft is not even about making rpki more accessible: it's about how to translate a subset of rpki features into existing policy methodologies, so that the operator doesn't need to use an rpki cache. The proposals in draft-ietf-sidrops-validating-bgp-speaker need to be broken out into two separate sub-cases of multilateral ebgp (i.e. route servers), and bilateral ebgp (i.e. normal bgp interconnection). For all ebgp implementations, the moment you examine a community that comes in over ebgp, you're implicitly trusting your peer to sanitise that community for you. In other words, because there is no cryptographic authentication of the rpki state of the prefix, you're depending on something which is no more or less reliable than hearsay and which can be easily faked by tacking on an illegitimate community and depending on misconfigured routers to forward the attribute. Route servers present a particular complication because they are a 90% solution to the problem of how to interconnect with lots of other organisations at an ixp, with all the massive simplifications that a 90% solution implies. The conceptual difficulty with route servers is that unless they provide add-path tx support (i.e. forward all prefixes to rsclients so that the clients can make their own decisions about what to do), they will perform bgp best path selection on behalf of their clients, i.e. forward a single prefix, losing information in the process. Job suggests that RPKI invalids should be dropped. There might be sound reasons to hold this opinion, but someone else might demand that RPKI invalids be depreffed instead. This outlines a fundamental difficulty: without add-path tx support, the route server is touching the RPKI problem and making explicit policy decisions on the basis of RPKI validation results. The problem with this is that rpki is subtle enough that if you're going to want to deploy rpki at all, you probably want enough policy manipulation hooks to get it to do what you want, not what someone else decides for you. These hooks would ideally need to specify what to do with invalids, and unknowns and how to apply various different attributes to them (e.g. tag, change localpref, change metric, drop, keep, etc). This sort of policy management needs to be handled from the route server provisioning system, ideally dynamically so that client operators don't need to prod the route server operator to make updates whenever they want their policy changed. If this is not present, then the route server is cooking up a bunch of results based on a stated / implicit policy, but where the rsclient has no means of inspecting all possible paths to make their own decision about what to do with them. As a further complication, the community mechanism proposed in this draft requires code changes on the rsclient to make it work at all. This is because generic extcomm support on routers doesn't usually exist. This can't really be fixed by moving to bilateral peering because if you move to bilateral, you're going to lose the community support proposed by this draft, i.e. your peer at the IXP or on PNI probably isn't going to support this draft. This means that if you want RPKI, you're back to square one: you will need to set up your own cache anyway. The comments in this email https://www.ietf.org/mail-archive/web/sidrops/current/msg00035.html (text search term "tl;dr: route servers and rpki are an uncomfortable fit", date Sat, 14 Jan 2017) are still relevant. In summary, this draft provides a partial workaround for operators who don't want to go to the effort of installing and configuring off-the-shelf RPKI validator software, using a mechanism which will provide arguably incorrect policy decisions in real world situations using systems which they have no control over, which requires code changes on client implementations, which doesn't provide a hook mechanism to allow the operator to use their router's RPKI grammar, and which in the best deployment scenario is only ever going to be possible on a limited set of bgp peering sessions. I can't reconcile this with either good quality protocol definition or sound networking operational procedures. Regarding the argument that this already exists and that standardisation is better than everyone doing their own thing: > Signalling ROA status in route servers is already happening (France IX, > AMS-IX), for better or worse. > The question then now becomes, does the community want to consolidate > into one way of doing things or not. Standardising different implementations of a bad idea doesn't make it a better idea. If some IXPs are tagging prefixes on their route server with rpki assessment information, then that's a decision for them to make. I'm sorry if this assessment comes across as being harsh, but given the limitations of what's being proposed, it would probably be more constructive to use the time and effort that would otherwise be spent working on this draft to educate operators about how relatively easy it is to implement native rpki, and that if operators are serious about rpki on route servers, then they will need either add path tx on the route server or else use bilateral peering. Nick From nobody Fri Feb 16 09:49:29 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2C9124C27; Fri, 16 Feb 2018 09:49:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 54UDis_L6WYt; Fri, 16 Feb 2018 09:49:24 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0090.outbound.protection.outlook.com [23.103.201.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8EC1200C1; Fri, 16 Feb 2018 09:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w8jvDta+branxVUBjWUyFjNama1n13fJfV297u5T+Tc=; b=z4u59813XU++3mQC2DrUIGR3bAJoAngMGGQf+xC4kssC8Zn3I2ca/p2OVG1N6QktL4xQBNNPa0sNiNbiuT7OB6pk1fi0QrEkkMMb4HskQC9Wub4MzCCXPl/pV73eVnQXtPxtxEPI/4pCCBOMEMH2lKPeaGddZQ7kqmwQsjQf/b0= Received: from DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) by DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 17:49:22 +0000 Received: from DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::20ef:6e1f:e58b:5d0a]) by DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::20ef:6e1f:e58b:5d0a%16]) with mapi id 15.20.0485.022; Fri, 16 Feb 2018 17:49:22 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "sidrops@ietf.org" CC: "sidrops-chairs@ietf.org" Thread-Topic: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis Thread-Index: AdOnTjS8nNGpSDWmTk+nTSZUMuvv5A== Date: Fri, 16 Feb 2018 17:49:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0559; 7:dzNZZUGQSKPQg/RLQCHTmfra58sGjw8cJynXksQRZHXAoMGIYJ8YoVR1WjEa28Og+tmfF8XiEhB9dtQthZMxCNQadO3zkOXtW/4Pabj+40XELI0hVYtU2slGPHOHvYxWHAPI6Hr2Pl2T1by6FRaZ4IDwxWrsYWqzR8+O5GUD4cSCDL0hIJAP7GIkHdQUZRzu0z9rMwXVbqcM1Aswbru7DdaqwAaQPSvbvBm85RLtmyhg/owPjobhBFbXsNAp4MVo x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fca44d01-f7e5-4f02-67b9-08d575659c90 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM2PR09MB0559; x-ms-traffictypediagnostic: DM2PR09MB0559: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM2PR09MB0559; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0559; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(39380400002)(396003)(199004)(189003)(1730700003)(99286004)(3660700001)(8676002)(7696005)(106356001)(3280700002)(2351001)(74316002)(6916009)(81156014)(966005)(14454004)(68736007)(81166006)(478600001)(5660300001)(5630700001)(790700001)(6116002)(7736002)(2906002)(86362001)(450100002)(4326008)(2900100001)(97736004)(3846002)(2501003)(25786009)(53936002)(186003)(55016002)(26005)(6246003)(236005)(9686003)(6306002)(54896002)(8936002)(5250100002)(105586002)(5640700003)(6506007)(316002)(6436002)(229853002)(66066001)(606006)(33656002)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0559; H:DM2PR09MB0559.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: e7m3s04NTFcT9LPmnVz3whsGkz0mRsWarzg/aDD70PeHiChyX5d3MljOXEIk0SU2gAvVAxFbxSgrgEr9WNADGA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB055959D4F18C02A41635443584CB0DM2PR09MB0559namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: fca44d01-f7e5-4f02-67b9-08d575659c90 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 17:49:22.0868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0559 Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:49:27 -0000 --_000_DM2PR09MB055959D4F18C02A41635443584CB0DM2PR09MB0559namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I've read the draft and support adoption . Sriram >I've read through the draft, believe it to be useful for BGPsec >development and support it for being added as a work item. > >-Mike > >> Christopher Morrow Tue, 30 January 20= 18 >> 18:38 UTCShow header > >> Howdy WG folks, > >> Oliver has done some work to further his presented material from Singapo= re: >> "Extending RFC82088 by adding Experimental/Documentation algorithm IDs= " > >> This is reflected in the subject draft/-bis for RFC8208. Can we please t= ake >> 2 weeks (ending: 02/13/2018 - Feb 13, 2018) to read/review/comment and >> consider if this document should be adopted by the sidrops working-group= as >> a work item? > >> Draft: > >> https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-algs-rfc8208-b= is-00 > >> thanks! >> -chris >> sidrops-chair-02 > --_000_DM2PR09MB055959D4F18C02A41635443584CB0DM2PR09MB0559namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

I’ve read the draft and support adoption .

 

Sriram

 

>I've read through the draft, believe it to be useful for BGPsec

>development and support it for being added as a work item.

> 

>-Mike

> 

>>  Christopher Morrow <christopher.morrow at gmail.com= > Tue, 30 January 2018

>>  18:38 UTCShow header

> 

>> Howdy WG folks,

> 

>> Oliver has done some work to further his presented material = from Singapore:

>>   "Extending RFC82088 by adding Experimental/= Documentation algorithm IDs"

> 

>> This is reflected in the subject draft/-bis for RFC8208. Can= we please take

>> 2 weeks (ending: 02/13/2018 - Feb 13, 2018) to read/review/c= omment and

>> consider if this document should be adopted by the sidrops w= orking-group as

>> a work item?

> 

>> Draft:

> 

>> https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-algs-rfc8208-bis-= 00

> 

>> thanks!

>> -chris

>> sidrops-chair-02

> <= /p>

 

--_000_DM2PR09MB055959D4F18C02A41635443584CB0DM2PR09MB0559namp_-- From nobody Sun Feb 18 15:01:54 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F9126FDC for ; Sun, 18 Feb 2018 15:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.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 Qmx1tYTi_ssf for ; Sun, 18 Feb 2018 15:01:49 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0063.outbound.protection.outlook.com [104.47.124.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1060120227 for ; Sun, 18 Feb 2018 15:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+rSPOXLKV9tFXwEABcdLwZnV7p/wPWekOsMzCU21XAQ=; b=bNUOr76YyllsnCry+ijIxhH1Ps/Q6So0o9MRA4fAUm40jKyALwS+hOI7eZeEGssCtZNax+/sDSG1t86SdLW09PJCG8ZV3eaUXaGjz5OH2wfc0iD19GWYInY1FN9M3ClLCr3QIO5yrwiih/UVPi3N7FY2wD0RWVSHJGGGwX3uQSI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=tomh@apnic.net; Received: from tomh-laptop (203.119.0.128) by HK2PR04MB0754.apcprd04.prod.outlook.com (2a01:111:e400:5891::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Sun, 18 Feb 2018 23:01:46 +0000 Received: from tomh by tomh-laptop with local (Exim 4.89) (envelope-from ) id 1enXxd-0005Uc-Kd; Mon, 19 Feb 2018 09:01:33 +1000 Date: Mon, 19 Feb 2018 09:01:33 +1000 From: Tom Harrison To: Tim Bruijnzeels Cc: sidrops@ietf.org Message-ID: <20180218230133.GG5488@tomh-laptop> Mail-Followup-To: Tim Bruijnzeels , sidrops@ietf.org References: <151064401825.5985.7789265592065530099@ietfa.amsl.com> <20171116103441.GB7247@tomh-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Originating-IP: [203.119.0.128] X-ClientProxiedBy: ME2PR01CA0005.ausprd01.prod.outlook.com (2603:10c6:201:15::17) To HK2PR04MB0754.apcprd04.prod.outlook.com (2a01:111:e400:5891::20) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b25322d2-8636-4168-2a8a-08d5772395b6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HK2PR04MB0754; X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0754; 3:qC/0pH+NR/fQmLYbIJPbGiBTouyojOhuE2D8Yto8Y8ShRAUWCkKRT/XIIs8uqVgkhNKappHo9JdSWVOMhyXSe2B2UZoIMWirfHvb1Hn33JxrFu2tNOGodOVLi7tLwWkZ72Ym395xzu0GCfOvDqfHZtu//ICww4jSEDcf3YjkBoQdjmyDRRo6FNJkzZT+JC50OWEox+K8hwKPT5hl53FE2aLAo64c1fUXEW6T8N5zc4fcK60jELVraWAfNcywCCfT; 25:28T4T56vfdh2J7UQBUpMwZSdwPKd/NVeKbKpGsjgjAWK01FLD1JWX81KxyFmMUIk6vVKW0xkDp/Rnz2HLuFQhOQ0lEyo7A4l6teWMw+0E99gMsFdj+jsG/q5DYSRv1XbSKQUTGt59WYCc4DQ1NxznyurdLsyDaHSEqDTL0W1v2B+nFrbZ+0Ers5AcXkHHbjRsrsepNfnIQyhnciPxEhKiDEIpzm9os8G4ltxWrF63rXyvvvlNTiR5lYoTTrS92wlH4FqB4jsoq3tBHZ6/l9IUPq+Vio5Y2VZR+ilROoU85PY4uDucWaOVpfLQUcteRe2tRhJTtNgkfA2Q198OoikdQ6mNItjXJ0De9N3vYDnSfk=; 31:Yl31yPMH6ysndj/r5v0XgNaV9ePsRcFMROlYRNId+7i84Y2JEelGJkmCxNqJfoAH5FuO8e7RDppTZiReiQKGjdagHaV5y7fdSCec+HjnT/HXRS6V341CTLDl35qn7aNaO1GzOiPYwTf+jNs1sm6wmehEoA/ThyRMAeKuyeBrEkbo5ln4vgr6jLfY2RQLpv5hWmY6nb6o8cIlFApDszmK0dFJCT4B9Z1c6OEhCrz3JpQ= X-MS-TrafficTypeDiagnostic: HK2PR04MB0754: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(944501161)(6041288)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:HK2PR04MB0754; BCL:0; PCL:0; RULEID:; SRVR:HK2PR04MB0754; X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0754; 4:khxr3Xd/ZMU+d8k8khkWBTg4FGJrM8Ru53Fg74csX5TAYcVTwrYQoRAWYrsHW8yDVcuzD6bDtsv0WqU8lNGDgAx95ILoNIo0cEFQfZDONKwqnuD/hSZ5QDfFhtYDkKhWV3YMqouIBFsZrR3jK7tx3b02ArHcDnE8K+TH5x1w9WMAS9Dx3sPBkhtsVXB9uNXUAXR5th0QcxVgDx/F6lc0DNvrQHG2Ly4fhrP/1q9C9D8te0yvMn5i2gg+VAm4Ldyvjj9x2MjgXcc6vVRWE2nRPw== X-Forefront-PRVS: 058707456E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7916004)(39830400003)(39380400002)(396003)(366004)(346002)(376002)(189003)(199004)(51444003)(9786002)(33716001)(86362001)(83506002)(8676002)(81156014)(81166006)(8936002)(50466002)(97736004)(2906002)(2870700001)(1076002)(3846002)(122856001)(83796002)(6116002)(4326008)(23676004)(33656002)(105586002)(106356001)(57986006)(58126008)(52146003)(52116002)(2486003)(316002)(386003)(59450400001)(229853002)(76176011)(33896004)(9746002)(68736007)(26005)(2950100002)(6916009)(53936002)(186003)(9686003)(6306002)(7736002)(305945005)(6246003)(5660300001)(66066001)(46656002)(47776003)(478600001)(18370500001)(107986001); DIR:OUT; SFP:1101; SCL:1; SRVR:HK2PR04MB0754; H:tomh-laptop; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtISzJQUjA0TUIwNzU0OzIzOndELzc2ODNrYVR2d2g4c2hzZ0RMcjdnRERx?= =?utf-8?B?N2xXbllBd0FNRHVCbm5NUzlETlQ1bTVLY1R3Q1dUdFU4MVArYk8rNlZwY0o2?= =?utf-8?B?Q1plSUdHdHVuQTArWFRuUzBpQXNuWXVyY2pWQVhmd3RnM3RWOHVBaFh6cXkr?= =?utf-8?B?cnBYSWlhTmJtM2xyZmpJTFdhT09GaWMrZCswZFd3R1A4ZGJpRm9oUnViYjc5?= =?utf-8?B?bDk0dytNT3Z4K1JrVjhxU29PYVlUVHpzY09Vdm1LanBvWHJGaGpaaWRGQmY2?= =?utf-8?B?dDFGa0tsVk5uRm1kT3pZUTQwS21xc3NQYkNhRENsUWR2UHNYcHdwTnVtdm5H?= =?utf-8?B?MUpHTFJaWGZ3M3VIcnhNcE0vcG4xakVJazJHZUd0RjJFK04raldoRnEyeGhm?= =?utf-8?B?Z1pxcm95UWgwbitYajUxNXhkOXZEZDJ3WU9LRnBQME15RmdNNms0MXVITDRS?= =?utf-8?B?YWFxRFovT05qSytNUWNUUUFmOTRtcUVkOUhEVkMxV0d5UmpiVlhjOE1jVi95?= =?utf-8?B?OG5tSWZHcmNlNlZDVEVSa25xY0FESGxFTHRHZnQxc2RDUVNwOGJKZzRla3lj?= =?utf-8?B?VWhlbHJPTVI4RzlGRWZTemIzNEpLbFRBTlIzUGVIMHRHVm91MDJlQ2o4R0wx?= =?utf-8?B?eDFPOVJrUy8yNDMzczNqdHVxdFNkY3gzVWJYQUlpQ2ovVnZPcEZWVFNhYk1Z?= =?utf-8?B?NVRJY0NxRXR4a2kvWTNzbEs4ZFdPNmdmMUtqOXZGWnhXRDRRU24vdkgzd3Z0?= =?utf-8?B?WUkwQit0VVZPUFE0aGVmWWhhT0ppejBZNEIwUGwzSE53RU9BVGVYcTZqUTY2?= =?utf-8?B?eTU5WWN6ZVY1aHMvaDR4YUtzbDlZZnZ0OHZnTnA0YlVTeDJremJ5VjJQSE55?= =?utf-8?B?V3NPbFkyZzE1Q2pkdGd0QVZDYUVKNkRyK2VwOUpUZFJOTzZUMDYrUzlGRXZI?= =?utf-8?B?b2F0Tkw1aDI4Yi82TDFGZnNLWi9mcytKWjducnJ5TFNmTnBpWmt0K0JYNDZ4?= =?utf-8?B?eCtpRWZHSUQrQjZRV3I3ek9rUUhBM3FUU29IWEFxQkdmMzd1S1RQZEp6cFZ3?= =?utf-8?B?V0tMRlJqZ3dydkM3ZEk3VHlUc0JING5FeFBGOUZEaVdFV0RMQ1luTFNPZU9J?= =?utf-8?B?Q1VsbC9pVXFibXI5UERMTXJUSk9MWlI2T3JZbDJqOFRSUiswVmlWcFoxMGQ0?= =?utf-8?B?Mm1UcE1tTXowMXVrZ3pTUnVtTTZaVnlWU1cxRkNta2s1Q0dScTlyMlNrTUMv?= =?utf-8?B?SEQwMzZJQ0UzanhJS3RWT3lXbWd6S0ZoR3ptSmNrZTVFdUhhbWhQMTlNWGhM?= =?utf-8?B?YTZCaUVFM1ZwUjBuNUJWU1ZWb0M0R3ZqOGd2SS9EUUt4RUFMZXZIZ3VucUE1?= =?utf-8?B?TXhON2pUcnY0eXZxdmRYajEvcEYvSVRvY1AwRFVRcEcraWxsWFFaYnpnY3F0?= =?utf-8?B?VGhxNjEzL0dMaGlncjRCSG4zcWc1ZHRGdzVPMkFxWkJMM2lNa2kzVWZsbmVY?= =?utf-8?B?UEdLZjF1VkVseWR0anA2TzRySFJXUFMzZ2M0K2ppcVorblZzS3hkMUh5MjdR?= =?utf-8?B?d2tEZnY0UUt2OFg0amVrU25qVVpkeS9lRnVIQzZ3eFZsY1luVWxQN3BlOXBX?= =?utf-8?B?NHlaWnV0ZnpVVVBHb2g0Z0FGejVBRDk3Uk91K1RKb0hvOFRwT3pCVnZyOUNN?= =?utf-8?B?SHhOVHpSaXJsbWIyZVNndkZtZGVPUmhoc0hBUUQxSE9hcTI0Vk1zSDN2Q2JE?= =?utf-8?B?OUl0RG1mem1acVIwbVFLRGtkb0xqK3Jwckc5L2hZbGExY3lFQmZXNDR5S3BL?= =?utf-8?B?ZFJjV0JjV3ZIdkJjeWZqSUFqMnlxNEkwQVJKanAzdXpyNTRtaklpUTZlajVB?= =?utf-8?Q?byB+a3sOvUz/RsVAxZzRF1eXriyyoeLB?= X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0754; 6:UncSODXUeC3XxMQtbSjlhseSYTVw/XzBZkWiz+rHpAcHdwaAR6AgJiAfBux0mm8zxBHZImWkIxsCEQHkahUiZKYYBNQs/lmvdg3fzE2KfKQCTNRbmpvkrT6ln0oyI8R4MjRw05KddhVeOzrnOSbN0VkC18KN7ECvXJK9QPMrEtvQYYTlPB93OjhaZDuDNSn9FVokItunjxWIaXtYj4iOz6hFDkVanIn3r+MK91uUtbmz3g7sNWnKZS/H8LRtBq3TCWCMsf9mjrXOCDyrRs2wZZKna6R3ltCgCBocjp9BdF/kYBmdg9FzSKoFBfvJDPAuWHtGRLJcFKk8AtSYSdyz3BfrvaVYhwYOKi/4+s3XYE0=; 5:c8adO6yKWNghyxGiy7bUVxZvhtT2yk2SLwRxPB2yDh7Kx9PKuflzs/MuqfVSyMUM6BdbsZgPzGmOfqS0Jfw73H0iglkGNblywuN2jrzpTTr3EKoYPU6rfEpkJhuAR3xHp23tt1dN//Nx4DMGiUg72FWEW/0zTdaNI+k98Ls1fNM=; 24:nFnuhR1x8wHZUVdApWmmYxusYoNGKq60LofjlvzXQtLqWOgikNnFQXc1Pm0w7LF1qRngeTlhyMalMRNgpUz5mHuN6+ZILt7wiNfmVjO6tWk=; 7:pPAFTw0F2ri0a7yNcu7+Zbq+TSzk0wTQFg8XPFMhjCu03kqmsZP4AFFhG3iXH7CUJBz41mNA2hAhVCGbbyhtjlkNgpKjA117go7kH+4CwvoPkuhC8zO1U3aLpMKU2rUDYnf4w535T2b6VrOWanDExrfFmHnRERnyrlTJhIdVVJbBoRegzQt7liAbEcszjhQd/9r0kaWGthrDgvrpn0ZlHGyQcl3XpfPa51vAGE8O2QfUVJfgVtg1OGzTgOP6JD+a SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2018 23:01:46.0378 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b25322d2-8636-4168-2a8a-08d5772395b6 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR04MB0754 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 23:01:53 -0000 Hi Tim, On Wed, Dec 06, 2017 at 02:59:51PM +0100, Tim Bruijnzeels wrote: > I think that there may be merit in an explicit json, or XML (to be > consistent with 6492 and 8181) format, e.g.: > > > > https://rpki.example.org/rpki/hedgehog/root.cer > rsync://rpki.example.org/rpki/hedgehog/root.cer > > > ... > > > > A structure like this will make it easier to add tags or attributes > to communicate other things. This approach looks good. Would this structure be specific to the signed TAL, with the 'standard' TAL remaining as-is? > If we need an explicit staging time, rather than require this > implicitly by publishing it, then I think we are better off with a > valid object and an XML structure like above with an additional tag > like: > > 2019-01-01T00:00:00.000Z Agreed, this approach makes more sense. >> Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old key >> after the staging period as a hint for RPs that missed the key roll". >> Although (I think) the only sensible way to read this is that the >> signed TAL to which this is referring is that pointing to the new TA, >> "for the old key" might make people think the signed TAL should be for >> the deprecated key instead. Something like "[t]he TA SHOULD preserve >> the Signed TAL pointing to the new TA after the staging period..." >> could work. > > So, here there is a lot of implicit stuff again. > > We could also think of this differently.. maybe extending the > structure to something like this could help: > > > > MIIBIjANBgk… > MIIBIjdfkhjfd… > ... > > > This way we can communicate explicitly which previous keys have been > expired. And what the current key is at the time of publishing this. > > If this is published by old keys in the form of long-lived objects > and CRLs, then RPs could still find their way to the current key. An > argument can also be made that RPs should not care about staleness > of MFT/CRL or expired MFT/TAL EE certificates in this case. What's the motivation for explicitly listing the previous keys in the signed TAL? If each deprecated TA publishes a long-lived signed TAL that points to the TA that superseded it, then anybody who is using a deprecated TA will be able to find the current TA, and I can't think of other instances where knowing the previous keys would be useful. >> I think 24 hours for the staging period is too short, mainly because >> people who don't update their validators to support this may not take >> action on the new validation error (something like "unknown type of >> object: {name}.tal") within that short a time period. > > Okay, it’s not clear to me that this is related to the staging period. > > But, before any of this could be deployed we do need to be sure that > RP software can be upgraded to support it, or at least not choke on > it. If people do not upgrade their RP software they can still find > out that a new TAL should be used through other means (e.g. mailing > lists). And let me be devil’s advocate here.. if people never, ever > upgrade their RP software, then breaking it and forcing them to > upgrade could be considered a feature by some. Of course, after a > reasonable time.. > >> There are also other instances like this where manual action might >> be required, e.g. where operations staff insist that the validator >> not have write access to its configuration and that all updates >> happen manually. A week or a month as a mandatory period would be >> better. > > I believe that we should insist that key rolls like this are fully > automated and not done manually. I also believe that it would be > prudent that if && when we agree on a mechanism for this, it is done > regularly - at least in some environments to ensure that this works. > In short: I think a planned key roll, signed by a trusted TA, should > be a normal thing. If we leave this as paperware then there will be > no guarantee that it works when we need it. OK, sounds good. > And as a final thought.. it would be good if the planned and > unplanned key roll processes are similar. One option here is for planned rollover to be handled by having the 'staging' key details include an additional 'transition date' field, indicating that the TA operator expects to be using the staging key as its TA key by that date. That would allow the 'staging period' from 6.2 to remain as-is, while also providing for more advance notice to be given by way of the 'transition date' field. -Tom From nobody Mon Feb 19 00:32:51 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D02126C89 for ; Mon, 19 Feb 2018 00:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 A7VHkcBuT1Fw for ; Mon, 19 Feb 2018 00:32:48 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62811242F5 for ; Mon, 19 Feb 2018 00:32:48 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1engsP-000B1B-QB for sidrops@ietf.org; Mon, 19 Feb 2018 09:32:47 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-126.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1engsP-0008HW-Db; Mon, 19 Feb 2018 09:32:45 +0100 From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Feb 2018 09:32:33 +0100 Message-Id: <7A074C08-F339-4650-8B40-0D2736B570B2@ripe.net> To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c73f66bb9690f09206144a68235ddbb1 Archived-At: Subject: [Sidrops] No meeting at IETF101? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 08:32:50 -0000 Hi all, I was looking to finalise my travel to London, and to my surprise I = found no session for SIDROPS on the preliminary agenda: = https://datatracker.ietf.org/meeting/agenda.html Given the opportunity I would really like the option to discuss the = following in person with attending working group members: - HTTPS in TALs (probably short and sweet) - Signed TALs: -- XML structure? -- Pre-stage keys for unplanned rolls? - RIPE NCC Validator 3 -- Highlight architecture / differences from 2.x -- Calll for feedback from operators and router vendors (now supports = RPKI-RTR v1, and deltas) Furthermore I know that RPKI (and IRR) filtering is now being enabled at = a number of IX-es. I would really value feedback from operators at these = IX-es, and their customers regarding RPKI validation, and ROA = maintenance. So, is there any chance of a face to face happening? Thanks Tim= From nobody Tue Feb 20 02:38:24 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE212426E for ; Tue, 20 Feb 2018 02:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 vKv3DWrfGnyu for ; Tue, 20 Feb 2018 02:38:21 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB111200E5 for ; Tue, 20 Feb 2018 02:38:21 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eo5JS-00079S-TA; Tue, 20 Feb 2018 11:38:19 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-226.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eo5JS-0005S7-NP; Tue, 20 Feb 2018 11:38:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <20180218230133.GG5488@tomh-laptop> Date: Tue, 20 Feb 2018 11:38:15 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151064401825.5985.7789265592065530099@ietfa.amsl.com> <20171116103441.GB7247@tomh-laptop> <20180218230133.GG5488@tomh-laptop> To: Tom Harrison X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190c35dddce193a3856ff02a510b53a9ae Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 10:38:23 -0000 Hi Tom, > On 19 Feb 2018, at 00:01, Tom Harrison wrote: >=20 > Hi Tim, >=20 > On Wed, Dec 06, 2017 at 02:59:51PM +0100, Tim Bruijnzeels wrote: >> I think that there may be merit in an explicit json, or XML (to be >> consistent with 6492 and 8181) format, e.g.: >>=20 >> >> >> https://rpki.example.org/rpki/hedgehog/root.cer >> rsync://rpki.example.org/rpki/hedgehog/root.cer >> >> >> ... >> >> >>=20 >> A structure like this will make it easier to add tags or attributes >> to communicate other things. >=20 > This approach looks good. Would this structure be specific to the > signed TAL, with the 'standard' TAL remaining as-is? In the past I have argued for a more structure TAL. But.. I don=E2=80=99t = think there is a strict need. There are working implementations that can = parse the current format. Allowing HTTPS (other thread) is fairly = trivial as well. So, in short I would leave the standard TAL as-is, until it=E2=80=99s = found that other information is needed there. >> If we need an explicit staging time, rather than require this >> implicitly by publishing it, then I think we are better off with a >> valid object and an XML structure like above with an additional tag >> like: >>=20 >> 2019-01-01T00:00:00.000Z >=20 > Agreed, this approach makes more sense.=20 >=20 >>> Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old = key >>> after the staging period as a hint for RPs that missed the key = roll". >>> Although (I think) the only sensible way to read this is that the >>> signed TAL to which this is referring is that pointing to the new = TA, >>> "for the old key" might make people think the signed TAL should be = for >>> the deprecated key instead. Something like "[t]he TA SHOULD = preserve >>> the Signed TAL pointing to the new TA after the staging period..." >>> could work. >>=20 >> So, here there is a lot of implicit stuff again. >>=20 >> We could also think of this differently.. maybe extending the >> structure to something like this could help: >>=20 >> >> >> MIIBIjANBgk=E2=80=A6 >> MIIBIjdfkhjfd=E2=80=A6= >> > ... >> >>=20 >> This way we can communicate explicitly which previous keys have been >> expired. And what the current key is at the time of publishing this. >>=20 >> If this is published by old keys in the form of long-lived objects >> and CRLs, then RPs could still find their way to the current key. An >> argument can also be made that RPs should not care about staleness >> of MFT/CRL or expired MFT/TAL EE certificates in this case. >=20 > What's the motivation for explicitly listing the previous keys in the > signed TAL? If each deprecated TA publishes a long-lived signed TAL > that points to the TA that superseded it, then anybody who is using a > deprecated TA will be able to find the current TA, and I can't think > of other instances where knowing the previous keys would be useful. I was thinking of pre-staging a backup key for an unplanned key roll. If = access to the current key is lost the backup key can then revoke the old = key. Having a full list was for completeness, but may be overkill, just = the one previous key should be enough. RPs would then always check the = back-up key, but as long as it didn=E2=80=99t revoke the current key no = further action would be needed. For planned rolls a simpler model with only forward signing (old key = says =E2=80=9Cnow use new key=E2=80=9D) would be fine. But.. if we do want to support unplanned rolls then it makes sense to me = that we should use the same algorithm in both cases. >>> I think 24 hours for the staging period is too short, mainly because >>> people who don't update their validators to support this may not = take >>> action on the new validation error (something like "unknown type of >>> object: {name}.tal") within that short a time period. >>=20 >> Okay, it=E2=80=99s not clear to me that this is related to the = staging period. >>=20 >> But, before any of this could be deployed we do need to be sure that >> RP software can be upgraded to support it, or at least not choke on >> it. If people do not upgrade their RP software they can still find >> out that a new TAL should be used through other means (e.g. mailing >> lists). And let me be devil=E2=80=99s advocate here.. if people = never, ever >> upgrade their RP software, then breaking it and forcing them to >> upgrade could be considered a feature by some. Of course, after a >> reasonable time.. >>=20 >>> There are also other instances like this where manual action might >>> be required, e.g. where operations staff insist that the validator >>> not have write access to its configuration and that all updates >>> happen manually. A week or a month as a mandatory period would be >>> better. >>=20 >> I believe that we should insist that key rolls like this are fully >> automated and not done manually. I also believe that it would be >> prudent that if && when we agree on a mechanism for this, it is done >> regularly - at least in some environments to ensure that this works. >> In short: I think a planned key roll, signed by a trusted TA, should >> be a normal thing. If we leave this as paperware then there will be >> no guarantee that it works when we need it. >=20 > OK, sounds good. >=20 >> And as a final thought.. it would be good if the planned and >> unplanned key roll processes are similar. >=20 > One option here is for planned rollover to be handled by having the > 'staging' key details include an additional 'transition date' field, > indicating that the TA operator expects to be using the staging key as > its TA key by that date. That would allow the 'staging period' from > 6.2 to remain as-is, while also providing for more advance notice to > be given by way of the 'transition date' field. For a planned rollover we can do this. Unless we find that access is = lost to the new key before the roll takes place. In that case it will = have to be withdrawn, and likely replaced with a new key. For unplanned rolls it would be needed that keys can be used ahead of = this date. One might use a back-up key with the intention of using it 3 = months from now, but if access to the current key is lost one week from = now, one would still do a quick uplanned roll then. So, in short, if unplanned rolls need to be supported, then this date = should be taken as an intent only. But RPs should keep checking for an = unplanned roll. I hope this makes sense. Would be happy to discuss in person. Tim >=20 > -Tom >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Feb 20 09:50:54 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72683127909 for ; Tue, 20 Feb 2018 09:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 AR8xs0vx7D8m for ; Tue, 20 Feb 2018 09:50:51 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5371A126D0C for ; Tue, 20 Feb 2018 09:50:51 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eoC42-0004lQ-Be (job@us.ntt.net) for sidrops@ietf.org; Tue, 20 Feb 2018 17:50:51 +0000 Received: by mail-oi0-f46.google.com with SMTP id x12so1637141oie.13 for ; Tue, 20 Feb 2018 09:50:50 -0800 (PST) X-Gm-Message-State: APf1xPCln25vH3b5Jwxc79Pp+FYvJi15uz4+Q6l8sY16Gc1mxoweLCiP 3LcVMKRZ/VR3cGYcOJe7aasRJm2xruDYvvQi9zKH/Q== X-Google-Smtp-Source: AH8x224QhiLO/Cd6vLrGOwgwCOcJ7umZVKXmlTqOg7w4uwo7LdHSYSZPEGunc9yXjEG1qVBD4io7riWpdkMIQ7AmHkg= X-Received: by 10.202.240.8 with SMTP id o8mr341722oih.208.1519149049843; Tue, 20 Feb 2018 09:50:49 -0800 (PST) MIME-Version: 1.0 References: <7A074C08-F339-4650-8B40-0D2736B570B2@ripe.net> In-Reply-To: <7A074C08-F339-4650-8B40-0D2736B570B2@ripe.net> From: Job Snijders Date: Tue, 20 Feb 2018 17:50:39 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Tim Bruijnzeels Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0933a67a2a610565a873a5" Archived-At: Subject: Re: [Sidrops] No meeting at IETF101? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:50:52 -0000 --94eb2c0933a67a2a610565a873a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m interested in a meeting as well! On Mon, 19 Feb 2018 at 03:32, Tim Bruijnzeels wrote: > Hi all, > > I was looking to finalise my travel to London, and to my surprise I found > no session for SIDROPS on the preliminary agenda: > https://datatracker.ietf.org/meeting/agenda.html > > Given the opportunity I would really like the option to discuss the > following in person with attending working group members: > > - HTTPS in TALs (probably short and sweet) > - Signed TALs: > -- XML structure? > -- Pre-stage keys for unplanned rolls? > > - RIPE NCC Validator 3 > -- Highlight architecture / differences from 2.x > -- Calll for feedback from operators and router vendors (now supports > RPKI-RTR v1, and deltas) > > Furthermore I know that RPKI (and IRR) filtering is now being enabled at = a > number of IX-es. I would really value feedback from operators at these > IX-es, and their customers regarding RPKI validation, and ROA maintenance= . > > So, is there any chance of a face to face happening? > > Thanks > > Tim > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --94eb2c0933a67a2a610565a873a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99m interested in a meeting as well!
On Mon, 19 Feb 2018 at 03:32, Tim Bruijnz= eels <tim@ripe.net> wrote:
Hi all,

I was looking to finalise my travel to London, and to my surprise I found n= o session for SIDROPS on the preliminary agenda: htt= ps://datatracker.ietf.org/meeting/agenda.html

Given the opportunity I would really like the option to discuss the followi= ng in person with attending working group members:

- HTTPS in TALs (probably short and sweet)
- Signed TALs:
=C2=A0 =C2=A0-- XML structure?
=C2=A0 =C2=A0-- Pre-stage keys for unplanned rolls?

- RIPE NCC Validator 3
=C2=A0 =C2=A0-- Highlight architecture / differences from 2.x
=C2=A0 =C2=A0-- Calll for feedback from operators and router vendors (now s= upports RPKI-RTR v1, and deltas)

Furthermore I know that RPKI (and IRR) filtering is now being enabled at a = number of IX-es. I would really value feedback from operators at these IX-e= s, and their customers regarding RPKI validation, and ROA maintenance.

So, is there any chance of a face to face happening?

Thanks

Tim
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--94eb2c0933a67a2a610565a873a5-- From nobody Tue Feb 20 17:42:05 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED11126BF7 for ; Tue, 20 Feb 2018 17:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZohBcteMed0h for ; Tue, 20 Feb 2018 17:42:03 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 B344C120227 for ; Tue, 20 Feb 2018 17:42:02 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id u200so55002vke.4 for ; Tue, 20 Feb 2018 17:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mfg0wrgvsp+0Bo0eWwfmdEtXg6f3YWHznSWsgTfq6T8=; b=bwawQw5zfOJoJd7OTEl0fr4Fon9whkq4ydFakW7oVdDNc2ckUI59GxsjOW6q0nRYKt uAGu442t2jiNPtmDYrd6n8cHYdcocldMQhAFDEWraV0V2N4gqpXV0wIqqj2ynMnszaQs spAkKVeon37u+NjnRCQCKd5jGjhmTkVCzpUZJv4YMpcrgY3Lz+mwzKyQSbyWtcQIvUjf pi48orOTEqeaX6nRz6KQvJnuHcfsY8IvLPQhpRCiufl/Cxx3oAVZpHL0y3kZaVdj6JhP fPEvpN9WhEN8+nM408HuOKLJgeUJwP/A9/x+aW89UayxZbFrgCSTwLztRGJJeWeBoHFx F5QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mfg0wrgvsp+0Bo0eWwfmdEtXg6f3YWHznSWsgTfq6T8=; b=iu4f/shw+Z0miGw4PQxJw4Mz9tx7Z2fAY2m7JosjlGZTudAypKcF6EcDw1Al3gLjXP M/CrNEjoWXg9rRYnPKjjdUjNAFK4TEV5EBX005l9uyTfelmsqF4u0RErOMAedEJyV2/J RaEUgaWlpulajrAUiv00sIXRPWIw3AuLU9dXenjbyUInu3LpWB+A0Wqoj0jxtrGcU0fJ 53GqInzBySvj/SNtqx5woy8h9tny2QzZHM8EFTnojy/HRZ/b9MS6KaOsLyQ7hobigIbl tC6ULA2JsPYuKa6QtPH3zQ9hmB4jfeyB3J7ARo33vcOlmkiRx6WbxPD/Pp2U+1wP/GOG VvNw== X-Gm-Message-State: APf1xPC3pGXgoBSqR6gHoJChmNZBU9O7yJ88LYpnQaLMktgdYosPS+fX lsHPuH6PKTSu6Zaz/ACCVa0otTHZX+Rddz8XmXI= X-Google-Smtp-Source: AH8x2250m3IookJ48PWxpcUPVkb/pFyO7uD/knnDYhFb+J9A+JP6eLLnQH3v9p93MazENKm/c+kZJ2AROMDmF4kYpYk= X-Received: by 10.31.252.2 with SMTP id a2mr1291736vki.22.1519177321531; Tue, 20 Feb 2018 17:42:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.9.205 with HTTP; Tue, 20 Feb 2018 17:42:00 -0800 (PST) In-Reply-To: References: <7A074C08-F339-4650-8B40-0D2736B570B2@ripe.net> From: Christopher Morrow Date: Tue, 20 Feb 2018 20:42:00 -0500 Message-ID: To: Job Snijders Cc: Tim Bruijnzeels , sidrops@ietf.org Content-Type: multipart/alternative; boundary="94eb2c14998a99cf0a0565af0851" Archived-At: Subject: Re: [Sidrops] No meeting at IETF101? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 01:42:05 -0000 --94eb2c14998a99cf0a0565af0851 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry folks, I missed out on signing up for a session (travel/sickness/hurtness got my attention during when I should have been signing up) :( I'm asking the ADs if they can squeeze us in. On Tue, Feb 20, 2018 at 12:50 PM, Job Snijders wrote: > I=E2=80=99m interested in a meeting as well! > > On Mon, 19 Feb 2018 at 03:32, Tim Bruijnzeels wrote: > >> Hi all, >> >> I was looking to finalise my travel to London, and to my surprise I foun= d >> no session for SIDROPS on the preliminary agenda: >> https://datatracker.ietf.org/meeting/agenda.html >> >> Given the opportunity I would really like the option to discuss the >> following in person with attending working group members: >> >> - HTTPS in TALs (probably short and sweet) >> - Signed TALs: >> -- XML structure? >> -- Pre-stage keys for unplanned rolls? >> >> - RIPE NCC Validator 3 >> -- Highlight architecture / differences from 2.x >> -- Calll for feedback from operators and router vendors (now supports >> RPKI-RTR v1, and deltas) >> >> Furthermore I know that RPKI (and IRR) filtering is now being enabled at >> a number of IX-es. I would really value feedback from operators at these >> IX-es, and their customers regarding RPKI validation, and ROA maintenanc= e. >> >> So, is there any chance of a face to face happening? >> >> Thanks >> >> Tim >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >> > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > --94eb2c14998a99cf0a0565af0851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry folks, I missed out on signing up for a session (tra= vel/sickness/hurtness got my attention during when I should have been signi= ng up) :( I'm asking the ADs if they can squeeze us in.

On Tue, Feb 20, 2018 at 12:= 50 PM, Job Snijders <job@ntt.net> wrote:
I=E2=80=99m interested in a meeting as well= !

On Mon, 1= 9 Feb 2018 at 03:32, Tim Bruijnzeels <tim@ripe.net> wrote:
Hi all,

I was looking to finalise my travel to London, and to my surprise I found n= o session for SIDROPS on the preliminary agenda: htt= ps://datatracker.ietf.org/meeting/agenda.html

Given the opportunity I would really like the option to discuss the followi= ng in person with attending working group members:

- HTTPS in TALs (probably short and sweet)
- Signed TALs:
=C2=A0 =C2=A0-- XML structure?
=C2=A0 =C2=A0-- Pre-stage keys for unplanned rolls?

- RIPE NCC Validator 3
=C2=A0 =C2=A0-- Highlight architecture / differences from 2.x
=C2=A0 =C2=A0-- Calll for feedback from operators and router vendors (now s= upports RPKI-RTR v1, and deltas)

Furthermore I know that RPKI (and IRR) filtering is now being enabled at a = number of IX-es. I would really value feedback from operators at these IX-e= s, and their customers regarding RPKI validation, and ROA maintenance.

So, is there any chance of a face to face happening?

Thanks

Tim
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops<= br>

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops<= br>

--94eb2c14998a99cf0a0565af0851-- From nobody Thu Feb 22 05:08:52 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 927DB12EAAF; Thu, 22 Feb 2018 05:08:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151930492655.21208.9958646222171374233@ietfa.amsl.com> Date: Thu, 22 Feb 2018 05:08:46 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 13:08:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties Authors : Di Ma Stephen Kent Filename : draft-ietf-sidrops-rp-01.txt Pages : 11 Date : 2018-02-22 Abstract: This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rp-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 22 09:00:02 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFFE127698; Thu, 22 Feb 2018 08:32:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sidrops-chairs@ietf.org, lflynn@amsl.com, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151931717514.8184.3994444892461658746.idtracker@ietfa.amsl.com> Date: Thu, 22 Feb 2018 08:32:55 -0800 Archived-At: X-Mailman-Approved-At: Thu, 22 Feb 2018 09:00:01 -0800 Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 101 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 16:32:55 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: grow idr Second Priority: opsec opsarea Third Priority: opsawg People who must be present: Keyur Patel Alvaro Retana Chris Morrow Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Feb 26 09:55:40 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7769512025C for ; Mon, 26 Feb 2018 09:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 HpQUpGKMLaEh for ; Mon, 26 Feb 2018 09:55:26 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0063.outbound.protection.outlook.com [104.47.38.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E861277BB for ; Mon, 26 Feb 2018 09:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cczk2URlM90kaVq+jwJw9+srXErT+f8KMsUh1L5N8Y8=; b=aYy1n0x189Lk+3FQ5xFjAVs8Aw+WwBsvnd4O2iiJuXA9LSTWjI77e3I3dotEdY+Fgz6fhNg42wbBZI6jbED7iNz5lFTTQrtv5swWj8PWaxAkC3OqjFjcvCno4sRvcHn3cee5N5AXbifpq4DSI1V3odk8MFbPK1aYhuwr4tT74gk= Received: from BY2PR18MB0328.namprd18.prod.outlook.com (10.163.192.30) by BY2PR18MB0245.namprd18.prod.outlook.com (10.163.72.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Mon, 26 Feb 2018 17:55:23 +0000 Received: from BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) by BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) with mapi id 15.20.0527.021; Mon, 26 Feb 2018 17:55:23 +0000 From: Keyur Patel To: SIDR Operations WG CC: Chris Morrow Thread-Topic: Call for SIDROPS WG Agenda Items Thread-Index: AQHTryr5bpo2gM2DtUixXX7C0Qu3sw== Date: Mon, 26 Feb 2018 17:55:22 +0000 Message-ID: <55A96281-2CCD-4D24-9543-6DCD8B6FEB01@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [75.8.210.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR18MB0245; 7:RdqX+Zu3JaPKLkjmjzrOoxQhwFS6BoOe0dyfWlgJcZKetjuFzdZXNHN44RqyoQBgByqH6pf7aj0bVqAuATV8Zvp7fq5ERqwRF+2lrrhfNS/4sCIY7boNJKjgMKGCD+JkaTyuvaEzq/vhj3ZLdzZoFTD0M7X1isJoUte9cK8yXr8fUw1wCThUY8EioGd1SQcIuYy4byYWwaBm27hkZz4os0L9NlO1U25VLQBWZi/FmJpljRn68Czjam4hS2bgu8zS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 614d1e0a-f861-4167-ca98-08d57d421bed x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR18MB0245; x-ms-traffictypediagnostic: BY2PR18MB0245: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231220)(944501161)(52105095)(3002001)(6041288)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:BY2PR18MB0245; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0245; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(346002)(396003)(376002)(39830400003)(189003)(199004)(99286004)(5660300001)(6512007)(77096007)(7736002)(97736004)(6116002)(102836004)(53936002)(3280700002)(3846002)(14454004)(54896002)(2900100001)(6436002)(6486002)(106356001)(3660700001)(6306002)(105586002)(4326008)(66066001)(316002)(33656002)(25786009)(6916009)(82746002)(478600001)(83716003)(68736007)(81156014)(186003)(6506007)(86362001)(8936002)(2906002)(81166006)(8676002)(36756003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0245; H:BY2PR18MB0328.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GERvHYnkuYjjR0lca3XPrvVakMnpe51Zdgi6gNMqWUzTECzSQ8leCKYidfiDXRi+7GWCVTq91v2QXxruv6OikCvR43MCCGBJvB8WCjw9vbI5yrCfHxSGVE511tQqjwibgj5DZrfCEyQDrbwVFXc87GdI7PwYJC4RZXuDVs7qEhA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_55A962812CCD4D2495436DCD8B6FEB01arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 614d1e0a-f861-4167-ca98-08d57d421bed X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2018 17:55:23.1267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0245 Archived-At: Subject: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:55:28 -0000 --_000_55A962812CCD4D2495436DCD8B6FEB01arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtMTAxIG9uIFRodXJzZGF5LCBN YXJjaCAyMm5kIGZyb20gMzo1MCBwbSAtIDU6NTAgcG0uIFBsZWFzZSBmb3J3YXJkIGFueSBTSURS T1BTIGFnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gQ2hyaXMgYW5kIG1lLiBQbGVhc2UgYWxz byBtYWtlIHN1cmUgdGhhdCB5b3VyIHNsaWRlcyBhcmUgYXZhaWxhYmxlIHRvIHRoZSBjaGFpcnMg YnkgTW9uZGF5IG1vcm5pbmcgKDMvMTkvMjAxOCkuIFNsaWRlcyByZWNlaXZlZCBhZnRlciB0aGUg ZGVhZGxpbmUgbWF5IG5vdCBiZSBhdmFpbGFibGUgZm9yIHVzZSBkdXJpbmcgdGhlIG1lZXRpbmcu DQoNClJlZ2FyZHMsDQpDaHJpcyBhbmQgS2V5dXINCg0K --_000_55A962812CCD4D2495436DCD8B6FEB01arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBmb2xr cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNJRFJPUFMgd2ls bCBtZWV0IGF0IElFVEYtMTAxIG9uIFRodXJzZGF5LCBNYXJjaCAyMjxzdXA+bmQ8L3N1cD4gZnJv bSAzOjUwIHBtIC0gNTo1MCBwbS4gUGxlYXNlIGZvcndhcmQgYW55IFNJRFJPUFMgYWdlbmRhIGl0 ZW1zIHlvdSBtYXkgaGF2ZSB0byBDaHJpcyBhbmQgbWUuIFBsZWFzZSBhbHNvIG1ha2Ugc3VyZSB0 aGF0IHlvdXIgc2xpZGVzIGFyZSBhdmFpbGFibGUNCiB0byB0aGUgY2hhaXJzIGJ5IE1vbmRheSBt b3JuaW5nICgzLzE5LzIwMTgpLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgdGhlIGRlYWRsaW5lIG1h eSBub3QgYmUgYXZhaWxhYmxlIGZvciB1c2UgZHVyaW5nIHRoZSBtZWV0aW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Q2hyaXMgYW5kIEtleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_55A962812CCD4D2495436DCD8B6FEB01arrcuscom_-- From nobody Tue Feb 27 01:35:22 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A329126BF7 for ; Tue, 27 Feb 2018 01:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 u6u53goVIw3q for ; Tue, 27 Feb 2018 01:35:19 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A5D12778D for ; Tue, 27 Feb 2018 01:35:19 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eqbfH-00093y-Ji; Tue, 27 Feb 2018 10:35:16 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-236.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eqbfH-00039Y-F9; Tue, 27 Feb 2018 10:35:15 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <55A96281-2CCD-4D24-9543-6DCD8B6FEB01@arrcus.com> Date: Tue, 27 Feb 2018 10:34:56 +0100 Cc: SIDR Operations WG , Chris Morrow Content-Transfer-Encoding: quoted-printable Message-Id: References: <55A96281-2CCD-4D24-9543-6DCD8B6FEB01@arrcus.com> To: Keyur Patel X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d3ccda9ad4a6dc36f418da10a338c678 Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 09:35:21 -0000 Hi, I can talk about the following, time permitting - so I would welcome = feedback from the WG on what people would be interested in - can be off = list as well of course. =3D RIPE NCC RPKI Validator 3 architecture We will have a beta release ready by the IETF. I can discuss the architecture and differences with version 2.x. In = particular we now have asynchronous retrieval of data, so an offline = repository does not block validation. And we separated the RPKI-RTR = server for redundancy. If folk are interested I can walk the group through the architecture and = algorithm we use. =3D Signed TALs https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-00 There was some discussion on the list regarding this. The published = document builds on plain old TALs, but: * It has implicit intent and dates * It does not support unplanned rolls On list I suggested an XML structure that would allow us to make things = explicit and a possible way to also deal with unplanned rolls. I would = value feedback on this, and think presenting and discussing on the mic = may help. =3D HTTPS in TALs https://tools.ietf.org/html/draft-tbruijnzeels-sidrops-https-tal-00 (Chairs: Adoption call ended on 9 feb) I can present on this if desired and time permitting. But, since (to me) = it seems to be non-controversial, I am also happy to do this on the = list, or just have the chairs ask if anyone wants to comment. > On 26 Feb 2018, at 18:55, Keyur Patel wrote: >=20 > Hi folks, > =20 > SIDROPS will meet at IETF-101 on Thursday, March 22nd from 3:50 pm - = 5:50 pm. Please forward any SIDROPS agenda items you may have to Chris = and me. Please also make sure that your slides are available to the = chairs by Monday morning (3/19/2018). Slides received after the deadline = may not be available for use during the meeting. > =20 > Regards, > Chris and Keyur > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Feb 27 06:41:37 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BCE12D940; Tue, 27 Feb 2018 06:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 Rw7TavFT27lg; Tue, 27 Feb 2018 06:41:34 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0115.outbound.protection.outlook.com [23.103.201.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B3F126DC2; Tue, 27 Feb 2018 06:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=urfyxwxRNqyT45Nb6tdT7H/LxFK9ac62HDbmIxfmN+w=; b=URI1t0gzBXOqu22yr3+LBpR8G7aHjB7SntF0C4C+ffM7oLSlIAYu6c9wNiAyMQnBebJFA05cqe93uHT9/2DUc+gxR5TajKnWLyXX80sNnw5Ko5uK/JlOwXglwg1i13fTYtcbjjKH/d62DSPQ+UOGxXc4dggkAfEkHLO+jAthqCQ= Received: from BYAPR09MB2773.namprd09.prod.outlook.com (52.135.224.26) by BYAPR09MB2774.namprd09.prod.outlook.com (52.135.224.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Tue, 27 Feb 2018 14:41:32 +0000 Received: from BYAPR09MB2773.namprd09.prod.outlook.com ([fe80::d015:9eb2:757:ba95]) by BYAPR09MB2773.namprd09.prod.outlook.com ([fe80::d015:9eb2:757:ba95%13]) with mapi id 15.20.0527.021; Tue, 27 Feb 2018 14:41:32 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "keyur@arrcus.com" CC: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" Thread-Topic: [Sidrops] Call for SIDROPS WG Agenda Items Thread-Index: AQHTr9WsP955gNW76EmxPhAwVRxpHQ== Date: Tue, 27 Feb 2018 14:41:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.218.118] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR09MB2774; 7:bQU7In9r5YcuI2Y2914aVTJ/K8EHaOPNNpAM5wscrbkpfebGzH2xsVjkmpyC371hbfkllfMZIIso206rEqGwW+ZGTEi5quM4hgubJX/4gKj3KrFlc0eMBGznFynyK+G3SDUCATOrSY9yGmmGiEz0qRt6b14RUBxh6Z0DuD2XaAVbcM2hzOpwNkc9e2Fa+8gQYkXcQqobt9EJMj/9rEDUGDS/G824hOaa9AUMaE8Y3fXC6s175eMsGBc/qZhEBO/l x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: aa3ea363-dcfc-4aae-fde4-08d57df03214 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BYAPR09MB2774; x-ms-traffictypediagnostic: BYAPR09MB2774: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501161)(52105095)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BYAPR09MB2774; BCL:0; PCL:0; RULEID:; SRVR:BYAPR09MB2774; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(366004)(39380400002)(199004)(189003)(106356001)(3846002)(6116002)(7696005)(6916009)(68736007)(186003)(2906002)(14454004)(2501003)(229853002)(26005)(3280700002)(99286004)(5250100002)(102836004)(4326008)(59450400001)(105586002)(478600001)(66066001)(6506007)(86362001)(5660300001)(316002)(25786009)(54906003)(53936002)(5640700003)(33656002)(97736004)(6246003)(55016002)(8936002)(2900100001)(3660700001)(74316002)(305945005)(81166006)(9686003)(7736002)(1730700003)(2351001)(81156014)(8676002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR09MB2774; H:BYAPR09MB2773.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: vUB2xgJmq2AGexXOWivKJCmm9xeSGbr0BJlmV/X0toEPbwuN6BCqcdptKhXV7muSuSgwU5S1BRv2yua242NvoTKz7BYyfWAt1xruOyvcs6YMfoOnsCfblI/wPiGu4HkJpQguGvcogtC8+AG5wvBmxIEencnxCx3MJer/6sn3Ft0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: aa3ea363-dcfc-4aae-fde4-08d57df03214 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2018 14:41:32.7559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR09MB2774 Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:41:36 -0000 I would like to make the following request: Topic: Origin Validation Policy Considerations for Dropping Invalid Routes Presenter: K. Sriram Time: ~ 20 min=20 It is about a study we (NIST) did about =93Drop Invalid if Still Routable (= DISR)=94 policy and its usefulness in partial/incremental deployment scenarios. We would to present it and invite discussion. Thanks. Sriram From nobody Tue Feb 27 15:13:24 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4812EA98; Tue, 27 Feb 2018 15:11:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307062.5200.14479453284270082572.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:10 -0800 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 101 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:11 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (1:00:00) Thursday, Afternoon Session II 1550-1750 Room Name: Park Suite size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: idr grow Second Priority: opsarea opsec Third Priority: opsawg People who must be present: Warren Kumari Chris Morrow Alvaro Retana Keyur Patel Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Feb 27 23:53:35 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48BB124207 for ; Tue, 27 Feb 2018 23:53:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3IUX-DqjaPqd for ; Tue, 27 Feb 2018 23:53:31 -0800 (PST) Received: from out20-15.mail.aliyun.com (out20-15.mail.aliyun.com [115.124.20.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785F61243F3 for ; Tue, 27 Feb 2018 23:53:28 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.268648|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e01e01542; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.B6vxXpW_1519804402; Received: from 192.168.216.94(mailfrom:madi@rpstir.net fp:202.173.9.211) by smtp.aliyun-inc.com(10.147.42.198); Wed, 28 Feb 2018 15:53:22 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <55A96281-2CCD-4D24-9543-6DCD8B6FEB01@arrcus.com> Date: Wed, 28 Feb 2018 15:53:21 +0800 Cc: SIDR Operations WG , Chris Morrow Content-Transfer-Encoding: quoted-printable Message-Id: References: <55A96281-2CCD-4D24-9543-6DCD8B6FEB01@arrcus.com> To: Keyur Patel X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 07:53:34 -0000 Keyur, I am going to brief the update of draft-ietf-sidrops-rp (Requirements = for RPKI Relying Parties) A 5-minute slot is okay. Thanks. Di > =D4=DA 2018=C4=EA2=D4=C227=C8=D5=A3=AC01:55=A3=ACKeyur Patel = =D0=B4=B5=C0=A3=BA >=20 > Hi folks, > =20 > SIDROPS will meet at IETF-101 on Thursday, March 22nd from 3:50 pm - = 5:50 pm. Please forward any SIDROPS agenda items you may have to Chris = and me. Please also make sure that your slides are available to the = chairs by Monday morning (3/19/2018). Slides received after the deadline = may not be available for use during the meeting. > =20 > Regards, > Chris and Keyur > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Feb 28 09:36:31 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2810A124217 for ; Wed, 28 Feb 2018 09:36:30 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 DAHyoFOFqp46 for ; Wed, 28 Feb 2018 09:36:27 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7C2126BF7 for ; Wed, 28 Feb 2018 09:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nwmrxnPftm2Q5IxRr6gvb9vDICVmfH6eLO+zHNDWEFk=; b=GkPV+eqibuIKSMwoP+todli0cXTCyI59WZ2kaeTUEC0VyFYN+H0NfHAhMMDudmVet1kQ/qEeKMpFqUWldvGQSdrg2+zhi9RJLkhqzbZGuoX29s5Th8oZNEfZMfa+xhwPjNDZI5VvTZUsXXIgw1jStBaq2FiNKlNR4yQ3F1RGlhw= Received: from BY2PR18MB0328.namprd18.prod.outlook.com (10.163.192.30) by BY2PR18MB0197.namprd18.prod.outlook.com (10.163.67.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 17:36:23 +0000 Received: from BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) by BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) with mapi id 15.20.0527.021; Wed, 28 Feb 2018 17:36:23 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt Thread-Index: AQHTluQNJn3dcRDtwUy6KH7GaOzx4KO5wWcA Date: Wed, 28 Feb 2018 17:36:23 +0000 Message-ID: <78223F83-6076-418C-8A7F-239739F40889@arrcus.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [75.8.210.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR18MB0197; 6:ORn21FfM3VXeHXKo6NY4TBx2Ek0wDnJB40p32y1B7j08x4h0JrkDj+mswRJzk6jHhpD6dgTpnuw8WBDDTP5ZA3yNYkRKLVjr2P7RO3kjBjvmEYn4NB9Aa0BP+cTJmfRfYJYZA9c2J5BpXfPZwBj2WRqHra6261pRwBj4awSUTPeD2KvVRrawWaHUtdibQUC1UkNAfxt90Ye3V7FIDUMkUsilG8LtkIXrFEnlcPyyLtYaXtDpgCrDPdSJbwhr84VfVUkIEJ/gfUZTiCaWSCHMs60LdwKh84FzZa4kmL3zw3uP4cd/nz6N2FiZzxRZ83sAWQ5kJphWhl6Zxwro5OxIDfk6tMZB9q4A2fUpy1dGydhWcFSEv7ihAsVOy7xBnVCa; 5:vAlCKOhkpa5DE+eOC71LDAhVpfdDSNYr063Kmpmsika1our76PrEzPNUBe1dAiJGKhqoiIEFBKSksvt39KyNX8w+3U3KL3peVxdQCdihcloXxCNAl1R+cVbb6dqlpz7Urfoq1ZpOExi1kdusL+lFAkbFTLNnpckHElSqtDQDhbk=; 24:5byjH2Ln1Y/9rN4FXEJoE9AfBQg0V1uv8WLuI5r+qGc2aHz287yIem7UTLasZx8r/jxavHelnlhy90OZ3cMkvxy8N0QQ9fQXjLJvR2n3Ccg=; 7:qhVgeIbgu+gNJgv2w+d2hKz0F8iQChxOugX7pbLElwY8ng5qoSWKtGXKewYoIeevlGNwXiR6Jwb5PDudCfNsWt4hXCwI1ICkpwFLwDMWLP5GEBbf4aC+YctOJFm2XRnfu5k0DGo/3cpW7IUTPw5shJvSg7V32m/hMNvSbyS8zqsMuH08bbKzX++/xlak6BliP3EmfTcQ9liLFJAX1LWV5JAZoVcNXm/0Y4C6pHB+zg/Pw0EzVEDoxPwpcQzf++vd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: db04b773-fa52-42fb-f8cb-08d57ed1c974 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR18MB0197; x-ms-traffictypediagnostic: BY2PR18MB0197: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501161)(52105095)(93006095)(93001095)(3002001)(6041288)(20161123564045)(2016111802025)(20161123558120)(20161123562045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:BY2PR18MB0197; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0197; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(376002)(346002)(396003)(39380400002)(366004)(189003)(199004)(99286004)(14454004)(6436002)(105586002)(236005)(6512007)(53936002)(2900100001)(6486002)(81166006)(7736002)(33656002)(66066001)(478600001)(6246003)(36756003)(25786009)(966005)(5640700003)(6306002)(102836004)(186003)(76176011)(229853002)(3660700001)(2906002)(26005)(2950100002)(6506007)(53546011)(2351001)(83716003)(54896002)(68736007)(316002)(8936002)(8676002)(5660300001)(82746002)(77096007)(86362001)(106356001)(97736004)(3846002)(81156014)(1730700003)(6916009)(606006)(2501003)(6116002)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0197; H:BY2PR18MB0328.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MmfirM9mJqt5MnDL+BnOZRuv9Wd6t3T0gsIaEZkihtWZxzvlxTelJdBAzzqAkbVMK3Tt3XbLrmfLCy9T4ttTZMzI7FKHGPvTv8yIRELNd5DD/yK3LRDzv5ELwmR4hSP1yD9Q+EXqOmRFH7XwFbsvCkTHM0yNzzCPbdynlm8To2M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_78223F836076418C8A7F239739F40889arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: db04b773-fa52-42fb-f8cb-08d57ed1c974 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 17:36:23.4850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0197 Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:36:30 -0000 --_000_78223F836076418C8A7F239739F40889arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFNJRFJPUFMgV0cgaGFzIHJlYWNoZWQgY29uc2Vuc3VzIHRvIGFkb3B0aW9uIG9mIHRoZSBk cmFmdC10YnJ1aWpuemVlbHMtc2lkcm9wcy1odHRwcy10YWwtMDAudHh0LiBUaGUgYXV0aG9ycyBh cmUgcmVxdWVzdGVkIHRvIHN1Ym1pdCB0aGUgLTAwIHdnIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KQ2hy aXMgJiAgS2V5dXINCg0KRnJvbTogS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+DQpEYXRl OiBGcmlkYXksIEphbnVhcnkgMjYsIDIwMTggYXQgMTI6MjcgUE0NClRvOiAic2lkcm9wc0BpZXRm Lm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBXRyBBZG9wdGlvbiBjYWxsIGZvciBk cmFmdC10YnJ1aWpuemVlbHMtc2lkcm9wcy1odHRwcy10YWwtMDAudHh0DQoNCkhpIEZvbGtzLA0K DQpUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBTSURST1BTIHdvcmtpbmcgZ3JvdXAgYWRvcHRp b24gY2FsbCBvZiDigJxSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSBU cnVzdCBBbmNob3IgTG9jYXRvcuKAnSwgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt dGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4dC4NCg0KUGxlYXNlIHNlbmQgeW91 ciBjb21tZW50cyB0byB0aGUgbGlzdC4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29uY2x1ZGUg b24gRmViIDkgMjAxOC4NCg0KUmVnYXJkcywNCkNocmlzICYgS2V5dXINCg0KDQo= --_000_78223F836076418C8A7F239739F40889arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F785E85299FF742988B38CEF9FDB1EE@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBTSURST1BTIFdHIGhhcyByZWFjaGVkIGNvbnNlbnN1 cyB0byBhZG9wdGlvbiBvZiB0aGUgZHJhZnQtdGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFs LTAwLnR4dC4gVGhlIGF1dGhvcnMgYXJlIHJlcXVlc3RlZCB0byBzdWJtaXQgdGhlIC0wMCB3ZyBk cmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkNocmlzICZhbXA7Jm5ic3A7IEtleXVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktleXVyIFBhdGVsICZsdDtr ZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEphbnVhcnkgMjYs IDIwMTggYXQgMTI6MjcgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcm cXVvdDsgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPldHIEFk b3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXRicnVpam56ZWVscy1zaWRyb3BzLWh0dHBzLXRhbC0wMC50 eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBGb2xrcyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVk IFNJRFJPUFMgd29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIG9mIOKAnFJlc291cmNlIFB1Ymxp YyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFJQS0kpIFRydXN0IEFuY2hvciBMb2NhdG9y4oCdLCAmbmJz cDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRicnVpam56ZWVscy1z aWRyb3BzLWh0dHBzLXRhbC0wMC50eHQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt dGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4dDwvYT4uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRv IHRoZSBsaXN0LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVkZSBvbiBGZWIgOSAyMDE4 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Q2hyaXMgJmFtcDsgS2V5dXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_78223F836076418C8A7F239739F40889arrcuscom_-- From nobody Wed Feb 28 09:40:25 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49848124217; Wed, 28 Feb 2018 09:40:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 j4WwaVmHSYlS; Wed, 28 Feb 2018 09:40:20 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::61f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2310126BF7; Wed, 28 Feb 2018 09:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iojfEO3pbvs02QuhhbegvdDku5Kts/KdoEfGNYtxd8I=; b=X/sJvZ06WkU4gFkQ2h2h2s215modY/Le/vFvpGHr5BTKxdvsnLqblFPc/ScKC/Gv6R+H8q90VjflUDfdUDbSJAz/kwhQOf86tVhM9bupHXkgjug9YY2q0Op8UDNZIUtBSBvmcOVwGhoLgpB21AoV2dJF9nSjQkKX1kGdMyjQ7ws= Received: from BY2PR18MB0328.namprd18.prod.outlook.com (10.163.192.30) by BY2PR18MB0149.namprd18.prod.outlook.com (10.163.67.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 17:40:16 +0000 Received: from BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) by BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) with mapi id 15.20.0527.021; Wed, 28 Feb 2018 17:40:16 +0000 From: Keyur Patel To: Christopher Morrow , "sidrops@ietf.org" , "sidrops-chairs@ietf.org" Thread-Topic: Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis Thread-Index: AQHTmfmCTOMq5pgaVkS/D5PyYKkcvKO5vFMA Date: Wed, 28 Feb 2018 17:40:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [75.8.210.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR18MB0149; 7:lxZ94QE4VJW3L/z0N4wTaZHOM0ozpiclbtDRKwV/yS0ZElGkKPn3XxYFNT73T0v9DG8xbKIrg/tiVaYdfxsaBMD3xqt6vFb1y8tJIAn4rBymtwnTjrKgqLKZoCE7dn+OfF6x7OfrRm/O6rI5zh63IkSrHqWAcCAF3/uK505Q9tcYexOZ4+wemQMozgKQg9UYEvmklsSAqPCc9J4sK230la1Lilgm8ABfLnfjKIhmuW0MHe0vElYSKqutHgwojyGC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f38971db-5abb-4c97-5bb7-08d57ed2548b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR18MB0149; x-ms-traffictypediagnostic: BY2PR18MB0149: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501217)(52105095)(10201501046)(6041288)(20161123560045)(20161123558120)(20161123562045)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011); SRVR:BY2PR18MB0149; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0149; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(366004)(39380400002)(396003)(346002)(189003)(199004)(3280700002)(6436002)(76176011)(2201001)(2900100001)(86362001)(606006)(186003)(3660700001)(66066001)(83716003)(68736007)(77096007)(26005)(2501003)(6306002)(6486002)(102836004)(236005)(54896002)(105586002)(14454004)(53546011)(6506007)(6246003)(99286004)(229853002)(53936002)(6512007)(3846002)(5660300001)(6116002)(966005)(25786009)(97736004)(82746002)(2950100002)(8936002)(478600001)(7736002)(36756003)(39060400002)(8676002)(33656002)(81156014)(110136005)(106356001)(81166006)(2906002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0149; H:BY2PR18MB0328.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ay42GK4O0OeR1nxSeLgU977YR4fS08MA0T3+WXUzBK/58h8tAXpOvP9iCB4BFck1tQiX+/IOS4GTfBeQ0owZKDdGosBntrLtwnPN2UGnofdHcHUHNj/piDITBZeX/OTYWDN3Kt9Ee00RqpWejP4XAgHCIkMIa/cqWx99dNllovI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BE4D251B6D2E431DA2AC6D62FF374E36arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: f38971db-5abb-4c97-5bb7-08d57ed2548b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 17:40:16.8350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0149 Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:40:22 -0000 --_000_BE4D251B6D2E431DA2AC6D62FF374E36arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFNJRFJPUFMgV0cgaGFzIHJlYWNoZWQgY29uc2Vuc3VzIHRvIGFkb3B0aW9uIG9mIHRoZSBk cmFmdC1ib3JjaGVydC1zaWRyb3BzLWJncHNlYy1hbGdzLXJmYzgyMDgtYmlzLiBUaGUgYXV0aG9y cyBhcmUgcmVxdWVzdGVkIHRvIHN1Ym1pdCB0aGUgLTAwIHdnIGRyYWZ0Lg0KDQpSZWdhcmRzLA0K Q2hyaXMgJiBLZXl1cg0KDQoNCkZyb206IENocmlzdG9waGVyIE1vcnJvdyA8Y2hyaXN0b3BoZXIu bW9ycm93QGdtYWlsLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEphbnVhcnkgMzAsIDIwMTggYXQgMTA6 MzggQU0NClRvOiAic2lkcm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+LCAic2lkcm9w cy1jaGFpcnNAaWV0Zi5vcmciIDxzaWRyb3BzLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IENh bGwgZm9yIEFkb3B0aW9uOiBkcmFmdC1ib3JjaGVydC1zaWRyb3BzLWJncHNlYy1hbGdzLXJmYzgy MDgtYmlzDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86 IDxtb3Jyb3djQG9wcy1uZXRtYW4ubmV0PiwgPGtleXVyQGFycmN1cy5jb20+DQpSZXNlbnQtRGF0 ZTogVHVlc2RheSwgSmFudWFyeSAzMCwgMjAxOCBhdCAxMDozOCBBTQ0KDQpIb3dkeSBXRyBmb2xr cywNCg0KT2xpdmVyIGhhcyBkb25lIHNvbWUgd29yayB0byBmdXJ0aGVyIGhpcyBwcmVzZW50ZWQg bWF0ZXJpYWwgZnJvbSBTaW5nYXBvcmU6DQogICJFeHRlbmRpbmcgUkZDODIwODggYnkgYWRkaW5n IEV4cGVyaW1lbnRhbC9Eb2N1bWVudGF0aW9uIGFsZ29yaXRobSBJRHMiDQoNClRoaXMgaXMgcmVm bGVjdGVkIGluIHRoZSBzdWJqZWN0IGRyYWZ0Ly1iaXMgZm9yIFJGQzgyMDguIENhbiB3ZSBwbGVh c2UgdGFrZSAyIHdlZWtzIChlbmRpbmc6IDAyLzEzLzIwMTggLSBGZWIgMTMsIDIwMTgpIHRvIHJl YWQvcmV2aWV3L2NvbW1lbnQgYW5kIGNvbnNpZGVyIGlmIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJl IGFkb3B0ZWQgYnkgdGhlIHNpZHJvcHMgd29ya2luZy1ncm91cCBhcyBhIHdvcmsgaXRlbT8NCg0K RHJhZnQ6DQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3JjaGVydC1zaWRy b3BzLWJncHNlYy1hbGdzLXJmYzgyMDgtYmlzLTAwDQoNCnRoYW5rcyENCi1jaHJpcw0Kc2lkcm9w cy1jaGFpci0wMg0K --_000_BE4D251B6D2E431DA2AC6D62FF374E36arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlRoZSBTSURST1BTIFdHIGhhcyByZWFjaGVkIGNvbnNlbnN1cyB0byBhZG9wdGlv biBvZiB0aGUgZHJhZnQtYm9yY2hlcnQtc2lkcm9wcy1iZ3BzZWMtYWxncy1yZmM4MjA4LWJpcy4g VGhlIGF1dGhvcnMgYXJlIHJlcXVlc3RlZCB0byBzdWJtaXQgdGhlIC0wMCB3ZyBkcmFmdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPkNocmlzICZhbXA7Jm5ic3A7S2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5DaHJpc3RvcGhlciBNb3Jyb3cgJmx0O2NocmlzdG9w aGVyLm1vcnJvd0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEphbnVh cnkgMzAsIDIwMTggYXQgMTA6MzggQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzaWRyb3BzLWNoYWly c0BpZXRmLm9yZyZxdW90OyAmbHQ7c2lkcm9wcy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPkNhbGwgZm9yIEFkb3B0aW9uOiBkcmFmdC1ib3JjaGVydC1zaWRyb3BzLWJn cHNlYy1hbGdzLXJmYzgyMDgtYmlzPGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMt Ym91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj4mbHQ7bW9ycm93Y0Bv cHMtbmV0bWFuLm5ldCZndDssICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPlJlc2Vu dC1EYXRlOiA8L2I+VHVlc2RheSwgSmFudWFyeSAzMCwgMjAxOCBhdCAxMDozOCBBTTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93 ZHkgV0cgZm9sa3MsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T2xpdmVyIGhhcyBkb25lIHNvbWUgd29yayB0byBmdXJ0aGVyIGhpcyBwcmVzZW50ZWQgbWF0 ZXJpYWwgZnJvbSBTaW5nYXBvcmU6PGJyPg0KJm5ic3A7ICZxdW90O0V4dGVuZGluZyBSRkM4MjA4 OCBieSBhZGRpbmcgRXhwZXJpbWVudGFsL0RvY3VtZW50YXRpb24gYWxnb3JpdGhtIElEcyZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIGlzIHJlZmxlY3RlZCBpbiB0aGUgc3ViamVjdCBkcmFmdC8tYmlzIGZvciBSRkM4MjA4LiBD YW4gd2UgcGxlYXNlIHRha2UgMiB3ZWVrcyAoZW5kaW5nOiAwMi8xMy8yMDE4IC0gRmViIDEzLCAy MDE4KSB0byByZWFkL3Jldmlldy9jb21tZW50IGFuZCBjb25zaWRlciBpZiB0aGlzIGRvY3VtZW50 IHNob3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSBzaWRyb3BzIHdvcmtpbmctZ3JvdXAgYXMgYSB3b3Jr IGl0ZW0/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRyYWZ0OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvcmNoZXJ0LXNpZHJvcHMtYmdwc2VjLWFsZ3MtcmZjODIwOC1iaXMtMDAiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3JjaGVydC1zaWRyb3BzLWJncHNlYy1h bGdzLXJmYzgyMDgtYmlzLTAwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tY2hyaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNpZHJvcHMtY2hhaXItMDI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BE4D251B6D2E431DA2AC6D62FF374E36arrcuscom_-- From nobody Wed Feb 28 13:04:19 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4541200C1 for ; Wed, 28 Feb 2018 13:04:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 7lXMCHfKuoL2 for ; Wed, 28 Feb 2018 13:04:16 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0053.outbound.protection.outlook.com [104.47.37.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04714124BE8 for ; Wed, 28 Feb 2018 13:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CokNCNmiL1JlPQeSg/CA8cRANpDPDyWEhPTGkADrvZU=; b=NwmR1/65/rCm+V+sr+IA4yj6cLE0iEoO/DcDPHqkot0jzVZKsEBjxhzbEpDMsk6WzsdQycLlQk3MVEheKagGaJTfFhxvkEhZxTqAyQCptO37+IaUC11VLEBAmFR+7vxLRn0DndP20CfxB0mIft09iTvYdDiKTgDmIUHYrBVqTwk= Received: from BY2PR18MB0328.namprd18.prod.outlook.com (10.163.192.30) by BY2PR18MB0312.namprd18.prod.outlook.com (10.163.73.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 21:04:13 +0000 Received: from BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) by BY2PR18MB0328.namprd18.prod.outlook.com ([10.163.192.30]) with mapi id 15.20.0527.021; Wed, 28 Feb 2018 21:04:13 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: WGLC for draft-ietf-sidrops-ov-clarify-00 Thread-Index: AQHTsNevd93dQqbRvk2fQa3dcVKOaA== Date: Wed, 28 Feb 2018 21:04:13 +0000 Message-ID: <5A15A7DD-EE21-499F-8F1C-6E250495E1F6@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2602:306:3005:4f60:31d6:f401:54e0:eb3c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR18MB0312; 6:v6pT5KFJeycGM901Ol5nOWKVuVSwqeqxXDwH1WUjK7pBvvbMCVGa6XU6VU96tZWsS/tJy7CXDmOq3PWhg4RKaLQVtft8hjXKz3N6JE+l/njSsncgvDhNnl7t67za/LiErowh1lqQmXZhWQUzV0FaNHGr9sCUnLtIF4mwlx/RZ96LeRMZzc5+2PU+JHUJ3GNRd7QlgTkllE1dCEoMNkcLUtNea1hZJsfGm6zEl+KyzTq2YuXI9XtlHsbG7TcGf/ySXdkw6qq/79kZrKOp7AXzrkwk3I4Y+JLuCY/dRzp7+NRwTgvV62ZLyhdRBNH8cuNDG4iS1DezOPrkYUeDOPT7KAJ6n2/zkjCR2KZWj71sJg0hC5VrcrMbxCl2Kvbkpylo; 5:HVopkug1y0C27Wv/ThBB7X6o7wJsNomWnKEmC9At17EZqhG4AzxppB+6WSCp1KvqltDFUjhDu8PYs437l0Z72zyoGsHb/Pi+1WrLchoX7vpMvFkS/70y4N1WEz4Oq2lo4EhQPfE1Qn89PNmev1mvEz1Zv9kzwFuXHCYklIi59Hw=; 24:wUD5xxf0uXbc0PycQNE+OWnkKiOZVd3EJ1fSJiufjF6g5fOc34ctqaJJygy0BQaD+XgVQus0PbyY0qMNz+AVr8ssTVzB9tNMmDbZ7cGe6GA=; 7:thKB3Lbxwptw1wpgVtT6UAI3GX1TjMrKICz4uwzMBItnZZLqY1p7OKp+3EfY9wCd5Tm9I0FPBYidTaEV/bBS6649SSe6u9ExUULZ+3MGTiUNW9OrE3gowvskskPEu4jD4hLD/NNOcgduAl8CyMu4fy6uiSpt2H/hTcvPuFekEXzuHDL4POWy+dXVVhecT8p6PsB4qFioxBDhX+BF0JysyAF+i/vv4CaKz9mjQfWrIysZdtS2TVrOdYTFJJMpHd2d x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a0fe87b8-cd0d-44a9-251e-08d57eeed1f4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR18MB0312; x-ms-traffictypediagnostic: BY2PR18MB0312: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501161)(52105095)(6041288)(20161123558120)(20161123564045)(2016111802025)(20161123562045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:BY2PR18MB0312; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0312; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(39830400003)(39380400002)(199004)(189003)(8936002)(81166006)(7736002)(102836004)(3660700001)(606006)(53936002)(6506007)(86362001)(5660300001)(478600001)(33656002)(3280700002)(77096007)(2501003)(966005)(59450400001)(2906002)(236005)(25786009)(6436002)(82746002)(2900100001)(316002)(106356001)(2351001)(6916009)(8676002)(83716003)(186003)(36756003)(105586002)(81156014)(6512007)(6486002)(1730700003)(14454004)(97736004)(99286004)(68736007)(6116002)(5640700003)(54896002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0312; H:BY2PR18MB0328.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4D9X3bQED9pHHOnvV7qKVMuggq2ez6+9fvHw2pBbJgNhCcZBxYX0JrURCdN6UxaMV2zHaeV5tHaYgJ2A6AYRJRDupQiDkZlHfQcxKLMvO6cV7LIy834GOFCVfp4vWYAZb9l0/g1RjG2Y/QzrNRRPokkDa5jw2M0mQVraT95dUug= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5A15A7DDEE21499F8F1C6E250495E1F6arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0fe87b8-cd0d-44a9-251e-08d57eeed1f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 21:04:13.1141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0312 Archived-At: Subject: [Sidrops] WGLC for draft-ietf-sidrops-ov-clarify-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:04:18 -0000 --_000_5A15A7DDEE21499F8F1C6E250495E1F6arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVk IGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtb3YtY2xhcmlmeS0wMCwg4oCcT3JpZ2luIFZhbGlkYXRp b24gQ2xhcmlmaWNhdGlvbnPigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIg Y29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIE1hcmNoIDE1LCAyMDE4Lg0KDQpUaGUgZHJh ZnQgY2FuIGJlIGZvdW5kIGF0OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXNpZHJvcHMtb3YtY2xhcmlmeS8uDQoNClJhbmR5IGFzIGFuIGF1dGhvciBvZiB0aGlz IGRvY3VtZW50IGl0IHdvdWxkIGJlIGdyZWF0IGlmIHlvdSBjYW4gcGxlYXNlIGNvbmZpcm0gdGhh dCBhbnkgcmVsZXZhbnQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCktleXVy DQo= --_000_5A15A7DDEE21499F8F1C6E250495E1F6arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <40F9DB2E473FAD4E94564A138B125F39@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJp Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q291cmllcjt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBGb2xrczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVx dWVzdGVkIGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtb3YtY2xhcmlmeS0wMCwg4oCcT3JpZ2luIFZh bGlkYXRpb24gQ2xhcmlmaWNhdGlvbnPigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRo IHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIE1hcmNoIDE1LCAyMDE4LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGRyYWZ0IGNhbiBiZSBm b3VuZCBhdDogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zaWRyb3BzLW92LWNsYXJpZnkvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2lkcm9wcy1vdi1jbGFyaWZ5LzwvYT4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SYW5keSBhcyBhbiBhdXRob3Igb2YgdGhpcyBkb2N1 bWVudCBpdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgY2FuIHBsZWFzZSBjb25maXJtIHRoYXQgYW55 IHJlbGV2YW50IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LZXl1cjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_5A15A7DDEE21499F8F1C6E250495E1F6arrcuscom_-- From nobody Wed Feb 28 13:57:10 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0D126CF9 for ; Wed, 28 Feb 2018 13:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WSpRpu9AnoN9 for ; Wed, 28 Feb 2018 13:57:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 BE88D126E64 for ; Wed, 28 Feb 2018 13:57:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1er9ij-00089n-Iv; Wed, 28 Feb 2018 21:57:06 +0000 Date: Thu, 01 Mar 2018 06:57:03 +0900 Message-ID: From: Randy Bush To: Keyur Patel Cc: "sidrops@ietf.org" In-Reply-To: <5A15A7DD-EE21-499F-8F1C-6E250495E1F6@arrcus.com> References: <5A15A7DD-EE21-499F-8F1C-6E250495E1F6@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-clarify-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:57:09 -0000 > Randy as an author of this document it would be great if you can > please confirm that any relevant IPR has been disclosed. ipr? ain't got any. randy