From nobody Fri Sep 2 13:56:14 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93212B04E; Fri, 2 Sep 2016 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 uDOE3PI5vf4p; Fri, 2 Sep 2016 13:56:12 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451EA12B010; Fri, 2 Sep 2016 13:56:12 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 44298405DF; Fri, 2 Sep 2016 20:56:11 +0000 (UTC) Received: from donkey.her.corp.google.com.ops-netman.net (unknown [104.132.12.87]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 0E7013A016DE; Fri, 2 Sep 2016 20:56:11 +0000 (UTC) Date: Fri, 02 Sep 2016 16:56:10 -0400 Message-ID: From: Chris Morrow To: sidr@ietf.org,sidr-chairs@ietf.org,sidr-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 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=US-ASCII Archived-At: Subject: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 20:56:13 -0000 Howdy SIDR peeps, (+bonus ops ad) Following on the Berlin meeting we were trying to accomplish two things: 1) get all documents related to sidr protocols into wglc and then publication 2) get all documents which are more operationally focused moved along to an ops group (sidr-ops or something akin to that) With that in mind there are 8 documents in the publication queue: draft-ietf-sidr-as-migration draft-ietf-sidr-bgpsec-algs draft-ietf-sidr-bgpsec-ops draft-ietf-sidr-bgpsec-overview draft-ietf-sidr-bgpsec-pki-profiles draft-ietf-sidr-bgpsec-protocol draft-ietf-sidr-origin-validation-signaling draft-ietf-sidr-rpki-rtr-rfc6810-bis and 11 still in progress. Of the 11 left Sandy and I think they roughly break down like: Documents which should move to the ops group: draft-ietf-sidr-bgpsec-rollover draft-ietf-sidr-lta-use-cases draft-ietf-sidr-route-server-rpki-light - authors notified/queried about this draft-ietf-sidr-rtr-keying documents which should finish out in sidr: draft-ietf-sidr-delta-protocol draft-ietf-sidr-publication draft-ietf-sidr-rpki-oob-setup - pub request in flight draft-ietf-sidr-rpki-tree-validation draft-ietf-sidr-rpki-validation-reconsidered draft-ietf-sidr-slurm - authors recently updated draft-ietf-sidr-adverse-actions - wglc imminent I think if there's no meaningful discussion on change for these between now and 9/16/2016 (Sept 16th) we will assume this list is correct. For documents in the 'move' list, if progress to publication happens 'good!'. For all documents in the 'stays' list: 1) we aim to have wglc by Seoul 2) publication requests started on as many as possible We plan to meet in Seoul, but not in Chicago (Mar 2017) where we expect the ops group to exist and meet. We can progress documents in SIDR after Seoul, but the WG should close out shortly after the new year. (or that's the goal). Thoughts? -chris From nobody Fri Sep 2 14:24:55 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222B12D559 for ; Fri, 2 Sep 2016 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W61hmzKG5wui for ; Fri, 2 Sep 2016 14:24:52 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 E6D4812D54F for ; Fri, 2 Sep 2016 14:24:51 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id l2so133911801qkf.3 for ; Fri, 02 Sep 2016 14:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AS/E8JBVKKItGTku/ImAGDmjdQcyBp6OLd5f6wfCY2Q=; b=rieyI0j6dLzYo5d0DMQTFrwuOm7zkyEJdwzp411OWxrdkRKS6l7I2X2OYHpTpbaclr N3AbCxVTqCLTj2Q0bsMtA42yjMf658UG9JXISj9WTv0sqLSxO4gAqTBI/NfPLQeZ3LeH vc1GYu926ni7HF599ptUJnZmyc+7USnnRgoRKbiwS0OeEXY24PAQFvlfb+Hwmh9sZGmm h/sBHuGHrlURs3OQjVn7Am9kYgxYWtmSeba0GOx89vYo9O2Cy9cLsVVEhazTnKfTPCHi Yh/fl5X5xFVhwlmg7FvgT7LsnRWWNTc7S2yiBaJYL+iMN23mHjrnOcSMewjfEZ9QsdWE Bpzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AS/E8JBVKKItGTku/ImAGDmjdQcyBp6OLd5f6wfCY2Q=; b=PJFo5r6g7e3IpgsMxTA528oywsZIUJLxbrnU7VAcvFiHgLvNOVD2pX20C7EaNiR+ni 8DnGijNtURr0J1EBKJsow0G3WbOKNE5AsZvfpAoAvTu3RIMwQ47ZnIT6QOlLniPhXjA8 /9PCDisk1cUi1uZlWjkmKLDObwM68rrHhT5PXO9EZTbivO6g7hOblk5oQHBB+jbTZhIL Eb2nhbuxIEWn16pt03UYKag55yNGSZ4kSpH2nBhJhC91tnt+YNrGXBiX+nG1+c5iC2o5 1dBYIQE+X4GIHhUHfle6hHP7njjGIyyGfhpV5wsGPDhYkOtNF354T6pAX9PcsTIFBUG3 0D0g== X-Gm-Message-State: AE9vXwNqG8aKmBHRoFWxUi31h7geeINzCqGGAh/sPahUQdGmw8d9btBOlI+bvFlr9gzix0Aw5cxqqiuPaD33hg== X-Received: by 10.55.120.2 with SMTP id t2mr25218807qkc.62.1472851491046; Fri, 02 Sep 2016 14:24:51 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Fri, 2 Sep 2016 14:24:50 -0700 (PDT) In-Reply-To: References: <76dad5c8-114a-19fe-6fc2-cf3c45e0f666@bbn.com> <227BF007-90BD-4301-A349-FC01A1A5969A@ripe.net> <9b33dd4f-6361-626d-5e0b-fa6d4ba3b260@bbn.com> From: Christopher Morrow Date: Fri, 2 Sep 2016 17:24:50 -0400 X-Google-Sender-Auth: yvQXyRz3F-oNE293t8ceaky3fmo Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=94eb2c05dd8cee4e8e053b8cf55a Archived-At: Cc: sidr Subject: Re: [sidr] adverse actions -01 posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:24:54 -0000 --94eb2c05dd8cee4e8e053b8cf55a Content-Type: text/plain; charset=UTF-8 On Tue, Aug 2, 2016 at 3:54 PM, Stephen Kent wrote: > Randy > >> Tim offered no suggestion for a different term, which is not helpful. >>>>> >>>> the suggestion was "unwanted". >>>> >>> I reread Tim's message; I don't interpret it as having suggested >>> "unwanted" as an alternative. >>> >> that is clear. others, such as matthias and i, did. but this is not >> productive. >> >> to be clear, i hereby suggest s/adverse/unwanted/ >> > I will process your suggestion in the same spirit that you continue to > ignore my comments about revising the folksy language in the LTA use cases > document. > > The term "adverse" is appropriate here. > > The discussion here seems to be about (though I haven't seen this word used) connotations attached to 'adverse'. 'by the english definition' adverse may be correct. It may be worth using 'unwanted' though to avoid the connotations associated with 'adverse' ? Is the point here that occasionally a parent my ask you to eat your peas, while you don't enjoy that thought? > Contrary to Tim's assertion, it does not imply, ".. that for conscious > actions by a parent CA against the will by a child CA, the parent is > "wrong" and the child is "right." > > "unwanted" is a wimpy term that fails to convey the fact that the actions > have a negative impact on the INR holder. > > Steve > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --94eb2c05dd8cee4e8e053b8cf55a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 2, 2016 at 3:54 PM, Stephen Kent <kent@bbn.com> w= rote:
Randy
Tim offered no suggestion for a different term, which is not helpful.
the suggestion was "unwanted".
I reread Tim's message; I don't interpret it as having suggested "unwanted" as an alternative.
that is clear.=C2=A0 others, such as matthias and i, did.=C2=A0 but this is= not
productive.

to be clear, i hereby suggest s/adverse/unwanted/
 I will process your suggestion in the same spirit that you continue to igno= re my comments about revising the folksy language in the LTA use cases docu= ment.

The term "adverse" is appropriate here.


The discussion here seems to be about = (though I haven't seen this word used) connotations attached to 'ad= verse'. =C2=A0'by the english definition' =C2=A0adverse may be = correct. It may be worth using 'unwanted' though to avoid the conno= tations associated with 'adverse' ?

Is the= point here that occasionally a parent my ask you to eat your peas, while y= ou don't enjoy that thought?
=C2=A0
Contrary to Tim's assertion, it does not imply, ".. that for consc= ious actions by a parent CA against the will by a child CA, the parent is &= quot;wrong" and the child is "right."

"unwanted" is a wimpy term that fails to convey the fact that the= actions have a negative impact on the INR holder.

Steve


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

--94eb2c05dd8cee4e8e053b8cf55a-- From nobody Fri Sep 2 15:02:20 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1984E12D0F8; Fri, 2 Sep 2016 15:02:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147285373906.24841.16441842136887667182.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 15:02:19 -0700 Archived-At: Cc: sidr@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com Subject: [sidr] sidr - New Meeting Session Request for IETF 97 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 22:02:19 -0000 A new meeting session request has just been submitted by Sandra L. Murphy, a Chair of the sidr working group. --------------------------------------------------------- Working Group Name: Secure Inter-Domain Routing Area Name: Routing Area Session Requester: Sandra Murphy Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: opsec idr grow saag rtgwg rtgarea Second Priority: dane i2rs isis trill lamps Special Requests: --------------------------------------------------------- From nobody Sat Sep 3 07:56:39 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F2A12D1CA for ; Sat, 3 Sep 2016 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je4AXBDUONqv for ; Sat, 3 Sep 2016 07:56:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0122.outbound.protection.outlook.com [23.103.201.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B981212D16B for ; Sat, 3 Sep 2016 07:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9AlXnR9iDsXnBMSiGIIV7PC0y6HahtOJHfBd69Fh2QY=; b=WSd/5+0DFSEcfCrOhKXXlBW59otCGbEkpRF5anCxqNkgO5IyeO11Zvil+EBfuVNJK28WbB2VOpJ6bxlA4Z5xtBn6/+opA5e0BFowTtW3Uof/+bwXhxF7O/e97Ei3CM8Ow2lUioI+BP6PgDlXP+knFzGtMSLmsTnbVloYB+YUO2A= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Sat, 3 Sep 2016 14:56:33 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0587.019; Sat, 3 Sep 2016 14:56:33 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Christopher Morrow , Stephen Kent Thread-Topic: [sidr] adverse actions -01 posted Thread-Index: AQHR5ojnah7wnR/LRkeP7IrTmJin9aAqvkYAgABPMoCAAE4+gIABMrUAgAAXfICAABOvAIAAQlqAgAkmOICAMNGmAIABIY58 Date: Sat, 3 Sep 2016 14:56:33 +0000 Message-ID: References: <76dad5c8-114a-19fe-6fc2-cf3c45e0f666@bbn.com> <227BF007-90BD-4301-A349-FC01A1A5969A@ripe.net> <9b33dd4f-6361-626d-5e0b-fa6d4ba3b260@bbn.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [132.163.219.49] x-ms-office365-filtering-correlation-id: 23fab34c-9e7c-4f02-3b0d-08d3d40a7f3b x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 6:wqqp88Tz1unMH7OsLOLxf0x0cR2VfFXnNqS1eDXdEPAimShN51UHJejiI/sIboH41ttP1r9W7EEaYjFq5j5lCYw9EcEOvIS8p7EWOulvY3NKHjUlWEWOe9QmxMnB7EoQky5R9I6i9gQwF6ENfZwZhMVWrzujpOTxQ8CnsC9RPw/9aS3zta/Ca+5h4WWZEKkJnRudI9qQyxFCcbjBd8BLtC51KFwWBtn7BCR5NgmTujXkUT/FxNMjKg5YQeAo1+pG6wjCuoUoZakpr2pnMSa/jIUzPjivjx9qQ/apI0nS/aeVW5GiRF6gliwBDjtoF7fGRJVCR7B1h+6h7KzB51+OOw==; 5:T8TFBYqCtIUkgktBtbEzOiZjoZq1ieaYEQe/NBnAzKJgXhpKJCXMtYAFJ/1E4I4ZwBlkYGBv82nx2UrU9fyPCqlba8lzMsLSDkPXoZLoQ+m+DmOdLPxnwdSh9Tnya52IKhX7YeK+/0AHVkXP+pU25g==; 24:jSFQ75jmp8VyPS4KjOWOqPKpif+mhz6hu0JaTEQ2UpJGy+iDfStv0qhr8QuRhseHJeumTWIMvMr5HaIX6RarfE7ur6oqF01R6Jpks3IvUxc=; 7:sRWTKfv1U9q8UCrRPnNdRdelo5ip100Serpgzd9Mfkhs9M6RkXYfehARa4s9NrHEK00xY/MM++VLUMm2AEq2RautnFfRm+I5meF8+IP14jpFF7oGKqkJKe7DdLzG2OOVdBeOSH9U6hC3TXrUehV9HLN1UuLhF7feu2ZNrLVPWIPlWfmJ1HKe5Wn6EG8qHKiHmoEL6x8gXk5/7kADGS0v5R+CN/JZHamgF1Fms4gRgW5GPFb5Q0Kcs8tfVfjGuteW x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 00540983E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(199003)(377454003)(189002)(87936001)(93886004)(5660300001)(305945005)(92566002)(74316002)(11100500001)(3900700001)(4326007)(76576001)(19580395003)(586003)(8936002)(2900100001)(9686002)(54356999)(2950100001)(50986999)(76176999)(33656002)(3660700001)(66066001)(3846002)(2906002)(6116002)(3280700002)(5001770100001)(7846002)(97736004)(7736002)(68736007)(5002640100001)(102836003)(189998001)(101416001)(19580405001)(81156014)(81166006)(15975445007)(77096005)(7696003)(106356001)(122556002)(10400500002)(5890100001)(106116001)(99286002)(105586002)(8676002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2016 14:56:33.2315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Cc: sidr Subject: Re: [sidr] adverse actions -01 posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 14:56:38 -0000 I think using the term "RPKI anomalies" is another choice here. It's kind o= f neutral about cause/intention. Advising/alerting the user community about - RPKI anomalies may arise due to various reasons. It could be due to fat fingers, negligence, or actions by your service prov= ider or law enforcement, etc. They have potential impacts on your routing, so you should be watchful, etc= .. Sriram ________________________________________ From: sidr on behalf of Christopher Morrow Sent: Friday, September 2, 2016 5:24 PM To: Stephen Kent Cc: sidr Subject: Re: [sidr] adverse actions -01 posted On Tue, Aug 2, 2016 at 3:54 PM, Stephen Kent > wrote: Randy Tim offered no suggestion for a different term, which is not helpful. the suggestion was "unwanted". I reread Tim's message; I don't interpret it as having suggested "unwanted" as an alternative. that is clear. others, such as matthias and i, did. but this is not productive. to be clear, i hereby suggest s/adverse/unwanted/ I will process your suggestion in the same spirit that you continue to igno= re my comments about revising the folksy language in the LTA use cases docu= ment. The term "adverse" is appropriate here. The discussion here seems to be about (though I haven't seen this word used= ) connotations attached to 'adverse'. 'by the english definition' adverse= may be correct. It may be worth using 'unwanted' though to avoid the conno= tations associated with 'adverse' ? Is the point here that occasionally a parent my ask you to eat your peas, w= hile you don't enjoy that thought? Contrary to Tim's assertion, it does not imply, ".. that for conscious acti= ons by a parent CA against the will by a child CA, the parent is "wrong" an= d the child is "right." "unwanted" is a wimpy term that fails to convey the fact that the actions h= ave a negative impact on the INR holder. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From nobody Sat Sep 3 14:06:30 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8913012B0EC; Sat, 3 Sep 2016 14:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508] 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 gOEQimwiSvQb; Sat, 3 Sep 2016 14:06:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 6121812B0AD; Sat, 3 Sep 2016 14:06:28 -0700 (PDT) Received: from mb-2.local ([IPv6:2601:1c0:cb00:5d1a:5996:34aa:2529:58c3]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u83L6Qx1094948 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 3 Sep 2016 21:06:27 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:1c0:cb00:5d1a:5996:34aa:2529:58c3] claimed to be mb-2.local To: Chris Morrow , sidr@ietf.org, sidr-chairs@ietf.org, sidr-ads@ietf.org References: From: joel jaeggli Message-ID: <453bf466-2b47-966f-4378-19a161d0c6a1@bogus.com> Date: Sat, 3 Sep 2016 14:06:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u7WoRkMrMXlHps8N59g1F6O7IcK9pDVXK" Archived-At: Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 21:06:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u7WoRkMrMXlHps8N59g1F6O7IcK9pDVXK Content-Type: multipart/mixed; boundary="6kehJiNlOi5aVhEWTBvMwG87KR9kDLxdg"; protected-headers="v1" From: joel jaeggli To: Chris Morrow , sidr@ietf.org, sidr-chairs@ietf.org, sidr-ads@ietf.org Message-ID: <453bf466-2b47-966f-4378-19a161d0c6a1@bogus.com> Subject: Re: Current document status && directionz References: In-Reply-To: --6kehJiNlOi5aVhEWTBvMwG87KR9kDLxdg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/2/16 1:56 PM, Chris Morrow wrote: >=20 > Howdy SIDR peeps, > (+bonus ops ad) >=20 > Following on the Berlin meeting we were trying to accomplish two > things: >=20 > 1) get all documents related to sidr protocols into wglc and then > publication >=20 > 2) get all documents which are more operationally focused moved > along to an ops group (sidr-ops or something akin to that) >=20 > With that in mind there are 8 documents in the publication queue: > draft-ietf-sidr-as-migration > draft-ietf-sidr-bgpsec-algs > draft-ietf-sidr-bgpsec-ops > draft-ietf-sidr-bgpsec-overview > draft-ietf-sidr-bgpsec-pki-profiles > draft-ietf-sidr-bgpsec-protocol > draft-ietf-sidr-origin-validation-signaling > draft-ietf-sidr-rpki-rtr-rfc6810-bis >=20 > and 11 still in progress. Of the 11 left Sandy and I think they > roughly break down like: >=20 > Documents which should move to the ops group: > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light - authors notified/queried ab= out this > draft-ietf-sidr-rtr-keying I think we good good feeback on the draft of a charter, I will start work on taking this to the IESG, but as some point soon the time will come to ask for community review of that proposal. regards joel > documents which should finish out in sidr: > draft-ietf-sidr-delta-protocol > draft-ietf-sidr-publication > draft-ietf-sidr-rpki-oob-setup - pub request in flight > draft-ietf-sidr-rpki-tree-validation > draft-ietf-sidr-rpki-validation-reconsidered > draft-ietf-sidr-slurm - authors recently updated > draft-ietf-sidr-adverse-actions - wglc imminent >=20 > I think if there's no meaningful discussion on change for these > between now and 9/16/2016 (Sept 16th) we will assume this list is > correct. For documents in the 'move' list, if progress to publication > happens 'good!'. For all documents in the 'stays' list: > 1) we aim to have wglc by Seoul > 2) publication requests started on as many as possible >=20 > We plan to meet in Seoul, but not in Chicago (Mar 2017) where we > expect the ops group to exist and meet. We can progress documents in > SIDR after Seoul, but the WG should close out shortly after the new > year. (or that's the goal). >=20 > Thoughts? > -chris >=20 --6kehJiNlOi5aVhEWTBvMwG87KR9kDLxdg-- --u7WoRkMrMXlHps8N59g1F6O7IcK9pDVXK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlfLO1IACgkQ8AA1q7Z/VrLBVgCfTS4+jQ77S3M1Hnv1NUVwXuYb Q9UAn39OfmSL++7gpmigK9tvQXp+IDuV =6rPA -----END PGP SIGNATURE----- --u7WoRkMrMXlHps8N59g1F6O7IcK9pDVXK-- From nobody Mon Sep 5 11:33:06 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93012B451; Mon, 5 Sep 2016 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 EUue8dMdrxYg; Mon, 5 Sep 2016 11:33:02 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 2A9DB12B0B3; Mon, 5 Sep 2016 11:33:02 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id u68so12493165uau.1; Mon, 05 Sep 2016 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jB8hJrUaagYTkjNsm81pT3/nnPXf3On+iIppb/D3yBI=; b=0VQROg3xTmMGh+Gj3SxY+o+sXF5/oZLxjW3+vDEuvcfVovk+ga5Ilb1an+hgREO+EX VtMTYqSEOH+2oIjxH6OgEFSuUQxnjZCeXNEHf0hqG6aDVd5JygoXnvi4LeRImArZPbFk jOR2d4AflFc8q6Q7Ex2dH2MiGgvYo47ov/WFARCjhUXuGY3GR0eI/JM1YviynBkxQtXF X+9olkLs/JKpnYMrdjqwW63/U/UlxW9jqWVBNTlia7Q+uuDWay/I5lRYJwaGWunl7t0L 8wp2ZqDHkwZdGePX8DjE/AsOLHwU2hsK+lISN3h0bac6U2FZzd8MVJCHvIIQEiTAz63C rCpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jB8hJrUaagYTkjNsm81pT3/nnPXf3On+iIppb/D3yBI=; b=fGA2lTewSotHdn/q83DYNuSGcLmS0XRiJXSD4h+gVvLn+RGoz3d+NGusA9EykdrsZT AKzJl5NUX4PBV7ZwJSehkNe9bCVcT1XCODqnY0u4QHGo+sLkUcWQIduqmz5ifUpbuWzG SGdkpK1rSc3zCFo99SVYHofuRgevGVa93oZXe5ThS/U/bK+/f5Yh5krjrRImNmn/STKc Jo6AQhlechDtaZYRVVi0vPZ0FQOB0UteQ2iPUkU1ZcOR/QyUJexHhbFyTTlIbm1iqIEd LmffG/HlFaCmh1ERwi4WmtejnFmJ+GU5NtanZhnpijfFtk+VvV3UV82bv3PjaGSO5En9 NThA== X-Gm-Message-State: AE9vXwPL16OB9OIiNDKmmU0Hv6D1qM8H1UVMm5uHZy7C8GYPblydMp4cpf8lJOC7VMTrhQ== X-Received: by 10.159.33.6 with SMTP id 6mr15534986uab.27.1473100381061; Mon, 05 Sep 2016 11:33:01 -0700 (PDT) Received: from [200.7.87.24] ([2001:13c7:7001:7000:4d2c:b463:1c3:50df]) by smtp.gmail.com with ESMTPSA id 61sm4454202uai.24.2016.09.05.11.32.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Sep 2016 11:33:00 -0700 (PDT) From: "Carlos M. Martinez" To: "Chris Morrow" Date: Mon, 05 Sep 2016 15:32:56 -0300 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5260) Archived-At: Cc: sidr-ads@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 18:33:04 -0000 Hi Chris, I know we already discussed this over private email, but perhaps you can comment on the list on the future of the requested WG adoption call for the ‘all resources’ applicability statement draft. thanks! -Carlos On 2 Sep 2016, at 17:56, Chris Morrow wrote: > > Howdy SIDR peeps, > (+bonus ops ad) > > Following on the Berlin meeting we were trying to accomplish two > things: > > 1) get all documents related to sidr protocols into wglc and then > publication > > 2) get all documents which are more operationally focused moved > along to an ops group (sidr-ops or something akin to that) > > With that in mind there are 8 documents in the publication queue: > draft-ietf-sidr-as-migration > draft-ietf-sidr-bgpsec-algs > draft-ietf-sidr-bgpsec-ops > draft-ietf-sidr-bgpsec-overview > draft-ietf-sidr-bgpsec-pki-profiles > draft-ietf-sidr-bgpsec-protocol > draft-ietf-sidr-origin-validation-signaling > draft-ietf-sidr-rpki-rtr-rfc6810-bis > > and 11 still in progress. Of the 11 left Sandy and I think they > roughly break down like: > > Documents which should move to the ops group: > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light - authors notified/queried > about this > draft-ietf-sidr-rtr-keying > > documents which should finish out in sidr: > draft-ietf-sidr-delta-protocol > draft-ietf-sidr-publication > draft-ietf-sidr-rpki-oob-setup - pub request in flight > draft-ietf-sidr-rpki-tree-validation > draft-ietf-sidr-rpki-validation-reconsidered > draft-ietf-sidr-slurm - authors recently updated > draft-ietf-sidr-adverse-actions - wglc imminent > > I think if there's no meaningful discussion on change for these > between now and 9/16/2016 (Sept 16th) we will assume this list is > correct. For documents in the 'move' list, if progress to publication > happens 'good!'. For all documents in the 'stays' list: > 1) we aim to have wglc by Seoul > 2) publication requests started on as many as possible > > We plan to meet in Seoul, but not in Chicago (Mar 2017) where we > expect the ops group to exist and meet. We can progress documents in > SIDR after Seoul, but the WG should close out shortly after the new > year. (or that's the goal). > > Thoughts? > -chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Sep 5 15:54:33 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B78412B464; Mon, 5 Sep 2016 15:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1JBz0o7A4Gp; Mon, 5 Sep 2016 15:54:29 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 3C5AC12B444; Mon, 5 Sep 2016 15:54:29 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id w124so86335852vkd.3; Mon, 05 Sep 2016 15:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PgvfelrdTVz8BcLcH+MDxzyVM1Cy4t/M6gb1fDdH31M=; b=ZRNnWzK6PJRwv3DDrZ5Qq17Tugr249s3n4sL0e93ax+wTfJgtZ7ZAfGeRGRRN6pUqm SABMBn5RSaxoCBTlui9obyXP/CWPYVqR9Xged5PR9bQPjgGK3CL+vnQALmqq9CUPI2dm wIFNZMlr1oSF6JMrfP9UOSgTZSg1HlYVq8UoLLGc/jC659b8fgJoHM9XVasJAcqoeJXB rSG0gvYX5VUU1xTxtoMrvLT4EmU20i0SSKNXMmZLJGr6snS97YT8ssW0/PP0YVo0Tga3 B3O8qxsyn4vMECa671YOcu3U8r0w/nGoMkclstjtto9xW2IF4ZQcARAY/tfEwVsNvOlt fecQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PgvfelrdTVz8BcLcH+MDxzyVM1Cy4t/M6gb1fDdH31M=; b=bCXyO829/nbBYf64wHcZ43FXOZka92HZz1Gp8BUQpUByQI8aIU55jamOSLYAKKs8Ua AkLTFLoHSMm4GQvhHyZSxRyI3T6dTQrI5TWyWGH98YK2CCPGxr40tM0/hNioMk4UuvsV FW4QgzDSs7D2x3QNJqMl/iEW35glSybyFple6cXKMzn3oNh2uZUvJiGo9EsZ9FyrGvHi ceYVY47zGwlVeSZOoLk0G5QbLpO9zIQ0bJlLiQn0qsL+kmm8++iSJM2wmQrSLCoLRQbq 8OB77Vt3MTSe6LFOPWVtEvjDT/iDFcKq3VzL1+yz6XCknP1Q7+sU2DHTp6xmzQk4soF3 T35g== X-Gm-Message-State: AE9vXwORx1e00k/tQyFRixfQ3B4XqSgPNNxHrx3iYKD+VpwREj41ZlQI/i0tzY3Lyshdsw== X-Received: by 10.31.210.66 with SMTP id j63mr10148882vkg.113.1473116068045; Mon, 05 Sep 2016 15:54:28 -0700 (PDT) Received: from ?IPv6:2800:af:a73a:1e4a:2da5:a8c4:25ca:9e7d? ([2800:af:a73a:1e4a:2da5:a8c4:25ca:9e7d]) by smtp.googlemail.com with ESMTPSA id 90sm4724192uam.22.2016.09.05.15.54.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Sep 2016 15:54:27 -0700 (PDT) To: Chris Morrow References: From: "Carlos M. Martinez" Message-ID: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> Date: Mon, 5 Sep 2016 19:54:53 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: sidr-ads@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 22:54:31 -0000 Here is the pointer to the document: https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 Apologies for my earlier laziness. On 9/5/2016 3:32 PM, Carlos M. Martinez wrote: > Hi Chris, > > I know we already discussed this over private email, but perhaps you can > comment on the list on the future of the requested WG adoption call for > the ‘all resources’ applicability statement draft. > > thanks! > > -Carlos > > On 2 Sep 2016, at 17:56, Chris Morrow wrote: > >> >> Howdy SIDR peeps, >> (+bonus ops ad) >> >> Following on the Berlin meeting we were trying to accomplish two >> things: >> >> 1) get all documents related to sidr protocols into wglc and then >> publication >> >> 2) get all documents which are more operationally focused moved >> along to an ops group (sidr-ops or something akin to that) >> >> With that in mind there are 8 documents in the publication queue: >> draft-ietf-sidr-as-migration >> draft-ietf-sidr-bgpsec-algs >> draft-ietf-sidr-bgpsec-ops >> draft-ietf-sidr-bgpsec-overview >> draft-ietf-sidr-bgpsec-pki-profiles >> draft-ietf-sidr-bgpsec-protocol >> draft-ietf-sidr-origin-validation-signaling >> draft-ietf-sidr-rpki-rtr-rfc6810-bis >> >> and 11 still in progress. Of the 11 left Sandy and I think they >> roughly break down like: >> >> Documents which should move to the ops group: >> draft-ietf-sidr-bgpsec-rollover >> draft-ietf-sidr-lta-use-cases >> draft-ietf-sidr-route-server-rpki-light - authors notified/queried >> about this >> draft-ietf-sidr-rtr-keying >> >> documents which should finish out in sidr: >> draft-ietf-sidr-delta-protocol >> draft-ietf-sidr-publication >> draft-ietf-sidr-rpki-oob-setup - pub request in flight >> draft-ietf-sidr-rpki-tree-validation >> draft-ietf-sidr-rpki-validation-reconsidered >> draft-ietf-sidr-slurm - authors recently updated >> draft-ietf-sidr-adverse-actions - wglc imminent >> >> I think if there's no meaningful discussion on change for these >> between now and 9/16/2016 (Sept 16th) we will assume this list is >> correct. For documents in the 'move' list, if progress to publication >> happens 'good!'. For all documents in the 'stays' list: >> 1) we aim to have wglc by Seoul >> 2) publication requests started on as many as possible >> >> We plan to meet in Seoul, but not in Chicago (Mar 2017) where we >> expect the ops group to exist and meet. We can progress documents in >> SIDR after Seoul, but the WG should close out shortly after the new >> year. (or that's the goal). >> >> Thoughts? >> -chris >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Sep 5 16:16:18 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B003212B417; Mon, 5 Sep 2016 16:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.409 X-Spam-Level: X-Spam-Status: No, score=-8.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, 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 XqGbh6Wwu4Ha; Mon, 5 Sep 2016 16:16:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7402712B012; Mon, 5 Sep 2016 16:16:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bh37c-0006jA-SM; Mon, 05 Sep 2016 23:16:13 +0000 Date: Tue, 06 Sep 2016 08:16:44 +0900 Message-ID: From: Randy Bush To: "Carlos M. Martinez" In-Reply-To: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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: Cc: sidr-ads@ietf.org, sidr@ietf.org Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 23:16:17 -0000 > https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 you gotta love it. the rirs do not have the social responsibility to root at the iana. and they do not have the guts to root at the nro. so we are supposed to weaken the reliability of the system and deploy a consistency checking hack as a patch? how does that work in the presence of make before break transfers etc? what's wrong with this picture? actually, what isn't wrong with it? randy From nobody Tue Sep 6 09:07:12 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBEF12B4C2; Tue, 6 Sep 2016 09:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 pRspGV0kq7f2; Tue, 6 Sep 2016 09:07:08 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD0112B56C; Tue, 6 Sep 2016 08:58:50 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 399F24089E; Tue, 6 Sep 2016 15:58:47 +0000 (UTC) Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (unknown [104.132.12.92]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 274EE4DE0D19; Tue, 6 Sep 2016 15:58:47 +0000 (UTC) Date: Tue, 06 Sep 2016 11:58:46 -0400 Message-ID: From: Chris Morrow To: "Carlos M. Martinez" In-Reply-To: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 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-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Chris Morrow , sidr-ads@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 16:07:10 -0000 At Mon, 5 Sep 2016 19:54:53 -0300, "Carlos M. Martinez" wrote: >=20 > Here is the pointer to the document: >=20 > https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 >=20 > Apologies for my earlier laziness. no worries, yes Sandy and I chatted about this... err, I think the end result was: "is this an ops thing? should this go to ops? or should we just adopt it in SIDR and jam it through?" I think sandy was due to send 'authors'(you/andy/etc) a mail about this... oh and we're waiting on Alvaro to reply to this as well. I'll mail an update to the list. >=20 > On 9/5/2016 3:32 PM, Carlos M. Martinez wrote: > > Hi Chris, > >=20 > > I know we already discussed this over private email, but perhaps you can > > comment on the list on the future of the requested WG adoption call for > > the =A1all resources=A2 applicability statement draft. > >=20 > > thanks! > >=20 > > -Carlos > >=20 > > On 2 Sep 2016, at 17:56, Chris Morrow wrote: > >=20 > >> > >> Howdy SIDR peeps, > >> (+bonus ops ad) > >> > >> Following on the Berlin meeting we were trying to accomplish two > >> things: > >> > >> 1) get all documents related to sidr protocols into wglc and then > >> publication > >> > >> 2) get all documents which are more operationally focused moved > >> along to an ops group (sidr-ops or something akin to that) > >> > >> With that in mind there are 8 documents in the publication queue: > >> draft-ietf-sidr-as-migration > >> draft-ietf-sidr-bgpsec-algs > >> draft-ietf-sidr-bgpsec-ops > >> draft-ietf-sidr-bgpsec-overview > >> draft-ietf-sidr-bgpsec-pki-profiles > >> draft-ietf-sidr-bgpsec-protocol > >> draft-ietf-sidr-origin-validation-signaling > >> draft-ietf-sidr-rpki-rtr-rfc6810-bis > >> > >> and 11 still in progress. Of the 11 left Sandy and I think they > >> roughly break down like: > >> > >> Documents which should move to the ops group: > >> draft-ietf-sidr-bgpsec-rollover > >> draft-ietf-sidr-lta-use-cases > >> draft-ietf-sidr-route-server-rpki-light - authors notified/queried > >> about this > >> draft-ietf-sidr-rtr-keying > >> > >> documents which should finish out in sidr: > >> draft-ietf-sidr-delta-protocol > >> draft-ietf-sidr-publication > >> draft-ietf-sidr-rpki-oob-setup - pub request in flight > >> draft-ietf-sidr-rpki-tree-validation > >> draft-ietf-sidr-rpki-validation-reconsidered > >> draft-ietf-sidr-slurm - authors recently updated > >> draft-ietf-sidr-adverse-actions - wglc imminent > >> > >> I think if there's no meaningful discussion on change for these > >> between now and 9/16/2016 (Sept 16th) we will assume this list is > >> correct. For documents in the 'move' list, if progress to publication > >> happens 'good!'. For all documents in the 'stays' list: > >> 1) we aim to have wglc by Seoul > >> 2) publication requests started on as many as possible > >> > >> We plan to meet in Seoul, but not in Chicago (Mar 2017) where we > >> expect the ops group to exist and meet. We can progress documents in > >> SIDR after Seoul, but the WG should close out shortly after the new > >> year. (or that's the goal). > >> > >> Thoughts? > >> -chris > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Sep 6 09:10:02 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B46212B20E; Tue, 6 Sep 2016 09:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 CaE8VtmI_9zQ; Tue, 6 Sep 2016 09:09:57 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D3D12B213; Tue, 6 Sep 2016 09:06:48 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 00DB94089E; Tue, 6 Sep 2016 16:06:47 +0000 (UTC) Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (unknown [104.132.12.92]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id E01C24DE452A; Tue, 6 Sep 2016 16:06:47 +0000 (UTC) Date: Tue, 06 Sep 2016 12:06:47 -0400 Message-ID: From: Chris Morrow To: joel jaeggli In-Reply-To: <453bf466-2b47-966f-4378-19a161d0c6a1@bogus.com> References: <453bf466-2b47-966f-4378-19a161d0c6a1@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 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=US-ASCII Archived-At: Cc: Chris Morrow , sidr-ads@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 16:10:00 -0000 At Sat, 3 Sep 2016 14:06:25 -0700, joel jaeggli wrote: > > [1 Re: Current document status && directionz ] > [1.1 ] > On 9/2/16 1:56 PM, Chris Morrow wrote: > > > > Howdy SIDR peeps, > > (+bonus ops ad) > > > > Following on the Berlin meeting we were trying to accomplish two > > things: > > > > 1) get all documents related to sidr protocols into wglc and then > > publication > > > > 2) get all documents which are more operationally focused moved > > along to an ops group (sidr-ops or something akin to that) > > > > With that in mind there are 8 documents in the publication queue: > > draft-ietf-sidr-as-migration > > draft-ietf-sidr-bgpsec-algs > > draft-ietf-sidr-bgpsec-ops > > draft-ietf-sidr-bgpsec-overview > > draft-ietf-sidr-bgpsec-pki-profiles > > draft-ietf-sidr-bgpsec-protocol > > draft-ietf-sidr-origin-validation-signaling > > draft-ietf-sidr-rpki-rtr-rfc6810-bis > > > > and 11 still in progress. Of the 11 left Sandy and I think they > > roughly break down like: > > > > Documents which should move to the ops group: > > draft-ietf-sidr-bgpsec-rollover > > draft-ietf-sidr-lta-use-cases > > draft-ietf-sidr-route-server-rpki-light - authors notified/queried about this > > draft-ietf-sidr-rtr-keying > > I think we good good feeback on the draft of a charter, I will start > work on taking this to the IESG, but as some point soon the time will > come to ask for community review of that proposal. > I also forgot to mention the all-res draft: draft-rir-rpki-allres-ta-app-statement is waiting for some AD comments to complete (with chairs I mean) to set location/direction. From nobody Tue Sep 6 12:45:36 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B35B12B416 for ; Tue, 6 Sep 2016 12:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, 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 7uZkDtyNtyAE for ; Tue, 6 Sep 2016 12:45:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9F512B287 for ; Tue, 6 Sep 2016 12:45:33 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:45818 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bhMJI-000DBK-FN for sidr@ietf.org; Tue, 06 Sep 2016 15:45:32 -0400 To: sidr@ietf.org References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> From: Stephen Kent Message-ID: <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> Date: Tue, 6 Sep 2016 15:45:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 19:45:35 -0000 +1 >> https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 > you gotta love it. the rirs do not have the social responsibility to > root at the iana. and they do not have the guts to root at the nro. > > so we are supposed to weaken the reliability of the system and deploy > a consistency checking hack as a patch? how does that work in the > presence of make before break transfers etc? > > what's wrong with this picture? actually, what isn't wrong with it? > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Sep 6 14:51:24 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CBF12B1A9; Tue, 6 Sep 2016 14:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 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 EcP0KthQ_PXX; Tue, 6 Sep 2016 14:51:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74EC12B0DA; Tue, 6 Sep 2016 14:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3719; q=dns/txt; s=iport; t=1473198681; x=1474408281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iL59kMwGQTx7F9yu1+mZnV64Q7mfJLw5DY6HRtcRWkI=; b=ac/e3u9H1TBtxiMGWne2EnDC9Mq92Gc6uxESfkALUNTMmFpAHDPAp7L5 lWXtN9xmse3jrDYOLgfQvTf/NGqveuZb1UY4EgqaDqIgNhOoLVvKzS+Gg H9IZPgWesNaJ/yNpnlH+ui01RghmBCu9zQgjnxQwv0FdBJ03Up9qyGgPi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQDsOM9X/4UNJK1dGgEBAQECAQEBA?= =?us-ascii?q?YMtAQEBAQEeV3wHjSeeU4w1ggIZC4V4AoFhOBQBAgEBAQEBAQFeJ4RiAQEEAQE?= =?us-ascii?q?BGlELEAIBCBguIQYLJQIEAQ0FG4gVAxcOuHwNgwwBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEXBYYvhE6CQ4FPEQEGFoU/HQWZHzQBhiCGPoJXj1mIQoQKg3kBHjaER3C?= =?us-ascii?q?EEQ0XB4ECfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,293,1470700800"; d="scan'208";a="148916048" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2016 21:51:20 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u86LpKrM002323 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Sep 2016 21:51:20 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Sep 2016 17:51:19 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Tue, 6 Sep 2016 17:51:19 -0400 From: "Roque Gagliano (rogaglia)" To: "Carlos M. Martinez" , Chris Morrow Thread-Topic: [sidr] Current document status && directionz Thread-Index: AQHSCIjNwDSafJV2ikaIhhAEiDU42Q== Date: Tue, 6 Sep 2016 21:51:19 +0000 Message-ID: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> In-Reply-To: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.172.245] Content-Type: text/plain; charset="Windows-1252" Content-ID: <01FF0070F19F8149B54E82182B0E2D64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sidr-ads@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 21:51:23 -0000 Carlos, I guess what the RIRs are going to do is to create a CA hierarchy: RIR_CA_0/0_(probably a hidden HSM) =8B> RIR_CA_RIR_RESOURCES (online HSM) = =8B> member_CA This means that not much changed from the current situation multiple self-signed certs, other than instead of getting the list of resources for each RIR from the first CA certificated, I need to fetch the second level CA cert. Is this how you plan to implement this change? Regards, Roque =8B=20 Roque Gagliano Tail-f Solutions Architect Southern Europe +41 76 449 8867 On 06/09/16 00:54, "sidr on behalf of Carlos M. Martinez" wrote: >Here is the pointer to the document: > >https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 > >Apologies for my earlier laziness. > >On 9/5/2016 3:32 PM, Carlos M. Martinez wrote: >> Hi Chris, >>=20 >> I know we already discussed this over private email, but perhaps you can >> comment on the list on the future of the requested WG adoption call for >> the =8Call resources=B9 applicability statement draft. >>=20 >> thanks! >>=20 >> -Carlos >>=20 >> On 2 Sep 2016, at 17:56, Chris Morrow wrote: >>=20 >>> >>> Howdy SIDR peeps, >>> (+bonus ops ad) >>> >>> Following on the Berlin meeting we were trying to accomplish two >>> things: >>> >>> 1) get all documents related to sidr protocols into wglc and then >>> publication >>> >>> 2) get all documents which are more operationally focused moved >>> along to an ops group (sidr-ops or something akin to that) >>> >>> With that in mind there are 8 documents in the publication queue: >>> draft-ietf-sidr-as-migration >>> draft-ietf-sidr-bgpsec-algs >>> draft-ietf-sidr-bgpsec-ops >>> draft-ietf-sidr-bgpsec-overview >>> draft-ietf-sidr-bgpsec-pki-profiles >>> draft-ietf-sidr-bgpsec-protocol >>> draft-ietf-sidr-origin-validation-signaling >>> draft-ietf-sidr-rpki-rtr-rfc6810-bis >>> >>> and 11 still in progress. Of the 11 left Sandy and I think they >>> roughly break down like: >>> >>> Documents which should move to the ops group: >>> draft-ietf-sidr-bgpsec-rollover >>> draft-ietf-sidr-lta-use-cases >>> draft-ietf-sidr-route-server-rpki-light - authors notified/queried >>> about this >>> draft-ietf-sidr-rtr-keying >>> >>> documents which should finish out in sidr: >>> draft-ietf-sidr-delta-protocol >>> draft-ietf-sidr-publication >>> draft-ietf-sidr-rpki-oob-setup - pub request in flight >>> draft-ietf-sidr-rpki-tree-validation >>> draft-ietf-sidr-rpki-validation-reconsidered >>> draft-ietf-sidr-slurm - authors recently updated >>> draft-ietf-sidr-adverse-actions - wglc imminent >>> >>> I think if there's no meaningful discussion on change for these >>> between now and 9/16/2016 (Sept 16th) we will assume this list is >>> correct. For documents in the 'move' list, if progress to publication >>> happens 'good!'. For all documents in the 'stays' list: >>> 1) we aim to have wglc by Seoul >>> 2) publication requests started on as many as possible >>> >>> We plan to meet in Seoul, but not in Chicago (Mar 2017) where we >>> expect the ops group to exist and meet. We can progress documents in >>> SIDR after Seoul, but the WG should close out shortly after the new >>> year. (or that's the goal). >>> >>> Thoughts? >>> -chris >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Sep 6 15:02:05 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF9012B18E for ; Tue, 6 Sep 2016 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 emzO59yKVsta for ; Tue, 6 Sep 2016 15:02:03 -0700 (PDT) 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 8AF3912B0D7 for ; Tue, 6 Sep 2016 15:02:03 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (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 A69C813994 for ; Tue, 6 Sep 2016 22:02:00 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id F1005420823A for ; Tue, 6 Sep 2016 18:00:00 -0400 (EDT) Date: Tue, 06 Sep 2016 18:00:00 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160906220000.F1005420823A@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 22:02:04 -0000 I guess one question here is the purpose of publishing this document: a) If the purpose of asking the WG to publish is a hope that the WG will agree that this is a good idea, then I'm with Randy and Steve in the "hell no" camp. b) If the purpose is to document something that the RIRs have unilaterally decided to do whether the IETF likes it or not, I guess we should thank them for documenting their intentions, and publish it with a big IETF / IESG disclaimer saying that it's a really bad idea but not something the IETF can prevent. I suppose we could refuse to publish entirely in this case, but suspect that just makes it harder for newcomers to understand what happened. My understanding was that we were already well into case (b) territory. Carlos et al, please correct me if I'm wrong and the RIRs are willing to back down on this. From nobody Tue Sep 6 19:48:12 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7981612B4FA for ; Tue, 6 Sep 2016 19:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji5T7lw4r448 for ; Tue, 6 Sep 2016 19:48:09 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 1AFED12B4C4 for ; Tue, 6 Sep 2016 19:48:09 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id v123so2524559qkh.2 for ; Tue, 06 Sep 2016 19:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=s+/F4eLrAtd97dgRcOHsC1pdZmK2QRKl3oOGs3FOc58=; b=UM7fRYnDaDdnvhdRtY/o3+EGhLr9aqS8ZvLWFBsYzEXPK0P5bO7nT0pvhSP5G9gPuT fZjbUUAlcJt8ZCrcSYREE+2p/g4eNSTlxozJoMVbPnEnjVHXtKdRUHlurDipjjNJZbQm WSxB9PJd4ZgxOLwhhSk2mDeAlftkev469ogHBoItC2i9uftp3b0bynn8KKTqKaw9MM7M IjDSco0Ua32sU5BqHR8n49pMsgE5rDd4twqTzbinl1y9WsunvHaQ52se9UTzWxQ5/FgG oteHuwXBE/wmAbxuGhWZtIMX8VI3skSj4Bdqrsl8pMfWrNfsqnS95FfEdm/rki/oLhI+ 0q/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=s+/F4eLrAtd97dgRcOHsC1pdZmK2QRKl3oOGs3FOc58=; b=HJ5fEOFpuh0eM/Bnlaw6j2lwuu15utodkqUO8fBAwOslekd60FdQhxXt5PS7FdD3cD LjxZm6jzasAsntRxYqMz1NVEkaKUF/DHfzPz5YlR0nfBKe37RGffus3+XMvcwJAsLvJU Mtt+qdWgcodb1yLvtGOd+0A0Ue7CRxxSIA+7binaUdOaDywiLj39ubWBSBt83yV9+A+w Zpv6vCv6m+Qn8P8vWGotDeOTlAbCvdYyxexO5TA667nlj4G3nt9KAoT53PNcsMhXnPjw Tq5h0OfXfGbJ3hzYl+r+HpTQtSLoWT2IJoACI+cD9MPlqxSV+lB+3cXfVgTGd6vhi7iu V4NQ== X-Gm-Message-State: AE9vXwNXWbzniNTddqHKyDy7cR/Ayd3ZnLnMqSYz4QcRa+8MAgqAGntOISfmfvOVGhEDTLRTEcHdBQB5tMG33w== X-Received: by 10.233.222.133 with SMTP id s127mr51880634qkf.166.1473216488272; Tue, 06 Sep 2016 19:48:08 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 6 Sep 2016 19:48:07 -0700 (PDT) In-Reply-To: <20160906220000.F1005420823A@minas-ithil.hactrn.net> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> From: Christopher Morrow Date: Tue, 6 Sep 2016 22:48:07 -0400 X-Google-Sender-Auth: EIIlNAVlI924QsiceZ23RvMqlN0 Message-ID: To: Rob Austein Content-Type: multipart/alternative; boundary=94eb2c0438f875f942053be1f142 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 02:48:10 -0000 --94eb2c0438f875f942053be1f142 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 6, 2016 at 6:00 PM, Rob Austein wrote: > I guess one question here is the purpose of publishing this document: > > a) If the purpose of asking the WG to publish is a hope that the WG > will agree that this is a good idea, then I'm with Randy and Steve > in the "hell no" camp. > > (note, I do not care for this message about politics) we're here because, I think, from the top down to the RIR there isn't a hierarchy being created, right? the RIR folk are saying: "Ok, you all want this thing, but upstairs hasn't created the root, so we're going to do the best we can with making a root each that allows us to xfer between RIRs. This is how it's being done, so you have some docs about the mechanics involved and can build/guide from there" is that not the case? (again, I don't care about the politics) > b) If the purpose is to document something that the RIRs have > unilaterally decided to do whether the IETF likes it or not, I > guess we should thank them for documenting their intentions, and > publish it with a big IETF / IESG disclaimer saying that it's a > really bad idea but not something the IETF can prevent. I suppose > we could refuse to publish entirely in this case, but suspect that > just makes it harder for newcomers to understand what happened. > > My understanding was that we were already well into case (b) territory. > --94eb2c0438f875f942053be1f142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 6, 2016 at 6:00 PM, Rob Austein <sra@hactrn.net> wrote:
I guess one question here is the= purpose of publishing this document:

