> 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
