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
>