Re: [sidr] BGPSec RFC status

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 <warren@kumari.net> wrote:

> ... and another +1.
> W
>
>
> On Wed, Apr 20, 2016 at 4:07 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
>>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>