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

Joel Jaeggli <> Wed, 09 December 2020 04:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8483C3A0AB4 for <>; Tue, 8 Dec 2020 20:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p-CSAt_jELcs for <>; Tue, 8 Dec 2020 20:06:54 -0800 (PST)
Received: from ( [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 885413A0962 for <>; Tue, 8 Dec 2020 20:06:54 -0800 (PST)
Received: from jmbp.local ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 0B946rNc087500; Wed, 9 Dec 2020 04:06:53 GMT (envelope-from
X-Authentication-Warning: Host [] claimed to be jmbp.local
To: Job Snijders <>,
References: <>
From: Joel Jaeggli <>
Message-ID: <>
Date: Tue, 08 Dec 2020 20:06:47 -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: <>
Content-Type: multipart/alternative; boundary="------------C90C1512F36451871DFEDC4F"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2020 04:06:57 -0000

On 12/8/20 06:27, Job Snijders wrote:
> Dear all,
> I propose some following text detailing a requirement for multiple
> implementations to exist prior to RFC publication will be beneficial to
> the working group.
> Our neighbors at the IDR working group are known to have a similar
> requirement, which has dramatically improved the quality of that working
> group's specifications and subsequently the deployability of IDR
> technologies. I hope the same can be achieved in SIDROPS.

So, back when we proposed that the sidr work was mature enough to spin
up this working group to focus more on deploying it and less on what
should go into the base specification. we figured this would be an
involved and somewhat perilous transformation.

    This deployment must be properly handled to avoid the division of
    the Internet into separate networks. Sidrops is responsible for
    encouraging deployment of theSIDR technologies while ensuring as secure
    of a global routing system, as possible, during the transition.

To my mind this includes addressing the question of how we collectively
use it and consensus on how the moving parts are expected  to work. If
we don't have a consensus reality, then how am I to expect that my
network and yours will operate on the same information in similar ways.
Inter-domain routing really is one of those places where the consensus
reality had better be the market dominate one.

> IDR participants track implementation reports & interopability testing
> through internet-drafts or their Wiki
> Here are some examples of what reports can look like:
> Proposed text to add to the SIDROPS charter:
> """
>     Specifications produced by the SIDROPS working group are intended to
>     address a practical need where a standard specification can assist
>     both vendors and consumers of cryptographic PKIX products to be
>     assured that a standards conformant implementation will undertake
>     certain functions in a known manner, and that, as appropriate,
>     implementations of the standard specification from different vendors
>     will indeed interoperate in intended ways. The SIDROPS working group
>     requires interopability reports from at least two different
>     implementations of a proposed specification, prior to publication as
>     RFC.
> """

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

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.


> Kind regards,
> Job
> _______________________________________________
> Sidrops mailing list