Re: [sidr] BGPSec RFC status

Joel Jaeggli <joelja@bogus.com> Sun, 17 April 2016 16:35 UTC

Return-Path: <joelja@bogus.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 08E9012DA8B for <sidr@ietfa.amsl.com>; Sun, 17 Apr 2016 09:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level:
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 aS0DhgPPvVSd for <sidr@ietfa.amsl.com>; Sun, 17 Apr 2016 09:35:18 -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 3A35712DA0D for <sidr@ietf.org>; Sun, 17 Apr 2016 09:35:18 -0700 (PDT)
Received: from [IPv6:2601:647:4204:51:8864:8274:5c2b:a9ec] ([IPv6:2601:647:4204:51:8864:8274:5c2b:a9ec]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u3HGZGwf004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Apr 2016 16:35:17 GMT (envelope-from joelja@bogus.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joel Jaeggli <joelja@bogus.com>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <723CA032-880C-4B37-A8EC-35D67964BFDC@juniper.net>
Date: Sun, 17 Apr 2016 09:35:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <42592C0A-B1A1-4992-8476-724FF26768A3@bogus.com>
References: <570E8D44.1080208@bbn.com> <723CA032-880C-4B37-A8EC-35D67964BFDC@juniper.net>
To: "John G. Scudder" <jgs@juniper.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/HZpVPNULGIDb4ZTAFkwybSNnM_0>
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: Sun, 17 Apr 2016 16:35:20 -0000


> On Apr 15, 2016, at 11:09, John G. Scudder <jgs@juniper.net> wrote:
> 
> All,
> 
> Thanks to Geoff and Tom for pointing out that we do have definitions of what PS and Experimental mean. If those definitions are wrong (c.f. some of the comments relating to whether some designation does or doesn't advance some greater good or agenda) is not a question for SIDR to decide -- if you don't like the definitions, propose revisions to RFCs 7127 and/or 2026.
> 
> Based on the definitions provided in those two RFCs, BGPSEC fits into the PS bucket. If there is debate about whether it falls short of any of the RFC 7127 criteria for PS, the best time to have raised that would have been at WGLC but of course there's still IESG review and IETF LC, so there's ample time for anyone who wants to be heard. 

Not liking something very much is not a great basis for experimental status vs ps as opposed to yes vs not at this time.  IMHO when we look at BGPSec we've go to ascertain whether we can live with the consequences of various actors outside the IETF participants deciding it's cooked enough to deploy, use, require and so on. 

From my vantage point it's about time, not because we're done, but the documents are not going to get much more cooked, we've accumulated significant infrastructure around it, and the marketplace needs to have as say on deployment and this is how we signal that.

> $0.02 from this individual WG member,
> 
> --John
> 
>> On Apr 13, 2016, at 2:17 PM, 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 believe standards track is the right approach here. This document has been
>> viewed as standards track since we began work on it long ago. It is the successor
>> to the origin validation standards, addressing the residual vulnerabilities that
>> persist based on that use of the RPKI. From the perspective of promoting adoption
>> it is critical that this remain a standards track document; router vendors will
>> be unlikely to devote resources to design and implementation if BGPsec is labeled
>> experimental. I agree that this is new technology, but I heard that we already have
>> a  couple of implementations already, and we may discourage others from continuing to
>> work on BGPSec implementations if we downgrade the status of the RFC. The design has
>> evolved to accommodate real-world routing deployment topics such as the role of IXPs
>> and AS migration. In my long experience in the IETF experience, the level of attention
>> to these an analogous details makes BGPsec a very solid candidate for standards track
>> publication.
>> 
>> Steve
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>