From nobody Sun Nov 1 19:52:12 2020 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 7C4B13A0CE1; Sun, 1 Nov 2020 19:52:10 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160428913047.8562.8628061640807872700@ietfa.amsl.com> Date: Sun, 01 Nov 2020 19:52:10 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 03:52:10 -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 : RPKI Signed Object for Trust Anchor Keys Authors : Carlos Martinez George G. Michaelson Tom Harrison Tim Bruijnzeels Rob Austein Filename : draft-ietf-sidrops-signed-tal-06.txt Pages : 18 Date : 2020-11-01 Abstract: A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by Relying Parties (RP) in the RPKI to locate and validate a Trust Anchor (TA) CA certificate used in RPKI validation. This document defines an RPKI signed object for a set of Trust Anchor Keys (TAK), that can be used by TA creators and publishers to signal their set of current keys and the location(s) of the accompanying CA certificates to RPs, as well as changes to this set in the form of revoked keys and new keys, in order to support both planned and unplanned key rolls without impacting RPKI validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-06 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-06 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 Sun Nov 1 21:00:23 2020 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 3CCCC3A0D65; Sun, 1 Nov 2020 21:00:22 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160429322222.24817.12520511990759493819@ietfa.amsl.com> Date: Sun, 01 Nov 2020 21:00:22 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 05:00:22 -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 : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-01.txt Pages : 17 Date : 2020-10-31 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-6486bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-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 Mon Nov 2 07:59:55 2020 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 5219E3A1184; Mon, 2 Nov 2020 07:59:27 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160433276728.27937.10370357022765531639@ietfa.amsl.com> Date: Mon, 02 Nov 2020 07:59:27 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:59:35 -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 : The Use of Maxlength in the RPKI Authors : Yossi Gilad Sharon Goldberg Kotikalapudi Sriram Job Snijders Ben Maddison Filename : draft-ietf-sidrops-rpkimaxlen-05.txt Pages : 12 Date : 2020-11-02 Abstract: This document recommends ways to reduce forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. The document also discusses creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and origin validation in the context of destination-based Remote Triggered Black Hole (RTBH) filtering are also highlighted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-05 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpkimaxlen-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 10:09:53 2020 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 D52563A011D; Mon, 2 Nov 2020 10:09:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160434059283.17915.2357672974511738943@ietfa.amsl.com> Date: Mon, 02 Nov 2020 10:09:52 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:09:53 -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 : A Profile for Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Uskov Randy Bush Keyur Patel Job Snijders Russ Housley Filename : draft-ietf-sidrops-aspa-profile-04.txt Pages : 9 Date : 2020-11-02 Abstract: This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized members of Provider set to be its upstream providers and for the Providers to send prefixes received from the Customer Autonomous System in all directions including providers and peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-profile-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 10:11:28 2020 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 D69933A011D; Mon, 2 Nov 2020 10:11:23 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160434068384.31368.11133710617113280750@ietfa.amsl.com> Date: Mon, 02 Nov 2020 10:11:23 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:11:24 -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 : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-06.txt Pages : 13 Date : 2020-11-02 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-verification-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 10:31:40 2020 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 5B89C3A0365; Mon, 2 Nov 2020 10:31:29 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160434188933.15957.8067316035340522087@ietfa.amsl.com> Date: Mon, 02 Nov 2020 10:31:29 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:31:29 -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 : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-02.txt Pages : 17 Date : 2020-11-02 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-6486bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-02 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 Nov 5 10:12:46 2020 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 BDA053A1944 for ; Thu, 5 Nov 2020 10:12:44 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 JAkwDYwSMK8A for ; Thu, 5 Nov 2020 10:12:43 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2062.outbound.protection.outlook.com [40.107.244.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCF93A1941 for ; Thu, 5 Nov 2020 10:12:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W53RBTmiFGXf+gXfEONGn4n6dALWmu3h4bgelpUEiMfRwGtFYrZ2nwN+Mk/yatGdvr30X+GZpaUjpZlTjQcMLoFNH25oIY6FVdy5uqwy7N9hpo9tohSZJE1C2vM6I0otmijiCpzEjm7s2g2KVPkdEZMxJ1kaH9T4n/AHv/NH325XVUTXuKYTT15dozcKwQHxpeZhedZkcWIh7jHKt6IOF/4OzvygNIZN2f4ZRO08NznD5bzh7Hs2BqeBeOHv6ZcjFEyFR7a0xEPNA/5pxffwRBE6hodGyXkX+d/DS1i19PbkazU9R3qL2ZqY2iewHUuYzVrAKnzv4yotWFTuU4UisA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FP3Su1nV2oB26Oc/t9b6hlnFa7FJQm24HceH1yij0Mc=; b=Us49FaZil3WrMN+JRkn096aodIASNeH67omAVP9UNj+X+VdBumZc8PR99af03RNLiwyyRp5kpt+YUC+5++HBMu4bF8pF2zvjEVhdLKYdeQb3+fd5DzI7wF6a2ls+4x9lVsM6EtWPSutyWRdh5TH+RlBHPSgeHzvHRMoRGLx1wMvIIfEMhcq55XFlg3gcbs8ajsRajqlS6G2GOVf90V4GruzOCj3kai2F25XMLF6QO0sDFbpXcfwXKjWdZwbZEQOVl0hlxudqHoq8kxU/8Yi8gJCAwCzXPTF609GeoPjnWy5Hg1GdsxWF1e4PMZrRcG3fdsblb3xYc4WsvByoBPBo0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FP3Su1nV2oB26Oc/t9b6hlnFa7FJQm24HceH1yij0Mc=; b=i+3Md8FHqz4w/174iJcGykoQ5U++sB+HAgrc9YtMFCdkArdL3GkQv/iI8rPbyg3xxFOiZu7UYDYbFS8sb7PniRNjTqpNcN8oiuHKlcj8Ird8jpOKqeHQI6j8SnAnKED25PB64rWzbOgkfGDDT6MXeQ1Q5tS7ZDsSA73VZ7mXmwY= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3426.namprd18.prod.outlook.com (2603:10b6:a03:1a5::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Thu, 5 Nov 2020 18:12:41 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::781a:ed2d:9d3f:294c]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::781a:ed2d:9d3f:294c%4]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 18:12:41 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: IETF109 -- Online -- Call for Agenda Items Thread-Index: AQHWqI/h1hLCqY+28kaE01GZFD5Ooam5Z0SA Date: Thu, 5 Nov 2020 18:12:41 +0000 Message-ID: <37C89F80-5288-4014-BD0B-63B29783C372@arrcus.com> References: <27CEB8B1-D1CF-400C-9FFE-A2CC2FA0CB1B@arrcus.com> In-Reply-To: <27CEB8B1-D1CF-400C-9FFE-A2CC2FA0CB1B@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0362e608-245a-4f06-d95d-08d881b6630c x-ms-traffictypediagnostic: BY5PR18MB3426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n5Ly7QNQaP6LgksYGJzuWpeBdQB6jUcrpzmFMsHm2kBsaF3W3rfupAWZssu1WD1r8RgJmDnuDbBGqIatEIUolR7GfKWLRDcnQkHLK8WSow4kW6ci4YHCpJRV7UMyvdI8QM0p7RSM0gvKtlZN0a6OPrGSU6IE6V+j1N+GKAA9/s81ikLRmEKICfDWQYh9W4dG2cOvJPhx5Eqidgod11JjJTAM1DUx68UOAquakW+6J0o9MGNsv1+tX+KMH6xRWukRhyaaEAigdKv7dJp0I5y/RWxbrI3DWwX9yjQlybch3oNGUzP7F2ACnx9bmPF0DL6EeMHa2N+nUcZuhQPyZK94Z6H8hp6K0X/1zkifDGwUFhKatkjhsCKcZQ4aI3BXA87F x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(136003)(39830400003)(396003)(316002)(36756003)(4744005)(53546011)(8936002)(71200400001)(76116006)(33656002)(6506007)(6486002)(86362001)(8676002)(66946007)(6916009)(26005)(83380400001)(2906002)(66476007)(64756008)(5660300002)(2616005)(6512007)(478600001)(66446008)(186003)(66556008)(489414010); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: QPpAyRfP2IGfBuIkYxzJuzmOPr+itTbdNDyH2FO5zTKHUUi3Z9h6UAp+/6td/lsxnYMMcoQRBAHU84xydhl/C13fJe6GNyXF665RQ9y49BQexS8kozD4dJlQWxj/leVPYxn7E6q+/P/DaEmhm/z+/LN2K8AdqDzULpt1W02sUBMCk6smbjhP2waC8E/6SwWv5IktoDlE7j1MlpsoUw0gop5estKpcovxO6YobBJReyzNK5K+VRZn0QUAs6t2JgYdeXZpB9A07vkexS9vR9l7G8T+xkAkTbtOZoAB612TNHdnuLRBjXndYyVPnO2ndJ0BxKQyU3/dbFCv/9d705PoGtvDPUHgXU4KCtWFnEaphUHYh1laJV7h7wHP/40PYuGTAy/ASxtZya9bsH8juWhCgoUgh8cg1X7QklTPGT3Ee49AEB9aTmHCYjC4/0xTgTVA/QuUD1brpPlsIKUy1O2+KjwgMOkFQ5byJ6XzSR9HlcXIOvXEP5Y8z9qiZ6qfyMlq4Xpme7YPUNt3l6MNNRCeY0nOevX89WNV4CrqRdYCTvNqnykUu6kWtTvNXYQtQTzy1mj3u7DYE7faa/6pRg7sJL+p+Mxkf43ZU9aVFL/axcQt7xHc8jpalE+z75A7NmBZP4PxGy1ng4cG1VIND1obFQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_37C89F8052884014BD0B63B29783C372arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0362e608-245a-4f06-d95d-08d881b6630c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 18:12:41.7783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ha7+SbQiris3rSf3xQFW4wSiq0mFPWPZgxlXaciRsIhpj6swKc5SysW/der8fDPYuFtSMN2RUr80fcRCPq2x4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3426 Archived-At: Subject: Re: [Sidrops] IETF109 -- Online -- Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2020 18:12:45 -0000 --_000_37C89F8052884014BD0B63B29783C372arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3M6DQoNCkEgZ2VudGxlIHJlbWluZGVyLiBXZSBhcmUgYSB3ZWVrIGF3YXkgZnJvbSBJRVRG LTEwOS4gUGxlYXNlIGZvcndhcmQgYW55IFNJRFJPUFMgYWdlbmRhIGl0ZW1zIHlvdSBtYXkgaGF2 ZS4NCg0KUmVnYXJkcywNCktleXVyDQoNCkZyb206IEtleXVyIFBhdGVsIDxrZXl1ckBhcnJjdXMu Y29tPg0KRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIwMjAgYXQgOToyNCBBTQ0KVG86ICJz aWRyb3BzQGlldGYub3JnIiA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IElFVEYxMDkgLS0g T25saW5lIC0tIENhbGwgZm9yIEFnZW5kYSBJdGVtcw0KDQpIaSBmb2xrcywNCg0KU0lEUk9QUyB3 aWxsIG1lZXQgb25saW5lIGF0IElFVEYtMTA5IG9uIE1vbmRheSwgTm92ZW1iZXIgMTZ0aCBmcm9t IDk6MDAgYW0gLSAxMTowMCBhbSAoVVRDKS4gUGxlYXNlIGZvcndhcmQgYW55IFNJRFJPUFMgYWdl bmRhIGl0ZW1zIHlvdSBtYXkgaGF2ZSB0byBOYXRoYWxpZSwgQ2hyaXMgYW5kIG1lLiBQbGVhc2Ug YWxzbyBtYWtlIHN1cmUgdGhhdCB5b3VyIHNsaWRlcyBhcmUgYXZhaWxhYmxlIHRvIHRoZSBjaGFp cnMgYnkgRnJpZGF5ICgxMS8xMy8yMDIwKS4gU2xpZGVzIHJlY2VpdmVkIGFmdGVyIHRoZSBkZWFk bGluZSBtYXkgbm90IGJlIGF2YWlsYWJsZSBmb3IgdXNlIGR1cmluZyB0aGUgbWVldGluZy4NCg0K UmVnYXJkcywNCk5hdGhhbGllLCBDaHJpcyBhbmQgS2V5dXINCg0KDQo= --_000_37C89F8052884014BD0B63B29783C372arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <984C352EF529BC44908C44A857DCB139@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5Gb2xrczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkEgZ2VudGxlIHJlbWluZGVyLiBXZSBhcmUgYSB3ZWVrIGF3YXkgZnJvbSBJRVRGLTEw OS4gUGxlYXNlIGZvcndhcmQgYW55IFNJRFJPUFMgYWdlbmRhIGl0ZW1zIHlvdSBtYXkgaGF2ZS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+S2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+S2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIwIGF0IDk6MjQgQU08YnI+ DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpZHJvcHNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPklFVEYxMDkgLS0gT25saW5lIC0tIENhbGwg Zm9yIEFnZW5kYSBJdGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5IaSBmb2xrcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PlNJRFJPUFMmbmJzcDt3aWxsIG1lZXQgb25saW5lIGF0IElFVEYtMTA5IG9uIE1vbmRheSwgTm92 ZW1iZXIgMTY8c3VwPnRoPC9zdXA+Jm5ic3A7ZnJvbSA5OjAwIGFtIC0gMTE6MDAgYW0gKFVUQyku IFBsZWFzZSBmb3J3YXJkIGFueSZuYnNwO1NJRFJPUFMmbmJzcDthZ2VuZGEgaXRlbXMgeW91IG1h eSBoYXZlIHRvIE5hdGhhbGllLCBDaHJpcyBhbmQgbWUuIFBsZWFzZSBhbHNvDQogbWFrZSBzdXJl IHRoYXQgeW91ciBzbGlkZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2hhaXJzIGJ5IEZyaWRheSAo MTEvMTMvMjAyMCkuIFNsaWRlcyByZWNlaXZlZCBhZnRlciB0aGUgZGVhZGxpbmUgbWF5IG5vdCBi ZSBhdmFpbGFibGUgZm9yIHVzZSBkdXJpbmcgdGhlIG1lZXRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5OYXRoYWxpZSwgQ2hyaXMgYW5kIEtleXVy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_37C89F8052884014BD0B63B29783C372arrcuscom_-- From nobody Sun Nov 15 03:48:36 2020 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 380AB3A10F6 for ; Sun, 15 Nov 2020 03:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6ggbOgatoZm for ; Sun, 15 Nov 2020 03:48:35 -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 D38473A10F5 for ; Sun, 15 Nov 2020 03:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=3uSCVM7Ek3x+pA4Z8GVyoGJiG523F1iEyVMOdBTLcZk=; b=nrQobpJthDr9RP8s8fSqHo PWhSZmgeRTSDz2ccr3V6Jf4BMwVBFptJiuHxTBRYkZVze2byaIrNh/FOEf9MmqdDt2d7DJoNwZTOA 1BRwkVpGPq+aExrv2n0aVnCvG48YpjPk3AiDBA0s+uUoWkyG0Zw/ARaEuBMIUDR2WH97+53o1griU lo5oWo0jWm7rnHXOGq3FJaICHzg04DysO/dfTJc2X4pzLkZINv6GmX5Vshvf/BU73f8OTyMWvRTzJ eceXs/H+gtMGPZBc19ru7SJHcVad+j0uClFGwnwqE1a5vBvEsiIQ5mZLeKgK5F0t0bXJD7cc4ABx2 DRSZ/ewN1Iyw==; Received: from allealle.ripe.net ([193.0.23.12]:59222) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1keGWH-0003XC-Cp for sidrops@ietf.org; Sun, 15 Nov 2020 12:48:33 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::c3d]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1keGWH-0003kf-9x for sidrops@ietf.org; Sun, 15 Nov 2020 12:48:33 +0100 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_5E0FD005-4668-4CEB-8D36-8105F3DB2E93" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <929B8605-8567-4FFF-A571-DFBF7863E0B7@ripe.net> Date: Sun, 15 Nov 2020 12:48:32 +0100 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a4e4b74d697ed6bf24e1ea1b3aebd090f Archived-At: Subject: [Sidrops] sidrops meeting at IETF109 tomorrow (Monday 16 November) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2020 11:48:36 -0000 --Apple-Mail=_5E0FD005-4668-4CEB-8D36-8105F3DB2E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, We=E2=80=99re less than a day away from the sidrops meeting at IETF109.=20= We hope to see you all on Meetecho = https://az.conf.meetecho.com/conference/?group=3Dsidrops&short=3D&item=3D1= Monday 09:00 UTC The agenda is uploaded: = https://datatracker.ietf.org/meeting/109/materials/agenda-109-sidrops-02 = = There is also a handy participant guide on: = https://ietf.org/how/meetings/109/session-participant-guide/ = See you soon, Chris, Keyur, Nathalie --Apple-Mail=_5E0FD005-4668-4CEB-8D36-8105F3DB2E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

We=E2=80=99re less than a day away from the sidrops meeting = at IETF109. 

We hope to see you all on Meetecho https://az.conf.meetecho.com/conference/?group=3Dsidrops&sh= ort=3D&item=3D1 Monday 09:00 UTC
The = agenda is uploaded: https://datatracker.ietf.org/meeting/109/materials/agenda-109-s= idrops-02

There is also a handy participant guide on: https://ietf.org/how/meetings/109/session-participant-guide/

See you = soon,




