... and another +1. W On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels <[email protected]> wrote:
> > > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <[email protected]> > 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" < > [email protected] > > on behalf of [email protected]> wrote: > > > >> > >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <[email protected]> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > > sidr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
