Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)

Joel Jaeggli <joelja@bogus.com> Wed, 09 December 2020 23:12 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5D73A0045 for <sidrops@ietfa.amsl.com>; Wed, 9 Dec 2020 15:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQMRhNqKQHeO for <sidrops@ietfa.amsl.com>; Wed, 9 Dec 2020 15:11:58 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2513A003E for <sidrops@ietf.org>; Wed, 9 Dec 2020 15:11:58 -0800 (PST)
Received: from jmbp.local ([73.63.242.69]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id 0B9NBu7q096582; Wed, 9 Dec 2020 23:11:56 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [73.63.242.69] claimed to be jmbp.local
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: Job Snijders <job@ntt.net>, sidrops@ietf.org
References: <X8+NbXjEfH7Balvq@bench.sobornost.net> <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl>
From: Joel Jaeggli <joelja@bogus.com>
Message-ID: <430ac11d-c2ce-0035-34f1-7a3a951f0ae6@bogus.com>
Date: Wed, 9 Dec 2020 15:11:45 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/XlnKOU1NGNPlZZDJ25f_Ro2loDQ>
Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 23:12:00 -0000

On 12/9/20 05:24, Tim Bruijnzeels wrote:


<snip>

...

>> In the current charter sidrops does not intend to produce standards track documents, with IETF and working group consensus being output as BCPs when the weight of demonstrating consensus is required. 
>>
>>  That is a challenge in the case of for example
>>
>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/
>>
>> And one that should probably be more explicitly included if we are amending the charter. If we take on the protocol specification maintenance here there absolutely we should require interoperable implementation for standards advancement.
>>
>> requirements text around interoperability testing is good, but it needs be expanded a little to let us do the protocol maintenance, which we generally would have ascribed to IDR under the original charter.
>>
>> I hope the current AD will revist this.
>
> I believe that it would be good to extend the sidrops charter to allow it to produce standard tracks documents *and* require two implementations for that track.
>
> While in case of ASPA one could still argue that this could also be discussed in IDR (or perhaps just be discussed there as well), I think there is other work here that is not suitable for IDR. It may not be routing related (see the RTA document for which adoption was requested), or talk about the RPKI infrastructure itself (mft-bis / deprecate-rsync / ..future work).

I tend to agree, charters are meant to be amended when taking on new work.

>
> Tim
>