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.

thanks!
-chris

On Wed, Apr 20, 2016 at 4:01 AM, Tim Bruijnzeels <tim@ripe.net> wrote:

>
> > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <rogaglia@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-bounces@ietf.org
> > on behalf of gih@apnic.net> wrote:
> >
> >>
> >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <kent@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
>