Re: [sidr] BGPSec RFC status
Warren Kumari <warren@kumari.net> Mon, 25 April 2016 14:53 UTC
Return-Path: <warren@kumari.net>
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 E0CDA12D5DC for <sidr@ietfa.amsl.com>; Mon, 25 Apr 2016 07:53:38 -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=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUaei1HWCyxn for <sidr@ietfa.amsl.com>; Mon, 25 Apr 2016 07:53:36 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 B44BD12D606 for <sidr@ietf.org>; Mon, 25 Apr 2016 07:53:30 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id x7so63056668qkd.3 for <sidr@ietf.org>; Mon, 25 Apr 2016 07:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PuUsD16MCvXJF8JvGyVbRnHrTTLLDE/IPNDADP+Fato=; b=XZoiWG/aX8kDSbObV1Q2lPQS4iCpH6a5tPjiJ7dp0gm8jGTPoYQqNaKjJx5O3aEEQd ZNEEvoyJ5Wct3E2p9OXQt99bqN6llwMTG4tTQAxIfDyFSza5hUDFwrEb3SjqaV9iLpo5 0eQ64wmsOGmSYUfxSi/PSwqMWzBoYdtEBdpI7SoyVPiW2LtUE3Dzxdn3ThgxNgz234ae 5jUna3C58P+VfkMhjaRkgNqGCSYreMfYSMg/JC6QkAvHSrgFUtdeYEgHW5iEDCAGZNNG +ICuNRREtGYo8/Og9e9GBb2e7R2SLEw+adDzsNS5mYnMjSEBW9klGdSI9J7IjPUp/CsL jFkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PuUsD16MCvXJF8JvGyVbRnHrTTLLDE/IPNDADP+Fato=; b=Q6+85fP7JcLzCyZAz+TzqE4sVGhJnzLpYM2j1aO0FBnZhA7Ka+CARsMKxUzv6m4+OP OPHLwVgP1dceR7e9VojmxcZ1XAD9c1Z5EjNsXB/SbSv3pBTeII9FWl1MCLnjV6n5LByM Ltf4sTpYRKXGyqk0ap6fXeaayPDiOc435C0JQ5heLFiWFDlRjicN2qPTIdfoD5MzU2h+ Pw5ta9AtNOereENrxxJI/qNKAhshjA1jDyKlmOnWGVATd+YLSES3xj/0or8Z8B/Rmo04 YDv0aQqve8klEglsMB5dOQaP3an/XcxxyaqgGGrs6Uas1ZeuiutLB5hYQSJoCxQdHk02 h4Ng==
X-Gm-Message-State: AOPr4FU0ziZEtkvlhjo5/TYUpCQ7PT47KAkbKwPNeYZjSHLj1LpQO5sVD6navAnncl0Okjzpx0DAONUsRfs4IpRG
X-Received: by 10.55.203.8 with SMTP id d8mr18492688qkj.124.1461596009825; Mon, 25 Apr 2016 07:53:29 -0700 (PDT)
MIME-Version: 1.0
References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <D33C7D23.4547B%rogaglia@cisco.com> <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net>
In-Reply-To: <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 25 Apr 2016 14:53:20 +0000
Message-ID: <CAHw9_iJk-P+BxWnyYXsC0uhn9ahirAHD2dSd48mjYRu2wqOMcg@mail.gmail.com>
To: Tim Bruijnzeels <tim@ripe.net>, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
Content-Type: multipart/alternative; boundary="001a113a3a50f89feb05315056af"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/C8h4EHD7RJm2Cx30Vxfu0DGmFr8>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] BGPSec RFC status
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2016 14:53:39 -0000
... and another +1. W On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels <tim@ripe.net> wrote: > > > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <rogaglia@cisco.com> > wrote: > > > > +1 with Standard Track. > > +1 > > > > > The question could have been relevant six years ago and we may not have > > debated it that much then. Today, we are clearly beyond experimental > draft > > definition and we do not want to stop people working on the topic. > > > > Roque > > > > > > > > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" < > sidr-bounces@ietf.org > > on behalf of gih@apnic.net> wrote: > > > >> > >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <kent@bbn.com> wrote: > >>> > >>> I didn't attend the IETF meeting, but I did listen to the Wednesday > >>> SIDR session, at > >>> which the issue was raised as to whether the BGPSec RFC should be > >>> standards track > >>> or experimental. > >>> > >> > >> I was in the room, but did not speak to this topic. > >> > >>> I believe standards track is the right approach here. > >> > >> I consulted the oracle of RFC2026 and read the following: > >> > >> A Proposed Standard specification is generally stable, has resolved > >> known design choices, is believed to be well-understood, has received > >> significant community review, and appears to enjoy enough community > >> interest to be considered valuable. However, further experience > >> might result in a change or even retraction of the specification > >> before it advances. > >> > >> This seems to fit well, including the caveats at the end. > >> > >> On the other hand: > >> > >> The "Experimental" designation typically denotes a specification that > >> is part of some research or development effort. Such a specification > >> is published for the general information of the Internet technical > >> community and as an archival record of the work, subject only to > >> editorial considerations and to verification that there has been > >> adequate coordination with the standards process (see below). > >> > >> Which seems to fall short. > >> > >> The exercise of RFC publication of BGPSec is more than archival, and the > >> process > >> has been much more than a cursory exercise of coordination with the SIDR > >> WG. While > >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow¹s > >> Internet, that > >> future uncertainty applies to most of the IETF¹s work, and that > >> consideration > >> should not preclude its publication as a Proposed Standard, as I > >> interpret RFC2026. > >> > >> Geoff > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >
- [sidr] BGPSec RFC status Stephen Kent
- Re: [sidr] BGPSec RFC status Russ Housley
- Re: [sidr] BGPSec RFC status Declan Ma
- Re: [sidr] BGPSec RFC status Geoff Huston
- Re: [sidr] BGPSec RFC status Russ White
- Re: [sidr] BGPSec RFC status Russ White
- Re: [sidr] BGPSec RFC status Randy Bush
- Re: [sidr] BGPSec RFC status Christopher Morrow
- Re: [sidr] BGPSec RFC status Rob Austein
- Re: [sidr] BGPSec RFC status t.petch
- Re: [sidr] BGPSec RFC status John G. Scudder
- Re: [sidr] BGPSec RFC status Joel Jaeggli
- Re: [sidr] BGPSec RFC status Roque Gagliano (rogaglia)
- Re: [sidr] BGPSec RFC status Tim Bruijnzeels
- Re: [sidr] BGPSec RFC status Christopher Morrow
- Re: [sidr] BGPSec RFC status Warren Kumari
- Re: [sidr] BGPSec RFC status Christopher Morrow
- Re: [sidr] BGPSec RFC status Sharon Goldberg