= --Apple-Mail=_5E0FD005-4668-4CEB-8D36-8105F3DB2E93-- From nobody Sun Nov 15 13:05:17 2020 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 3AF463A09BC for ; Sun, 15 Nov 2020 13:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FrJnmS/r; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GTgedzB5 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 5A7E-CxG6lVG for ; Sun, 15 Nov 2020 13:05:14 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2CC3A09A4 for ; Sun, 15 Nov 2020 13:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20942; q=dns/txt; s=iport; t=1605474313; x=1606683913; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zQvo4mmDHOcxCTtcSmhdjN1PSSFwfFVUFG34SnjbC0g=; b=FrJnmS/rWp3Jj0Jgc6MC4kzQAvL1jOqr4nlGDaeF985B+M87I4qYpmc2 C8KtgHivjWUVLD04N1mIP0IWnh9g8tfbSN5MpNbQSXjd9RfWu09c8aUei WYLgkjfwA2Dyf0DkVx1pjMQ4bcgT90S1ijbJCgm1oC1yw/xFF36OsSTTI 4=; X-IPAS-Result: =?us-ascii?q?A0D3CACqlbFffYENJK1iHgEBCxIMgzIvUXtZLy6EPINJA?= =?us-ascii?q?41XlBSEb4JTA1QLAQEBDQEBGAEKCgIEAQGEBkQCF4IFAiU4EwIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEFAEBhjwMhXIBAQEBAgEBARARChMBASwEBQIBBAsCAQYCD?= =?us-ascii?q?gMEAQEoAwICAiULFAkIAgQBDQUIGoMFgX5XAw4gAQ6QaZBqAoE8iGh2gTKDB?= =?us-ascii?q?AEBBYUCGIIQAwaBOIJzg3aCRIQTG4FBP4ERQ4JPPoJdAQGBYRUWCYJhM4Isi?= =?us-ascii?q?3mEeoJ1hx6MDpEeCoJtlRKGJYMZnmCTUoIAmhiEOwIEAgQFAg4BAQWBayGBW?= =?us-ascii?q?XAVO4JpUBcCDY4fDBeDToUUhUR0NwIGAQkBAQMJfIxsWwUBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A8cD3nRwCppFCRzfXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/pohV7NG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK0NEFUHID1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,481,1596499200"; d="scan'208,217";a="609248596" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Nov 2020 21:05:13 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AFL5CbT004443 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2020 21:05:12 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 15 Nov 2020 15:05:12 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 15 Nov 2020 15:05:12 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 15 Nov 2020 15:05:12 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jO4DPXUFYZt7YIYBW7nsPWos62bY+rgR0jgRr9cZOtrNdpy7bI6+qnVjx0EXdLpTVCco/xmVyINvRqqXxOopkwpeNozvW/Qq9VJizCDQxki3lp+oNpHK64Zd00jWmT8VkYr50GZD4Zq6tZSZbryKDqB9okMnmQ1XBUUs44nHtZqf/LVIaJzD6HB+RJvU3vhP1vGhg6+MMXow8iqwjUGOenjGJUI9E+FUATShSAfFq6VRPlatTO4pV5iXqfThbhB5O3ilUFrFrOuoZqiFxKdKitQiNRh5/X08ozO5TBdzdLid031g/oZb3ZE6hX2RzUaizEt7LfYUqZD+ZXuiM0ChFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zQvo4mmDHOcxCTtcSmhdjN1PSSFwfFVUFG34SnjbC0g=; b=LtYqaRLwM1OLX363KvVkFT9cZPn56bYfv1dahkO89lOpt1djd4ijqg/lH9aE1rzZ2h6JNbodEkRLdtIzs+jVkYfyWo0Oumq5f5MT2aR7gtD5W/CW1GXOWnW+XIHBnT+rO/6SGyDGgxXsFeD9lAOydwvuEG9NMqU1uVLph75KjdNP3n/bOAyfvm89erEMC/vWGowN076iIp7F0JQKBuls8YPlvr60Eh1BRIytQ6HPCKgRo1o19bem1iF12ApfqnkrBrylXyGd9Ml94EfAkuwRLssQYluaJF/7ZhBKDQ+XcI5f2xYnvLSi/xo4HrBMKxuqrlXMRD4rmvNqmS0t1qU/MA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zQvo4mmDHOcxCTtcSmhdjN1PSSFwfFVUFG34SnjbC0g=; b=GTgedzB5dv7gSxTWnBTqyTsPnHueJ7oKBE8ZRdwPsLUUQ3ckpYSMGJSxHZdY2dynHxIYKBi4EL37g834p4TkRmXn7QqvdKN5IxkZxcBBgH6utAemzimauVQIEDzxxfnhUbS6WfunOM9YrGcJqUf9JsNlf/zUPQSA6uD98ycNQYY= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3832.namprd11.prod.outlook.com (2603:10b6:a03:ff::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Sun, 15 Nov 2020 21:05:09 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::f9c7:5d2b:4417:bb33]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::f9c7:5d2b:4417:bb33%3]) with mapi id 15.20.3541.025; Sun, 15 Nov 2020 21:05:09 +0000 From: "Jakob Heitz (jheitz)" To: Alexander Azimov , Randy Bush CC: SIDR Operations WG , Martin Hoffmann Thread-Topic: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt Thread-Index: AQHV7NDV3OdNqxpn3E2YzOPpNEuebKg7hE6AgAW4JICAElO8gIF3upnA Date: Sun, 15 Nov 2020 21:05:09 +0000 Message-ID: References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:9928:c1e8:ef98:bcb6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c06bcb72-8346-4dcd-88a2-08d889aa22da x-ms-traffictypediagnostic: BYAPR11MB3832: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wQU9lxxyWmlJGr2r7yKjZDnheovlWksyQPRenIdLUi3PUOWrm9l9FtRg038vRH6QI5Q9CsO4gC1FThLZeoRV/X3eYM21MSMzEu9FPUblERMvSyV0JC2sSKKeLqE0oZMavUDCxPDWrIG9+xD0Mfp/zUn9WbecdnehvaI2WJMXPpCBNEcWpjko0xTpIrchmQmN9un13Y9nk85gbxHh4F1YlQ8ee04RPjrxG1MbcLTXSoo0Qz2Cefa2A8CJEiD6qYyPzMIxQu9wqhLMv9lY4PPhIrgYQZ2Ayj/QYcKgNKZQIqsMwx94ZrwISjetZuGEHf8k2gxPmA5A53f1fPi7NI7UGfEmUwPTFuE9sBseiPS17bbbI8nyGGsfqRmcsoyUKk9v7q/IxJSvcVD27gMJE69cNQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(346002)(376002)(396003)(136003)(166002)(52536014)(71200400001)(83380400001)(54906003)(110136005)(5660300002)(316002)(66946007)(4326008)(66446008)(66556008)(8676002)(76116006)(64756008)(66476007)(15650500001)(8936002)(966005)(2906002)(86362001)(55016002)(186003)(33656002)(6506007)(478600001)(9686003)(53546011)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bmFyOFBoVFVmbTR2R2VQUU9MNTY0L1BHRElvU2FFdWljV2ZUZTNITHQ2Tng3?= =?utf-8?B?SlBYK3NtbXlSMXYrd0JDVTRQZjMzTzFpZVd3UFhYMTJIKzJyNkFEOWM5eHRL?= =?utf-8?B?djk3THRBcENtM0tyT3ArRFdocXljaDVGNysrYVNOeVJpbVRWdHlMQVE1UVNT?= =?utf-8?B?NzJUT3EzN1p1K1RuNm1WTzYzd0JlT1EyNzBDNC9XdUFwRk5NUUVWU2Vzc1Zj?= =?utf-8?B?TFF5WmMrQ1BXclRtM2VBNkUxcURNNmVGVEdlcE9xUjhqRytrOUZPV0wzdVpG?= =?utf-8?B?Rjkvcm1hMW5scUhKVUkvdUV6SXFrNVo4b0tYNzdTSGxNVlNQSG1COHhyV0I2?= =?utf-8?B?OTc2aGZiU2Y2ZnBtRC92NjRsRzJRaGg3b3hnQzV6OGRSRUdhd1MzQU1DeENQ?= =?utf-8?B?VElVQm5TMFY0MVYzSklhRUxpZ3lUNUhNb3ZWNHFnMTZiemVPT1N5QlBpQXFp?= =?utf-8?B?enNWa0lkYm80TTJFcWZkdC9YVVRxc05EZ09ZTHF4S2ZlNzVHOVhlUHIrZ2dh?= =?utf-8?B?bXBUNDdIeGJPRjlkQzN2MndkQlcrNjRTU25kbVBNY2dFaTI1Vk1PWnFYMCt1?= =?utf-8?B?UkROS1JHOHVXM3pXaURROWRZaVYwMDBleDNWZWFzOFBmbFNyeU5EaS9vMURv?= =?utf-8?B?aytMUW9Mc21IbEt3cHpuMldBN1cwUThzMmJoZU5ING5reWh1MXh2dDhEY1BU?= =?utf-8?B?aVlSQmdRZm1zZHFPNEhFd21YODQ5Ykx3QTlONVF6U2hmZU5KVmtRVkcwMWE3?= =?utf-8?B?a2ZaaU52d21Mbm1KemI2Y0VaTjY4THFHOGF3dGZCcVlGeG1NdWVjb2FlWjJV?= =?utf-8?B?NUhjMkZpK3V1aWRQelU1Z2Q0dUhTY0czNkV5VTRBc2k2dERCcTdseXNGdGNT?= =?utf-8?B?VlpRdGoxcWVTTW14MDk3Q2llcW9sWGNXVkVGUWVocC9QQmlNNUFKcFFqWXlI?= =?utf-8?B?UTlXczhWY1hHVnp2ci9rTG9FYWthOFFmQTVXNHZGVHRKeW9Kelg5dzFzMFNs?= =?utf-8?B?ZGJhdExpN29DYUpEb2s0Si84eHlPaVpYd1VjQTJuVlppTzkwdTJUWElhZXN1?= =?utf-8?B?Mi9rVUFkQ0pXbm5nbnJwWDNoK0JRV0lCdlBsa3dvRnREU2Y2RHBEeXBDUU9P?= =?utf-8?B?S1RzQ0dYdkJLNmRqeCtEMUJpS3pYM2doQk0zeTRRLzkwcGdOdDVTMTlDS1ZF?= =?utf-8?B?NGI3emVtT3NuMElyRWdBM1JuOUJDTWFxUlB5QS9iMUxZN2d1TWg0NFZxRmJB?= =?utf-8?B?Vm1uS2pqSkV1S2ZnOERYeFdsekdsZGNQRnkvbXhiMTk3b1YzUT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207F821FF385403F3874360C0E40BYAPR11MB3207namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c06bcb72-8346-4dcd-88a2-08d889aa22da X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2020 21:05:09.4438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w4/7OWPiQefqI01xa5kyp6uBJaIAYrr4+Zm6EYfJPxAL0rSlz/DzSTN/BV8B3adZbY9owfgoJgOGYWS3lNKZbw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3832 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2020 21:05:16 -0000 --_000_BYAPR11MB3207F821FF385403F3874360C0E40BYAPR11MB3207namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG1vcmUgcmFjZSBjb25kaXRpb24gaXMgbW9yZS1zcGVjaWZpY3MgdnMuIGxlc3Mgc3BlY2lm aWNzLg0KQSBsZXNzLXNwZWNpZmljIFJPQSB3aWxsIGludmFsaWRhdGUgYSBtb3JlIHNwZWNpZmlj IHByZWZpeCB0aGF0IHdvdWxkIGJlIG5vdC1mb3VuZCBpZiB0aGUgUk9BIHdlcmUgdG8gbm90IGV4 aXN0Lg0KSW52YWxpZHMgYXJlIGluY3JlYXNpbmdseSBiZWluZyBkcm9wcGVkLCB3aGVyZWFzIG5v dC1mb3VuZHMgYXJlIG5vdCBkcm9wcGVkIGFuZCB3aWxsIG5vdCBiZSBkcm9wcGVkIGluIHRoZSBm b3Jlc2VlYWJsZSBmdXR1cmUuDQpTbyB0aGlzIG1hdHRlcnMuDQpNb3JlLXNwZWNpZmljIFJPQXMg c2hvdWxkIGJlIHVwZGF0ZWQgYmVmb3JlIGxlc3Mtc3BlY2lmaWMuDQoNClJlZ2FyZHMsDQpKYWtv Yi4NCg0KRnJvbTogU2lkcm9wcyA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgQWxleGFuZGVyIEF6aW1vdg0KU2VudDogU2F0dXJkYXksIE1hcmNoIDIxLCAyMDIwIDEyOjE0 IFBNDQpUbzogUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNvbT4NCkNjOiBTSURSIE9wZXJhdGlvbnMg V0cgPHNpZHJvcHNAaWV0Zi5vcmc+OyBNYXJ0aW4gSG9mZm1hbm4gPG1hcnRpbkBvcGVubmV0bGFi cy5jb20+DQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQteW1iay04MjEwYmlzLTAwLnR4dA0KDQpUaGUgc2VwYXJhdGVkIHJlY29yZHMgZm9y IHY0IGFuZCB2NiBBU1BBIHdlcmUgaW5zcGlyZWQgYnkgdGhlIHByZXZpb3VzIHJlc2VhcmNoIHRo YXQgc2hvd2VkIGEgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBpbiB0aGUgcGVlcmluZyByZWxhdGlv bnMgaW4gdjQgYW5kIHY2IHJlc3BlY3RpdmVseS4NCkkgZGlkIHRoaXMgcmVzZWFyY2ggYSBjb3Vw bGUgb2YgeWVhcnMgYWdvLCBpdCB3aWxsIGJlIGludGVyZXN0aW5nIHRvIGNoZWNrIGlmIHRoZSBz aXR1YXRpb24gaGFzIHNpZ25pZmljYW50bHkgY2hhbmdlZC4NCg0KSSdkIGxpa2UgdG8gZ2V0IHRo ZSBXRyBhdHRlbnRpb24gb24gdGhlIGludHJvZHVjZWQgdXBkYXRlIG9mIFJPQSBwcm9jZXNzaW5n Lg0KVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgUlRSIHByb3RvY29sIHJlbGF0ZWQgdG8gUk9B cyBpcyB2dWxuZXJhYmxlIHRvIHBvc3NpYmxlIHJhY2UgY29uZGl0aW9uczogaWYgdGhlIHByZWZp eCBoYXMgbXVsdGlwbGUgUk9BIHJlY29yZHMgb3IgaXQgY292ZXJpbmcgcHJlZml4ZXMgd2l0aCBk aWZmZXJlbnQgb3JpZ2luIGFzbiB0aGUgc3RhdGUgb2YgdGhlIHBhcnRpYWwgdXBkYXRlIG1heSBs ZWFkIHRvIGludmFsaWRhdGluZyBvZiByZWFsbHkgdmFsaWQgcHJlZml4ZXMuIEhlcmUgaXMgZnJl c2ggc3RhdGlzdGljczoNCsK3ICAxNjE1MyBJUHY0IHByZWZpeGVzIHdpdGggZXF1YWwgKDU0ODYp IG9yIG1vcmUgc3BlY2lmaWMgKDExODcyKSBjb25mbGljdHM7DQrCtyAgMjI1MCBJUHY2IHByZWZp eGVzIHdpdGggZXF1YWwgKDEyMDIpIG9yIG1vcmUgc3BlY2lmaWMgKDExNjQpIGNvbmZsaWN0cy4N Cg0KVGhlIGN1cnJlbnQgcHJvcG9zYWwgYWRkcmVzc2VzIHRoaXMgaXNzdWUgZm9yIEFTUEEgYW5k IFJPQXMgaW4gYSBkaWZmZXJlbnQgd2F5Og0KDQogICogICBGb3IgQVNQQSBhIHNpbmdsZSBQRFUg cGVyIGN1c3RvbWVyIEFTIGlzIG5ldmVsaW5nIHRoZSBpc3N1ZTsNCiAgKiAgIEZvciBST0FzIHRo ZSBkcmFmdCBpbnRyb2R1Y2VzIG9yZGVyaW5nIG9mIHRoZSB1cGRhdGVzICsgc3VnZ2VzdHMgc2Vu ZGluZyB1cGRhdGVzIHdpdGggdGhlIHNhbWUgcHJlZml4IGJhY2sgdG8gYmFjay4NClRoZSB3YXkg Uk9BcyB3aWxsIGJlIHByb2Nlc3NlZCBkZWNyZWFzZXMgdGhlIGNoYW5jZXMgdGhhdCB2YWxpZCBw cmVmaXhlcyB3aWxsIGJlIG1hcmtlZCBhcyBpbnZhbGlkLCBidXQgdGhleSBhcmUgbm90IHplcm8u IE15IHRoaW5raW5nIGlzLCB0aGF0IHNpbmNlIFJUUiBwcm90b2NvbCBpcyBuZWdvdGlhdGluZyBp dHMgdmVyc2lvbiBhdCB0aGUgc3RhcnQgb2YgdGhlIHNlc3Npb24gdGhlcmUgaXMgbm8gbmVlZCB0 byBrZWVwIGZ1bGwgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIHRoZSB3YXkgUk9BcyB3ZXJl IHByb2Nlc3NlZCBwcmV2aW91c2x5LiBJbnN0ZWFkLCB3ZSBjYW4gY2hhbmdlIFJPQSBSVFIgUERV cyBpcyB0aGUgc2FtZSBmYXNoaW9uIGFzIGl0IGlzIGludHJvZHVjZWQgZm9yIEFTUEE6IGEgc2lu Z2xlIFBEVSBmb3IgYSBzZWxlY3RlZCBwcmVmaXggdGhhdCByZXBsYWNlcyBwcmV2aW91cyByZWNv cmRzLg0KDQrQstGCLCAxMCDQvNCw0YAuIDIwMjAg0LMuINCyIDA2OjIyLCBSYW5keSBCdXNoIDxy YW5keUBwc2cuLmNvbTxtYWlsdG86cmFuZHlAcHNnLmNvbT4+Og0KPiBBcyBhIHNlcGFyYXRlIG5v dGUsIEFTUEEgaW4gaXRzIGN1cnJlbnQgZm9ybSBpbmNsdWRlcyB0aGUgYWRkcmVzcw0KPiBmYW1p bHksIGllLiwgaXQgaGFzIGRpZmZlcmVudCBBU1BBIG9iamVjdHMgZm9yIHY0IGFuZCB2Ni4gVGhp cyBpcw0KPiBtaXNzaW5nIGZyb20gdGhlIHByb3Bvc2VkIEFTUEEgUlRSIHBheWxvYWQgUERVLCBi dXQgbHVja2lseSB0aGVyZSBpcw0KPiBlbm91Z2ggemVybyBzcGFjZSB0byBpbmNsdWRlIGl0Lg0K DQppIGJlbGlldmUgdGhpcyBpcyBhZGRyZXNzZWQgaW4gdGhlIGRyYWZ0IG91dCB0b2RheTsgdGhv dWdoIG5vdCBleGFjdGx5DQppbiB0aGUgd2F5IHlvdSBzdWdnZXN0LiAgdGhhbmtzIGFnYWluIGZv ciBwb2ludGluZyB0aGlzIG91dC4NCg0KcmFuZHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClNpZHJvcHMgbWFpbGluZyBsaXN0DQpTaWRyb3BzQGll dGYub3JnPG1haWx0bzpTaWRyb3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaWRyb3BzDQoNCg0KLS0NCkJlc3QgcmVnYXJkcywNCkFsZXhhbmRlciBB emltb3YNCg== --_000_BYAPR11MB3207F821FF385403F3874360C0E40BYAPR11MB3207namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiM0NDFENjE7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjEyNDI1NjU1MDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDQ4 NjY5MDg4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNzQ5 ODQzNzIzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3ODM2MTI4MjQ7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNDQxRDYxIj5PbmUgbW9yZSByYWNl IGNvbmRpdGlvbiBpcyBtb3JlLXNwZWNpZmljcyB2cy4gbGVzcyBzcGVjaWZpY3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6IzQ0MUQ2MSI+QSBsZXNzLXNwZWNpZmljIFJPQSB3aWxsIGludmFsaWRh dGUgYSBtb3JlIHNwZWNpZmljIHByZWZpeCB0aGF0IHdvdWxkIGJlIG5vdC1mb3VuZCBpZiB0aGUg Uk9BIHdlcmUgdG8gbm90IGV4aXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM0NDFENjEiPklu dmFsaWRzIGFyZSBpbmNyZWFzaW5nbHkgYmVpbmcgZHJvcHBlZCwgd2hlcmVhcyBub3QtZm91bmRz IGFyZSBub3QgZHJvcHBlZCBhbmQgd2lsbCBub3QgYmUgZHJvcHBlZCBpbiB0aGUgZm9yZXNlZWFi bGUgZnV0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM0NDFENjEiPlNvIHRoaXMgbWF0dGVy cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNDQxRDYxIj5Nb3JlLXNwZWNpZmljIFJPQXMgc2hv dWxkIGJlIHVwZGF0ZWQgYmVmb3JlIGxlc3Mtc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6IzQ0MUQ2MSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzQ0MUQ2MSI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNDQxRDYxIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojNDQxRDYxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gU2lkcm9w cyAmbHQ7c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5B bGV4YW5kZXIgQXppbW92PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXJjaCAyMSwgMjAy MCAxMjoxNCBQTTxicj4NCjxiPlRvOjwvYj4gUmFuZHkgQnVzaCAmbHQ7cmFuZHlAcHNnLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IFNJRFIgT3BlcmF0aW9ucyBXRyAmbHQ7c2lkcm9wc0BpZXRmLm9y ZyZndDs7IE1hcnRpbiBIb2ZmbWFubiAmbHQ7bWFydGluQG9wZW5uZXRsYWJzLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTaWRyb3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXltYmstODIxMGJpcy0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzZXBhcmF0ZWQmbmJzcDtyZWNvcmRzIGZvciB2NCBhbmQg djYgQVNQQSB3ZXJlIGluc3BpcmVkIGJ5IHRoZSBwcmV2aW91cyByZXNlYXJjaCB0aGF0IHNob3dl ZCBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gdGhlIHBlZXJpbmcgcmVsYXRpb25zIGluIHY0 IGFuZCB2NiByZXNwZWN0aXZlbHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpZCB0aGlzIHJlc2VhcmNoIGEgY291cGxlIG9mIHll YXJzIGFnbywgaXQgd2lsbCBiZSBpbnRlcmVzdGluZyB0byBjaGVjayBpZiB0aGUgc2l0dWF0aW9u IGhhcyBzaWduaWZpY2FudGx5IGNoYW5nZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBsaWtlIHRvIGdldCB0aGUgV0cgYXR0ZW50aW9u IG9uIHRoZSBpbnRyb2R1Y2VkIHVwZGF0ZSBvZiBST0EgcHJvY2Vzc2luZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHZlcnNp b24gb2YgdGhlIFJUUiBwcm90b2NvbCByZWxhdGVkIHRvIFJPQXMgaXMgdnVsbmVyYWJsZSZuYnNw O3RvIHBvc3NpYmxlIHJhY2UgY29uZGl0aW9uczogaWYgdGhlIHByZWZpeCBoYXMgbXVsdGlwbGUg Uk9BIHJlY29yZHMgb3IgaXQgY292ZXJpbmcgcHJlZml4ZXMgd2l0aCBkaWZmZXJlbnQgb3JpZ2lu IGFzbiZuYnNwO3RoZSBzdGF0ZSBvZiB0aGUgcGFydGlhbCB1cGRhdGUgbWF5IGxlYWQgdG8gaW52 YWxpZGF0aW5nDQogb2YgcmVhbGx5IHZhbGlkIHByZWZpeGVzLiBIZXJlIGlzIGZyZXNoIHN0YXRp c3RpY3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7C tzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+MTYxNTMgSVB2NCBwcmVmaXhlcyB3 aXRoIGVxdWFsICg1NDg2KSBvciBtb3JlIHNwZWNpZmljICgxMTg3MikgY29uZmxpY3RzOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjQ3LjI1cHQ7dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjIyNTAgSVB2NiBwcmVmaXhlcyB3aXRoIGVxdWFsICgxMjAyKSBvciBtb3JlIHNw ZWNpZmljICgxMTY0KSBjb25mbGljdHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHByb3Bvc2FsIGFkZHJlc3NlcyZuYnNw O3RoaXMgaXNzdWUgZm9yIEFTUEEgYW5kIFJPQXMgaW4gYSBkaWZmZXJlbnQgd2F5OjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpGb3IgQVNQQSBhIHNpbmdsZSBQRFUg cGVyIGN1c3RvbWVyIEFTIGlzIG5ldmVsaW5nIHRoZSBpc3N1ZTs8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpGb3IgUk9BcyB0 aGUgZHJhZnQgaW50cm9kdWNlcyBvcmRlcmluZyBvZiB0aGUgdXBkYXRlcyZuYnNwOysgc3VnZ2Vz dHMgc2VuZGluZyB1cGRhdGVzIHdpdGggdGhlIHNhbWUgcHJlZml4IGJhY2sgdG8gYmFjay48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSB3YXkgUk9BcyB3aWxsIGJlIHByb2Nlc3NlZCBkZWNyZWFzZXMmbmJzcDt0aGUgY2hhbmNlcyB0 aGF0IHZhbGlkIHByZWZpeGVzIHdpbGwgYmUgbWFya2VkIGFzIGludmFsaWQsIGJ1dCB0aGV5IGFy ZSBub3QgemVyby4gTXkgdGhpbmtpbmcgaXMsIHRoYXQgc2luY2UgUlRSIHByb3RvY29sIGlzIG5l Z290aWF0aW5nIGl0cyB2ZXJzaW9uIGF0IHRoZSBzdGFydCBvZiB0aGUgc2Vzc2lvbiB0aGVyZSBp cyBubyBuZWVkIHRvDQoga2VlcCBmdWxsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUg d2F5IFJPQXMgd2VyZSBwcm9jZXNzZWQgcHJldmlvdXNseS4gSW5zdGVhZCwgd2UgY2FuIGNoYW5n ZSBST0EgUlRSIFBEVXMgaXMgdGhlIHNhbWUgZmFzaGlvbiBhcyBpdCBpcyBpbnRyb2R1Y2VkIGZv ciBBU1BBOiBhIHNpbmdsZSBQRFUgZm9yIGEgc2VsZWN0ZWQgcHJlZml4IHRoYXQgcmVwbGFjZXMg cHJldmlvdXMgcmVjb3Jkcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPtCy0YIsIDEwINC80LDRgC4gMjAyMCDQsy4g0LIgMDY6MjIsIFJhbmR5IEJ1c2ggJmx0 OzxhIGhyZWY9Im1haWx0bzpyYW5keUBwc2cuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmFuZHlAcHNn Li5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgQXMgYSBzZXBhcmF0ZSBub3RlLCBBU1BBIGluIGl0cyBjdXJy ZW50IGZvcm0gaW5jbHVkZXMgdGhlIGFkZHJlc3M8YnI+DQomZ3Q7IGZhbWlseSwgaWUuLCBpdCBo YXMgZGlmZmVyZW50IEFTUEEgb2JqZWN0cyBmb3IgdjQgYW5kIHY2LiBUaGlzIGlzPGJyPg0KJmd0 OyBtaXNzaW5nIGZyb20gdGhlIHByb3Bvc2VkIEFTUEEgUlRSIHBheWxvYWQgUERVLCBidXQgbHVj a2lseSB0aGVyZSBpczxicj4NCiZndDsgZW5vdWdoIHplcm8gc3BhY2UgdG8gaW5jbHVkZSBpdC48 YnI+DQo8YnI+DQppIGJlbGlldmUgdGhpcyBpcyBhZGRyZXNzZWQgaW4gdGhlIGRyYWZ0IG91dCB0 b2RheTsgdGhvdWdoIG5vdCBleGFjdGx5PGJyPg0KaW4gdGhlIHdheSB5b3Ugc3VnZ2VzdC4mbmJz cDsgdGhhbmtzIGFnYWluIGZvciBwb2ludGluZyB0aGlzIG91dC48YnI+DQo8YnI+DQpyYW5keTxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KU2lkcm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U2lkcm9wc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlNpZHJvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFsZXhhbmRlciBBemltb3Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR11MB3207F821FF385403F3874360C0E40BYAPR11MB3207namp_-- From nobody Sun Nov 15 20:18:10 2020 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 B43483A1060 for ; Sun, 15 Nov 2020 20:18:08 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgSq7Xn6C7JW for ; Sun, 15 Nov 2020 20:18:07 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980C13A1056 for ; Sun, 15 Nov 2020 20:18:07 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-196-134.hsd1.ma.comcast.net [73.47.196.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 3A23F139A9; Mon, 16 Nov 2020 04:18:03 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 359652019F8E25; Sun, 15 Nov 2020 23:18:07 -0500 (EST) Date: Sun, 15 Nov 2020 23:18:07 -0500 From: Rob Austein To: Job Snijders Cc: sidrops@ietf.org In-Reply-To: <20201030163827.GE34637@bench.sobornost.net> References: <20201030163827.GE34637@bench.sobornost.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20201116041807.359652019F8E25@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] notes on rsync --delete (rrdp withdraw), and garbage collection X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 04:18:09 -0000 [Apologies for belated response, saw this while catching before today's meeting (for some definition of "today")] Job, I agree that flushing data solely because rsync or RRDP said to do so is a bad idea, but I think that outlawing rsync --delete or RRDP withdraw is going a bit overboard in the other direction. The operative word here is "solely". At least in my implementation, rsync/RRDP deletion only remove data from the pre-validation cache; there's a separate cache of previously-validated data, and I use both of them when constructing the output of the current validation cycle. End result is that we only gc objects that have both been deleted and have failed to pass validation, which (still) seems about right to me. From nobody Sun Nov 15 20:23:17 2020 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 C92DA3A104B for ; Sun, 15 Nov 2020 20:23:15 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 mH98CL0w0wzv for ; Sun, 15 Nov 2020 20:23:13 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 42D883A104A for ; Sun, 15 Nov 2020 20:23:12 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id f11so23318805lfs.3 for ; Sun, 15 Nov 2020 20:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TytzL8Vy9bss4/HcnEg4zthqdh20yrYQP0OGpG7mQbs=; b=vhiSskgwHj63U1DTWpxql2ob1U8IGwOazRs23mJzKxA+jsIsvnMh7hIm3Db0qtSHZh bi9KxS1Ru5Z2FyoKX33heOF4eSst7E/aSKoPGdHUSLilPGq2lACOnKhUuFK59QwsH53q AjtRstSSEjjVh1hVyxzHHvpbd2q6/nN+QGhMIknxytXVtsbr9960dDYeEBYmKKaJmrVf HGl+fRoc7kxm0diX8s6LQKw4tEtGyn9gSV4lJCJIVYk24/4bcd7Qo82yOefMe2WkfWD8 45rPHJtcxkqeJvn5DS5zgdLCUk+j7alifkvCLMZBjmvH1cOoKptwjFZ5/UeYFUH3zjdN mwrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TytzL8Vy9bss4/HcnEg4zthqdh20yrYQP0OGpG7mQbs=; b=szA25cMjIP+k72Rc6M/h7BSTy+7WpKQ7kVHPUnW9yWxVZRPzH1Xi/JqOWgIafUM7NN bnWpQ0gLNopPMYERgwfnDqJx84vU6lhjUqGj/FbicOPR79sEyKAVP8rNHoHisBz037SA aRtrqQewPL2HMgba3+cMESoYJovqRrlUD/9InYDdIDuXSX5qLk86sgTqxIRtM67xou3U PRH5R+HjWm/qdBxul1cmT47LKGJTJHAl6wK09zgLTkszp3l4zPivOBwaJ/SyEZFjqOZg Cz7YJljhew+LFgX0sc5jJKOkGpl2Vf+Nk/GbZKiq6tlwcgnHkHMlbgNA1RrS9s2/VsBP Dt1w== X-Gm-Message-State: AOAM533foUc85+u2Aka0wUa6V+6/7ZyC+b6VmtsCHunp/gKXqF/y2JLs T7ZTuq+PY+mTbU8HUSHjgudTj8yaN1yQDjD4+6FJwv5FvLU= X-Google-Smtp-Source: ABdhPJznaadRCnwMkG8hf2zvj1PId2mSH0enErTpL0OnYkRmsdzjEdXQiwxyupgvgu4xLl3CLDJVaw++lBg0vXWJ+Zc= X-Received: by 2002:a19:48d4:: with SMTP id v203mr745667lfa.169.1605500590465; Sun, 15 Nov 2020 20:23:10 -0800 (PST) MIME-Version: 1.0 References: <20201030163827.GE34637@bench.sobornost.net> <20201116041807.359652019F8E25@minas-ithil.hactrn.net> In-Reply-To: <20201116041807.359652019F8E25@minas-ithil.hactrn.net> From: George Michaelson Date: Mon, 16 Nov 2020 14:22:59 +1000 Message-ID: To: Rob Austein Cc: Job Snijders , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] notes on rsync --delete (rrdp withdraw), and garbage collection X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 04:23:16 -0000 I like this behaviour, and I continue to use your validator for the enhanced debugging it gives on the states of the repo. I could quibble about colour marking yellow on some stuff, but overall, "I like your approach" -G On Mon, Nov 16, 2020 at 2:18 PM Rob Austein wrote: > > [Apologies for belated response, saw this while catching before > today's meeting (for some definition of "today")] > > Job, I agree that flushing data solely because rsync or RRDP said to > do so is a bad idea, but I think that outlawing rsync --delete or RRDP > withdraw is going a bit overboard in the other direction. > > The operative word here is "solely". At least in my implementation, > rsync/RRDP deletion only remove data from the pre-validation cache; > there's a separate cache of previously-validated data, and I use both > of them when constructing the output of the current validation cycle. > > End result is that we only gc objects that have both been deleted and > have failed to pass validation, which (still) seems about right to me. > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Nov 16 00:35:19 2020 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 37F193A0DD9 for ; Sun, 15 Nov 2020 13:22:01 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zprVVaqb6q8G for ; Sun, 15 Nov 2020 13:21:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9DDC03A0DD8 for ; Sun, 15 Nov 2020 13:21:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kePTA-0008AF-MO; Sun, 15 Nov 2020 21:21:56 +0000 Date: Sun, 15 Nov 2020 13:21:56 -0800 Message-ID: From: Randy Bush To: "Jakob Heitz (jheitz)" Cc: Alexander Azimov , SIDR Operations WG , Martin Hoffmann In-Reply-To: References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: X-Mailman-Approved-At: Mon, 16 Nov 2020 00:35:17 -0800 Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2020 21:22:01 -0000 > One more race condition is more-specifics vs. less specifics. > A less-specific ROA will invalidate a more specific prefix that would > be not-found if the ROA were to not exist. > Invalids are increasingly being dropped, whereas not-founds are not > dropped and will not be dropped in the foreseeable future. > So this matters. > More-specific ROAs should be updated before less-specific. rtfd 11. ROA PDU Race Minimization When a cache is sending ROA PDUs to the router, especially during an initial full load, two undesirable race conditions are possible: Break Before Make: For some prefix P, an AS may announce two (or more) ROAs because they are in the process of changing what provider AS is announcing P. This is is a case of "make before break." If a cache is feeding a router and sends the one not yet in service a significant time before sending the one currently in service, then BGP data could be marked invalid during the interval. To minimize that interval, the cache SHOULD announce all ROAs for the same prefix as close to sequentially as possible. Shorter Prefix First: If an AS has issued a ROA for P0, and another AS (likely their customer) has issued a ROA for P1 which is a sub- prefix of P0, a router which receives the ROA for P0 before that for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the cache SHOULD announce the sub-prefix P1 before the covering prefix P0. From nobody Mon Nov 16 16:51:36 2020 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 B14AC3A17AA for ; Mon, 16 Nov 2020 16:51:34 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 eNo_3rB-cRVj for ; Mon, 16 Nov 2020 16:51:32 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 DB8E33A17A6 for ; Mon, 16 Nov 2020 16:51:31 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id r9so27773938lfn.11 for ; Mon, 16 Nov 2020 16:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=RF8vMVRuwr6I/N6S0fN3BNnzNPcHmZ+t+ZKsb5MYP4U=; b=Z5RbvjwKqa+cNUtnD4v4Nq/zU6M6rbi/jVBBnjlVJmNqLS5lwu/ryQtaKb2EKZtugy 39fZ9idqh6ftpZF0ObBwdSHWanX9SIEzrKoWtQgnLKjhTKjlIryLlFjI0LNp028AJPod 1VTb2OQJKipqwiukzJCrpkl8JK/1sU1YHuvhoAdx4MjB1h7FRmptmr8ned5HAk9nAaaQ jqCjWDdNme3pOiJVkL/nFSMxYEcWIKm4fM8C4xOHKCCKGZ0J9xWBS6jkl8uvOCWZnz3i Ucf4B/P66U/VaA9COEps4wgza2XBkMOXR/CZgHoWbfDxCOGn2GszqeZqW5jhwFxOQ4Wv CcIw== 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=RF8vMVRuwr6I/N6S0fN3BNnzNPcHmZ+t+ZKsb5MYP4U=; b=If7NB+lzcB8HT9NCnHBmz3zUCuo7ManH+g8xe68w6NT6vMEC8FqXTlanidSNdPxJXI Q9eMd41hZLDTknTf6WMPG+ZDwUzSEHJPruATkuNHagTCx6kh9SybPURfLoUaaEcYUKYT ic8wCZd3g1SXmWgf6/g091fldH5mDFaak8G5+yLkAFTL4yyYTloV+39EtiSWxHD9QqXv 3Xu4v+/+B7MEcZFbNx2MtxGpoiUYbPX+09sFEaEPbG3DxrLBisq59wbIjiw1d4d1GPtR FdLdqVefsiLDr2eyRxD9LO9V/6KvJ5coR8cnJ8iGQKjqEhSjAD+gM4tpOzc0xiR7w24a 4Zww== X-Gm-Message-State: AOAM530l++dKkW1BMa61mP9LnxiS5ueXitRbUEKAg44TAW+SDssS+jAi +vWChSa4kH9xgaCzyVlQcK+81MYcJ8FL8OwfDKhzCBDSSghmDQ== X-Google-Smtp-Source: ABdhPJwoxdyO4ZiKNGdugGetcPev3YwOmdIwzjla/EfTSNEK++fmDfoL4UCdgpJQwfEwZKYwMdx07eMeGAY9aBwOK3E= X-Received: by 2002:a19:e059:: with SMTP id g25mr790795lfj.584.1605574288903; Mon, 16 Nov 2020 16:51:28 -0800 (PST) MIME-Version: 1.0 From: George Michaelson Date: Tue, 17 Nov 2020 10:51:18 +1000 Message-ID: To: SIDROps Chairs , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] request for adoption: draft-michaelson-rpki-rta-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 00:51:35 -0000 I would like to propose https://tools.ietf.org/html/draft-michaelson-rpki-rta-02 for adoption by SIDROPS. cheers -George From nobody Tue Nov 17 00:21:30 2020 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 C7E473A07C0; Tue, 17 Nov 2020 00:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 cpDvK8w2AIaO; Tue, 17 Nov 2020 00:21:24 -0800 (PST) Received: from out20-61.mail.aliyun.com (out20-61.mail.aliyun.com [115.124.20.61]) (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 610113A07DE; Tue, 17 Nov 2020 00:21:17 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06546368|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.436852-0.018783-0.544365; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047199; MF=madi@rpstir.net; NM=1; PH=DS; RN=7; RT=7; SR=0; TI=SMTPD_---.IxmCWRO_1605601266; Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.IxmCWRO_1605601266) by smtp.aliyun-inc.com(10.147.42.22); Tue, 17 Nov 2020 16:21:07 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Di Ma In-Reply-To: Date: Tue, 17 Nov 2020 16:21:05 +0800 Cc: SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Chris Morrow , Melchior Aelmans Content-Transfer-Encoding: quoted-printable Message-Id: <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> References: <87imbybjne.wl-morrowc@ops-netman.net> To: Christopher Morrow X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 08:21:28 -0000 Chris, We authors have removed AS0 usecase for RUSH re Job=E2=80=99s concern. And we also made some editorial change to articulate HTTPs as transport = where needed, re Yunan=E2=80=99s suggestion. Please consider whether it is ready to be adopted. Thanks. Di > 2020=E5=B9=B410=E6=9C=8822=E6=97=A5 22:42=EF=BC=8CChristopher Morrow = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Howdy folks, > We had 2 authors and 1 not-author reply here... Are there other folks > interested in moving this forward? or working on this in the WG over > the next few meeting slots/periods? >=20 > -chris >=20 > On Fri, Oct 9, 2020 at 6:51 AM Di Ma wrote: >>=20 >> Yunan, >>=20 >>> 2020=E5=B9=B410=E6=9C=889=E6=97=A5 14:41=EF=BC=8CGuyunan = =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> Seems quite useful for local management of validated cache. A small = suggestion, maybe the authors can further clarify the use of HTTP and = HTTPs, whether HTTPs is mandatory, or it=E2=80=99s optional using either = HTTP only or HTTPs. >>=20 >>=20 >> A very good catch. >>=20 >> I think https is default at least as it is used in the name of this = draft literally. >>=20 >> But I see a potential that http can work if IPsec has been = established between two cache servers. >>=20 >> We can discuss it further if adopted as a WG item. >>=20 >> Di >>=20 >>>=20 >>> Support adoption. >>>=20 >>> BR, >>>=20 >>> Yunan >>>=20 >>> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of = Melchior Aelmans >>> Sent: Thursday, October 1, 2020 12:51 AM >>> To: Chris Morrow >>> Cc: SIDROps Chairs ; SIDR Operations WG = ; sidrops-ads@ietf.org >>> Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS = 10/12/2020 (Oct 12th) >>>=20 >>> As a co-author I support adoption by the WG. >>>=20 >>> THanks! >>> Melchior >>>=20 >>> On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow = wrote: >>>=20 >>> Howdy, >>>=20 >>> Please consider this the start of a WG Adoption call for the subject >>> draft, the abstract of which is: >>>=20 >>> "This document defines a method for transferring RPKI validated = cache >>> update information in JSON object format over HTTPs." >>>=20 >>> The URL of which is: >>> https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 >>>=20 >>> Please give this a read-through and consider if the work is = appropriate >>> for the WG to work on. >>>=20 >>> thanks! >>> -chris >>> co-chair-persona >>>=20 >>> _______________________________________________ >>> 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 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Nov 17 03:59:22 2020 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 17BB73A1183; Tue, 17 Nov 2020 03:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 9OrM3XVR4oUY; Tue, 17 Nov 2020 03:59:16 -0800 (PST) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FBA3A1131; Tue, 17 Nov 2020 03:59:15 -0800 (PST) Received: from mail.ops-netman.net (mail.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id E89363C1E1E; Tue, 17 Nov 2020 11:59:13 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id BFF4A23D; Tue, 17 Nov 2020 11:59:13 +0000 (UTC) Date: Tue, 17 Nov 2020 11:59:13 +0000 Message-ID: <87a6vgfb3i.wl-morrowc@ops-netman.net> From: Chris Morrow To: Di Ma Cc: Christopher Morrow , SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Chris Morrow , Melchior Aelmans In-Reply-To: <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 11:59:21 -0000 On Tue, 17 Nov 2020 08:21:05 +0000, Di Ma wrote: > > Chris, > > We authors have removed AS0 usecase for RUSH re Job$B!G(Bs concern. > > And we also made some editorial change to articulate HTTPs as transport where needed, re Yunan$B!G(Bs suggestion. > > Please consider whether it is ready to be adopted. > ok, awesome. Can yunan/job speak up if their concerns are NOT met at this time? If they don't speak up in an hour I think we can consider this adopted and ask the authors to submit the appropriately re-named draft :) -chris > Thanks. > > Di > > > > 2020$BG/(B10$B7n(B22$BF|(B 22:42$B!$(BChristopher Morrow $B > > > Howdy folks, > > We had 2 authors and 1 not-author reply here... Are there other folks > > interested in moving this forward? or working on this in the WG over > > the next few meeting slots/periods? > > > > -chris > > > > On Fri, Oct 9, 2020 at 6:51 AM Di Ma wrote: > >> > >> Yunan, > >> > >>> 2020$BG/(B10$B7n(B9$BF|(B 14:41$B!$(BGuyunan $B >>> > >>> Seems quite useful for local management of validated cache. A small suggestion, maybe the authors can further clarify the use of HTTP and HTTPs, whether HTTPs is mandatory, or it$B!G(Bs optional using either HTTP only or HTTPs. > >> > >> > >> A very good catch. > >> > >> I think https is default at least as it is used in the name of this draft literally. > >> > >> But I see a potential that http can work if IPsec has been established between two cache servers. > >> > >> We can discuss it further if adopted as a WG item. > >> > >> Di > >> > >>> > >>> Support adoption. > >>> > >>> BR, > >>> > >>> Yunan > >>> > >>> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Melchior Aelmans > >>> Sent: Thursday, October 1, 2020 12:51 AM > >>> To: Chris Morrow > >>> Cc: SIDROps Chairs ; SIDR Operations WG ; sidrops-ads@ietf.org > >>> Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) > >>> > >>> As a co-author I support adoption by the WG. > >>> > >>> THanks! > >>> Melchior > >>> > >>> On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow wrote: > >>> > >>> Howdy, > >>> > >>> Please consider this the start of a WG Adoption call for the subject > >>> draft, the abstract of which is: > >>> > >>> "This document defines a method for transferring RPKI validated cache > >>> update information in JSON object format over HTTPs." > >>> > >>> The URL of which is: > >>> https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 > >>> > >>> Please give this a read-through and consider if the work is appropriate > >>> for the WG to work on. > >>> > >>> thanks! > >>> -chris > >>> co-chair-persona > >>> > >>> _______________________________________________ > >>> 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 > >> > >> _______________________________________________ > >> 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 Tue Nov 17 06:05:27 2020 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 16B733A11EA; Tue, 17 Nov 2020 06:05:26 -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, SPF_HELO_NONE=0.001, 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 LHusrkPVMJo3; Tue, 17 Nov 2020 06:05:24 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679983A10C5; Tue, 17 Nov 2020 06:05:24 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 3F88F22012F; Tue, 17 Nov 2020 14:05:20 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 332763a6; Tue, 17 Nov 2020 14:05:17 +0000 (UTC) Date: Tue, 17 Nov 2020 14:05:17 +0000 From: Job Snijders To: Chris Morrow Cc: Di Ma , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , SIDROps Chairs , Melchior Aelmans , Christopher Morrow Message-ID: References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a6vgfb3i.wl-morrowc@ops-netman.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 14:05:26 -0000 On Tue, Nov 17, 2020 at 11:59:13AM +0000, Chris Morrow wrote: > Can job speak up if their concerns are NOT met at this time? > > If they don't speak up in an hour I think we can consider this adopted > and ask the authors to submit the appropriately re-named draft :) Eh.... a new IETF rule? :-) I am not a fan of adopting this draft, I think the working this working group's sparse resources should be allocated towards other work. In the operational field, people have been transporting SLURM files for years over HTTPS, SSH, whatever is suitable. It seems awkward to describe that a SLURM file can be transported over HTTPS... it seems ... obvious? The security section of RFC 8416 already establishes "Additionally, each RP using SLURM MUST ensure the authenticity and integrity of any SLURM file that it uses." The described use-cases erode potential security, specifically: "A small site or enterprise network MAY also use RUSH by synchronizing with a third-party RPKI cache provider over external networks." Who are those small networks? Are the authors attempting to speak for a silent majority? As far as I know small networks have just as much access to tools to validate RPKI data as big networks. What even *is* a 'small' network? Seems pedantic to a-priori diminish/downgrade a small network's access to secure routing by suggesting they should use an inferior substitute instead of the real thing, when everyone knows you can run a RPKI validator on a raspberry pi or smaller. Furthermore I do not believe that the SLURM format is optimal to distribute Validated RPKI cache data. It is inefficient from a size perspective. The SLURM format makes a lot of sense for describing 'Local RPKI exceptions', but the datastructure seems less suitable as the RPKI grows in size. Many operators *already today* are using different formats, so why not either look to standardize the format that actually is in use in the wild, or optimize towards something that is better than what is already used in the wild? summary: 1) SLURM RFC already covers important aspects of SLURM, no novelty 2) SLURM format seems less suitable than already-deployed JSON formats 3) Suggestion to research the already-deployed-formats and standardize those, or optimize those formats to improve RPKI cache distribution. Kind regards, Job From nobody Tue Nov 17 22:48:52 2020 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 A162B3A0BB2; Tue, 17 Nov 2020 22:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 wma5Vzw-t8W5; Tue, 17 Nov 2020 22:48:48 -0800 (PST) Received: from out20-38.mail.aliyun.com (out20-38.mail.aliyun.com [115.124.20.38]) (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 61B833A0BA4; Tue, 17 Nov 2020 22:48:41 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1863876|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.519537-0.025402-0.455061; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047194; MF=madi@rpstir.net; NM=1; PH=DS; RN=8; RT=8; SR=0; TI=SMTPD_---.IyCGFKu_1605682113; Received: from 172.20.10.2(mailfrom:madi@rpstir.net fp:SMTPD_---.IyCGFKu_1605682113) by smtp.aliyun-inc.com(10.147.41.158); Wed, 18 Nov 2020 14:48:34 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Di Ma In-Reply-To: Date: Wed, 18 Nov 2020 14:48:33 +0800 Cc: Chris Morrow , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , SIDROps Chairs , Melchior Aelmans , Christopher Morrow Content-Transfer-Encoding: quoted-printable Message-Id: References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> To: Job Snijders X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 06:48:51 -0000 Job, > 2020=E5=B9=B411=E6=9C=8817=E6=97=A5 22:05=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Tue, Nov 17, 2020 at 11:59:13AM +0000, Chris Morrow wrote: >> Can job speak up if their concerns are NOT met at this time? >>=20 >> If they don't speak up in an hour I think we can consider this = adopted >> and ask the authors to submit the appropriately re-named draft :) >=20 > Eh.... a new IETF rule? :-) >=20 > I am not a fan of adopting this draft, I think the working this = working > group's sparse resources should be allocated towards other work. In = the > operational field, people have been transporting SLURM files for years > over HTTPS, SSH, whatever is suitable. It seems awkward to describe = that > a SLURM file can be transported over HTTPS... it seems ... obvious? Happy to know people have been transporting SLURM files, which makes it = necessary to standardize RUSH for inter-operation. I think this argument of yours is a kinda support for adoption of RUSH = not the other way around. >=20 > The security section of RFC 8416 already establishes "Additionally, = each > RP using SLURM MUST ensure the authenticity and integrity of any SLURM > file that it uses." The described use-cases erode potential security, > specifically: >=20 > "A small site or enterprise network MAY also use RUSH by > synchronizing with a third-party RPKI cache provider over external > networks." >=20 > Who are those small networks? Are the authors attempting to speak for = a > silent majority? As far as I know small networks have just as much > access to tools to validate RPKI data as big networks. What even *is* = a > 'small' network? Seems pedantic to a-priori diminish/downgrade a small > network's access to secure routing by suggesting they should use an > inferior substitute instead of the real thing, when everyone knows you > can run a RPKI validator on a raspberry pi or smaller. We don=E2=80=99t make decision for operators but offer them a choice = that they can outsource valiation if they have no problem with this = fashion. >=20 > Furthermore I do not believe that the SLURM format is optimal to > distribute Validated RPKI cache data. It is inefficient from a size > perspective. The SLURM format makes a lot of sense for describing = 'Local > RPKI exceptions', but the datastructure seems less suitable as the = RPKI > grows in size. I don=E2=80=99t agree in terms of SIZE. The beauty of SLURM file is that it naturally supports incremental = update. >=20 > Many operators *already today* are using different formats, so why not > either look to standardize the format that actually is in use in the > wild, or optimize towards something that is better than what is = already > used in the wild? >=20 I am pleased to know those operators have *already today* used some = other formats that works for their networking condition. If they want a standardized format, it is fine and good. But this = won=E2=80=99t necessarily stop RUSH from being a WG item. =20 Di From nobody Tue Nov 17 22:54:21 2020 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 65C903A0BDB; Tue, 17 Nov 2020 22:54:19 -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, 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 6G67ZeY-S1M2; Tue, 17 Nov 2020 22:54:18 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6C23A0BD7; Tue, 17 Nov 2020 22:54:18 -0800 (PST) Received: from [10.0.0.129] (unknown [23.138.112.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 542CC540121; Wed, 18 Nov 2020 01:54:15 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Jared Mauch In-Reply-To: Date: Wed, 18 Nov 2020 01:54:14 -0500 Cc: Job Snijders , SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Melchior Aelmans Content-Transfer-Encoding: quoted-printable Message-Id: <95A9B418-370C-43F5-8466-3FC157C3F914@puck.nether.net> References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> To: Di Ma X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 06:54:20 -0000 > On Nov 18, 2020, at 1:48 AM, Di Ma wrote: >=20 > We don=E2=80=99t make decision for operators but offer them a choice = that they can outsource valiation if they have no problem with this = fashion. Is it perhaps better to think about offering validation as a service to = people who can=E2=80=99t or are unable to run their own validators? (Thinking of how people may decide to use an off-network DNS resolver so = they don=E2=80=99t need to operate one themselves). Perhaps this is something larger networks may want to offer to their = customers, similar to how they may offer NTP, DNS and other services? - Jared= From nobody Tue Nov 17 23:03:00 2020 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 814113A0B8B; Tue, 17 Nov 2020 23:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 lQntdHgUlCGg; Tue, 17 Nov 2020 23:02:57 -0800 (PST) Received: from out20-73.mail.aliyun.com (out20-73.mail.aliyun.com [115.124.20.73]) (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 5A0EB3A0C0F; Tue, 17 Nov 2020 23:02:50 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1164834|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0132064-0.00113803-0.985656; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047201; MF=madi@rpstir.net; NM=1; PH=DS; RN=7; RT=7; SR=0; TI=SMTPD_---.IyCWIoO_1605682964; Received: from 172.20.10.2(mailfrom:madi@rpstir.net fp:SMTPD_---.IyCWIoO_1605682964) by smtp.aliyun-inc.com(10.147.43.230); Wed, 18 Nov 2020 15:02:46 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Di Ma In-Reply-To: <95A9B418-370C-43F5-8466-3FC157C3F914@puck.nether.net> Date: Wed, 18 Nov 2020 15:02:44 +0800 Cc: "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , SIDROps Chairs , Melchior Aelmans , Job Snijders Content-Transfer-Encoding: quoted-printable Message-Id: References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> <95A9B418-370C-43F5-8466-3FC157C3F914@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 07:03:00 -0000 Jared, Thanks for your suggestion. > 2020=E5=B9=B411=E6=9C=8818=E6=97=A5 14:54=EF=BC=8CJared Mauch = =E5=86=99=E9=81=93=EF=BC=9A >=20 >=20 >=20 >> On Nov 18, 2020, at 1:48 AM, Di Ma wrote: >>=20 >> We don=E2=80=99t make decision for operators but offer them a choice = that they can outsource valiation if they have no problem with this = fashion. >=20 > Is it perhaps better to think about offering validation as a service = to people who can=E2=80=99t or are unable to run their own validators? >=20 > (Thinking of how people may decide to use an off-network DNS resolver = so they don=E2=80=99t need to operate one themselves). >=20 > Perhaps this is something larger networks may want to offer to their = customers, similar to how they may offer NTP, DNS and other services? I think this is a reasonable usecase which can be added into RUSH = document. And RUSH can also be used within a large ISP to distribute cache to RTR = servers deployed in different ASes. Di From nobody Tue Nov 17 23:49:15 2020 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 971663A0E53; Tue, 17 Nov 2020 23:49:12 -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, 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 ZC2NMroBo3Jd; Tue, 17 Nov 2020 23:49:11 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F2A3A1024; Tue, 17 Nov 2020 23:49:11 -0800 (PST) Received: by puck.nether.net (Postfix, from userid 162) id 91A46540118; Wed, 18 Nov 2020 02:49:10 -0500 (EST) Date: Wed, 18 Nov 2020 02:49:10 -0500 From: Jared Mauch To: Di Ma Cc: Jared Mauch , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , SIDROps Chairs , Melchior Aelmans , Job Snijders Message-ID: <20201118074910.GC2366865@puck.nether.net> References: <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> <95A9B418-370C-43F5-8466-3FC157C3F914@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 07:49:14 -0000 On Wed, Nov 18, 2020 at 03:02:44PM +0800, Di Ma wrote: > Jared, > > Thanks for your suggestion. > > > 2020年11月18日 14:54，Jared Mauch 写道： > > > > > > > >> On Nov 18, 2020, at 1:48 AM, Di Ma wrote: > >> > >> We don’t make decision for operators but offer them a choice that they can outsource valiation if they have no problem with this fashion. > > > > Is it perhaps better to think about offering validation as a service to people who can’t or are unable to run their own validators? > > > > (Thinking of how people may decide to use an off-network DNS resolver so they don’t need to operate one themselves). > > > > Perhaps this is something larger networks may want to offer to their customers, similar to how they may offer NTP, DNS and other services? > > I think this is a reasonable usecase which can be added into RUSH document. > > And RUSH can also be used within a large ISP to distribute cache to RTR servers deployed in different ASes. While an idea, how i copy data internally between my infrastructure doesn't always need to become a standard. In that regard I tend to lean towards the comments from Job. I may clone VMs, use rsync, ftp, scp, webdav, SMB to copy data around internally. My [dirty] incantations don't need to be all standards based. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Wed Nov 18 00:04:26 2020 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 391F73A14E0; Wed, 18 Nov 2020 00:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 uo8t8fahx-2n; Wed, 18 Nov 2020 00:04:16 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0563A14B2; Wed, 18 Nov 2020 00:04:15 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id ECAF160100; Wed, 18 Nov 2020 08:04:12 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1605686651; bh=fWUzshm/K2NRn/l/qfDrDbiIukDmws0UDvWIvkWTeQc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=TeQ0rzxp8atq+fgQcd+uh4At1PfPRfw0q/VrtC3XOwqcDxTpFRSdfg0nnSNppA/Im HbWZEUfMTpD1khWuZ826QcL/1JSX04I7pbnzO1YK+ee7JkMplLxTn+RIxjwnp6fYES tHTTWqIkgfiyENE8O2caMjnkLeJ7p0LPpULeAvMoNM97f772hoNT7xxYtr0rCmRiaH YrR09xPL8UMnz4ygO8m4neSxq4coO6kGF4+9xTN6UW5bcXP5OPXrs3gbrtITmy9YoG BzVEYe5E0Ce3JOI6H/mOb/NFl5+NSJT2iOhMLkhUPc8+TJ2z34nWtlXgoCKggacC0I /lYfJ0155BNOQ== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 18 Nov 2020 09:04:06 +0100 Cc: Jared Mauch , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , SIDROps Chairs , Melchior Aelmans , Job Snijders Content-Transfer-Encoding: quoted-printable Message-Id: <6C07A611-5D8F-4668-BF2F-16CD48C77C2A@nlnetlabs.nl> References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> <95A9B418-370C-43F5-8466-3FC157C3F914@puck.nether.net> To: Di Ma Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 08:04:25 -0000 Hi, > On 18 Nov 2020, at 08:02, Di Ma wrote: >=20 > Jared, >=20 > Thanks for your suggestion. >=20 >> 2020=E5=B9=B411=E6=9C=8818=E6=97=A5 14:54=EF=BC=8CJared Mauch = =E5=86=99=E9=81=93=EF=BC=9A >>=20 >>=20 >>=20 >>> On Nov 18, 2020, at 1:48 AM, Di Ma wrote: >>>=20 >>> We don=E2=80=99t make decision for operators but offer them a choice = that they can outsource valiation if they have no problem with this = fashion. >>=20 >> Is it perhaps better to think about offering validation as a service = to people who can=E2=80=99t or are unable to run their own validators? >>=20 >> (Thinking of how people may decide to use an off-network DNS resolver = so they don=E2=80=99t need to operate one themselves). >>=20 >> Perhaps this is something larger networks may want to offer to their = customers, similar to how they may offer NTP, DNS and other services? >=20 > I think this is a reasonable usecase which can be added into RUSH = document. >=20 > And RUSH can also be used within a large ISP to distribute cache to = RTR servers deployed in different ASes. I believe that for this use case it would be better to standardise the = (signed) json emitted by validators so that it can be used by rpki-rtr = implementations (go-rtr, and the one we are building rtrtr). That way people can have interchangeable validators and RTR = implementations. With signing one can distribute the data safely even = over public internet which can help centralised *own* management. I believe that outsourcing the validation and using someone else's RP = feed for their RTR is ill advised, yet it may be something that people = choose to do regardless. As far as RUSH is concerned I am still on the fence about it, but I see = a possible use case in having an API to push updated SLURM settings in a = local RP, more finegrained, e.g. allow listing things, adding/removing = one or more exceptions as a delta, rather than just giving the RP a = complete new file. But.. that would be a different thing altogether, and = I don't really want to invent this for the sake of it - I would ask = operators here if they have that use case first. As written the document seems to say: there are SLURM files and you can = transport them over HTTPS, possibly implying that RP software will = actively fetch these files. I lean towards not standardising this, as = it's something that people can already do today. A simple script that = fetches a file and feeds it to an RP would already work, if that's the = way one chooses to operate. Tim >=20 > Di >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Nov 18 00:26:22 2020 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 6941F3A1669 for ; Wed, 18 Nov 2020 00:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 P--PP21P6WcL for ; Wed, 18 Nov 2020 00:26:20 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B536C3A1668 for ; Wed, 18 Nov 2020 00:26:18 -0800 (PST) Received: (qmail 23564 invoked by uid 1000); 18 Nov 2020 08:19:36 -0000 Date: Wed, 18 Nov 2020 09:19:36 +0100 From: Claudio Jeker To: Di Ma Cc: Job Snijders , SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Chris Morrow , Melchior Aelmans , Christopher Morrow Message-ID: <20201118081936.GA75316@diehard.n-r-g.com> References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> 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.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 08:26:21 -0000 On Wed, Nov 18, 2020 at 02:48:33PM +0800, Di Ma wrote: > Job, > > > 2020年11月17日 22:05，Job Snijders 写道： > > > > On Tue, Nov 17, 2020 at 11:59:13AM +0000, Chris Morrow wrote: > >> Can job speak up if their concerns are NOT met at this time? > >> > >> If they don't speak up in an hour I think we can consider this adopted > >> and ask the authors to submit the appropriately re-named draft :) > > > > Eh.... a new IETF rule? :-) > > > > I am not a fan of adopting this draft, I think the working this working > > group's sparse resources should be allocated towards other work. In the > > operational field, people have been transporting SLURM files for years > > over HTTPS, SSH, whatever is suitable. It seems awkward to describe that > > a SLURM file can be transported over HTTPS... it seems ... obvious? > > Happy to know people have been transporting SLURM files, which makes it necessary to standardize RUSH for inter-operation. > > I think this argument of yours is a kinda support for adoption of RUSH not the other way around. > Why is file transport an inter-op problem. If the file is copied with scp, sftp, rcp, rsync, https, http, ftp, USB stick, floppy disk, or using any combination of those methods is up to the operator and there is no need to write an RFC about this. Especially since RUSH is not on the same level as RPKI regarding authenticity validation. > > > > > The security section of RFC 8416 already establishes "Additionally, each > > RP using SLURM MUST ensure the authenticity and integrity of any SLURM > > file that it uses." The described use-cases erode potential security, > > specifically: > > > > "A small site or enterprise network MAY also use RUSH by > > synchronizing with a third-party RPKI cache provider over external > > networks." > > > > Who are those small networks? Are the authors attempting to speak for a > > silent majority? As far as I know small networks have just as much > > access to tools to validate RPKI data as big networks. What even *is* a > > 'small' network? Seems pedantic to a-priori diminish/downgrade a small > > network's access to secure routing by suggesting they should use an > > inferior substitute instead of the real thing, when everyone knows you > > can run a RPKI validator on a raspberry pi or smaller. > > We don’t make decision for operators but offer them a choice that they can outsource valiation if they have no problem with this fashion. This is a very bad choice. There is no cryptographic signature in RUSH that ensures that the provided data is actually authentic and unaltered. There is no way to verify the data. All the trust is put in HTTPS. A secure transport layer does not ensure that the file served was not altered. I think this WG is responsible in helping operators to take the right decision and to make sure that the promise of validated resource authorization is not watered down. Because of this I agree with Job that this draft should not be adopted by this WG. People should better spend the effort in making the rpki validators as easy to use and deploy as possible. > > > > Furthermore I do not believe that the SLURM format is optimal to > > distribute Validated RPKI cache data. It is inefficient from a size > > perspective. The SLURM format makes a lot of sense for describing 'Local > > RPKI exceptions', but the datastructure seems less suitable as the RPKI > > grows in size. > > > I don’t agree in terms of SIZE. > > The beauty of SLURM file is that it naturally supports incremental update. > > > > > Many operators *already today* are using different formats, so why not > > either look to standardize the format that actually is in use in the > > wild, or optimize towards something that is better than what is already > > used in the wild? > > > > I am pleased to know those operators have *already today* used some > other formats that works for their networking condition. > > If they want a standardized format, it is fine and good. But this won’t > necessarily stop RUSH from being a WG item. -- :wq Claudio From nobody Wed Nov 18 04:27:49 2020 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 4D30E3A1840; Wed, 18 Nov 2020 04:27:48 -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, SPF_HELO_NONE=0.001, 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 KBGv_Q-2Dgoa; Wed, 18 Nov 2020 04:27:47 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12ED3A183E; Wed, 18 Nov 2020 04:27:46 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id EDB42EE0157; Wed, 18 Nov 2020 12:27:43 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 08f753d1; Wed, 18 Nov 2020 12:27:42 +0000 (UTC) Date: Wed, 18 Nov 2020 12:27:42 +0000 From: Job Snijders To: Di Ma Cc: SIDROps Chairs , "sidrops-ads@ietf.org" , Guyunan , SIDR Operations WG , Chris Morrow , Melchior Aelmans , Christopher Morrow Message-ID: References: <87imbybjne.wl-morrowc@ops-netman.net> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2020 12:27:48 -0000 On Wed, Nov 18, 2020 at 02:48:33PM +0800, Di Ma wrote: > > Furthermore I do not believe that the SLURM format is optimal to > > distribute Validated RPKI cache data. It is inefficient from a size > > perspective. The SLURM format makes a lot of sense for describing > > 'Local RPKI exceptions', but the datastructure seems less suitable > > as the RPKI grows in size. > > I don’t agree in terms of SIZE. Hmmm, when analyzing the SIZE difference: $ du -sh slurm.json rpki-client.json 16.3M rpki-client.json 20.3M slurm.json The size difference can be explained because the non-standard format uses 'maxLength' as key, and SLURM uses 'maxPrefixLength' (which is more bytes). Furthermore, the SLURM format does not have a "ta" (Trust Anchor) key, so the SLURM format offers *less* detail than the non-standard format. The SLURM format also does not have the "metadata" key, which contains valuable metadata about the set of VRPs the JSON object describes. > The beauty of SLURM file is that it naturally supports incremental > update. As far as I can see SLURM does not 'naturally support incremental updates'. Can you please elaborate on this 'natural' property? Reading the SLURM RFC it has a section on "atomicity", making it clear that a partial SLURM file is problematic, and further more it specifies how to deal with multiple SLURM files, which is not the same as 'naturally supporting incremental updates'. > > Many operators *already today* are using different formats, so why > > not either look to standardize the format that actually is in use in > > the wild, or optimize towards something that is better than what is > > already used in the wild? > > I am pleased to know those operators have *already today* used some > other formats that works for their networking condition. > > If they want a standardized format, it is fine and good. But this > won’t necessarily stop RUSH from being a WG item. I would encourage you to not ignore feedback from operators such as myself. It seems the authors are ignoring the lessons learned from existing solutions. Operators (like myself) have experience with large-scale Route Origin Validation designs where RPKI Cache Validators and RTR servers are separate network elements. This experience must not be ignored. There are 5 (!!!!) validator implementations which support a common (not-yet-standardized) format used in many real-world deployments. From this tangible experience we know some of the good and bad sides of the particular format. SIDROPS can choose between 3 options: do nothing; or standardize the existing commonly used format; or improve the existing deployed format. Investing working group time in a *WORSE* format is not an option. Kind regards, Job From nobody Thu Nov 19 01:04:00 2020 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 F16C03A1245 for ; Thu, 19 Nov 2020 01:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8uanhbrvet5 for ; Thu, 19 Nov 2020 01:03:56 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 DE9963A1246 for ; Thu, 19 Nov 2020 01:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: CC; bh=WPWHfFEX3Kkp68YIvvye7haARg+p1Mv5dc5Bl5EN08o=; b=Mh5GOgFEz6xJGXcubGKIkP 7cALGeNP5JmVyQXT7bvOgCVOTSpytA5UKwC7hFsa5c8P+k9yU0yHY4MJEws9yfsCCq+RDro5ezMby rdRYKu/gM0cZdhpEhQeTGjNZEIeE2oKTjBc/kFv+TIXxpLy4PUuqrXVEsw3zR3LtVMWMUAWcvdROW AwLtzeIKUempJDgkWAXOHJ4xD+kJd+9Wtc4fa4qibBGrUMQBd5nByMO6pPn2g6v1lR9XXhDOoycUN TFs7U2ru1faqlbEBvT1DPhLhhuvT2RCbtsCA32sZtYWhQkKhFsmpijPQhLXeACZU/zj5wXCYsTgqr v94DyHSM8q2Q==; Received: from bufobufo.ripe.net ([193.0.23.13]:43432) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kffr8-0003YW-KB for sidrops@ietf.org; Thu, 19 Nov 2020 10:03:54 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::346]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kffr8-0007il-BM for sidrops@ietf.org; Thu, 19 Nov 2020 10:03:54 +0100 From: Erik Rozendaal Content-Type: multipart/alternative; boundary="Apple-Mail=_48EB6C8D-C09A-4473-936B-8E802C97C0E2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> Date: Thu, 19 Nov 2020 10:03:53 +0100 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 3081e9bfa2e75d9dc8fe5e8110458a383f50b0a5e24c6ca4d1ae405cb3115ed6 Archived-At: Subject: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 09:03:58 -0000 --Apple-Mail=_48EB6C8D-C09A-4473-936B-8E802C97C0E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, During the past months we've been working on improving the RPKI=20 validator to track the 6468bis RFC. As part of that effort we've also been finding and fixing various other mismatches with the current RPKI RFCs. One part of this is validating manifest entry file names. Currently the various validator implementations handle manifest filename entries differently, potentially resulting in different validation results. Summary: We think the manifest RFC 6486 should define rules used for the filename entries in a manifest. Our proposal is to only allow a minimal set of characters from the ASN.1 IA5String type: a-z, A-Z, 0-9, . (dot), - (dash), _ (underscore). Furthermore blank entries, ".", and ".." must not be allowed. Filename extensions should be matched in a case insensitive manner when determining object type (ROA, CRL, etc). These rules validate all current objects from the major trust anchors (all RIRs and APNIc AS0). They avoid special URI characters and characters that may be used to navigate file system directories. We may also want to add rules such as: - Avoid illegal (Windows) filenames such as PRN, NUL, or CON (see https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file = ). - Require that all entries have a three letter filename extension. - Prohibit entries that only differ by upper or lower case (FOO.CER vs foo.cer). Background: Manifest entry filename validation Currently the different RPKI validators use different rules to validate the filename of a manifest entry. The RFC says (section 4.2.1 under "fileList"): "Each FileAndHash is an ordered pair consisting of the name of the file in the repository publication point (directory) that contains the object in question and a hash of the file's contents." Unfortunately it is not exactly clear what is allowed as the filename. The three validators that I investigated use different strategies: rpki-validator-3: anything goes. Filename is resolved using the base repository URI and the `resolve` method on the Java URI class. This allows subdirectories, escaping to parent directories, etc. This will be fixed by https://github.com/RIPE-NCC/rpki-commons/pull/30 = where a filename must: - only have characters a-z, A-Z, 0-9, , (, ), +, -, ', :, =3D, or = _. - not be blank - not be "." - not be ".." All currently published objects pass these test. rpki-client: filename entries must be at least four characters and the filename should not contain a forward slash (/). See = https://cvsweb.openbsd.org/src/usr.sbin/rpki-client/mft.c?rev=3D1.14.4.1&c= ontent-type=3Dtext/x-cvsweb-markup = in the `mft_parse_filehash` function. routinator: filename cannot have control characters or spaces, ", #, <, >, ?, [, \, ], ^, `, {, |, } or have value >=3D 0x7f (see = https://github.com/NLnetLabs/rpki-rs/blob/b3b0eb6b0c524d1bdd8de23acc6cf398= 8386b3b0/src/uri.rs#L682 = ). Furthermore "." and ".." are not allowed as segment anywhere in a complete rsync URI (see = https://github.com/NLnetLabs/rpki-rs/blob/b3b0eb6b0c524d1bdd8de23acc6cf398= 8386b3b0/src/uri.rs#L95 = ). Kind regards, Erik= --Apple-Mail=_48EB6C8D-C09A-4473-936B-8E802C97C0E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

During the past months we've been = working on improving the RPKI 
validator to track the = 6468bis RFC. As part of that effort we've also
been = finding and fixing various other mismatches with the current
RPKI RFCs.

One part of this is = validating manifest entry file names. Currently the
various = validator implementations handle manifest filename entries
differently, potentially resulting in different validation = results.

Summary:

We think the manifest RFC 6486 should define rules used for = the filename
entries in a manifest.

Our proposal is to only allow a minimal set of
characters from the ASN.1 IA5String type: a-z, A-Z, 0-9, . = (dot), -
(dash), _ (underscore).  Furthermore blank = entries, ".", and ".." must
not be allowed. Filename = extensions should be matched in a case
insensitive manner = when determining object type (ROA, CRL, etc).

These rules validate all current objects from the major trust = anchors
(all RIRs and APNIc AS0). They avoid special URI = characters and
characters that may be used to navigate = file system directories.

We may also want = to add rules such as:

- Avoid illegal = (Windows) filenames such as PRN, NUL, or CON (see
 https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-= file).

- Require that all entries have = a three letter filename extension.

- = Prohibit entries that only differ by upper or lower case (FOO.CER vs
 foo.cer).


Background:

Manifest entry = filename validation

Currently the different = RPKI validators use different rules to
validate the = filename of a manifest entry. The RFC says (section
4.2.1 = under "fileList"):

"Each FileAndHash is an = ordered pair consisting of the name of the
file in the = repository publication point (directory) that contains
the = object in question and a hash of the file's contents."

Unfortunately it is not exactly clear what is allowed as = the
filename. The three validators that I investigated use = different
strategies:


rpki-validator-3: anything goes. Filename is resolved using = the
base repository URI and the `resolve` method on the = Java URI
class. This allows subdirectories, escaping to = parent directories,
etc. This will be fixed by
https://github.com/RIPE-NCC/rpki-commons/pull/30 where= a filename
must:

- only have = characters a-z, A-Z, 0-9, <dot>, (, ), +, -, ', :, =3D, or _.
- not be blank
- not be "."
- not = be ".."

All currently published objects = pass these test.


rpki-client: = filename entries must be at least four characters and
the = filename should not contain a forward slash (/). See
https://cvsweb.openbsd.org/src/usr.sbin/rpki-client/mft.c?rev=3D= 1.14.4.1&content-type=3Dtext/x-cvsweb-markup
in = the `mft_parse_filehash` function.


routinator: filename cannot have control characters or = spaces, ", #,
<, >, ?, [, \, ], ^, `, {, |, } or = have value >=3D 0x7f (see
https://github.com/NLnetLabs/rpki-rs/blob/b3b0eb6b0c524d1bdd8de= 23acc6cf3988386b3b0/src/uri.rs#L682).
Furthermore "." =  and ".." are not allowed as segment anywhere in a
complete rsync URI (see
https://github.com/NLnetLabs/rpki-rs/blob/b3b0eb6b0c524d1bdd8de= 23acc6cf3988386b3b0/src/uri.rs#L95).


Kind regards,
Erik= --Apple-Mail=_48EB6C8D-C09A-4473-936B-8E802C97C0E2-- From nobody Thu Nov 19 07:01:38 2020 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 68F773A0A26 for ; Thu, 19 Nov 2020 07:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrOpPvfEsE6N for ; Thu, 19 Nov 2020 07:01:36 -0800 (PST) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.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 494093A0D4C for ; Thu, 19 Nov 2020 06:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1605797994; bh=tVPnwqwPYZs2Q0JVQ8B8V1FdfvflZ+h45Jh8NVP0+BY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=l/FBVHIzn8trzJLGOPjWQdzfdjKj6yC4ul+fqxCd4y8Tgl08basFst8SGHTFWPXC+ce64VTX6oA2NNrhsdVOlRtToiapa5/fJbLruKGXeBtk1pFDcrQWWCvAM2msewbo3dshpEus0qCt6AEU8+vU09z5eMOj6Y2c9447wVjEP4MK6Y/+c85RVPVzUARwAKm992i1ETvvqAyIt+oF1VuGBniSnhfGLWiyl1Z49JzPcD0vfq4+gSyFFIepb/InX/OaUYWdubttdRV+KHaMrHzfs4t4ePICS0vc9r94qbjXWeMu+i6NhpRoX1wsvemqz1mAgZ2gNm6ExVB/CHDqcTpSLA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1605797994; bh=9jMU/QVs0nPKqhvzXiUbNVabdI0Frq2WICktAHpyAbf=; h=Subject:To:From:Date:From:Subject; b=rIZyyTp9lvp2LjxywT7I+FJshSVwisEOiPX7Qs9sUjdtBEPoKWB4NLtW4zx4m/uL9fjyNgjtMbY1RNQD5B/0H93k8CZr8ajtszZmwzlNhw8dqBDcr2KevmsKDF+AcbOQezV4pt6VQR3AEKmz500PY/Pf3dbIb0ANmsnE3oaF1ossFvD+eFYeYJN/k0W0iRhhBe6sLKHO2Y+k40a1b14SradkeYRJTLhysKkaZSYIdnGZdCBZUFtPAYIelyM6lMZAHwa4byLPxImxvbXgzFuMY/jAoO8pDXAa3//1c3OdB5j8gnU3WfLfNElN4O4x8+3e7Ejkg2AMBIs/sRJy0xoMTg== X-YMail-OSG: HfSSntMVM1lReRab1mXhJalzJMK3QcE81i8lex3v7kZhGqQT4Io4qsYZM880ecc WDqHvUhfaa7S9k4oslk4R3EmE2wNW5CwODpwDwTx29o3gBXynzFcn7zLWvPH.CSvLF.xXiTRV.HJ hZWLOJa85jBDeEjY8IQZHlmeS2IdtqLCVXlLkr1lkY6F4YNXR30aKlSBcTE84aELZeLCINoRXxm0 WSWpzjE2kroMSHUYqIP0zSPuv4UcMJM3NXb.lIwKgV2u1AkMoehwm41nBDybtKizA5A3Nv7xTmWd 8XoBL7khhnlJCseI.C4fqRrD9vJCRkElDG1z.TSDIqjigV1ZASNZIKcshquKxZvoZ0..0J3p3U.L 3MF6rg.EMq9T8dAEUObAS7roBWJ.f9kJtUnnQVgruTckaDYjgc7799Un2r5UU0xci7Z48C.ZJffm TZbEs0nlSFMTxjBDrzMA0IW3tza.6Of0jPTDCqUGwvQ.VrUP6S8EfJ4H_6TcdCGgOS6U02KD96AQ 5EA.ln468CBzZe9uqpjXej9A_SyNh2Q9hoGVu.DUK_ZAqv..hE.RqHrDfwtZR7._A_CJpv9yOpqN fRqYyuQ7hoVIlO4Siv0ZgE6k0L2wN5L2EjDZSPfo3QkALeGAYffcyOzI9IYuFJNIb0fQB8EWXi1R Ou187m8pA8d5wjySXCINgX8CDXOXS1eWTnsWPU7IhFF_o0FIOVm9s2wwic1t51qkkOTLRUs9YbIJ vAfcC.lMLe30Q8qlWnmZOrLPOKIiPrUDZJBESBd6SNdc5cB2THL0PZVTv1x8na.EJAuhhpWWt_Sy axnKfSGtcUYHeMz8Iy5Tqa0HFxin3noNgKgnK3llZJ03wQFiwk_crj8yZ_Pex5O5MvmiPxOKWah8 yoD6F2vFr5t1SNsxHFQZB5MVWHZ73aK3RphmQCQDlY5OQjIuG8zbVGsJtvpIgnfIn1YfLcMg0HV6 TiQzRvQIOV9aRr0gLWVa4xeE0yNoP6IEUE8hFQfxHoS7JmRUb60oG97IbKAjTcGF7m8HXrWmwYch H1Shd3w8pjEC3O5KtnikVo.06_HVT1XhBHQXTDtVvps1qCHt3Xi8yXrb35..p1SMu2SM28CeGUDr C4PMHbkqcE9nhc.4IQArwW2.NmYWrzkyrX6uPzFVusPgJLS7cqrl_Fv2hEeA8BVp9t.XctAN5qmE oCtwD8qy48CG6KO1FMtxxK.72MPD4mG4.KOmqutovChkGISGe19S_86F.0jqK85WcNMAkvKyVPFb uBVvUA9GIlLsVoBij7eztUTsEj2wb5Lop33aQWiw4uAH8ZxZXbOO7Udksc1O2lRXlq1A8Q3Nx7wZ _CoXN9X9kkzM7cZdUFwLj7AlH0wEKG.lRwjOE7u8I9zw1tGn2Qu1YRCfjyl_gJtVt330F5p9nVvO aipKP2PsL4.OzdAeenc9C.WFUNfsyv1IryxiK1j32TtSQ9eN2IOv2.Iowp9pn5WHmDyhiV3QXNsu AG4.Y1peCBiZzl1yPv2y2f21UobIQ9S1p3V7fO8Mc3ogbDStdN0iLExZZn5BSNwoVvlOklRg8sql 9M7bLiybRw1Vtv1xm_rzW_sDi99nOHtwgKIaj3ieFcaQA02flQQylqV2sSs3ssNnTviC03bt9wjN 6bI.b9RBXf2s9xMtClWEaf1TLg2S2gm9CdjUsNxeXwzd3ZwvXf3GKox21j5odkUPDxk4HXFitNPy YUO6u_GQ4un2BTF9NbCQ3Osm1Fr7.i9zKCXlEwD4In7ECAi3Yab58x.R1NGQBdy_no2GqlYcM_HZ 4vJyIN9KMlnGh2uJA8l92QI4DAa6jTnZrvqe7n001v548L1RSWp65m1Oc7v5dv3DF2aYGpj8enV6 TOLqDZnDSL8pm0BB7JCjQPNKjPeDng0zIuAooYDApyMjugfzyjHCvoElrhpIEcPs.tOPQrXfhOAN KDwwy1ulfeEVvSUyOMZETWt5gKgDqtfVpFU8DA6r32dgDLcOEAOLuITq3eSxolpB0EaevQ2nYQ1M K0WqE53r_WbKWCYBKz5zkJtrOZ9m9nRTAsi1IXRYTQTVfgF_CBFRpswoZv4k6qyzDA6i0JN69Kju CggNPtxM__XqGOv5n3JK0n.coo_4O90WrwLBjCZFsihAl_xwA93m2KIr0Um7iHGvMKQwsopsCmB3 b_KOsj1Y5zAcaW9ZU5XtqT1Ht0oBzY3xv5ypi_S9.QKxGcnXrM5ukKyhABXOj8ftJQApNf6og8FX OVGPFunJ0sagAACwAN_V965PHXTJjIvpwz6wGOOGqR0iRCJrJdHF.aUJ5U8NfUk45Jn6eofJoGzI 7FwlLaJNMhLKghZw1orwmwyXFeNOQFaqIAH.e.IZkTn0pdoXJGJO2A44wFBtLTE4kuCZomC0775K svBkobHAwzDLWEHXmLTxnanD6HLYlTzFRPQhv0x.H.rliVr.nhTueMPnFHPR5VQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Thu, 19 Nov 2020 14:59:54 +0000 Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1e238646c57d11af8576078c95c6fa76; Thu, 19 Nov 2020 14:59:49 +0000 (UTC) To: sidrops@ietf.org References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> From: Stephen Kent Message-ID: <3078ef7c-e282-a196-9f07-21789276673d@verizon.net> Date: Thu, 19 Nov 2020 09:59:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 15:01:37 -0000 Erik, Thanks for looking into this problem and proposing a solution. I'm anxious to incorporate changes into the -bis version before the end of 2020. I believe the character set restrictions are appropriate, as is prohibiting single and double period directory entry names, and mandating the presence of the 3-character suffix. I also have no problem with prohibiting a specific set of names, such as the Windows-centric ones you mention. The proposal to prohibit entries that differ only due to capitalization is worrisome. All of the other syntactic tests are easy to perform on individual entries. This test seems to require examining all entries at once to detect a violation. I'd rather not include this rule, because of the added complexity. Would folks like to mandate use of only upper or lower case characters as an alternative? Steve From nobody Thu Nov 19 07:05:06 2020 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 301623A09F1; Thu, 19 Nov 2020 07:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Vrh-9s4G72yU; Thu, 19 Nov 2020 07:05:02 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 10B8E3A09AD; Thu, 19 Nov 2020 07:05:01 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id u22so884401qtw.4; Thu, 19 Nov 2020 07:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=o7j8mC4rEzyTu/bSpaWRt4reIhvoo4jA1rcuyNVOu4M=; b=kNEibXMx5ZQOzfAaqGNOAnWxpU8tc0EnOkocutyn1JtHBox/1YkeV3VtJCjW/+UJoW PRqJB7u+vcuN7n4ptArQWhPQgawy64BIf4jRK5MYbbtBWZWnydAJ5uVMHMdJ2fNscDtL UuNVAYcC6X1gMblg6lDdegFoDJtOHFKamNzJflHk5JUYs1d72qIiIBbilqvQMOUAVFMP DwFpvWC0eSyqn8eJokxsE/1fL38DvV0hfo4RU5LImCQj/IaOA9FnSik4RPuGBQmpqKqS NcqOaEXeR427gOg/v8ZTCRCNEjLT93yRh7Yd0x3XlncJHu+hqotYmd/i2fN1B2Ytb0MX LvEA== 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=o7j8mC4rEzyTu/bSpaWRt4reIhvoo4jA1rcuyNVOu4M=; b=R9V5O3zVj0U10aH83KxYHsyyzINWNHN3dDDHE248SyZja4uQ0zOM0kf6vQoLXqj9Vn lqyZc8Wm4ZTEN2OM8YxKyvJS1eQ4Rj4x1uXUd6LW3dTgYBLB2xUFjhS8Qu+rKvHqHpoK mNnlkqFJy14fcpZmvivhh1+6FvP7UVFn5DDlEo8h1WCklSxrJsk3wMAoOeJmQwYMd+Hx AjYMac0En3YutssVnbd2Hda+DFCK6ZB9gI0kdYyNNT/tld57hzbJ5n4ifRv+nrkz1+7z F+e2DXhtpgxVz0dYvWKtnEpE6RkY+AL3ZDHaBkTX3GP3KuCekXEfOTHAdVgHpX56gKEX GukA== X-Gm-Message-State: AOAM530ODXbRWgZ5t80zXszX6evuCvSs76S5muCaQBv9awpwHEWDMC7e B7JENhT3PNHDzellv5GWqpViifSoClh0PbZM5YZ7q4jnQvrzsA== X-Google-Smtp-Source: ABdhPJwa1c9cYjgPgRDq3ve3iB73Ee9uNith4YV9fCkcwN3pr3wRBfR+YLDmzkDXZBijqz8ycy3qmXpslYJr7b6CATY= X-Received: by 2002:ac8:39a6:: with SMTP id v35mr360471qte.315.1605798300759; Thu, 19 Nov 2020 07:05:00 -0800 (PST) MIME-Version: 1.0 From: Christopher Morrow Date: Thu, 19 Nov 2020 10:04:50 -0500 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 15:05:04 -0000 Howdy WG Folks! During our last Face-to-Face meeting the authors of: draft-michaelson-rpki-rta presented their document and requested (in meeting and via email to the list) a call for Working Group Adoption. The abstract of the document is: "This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of an arbitrary digital object, to be signed "with resources", and for validation to provide an outcome of "valid with resources". The profile is intended to provide for the signing of an attestation with an arbitrary set of resources." let's have a read-through, think about applicability to SIDR-OPS as it relates to the technology we build and operate (technology and business intersection), and provide feedback on the list before 10/12/2020 (Dec 10th). Thanks! -chris co-chair-persona From nobody Thu Nov 19 07:53:41 2020 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 ECEAB3A0C15; Thu, 19 Nov 2020 07:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouKlEc4Omajj; Thu, 19 Nov 2020 07:53:38 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 B8EE53A0C0A; Thu, 19 Nov 2020 07:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=2nHuUItGRDDzt4VDEQT0R8KT9zHx+wmOCP/wYvCv/Z4=; b=HSDi/nEjXOWw 30Mi78UNqPOKQYvIMIL+4zexWYCtTAgBjW0fQBIw3/U8vlKeNRGN3drj7lPvuXRs4fTgjmVHg6R0d CEyK9GyX60SQYLrZUQ7ED8szbg3sJjEdhdu+efKrS0ogBPRL/HlkzwuytQQx59S985JouM9jclLmp PsDH2spwiLrZIDV0meFfl6b5CWSNaGGJDdxgtSet3XlOtM/vwcJiuerFuEdYtUpTR7uvjT9bUfuy5 Gm8coq73VOest9ks3lJ31XSHkbtEwV2BJzPqOnalXabmzH44SKZ0GzJSnGKpa9LO8KJEN/yvmXHwv jzqmtmsxX1lDkwmoAB6MHw==; Received: from allealle.ripe.net ([193.0.23.12]:44072) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kfmFd-0000Tx-Gj; Thu, 19 Nov 2020 16:53:37 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::14e]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kfmFd-0001FN-Cl; Thu, 19 Nov 2020 16:53:37 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Erik Rozendaal In-Reply-To: <3078ef7c-e282-a196-9f07-21789276673d@verizon.net> Date: Thu, 19 Nov 2020 16:53:36 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <3078ef7c-e282-a196-9f07-21789276673d@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 3081e9bfa2e75d9dc8fe5e8110458a3898ac02a6125958ee1ab94cf393f3f1f0 Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 15:53:40 -0000 Hi Steve, > On 19 Nov 2020, at 15:59, Stephen Kent = wrote: >=20 > I believe the character set restrictions are appropriate, as is = prohibiting single and double period directory entry names, and = mandating the presence of the 3-character suffix. I also have no problem = with prohibiting a specific set of names, such as the Windows-centric = ones you mention. >=20 > The proposal to prohibit entries that differ only due to = capitalization is worrisome. All of the other syntactic tests are easy = to perform on individual entries. This test seems to require examining = all entries at once to detect a violation. I'd rather not include this = rule, because of the added complexity. Would folks like to mandate use = of only upper or lower case characters as an alternative? Most of the additional proposed rules are an (probably incomplete) = attempt to make rsync work on non-Unix systems. Maybe we can just make = this a recommendation or SHOULD, or just forget about this. RRDP should = not be affected unless you directly map object URIs to filenames on a = file system.=20 Only allowing lower- or uppercase characters will break existing objects = in the RPKI and require changes at the CA level, so that's probably a = no-go. Kind regards, Erik From nobody Thu Nov 19 08:47:10 2020 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 01B6E3A0A50 for ; Thu, 19 Nov 2020 08:47:09 -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, SPF_HELO_NONE=0.001, 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 57XWOiLMH3Hn for ; Thu, 19 Nov 2020 08:47:07 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [128.241.192.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D2C3A0A4E for ; Thu, 19 Nov 2020 08:47:07 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 132D2EE00F6; Thu, 19 Nov 2020 16:47:05 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 0a32f49f; Thu, 19 Nov 2020 16:47:03 +0000 (UTC) Date: Thu, 19 Nov 2020 16:47:03 +0000 From: Job Snijders To: Erik Rozendaal Cc: sidrops@ietf.org Message-ID: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 16:47:09 -0000 On Thu, Nov 19, 2020 at 10:03:53AM +0100, Erik Rozendaal wrote: > Summary: > > We think the manifest RFC 6486 should define rules used for the > filename entries in a manifest. I dont think one would want to go as far as to "make rpki work on case insensitive filesystems like some versions of macosx or windows". RPKI objects map to RPKI files. Paths and filenames are considered from the IEEE Std 1003.1-2008 / POSIX.1 interface perspective to improve portability. Filesystems with with an assortment of capability limitations (example FAT32's case insensitivity or small filename length limits) just aren't suitable. > Our proposal is to only allow a minimal set of characters from the > ASN.1 IA5String type: a-z, A-Z, 0-9, . (dot), - (dash), _ > (underscore). Furthermore blank entries, ".", and ".." must not be > allowed. Filename extensions should be matched in a case insensitive > manner when determining object type (ROA, CRL, etc). Or alternatively the spec requires all RPKI filename extensions to be lower case? At the moment of writing all published rpki files seem to use lower case anyhow. > These rules validate all current objects from the major trust anchors > (all RIRs and APNIc AS0). They avoid special URI characters and > characters that may be used to navigate file system directories. > > We may also want to add rules such as: > > - Avoid illegal (Windows) filenames such as PRN, NUL, or CON (see > https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file I consider attempting to protect against windows-specific bugs very much out of scope for this working group :-) > - Require that all entries have a three letter filename extension. ack > - Prohibit entries that only differ by upper or lower case (FOO.CER vs > foo.cer). Requiring filename extensions to be lowercase addresses some of this, but 'FOO.cer' and 'foo.cer' really are separate paths. Regards, Job From nobody Thu Nov 19 08:47:40 2020 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 CE46E3A0BED for ; Thu, 19 Nov 2020 08:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl 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 DohJrecq7XI3 for ; Thu, 19 Nov 2020 08:47:32 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9253A0AB1 for ; Thu, 19 Nov 2020 08:47:31 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 43FDB60577; Thu, 19 Nov 2020 16:47:29 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1605804448; bh=JnmAy6ywetfK2WbvO/vm1l9T/T+6A4HWWdvAlX0Pcjw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mwVJTAi4n/dOPoNEKKat9pjicBmspsmh95m5VcxYNOG46RQXEJfectGnvR8j4HiLG ZVh5j0l05PkxrTc//d8DC/V9vscpabED4yxv5+YPNORTs8ci7TLlSmMGbPJcs0+JOh jCC79F41wHsK5hLZmN7h0ws/UH55VpIHmHkK48cyikZ+aP00D+nlAWQh3Ptn3DkxbP Ftr6TfL0mxij6zHQffvVNZlGK/GXhJvDUQ4tLxj8dVlqvvQsXgpXhJhQJtJHNYlrXL wkmA2Zt0paWnRsYqegsNEIkAp0ANnBgBusS3ZafqtoCgNyinjxGwQkCuTmStLW1Qt5 XIzwu7FwA6xqQ== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 19 Nov 2020 17:47:27 +0100 Cc: Stephen Kent , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0A014A96-D583-4319-8660-C3EBB1FEE446@nlnetlabs.nl> References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <3078ef7c-e282-a196-9f07-21789276673d@verizon.net> To: Erik Rozendaal Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 16:47:39 -0000 Hi, > On 19 Nov 2020, at 16:53, Erik Rozendaal wrote: >=20 > Hi Steve, >=20 >> On 19 Nov 2020, at 15:59, Stephen Kent = wrote: >>=20 >> I believe the character set restrictions are appropriate, as is = prohibiting single and double period directory entry names, and = mandating the presence of the 3-character suffix. I also have no problem = with prohibiting a specific set of names, such as the Windows-centric = ones you mention. >>=20 >> The proposal to prohibit entries that differ only due to = capitalization is worrisome. All of the other syntactic tests are easy = to perform on individual entries. This test seems to require examining = all entries at once to detect a violation. I'd rather not include this = rule, because of the added complexity. Would folks like to mandate use = of only upper or lower case characters as an alternative? >=20 > Most of the additional proposed rules are an (probably incomplete) = attempt to make rsync work on non-Unix systems. Maybe we can just make = this a recommendation or SHOULD, or just forget about this. RRDP should = not be affected unless you directly map object URIs to filenames on a = file system.=20 >=20 > Only allowing lower- or uppercase characters will break existing = objects in the RPKI and require changes at the CA level, so that's = probably a no-go. Indeed this would be hard for my CA implementation. Or well, it's easy = enough to fix in future, but there are versions deployed today that use = both lower and uppercase. So, where was this coming from? Case-preserving, but insensitive, file = systems? I could live with some normative language that instructs a CA to avoid = creating case-insensitive collisions between filenames. Tim >=20 > Kind regards, > Erik >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Nov 19 09:32:53 2020 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 9AD333A0E3F for ; Thu, 19 Nov 2020 09:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkr7449uMLat for ; Thu, 19 Nov 2020 09:32:50 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 78A603A0E3E for ; Thu, 19 Nov 2020 09:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1605807167; bh=PIfJJtJdGG7CaXJIkn92DTTza/B63Is40+EYljQ/Dzc=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=SauDtdSRLOdfUef3TFbunF+p4hn4zybNOIOHVqOf6B4P4ucZbt1ZrsXq3nrIE9NLkpVw3kpHLnbIvmo5JnS52YZjeV3OLkLjvnu8TkFDGsP9MQ6oV4P2gng75+J48D0ie7g+GaT1r8g8jnuUeGbkEBzK5gt0A6q/ePbBIwt2LD+mSfOCKJu5WXR+CNS+LOqHCIoyw72QiJPQB2are+CfRfV7igmtVLUH12JO/eOTU+PqTyHsr+egjZPaeUB5j35XBHWAyHTaAf/GWXCvSheYlkXwKBFykjaJ/0C62/34v/QtjnkNSja1fEOylNUz/KQf7rNh0r5/RXU11WdI4eidlQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1605807167; bh=fb6fRzPRccljFazSN6WbSF2w7chpLgJeAITTpl7dSJ9=; h=Subject:To:From:Date:From:Subject; b=dPG57RYRVFYw30D/zHnrsWMNiettZym8afAHIvzVv9pY8M8Xd4xIDz5jXywkWfUheqZ2wc2uQsu7cUjGIshJYlF9ESKflHbTW1W/3QyJkxzEe6Iwyp3YYqHT7Mg1Jd3kTxe4f1lr9HvbZxwKAVMQ2N2KWNNcYhsrSY28JGrdTZHxzOrbNu+FyjUw8vFpxfrdYiOMBtT0lkWVccf2VaW+OVOEMwGIFDw5PqvF/y5TINccwd0Pwuk3vN+fwVvHR0iAlWUH0nMcF8jZRi1UvD0cUeR3dyXwmC6Ylx0MAkITBSBcSXJbxR6L/ERAPK7cm9fxOiPcm/UZF6eXLDniWZhNfA== X-YMail-OSG: _DsSG4gVM1k.E4AUikTtNnl7e9rBHpqcq6tBqlKPuifR32cFSSqGpRSBDJacxC1 97.ZUlNRCCVbG7eUTGdp.MrX658.hgMbUZEHvYbmsO4d_yvmi5YW00QDcIgJEsE53JWuXCmvKOlx FRfUi1kZHY61vRvnSEKJDIdA.Rt.vTDbI11QqzUubyF3_uQYDlo3JjZPon_7xZimijQ2J.khySsv WZWK_yRenkRBrNDf3_NpPJgttr8oVRRc897jynOwVPF3dxAZHlCpF7f3W1_1_6RMWe50XjUIgrmq .dqDzVY5RojCBblqc0jUDOfYtIP9V7ux.GZVqBTkkCNrAknBB31hAiawbwb2kAXCEwDcMoDKLChR 0nyEUE8xX7GcEhYDiOJx6jxW86OGS2WDa_WY8THOtS5rW7SisAZOM1_YYj9X0MyZYmcHkey2Ja_z CBy.OC5ebMTIv5Pnj_9jRCM187NnGbcA9r08IWs1_MPYF0UUyuN8OImTWJYfivzTmCPbZuNApLo9 u1u4cK4nDax.0DQxOtSx1AMZ4dLdgKpSCmQV4fHmxDzTHK.XVj3LDzqYw7zGRjHutaFBE7i0OLPZ 6N6GT0ps7w4nbrLzipzPBMO1a5idiAhsq5BBGmQSW12WrfWycbq3iSa5BygZFhaEF6QWh8_.yd4t ZvXBG7bOCaVKCb3G8puplEF3wcv463Pazg8COZe9Qdd644RDzThkVKV0p6FB8wNXsXfmj1c.mm7S X0QaVFrPtf1qFHR1b0M8bqvVo5cR5IVjs0OlM0qOrfK0B_dGmvHEP4UFN0bpgD1WdNRI15.vRpwH AnhpudxWR4KU5VaoHqQvoFosNP6RubGqooKTvj1_ePFSR.h1x.zYoK6r20SrxAerZq09QDh9j1u3 CsfXzoZmQBIoSIHKnyeL1vVq2DaRIvXFi3e2XK9GqeETPE4i5NnNg8nIFmDdoONE2VyqO3Q3Jsgc QaXcH5A.BZbZOwQ3VYAgGgBeCFJtfyAJBlcVbphNroXyr1RT5bv8XEyE67Bp02TZ5GK5L4VBYaHI N.tuIY58LRhJHxx1sk80LlL02H6dQUcFfQjTSMVqeA7cyuDtzyObE8YW0P3zSHrmaJ.nCSeMRYpD lg.IWnM.saMtT2WAg4cElcOO2IKAn_LunZNp.le.7IdRwjKxhovdlzKhHZsejg5C_YAtKa4IfoWV F5woyuaQRhQuluLRlYKr6i2D7Dk4Rg3ULbXyd7e.CRTghBjNHkpnS7tqYkmctQ7NhTH7Qy4RToll I1.g_jc08tsPFcb2rk9eSSLeG0Io7ZhVphlNe1peAlmoG2EY8p8waZWp4LFdcn2bTkEgOI0rkXPd hAetnViXWS0V2CcVz5dtTyJHMhuBpa1RR_kVLu9yWI2YxcBNJ5a3ApT9PwTjQEbGgQSpYXy1vDmC WE4j66sp52QjUcMx9OMvprtvN6I.2_fZUVlewgjogv_wKRWLUtjCqQLRzUTaT1rp9YNT8v0rx01R 0nAPf2q70t0lr1EU0gji_m4H72amkrFHwGDMjBTLylqj1V0Neweg7u_mjZYg.eFqmGhvWdRGVsKu MqBmgmmw6EdydeD7Z6GNwO.dMBFyTuSMmrVP8g9PfWpmiMG9NEGUM4XLOA3g0I0VUy9OUuSQ1s0b SXzGIP6xHZ8x7yzQO5vJtv5MpGLFsHHGEzcQSFwIxbw32MLLfQFlYgJlrQdzYJsvggy0PjHFot65 V8Ogw5UyE5di5PTIltK4zP3Itjrn7CZD5LJKz4H33Jc6JSDIGsejpLT0rJf7iqkC8hMxr7rJLSFT lcHufqqAW2bCEpP123yVRT5L2bQFbP1utjWcz7lZOZvA9ij9QIsPe9QJq5BWBY1Gbl_ijCzV7Kvi vljPz4vSP5.Ghj.WbOY.5UU6n_J0IxCcb8MVtHsUqxUHpVhp4zYkJqGPulVst_PWyyVyyNusYGBk FHfT9.xeev6b5D6WzjkXkbAV7kyKqXT2VS7ftiAfQ3cWpfWObTChsaRTnyKc1YOJITZuOvHBaS_f .DFGXNcnwBiuRJ6QL_mglNa4ZJe.SGBtIGu2e0yZ_tx_X.JYDQ3g85VMTf8mzWv7dhxh.HfRRGGv UcPFAoYKK4ONbwT9IiIcHVrJcVpxnaIbD2rWIpQI2zYsC.Uq2Iu0jke6czPfkxu8ljJn5cxS6sh3 2cVmnSLxlxPqIHs_dK12wOEIlyGlAFzKya.tHqHdK7iKiWZ09o29aWzNu3b2x55zrl5s1gLGiPC9 jWdf63_X4sYCgsWJTOQMeqPm0CxAqdWs_vtDXA8VF6wQQEemHyGz2dD6bR8.wJwDNFg5Tn.wKrGJ 08MTRXVzprtqBFMkUSHD8VDqcvpp3CaaHJ2fAmQaTTVjGIQ9l8ynANE6rmPIusbqHRs8ByIH46SW IadVihanj Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 19 Nov 2020 17:32:47 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fc5d8a5dc26780b5bebddbda3db485a6; Thu, 19 Nov 2020 17:32:42 +0000 (UTC) To: sidrops@ietf.org References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> From: Stephen Kent Message-ID: <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> Date: Thu, 19 Nov 2020 12:32:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> Content-Type: multipart/alternative; boundary="------------59E191655589A0D5C8A4EF99" Content-Language: en-US X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 17:32:52 -0000 This is a multi-part message in MIME format. --------------59E191655589A0D5C8A4EF99 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit How about the following text: Section 4.2.2 To promote interoperability across file systems, the following restrictions are imposed on the file names that appear in the fileList: 1.Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (dot), - (dash), and _ (underscore). 2.No blank file names are permitted. 3.Single and double dot (. and ..) file names are prohibited. 4.The three-character filename extension defined for each object type MUST be present and MUST be lowercase, e.g., cer, roa, and crl. --------------59E191655589A0D5C8A4EF99 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

How about the following text:


Section 4.2.2

�

To promote interoperability across file systems, the following restrictions are imposed on the file names that appear in the fileList:

�

1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (dot), - (dash), and _ (underscore).

2. No blank file names are permitted.

3. Single and double dot (. and ..) file names are prohibited.

4. The three-character filename extension defined for each object type MUST be present and MUST be lowercase, e.g., cer, roa, and crl.

--------------59E191655589A0D5C8A4EF99-- From nobody Thu Nov 19 10:00:40 2020 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 2B04F3A0EC2 for ; Thu, 19 Nov 2020 10:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 3ZXnvDcNIT6n for ; Thu, 19 Nov 2020 10:00:38 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EB43A0EBD for ; Thu, 19 Nov 2020 10:00:37 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 61DC7220076; Thu, 19 Nov 2020 18:00:36 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 21e64c54; Thu, 19 Nov 2020 18:00:34 +0000 (UTC) Date: Thu, 19 Nov 2020 18:00:34 +0000 From: Job Snijders To: Stephen Kent Cc: sidrops@ietf.org Message-ID: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 18:00:39 -0000 On Thu, Nov 19, 2020 at 12:32:42PM -0500, Stephen Kent wrote: > How about the following text: > > Section 4.2.2 > > To promote interoperability across file systems, the following restrictions > are imposed on the file names that appear in the fileList: > > 1.Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . > (dot), - (dash), and _ (underscore). > > 2.No blank file names are permitted. > > 3.Single and double dot (. and ..) file names are prohibited. > > 4.The three-character filename extension defined for each object type MUST > be present and MUST be lowercase, e.g., cer, roa, and crl. I reworded things a bit: ----------- The following restrictions are imposed on the names that appear in the fileList: 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). 2. Each name MUST be suffixed with the appropriate filename extension defined the object type and MUST be lowercase, e.g., '.cer', '.roa', or '.crl'. 3. The . (DOT) character MUST appear exactly once in a name. From nobody Thu Nov 19 12:27:45 2020 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 452CD3A1192 for ; Thu, 19 Nov 2020 12:27:43 -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, SPF_HELO_NONE=0.001, 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 oX4eg-G98754 for ; Thu, 19 Nov 2020 12:27:42 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [128.241.192.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FF83A1190 for ; Thu, 19 Nov 2020 12:27:42 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 576A4EE01A2; Thu, 19 Nov 2020 20:27:40 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 8150844b; Thu, 19 Nov 2020 20:27:38 +0000 (UTC) Date: Thu, 19 Nov 2020 20:27:38 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2020 20:27:43 -0000 On Thu, Nov 19, 2020 at 06:00:34PM +0000, Job Snijders wrote: > On Thu, Nov 19, 2020 at 12:32:42PM -0500, Stephen Kent wrote: > > How about the following text: now with less typos: -------------------- Section 4.2.2 "Names in FileAndHash objects" The following restrictions are imposed on the names that appear in the fileList: 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). 2. Each name MUST be suffixed with the appropriate filename extension defined for the object type, and MUST be lowercase, e.g., '.cer' or '.roa'. 3. The . (DOT) character MUST appear exactly once. As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. From nobody Fri Nov 20 00:55:08 2020 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 6BD903A1AE5 for ; Fri, 20 Nov 2020 00:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 Xctnb4BccoZP for ; Fri, 20 Nov 2020 00:55:00 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D063A09B7 for ; Fri, 20 Nov 2020 00:54:59 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 729D5600D0 for ; Fri, 20 Nov 2020 08:54:57 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1605862497; bh=2/cIv+3tqLarSw/RDppHRoKe5BFC2msX8AHiWcjhTX8=; h=Subject:From:In-Reply-To:Date:References:To:From; b=pASsh3G0gcalc1YAvms4oIbtHEH5NTsIeC6K8FdAsAiMKo/ruTqKqCzMnVV8tDjGZ pLDXCVmqwv8fj4v/nNfIKYrwE6rXLIefZUjaY8V5dlYk3xkuIi8/9U4jrdsjqP/zAv GmDlmWQNf13TBFWAOayw3BeglJrFWURdq7LnkZk7HDlqF3wnNZ4AFEQPrA7o/HbL2c Z1qpgIsMMmjYJTqNLL3KVrmOEQ2W/kS7XKEXYqOr0sjdgCJ+Rjgfq41UtD3Hy/P53C 6zkoba8TO+ZbhCltqMkf9QvV3r5omaxWDeDnoNUFBOwF+sOotDUlTuZHb3yB1jHrBc pws3jfTHmD0xA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 20 Nov 2020 09:54:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72D12CAA-9A56-4C32-A8CE-6C0533DBCBB3@nlnetlabs.nl> References: To: SIDR Operations WG Archived-At: Subject: Re: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2020 08:55:07 -0000 Hi, As a co-author I believe my support is implicit.. What I wanted mention though, is that NLnet Labs and APNIC have worked = together on an interoperable proof-of-concept implementation of this = specification. The following blog post gives a high level overview of = the RTA concept, and how it can be used for testing today: https://blog.apnic.net/2020/11/20/moving-rpki-beyond-routing-security/ Cheers Tim > On 19 Nov 2020, at 16:04, Christopher Morrow = wrote: >=20 > Howdy WG Folks! > During our last Face-to-Face meeting the authors of: > draft-michaelson-rpki-rta >=20 > presented their document and requested (in meeting and via email to > the list) a call for Working Group Adoption. The abstract of the > document is: >=20 > "This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose Resource Tagged Attestation (RTA), for use = with > the Resource Public Key Infrastructure (RPKI). The objective is to > allow an attestation, in the form of an arbitrary digital object, to > be signed "with resources", and for validation to provide an outcome > of "valid with resources". The profile is intended to provide for > the signing of an attestation with an arbitrary set of resources." >=20 > let's have a read-through, think about applicability to SIDR-OPS as it > relates to the technology we build and operate (technology and > business intersection), and provide feedback on the list before > 10/12/2020 (Dec 10th). >=20 > Thanks! > -chris > co-chair-persona >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Nov 20 01:11:00 2020 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 D21903A1ADD; Fri, 20 Nov 2020 01:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 wMvX5ZT9lPrS; Fri, 20 Nov 2020 01:10:56 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) (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 560C13A1B44; Fri, 20 Nov 2020 01:10:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DaFUHHA03/0hSKdpYuVA+rfP1ftEi5CddKbarLh+gbLwap0VwuVftzo33JAE04PRSbxAp2L6uVOHVpNXI1ur0Kxt2W2Rc+/WabO43scdf66yLiKLNIsI7PTuZa2/5ITW1JBniRQGzvzoxUMk1Tl0AqIBzgaoocWewFPPUuKVaO5evvrcknxqKHa6uSbiA91wmm0KbLkcUXKdhASQOo2rm8uPjYyLiKZ7dqZbYINYyjUhP02n4w15s5peUCntj+kJFLqNQTVfkFlIzgC64HMy9KM6Up3IcLlBF8YGDfmufKi2AtqylKkIfZYY01xSrJTax9FjPNIKbI2eJ8el3MZmwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lh+kTw9J21sI611Ui/8GshKejgh75jq8hzpX5bL9NJ0=; b=BlnOG6lVAJ054qkEtR5hYtpWyyeSY3gOdaHr/8LWLwu2lVHM6Ij2CUEuKdgojFoGg0o/ZJxMao/xGOeEgo3KSwego5Jwr/vJOsb62f4f0vvlZF1iGL7pfh8n9Ay8KyJfy1GPfp0htD2ZFewvUifk5qwBl3Md76f5VAcWFlD1/PDoFdj1rJ26egGTsgcmvBzDdirS/4aluCfof3OZ80tbdOCy3vQ0XX8BVbESAVtOLqN2WSQ4GfSbfDdsPF71pQqmqNjXEi1jJ2OV96tL5QZjxwBb06+Wx1yaQfr0Lw2YJ1127eG9D5BOq78bxhah2cxZxL1Ixrn4JwurevCOFczKrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lh+kTw9J21sI611Ui/8GshKejgh75jq8hzpX5bL9NJ0=; b=cV7FygT4rHzjB9ujg4noyr1wsqWlr8zPG5zp4Titw6GtcAFO8wqSRgKMQQV+ajVwFzIHOEuL4O/76oSixakKrZ8KfMPkoiLbQbzjJ1Qd+PWybTfIh7vGR+iFXv5QuTPznxqHmGb2Tzm5kwtCvHTjakZTM+4Zf8eIot4c8Sv1G5c= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB9P190MB1066.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:22e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Fri, 20 Nov 2020 09:10:42 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda%3]) with mapi id 15.20.3589.021; Fri, 20 Nov 2020 09:10:42 +0000 Date: Fri, 20 Nov 2020 11:10:30 +0200 From: Ben Maddison To: Christopher Morrow Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Message-ID: <20201120091030.ffpkqhfhmf53wnm2@benm-laptop> References: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ogxnrde2mfi56hkt" Content-Disposition: inline In-Reply-To: X-Originating-IP: [165.0.73.66] X-ClientProxiedBy: JNXP275CA0038.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:18::26) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (165.0.73.66) by JNXP275CA0038.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:18::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 09:10:41 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f453a421-04de-4732-ac3f-08d88d3427de X-MS-TrafficTypeDiagnostic: DB9P190MB1066: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YocDlBKPjFEpbliQGz0d0sTatT5St63132yc1FxY7ai7370V8DFNg3HkjVxJ8DM0EEewipKpbnBi09EHcc+FeYf2i+PDGQz7OcQ8fKlw40r2muR6g6dTC668dvq93eNnSbVurbuBIecQqMmVKwlaVeHRJsagGvJEmuOvMvEcohppchsaielhwhQRIk1NrtJf+Smwtj/bpF1pIKkkO8nS0S3RitlkDrGY/6VxYitmHhKDWtrzWKZ9awpesx5//gkfi3Z3HoJPtk4J/8Y3HHr1C3/CwxB7vjAQsqWBIOmqhbUhuYFfPj+vqbzoQqkAYkbqUnojZabZptCLWPW4aKp031KDUHWv8wd6kywvR4Gu2s7AvA6etdmCVRQXem/E7fn3Jzgp+o4w2LUr7WwI/iuoPw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(136003)(376002)(346002)(366004)(396003)(39830400003)(8676002)(26005)(16526019)(8936002)(6496006)(54906003)(186003)(21480400003)(316002)(956004)(6486002)(1076003)(9686003)(44144004)(83380400001)(6666004)(478600001)(52116002)(66556008)(5660300002)(33716001)(66476007)(66946007)(4326008)(86362001)(6916009)(2906002)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: WDxLFG4upteG1ILlhJXKpVqLmGuIi2FHk4X2Lvy+oRIZb/SAtCprLGyPxFEJvoQxelgpTzHgnaL8QyQtxhrg3Os77FKQZrfwsIGaDGNVsWUi0a7P5UaGRa9KHztnhhdeuiWHAbtheevNG2G4moStpC1tAKxj4pdxA8j9qj3OS/Z975ZoiNQVZSgFjAOgm8TdfpMUHSizQcJAtFqwmjNHMO4cnOM19n8i2bodJ9hu+QAdxgoQ4miV4elbquP8eT2Jir2cKfikqIiJWZLij9eTE52+6O6flojUg5TrUT9Wd8Y5lG8c3xT5GhGTetNPZU5nAuiBjSWcCXNkr6q9vDlot5EV3Qc95rRLeJW/4DtUKiqmtokLWujb8hVqIgwsiKXNkpDkG9v6wgpJaEvR+soWihNuxbwqKJFB286SQifyiry1jccHenqUiJzuEg3G6hTKG8JYgygh4w94hhmBas9Si9sc8Kyi15MZlt/UDIontciwBwtkeik3bfvBme4Do7v24UvWDUcU6zzUCLt3RCBtCgS9gDnEG5st6TjyDAeHLEIirceNfDBje7EBybiF4qQUyrCT4wUp/BRSPUT7bSMwBJ3CI8xezs0+e6rfVtvN5fPx0rxuku5O5eEy+YS4Srm3d+AXO0XMGGP41HjqIeQ9vXMdnMS7642F/wIHMMPgsJjGAGopV6M0jZJsxAVEajzENS9CX8dc8AtmtdKURhy/xFFUkUdHS8hWYLUDR8jnkTrAL/ISLw6r1gwI8ao5nDiJXTkbug0YE9P2+RWQ6vW8ZasQx69X826LTwKm0cb/wgs0FBPe8mDEJYvdVHfJHMS6FXkRedOIQo/KRUxM14NplTotxkLIjCpOPS26kOr0+3biboK8SDfSCcijAXbH+hn4 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: f453a421-04de-4732-ac3f-08d88d3427de X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2020 09:10:42.4922 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nZr1NNbBpMLymXDQtheafF83+r4jYj1e+pcS0a5suK+dmvVjgd6Tla6Ag3yhx8ghxJRrSIwAxuJER9AwRBj37Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P190MB1066 Archived-At: Subject: Re: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2020 09:10:59 -0000 --ogxnrde2mfi56hkt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, On 11/19, Christopher Morrow wrote: > Howdy WG Folks! > During our last Face-to-Face meeting the authors of: > draft-michaelson-rpki-rta >=20 > presented their document and requested (in meeting and via email to > the list) a call for Working Group Adoption. The abstract of the > document is: >=20 > "This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose Resource Tagged Attestation (RTA), for use with > the Resource Public Key Infrastructure (RPKI). The objective is to > allow an attestation, in the form of an arbitrary digital object, to > be signed "with resources", and for validation to provide an outcome > of "valid with resources". The profile is intended to provide for > the signing of an attestation with an arbitrary set of resources." >=20 > let's have a read-through, think about applicability to SIDR-OPS as it > relates to the technology we build and operate (technology and > business intersection), and provide feedback on the list before > 10/12/2020 (Dec 10th). As I said during the 109 meeting, I support adoption. We have at least two immediate use cases for this: - Ability for customers (and maybe peers more generally) to prove ownership of their ASN - Ability for customers-of-customers to signal to us which TE/Anti-DDoS actions we should honor via communities for their address space As I mentioned during the meeting, the first of these probably should be exchanged outside of repo publication; the second needs to be published in the repos so that direct communication between unrelated parties need not be required. As such, I think a primary focus for work on this should be to flesh-out how in-/out-of-repo should co-exist, and how validation should be done in each case. Cheers, Ben --ogxnrde2mfi56hkt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl+3iAYACgkQOkYk/rSL aGAlzA/+JOdrseMkNWR604NVbR3pqAa92Wbhg+6jnn/ihWmO7SpYQ/5vfnlW9/QT FWrCTLtEcDYhRd2914z9k8t3CjoVMVkDM5Neo/pSAEGvCpWXf8nnPm2Qluwiaday I8lKhj2o+xeaVOp3z++qUX92UrSIV4oiDwzQJOHNcV3ETP1zct+kLJojaCjy53j2 tjiZOlQoKzc4hPlDM/eaXRH5AkaARObbVisrFQxwv+CmbfLCUzA55BErjOHm8w/m x4WbtiTBTAXokBvgfH3JXbSXCVaqr5XajTteGgMC4k8vuw+kBW4VR7ubfuFrX7Mh EZxmo4tfl33Ofu13aidMoWS4dUqfgl2RPBhmHOotpJdNBt/Z6Q1d6DJdjzkpXLPE V/aGjknyUmtx32xgjw76ootIC2aBRrG4/l0JsbTkkcq/kchUtraWtfT6OXLMDKF+ xntSCvKKb7M8NyoJh7bE7UTGBYV5eGC1yb9taKS1A0XjUnXAIfiuarsKGAvjBHfw SUdK70vXX4hPIKu8mEsWjbk+bb024LzyalPWuj4JXohto/G+DOeLwf2v9Q+65AuF rrbKAA1vwidno83LtuxTpDuN0BK1pZhEqJ7bKOTZGCBuO1lxGm+kIt9h1bIiNyXP AqJ6lPJ6RykV78zsHb4n83k3pMBaanaTbuA1Wpuv28lBpj9BT28= =UvQV -----END PGP SIGNATURE----- --ogxnrde2mfi56hkt-- From nobody Mon Nov 23 06:43:47 2020 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 827843A0D3C for ; Mon, 23 Nov 2020 06:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOqNOzrA4V-9 for ; Mon, 23 Nov 2020 06:43:44 -0800 (PST) Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (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 21D063A0D3B for ; Mon, 23 Nov 2020 06:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1606142623; bh=0DM7F70u26XOqHikLQRj1xddPsBLeav2UZfSCSdmqac=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=uAbntrQnKtfvswchfk0pfIxm415y5b1D+ozSixiS9ivB5BZoMYQfFaOdq05RlcdnEEPjZNFi/ZZFjdKiJVvJ72tfmJvLKA8d8855Ni2e62fm4K6QCa3ByODGCMMJReK2IpcreL41De86AU99cosI0YMx39waLHZXueFt8ZyznmS6pl2LunI8rINywxym36sDg158tbBumpD5jkGfyz8LJ3M8Lq4ySwLLfjPM+LG7TolqY25zJX8DoRa+CdywzVY0dcj433OPes1OskEOu8dGILnBvw+avcEG+QyfdSpIpFOgmGrTMtx16RsbN0S30CKzzXBHieZJNDzjuYDjRgKI6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1606142623; bh=Q4/5IkZ2ok9XIci79k/S6ge1LCdDZCYlWM1Yyu3nudg=; h=Subject:To:From:Date:From:Subject; b=juQgbZataCtaWszgbTmrkOaJn5/6NxlarSd/9js5ElLuyMKI2OYMCKPOJyfdFXlogDl9FtZVm6mr9VCtgfbB7rMjulkVYhChRn0G4m0v60FoXUjUjjvRYw16tRyzdD/ERYI/1Xdzbcm0ys0iAGbDg9MPKSunSgSOm9JcXxquPpB7EnxR/kpEHpFPrb2VMBSgXPvMQuZaALfofmxDkdCHK37OqMsB4zArUp1i3OTQrbtuNwg0LaFkY6Lsr9i6klNkhL9y/V8+km9lyjoADF3djsc8NOQ/AQfXkwjt8eLlySzhdp/ktC6L17Q2Ktz8rywN8sIqjrvR9Qzesylrf4uyFw== X-YMail-OSG: OVA81QwVM1kjnW20HdKW2wen7oGhpNaFEey6G9Ij2p4_jPTJR_LHR.9auVjTnal 2.Gz5k7WhHPTYKmumGohtW1kJAIymeI4doN_I_JwRUNn_p3r2iXVmxLgBB6w8HiLzo46cYy_PHZs kPiRyMxAeFrQh8FqzWCVliMnY.gts88MEDKG9ZOcu52xSzIF12oB4jUtcB9JELetDJ3gm3OjQdeD g13s6ha_5LTZsR_QwdI3Ba1bohIbAz6BOllCbFuk1rGC.583lgprQLSGb2GsItu77ZP61C0iBuLC UyV25hzLTRzapLzGebyqpfJgskCGlFJAU65ikPjHBBYN1EPpBm4yuqRJ0ph8.oa4gDO4UWYHEaHz KT1HC5XMSQ0e0DE.m9iWeZkv68xv29Ca4.RQWYvA1JVlvOCtxaAsux1fqdUsRRZhTqazM37k9zm7 IxRbjYELh.b9JqXCzEpZR5Kh1Wre.G1CdavwTvAdaFI9UsAQsmRc_YX5DVIP22KL6BZtS3Hc4I9y wStzoIy5ljxk5vZT.C.kfqwMNqzoEIDaEuB7ZFs3VTeAL11I8XO42p5WD1pUQ9DYNXTEY36GZyVN jcVVIK.l.9hVbEJZx0jpp7FGzntdCjkBNay5v.dOdlfKWPc21xbhqvFGVLyM_ZigqTPoCNa2jatP 5USdik5u7O3eB9DlcMY_8GIFD8uYpxndWx9mM9QpQYSh4JofykovZQ7byi5yUuwUXkwC4wBvCumV .E1tsvHTnDU0IFByTp9nVbw3PA.e1GvH.BflxD6qHsODjYF5EBkMevZlUQmS0CVqbh.qec3pH7Qy Aae_b4ZUcchISulxgszoExK5TYcUEUHr4yXHNScmFg.tthBUY2_7as.FuKzO5o7NKPDbm5P_60RJ 64K.nhQyOBOkdHZ0Su2Gqq9iHhPfNxsuvvCr3_vj6AVyvKS2uYPSb60beDQM7AqMBJvoogK7iI_C XFq1p1gHV71E7k1RBuF5hx68B5PE3Q0H0UkUqDWr3_uBUAenDYX_dqJ2PB1xB1TTkbqWw1iBCJGr LclfomZM_i5Ln3hpiyeW1lC.qLyXXUMfLsB9s1gkh4c2g4.xixXESNy7FQZ1v0XpXcZvC27MNQ04 XZbowF4U.XPueKHWWHrx9K3mt5gHeBIMiIiM.yZ.HenxvQJpj3AbkNeC3V4y3AHESlKX1BirI58O xZ082Kaclk6W9wkanTSD4LB8VnHypHCkBP6ork4H8Trc8TRM.Ydn2vUEKNdP9T0ov1GDP3A4ue7_ 3thTh1Ky4wpSzyUYs.e.eNgI18ojx5hEladx7EMNkzNDRoDPoSwkgOSIcALVkmRWC3Hr76TlMA1E Y1NllUva4iQBkxNj9PxK4UxBusEXuEWDIhGAJeXx03xmJgoiRYsbKTrRd0.LV6zFfO8yOkULt4mO nohgxprsJ8A9urtqmxh6xYjJWgo20WX3V84NkyPOMW10rYSK8DGHBUr7tWEhaeufBrH.FW72DyAy XQfWkB6Xlh4s6Iw8XWpkyb9Kxve0WDlDn0cQTCACa787LUMIyCjo5IRXhDN3B0gWPmquppy6Q3pg B444XO4mSmQnt._fgutEak9b5ZKD22aaoC8MJ_yt6yPIY6R4jf0swQNAKXvMjrxjJq8YvfIkhXqw 6QldXUQ3Xr0.DwuCnUkPbB9NECGj26U3s6Ic5jybFIWW5EOQvom4tZaHjgYIXtsLDJ1nZjJXq6Fi gu8elkFuz2VfTRWIinyPEnwixI22w5yOE2Ri_tMwEpfB48UO3iYe_PLogJ7UW9mBaN.U8UEciJ4M 21I.YgvUs_HcqNOc5Iq1Leu.7Up4w9uHopvRTYPLu3hhmIOHj5USMBrQQoLHWd6LSqm.Sa_zAxQ9 VYXarmC3JXbxomwa_bG3hcScY96sH74M4hpzMFDA1d3wpgWZbJ82cG6jq7puzrGnR3bcdNftRcIa tICxj28jC4OVKZmMegJohRkBZkkpg2xhPPWQ0W8XptrsVrmzxZDRrEAGjalvbHR6rq1A9YoD2OKA mINIcMBur2iloydoE9wWpz6sT5JXB6iwTrs8wqv5HFgRqXeTXkb.Jsmm0c2sfrFLK98lOXhw1vKe eVY8rw4drc4rLMQG5ePrmGcKbGhZtFzmcVux2qUqn.OQKDS0mxVSHrcu5Q0j6lM.VDnIT5RQ0ffg nRzwkRPILB0x.bdIhYs6_GiTJGqVuNBAUYfzpHgtSe50KpbSHTfOSm.mwf5f7Kt3sfobDPhwfL.k G5waUNyFJVt3DCAN9sli2Y46JT372jI1fB92ZC8c1lEPq_GiZRhJ8Wf7bO0SVBA81Q_jMpqoK8v9 FkwUEYgKo3JHWlWEWmv3MqqR9ZrZNCB9E.40SAhnQ4K6p1ai0.EfZ2KMwH56P0.wBL1343PziSmj o6LQbcQKEglouoSSbBu3ZopKRSg0oFm.J9.JhjXWannQrHkuXD0LyER13Zk7pAQbkCDMVPXxjL2S JnzJP85jk.6SmUmQTpbCSLjQihNbTjRSj Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Mon, 23 Nov 2020 14:43:43 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dd0109f565cf5e0af1e413fa387b9925; Mon, 23 Nov 2020 14:43:40 +0000 (UTC) To: Job Snijders Cc: sidrops@ietf.org References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> From: Stephen Kent Message-ID: Date: Mon, 23 Nov 2020 09:43:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.17111 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2020 14:43:46 -0000 Job, I like your more concise phrasing of the file name restrictions. I note, however, that they are not identical to what was initially proposed. For example, the original proposal did not prohibit more than one "." in a file name, except for the ".." case. Before I adopt your suggested text I'd like to see comments from the WG that confirm agreement with your version of the constraints. Thanks, Steve > On Thu, Nov 19, 2020 at 12:32:42PM -0500, Stephen Kent wrote: >> How about the following text: >> >> Section 4.2.2 >> >> To promote interoperability across file systems, the following restrictions >> are imposed on the file names that appear in the fileList: >> >> 1.Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . >> (dot), - (dash), and _ (underscore). >> >> 2.No blank file names are permitted. >> >> 3.Single and double dot (. and ..) file names are prohibited. >> >> 4.The three-character filename extension defined for each object type MUST >> be present and MUST be lowercase, e.g., cer, roa, and crl. > I reworded things a bit: > > ----------- > > The following restrictions are imposed on the names that appear in the fileList: > > 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). > > 2. Each name MUST be suffixed with the appropriate filename extension defined the object type and MUST be lowercase, e.g., '.cer', '.roa', or '.crl'. > > 3. The . (DOT) character MUST appear exactly once in a name. From nobody Mon Nov 23 07:00:42 2020 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 62B2C3A0E90 for ; Mon, 23 Nov 2020 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P7WRugV7qqF for ; Mon, 23 Nov 2020 07:00:34 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 028BB3A0E82 for ; Mon, 23 Nov 2020 07:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id: From; bh=6p6bLJrv1jqx8wS57pCmlQzmohYeyH/e9kvULc9W3nQ=; b=k50YGnyEtQDf3c2Lc7c8 pw9QD+AlwDz4W/7SR+aWppWd/grYRBQdbydKFNDlPsx8fle3oPcPhKBzLFRQhDOTJGRy2J9pyC8j3 BBk2OJmoabdcrgOHYD904x0w+VWKrlHcIFLufZQeD5vJK9yN/+tUBaGUbjA56CBIY9GIsK1WZGG1u Ng3i4PDShi2srblLoCGVRIkmmXFvpa6humxQk21aHIZlYvp1X+jcEd+amvmcyDSqdckuQUD3tatX7 kBY71cS+tpWXZ3IzWbH0AiGcH6Wu67b1L5CoJdjKzF0AuQzHnjK4/0BIZlBdESBJCaDeNqMP+5hM7 nK5oQiFKHN1YrA==; Received: from bufobufo.ripe.net ([193.0.23.13]:51422) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khDKR-0006qR-IX; Mon, 23 Nov 2020 16:00:31 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::646]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khDKR-0004Li-GG; Mon, 23 Nov 2020 16:00:31 +0100 From: Ties de Kock Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0145DF86-652D-4351-8CDD-BD1140EFB214" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 23 Nov 2020 16:00:31 +0100 In-Reply-To: Cc: sidrops@ietf.org To: Job Snijders References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1c5d8760b6bcba14b845495fb8d5988c9 Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2020 15:00:42 -0000 --Apple-Mail=_0145DF86-652D-4351-8CDD-BD1140EFB214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 19 Nov 2020, at 21:27, Job Snijders wrote: >=20 > 2. Each name MUST be suffixed with the appropriate filename extension = defined for the object type, and MUST be lowercase, e.g., '.cer' or = '.roa'. A request for clarification: Do you intend this to convey that filenames have to be completely lower-case? The current phrasing is slightly ambiguous and can be read to include = "each name MUST be lowercase", while the examples show that the extension must be = lower-case. Kind regards, Ties --Apple-Mail=_0145DF86-652D-4351-8CDD-BD1140EFB214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

On 19 Nov 2020, at 21:27, Job = Snijders <job@ntt.net>= wrote:

2. Each name MUST be suffixed = with the appropriate filename extension defined for the object type, and = MUST be lowercase, e.g., '.cer' or = '.roa'.

A request for clarification: Do you = intend this to convey that filenames
have to be = completely lower-case?

The current phrasing is slightly ambiguous and can be read to = include "each name
MUST be lowercase", while the = examples show that the extension must be lower-case.

Kind regards,
Ties

= --Apple-Mail=_0145DF86-652D-4351-8CDD-BD1140EFB214-- From nobody Mon Nov 23 07:11:18 2020 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 117613A0EF2 for ; Mon, 23 Nov 2020 07:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 f10Lo6UY2XP5 for ; Mon, 23 Nov 2020 07:11:16 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8B33A10C4 for ; Mon, 23 Nov 2020 07:10:52 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 5C789220141; Mon, 23 Nov 2020 15:10:51 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 0bbe1b76; Mon, 23 Nov 2020 15:10:49 +0000 (UTC) Date: Mon, 23 Nov 2020 15:10:49 +0000 From: Job Snijders To: Ties de Kock Cc: sidrops@ietf.org Message-ID: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2020 15:11:17 -0000 Thanks Ties, how about: -------------------- Section 4.2.2 "Names in FileAndHash objects" The following restrictions are imposed on the names that appear in the fileList: 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). 2. Each name MUST be suffixed with the appropriate filename extension defined for the object type, and the filename extension MUST be lowercase, e.g., '.cer' or '.roa'. 3. The . (DOT) character MUST appear exactly once. As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. From nobody Mon Nov 23 07:22:02 2020 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 20EA23A0365 for ; Mon, 23 Nov 2020 07:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 4XNO8LMeQh0H for ; Mon, 23 Nov 2020 07:21:59 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7224F3A03EE for ; Mon, 23 Nov 2020 07:21:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5C61300BB2 for ; Mon, 23 Nov 2020 10:21:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TPNtayW_H1MJ for ; Mon, 23 Nov 2020 10:21:54 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C7D22300B22; Mon, 23 Nov 2020 10:21:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Mon, 23 Nov 2020 10:21:56 -0500 Cc: Job Snijders , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2020 15:22:01 -0000 If no one is useing multiple DOTs in their filenames, this this is clear = and straightforward. Russ > On Nov 23, 2020, at 9:43 AM, Stephen Kent = wrote: >=20 > Job, >=20 > I like your more concise phrasing of the file name restrictions. I = note, however, that they are not identical to what was initially = proposed. For example, the original proposal did not prohibit more than = one "." in a file name, except for the ".." case. >=20 > Before I adopt your suggested text I'd like to see comments from the = WG that confirm agreement with your version of the constraints. >=20 > Thanks, >=20 > Steve >> On Thu, Nov 19, 2020 at 12:32:42PM -0500, Stephen Kent wrote: >>> How about the following text: >>>=20 >>> Section 4.2.2 >>>=20 >>> To promote interoperability across file systems, the following = restrictions >>> are imposed on the file names that appear in the fileList: >>>=20 >>> 1.Only a subset of IA5string characters are permitted: a-z, A-Z, = 0-9, . >>> (dot), - (dash), and _ (underscore). >>>=20 >>> 2.No blank file names are permitted. >>>=20 >>> 3.Single and double dot (. and ..) file names are prohibited. >>>=20 >>> 4.The three-character filename extension defined for each object = type MUST >>> be present and MUST be lowercase, e.g., cer, roa, and crl. >> I reworded things a bit: >>=20 >> ----------- >>=20 >> The following restrictions are imposed on the names that appear in = the fileList: >>=20 >> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, = 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). >>=20 >> 2. Each name MUST be suffixed with the appropriate filename extension = defined the object type and MUST be lowercase, e.g., '.cer', '.roa', or = '.crl'. >>=20 >> 3. The . (DOT) character MUST appear exactly once in a name. >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Nov 23 21:34:03 2020 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 6D2A33A0DDC for ; Mon, 23 Nov 2020 21:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 GKJrFLfsvfnH for ; Mon, 23 Nov 2020 21:33:59 -0800 (PST) Received: from out20-13.mail.aliyun.com (out20-13.mail.aliyun.com [115.124.20.13]) (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 D90B73A0DD9 for ; Mon, 23 Nov 2020 21:33:57 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.3163746|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.211977-0.000279342-0.787743; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047212; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.J-XAXsE_1606196031; Received: from 10.99.106.113(mailfrom:madi@rpstir.net fp:SMTPD_---.J-XAXsE_1606196031) by smtp.aliyun-inc.com(10.147.42.16); Tue, 24 Nov 2020 13:33:52 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Di Ma In-Reply-To: <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> Date: Tue, 24 Nov 2020 13:33:50 +0800 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D2C7BBA-3BD1-40DE-A0D8-21646D651262@rpstir.net> References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 05:34:01 -0000 Steve, I am in favor of your suggestion, based on our experience of developing = and maintaining RP software . Di > 2020=E5=B9=B411=E6=9C=8820=E6=97=A5 01:32=EF=BC=8CStephen Kent = =E5=86=99=E9=81=93=EF=BC=9A >=20 > How about the following text: >=20 >=20 >=20 >=20 > Section 4.2.2 > =C3=AF=C2=BF=C2=BD > To promote interoperability across file systems, the following = restrictions are imposed on the file names that appear in the fileList: > =C3=AF=C2=BF=C2=BD > 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, = . (dot), - (dash), and _ (underscore). > 2. No blank file names are permitted. > 3. Single and double dot (. and ..) file names are prohibited. > 4. The three-character filename extension defined for each object type = MUST be present and MUST be lowercase, e.g., cer, roa, and crl. > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Tue Nov 24 00:21:30 2020 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 6288A3A19D1 for ; Tue, 24 Nov 2020 00:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 e1SUIezU3tRz for ; Tue, 24 Nov 2020 00:21:26 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173203A19D0 for ; Tue, 24 Nov 2020 00:21:25 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 61CC2601C8; Tue, 24 Nov 2020 08:21:23 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1606206082; bh=BTb7BCIOURHxM6leJCVSC+0fIAjFgBFeLBavBzEnDdQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cqxtnhie/+a9buRvBPYDI2JKkZ0dD4LCt/67eN8vtB0vsKn4nBVl09kD3Ng0GYQrM e275yJ8YIHf8i+u3aOPS+fs84b0CGOrKEO1Fn9YcyO4nCaigQZ6nA3W+F0WNRFVEtE oLzEbGO3bsGbkhCReq2D+wc7RivUYAtM1TtKOhDzx994/lngsSuXZf6XWmQdKFfsAj C/RpWhCwEUs/mqhJOPeunk+Kra2vx1kNv3dJFqWXAWArbLkzWVPN9vL5WEEfpRmed7 HXCXh3mMj8Hsqe0mQhEPdWWj5cNLdpVHp8zwmQQWI/9S8R7jXhXgxfm1yb+Q+Yn44a /VXU1S0GNKWRA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 24 Nov 2020 09:21:20 +0100 Cc: Ties de Kock , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> To: Job Snijders Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 08:21:29 -0000 Hi Job, Steve, all, I am losing track a bit, but I believe this text below was the latest = suggestion by Job to Steve, right? Question / suggestion on extensions below. > On 23 Nov 2020, at 16:10, Job Snijders wrote: >=20 > Thanks Ties, how about: >=20 > -------------------- >=20 > Section 4.2.2 "Names in FileAndHash objects" >=20 > The following restrictions are imposed on the names that appear in the > fileList: >=20 > 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, = . (DOT), - (HYPHEN), and _ (UNDERSCORE). >=20 > 2. Each name MUST be suffixed with the appropriate filename extension = defined for the object type, and the filename extension MUST be = lowercase, e.g., '.cer' or '.roa'. I think we should probably have a normative reference here to section = 7.2 of RFC 6481 (Repository Structure), or better yet to the "RPKI = Repository Naming Scheme" registry maintained by IANA: https://www.iana.org/assignments/rpki/rpki.xhtml As that section says the extensions are supposed to be "three-letter", = presumably to make file name parsing safe. Not sure if that needs to be = repeated here explicitly. As a side note, while I am here.. I would also like to note that it's a = bit unfortunate that '.cer' can be _any_ resource certificate. So it = could be: - An RPKI CA certificate used for delegations - A 'naked' EE certificate (as possibly used by RFC 7909) - A BGPSec Router certificate At least my quick scanning of RFC 6481 seems to imply this, as it uses = the term 'certificate' without applying further constraints. However, it = would be nicer for RPs if these cases used different extensions. This = could simplify parsing quite a bit. And while this would be a breaking = change in theory, I think it could be done without impact in practice = since currently *all* .cer files found in the wild are CA certificates. >=20 > 3. The . (DOT) character MUST appear exactly once. >=20 > As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. Looks good to me. Tim >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Nov 24 05:20:44 2020 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 C0E083A0CBE for ; Tue, 24 Nov 2020 05:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxD-bOs9LYw5 for ; Tue, 24 Nov 2020 05:20:42 -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 956E03A0CBA for ; Tue, 24 Nov 2020 05:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=wpI+ZliWKastm7v8+BDJGabDAM5NgTk4/xlBiXZfzLA=; b=sBA9lkkaFhYT /7MNC9LIFy4rqYW2ofPri4zoJhBABozrFOgY+YqN5tLQ4hpMSl+b2TVs++8fKp8brSAKgrt7L6PxT P3G+N1sZCNqYvDHcuVI808F9gyqWJX2HSkpZFUpHutgMypVsBuqelq630SmINtH0a8nvgL3xHCErz Hz5FDA87NS0lHws9yOBv0M0K1fR0HzEa8rM6k6AU5HW4o9UxDg0uvmsWBPa+u8k3iTyMs64jXCFeL G1pgse3liUxLebguR3k7IoZI03bPxAmG32qIIB+LRIUHXp3DYuVot3IsBudkXW18SHpidpPBZ88Xr 5khq4g5aj7I5C8aZitvJgA==; Received: from allealle.ripe.net ([193.0.23.12]:51748) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khYFM-0001m6-Vo; Tue, 24 Nov 2020 14:20:40 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::136]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khYFM-0004hU-TR; Tue, 24 Nov 2020 14:20:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Ties de Kock In-Reply-To: Date: Tue, 24 Nov 2020 14:20:40 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e152a0938c22201691620927beeed855d9 Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 13:20:44 -0000 Hi Job, all, > On 23 Nov 2020, at 16:10, Job Snijders wrote: >=20 > Thanks Ties, how about: >=20 > -------------------- >=20 > Section 4.2.2 "Names in FileAndHash objects" >=20 > The following restrictions are imposed on the names that appear in the > fileList: >=20 > 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, = . (DOT), - (HYPHEN), and _ (UNDERSCORE). >=20 > 2. Each name MUST be suffixed with the appropriate filename extension = defined for the object type, and the filename extension MUST be = lowercase, e.g., '.cer' or '.roa'. >=20 > 3. The . (DOT) character MUST appear exactly once. >=20 > As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. Looks good. However, after an internal discussion during which we = realised that empty names (e.g. .cer) were valid filenames under the previous = proposal, and after validating that all current valid objects from the major trust = anchors adhere to our proposal, we would like to propose: ---------- Section 4.2.2 "Names in FileAndHash objects" Names that appear in the fileList MUST consist of one or more characters = from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a = single . (DOT), followed by a three-letter extension a-z. As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.= From nobody Tue Nov 24 05:29:30 2020 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 DCFD03A0D45 for ; Tue, 24 Nov 2020 05:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfVhgXfXeoFH for ; Tue, 24 Nov 2020 05:29:27 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 25B003A0D44 for ; Tue, 24 Nov 2020 05:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:MIME-Version:Date:Message-ID:From:To:Subject: CC; bh=BbUAVDzGjgCG3FqOmJyoUpWb90vHroc9CjNzqEbnkpg=; b=Luu8Im3b22IxGqh4sKqWxg qMbvee2LKTGyGxPzv3e1B1CafzTnpzqRuk6EQj9lOcfo6uiuIW3uynF6VCjCqVaaFVuzDVp+8yo5l BJa2qSNrhTSSU7oZhNIEJm6Kun/b8CGvk5cCB9yq0A5UuXWM2ToBm2IWXGOHnbhkXTBmyBkkVni8G VWp3/HHotanMxHhtCbjg1B9NqqcwzxiyxVeLgQll0U14NWZdek+84zRQZzi30lo1uK8UmTX5P1B1P i29SBJ5lQcaYA+KS2Wh5lcL3uLURuRL/wfRYRLdCVL30sK1Mb7b5xV9kSJJW3fXZnOf99ISL3xrW5 uAawIu8+V52g==; Received: from bufobufo.ripe.net ([193.0.23.13]:58288) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khYNp-0005lv-S3 for sidrops@ietf.org; Tue, 24 Nov 2020 14:29:25 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::aff]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1khYNp-00068L-PH for sidrops@ietf.org; Tue, 24 Nov 2020 14:29:25 +0100 To: sidrops@ietf.org References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> From: Robert Kisteleki Organization: RIPE NCC Message-ID: Date: Tue, 24 Nov 2020 14:29:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2747d2a27f8077b27bd418cc82affcccdf3 Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 13:29:29 -0000 >> The following restrictions are imposed on the names that appear in the >> fileList: >> >> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). >> >> 2. Each name MUST be suffixed with the appropriate filename extension defined for the object type, and the filename extension MUST be lowercase, e.g., '.cer' or '.roa'. >> >> 3. The . (DOT) character MUST appear exactly once. >> >> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. > > > Looks good. However, after an internal discussion during which we realised that > empty names (e.g. .cer) were valid filenames under the previous proposal, and > after validating that all current valid objects from the major trust anchors > adhere to our proposal, we would like to propose: > > ---------- > Section 4.2.2 "Names in FileAndHash objects" > > Names that appear in the fileList MUST consist of one or more characters from > the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single . > (DOT), followed by a three-letter extension a-z. > > As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. At this point perhaps a regexp would be simpler to specify? I also note that both miss a clause saying the filenames are case sensitive, thus 'vixxBTS_TVXQ-2pmGOT7.cer' and 'VixxBTS_TVXQ-2pmGOT7.cer' are different certificates. Robert From nobody Tue Nov 24 06:43:03 2020 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 80E073A0F4A for ; Tue, 24 Nov 2020 06:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-gHU4eit6ih for ; Tue, 24 Nov 2020 06:42:53 -0800 (PST) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.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 0CCFA3A0EF6 for ; Tue, 24 Nov 2020 06:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1606228968; bh=z0AGKseTr5egVn/zzetyA4mKc8eH79pxaUzUeOUWWO4=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=FI5W+LLKbSxmjl2txyPAWM1z/Uzor10Po431I7n4dVkx8MPhffPQlkdIe/NPwWhM6gDErtOPBoS02Dsd/q5Wog1ZwFfb++1Y80gSCNlcUgpzL56EfGi7f9uZfq2dRUYZD7+iWnPKaSB4wkX4v0uC1xpnAouwTnrJJQzlHvp2NPaHBQs1KU9azz9W32FaiG2wwYynH9uUO5fhQjlnpTLki6uaau/jGFSubmdwBWCTw1y0e6286voAOzhSWnDmypukan7BpRnxNDVkK5UQi6umkkCVtlqD4aTC/BsElqzp3wKiRN6SFzqno+/ekSbZNlLxTX8iclEf8/BR6dGQdJpr8w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1606228968; bh=MJZf6+2XA/6Wo1NbhRYjTxu4U4QF2FiZHBkD1Z4ps5i=; h=Subject:To:From:Date:From:Subject; b=Rz1ZL7PNkCyKWwu+Qst/cKsmKWgGakYY1Pz8VvhUPFEbbN+Sfvfz2qe9LIT9fTH39uvcDpSk8e1buKk69tnJ4FyEvbbipbjEYDzYSkLDjuc3dB4uCpUy7KHArbceklGv7vagNPwJj39Xx2McShi8AZc6SSWjF7zHsF/ZbIlfqjUpC3A/lVRZPLkek2w+MWPpbdw/23ALH1jgxqUVMpJp186X4kT/KOE77bDGDyx9tg8Ustr0AWLoRsO/1bAmm4hHZ88XOpt5YeE6CshU77awBrQF/N962IZJQpwqyPvrk6ErmXQA2WwRsPC/yDfP7Po5Ly3bU4f3eDEAdkOEsBKX5w== X-YMail-OSG: sUiPk4sVM1mLnlaloy8eBb7KhODdd_.BTMQp_9ZYrwB6G8thde1d9ftam146N_r G1U.IPlANB7EqHXpuPSZ_JY01TLcxpP4GgQGjrs2VkgP9WpXZcYjTEf.8OvfSMHd1glmSC8Swb.U mzAr30G4XvVfYiEaCofmkqr1CCTWRYkNvHSAxpNQsYY34rYnLRBUXNY1d.PerjUoKAbzH0ymnHln M13_3yDV1EqS1L5wW3.Jg7znUpsOzCYbznVFpp3GFdI_dk5OFAjBQvb3M1kiEqmhl4LsUQiw01kl PisVpsNvB.pQFdtVGdS8GbJP364oEno4jHT83ehPyPcMhsuOASsoXhoO0HYlGsb4.lRGGTEpA2tO IBgO.lce.qwQaA.i3wEFcoLunXn5wyqOx3raqW9Votk7k5T.PIbzaMH8u1YgybvdIlTsZsMoC85s TWequa6Fjqm4CJi50unYf.ii0PsY_t0Xpi.VeCKCloXkUvan9eaFB9M9o1zvpH2egpKnUTmOmuD7 6tCQAsHnlFSSf839V8R3365_n0Qc7OsTrmLRoPMs9.u5TZtdpDqf8qYrbLuAq.yk3T_mgR.xLubV HbqKj0Nf54I.AJQ7hDkuX9fB1DbVVbFM7huvY_cb63QENRRfQn15g03Zy3nl.rgQ6997pH1MrLAn Cd9RYxjD8WnAshJPF0MOksvhdbv9KaGLucAUos4En3BNbsU14r5MdxBeIfvlJleFJE5IlhRwWKWc ufb8aOmHP1PzwcUYwJVUGmTkZkoLMwTNRtczll7.rs3mLQWffuLLa09fS47wmOLoU_CH84fyUTH_ 113TipfEvz8.XSK1K3jKh73xc3uVYR9cGNy.1P.QkLW9a2odFiJdHl7RFNIG5qxTqyG3eaFNSbVp JW6d2MXXQt10KDsll0Fb6NXxwZvrHvEarLcMItO83liHc4KS3VaS8_1foEoEOaIOWjYOwy66_Rio LsrJ3Qfusoi48JTdKD7AQShhDZc74bKaslzaZ6l2Ti6cOEVvzW6cpXu0Ddojo_cFiTUDH5L5Kmi6 A2ZI80sLOE0gKBKgjTyYBUnvyJIxOwM8gfIfcwMC7YVbUmyw.lIU9LQ_V9BKnzj.A1cQbrX761Iw V.ETNaxL5ZXMf3182zeH6atbeLx3NsUO6FVRf3MdCpPpx9O5GA3ApdAvUr_iA9Y_7HSVf8zY8Sm0 B2JIUhNQ4obJo3UTgP99XbTyHWNWRP0Zw8a0PcqJdKmmQD4P9hZN7rQ4O8EbPx5m5dbHDajp7w3a YlikybSlRE0RB.sTwdL891KSs2pcE9A8Av2x53t4mYCmDZ.DJK240LZpdLrhZqwK0RAICLJqLaHI GExT0DR6ZlFao_nUafF8nARQqkmjFfdxuJ2B9M5QmQ9UPaoM434BK6FSXjz1dCvMi.OyUzTd_8hi EAiZbBjBUHxJX5JXUbL5xsYV1IYFMMZN3u1je1.0l9sV98hE7p4G1XcSMqDY00vSvUHe5fIjVxZk LGNP3mv9Uo4jxnezpRpxPGblez5zbOlGx9b5tVWhgNp_WrIjd0EqHO2hv0WgOm.f_8Fam5kAVdou geYO4WsR8adKIkSjniXtHcStNG_RhJotns4.XTzmfRViB.XOCDNyM25mCa1e6eFIZUaosE_cjEzW 7qVWiGuR8c6PJsZ7HSkeM1X2jY74WrAaU7DxdqTyQbNWV.0XA_YYa2oavi6rnbCD2EroLipApjKQ SjGo7L6WkgfYopv37ziquEzfp3mwLOmyxgKaxw2le61rB9bOzrGJhWh1SRvDIfpDnpjk_04xr7gO 0rUsWtFiJmJs1jz_KeyDSlj7opilsXbQVCGo_iEE6CUVltjANh3cKRGb_pVX5hSDEtNJCwfv3WAz xkmuLBwxl4Xu8_.2Vb7NVeiHGZJKKraJhDqHMgwDwgFSQCouNnJtVQ.BvV7BnhVhwGRlv7YM4zkT _N5swPmKZWSeWH_iI_zH9VC_8ZEVXer6MvCmQ20FctpAIDPsmLs971gSgfRVpZmZesKHs.QMzq00 AgbCZ776g_5bnkEwIuLSozjGsnF4h.dFQXKyJ6Svmt3trg1EF7sZGy8_7Vme.LUM96.oINVpsLwa H9ItnVWptiL.n5BBD_D8QGSz1rGgnyqM.c6KLi4_lIpjgfxBJueID_3g4fiPTATRfr3F2dUN8sgg MgPk5sLK46tJWc_x0g_V7nbzVG15GIz8IgzpXKnCWrQsjraUs3uA64IgatX_QaahPhENs60LS19n Kp85xylgzwRjbrwbFIqz1qKWz6Pw5ALhmp1lPyO9kiMKQPBiOwqJF7lmoDMF6fR1wIh_ZRE95GA9 nyqxb1tTvPYFk9FzkMS3i5XyNg0CPQteWVD6GW6CaIOZN23f5mQvQnLimaezGBEUu3aWoQpcGZcM Plx.0awh1dKmPHn94jskq_QKbSZdcNNlB6dHknEJjPwvp_o_QMDfKLYsMGXRPmw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Tue, 24 Nov 2020 14:42:48 +0000 Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f8286e597b081bbd3cec7168966b128f; Tue, 24 Nov 2020 14:42:47 +0000 (UTC) To: sidrops@ietf.org References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> From: Stephen Kent Message-ID: <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> Date: Tue, 24 Nov 2020 09:42:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.17111 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 14:43:01 -0000 Ties, I think we're getting closer to a rigorous description. I like your concise text, but it doesn't cite the relevant list of allowed extensions, as suggested by Tim.  Also, the requirement that extensions be lowercase is redundant - RFC 6481 already dictates this for manifests, ROAs, CRLs, GB records, and  (all types of) certs. Thus I suggest the following: Section 4.2.2 "Names in FileAndHash objects" Names that appear in the fileList MUST consist of one or more characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single . (DOT), followed by a three-letter extension. The extension MUST be one of those enumerated in the "RPKI Repository Naming Scheme" registry maintained by IANA [IANA] As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. add the following Normative Reference entry: [IANA] https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes From nobody Tue Nov 24 07:03:35 2020 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 505DF3A10B4 for ; Tue, 24 Nov 2020 07:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 kDcTyXTgrIf7 for ; Tue, 24 Nov 2020 07:03:33 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90713A10B1 for ; Tue, 24 Nov 2020 07:03:32 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id B6042EE0140; Tue, 24 Nov 2020 15:03:31 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 2d0cce22; Tue, 24 Nov 2020 15:03:30 +0000 (UTC) Date: Tue, 24 Nov 2020 15:03:29 +0000 From: Job Snijders To: Stephen Kent Cc: sidrops@ietf.org Message-ID: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 15:03:34 -0000 On Tue, Nov 24, 2020 at 09:42:46AM -0500, Stephen Kent wrote: > I think we're getting closer to a rigorous description. I like your concise > text, but it doesn't cite the relevant list of allowed extensions, as > suggested by Tim. Also, the requirement that extensions be lowercase > is redundant - RFC 6481 already dictates this for manifests, ROAs, > CRLs, GB records, and (all types of) certs. > > Thus I suggest the following: > > Section 4.2.2 "Names in FileAndHash objects" > > Names that appear in the fileList MUST consist of one or more characters chosen > from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single . > (DOT), followed by a three-letter extension. The extension MUST be one of those > enumerated in the "RPKI Repository Naming Scheme" registry maintained by IANA [IANA] > > As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. > > add the following Normative Reference entry: > > [IANA] https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes OK for me, thank you all for picking at this until it looked right Kind regards, Job From nobody Tue Nov 24 07:12:09 2020 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 8CB2C3A10D4 for ; Tue, 24 Nov 2020 07:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=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 DCQmHKHGUvOA for ; Tue, 24 Nov 2020 07:12:05 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A973A10D2 for ; Tue, 24 Nov 2020 07:12:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6A325300B96 for ; Tue, 24 Nov 2020 10:12:02 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xgYzrzDLLjKI for ; Tue, 24 Nov 2020 10:12:00 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id AC6FD300670; Tue, 24 Nov 2020 10:12:00 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> Date: Tue, 24 Nov 2020 10:12:02 -0500 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3324ED41-816A-4EAB-9629-6C2712F9A58C@vigilsec.com> References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 15:12:08 -0000 Tim: RFC 2585 is the document that specifies the conventions of ".cer" and = ".crl" for X.509 certificates and X,509 CRLs, respectively. Russ > On Nov 24, 2020, at 3:21 AM, Tim Bruijnzeels wrote: >=20 > Hi Job, Steve, all, >=20 > I am losing track a bit, but I believe this text below was the latest = suggestion by Job to Steve, right? >=20 > Question / suggestion on extensions below. >=20 >> On 23 Nov 2020, at 16:10, Job Snijders wrote: >>=20 >> Thanks Ties, how about: >>=20 >> -------------------- >>=20 >> Section 4.2.2 "Names in FileAndHash objects" >>=20 >> The following restrictions are imposed on the names that appear in = the >> fileList: >>=20 >> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, = 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). >>=20 >> 2. Each name MUST be suffixed with the appropriate filename extension = defined for the object type, and the filename extension MUST be = lowercase, e.g., '.cer' or '.roa'. >=20 > I think we should probably have a normative reference here to section = 7.2 of RFC 6481 (Repository Structure), or better yet to the "RPKI = Repository Naming Scheme" registry maintained by IANA: >=20 > https://www.iana.org/assignments/rpki/rpki.xhtml >=20 > As that section says the extensions are supposed to be "three-letter", = presumably to make file name parsing safe. Not sure if that needs to be = repeated here explicitly. >=20 > As a side note, while I am here.. I would also like to note that it's = a bit unfortunate that '.cer' can be _any_ resource certificate. So it = could be: > - An RPKI CA certificate used for delegations > - A 'naked' EE certificate (as possibly used by RFC 7909) > - A BGPSec Router certificate >=20 > At least my quick scanning of RFC 6481 seems to imply this, as it uses = the term 'certificate' without applying further constraints. However, it = would be nicer for RPs if these cases used different extensions. This = could simplify parsing quite a bit. And while this would be a breaking = change in theory, I think it could be done without impact in practice = since currently *all* .cer files found in the wild are CA certificates. >=20 >>=20 >> 3. The . (DOT) character MUST appear exactly once. >>=20 >> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. >=20 > Looks good to me. >=20 > Tim >=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Nov 24 07:44:53 2020 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 A16E43A110F for ; Tue, 24 Nov 2020 07:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 ljnnShIl4XtI for ; Tue, 24 Nov 2020 07:44:49 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD5C3A110E for ; Tue, 24 Nov 2020 07:44:48 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id C2B276029D; Tue, 24 Nov 2020 15:44:46 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1606232686; bh=66SMSajjrjYE1eAQZTjTAmLkqclWZCBwpB+lusa+L8o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gg2Gt/MisLqNQyzqnetN3cc/kpF8HBepAd/3NEd23hNDLD18o23X2prsLttcCzU5b 1kE+AiJd9DFDGPUIlmoal1L5L1/lQNvWcBGm0x9bPn1+VmiS4Mm8pLrTly797/XSkc xx2L8K8FpbO5LaXw1S37gXPRd2+v1zPcBGRMkYh8c3EoXdMloCFojJvfZdaUlq2IxK dt6Bbf1JA/5WrDDGh+wN/hU8kIlXBFATJ5zw2fCiJX7NKrEy9fZV5IVD7RZY1kMJrP 5Vhq/uL1E6qXYlhP278SRN78NgGkCLlQ4xstCJpbrJ5Gp1+/BXbnTuo9NlEiNC9QW0 5XqZ/o+n4TzTA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <3324ED41-816A-4EAB-9629-6C2712F9A58C@vigilsec.com> Date: Tue, 24 Nov 2020 16:44:44 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> <3324ED41-816A-4EAB-9629-6C2712F9A58C@vigilsec.com> To: Russ Housley Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2020 15:44:52 -0000 Hi Russ, > On 24 Nov 2020, at 16:12, Russ Housley wrote: >=20 > Tim: >=20 > RFC 2585 is the document that specifies the conventions of ".cer" and = ".crl" for X.509 certificates and X,509 CRLs, respectively. That may well be, but I still think it would be useful, in the context = of RPKI, to be able to differentiate between different types of .cer = *before* parsing rather than differentiate while parsing. And if we did, = then an entry in the IANA registry "RPKI Repository Naming Scheme" could = be appropriate. Anyway, I don't want to complicate things - if RP = implementers don't speak up that they want this, then I would say we = just leave it as an aside.. The other more important reason for bringing up that registry is because = it already defines the extensions one can expect. So I would suggest = that the following in item 2 extension defined for the object type Becomes: extension defined for the object type in the IANA registry "RPKI = Repository Name Scheme"=20 Tim >=20 > Russ >=20 >=20 >> On Nov 24, 2020, at 3:21 AM, Tim Bruijnzeels = wrote: >>=20 >> Hi Job, Steve, all, >>=20 >> I am losing track a bit, but I believe this text below was the latest = suggestion by Job to Steve, right? >>=20 >> Question / suggestion on extensions below. >>=20 >>> On 23 Nov 2020, at 16:10, Job Snijders wrote: >>>=20 >>> Thanks Ties, how about: >>>=20 >>> -------------------- >>>=20 >>> Section 4.2.2 "Names in FileAndHash objects" >>>=20 >>> The following restrictions are imposed on the names that appear in = the >>> fileList: >>>=20 >>> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, = 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). >>>=20 >>> 2. Each name MUST be suffixed with the appropriate filename = extension defined for the object type, and the filename extension MUST = be lowercase, e.g., '.cer' or '.roa'. >>=20 >> I think we should probably have a normative reference here to section = 7.2 of RFC 6481 (Repository Structure), or better yet to the "RPKI = Repository Naming Scheme" registry maintained by IANA: >>=20 >> https://www.iana.org/assignments/rpki/rpki.xhtml >>=20 >> As that section says the extensions are supposed to be = "three-letter", presumably to make file name parsing safe. Not sure if = that needs to be repeated here explicitly. >>=20 >> As a side note, while I am here.. I would also like to note that it's = a bit unfortunate that '.cer' can be _any_ resource certificate. So it = could be: >> - An RPKI CA certificate used for delegations >> - A 'naked' EE certificate (as possibly used by RFC 7909) >> - A BGPSec Router certificate >>=20 >> At least my quick scanning of RFC 6481 seems to imply this, as it = uses the term 'certificate' without applying further constraints. = However, it would be nicer for RPs if these cases used different = extensions. This could simplify parsing quite a bit. And while this = would be a breaking change in theory, I think it could be done without = impact in practice since currently *all* .cer files found in the wild = are CA certificates. >>=20 >>>=20 >>> 3. The . (DOT) character MUST appear exactly once. >>>=20 >>> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. >>=20 >> Looks good to me. >>=20 >> Tim >>=20 >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Nov 30 12:22:11 2020 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 ED10C3A112E for ; Mon, 30 Nov 2020 12:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf0mS4GMsWCu for ; Mon, 30 Nov 2020 12:22:02 -0800 (PST) Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 88BFB3A0EF3 for ; Mon, 30 Nov 2020 12:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1606767720; bh=VITjYtTZD0jT6auQdwNzGFg188S0KfJH1gfgEBapwxc=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=OLeKZTQqFpmUElpV+PmK7C5lTMc29vqO2hwOfRTwOmuckeSY7twKXbqrTVgzi8lHTyisvDPQAts86ABoc+hFr0ghE3OfSinsizEp6IQOJDzzBmmAd9wN1TES6h1cxFpS+rGirhWYdaFDFbhncyNvPtnzVPuIGM/0JfS0Fn5zrSt4E5cv8IgNuIwxQpogLwYPAs/e/m0aMNCZdvF9xtmAM42y3/Q62lVVMKuqy6wJFScFEsg+C6xtIj2DHtDfKscJR9l8aHWZZKrVhp2Xtx8DzwW6ltJci+CJMLkMijOvc0tMKOdLSqaL8WcfFG7wWs3jxbsbtsH65i8qb6kFhTCD9g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1606767720; bh=WPFwBjG7euCefCvucIDR5OyXQpxfAOeZzT05QFM3rlc=; h=Subject:To:From:Date:From:Subject; b=Zy2F39Lte8ZDZ/2fEizQkaf3KBojnii3Ml1FO3ummTXAA6Wlg8RGpi11j9R/esyveJM0Yr6P0IigEFGcfn0hcjWXQRWLUh6uS71mCKDIPugmRbd8l+PaknbWzWpHeS0ZcC8ZtRiHeK4GOYsywundCMgjnEh95axn+ukoNrmXSRyr5tuYETNdByBclCJcW3NLGSBI1kUQ7FwF5PpSWgYFjUGxUUmceBEZZYvcX43lqfO5SRKF7rQrYvUjmnTBzNpDa+Ny2PPIwckUmRfxACXojQ5ckcIzkOzOeArCUeIbOQc2p2U50BgatMprehgfIj727/6RpwyObqxmR3SgQCxZ3A== X-YMail-OSG: HVLMO4gVM1kUuocXoZuIiQOaPUi2_BbsflrBxh7V7nL6D3CsAuTDxb6ynLHcAs_ 9UZfM.aYVgtDI5aCiw1DKGOR5dXKDZbOXYtMY1kxF782lZBW9Y3m9bjn2mnXw6.5E3D2x0H_w.s9 zxL6JLMHHiNA1V3gheBlpKNNSj9UoTbA1kIOX_p0x5APWa6DuLRqgsnrmFeA7hEP9Qh9MoIdAFp4 hyVtum333Mjh4zQoOEDav5ZBTg6o1MX6ZCWhjUeWbmwRWiqsHBCtlW64t9WRPUnoPIDDp1Uh2nzs Mr3rRdlhkGNZ_mE.CewkS9xJJxwHUs.bYPfD6LUlcy79_wG443vlwL0Go3ZgItuPMK4Tk0lr6r4p 7ej9FvmY3w9uHzkxehR41ANAgrWrf477AtRMRN6weaijrdSOLRHw_yx.mmbNBkk0ofVX3SRegCNh lkkNGDEW_xCXhq_BuoV3oI1Oe3hfs_jjrVAnp8k8rwKDnpy.MiWT58PtJ67uI9uFir9iOv9q76ek MI6CQPjRgB_szPOpV3I5EkLAR2q_OqR6SgkKtwFziC0l7l9JGMO4Np.coi3x4J_3Bn5xmWWDmlCi NN2dlkeOmzbo1336ZKVuM7QmcmgVrH1dNZaSnOYqnhjzWKh8rDDY4y5AY.MfvCEMAWtLN5eZRwE2 d7ocJ_hWeBPML2qULdvwSTMR0hrmxZMUKO8k8Bczh2eEU8_tSt8cIwtoXl9hTQlTEyoYk8w6nRu5 iwqiUznjUNCrJHyKAMFBtIUlfPvWRfce5EVfoykpIe8iKDRclX4sLoz28LRPTHRNsudMwO3cX0SA n.uhuieVdWWEI3kRi4KkNNzxRaFw7CTf1v3w5IPidv5dTe0lArH4c8GOXRcrVI7WWKHg.wOPzD3i nx9DikFgVVKFUR8b2c5SYfDylAHl2uOjiUXwBgWJ2bAtcD.AwuIfEWRcmGcX3XJj2A4tkEfoqCyV VrYRCPryK_Wm00slzA6jGn95tUbwm6wfPfO7StxljLjawu3rEaoiPKq5IKeHsGH0P2vWy84VN75J Nuj02ZagMiKRGuN61pdApr1K1fTE6km3_u3i2sDJ4.QS2sXzuIPDNbfIFNaHLRWXOFOWuaUmtmkV FNKD3dAAyisha2atVVU8HZb95XOFr2EnwFTJVz9xKF_3iEzXzOqqhQHze3vVt8_gAWWFI2xl17IY rk.3VjUxHQbTnVMCpj5JXT9N5KDHlr81HAb4M9NWtnZork1QeRMVh3._ePclUU386iFEPrzc7jt_ 5yYCcNANK97FIXIWKIiDdlXzOaoEMJkOMNONrMrwclI1vgG8ZpMwVdzbc11WOLBw5Ey04QrmOZZQ wlKARrta7qCpEbULPFbsTUVpBynTOT1ug.qvGGTn8mAt9s3mHtD_SilRGcGknUh97IgfvCXcTMKj ozjs16BzXFJe1cqVfnqvXS82io7VxrklNZdJxLo2U8e9Gx5FGXN0PZvIZynyqsI0B1j04vuUYSyk hnSz77vga1CztOvj7VepU6aQNg.r9Prc1rra5WXfX4MW6j9HcmDqQXX1S_qJWwXllTKs4VH7qw38 WrOB2HBGWBI25uaIn46Z6GDyoxv_E6LDJkky1QHNfjZOv_yKZ42soJaGT_yn4h96libn1Rfr.Qn0 YLUrRVjDL20EJy2j1aZ.8u5elgkzHvcIIOkBu3bYlM0ZjZwTvwTmwVF4aGuORJvZrsT56nGcK4Jc ZMN1aSfP1TqSI.S3cb4YaCZAHKPxBeGY8RbWxqZlFjhVKZb1meBT8rImc2_0UQ_d7R7ss1p0faux pgSBBlk5WioRENyYH7QSt4dViTxuDM8HIVx5WFsQGLancaSBznspx4zkhDJsS.9Y8eu2HyBnYa9m khxCbsEvixEeHMF_naxnbjLV4KeCxV2AtNREU3kIv5rOPxGpVQtE5T47Qm_xBiQEGJqgA4rEOj2X 92TXWWUcUUxeyKVYxNzUfZPRQOqo4SFnUCl92nUW32tsexJy_eKqdhjB_kpZBXCOMQRSR1869_Yq q7zES83QFuEBCbQpufSbFUaKRWtJuKOCgNfazyScvGLbk35uoCHM.6jz8QPvTvhe5phPUgIa6e5b XFQnz2dhQ4VPsTJlfiATVD6OT_EH1K8kcltaszw7xczV9q5IjOy1xF11qf539Htd4VAcGSak7pmv dW4lrVAtREnmdoUeifEtsBAXakiN.u9hWXTT3IrVWUtXM4vOU_sPyE9jfd0sgPbrDXku5U2pRPjw BQrXYgRYMFctEqlghg166C.TqQb0Lhg760RVKmtOPegb4B6LAabLwlEppyKqi9Q6qbZYpsmxrWen 9jWxK9Ooh9RbcEhbvILXHfCMg2hr2gpIAqaP12Pum1GIm..s8lbdftvmSjBpiRNG1faHtE_1Pf9R AfdI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Mon, 30 Nov 2020 20:22:00 +0000 Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 753383323b60d2750295413440d1b014; Mon, 30 Nov 2020 20:21:58 +0000 (UTC) To: sidrops@ietf.org References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> From: Stephen Kent Message-ID: Date: Mon, 30 Nov 2020 15:21:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.17111 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 30 Nov 2020 20:22:10 -0000 I've seen no responses to Tim's suggestion to create alternate extension types for certs used to other purposes, e.g., router certs, so I will ask my buddies to issue another version of the ID with the text below. Thanks to everyone for their contributions to this additional, clarifying text. Steve > Section 4.2.2 "Names in FileAndHash objects" > > Names that appear in the fileList MUST consist of one or more > characters chosen > from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by > a single . > (DOT), followed by a three-letter extension. The extension MUST be one > of those > enumerated in the "RPKI Repository Naming Scheme" registry maintained > by IANA [IANA] > > As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. > > > add the following Normative Reference entry: > > [IANA] https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes From nobody Mon Nov 30 13:40:22 2020 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 AB2033A11D0; Mon, 30 Nov 2020 13:40:16 -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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160677241666.17348.5041783535108113136@ietfa.amsl.com> Date: Mon, 30 Nov 2020 13:40:16 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 21:40:17 -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 : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-03.txt Pages : 18 Date : 2020-11-30 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-6486bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 30 23:25:15 2020 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 545FE3A02BB for ; Mon, 30 Nov 2020 23:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 8QVXt_XM8LXk for ; Mon, 30 Nov 2020 23:25:10 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BAA3A00C9 for ; Mon, 30 Nov 2020 23:25:09 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 9A79C600E3; Tue, 1 Dec 2020 07:25:07 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1606807507; bh=gFBgLidGPgDysQiS7l4Q9eHK/2wFfDODy56KWPMCH5Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Mnw9s/H6pJvNZS3rwAx9dxReLNl6TX3+RV9oAZsGOyNKfZ+qNJ1L1ftBnV47kgmSN n8PAQcgNiiqCwh9QbJeipl6K2nYuiZwrbjv0+92+s8YTm0ON3vQR1JfM41x09imCIL DWhEtfI+Ntw3ZxH+tgadyfOXdFEYYyuoEeNjvtfjbQbZyFBPZbbHQ4c+COr/1FFoO+ l5UmiwckJXBYGO4QmTt5w0mv2JIQfic52wJUCUyoE5gOpkDbZML3yAxk1KybvFnnmZ m74P0YLl0SaSbo2wkeEx9embHn2lZlFM3QneX7C2JCnO3Sav/pleIcbtFC+tSxRKCE JX/RYPZOXc2Ig== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 1 Dec 2020 08:25:04 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C6FEDBA-C3C1-48AF-B4A6-9C5C69244D15@nlnetlabs.nl> References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] Manifest entry filename validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 07:25:13 -0000 Hi Steve, > On 30 Nov 2020, at 21:21, Stephen Kent = wrote: >=20 > I've seen no responses to Tim's suggestion to create alternate = extension types for certs used to other purposes, e.g., router certs, so = I will ask my buddies to issue another version of the ID with the text = below. Thanks to everyone for their contributions to this additional, = clarifying text. Works for me. If we should ever think about updating the manifest = structure (out of scope for now clearly), then we could consider to = include specific type information fields rather than depending on = filename extensions. Tim >=20 > Steve >> Section 4.2.2 "Names in FileAndHash objects" >>=20 >> Names that appear in the fileList MUST consist of one or more = characters chosen >> from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed = by a single . >> (DOT), followed by a three-letter extension. The extension MUST be = one of those >> enumerated in the "RPKI Repository Naming Scheme" registry maintained = by IANA [IANA] >>=20 >> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. >>=20 >>=20 >> add the following Normative Reference entry: >>=20 >> [IANA] https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes=20= >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops