Re: [sidr] BGPSec RFC status

+1 to Roque's point. Definitely standards track. Thanks, Sharon On Tue, Apr 19, 2016 at 6:31 PM, Roque Gagliano (rogaglia) < rogag...@cisco.com> wrote: > +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

Re: [sidr] BGPSec RFC status

​ howdy, it's past 4/29/2016 || 29/4/2016 || Mar 29 2016... and from the discussion on-list and mostly in the room in EZE, it appears: "Please maintain Proposed Standard as the track for SIDR work." i think this closes out the discussion. thanks for deliberating and discussing this topic!

Re: [sidr] BGPSec RFC status

... and another +1. W On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels wrote: > > > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) > wrote: > > > > +1 with Standard Track. > > +1 > > > > > The question could have been relevant six years ago and we may not

Re: [sidr] BGPSec RFC status

There's been some good discussion on this, i think we (chairs) didn't expect the list to jump on this without some prompting... but it's nice to see :) So, in service of 'coming to a decision' I think we should debate/discuss for another bit, and close discussion Fri 4/29/2016 - April 29th 2016.

Re: [sidr] BGPSec RFC status

> On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) > 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

Re: [sidr] BGPSec RFC status

+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

Re: [sidr] BGPSec RFC status

> On Apr 15, 2016, at 11:09, John G. Scudder 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

Re: [sidr] BGPSec RFC status

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

Re: [sidr] BGPSec RFC status

- Original Message - From: "Geoff Huston" To: "sidr" Sent: Thursday, April 14, 2016 9:20 PM > > On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: > > I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR session, at > >

Re: [sidr] BGPSec RFC status

At Fri, 15 Apr 2016 00:18:00 -0300, Christopher Morrow wrote: > > I don't know exactly either, but this from 2026: > > " A Proposed Standard specification is generally stable, has resolved >known design choices, is believed to be well-understood, has received >significant community

Re: [sidr] BGPSec RFC status

On Thu, Apr 14, 2016 at 10:05 PM, Russ White <7ri...@gmail.com> wrote: > > > snmp, netconf, yang, ... heck even cops played in the space > > > > when your so-bgp, 15 years in the non-making, is mature as a document > set, > > with two or more implementations, i'll support it for standards track,

Re: [sidr] BGPSec RFC status

> snmp, netconf, yang, ... heck even cops played in the space > > when your so-bgp, 15 years in the non-making, is mature as a document set, > with two or more implementations, i'll support it for standards track, no > problem. i am not desperate enough to sabatoge the work of others to > move

Re: [sidr] BGPSec RFC status

snmp, netconf, yang, ... heck even cops played in the space when your so-bgp, 15 years in the non-making, is mature as a document set, with two or more implementations, i'll support it for standards track, no problem. i am not desperate enough to sabatoge the work of others to move my work

Re: [sidr] BGPSec RFC status

I wanted to address a point that's been brought up a number of times in this thread -- the contention "if we don't go standards track, people aren't going to be motivated to deploy this." There is an opposite argument to be made in this line of logic -- "if we do go standards track, there will

Re: [sidr] BGPSec RFC status

> On 14 Apr 2016, at 4:17 AM, Stephen Kent 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

Re: [sidr] BGPSec RFC status

I think BGPsec should be Standards Track. ISPs and router vendors won’t take BGPsec seriously if it is published as an Experimental RFC. We came a long way here from S-BGP and so much time and so many efforts by many have been spent on BGPsec. The community need some real experience. Di

[sidr] BGPSec RFC status

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