a) If the purpose of asking the WG to publish is a hope that the WG
=C2=A0 =C2=A0will agree that this is a good idea, then I'm with Randy a= nd Steve
=C2=A0 =C2=A0in the "hell no" camp.


(note, I do not care for this message = about politics)

we're here because, I think, f= rom the top down to the RIR there isn't a hierarchy being created, righ= t? the RIR folk are saying: "Ok, you all want this thing, but upstairs= hasn't created the root, so we're going to do the best we can with= making a root each that allows us to xfer between RIRs. This is how it'= ;s being done, so you have some docs about the mechanics involved and can b= uild/guide from there"

is that not the case? = (again, I don't care about the politics)
=C2=A0
b) If the purpose is to document something that the RIRs have
=C2=A0 =C2=A0unilaterally decided to do whether the IETF likes it or not, I=
=C2=A0 =C2=A0guess we should thank them for documenting their intentions, a= nd
=C2=A0 =C2=A0publish it with a big IETF / IESG disclaimer saying that it= 9;s a
=C2=A0 =C2=A0really bad idea but not something the IETF can prevent.=C2=A0 = I suppose
=C2=A0 =C2=A0we could refuse to publish entirely in this case, but suspect = that
=C2=A0 =C2=A0just makes it harder for newcomers to understand what happened= .

