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

Christopher Morrow <christopher.morrow@gmail.com> Wed, 10 March 2021 03:34 UTC

Return-Path: <christopher.morrow@gmail.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 0310F3A1926 for <sidrops@ietfa.amsl.com>; Tue, 9 Mar 2021 19:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GwRpigI6J-96 for <sidrops@ietfa.amsl.com>; Tue, 9 Mar 2021 19:34:08 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3B03A1924 for <sidrops@ietf.org>; Tue, 9 Mar 2021 19:34:08 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id b130so15471711qkc.10 for <sidrops@ietf.org>; Tue, 09 Mar 2021 19:34:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iUiJ3xmHrX6DVmKnd1W58VX9oTGqvtlx539A3MU6FgY=; b=ocbe0S2t5Ed2+qOYTwSETk3vH48nKQKCbp9Y0tZxcTvASlWxc9p+DWZv5EnD6UWf8g 55WbMr60jwgta5Iu9a5QN7R1HQVCWVjeUIqOOsHmRNvsuZLHGXkweApHW+IIs0U5VDn4 Oa2NIf0kruKrEpnmnactAirK3SyA8e1SUpaLsmDlXITY96sEArAZHrfOVDo+4OnnJBz/ x7GrOYjAghI95HB7h0lHGMjakm0jDoD1Y/yOP93Qv91W4DVV1LAmlbJAPKoaQAMAzmMI JhlZNYEqON2vIV5c0LD6SDO/JqkvnK+cz9VqXV8JAp7dkvpLkQAWJ8dJBHj6bcoP/lKc eaWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iUiJ3xmHrX6DVmKnd1W58VX9oTGqvtlx539A3MU6FgY=; b=RAEGi8aOGnpLT+U1007DNT5V+5EqTL9cI/b0TLOGXPt/6be9ee6MWvIrT4wEf3x4F6 tAMRpgPGkP+vr//WI721Bdm/Jbw58hCNA3cBZoKoCwcQY+pNIi0dOR6gl7+TZIMtW/au qi3M6jRfYX+HUWEDBTa2igwD3kfUYMGbX47lETyP3EMTYPKrdLSAsnU7TElNdR9nuGnO XMe1gdCeZWeJdEXnzkPVQQCgOBqXFY47WzzAERqtaxhBctYxWH4QJ/mG3r7wJNocx1Dk YwhHmL9km1/ALPnmZsMsD5eVw7OMiUK0jXtRChcNwZaL+VrfEUIc5gmATQva5ghBH7tF WAtg==
X-Gm-Message-State: AOAM5309wZu8oqhtd4NJrfzgIwc+UMrxYci3qdppjsCLjDWSJPIo1fN0 hVkwbNyzaYR/rTZum3aDMmRmxzxO5TFJw9phjcGbBhUq5Eg=
X-Google-Smtp-Source: ABdhPJwf+n2drrq1coNS1vK0XVrj7Qx6w+7PSt6tOEdB1LjZvwrA/nzx8AMsT0hnzIIvWjgwu7yaZTy3QeBxd+A/iYE=
X-Received: by 2002:ae9:eb4d:: with SMTP id b74mr897098qkg.45.1615347246453; Tue, 09 Mar 2021 19:34:06 -0800 (PST)
MIME-Version: 1.0
References: <X8+NbXjEfH7Balvq@bench.sobornost.net> <CAKr6gn09vm9e++cyAw-m1W8LgU4Y=jNC4ouDcBBrK_1obZQP5w@mail.gmail.com>
In-Reply-To: <CAKr6gn09vm9e++cyAw-m1W8LgU4Y=jNC4ouDcBBrK_1obZQP5w@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Tue, 9 Mar 2021 22:33:55 -0500
Message-ID: <CAL9jLaayncgCdMYrEeUgbzsOJ8akUP5vhcjyk2vQnCe930rsJw@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
Cc: Job Snijders <job@ntt.net>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/p2Nm9K0M6JLqjNghgD5ktbVC3VY>
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, 10 Mar 2021 03:34:10 -0000

Hey there, before we get to the meeting time in the morning....

I think some chat about the charter change SHOULD happen at the end of
the meeting period tomorrow (time permitting).
I think there's a decent call for :"Hey, can we get some working code
/ 2x implementations before we move to IESG finality on a document?"
   (I presume that would apply where changes to code and protocol and
ops would dictate code/ implementations.. this seems obvious, but :) )

I think these things sound good to me (need implementations before we
release the kraken(s) ).
I think one good outcome of this form of change SHOULD be that we get
some more operational experience with how the changes being proposed
will:
  1) work in the ecosystem as it stands
  2) make the system more operable
  3) bring to light corner cases which we didn't envision when we
wrote documents/etc :)
  4) permit us to gain experience and better fight off the whalers in
the IESG when they have their inevitable quibbles with our world
view(s). :)

On Wed, Dec 16, 2020 at 6:46 AM George Michaelson <ggm@algebras.org> wrote:
>
> On Wed, Dec 9, 2020 at 12:28 AM Job Snijders <job@ntt.net> 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.
> >
> > IDR participants track implementation reports & interopability testing
> > through internet-drafts or their Wiki
> > https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports
> >
> > Here are some examples of what reports can look like:
> >
> >     https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis
> >     https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations
> >     https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
> >
> > 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.
> > """
> >
> > Kind regards,
> >
> > Job
> >
>
> I think this would be sensible. From a CA, producer-side point of
> view, I think having confidence of interop demonstrated, and having
> this in both producer and consumer (signer and validator)  would be
> net beneficial.
>
> cheers
>
> -george
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops