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! -chris co-chair On Mon, Apr 25, 2016 at 10:53 AM, Warren Kumari <war...@kumari.net> wrote: > ... and another +1. > W > > > On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels <t...@ripe.net> wrote: > >> >> > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <rogag...@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-boun...@ietf.org >> > on behalf of g...@apnic.net> wrote: >> > >> >> >> >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <k...@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 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