My understanding was that we were already well into case (b) territory.
=
--94eb2c0438f875f942053be1f142-- From nobody Tue Sep 6 21:09:26 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D012B2ED for ; Tue, 6 Sep 2016 21:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 Edujr-oLaSXb for ; Tue, 6 Sep 2016 21:09:23 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F87D127078 for ; Tue, 6 Sep 2016 21:09:23 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 0ED4B39818 for ; Wed, 7 Sep 2016 04:09:23 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 769594208DBB for ; Wed, 7 Sep 2016 00:07:20 -0400 (EDT) Date: Wed, 07 Sep 2016 00:07:20 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160907040720.769594208DBB@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 04:09:25 -0000 At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote: > > (note, I do not care for this message about politics) Understood, with the caveat that since it's the politics which are pushing the wrong technical solution here, any technical discussion will loop back to politics as soon as one asks "why?" > we're here because, I think, from the top down to the RIR there isn't a > hierarchy being created, right? the RIR folk are saying: "Ok, you all want > this thing, but upstairs hasn't created the root, so we're going to do the > best we can with making a root each that allows us to xfer between RIRs. > This is how it's being done, so you have some docs about the mechanics > involved and can build/guide from there" > > is that not the case? (again, I don't care about the politics) I'm ignoring "upstairs", because that is also political. Stripped of the politics, we're having this conversation because the RIRs are proposing to operate five roots instead of one, with each root allowed to claim ownership over the known universe, because actually coordinating with each other is Too Hard. Or maybe it's more than five, some of the RIRs have extra roots just for fun, but let's take it as given for now that they'll collapse back down to five. The problem with multiple global RPKI roots, as KC Claffy put it rather neatly many years ago, is that it pushes responsibility for fixing RIR coordination mistakes (which the RIRs apparently believe are a serious issue, as evidenced by the draft under discussion) onto the relying parties rather than forcing the RIRs to fix those issues on the CA side. This is technically broken. Generating a single RPKI root is not hard. It can be done by a cron job. I ran one for years, for experimental purposes, entirely from data already available to the RIRs. The only real issue is which database to believe when they disagree -- which is exactly the problem the RIRs are trying to push onto the RPs with this document. Which brings us back to bad technical decisions and political reasons. Sorry. From nobody Tue Sep 6 21:10:29 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8D127078 for ; Tue, 6 Sep 2016 21:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.409 X-Spam-Level: X-Spam-Status: No, score=-8.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, 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 3z3MDOm2ncfq for ; Tue, 6 Sep 2016 21:10:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDAE12B111 for ; Tue, 6 Sep 2016 21:10:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bhUBs-0005oC-9t; Wed, 07 Sep 2016 04:10:24 +0000 Date: Wed, 07 Sep 2016 13:10:51 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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: Cc: sidr wg list Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 04:10:27 -0000 > (note, I do not care for this message about politics) > > we're here because, I think, from the top down to the RIR there isn't a > hierarchy being created, right? the RIR folk are saying: "Ok, you all want > this thing, but upstairs hasn't created the root, so we're going to do the > best we can with making a root each that allows us to xfer between RIRs. > This is how it's being done, so you have some docs about the mechanics > involved and can build/guide from there" > > is that not the case? (again, I don't care about the politics) dear ostrich, the problem is it is all about politics. and politics is what happens when two or more funny monkeys are involved. despite many years of promises promises of a single root o the rirs have been at war with the iana this whole time. i neither know nor care whose fault it is. but their egos and lawyers are preventing an iana root. o the rirs have the nro, which could be a single root. they seem to lack the fortitude and/or spirit of cooperation to root at the nro. this was not how it was being done a year ago. now the warring parties are each declaring themselves god. this is not an improvement, in fact the opposite. if we accept this draft, as rob says, it should be labeled as highly toxic. randy From nobody Wed Sep 7 07:42:19 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEAF12B032 for ; Wed, 7 Sep 2016 07:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6WMkjctqsoE for ; Wed, 7 Sep 2016 07:42:12 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739BB12B0D1 for ; Wed, 7 Sep 2016 07:42:12 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 11so8321155qtc.0 for ; Wed, 07 Sep 2016 07:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mBgBCtLx4g3l8sM2MvkBSiMDcqHjtUJLMAs37rgfnfc=; b=GXW0vgVLva38j0PtlV9VBMBC/BcYsDzAMQ8IymAz4jlOfhvhBPC9ALoOUkRHBaekWi tFNP1ROIqqpoWcpVo8LqzktauzDeAdGs3iD7s+VgEnClmI5hHmkXjP6VxrgXEG27H1FV V2OBx1UHyfjBk1nEup5CIk3cRBIPpRyGPYLGhcenN+VaHvjoMKiVSbCdw8EwBr0Tl2Ls C00GTGuUMaYwVG6Dun/YJ5UOHezE6ymj1ssIVBZZCuD8DhK/djKafteyuFO0RVr6aVMh J78RsyHSanJ3Ghak7lLGhFw4Zc2/RiXK/x5EVkXzhzQVOhza3mZsI/B2DBQjhCsH/5kp XkgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mBgBCtLx4g3l8sM2MvkBSiMDcqHjtUJLMAs37rgfnfc=; b=UbqKI2JeuWlLGzUfxCn9LBUExDMkeloPJh82v55p187PTfON4Q42bL1rNJTsz2VxOK JODWxuvA11+wEie/AC18Ow17Aph+rsQse6Lj08xHb8TCLtI+uDGP3TW0EA4hVZRQOpqm LpYQm0YyXz037rbyoSJtcZCKtBVk79mcrYSvpbeyKhkxh2+4/UqZZ2XbLLzgjPHAKmE3 IgO7CSNUA4M0gD5rQkiI4hFWkUq529O+LSFkPZKstUECTgNzo+BeIiFgbFwQGboR62nc xFRiCC8wxk88InvI7dFRVFors/iOmpeWMfzitPdN+vs0WkPnZyISS2XpETEm3rZQ8dru +2Fw== X-Gm-Message-State: AE9vXwPnLGgJVa6yFmY787e1P/6cnuYoA0sG7Qk0Cbia+/Hc2rU1MED4mZLc0SRIf0iivgWx1ZZLRW1cGyYwZg== X-Received: by 10.200.55.215 with SMTP id e23mr23795323qtc.23.1473259331533; Wed, 07 Sep 2016 07:42:11 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Wed, 7 Sep 2016 07:42:10 -0700 (PDT) In-Reply-To: <20160907040720.769594208DBB@minas-ithil.hactrn.net> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> From: Christopher Morrow Date: Wed, 7 Sep 2016 10:42:10 -0400 X-Google-Sender-Auth: 174W8Ec-drg2PPfTkxOwXOO4I1g Message-ID: To: Rob Austein Content-Type: multipart/alternative; boundary=001a11471b9c1e6577053bebeb93 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 14:42:18 -0000 --001a11471b9c1e6577053bebeb93 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein wrote: > At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote: > > > > (note, I do not care for this message about politics) > > Understood, with the caveat that since it's the politics which are > pushing the wrong technical solution here, any technical discussion > will loop back to politics as soon as one asks "why?" > > totally agree/understand. > > we're here because, I think, from the top down to the RIR there isn't a > > hierarchy being created, right? the RIR folk are saying: "Ok, you all > want > > this thing, but upstairs hasn't created the root, so we're going to do > the > > best we can with making a root each that allows us to xfer between RIRs. > > This is how it's being done, so you have some docs about the mechanics > > involved and can build/guide from there" > > > > is that not the case? (again, I don't care about the politics) > > I'm ignoring "upstairs", because that is also political. > > yes, sorry I was trying to not point fingers at particular people/things :( > Stripped of the politics, we're having this conversation because the > RIRs are proposing to operate five roots instead of one, with each > root allowed to claim ownership over the known universe, because > actually coordinating with each other is Too Hard. Or maybe it's more > than five, some of the RIRs have extra roots just for fun, but let's > take it as given for now that they'll collapse back down to five. > > ok > The problem with multiple global RPKI roots, as KC Claffy put it > rather neatly many years ago, is that it pushes responsibility for > fixing RIR coordination mistakes (which the RIRs apparently believe > are a serious issue, as evidenced by the draft under discussion) onto > the relying parties rather than forcing the RIRs to fix those issues > on the CA side. This is technically broken. > > I think it means that since there is no single root coming 'soon', the RIR's are taking a step to move forward with rpki despite the 'no single root' existing. Ideally they would have a method to keep from being out of sync in their processing of requests/changes. Ideally that process would be outlined in the document here so we'd be able to say: "Ok, as the rpki lives on, how does X and Y and Z get done? what happens at X step 3 when Carlos decides to take a very long lunch? how does the process move along? what checks/balances are there?" That's the part that you're referring to as KC's comment, I think? > Generating a single RPKI root is not hard. It can be done by a cron > job. I ran one for years, for experimental purposes, entirely from > data already available to the RIRs. The only real issue is which > database to believe when they disagree -- which is exactly the problem > the RIRs are trying to push onto the RPs with this document. > > I don't disagree that running a CA is 'simple'... I think though that if the RIRs are in a position where there won't be a single root above them 'for a while' (it's been ~10 yrs at this point) but they feel they need to move forward with something, is this direction acceptable? is it better to document that decision and it's gotchas than to not move forward at all? or to 'continue waiting for the single root' to arrive? > Which brings us back to bad technical decisions and political reasons. > Sorry. > yup. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a11471b9c1e6577053bebeb93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <sra@hactrn.net> wrote:
At Tue, 6 Sep = 2016 22:48:07 -0400, Christopher Morrow wrote:
>
> (note, I do not care for this message about politics)

