+1 to Roque's point. Definitely standards track. Thanks, Sharon
On Tue, Apr 19, 2016 at 6:31 PM, Roque Gagliano (rogaglia) < [email protected]> 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 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 > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
