IETF Logo Mail Archive

Re: [sidr] BGPSec RFC status

"Roque Gagliano (rogaglia)" <rogaglia@cisco.com> Tue, 19 April 2016 22:31 UTC

Return-Path: <rogaglia@cisco.com>
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 4C64E12E7A1 for <sidr@ietfa.amsl.com>; Tue, 19 Apr 2016 15:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 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=-0.996, 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 jo4cxSVwPx-X for <sidr@ietfa.amsl.com>; Tue, 19 Apr 2016 15:31:34 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEF112E744 for <sidr@ietf.org>; Tue, 19 Apr 2016 15:31:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2364; q=dns/txt; s=iport; t=1461105094; x=1462314694; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BvnZGD+5HODWqTyGm3ar4enmGeewRc6gHrTMrCArZMA=; b=e2MaPCaYKXx0RlyxVpGAjdO59oOQnVO5DJDKOm/2vpFqx7bnbkJZ/IVH ERYsZWvS5flekDr2A4S4YByYGIcxfmn/C/8w/l+9/epaih45XJ9LmaHfZ b3o5+8sNPQAzIpzJkw3CglMLgf6F80KqWIQoM9k2unD2jhvluAGRFE95p k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQAgCdsRZX/4UNJK1egzhTfQa5cAENgXEXC4VnAQIBAQKBSzgUAQEBAQEBAWUnhEEBAQEDAQEBAWsbAgEIGC4nCyUCBBMUiA0IDr1fAQEBAQEBAQECAQEBAQEBAQEUBIYhhEuKFQWOC4oDAY4RgWaHd4UzjyoBHgEBQoIEGoFKbIgVfgEBAQ
X-IronPort-AV: E=Sophos;i="5.24,507,1454976000"; d="scan'208";a="99118796"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2016 22:31:23 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3JMVNZs024672 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <sidr@ietf.org>; Tue, 19 Apr 2016 22:31:23 GMT
Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 18:31:22 -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.1104.009; Tue, 19 Apr 2016 18:31:22 -0400
From: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
To: sidr <sidr@ietf.org>
Thread-Topic: [sidr] BGPSec RFC status
Thread-Index: AQHRmoszlHYu8eSboE2+sKRlZsym3A==
Date: Tue, 19 Apr 2016 22:31:22 +0000
Message-ID: <D33C7D23.4547B%rogaglia@cisco.com>
References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net>
In-Reply-To: <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.246.207]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3F2A0928AA2E1E48A35576C2B3F76012@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/pj5w0w2N0kcDlZdUXzApAcUinN0>
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: Tue, 19 Apr 2016 22:31:36 -0000

+1 with Standard Track.

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

v2.23.0 | Report a Bug | By Email