Understood, with the caveat that since it's the politics which a= re
pushing the wrong technical solution here, any technical discussion
will loop back to politics as soon as one asks "why?"


totally agree/= understand.
=C2=A0
> we're here because, I think, from the top down to the RIR there is= n't a
> hierarchy being created, right? the RIR folk are saying: "Ok, you= all want
> this thing, but upstairs hasn't created the root, so we're goi= ng to do the
> best we can with making a root each that allows us to xfer between RIR= s.
> This is how it's being done, so you have some docs about the mecha= nics
> involved and can build/guide from there"
>
> is that not the case? (again, I don't care about the politics)

I'm ignoring "upstairs", because that is also politica= l.


yes, sorry I was trying to not point f= ingers at particular people/things :(
=C2=A0
Stripped of the politics, we're having this conversation because the RIRs are proposing to operate five roots instead of one, with each
root allowed to claim ownership over the known universe, because
actually coordinating with each other is Too Hard.=C2=A0 Or maybe it's = more
than five, some of the RIRs have extra roots just for fun, but let's take it as given for now that they'll collapse back down to five.


ok
=C2=A0
The problem with multiple global RPKI roots, as KC Claffy put it
rather neatly many years ago, is that it pushes responsibility for
fixing RIR coordination mistakes (which the RIRs apparently believe
are a serious issue, as evidenced by the draft under discussion) onto
the relying parties rather than forcing the RIRs to fix those issues
on the CA side.=C2=A0 This is technically broken.


I think it means that since there is n= o single root coming 'soon', the RIR's are taking a step to mov= e forward with rpki despite the 'no single root' existing. Ideally = they would have a method to keep from being out of sync in their processing= of requests/changes. Ideally that process would be outlined in the documen= t here so we'd be able to say: "Ok, as the rpki lives on, how does= X and Y and Z get done? what happens at X step 3 when Carlos decides to ta= ke a very long lunch? how does the process move along? what checks/balances= are there?"

That's the part that you'= ;re referring to as KC's comment, I think?
=C2=A0
Generating a single RPKI root is not hard.=C2=A0 It can be done by a cron job.=C2=A0 I ran one for years, for experimental purposes, entirely from data already available to the RIRs.=C2=A0 The only real issue is which
database to believe when they disagree -- which is exactly the problem
the RIRs are trying to push onto the RPs with this document.


I don't disagree that running a CA= is 'simple'... I think though that if the RIRs are in a position w= here there won't be a single root above them 'for a while' (it&= #39;s been ~10 yrs at this point) but they feel they need to move forward w= ith something, is this direction acceptable? is it better to document that = decision and it's gotchas than to not move forward at all? or to 'c= ontinue waiting for the single root' to arrive?
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Which brings us back to bad technical decisions and political reasons.
Sorry.

yup.
=C2=A0

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

--001a11471b9c1e6577053bebeb93-- From andrewh@ripe.net Wed Sep 7 07:55:44 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EF212B018 for ; Wed, 7 Sep 2016 07:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508] 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 9NZIO_-CS2oA for ; Wed, 7 Sep 2016 07:55:41 -0700 (PDT) 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 487CB12B01A for ; Wed, 7 Sep 2016 07:55:41 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bheGH-0005It-OC; Wed, 07 Sep 2016 16:55:39 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-254.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bheGH-0007Yp-Ik; Wed, 07 Sep 2016 16:55:37 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_A9B010DF-EA63-43F5-BA2B-71C9324EF1AC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Andrew de la Haye In-Reply-To: Date: Wed, 7 Sep 2016 16:55:37 +0200 Message-Id: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> To: Christopher Morrow X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.1 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0144] X-RIPE-Signature: e27d87b2fb08ebd3914ba33c5d0e271be24b13a2b165e8158867823db13fc5e1 Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 14:58:14 -0000 --Apple-Mail=_A9B010DF-EA63-43F5-BA2B-71C9324EF1AC Content-Type: multipart/alternative; boundary="Apple-Mail=_63BC576B-80E6-4D83-9298-78B16898F732" --Apple-Mail=_63BC576B-80E6-4D83-9298-78B16898F732 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 07 Sep 2016, at 16:42, Christopher Morrow = wrote: >=20 >=20 >=20 > On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein > wrote: > At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote: > > > > (note, I do not care for this message about politics) >=20 > Understood, with the caveat that since it's the politics which are > pushing the wrong technical solution here, any technical discussion > will loop back to politics as soon as one asks "why?" >=20 >=20 > totally agree/understand. > =20 > > we're here because, I think, from the top down to the RIR there = isn't a > > hierarchy being created, right? the RIR folk are saying: "Ok, you = all want > > this thing, but upstairs hasn't created the root, so we're going to = do the > > best we can with making a root each that allows us to xfer between = RIRs. > > This is how it's being done, so you have some docs about the = mechanics > > involved and can build/guide from there" > > > > is that not the case? (again, I don't care about the politics) >=20 > I'm ignoring "upstairs", because that is also political. >=20 >=20 > yes, sorry I was trying to not point fingers at particular = people/things :( > =20 > Stripped of the politics, we're having this conversation because the > RIRs are proposing to operate five roots instead of one, with each > root allowed to claim ownership over the known universe, because > actually coordinating with each other is Too Hard. Or maybe it's more > than five, some of the RIRs have extra roots just for fun, but let's > take it as given for now that they'll collapse back down to five. >=20 >=20 > ok > =20 > The problem with multiple global RPKI roots, as KC Claffy put it > rather neatly many years ago, is that it pushes responsibility for > fixing RIR coordination mistakes (which the RIRs apparently believe > are a serious issue, as evidenced by the draft under discussion) onto > the relying parties rather than forcing the RIRs to fix those issues > on the CA side. This is technically broken. >=20 >=20 > I think it means that since there is no single root coming 'soon', the = RIR's are taking a step to move forward with rpki despite the 'no single = root' existing. Ideally they would have a method to keep from being out = of sync in their processing of requests/changes. Ideally that process = would be outlined in the document here so we'd be able to say: "Ok, as = the rpki lives on, how does X and Y and Z get done? what happens at X = step 3 when Carlos decides to take a very long lunch? how does the = process move along? what checks/balances are there?" >=20 > That's the part that you're referring to as KC's comment, I think? > =20 > Generating a single RPKI root is not hard. It can be done by a cron > job. I ran one for years, for experimental purposes, entirely from > data already available to the RIRs. The only real issue is which > database to believe when they disagree -- which is exactly the problem > the RIRs are trying to push onto the RPs with this document. >=20 >=20 > I don't disagree that running a CA is 'simple'... I think though that = if the RIRs are in a position where there won't be a single root above = them 'for a while' (it's been ~10 yrs at this point) but they feel they = need to move forward with something, is this direction acceptable? is it = better to document that decision and it's gotchas than to not move = forward at all? or to 'continue waiting for the single root' to arrive? Chris, fully agree, the intent is to provide unity and transparency on how the = RIRs handle their respective trust anchors at this stage Andrew=20 > =20 > Which brings us back to bad technical decisions and political reasons. > Sorry. >=20 > yup. > =20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr = >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_63BC576B-80E6-4D83-9298-78B16898F732 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 07 Sep 2016, at 16:42, Christopher Morrow <morrowc.lists@gmail.com> wrote:



On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <sra@hactrn.net> wrote:
At = Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
>
> (note, I do not care for this message about politics)

Understood, with the caveat that since it's the politics which = are
pushing the wrong technical solution here, any technical discussion
will loop back to politics as soon as one asks "why?"


totally agree/understand.
 
> we're here because, I think, from the top down to the RIR there = isn't a
> hierarchy being created, right? the RIR folk are saying: "Ok, you = all want
> this thing, but upstairs hasn't created the root, so we're going to = do the
> best we can with making a root each that allows us to xfer between = RIRs.
> This is how it's being done, so you have some docs about the = mechanics
> involved and can build/guide from there"
>
> is that not the case? (again, I don't care about the politics)

I'm ignoring "upstairs", because that is also political.


yes, sorry I was trying to not point fingers at particular = people/things :(
 
Stripped of the politics, we're having this conversation because the
RIRs are proposing to operate five roots instead of one, with each
root allowed to claim ownership over the known universe, because
actually coordinating with each other is Too Hard.  Or maybe it's = more
than five, some of the RIRs have extra roots just for fun, but let's
take it as given for now that they'll collapse back down to five.


ok
 
The problem with multiple global RPKI roots, as KC Claffy put it
rather neatly many years ago, is that it pushes responsibility for
fixing RIR coordination mistakes (which the RIRs apparently believe
are a serious issue, as evidenced by the draft under discussion) onto
the relying parties rather than forcing the RIRs to fix those issues
on the CA side.  This is technically broken.


I think it means that since there is no single root coming = 'soon', the RIR's are taking a step to move forward with rpki despite = the 'no single root' existing. Ideally they would have a method to keep = from being out of sync in their processing of requests/changes. Ideally = that process would be outlined in the document here so we'd be able to = say: "Ok, as the rpki lives on, how does X and Y and Z get done? what = happens at X step 3 when Carlos decides to take a very long lunch? how = does the process move along? what checks/balances are there?"

That's the part that = you're referring to as KC's comment, I think?
 
Generating a single RPKI root is not hard.  It can be done by a = cron
job.  I ran one for years, for experimental purposes, entirely = from
data already available to the RIRs.  The only real issue is = which
database to believe when they disagree -- which is exactly the = problem
the RIRs are trying to push onto the RPs with this document.


I don't disagree that running a CA is 'simple'... I think = though that if the RIRs are in a position where there won't be a single = root above them 'for a while' (it's been ~10 yrs at this point) but they = feel they need to move forward with something, is this direction = acceptable? is it better to document that decision and it's gotchas than = to not move forward at all? or to 'continue waiting for the single root' = to arrive?

Chris,

fully = agree, the intent is to provide unity and transparency on how the RIRs = handle their respective trust anchors at this stage

Andrew 


 
Which brings us back to bad technical decisions and political = reasons.
Sorry.

yup.
 

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

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

= --Apple-Mail=_63BC576B-80E6-4D83-9298-78B16898F732-- --Apple-Mail=_A9B010DF-EA63-43F5-BA2B-71C9324EF1AC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHADCCBvww ggXkoAMCAQICCkctQbYAAgAABQYwDQYJKoZIhvcNAQEFBQAwYDETMBEGCgmSJomT8ixkARkWA25l dDEUMBIGCgmSJomT8ixkARkWBHJpcGUxFjAUBgoJkiaJk/IsZAEZFgZzaW5nZWwxGzAZBgNVBAMT EnNpbmdlbC1DSEFLT1RBWS1DQTAeFw0xNjA2MDcwNTA1MzFaFw0xNzA2MDcwNTA1MzFaMIGiMRMw EQYKCZImiZPyLGQBGRYDbmV0MRQwEgYKCZImiZPyLGQBGRYEcmlwZTEWMBQGCgmSJomT8ixkARkW BnNpbmdlbDERMA8GA1UECxMIYWNjb3VudHMxDTALBgNVBAsTBG1nbXQxGjAYBgNVBAMTEUFuZHJl dyBkZSBsYSBIYXllMR8wHQYJKoZIhvcNAQkBFhBhbmRyZXdoQHJpcGUubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4nXV/xt3HKRDs+vBFvwI2jm7I0uQ32PskLEXkBRnkGmg24FI Y/K81TXxGKOVV1RFmbibKiZNGK+4HnN+ki7J/QJ+EYQ3XnL4A2EEDy04jXPJr6nN19j2lr/PG72e iVDfwPoSaexoFnhBwFUAG8gbgop1HdADErKuWUcLqRA7y7U/YamZdSU+mbMhngu4y62GgR3I+v75 HDlgKhEP+KzFVesD/8c6D19YaMijcc0wFsaPGsuTKIjUo76UDZoYCFRHkSNyHAfhipnGRDoIr0un CHNp/qphLY3KQWDcLsTmZBoXLZJsC2V1nIRma6dx4xOm+QSVPe4UGSupg6zvYFNmjwIDAQABo4ID czCCA28wFwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsG AQUFBwMEBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG 9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTH CUGzXoD3idvJCfsV4Oq+6RW4oTAfBgNVHSMEGDAWgBRxQNmbxDyqFNIksgHFYHIn74DrgDCCARcG A1UdHwSCAQ4wggEKMIIBBqCCAQKggf+Ggb1sZGFwOi8vL0NOPXNpbmdlbC1DSEFLT1RBWS1DQSxD Tj1QSUtFLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPXNpbmdlbCxEQz1yaXBlLERDPW5ldD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGPWh0dHA6Ly9waWtl LnNpbmdlbC5yaXBlLm5ldC9DZXJ0RW5yb2xsL3NpbmdlbC1DSEFLT1RBWS1DQS5jcmwwggEwBggr BgEFBQcBAQSCASIwggEeMIG4BggrBgEFBQcwAoaBq2xkYXA6Ly8vQ049c2luZ2VsLUNIQUtPVEFZ LUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPXNpbmdlbCxEQz1yaXBlLERDPW5ldD9jQUNlcnRpZmljYXRlP2Jhc2U/b2Jq ZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBhBggrBgEFBQcwAoZVaHR0cDovL3Bpa2Uu c2luZ2VsLnJpcGUubmV0L0NlcnRFbnJvbGwvUElLRS5zaW5nZWwucmlwZS5uZXRfc2luZ2VsLUNI QUtPVEFZLUNBKDIpLmNydDBEBgNVHREEPTA7oCcGCisGAQQBgjcUAgOgGQwXYW5kcmV3aEBzaW5n ZWwucmlwZS5uZXSBEGFuZHJld2hAcmlwZS5uZXQwDQYJKoZIhvcNAQEFBQADggEBAGs5rvOXxkQ5 LYwDbIwzNUD3zCpbz+c5YU22f8tKDCRFPpTtGfUEspzvfSTcoJ81kZapSiKA3Q2cuGgpg87MN0B3 xm9gYCx/IzOIzXBCnL5HmC7fAFyeQT1f6A2y8ZX4WEwexCrdA+pZgvklDy2YBp6ZXUTsFeL7CipQ MW1hAfPGffU11iyyqpcRldtkC/bBp6VQKDx5tnWoR0+GxThA4jSDjUAj/Vej9BFxiaQwcNyK1pou Ukf3Ot5HT8hpksAfIKUR6BKlpcLA0E9KoZcJadewkxl/9CHp4ufj1VTN/w4tnUTyYb9UhLUgKHhi wEAQTEMUsoT/1Dl9UH440eCO3kExggL2MIIC8gIBATBuMGAxEzARBgoJkiaJk/IsZAEZFgNuZXQx FDASBgoJkiaJk/IsZAEZFgRyaXBlMRYwFAYKCZImiZPyLGQBGRYGc2luZ2VsMRswGQYDVQQDExJz aW5nZWwtQ0hBS09UQVktQ0ECCkctQbYAAgAABQYwCQYFKw4DAhoFAKCCAV0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTA3MTQ1NTM3WjAjBgkqhkiG9w0BCQQx FgQUpyE3gbfZ9EzRelZVxS6XoZtuKjowfQYJKwYBBAGCNxAEMXAwbjBgMRMwEQYKCZImiZPyLGQB GRYDbmV0MRQwEgYKCZImiZPyLGQBGRYEcmlwZTEWMBQGCgmSJomT8ixkARkWBnNpbmdlbDEbMBkG A1UEAxMSc2luZ2VsLUNIQUtPVEFZLUNBAgpHLUG2AAIAAAUGMH8GCyqGSIb3DQEJEAILMXCgbjBg MRMwEQYKCZImiZPyLGQBGRYDbmV0MRQwEgYKCZImiZPyLGQBGRYEcmlwZTEWMBQGCgmSJomT8ixk ARkWBnNpbmdlbDEbMBkGA1UEAxMSc2luZ2VsLUNIQUtPVEFZLUNBAgpHLUG2AAIAAAUGMA0GCSqG SIb3DQEBAQUABIIBANJzQv2iGP82SIBABlfjvi2rnCYeL1MHP8EKOpa9GYHMxhrJy8IUjFd0jYXN vSZ3E9Dbb2anpz5wWZWJoJaeXrMupBUX2BDBmBIeCF7W4qsckDzuWRw8qn9KJ43nijt+jegYC314 ZVCSEEtga6JGY+j0NwZGJtQ4kkK68A56RxBzbVQTmAc2i1jSlrLbfgxDbUEhGMvY0GODs+ry/tvl KHFFux1AtB7Zt7dn6fIhO33OlBZtCD+WpQSgSXQpU94uZqkhLTrubyAP2fCQj//jO/Fy7FNScHIE ZflsWp5HDPEUA6J6HU6y1KXzXVuEgG0ZVXB2OdHRX0AtjbeQcj/VcfAAAAAAAAA= --Apple-Mail=_A9B010DF-EA63-43F5-BA2B-71C9324EF1AC-- From nobody Wed Sep 7 09:04:26 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E733E12B397 for ; Wed, 7 Sep 2016 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XAQCUjJTbaU for ; Wed, 7 Sep 2016 09:04:23 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 B46B112B384 for ; Wed, 7 Sep 2016 09:04:22 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id 11so9659894qtc.0 for ; Wed, 07 Sep 2016 09:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZNj3QyIR0pfhYMU/WpGEJg4Ug71pqLuWR0+fdGoFDuM=; b=wLZS1y1sUjFiOcDsx6DtRs2YxZKla8c0hT5TH0rNG++rHiPpx/Ym8QkR7qZt0boXyc 53W2Oit8Dvn9isQAc8SDoxN6+SHqkQqSHPZHewmhu02GwzO8vC3oifNoLmcS7Ut3bJPB ZxJggznu7iLCWMdm5oWPM64z5a/78aVotJ1ZrNQjjsb+xQknHgpH/CNB/eknnICu6Wdz rq7thxBT01oPVtq9lZplpybNrFS1QPPHfLPyqdtwl3VCNSIlg5oDMTfMaEe7f6vyjImv eD9/3BYo/RLp+I1kgqfZCJzR71/5d0uGWfuaTStpPapkDfAGmf+DbgzEvHn/fMWvf/Ig AqYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZNj3QyIR0pfhYMU/WpGEJg4Ug71pqLuWR0+fdGoFDuM=; b=DO+yVwl1CeLHsiEC3JAfxRagST8K25ne/2iK65VYdXslVnFs3z08fzBRFPPVhZatvh w4f8WeIl4ZHMgPIVDs62wIATxaHKOP07H7dKdZvxYBAbYwGGKjgU45ci4cBKh8VPm3/n MkIDdwjU9ClHB7/aSm0fP0JvHlgHuBuYTm1nCEhtXk80Hfu6XTU+2GTOsrfU0GBH+hAK WkabTTTfWbMw0sf5wOiCtbWejocV8R6OENVAbvOK13wlOdpUjjSYNf858Np+jDAZBP/8 GGVDV3OSCJtUsLipV8gaxnRM8naCpl7mvsVHFUt9k1zqmWMGbYCJkb/Yf4plfTgP/Wiz r7UA== X-Gm-Message-State: AE9vXwPhliBgGORjPfz3Hl67U5OFkgbIBfGE1KhuHkTqZdTOteaDpqOkmKRCy1woYdckTpi02qVcp7tselhn4A== X-Received: by 10.200.38.241 with SMTP id 46mr19622208qtp.135.1473264261728; Wed, 07 Sep 2016 09:04:21 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Wed, 7 Sep 2016 09:04:21 -0700 (PDT) In-Reply-To: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> From: Christopher Morrow Date: Wed, 7 Sep 2016 12:04:21 -0400 X-Google-Sender-Auth: AN9k0tXIh74Q2lDcZ6kYUqRxDJ0 Message-ID: To: Andrew de la Haye Content-Type: multipart/alternative; boundary=001a113feba2fb540c053bed1040 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 16:04:26 -0000 --001a113feba2fb540c053bed1040 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 7, 2016 at 10:55 AM, Andrew de la Haye wrote: > > On 07 Sep 2016, at 16:42, Christopher Morrow > wrote: > > > > On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein wrote: > >> At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote: >> > >> > (note, I do not care for this message about politics) >> >> Understood, with the caveat that since it's the politics which are >> pushing the wrong technical solution here, any technical discussion >> will loop back to politics as soon as one asks "why?" >> >> > totally agree/understand. > > >> > we're here because, I think, from the top down to the RIR there isn't a >> > hierarchy being created, right? the RIR folk are saying: "Ok, you all >> want >> > this thing, but upstairs hasn't created the root, so we're going to do >> the >> > best we can with making a root each that allows us to xfer between RIRs. >> > This is how it's being done, so you have some docs about the mechanics >> > involved and can build/guide from there" >> > >> > is that not the case? (again, I don't care about the politics) >> >> I'm ignoring "upstairs", because that is also political. >> >> > yes, sorry I was trying to not point fingers at particular people/things :( > > >> Stripped of the politics, we're having this conversation because the >> RIRs are proposing to operate five roots instead of one, with each >> root allowed to claim ownership over the known universe, because >> actually coordinating with each other is Too Hard. Or maybe it's more >> than five, some of the RIRs have extra roots just for fun, but let's >> take it as given for now that they'll collapse back down to five. >> >> > ok > > >> The problem with multiple global RPKI roots, as KC Claffy put it >> rather neatly many years ago, is that it pushes responsibility for >> fixing RIR coordination mistakes (which the RIRs apparently believe >> are a serious issue, as evidenced by the draft under discussion) onto >> the relying parties rather than forcing the RIRs to fix those issues >> on the CA side. This is technically broken. >> >> > I think it means that since there is no single root coming 'soon', the > RIR's are taking a step to move forward with rpki despite the 'no single > root' existing. Ideally they would have a method to keep from being out of > sync in their processing of requests/changes. Ideally that process would be > outlined in the document here so we'd be able to say: "Ok, as the rpki > lives on, how does X and Y and Z get done? what happens at X step 3 when > Carlos decides to take a very long lunch? how does the process move along? > what checks/balances are there?" > > That's the part that you're referring to as KC's comment, I think? > > >> Generating a single RPKI root is not hard. It can be done by a cron >> job. I ran one for years, for experimental purposes, entirely from >> data already available to the RIRs. The only real issue is which >> database to believe when they disagree -- which is exactly the problem >> the RIRs are trying to push onto the RPs with this document. >> >> > I don't disagree that running a CA is 'simple'... I think though that if > the RIRs are in a position where there won't be a single root above them > 'for a while' (it's been ~10 yrs at this point) but they feel they need to > move forward with something, is this direction acceptable? is it better to > document that decision and it's gotchas than to not move forward at all? or > to 'continue waiting for the single root' to arrive? > > > Chris, > > fully agree, the intent is to provide unity and transparency on how the > RIRs handle their respective trust anchors at this stage > > ok, I'm glad I ddin't mis-interpret... now I'll wait on stephen/rob to pipe back up :) Maybe this doesn't go through a routing-area group as a document, maybe this should really be in the ops-area group that comes out of SIDR? Or maybe there's pushback that says: "Hey, I hear what you all in the rir want, but it's not cool, please please let's dive back into the politics stream and see how we get movement on what we all (probably?) want: a single root for this system." i'm just fishing for direction. > Andrew > > > > >> Which brings us back to bad technical decisions and political reasons. >> Sorry. >> > > yup. > > >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > > --001a113feba2fb540c053bed1040 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 7, 2016 at 10:55 AM, Andrew de la Haye &l= t;andrewh@ripe.net> wrote:

On 07 Sep 2016, at 16:42, Christopher Morrow <morrowc.lists@gmail.com> wrote= :



On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <sra@hactrn= .net> wrote:
At Tue, = 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
>
> (note, I do not care for this message about politics)

Understood, with the caveat that since it's the politics which a= re
pushing the wrong technical solution here, any technical discussion
will loop back to politics as soon as one asks "why?"


totally agree/understand.=
=C2=A0
> we're here because, I think, from the top down to the RIR there is= n't a
> hierarchy being created, right? the RIR folk are saying: "Ok, you= all want
> this thing, but upstairs hasn't created the root, so we're goi= ng to do the
> best we can with making a root each that allows us to xfer between RIR= s.
> This is how it's being done, so you have some docs about the mecha= nics
> involved and can build/guide from there"
>
> is that not the case? (again, I don't care about the politics)

I'm ignoring "upstairs", because that is also politica= l.


yes, sorry I was trying to not point f= ingers at particular people/things :(
=C2=A0
Stripped of the politics, we're having this conversation because the RIRs are proposing to operate five roots instead of one, with each
root allowed to claim ownership over the known universe, because
actually coordinating with each other is Too Hard.=C2=A0 Or maybe it's = more
than five, some of the RIRs have extra roots just for fun, but let's take it as given for now that they'll collapse back down to five.


ok
=C2=A0
The problem with multiple global RPKI roots, as KC Claffy put it
rather neatly many years ago, is that it pushes responsibility for
fixing RIR coordination mistakes (which the RIRs apparently believe
are a serious issue, as evidenced by the draft under discussion) onto
the relying parties rather than forcing the RIRs to fix those issues
on the CA side.=C2=A0 This is technically broken.


I think it means that since there is n= o single root coming 'soon', the RIR's are taking a step to mov= e forward with rpki despite the 'no single root' existing. Ideally = they would have a method to keep from being out of sync in their processing= of requests/changes. Ideally that process would be outlined in the documen= t here so we'd be able to say: "Ok, as the rpki lives on, how does= X and Y and Z get done? what happens at X step 3 when Carlos decides to ta= ke a very long lunch? how does the process move along? what checks/balances= are there?"

That's the part that you'= ;re referring to as KC's comment, I think?
=C2=A0
Generating a single RPKI root is not hard.=C2=A0 It can be done by a cron job.=C2=A0 I ran one for years, for experimental purposes, entirely from data already available to the RIRs.=C2=A0 The only real issue is which
database to believe when they disagree -- which is exactly the problem
the RIRs are trying to push onto the RPs with this document.


I don't disagree that running a CA= is 'simple'... I think though that if the RIRs are in a position w= here there won't be a single root above them 'for a while' (it&= #39;s been ~10 yrs at this point) but they feel they need to move forward w= ith something, is this direction acceptable? is it better to document that = decision and it's gotchas than to not move forward at all? or to 'c= ontinue waiting for the single root' to arrive?
=

Chris,

fully agree, the intent is to provide unity and transparency on how= the RIRs handle their respective trust anchors at this stage

<= /div>

ok, I'm glad I ddin't mis-int= erpret... now I'll wait on stephen/rob to pipe back up :)
May= be this doesn't go through a routing-area group as a document, maybe th= is should really be in the ops-area group that comes out of SIDR?

Or maybe there's pushback that says: "Hey, I hear = what you all in the rir want, but it's not cool, please please let'= s dive back into the politics stream and see how we get movement on what we= all (probably?) want: a single root for this system."

<= /div>
i'm just fishing for direction.
=C2=A0
Andrew=C2=A0


=C2=A0
Which brings us back to bad technical decisions and political reasons.
Sorry.

yup.
=C2=A0

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

_______________________________________________
sidr mailing listsidr@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/sidr" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/sidr


--001a113feba2fb540c053bed1040-- From nobody Wed Sep 7 09:34:13 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8F12B3EF for ; Wed, 7 Sep 2016 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 kx8Egkz2Glzt for ; Wed, 7 Sep 2016 09:34:09 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9362112B3B7 for ; Wed, 7 Sep 2016 09:34:09 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 6336B3983B for ; Wed, 7 Sep 2016 16:34:08 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id F0AE2420ADDD for ; Wed, 7 Sep 2016 12:32:02 -0400 (EDT) Date: Wed, 07 Sep 2016 12:32:02 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160907163202.F0AE2420ADDD@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 16:34:11 -0000 At Wed, 7 Sep 2016 10:42:10 -0400, Christopher Morrow wrote: ... > I think it means that since there is no single root coming 'soon', Because they have chosen to neither create one nor work out their issues with the obvious external candidate. Politics. > the RIR's are taking a step to move forward with rpki despite the > 'no single root' existing. Ideally they would have a method to keep > from being out of sync in their processing of > requests/changes. Ideally that process would be outlined in the > document here so we'd be able to say: "Ok, as the rpki lives on, how > does X and Y and Z get done? what happens at X step 3 when Carlos > decides to take a very long lunch? how does the process move along? > what checks/balances are there?" So they're proposing a half-assed alternative instead of doing what they should be doing and promised us they would be doing. Politics. > That's the part that you're referring to as KC's comment, I think? No, KC's comment was the observation that this is a cost transfer and a technically bad one: it's the RIRs pushing problems onto RPs instead of solving those problems, and technically bad because the RPs have no sane grounds for deciding which RIR to believe when RIRs disagree. > I don't disagree that running a CA is 'simple'... I think though > that if the RIRs are in a position where there won't be a single > root above them 'for a while' (it's been ~10 yrs at this point) They could have a single root next week if they wanted one badly enough. (Lack of) action speaks louder than words. Politics. Well, unless the current generation of RIR CA implementations don't support the client side of the provisioning ("up-down") protocol, which would be interesting in view of their long-standing promise to move towards a single root. I have no data on this other than that it's been at least five years since the last time I participated in an up-down interoperability test with RIR CA software in the client role; I have no idea whether the RIRs have tested this since that time. > but they feel they need to move forward with something, is this > direction acceptable? is it better to document that decision and > it's gotchas than to not move forward at all? or to 'continue > waiting for the single root' to arrive? Each RIR separately claiming ownership of 0-4294967295,0.0.0.0/0,::0/0 is not progress towards anywhere we want to go. From nobody Wed Sep 7 12:56:07 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D537A12B1AB for ; Wed, 7 Sep 2016 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.028 X-Spam-Level: X-Spam-Status: No, score=-16.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 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 zrm0hukFPTq4 for ; Wed, 7 Sep 2016 12:56:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435E212B358 for ; Wed, 7 Sep 2016 12:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15886; q=dns/txt; s=iport; t=1473278163; x=1474487763; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1akQg/zFiItq7P9n0Sp8SEpU1OpZ2YF2vWaBq8WEbsw=; b=gxVQ7RHJ1vDjYQVm0n+PuvR2h0zw/x9biSFKovX3x/MRxaovi+zU5EtI tK0N86CjJYv+rY6/qsiHWp8hIxkzynBvBkWfnmInsSqXNYRqC3223gC9C wqL/Bp63QexycnuWO02tlkH5gNebQZJhJDnbSubx/jWAbO1ivVked1X3y k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AQAMcNBX/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgnozAQEBAQEeV3wHjSieW4cphQ2CAxkBCoV4AoFqOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwEBAQEaSAkGBQULAgEIEQMBAgEnByEGAQoUCQgCBAENBRuIFQMPCA65J?= =?us-ascii?q?g2CewEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhi+DS4EDgkOBTxEBPIUfHQWZJDU?= =?us-ascii?q?Bi2p3gluBbogThVqIRIQMg3oBHjaCMIIgcIM3gSB/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,296,1470700800"; d="scan'208,217";a="320569662" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2016 19:56:02 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u87Ju18X021490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Sep 2016 19:56:02 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Sep 2016 15:56:01 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Wed, 7 Sep 2016 15:56:01 -0400 From: "Roque Gagliano (rogaglia)" To: Andrew de la Haye , Christopher Morrow Thread-Topic: [sidr] Current document status && directionz Thread-Index: AQHSCUHbwDSafJV2ikaIhhAEiDU42Q== Date: Wed, 7 Sep 2016 19:56:01 +0000 Message-ID: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.172.245] Content-Type: multipart/alternative; boundary="_000_D3F638FF57F9Crogagliaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 19:56:06 -0000 --_000_D3F638FF57F9Crogagliaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andrew, Taking into consideration your call for transparency, do you think the RIRs= could add a section on the document where it is clearly stated what are th= e roadblocks to have a single root? I believe the document describes the pr= oblem and one technical feasible solution but not the full solution space. = We need to understand that this is a decision from which we will most proba= bly not turn back (we are basically deciding that there will never be a sin= gle root). Finally, I can read in your email that you mention that this is a request f= rom =93the RIR folks=94. Are you referring to RIR staff? The boards? The co= mmunities via a bottom-up process? Best regards, Roque =97 Roque Gagliano Tail-f Solutions Architect Southern Europe +41 76 449 8867 From: sidr > on behalf = of Andrew de la Haye > Date: Wednesday 7 September 2016 at 16:55 To: Christopher Morrow > Cc: "sidr@ietf.org" > Subject: Re: [sidr] Current document status && directionz On 07 Sep 2016, at 16:42, Christopher Morrow > wrote: On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein > wrote: At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote: > > (note, I do not care for this message about politics) Understood, with the caveat that since it's the politics which are pushing the wrong technical solution here, any technical discussion will loop back to politics as soon as one asks "why?" totally agree/understand. > we're here because, I think, from the top down to the RIR there isn't a > hierarchy being created, right? the RIR folk are saying: "Ok, you all wan= t > this thing, but upstairs hasn't created the root, so we're going to do th= e > best we can with making a root each that allows us to xfer between RIRs. > This is how it's being done, so you have some docs about the mechanics > involved and can build/guide from there" > > is that not the case? (again, I don't care about the politics) I'm ignoring "upstairs", because that is also political. yes, sorry I was trying to not point fingers at particular people/things :( Stripped of the politics, we're having this conversation because the RIRs are proposing to operate five roots instead of one, with each root allowed to claim ownership over the known universe, because actually coordinating with each other is Too Hard. Or maybe it's more than five, some of the RIRs have extra roots just for fun, but let's take it as given for now that they'll collapse back down to five. ok The problem with multiple global RPKI roots, as KC Claffy put it rather neatly many years ago, is that it pushes responsibility for fixing RIR coordination mistakes (which the RIRs apparently believe are a serious issue, as evidenced by the draft under discussion) onto the relying parties rather than forcing the RIRs to fix those issues on the CA side. This is technically broken. I think it means that since there is no single root coming 'soon', the RIR'= s are taking a step to move forward with rpki despite the 'no single root' = existing. Ideally they would have a method to keep from being out of sync i= n their processing of requests/changes. Ideally that process would be outli= ned in the document here so we'd be able to say: "Ok, as the rpki lives on,= how does X and Y and Z get done? what happens at X step 3 when Carlos deci= des to take a very long lunch? how does the process move along? what checks= /balances are there?" That's the part that you're referring to as KC's comment, I think? Generating a single RPKI root is not hard. It can be done by a cron job. I ran one for years, for experimental purposes, entirely from data already available to the RIRs. The only real issue is which database to believe when they disagree -- which is exactly the problem the RIRs are trying to push onto the RPs with this document. I don't disagree that running a CA is 'simple'... I think though that if th= e RIRs are in a position where there won't be a single root above them 'for= a while' (it's been ~10 yrs at this point) but they feel they need to move= forward with something, is this direction acceptable? is it better to docu= ment that decision and it's gotchas than to not move forward at all? or to = 'continue waiting for the single root' to arrive? Chris, fully agree, the intent is to provide unity and transparency on how the RIR= s handle their respective trust anchors at this stage Andrew Which brings us back to bad technical decisions and political reasons. Sorry. yup. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_D3F638FF57F9Crogagliaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0E3F4D632071CF42B4D1E58587079528@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Taking into consideration your call for transparency, do you think the= RIRs could add a section on the document where it is clearly stated what a= re the roadblocks to have a single root? I believe the document describes t= he problem and one technical feasible solution but not the full solution space. We need to understand that this = is a decision from which we will most probably not turn back (we are basica= lly deciding that there will never be a single root). 

Finally, I can read in your email that you mention that this is a requ= est from =93the RIR folks=94. Are you referring to RIR staff? The boards? T= he communities via a bottom-up process?

Best regards,
Roque

=97 
Roque Gagliano
Tail-f Solutions Architect Southern Europe
+41 76 449 8867


From: sidr <sidr-bounces@ietf.org> on behalf of Andrew de l= a Haye <andrewh@ripe.net>
Date: Wednesday 7 September 2016 at= 16:55
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: "sidr@ietf.org" <sidr@i= etf.org>
Subject: Re: [sidr] Current documen= t status && directionz


On 07 Sep 2016, at 16:42, Christopher Morrow <morrowc.lists@gmail.com>= wrote:



On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <sra@hact= rn.net> wrote:
At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrot= e:
>
> (note, I do not care for this message about politics)

Understood, with the caveat that since it's the politics which are pushing the wrong technical solution here, any technical discussion
will loop back to politics as soon as one asks "why?"


totally agree/understand.
 
> we're here because, I think, from the top down to the= RIR there isn't a
> hierarchy being created, right? the RIR folk are saying: "Ok, you= all want
> this thing, but upstairs hasn't created the root, so we're going to do= the
> best we can with making a root each that allows us to xfer between RIR= s.
> This is how it's being done, so you have some docs about the mechanics=
> involved and can build/guide from there"
>
> is that not the case? (again, I don't care about the politics)

I'm ignoring "upstairs", because that is also political.

yes, sorry I was trying to not point fingers at particular = people/things :(
 
Stripped of the politics, we're having this conversation because the
RIRs are proposing to operate five roots instead of one, with each
root allowed to claim ownership over the known universe, because
actually coordinating with each other is Too Hard.  Or maybe it's more=
than five, some of the RIRs have extra roots just for fun, but let's
take it as given for now that they'll collapse back down to five.


ok
 
The problem with multiple global RPKI roots, as KC Claffy put it
rather neatly many years ago, is that it pushes responsibility for
fixing RIR coordination mistakes (which the RIRs apparently believe
are a serious issue, as evidenced by the draft under discussion) onto
the relying parties rather than forcing the RIRs to fix those issues
on the CA side.  This is technically broken.


I think it means that since there is no single root coming = 'soon', the RIR's are taking a step to move forward with rpki despite the '= no single root' existing. Ideally they would have a method to keep from bei= ng out of sync in their processing of requests/changes. Ideally that process would be outlined in the documen= t here so we'd be able to say: "Ok, as the rpki lives on, how does X a= nd Y and Z get done? what happens at X step 3 when Carlos decides to take a= very long lunch? how does the process move along? what checks/balances are there?"

That's the part that you're referring to as KC's comment, I= think?
 
Generating a single RPKI root is not hard.  It can be done by a cron job.  I ran one for years, for experimental purposes, entirely from data already available to the RIRs.  The only real issue is which
database to believe when they disagree -- which is exactly the problem
the RIRs are trying to push onto the RPs with this document.


I don't disagree that running a CA is 'simple'... I think t= hough that if the RIRs are in a position where there won't be a single root= above them 'for a while' (it's been ~10 yrs at this point) but they feel t= hey need to move forward with something, is this direction acceptable? is it better to document that decision and i= t's gotchas than to not move forward at all? or to 'continue waiting for th= e single root' to arrive?

Chris,

fully agree, the intent is to provide unity and transparency on how th= e RIRs handle their respective trust anchors at this stage

Andrew 


 
Which brings us back to bad technical decisions and political reasons.
Sorry.

yup.
 

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/li= stinfo/sidr

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

 --_000_D3F638FF57F9Crogagliaciscocom_-- From nobody Wed Sep 7 13:10:12 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5303012B395; Wed, 7 Sep 2016 13:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.03 X-Spam-Level: X-Spam-Status: No, score=-16.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 k3mzm48cLVYt; Wed, 7 Sep 2016 13:10:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDEC12B1AB; Wed, 7 Sep 2016 13:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1473279010; x=1474488610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yzTreL6KQD/iUIP4xhs2T7G42ihAQ/6OeykW8fpotPk=; b=Bb6d1u72tm/lo2ENtdV2s4BbwdfksgV3t2Ac/T6nV4MCjYJQXKOD5iLn xS3fP8n1opDl4M3joZcycUyQ2jBq0UiykAD/b358KWZM02vPWkPuPr9NV 3fXWT8VUAHsynAe3ltSnnN35BPoDEQiSagnRTJH9EcMsVldoWS4AzykaO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAQA8c9BX/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgy0BAQEBAR5XfAeNKKsRggMZC4V4AoFqOBQBAgEBAQEBAQFeJ4RiAQEEAQE?= =?us-ascii?q?BawsQAgEIGC4nCyUCBAEJBAUUB4gvDrwyAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWGL4ROhCoWhT8dBY5hingBhxOIKYFujW2MUIN6AR42hFBwg04rgQJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,297,1470700800"; d="scan'208";a="320782995" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2016 20:10:09 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u87KA8n6011171 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Sep 2016 20:10:09 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Sep 2016 16:10:07 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Wed, 7 Sep 2016 16:10:08 -0400 From: "Roque Gagliano (rogaglia)" To: Chris Morrow , joel jaeggli Thread-Topic: [sidr] Current document status && directionz Thread-Index: AQHSCUPUwDSafJV2ikaIhhAEiDU42Q== Date: Wed, 7 Sep 2016 20:10:08 +0000 Message-ID: References: <453bf466-2b47-966f-4378-19a161d0c6a1@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.172.245] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sidr-ads@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 20:10:11 -0000 Hi Chris, With regards to "draft-rir-rpki-allres-ta-app-statement=B2, the question fo= r the WG acceptance should go back to the authors on their willingness to take WG feedback. If the aim is to work with the WG, I think the document describes a current problem with inter-RIR address transfers and one (but maybe not the one the WG would finally document) solution. If the aim is for the RIRs to inform the rest of the world of a decision they have taken, this should be an individual draft submission into the Independent Submission Editor and not a SIDR WG item. Regards, Roque On 06/09/16 18:06, "sidr on behalf of Chris Morrow" wrote: >At Sat, 3 Sep 2016 14:06:25 -0700, >joel jaeggli wrote: >>=20 >> [1 Re: Current document status && directionz ] >> [1.1 ] >> On 9/2/16 1:56 PM, Chris Morrow wrote: >> >=20 >> > Howdy SIDR peeps, >> > (+bonus ops ad) >> >=20 >> > Following on the Berlin meeting we were trying to accomplish two >> > things: >> >=20 >> > 1) get all documents related to sidr protocols into wglc and then >> > publication >> >=20 >> > 2) get all documents which are more operationally focused moved >> > along to an ops group (sidr-ops or something akin to that) >> >=20 >> > With that in mind there are 8 documents in the publication queue: >> > draft-ietf-sidr-as-migration >> > draft-ietf-sidr-bgpsec-algs >> > draft-ietf-sidr-bgpsec-ops >> > draft-ietf-sidr-bgpsec-overview >> > draft-ietf-sidr-bgpsec-pki-profiles >> > draft-ietf-sidr-bgpsec-protocol >> > draft-ietf-sidr-origin-validation-signaling >> > draft-ietf-sidr-rpki-rtr-rfc6810-bis >> >=20 >> > and 11 still in progress. Of the 11 left Sandy and I think they >> > roughly break down like: >> >=20 >> > Documents which should move to the ops group: >> > draft-ietf-sidr-bgpsec-rollover >> > draft-ietf-sidr-lta-use-cases >> > draft-ietf-sidr-route-server-rpki-light - authors notified/queried >>about this >> > draft-ietf-sidr-rtr-keying >>=20 >> I think we good good feeback on the draft of a charter, I will start >> work on taking this to the IESG, but as some point soon the time will >> come to ask for community review of that proposal. >>=20 > >I also forgot to mention the all-res draft: > draft-rir-rpki-allres-ta-app-statement > >is waiting for some AD comments to complete (with chairs I mean) to set >location/direction. > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Sep 8 00:41:17 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A194712B213 for ; Thu, 8 Sep 2016 00:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.409 X-Spam-Level: X-Spam-Status: No, score=-8.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, 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 C-PsfS77x3Kl for ; Thu, 8 Sep 2016 00:41:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD9F12B140 for ; Thu, 8 Sep 2016 00:41:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bhtxP-0001yo-JN; Thu, 08 Sep 2016 07:41:11 +0000 Date: Thu, 08 Sep 2016 00:42:16 -0700 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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: Cc: sidr wg list Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 07:41:15 -0000 > Or maybe there's pushback that says: "Hey, I hear what you all in the > rir want, but it's not cool, please please let's dive back into the > politics stream and see how we get movement on what we all (probably?) > want: a single root for this system." the iab did that and got a written agreement that the rirs would do so. nothing more is needed other than action. randy From nobody Thu Sep 8 06:35:52 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304E412B2A4 for ; Thu, 8 Sep 2016 06:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-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 FcC-VDOR0tcQ for ; Thu, 8 Sep 2016 06:35:45 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9440C12B2EF for ; Thu, 8 Sep 2016 06:32:31 -0700 (PDT) Received: from [198.58.5.42] (unknown [198.58.5.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by guelah.shrubbery.net (Postfix) with ESMTPSA id 6573C78A85; Thu, 8 Sep 2016 13:32:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Heasley X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Thu, 8 Sep 2016 06:32:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F99CEBE-90B9-46F9-92CE-3E773933A760@shrubbery.net> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> To: Randy Bush Archived-At: Cc: sidr wg list Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 13:35:51 -0000 Am 08.09.2016 um 00:42 schrieb Randy Bush : >> Or maybe there's pushback that says: "Hey, I hear what you all in the >> rir want, but it's not cool, please please let's dive back into the >> politics stream and see how we get movement on what we all (probably?) >> want: a single root for this system." Or can the RIRs be removed from the equation? Why must we care what the RiRs= want (fitting of many questions surrounding the RIRs)? Theyre essentially j= ust agents of the IANA, its not inconceivable to replace them or separate du= ties.=20 >=20 > the iab did that and got a written agreement that the rirs would do so. > nothing more is needed other than action. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Sep 8 07:28:58 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EEA12B1A6 for ; Thu, 8 Sep 2016 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WmF_G7lyfbXc for ; Thu, 8 Sep 2016 07:28:54 -0700 (PDT) Received: from bos-mailout2.raytheon.com (bos-mailout2.raytheon.com [199.46.198.208]) (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 3759612B2A9 for ; Thu, 8 Sep 2016 07:28:51 -0700 (PDT) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by bos-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u88ESncl022138 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Sep 2016 14:28:49 GMT Received: from smtp.bbn.com ([128.33.0.80]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u88ESmWu010890 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2016 14:28:49 GMT Received: from ssh.bbn.com ([192.1.122.15]:48848 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bi0Js-000MBd-Kc; Thu, 08 Sep 2016 10:28:48 -0400 From: Stephen Kent To: "Sriram, Kotikalapudi (Fed)" , Christopher Morrow References: <76dad5c8-114a-19fe-6fc2-cf3c45e0f666@bbn.com> <227BF007-90BD-4301-A349-FC01A1A5969A@ripe.net> <9b33dd4f-6361-626d-5e0b-fa6d4ba3b260@bbn.com> Message-ID: Date: Thu, 8 Sep 2016 10:28:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CC: sidr@ietf.org, morrowc.lists@gmail.com, kotikalapudi.sriram@nist.gov X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609080208 Archived-At: Cc: sidr Subject: Re: [sidr] adverse actions -01 posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 14:28:57 -0000 "anomaly" is better than "unwanted" in some respects, but it too fails to convey the fact that the anomaly has an adverse impact on the INR holder. It would be anomalous if a CA changed a cert to contain more resources than were supposed to be allocated to the INR holder, but if these resources are not in conflict with allocations to other INR holders, the effect is not adverse. [Maybe it becomes adverse when the bill arrives ;-)] I'm still reluctant to change the term given the changes I have already made to the text to note that a CA may engage in an action that is perceived as adverse by an INR holder, but the CA may be in the right in effecting this action. Steve > I think using the term "RPKI anomalies" is another choice here. It's kind of neutral about cause/intention. > Advising/alerting the user community about - > RPKI anomalies may arise due to various reasons. > It could be due to fat fingers, negligence, or actions by your service provider or law enforcement, etc. > They have potential impacts on your routing, so you should be watchful, etc.. From nobody Thu Sep 8 07:39:43 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4312B2A7 for ; Thu, 8 Sep 2016 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 bvvMoIpAZ4iZ for ; Thu, 8 Sep 2016 07:39:39 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 EE21E12B1A0 for ; Thu, 8 Sep 2016 07:39:38 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id f76so42778510vke.0 for ; Thu, 08 Sep 2016 07:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=pmbYmYh3dv0qfhEuHdR52c7KvwdHJ6xOHc8FqjVuFh0=; b=SxHAfgcBSeGLbkBHrCwYM4JLEPPMNBGJIrv72EmrWute+uGd1RcvQ/qSX2WTueI3sP R2am0W63l+iim+bRKi0Q4jgFpwvl4XSGrRcieJACF+lr+c94qH5Y7C89ODEK8yVp85qY MJBFikLl9qX+Cqx6fOfsDuYrNrKt2LMnDzoJ+yzTP3ZwtXBJAfOJ0AHKYtqw2j+heiCf V1XvmsPx10m3kSHQhTNz+OvzPmqrPErlF6WxSBJSwEEz6UvxT/C6N38cfGjYTphKNO1X 1uySZgcg8g/3EODjaMXdf1Li/0JAYLHX3hR7pA5AMwgTZpdEgRvB2N2h3dHPTkYDaVXr w44w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=pmbYmYh3dv0qfhEuHdR52c7KvwdHJ6xOHc8FqjVuFh0=; b=cSNZMJRLAuxkTxOQ3EI8KUdE9+0vQRyJwNrWph/FI7wxdh6f+bxhGGCaqESEyjJp8K itApE5nOoWzvT4hcsvoFkOIgAaLru/tcEHssNNKAXVNghopSN255LAQQQ2bUeQt0Dxm/ ju2VqM9vwUi/OFuvfKDDHUGhr++9Ujh755PXBRzPhuaZ/7/xskQHZ75aVIZ6enZ9PG5/ 6SPFDPV8Tl46dcE6gN+Oqf5bLA54/Os4YXJwQbOYGQ+6d4i1YhuphNxRUHoMZ/YE6RhX AbJ/kC+J6Qq2fieTyd9MIjfVwXtQtqkWQjcNe1FR9gdq+HsZDmaGan0jxbY6k2S5iIIW oLrg== X-Gm-Message-State: AE9vXwOnhKmEo6cZcu/xNXlUMJgvItBHgjO02hkxpVbi0tcfcv3l7DM56g9Pq3KoYJN2zA== X-Received: by 10.31.219.194 with SMTP id s185mr14484202vkg.31.1473345577783; Thu, 08 Sep 2016 07:39:37 -0700 (PDT) Received: from [200.7.87.24] ([200.7.87.24]) by smtp.gmail.com with ESMTPSA id w66sm5894672vkw.13.2016.09.08.07.39.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 07:39:37 -0700 (PDT) From: "Carlos M. Martinez" To: sidr Date: Thu, 08 Sep 2016 11:39:35 -0300 Message-ID: <5E409AD4-CF23-4D7A-8052-52F6D7EF4C30@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5260) Archived-At: Subject: [sidr] On 0/0 at the 5 TAs - Answers to some questions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 14:39:40 -0000 Hi all, In this second email, I will take most of the questions I identified in the directionz thread and we can take it from here: 1- Whether the RIRs are willing to "back up on this" -- Depending on what is meant by 'this'. If 'this' refers to 'back up on the whole 0/0 idea', I of course cannot provide an absolute answer, but I don't think the RIRs are willing to do that just now. However, we don't necessarily see 0/0 as a permanent state, just as the previous one wasn't. If 'this' refers to WG adoption, definitely. If the WG doesn't want the document, then we are fine with that. We will probably pursue an independent submission since we believe that it’s important that this gets documented within the IETF. 2. Regarding how the top levels of the cert tree will look like (Roque) -- Roque asks whether there will be a 2nd level certificate that will list the resources each RIR has, in the same way as today's top level certificates do. Short answer: it will be RIR-dependent. A bit longish answer: In our case (LACNIC), we will probably do what you've described, but just because that is the simplest thing for us to do. However, bear in mind we don't have inter-RIR transfer policies that apply to us, and if such a policy gets approved we will probably review this decision. If there is a need to have a way to list what an RIR's holdings are, there are ways to do that which do not involve RPKI. In fact, RPKI certs are not authoritative as of today. They are fed from other systems that are authoritative; systems that also feed the logic that generates the 'delegated-extended-stats' files. Regarding listing resources, these files are just as authoritative as the RPKI certs are. An RIR's holdings can be easily aggregated up by looping through the delegated-extended files. If there is a community need that the RIRs publish a file stating which our holdings are, we are open to talk about it. Again, thanks for all your feedback. -Carlos From nobody Thu Sep 8 07:39:46 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD16A12B1A0 for ; Thu, 8 Sep 2016 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 b_l5nExErDKD for ; Thu, 8 Sep 2016 07:39:39 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6FC12B28C for ; Thu, 8 Sep 2016 07:39:39 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id b7so42114734uab.3 for ; Thu, 08 Sep 2016 07:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version; bh=MaVaZlvFtgHcARNU9U+TOcZVG6O2GCCB2wAsm1y2y0E=; b=0zx3NGQcuQusbPwQwanl0aTk4X85dYBYPj5Vxb4DkFxS7i9DEvjRpEhIHhzvDYa+Zu alfLMQrWhYIfvEZSbh4MIaTaIKZl3L3yJvwS+RsiOgT2SnZYO3WDSQCeUOTOVG3aM9P6 Y1iQXfAJYRSyBYzL/5o58fAsJQxEwunddzznb1PG+NnqffNCqMzU6ZbyxvOPGbe34wQD UKdJeNbyhgawQuDbkMoR4cy287Xts+hLnRo6sMhl8s5Rb/WBm8BIexFIprzBleeQ8sXq 2Bwm5/P4IufdZ4XMoExon2NpEA8MSkzDgfCLORCGBedwN5mAz192g4rgpuNKCOTAvcf5 aKrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=MaVaZlvFtgHcARNU9U+TOcZVG6O2GCCB2wAsm1y2y0E=; b=HeBjji/QFPFviIfiBtv8uMoKa87bXmzYk5aeGglijmpRhCNfC7zL1tLxmDJBEQc4Id ZS7eC7DoTC6blFkh15oiyHZ5PEwvh3wga+2RV1W0QtvGnztlrh5+O9akdsiVcI565GGb Mfl4ozWz6NBfs8KAIWdE9+4y0XxYOvIT6pef7g8/VuvO1IrGW1W2XYN5x0kYcdYFo/F6 WarFeftXB9AXABuHoOY276LPhm7bGsp1ieu/659oPqgUNbq7edQKPE1IJAacOXKwagzj rcTZY81YOwNS4i4FZjog8IHcmj5ySZ+GgN27nOqxqUkGSbaXzZw338rfkbrqxzwCBGkT ZE5Q== X-Gm-Message-State: AE9vXwPo3x1xpHYVAqrn3PvBZVfqfq+1K+hfYdNCtB/RBreZAkwtG3YbPQ1oXFRmhy2fXA== X-Received: by 10.159.53.33 with SMTP id o30mr11908353uao.106.1473345578629; Thu, 08 Sep 2016 07:39:38 -0700 (PDT) Received: from [200.7.87.24] ([200.7.87.24]) by smtp.gmail.com with ESMTPSA id 105sm4821884uas.27.2016.09.08.07.39.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 07:39:37 -0700 (PDT) From: "Carlos M. Martinez" To: sidr Date: Thu, 08 Sep 2016 11:39:33 -0300 Message-ID: <85DF97DE-0EFD-4002-8EDE-83C3B6CB8E8F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5260) Archived-At: Subject: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 14:39:41 -0000 Hello all I'm going to provide the best answers I can to the questions that have been made in the mailing list. I'm spinning a new thread so we don't hijack the WG directionz one. Intentionally I'm **not** going to answer any emails that invoke politics. Those who feel they need answers from that side of things know who you can refer to. First of all, thanks for the feedback. To be honest, I am quite surprised that it took this long. This document was first presented in Buenos Aires, which was almost 5 months ago. This decision to move to 0/0 is a solution born more of necessity than desire for the following reasons: a. There exist political obstacles to a global trust anchor of 0/0 that are, at the moment and for the foreseeable future, insurmountable. This is regrettable, but also a reality and should not be denied. b. Due to the above, there is an inconsistent model of trust anchors published by the RIRs. This solution does fix this problem, making the overall RPKI at least consistent. c. The RPKI does not have a graceful mechanism for which to handle "ERX space" (networks managed by one RIR placed under the IANA allocation for another RIR). As inter-RIR transfers become more common place, the ERX space will become more fluid and a source of conflict. Management of ERX space is all the more difficult to manage under the RPKI as there is no make-before-break mechanism built-in to the RPKI nor does the RFC 6492 protocol provide a mechanism for parent-to-child messaging with which to enable a make-before-break mechanism. d. Given the fluidity of the ERX space mentioned above and the current validation algorithm, there is foreseeable fragility of the system that is solved by this solution. The IETF is working on changing the validation algorithm, but this change has been in progress for years and is still dependent on a timetable for publication of new ROAs by all CAs and installation of new software by all RPs. e. Given that there is no global trust anchor and the RIRs each operate offline Trust Anchors for security, having just the resources actually assigned or allocated by the respective RIR, would require a trip to the datacenter for each inter-RIR transfer which will incur delays and result in resources showing up at two RIRs simultaneously, or none of the RIRs for some time as TA certificates are updated independently. Thanks to all! -Carlos From nobody Thu Sep 8 08:41:29 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ABE12B1B5 for ; Thu, 8 Sep 2016 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsIxEw12qj64 for ; Thu, 8 Sep 2016 08:41:26 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 A106012B4B4 for ; Thu, 8 Sep 2016 08:36:57 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id l91so8211676qte.3 for ; Thu, 08 Sep 2016 08:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xa/kipwTCl5fXxHWuqkVPMnM1cpJTKoFNs3cuJ/W3Ow=; b=1Hxy9gqsvzvc+rpuBE8Cng4zyg+qC0M6c+Vtx6vSC+P9yqAzbXkyFpbYnHjA3C2k6W RmI+zXA4LCPKA1jKniBOuzXbfbSpSIrMLREC8LSnCq8MMZhHlDgH7rusrpZO/4BHWcR7 tlGlL2qARpjeH/DbtMePteXnVkHXnZP+eiOBA2Zs2va9j/78ABG2vZiIadtlIcbinR+a Qwq3C+9ti4hS2ErUZBcnjCxLQEdNBOCeBczjg21rd3fk1iBm1/cZ/rxElbVHOVDMsLBc DZBQGtZoKKIr/66mihQRDSKhM4SWpP/jy2+0kTmGNzZAUSbVlRFWK15Nc71bx39Y7uJD PPhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xa/kipwTCl5fXxHWuqkVPMnM1cpJTKoFNs3cuJ/W3Ow=; b=MQ0VuElngDgxNSUhLBcLiv2Vve+W1MmQ4mDQ7IwFTlLM1RT4J+uqxsLSqQVgF4O/pr Eb9HJ7hAkZepUvYcQ50xSoDDOqqW82TOUG79M1ML1+QeetkSxGJ8PHHNY0AZrB1jcH9T V/bp5vPXFRPfPXfqmOpsjPmDO3fqOB7A+FCvyAhHWwqJy3soD8iB6XgR+RKQ03rL7tev 9VCEfMsLehVtBTXwlK/xTHNm/U7Zb8i1O1qPKDxtYso4+fh+j+AtiPwMLkiREU80Xdna e7okWOKYNA+T0jOAYcXWjITzFp15Fy4zhvGcV5sgtdEiM2GQQRQFg7UbC84uqByOLzJy eJxw== X-Gm-Message-State: AE9vXwMx8Mf9YqdIx0shzFSawUKBuZdaTrLgeNUsEPQldRmvz2d90AT6+3898YoTZUBan2vhFCDZAG/tHDCQqQ== X-Received: by 10.237.42.165 with SMTP id t34mr345456qtd.106.1473349016762; Thu, 08 Sep 2016 08:36:56 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Thu, 8 Sep 2016 08:36:56 -0700 (PDT) In-Reply-To: <3F99CEBE-90B9-46F9-92CE-3E773933A760@shrubbery.net> References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> <3F99CEBE-90B9-46F9-92CE-3E773933A760@shrubbery.net> From: Christopher Morrow Date: Thu, 8 Sep 2016 11:36:56 -0400 X-Google-Sender-Auth: ctSBZW6SBQGkj4n1RfV9ZMKVpbU Message-ID: To: Heasley Content-Type: multipart/alternative; boundary=94eb2c06a3b0c64072053c00cca5 Archived-At: Cc: sidr wg list Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 15:41:28 -0000 --94eb2c06a3b0c64072053c00cca5 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 8, 2016 at 9:32 AM, Heasley wrote: > > > Am 08.09.2016 um 00:42 schrieb Randy Bush : > > >> Or maybe there's pushback that says: "Hey, I hear what you all in the > >> rir want, but it's not cool, please please let's dive back into the > >> politics stream and see how we get movement on what we all (probably?) > >> want: a single root for this system." > > Or can the RIRs be removed from the equation? Why must we care what the > RiRs want (fitting of many questions surrounding the RIRs)? Theyre > essentially just agents of the IANA, its not inconceivable to replace them > or separate duties. > > sure... I think sriram may cover this in his document about the decision processes which lead to where we are today. I think, one way to look at the document and situation is this: o community folks for each RIR asked for RPKI to be supported o RIR folk put in some development $$/effort to do that o no single-root came forward o to make the RPKI work, specifically for xfers, or one way wrt transfers, is to fake the root at each RIR. o rpki progress can still be made until single-root arrives, and then some re-signing and probably rough work would have to happen to move under the single-root. sure lots of evil other things could be afoot, but I don't see evidence of that. again, perhaps it's worth the community folks (outside the ietf) just saying: "I hear what you're saying, I like your want to keep this going forward, but REALLY we need to sort out the issues around 'single-root' and get that done.. the operational cost to not having a 'single-root' is just too damned high." > > > > the iab did that and got a written agreement that the rirs would do so. > > nothing more is needed other than action. apologies for not being up on the chain-of-command, but this doesn't seem like it's enough... we've been waiting, what are the blockers? why can't this action move forward? (yes, politics, let's move that to anyother list I suppose) -chris --94eb2c06a3b0c64072053c00cca5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 8, 2016 at 9:32 AM, Heasley <heas@shrubbery.net>= wrote:


Am 08.09.2016 um 00:42 schrieb Randy Bush <randy@psg.com>:

>> Or maybe there's pushback that says: "Hey, I hear what yo= u all in the
>> rir want, but it's not cool, please please let's dive back= into the
>> politics stream and see how we get movement on what we all (probab= ly?)
>> want: a single root for this system."

Or can the RIRs be removed from the equation? Why must we care what = the RiRs want (fitting of many questions surrounding the RIRs)? Theyre esse= ntially just agents of the IANA, its not inconceivable to replace them or s= eparate duties.


sure... I think sriram may cover this = in his document about the decision processes which lead to where we are tod= ay.

I think, one way to look at the document and s= ituation is this:
=C2=A0 o community folks for each RIR asked for RPKI t= o be supported
=C2=A0 o RIR folk put in some development $$/effor= t to do that
=C2=A0 o no single-root came forward
=C2= =A0 o to make the RPKI work, specifically for xfers, or one way wrt transfe= rs, is to fake the root at each RIR.
=C2=A0 o rpki progress can s= till be made until single-root arrives, and then some re-signing and probab= ly rough work would have to happen to move under the single-root.

sure lots of evil other things could be afoot, but I don= 9;t see evidence of that.

again, perhaps it's = worth the community folks (outside the ietf) just saying:
=C2=A0 "I= hear what you're saying, I like your want to keep this going forward, = but REALLY we need to sort out the issues around 'single-root' and = get that done.. the operational cost to not having a 'single-root' = is just too damned high."

= =C2=A0
>
> the iab did that and got a written agreement that the rirs would do so= .
> nothing more is needed other than action.

<= div>apologies for not being up on the chain-of-command, but this doesn'= t seem like it's enough... we've been waiting, what are the blocker= s? why can't this action move forward? (yes, politics, let's move t= hat to anyother list I =C2=A0suppose)

-chris=C2=A0=
--94eb2c06a3b0c64072053c00cca5-- From nobody Thu Sep 8 08:43:45 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2038C12B333 for ; Thu, 8 Sep 2016 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 dDDeo929Ew_t for ; Thu, 8 Sep 2016 08:43:43 -0700 (PDT) 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 8BC0312B2D9 for ; Thu, 8 Sep 2016 08:39:15 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (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 93CAA13992 for ; Thu, 8 Sep 2016 15:39:11 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id F0CA0420E4D8 for ; Thu, 8 Sep 2016 11:37:01 -0400 (EDT) Date: Thu, 08 Sep 2016 11:37:01 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <85DF97DE-0EFD-4002-8EDE-83C3B6CB8E8F@gmail.com> References: <85DF97DE-0EFD-4002-8EDE-83C3B6CB8E8F@gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160908153701.F0CA0420E4D8@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 15:43:44 -0000 Hi, Carlos. Technical question: Do the current RIR CA implementations support the client role of the "up-down" provisioning protocol, and, if so, has there been any recent interop testing of this, either against other RIR CA implementations or against mine? APNIC's original implementation did support it. I think RIPE's implementation sort of supported it at one point but they did not consider it production-ready. Dunno about the others, and all of this was a while ago, haven't heard much about it recently. From nobody Thu Sep 8 09:02:15 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9987D12B352 for ; Thu, 8 Sep 2016 09:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJSGt9Wkzcbw for ; Thu, 8 Sep 2016 09:02:10 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 78A4E12B421 for ; Thu, 8 Sep 2016 08:58:02 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 16so25710638vko.2 for ; Thu, 08 Sep 2016 08:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=W4pOn6FyIoOSjuGmMwz+wXy3fct60AQZzhgF3ZXgoE0=; b=Alhq4d/NsLiQcY5uibtB5eqZT3AN7nLZ4mZkloZMvaFcQBzGIxwdhUhsxosMPAEqvR 0K4BL9J4lK2/fqaK2sQcEi4fp5/lj1+saVXr5c7vgaDzM46Syw73zoA36KLq25RPb8AI OkUCd7hCJdEbftV5f9EPQ0KlY+/6NLpYREPDkWi6y+YfV4Dp6sNllPI62y7oKi+95eAF S1J2jjAyDYVwtyhjh5FntzJtsntjUvLFDIS3lW+SLGrrFB7oa4Pd/J0loXTaPk+9+K9F 4gwGnP4xsCCD1+Nq879LGrdE5WQtrhsjR3wrO6lVgPd3YDaFEnbMbqoW5XSAujvrpEuC bPVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=W4pOn6FyIoOSjuGmMwz+wXy3fct60AQZzhgF3ZXgoE0=; b=ZrlgsndxlwouLdJiamg2v5uW5dWwF1BMty+MP8V4RiKICvU2qjF5Om2t0O1PZApjvs dUcoITUw3b8Wp3jzLWhCdteJ31FMYw9flxOdRsvdYj/JImoUIjhZyaA0KM84ULJQaOHS NdhXknVobrvjnHiuCO6UJ+9kSxq7O6G6UiLCm2Q1efSAthmulMhRaoqI3I7vq1jtZH61 WmaQF6ITnv3bkRVthfc2Gf5KY4q0HcRY+ok/bhOz7Xy7vgrZYGwMtfmG9ZCZ7CBDgzWw nn6qvQN+Je57yTEurewWNuIoqT31J2dSdJmmRxq5dmUIpuNTE9a9Dd+vqrFkmnfEtMDu iC9g== X-Gm-Message-State: AE9vXwMszx7vlvLYVtyrrsEsRzo4+Y3I1Kuf7LggN6/TMrW5Y9P8F/YaGCSBGidO0DYHxg== X-Received: by 10.31.83.65 with SMTP id h62mr256514vkb.63.1473350281241; Thu, 08 Sep 2016 08:58:01 -0700 (PDT) Received: from [200.7.87.24] ([200.7.87.24]) by smtp.gmail.com with ESMTPSA id 12sm3741994uak.7.2016.09.08.08.57.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 08:58:00 -0700 (PDT) From: "Carlos M. Martinez" To: "Rob Austein" Date: Thu, 08 Sep 2016 12:57:57 -0300 Message-ID: <1839617E-8453-4A26-9A4A-7428EE887CF5@gmail.com> In-Reply-To: <20160908153701.F0CA0420E4D8@minas-ithil.hactrn.net> References: <85DF97DE-0EFD-4002-8EDE-83C3B6CB8E8F@gmail.com> <20160908153701.F0CA0420E4D8@minas-ithil.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5260) Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 16:02:14 -0000 Hi Rob, I’ll let each RIR answer for themselves. In our case (LACNIC), we don’t support up/down. We’ve had a very rough implementation of a ‘parent’ CA for a while, but since there is essentially no demand for it from our members, the project always gets down-prioritized. If the GTA was to gain any traction, we’d commit resources accordingly in order to support it from the ‘child’ side. In short: it’s not the availability of up-down what has stalled the GTA. tks! Carlos On 8 Sep 2016, at 12:37, Rob Austein wrote: > Hi, Carlos. Technical question: > > Do the current RIR CA implementations support the client role of the > "up-down" provisioning protocol, and, if so, has there been any recent > interop testing of this, either against other RIR CA implementations > or against mine? > > APNIC's original implementation did support it. I think RIPE's > implementation sort of supported it at one point but they did not > consider it production-ready. Dunno about the others, and all of this > was a while ago, haven't heard much about it recently. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Sep 8 10:39:30 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8C12B294 for ; Thu, 8 Sep 2016 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-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 K9kZsR6qNV46 for ; Thu, 8 Sep 2016 10:39:28 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 EBED512B03F for ; Thu, 8 Sep 2016 10:39:27 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id cm16so19467182pac.0 for ; Thu, 08 Sep 2016 10:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=CbqfG9A7ugwSXWWbO62tLOlsUD7ffmH1iJ0R5wrAkY4=; b=EhjDYVUQf8C7bXUjJUxhVV4DpoJRMCddndERsqgI2igOr6lfDWvHCnI3lklIpMDSkb A1T+2OJa3UHFBrVBBuGQAhJ5ZDSYsfpqUBgoco7iyC+2lRpXtCYecU9GqiP8wTIQq/XI W9mCSDCPwsLcg8S7ThMjjpLB3JqQPi0okk0+jwL7KWsvq8bKcfJhKAL9E/Vtphr+JXkU 8ITFIf8KTr0P3eNJPXN+mlZp6auEeUfbKnAVZImG9T++xlLe1U/Sg7RJr/myxzK508J5 uPbVojHu2R1HN15+KYhhpaF9+NyOx84lcp3wXJkarFmsKXHdkyJMjiTEK0TbW4YKclQU muqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=CbqfG9A7ugwSXWWbO62tLOlsUD7ffmH1iJ0R5wrAkY4=; b=WFx4D8bzV55nnI2ys5iCqRFOUVok0IAvAB4JmnyFhzOdYNubzUNP9QmmqebaNln7Wu u2FL5+buOuMVgblAgi8gvT273bJ3BtWKsFBnfUyHcrM+jYsEvtMHovus0qI4xd4DR1b8 +cvK+qy9hK6D0o8vHIjDOKmjCFrzn+MbH/vA6bdcgLxFddBj7xjHLi+5WX9eFIZClsS5 YqwO14zRuHLLOalpoUX9N3dqGsEXjP5EDnfXzc48Rucqi+zhxazxtVk4y8F34Kmvd6Wg ujaBFsPfUBzee/hopO+VAmTbKPUZrX5MAkLWt02MxO8zaQ5cn8qECgrrJcT57ku0h8SO qAIg== X-Gm-Message-State: AE9vXwPxS0uqjBzT8CeS0ahJLjYLLktCpLzSlnpKBbbksmHF/3Zq+hB0BTliJhNbCpE0Ow== X-Received: by 10.66.182.167 with SMTP id ef7mr1477345pac.128.1473356367486; Thu, 08 Sep 2016 10:39:27 -0700 (PDT) Received: from DACO-4417.local.mail ([72.234.167.101]) by smtp.gmail.com with ESMTPSA id yu7sm57956349pab.45.2016.09.08.10.39.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 10:39:26 -0700 (PDT) Date: Thu, 8 Sep 2016 07:39:23 -1000 From: David Conrad To: Christopher Morrow Message-ID: In-Reply-To: References: <349cb6ac-f4fe-29e5-b01f-3223b14e47de@gmail.com> <0a66024b-5cae-1abb-dc53-b11c1e35cdeb@bbn.com> <20160906220000.F1005420823A@minas-ithil.hactrn.net> <20160907040720.769594208DBB@minas-ithil.hactrn.net> X-Mailer: Airmail (382) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="A6B4569A-0ECD-40C0-B133-0CD42E39F507"; protocol="application/pgp-signature"; micalg=pgp-sha512 Archived-At: Cc: "=?utf-8?Q?sidr=40ietf.org?=" Subject: Re: [sidr] Current document status && directionz X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 17:39:30 -0000 --A6B4569A-0ECD-40C0-B133-0CD42E39F507 Content-Type: multipart/alternative; boundary="57d1a24b_86ff14b_1a2d" --57d1a24b_86ff14b_1a2d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Chris, On September 7, 2016 at 4:42:21 AM, Christopher Morrow (morrowc.lists=40g= mail.com) wrote: I don't disagree that running a CA is 'simple'... I think though that if = the RIRs are in a position where there won't be a single root above them = 'for a while' (it's been =7E10 yrs at this point) but they feel they need= to move forward with something, is this direction acceptable=3F is it be= tter to document that decision and it's gotchas than to not move forward = at all=3F or to 'continue waiting for the single root' to arrive=3F =46or blood pressure spiking reasons, I have been trying to keep out of t= his discussion, but this put me over the edge. As far as I am aware, ICANN as the IANA Internet Numbering =46unctions Op= erator, has been and continues to be willing to provide RPKI =22single ro= ot=22 services. In point of fact, ages ago, I personally authorized non-t= rivial expenditures (including hiring staff) to set up and deploy a worki= ng RPKI root pilot to allow the RIRs to test working with a single root a= s directed by the IAB in https://www.iab.org/documents/correspondence-rep= orts-documents/docs2010/iab-statement-on-the-rpki/: =22Thus, the IAB strongly recommends a single root aligned with the root = of the address allocation hierarchy (now part of the IANA function).=C2=A0= =22 After said testbed deployment, I was informed that none of the RIRs were = interested in participating in the tests. I will admit a high level of amazement and not a small amount of disappoi= ntment at the fascinating level of complexity being created in order to a= void a single root. This is not technical. =C2=A0 Regards, -drc --57d1a24b_86ff14b_1a2d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline