[Asdf] on ASDF cycling at internet-draft

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 19 August 2020 13:18 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: asdf@ietfa.amsl.com
Delivered-To: asdf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41293A09B3 for <asdf@ietfa.amsl.com>; Wed, 19 Aug 2020 06:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 XcFiB8UX7_r5 for <asdf@ietfa.amsl.com>; Wed, 19 Aug 2020 06:18:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289013A09AD for <asdf@ietf.org>; Wed, 19 Aug 2020 06:18:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C144D38A02; Wed, 19 Aug 2020 08:57:20 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qZwT3-iWR4o3; Wed, 19 Aug 2020 08:57:19 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9247B38A01; Wed, 19 Aug 2020 08:57:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4144E7B; Wed, 19 Aug 2020 09:18:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: asdf@ietf.org, Barry Leiba <barryleiba@computer.org>
In-Reply-To: <C5ADCAAD-A2DE-47EB-87AA-D5D946E606AA@tzi.org>
References: <5C210025-34B4-45BC-9A1D-66D9E92B339A@tzi.org> <31064.1596838037@localhost> <C5ADCAAD-A2DE-47EB-87AA-D5D946E606AA@tzi.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 19 Aug 2020 09:18:11 -0400
Message-ID: <11386.1597843091@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/asdf/BE5Ir_46-GPXvPHQEOWK1n12fvU>
Subject: [Asdf] on ASDF cycling at internet-draft
X-BeenThere: asdf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" <asdf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/asdf>, <mailto:asdf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/asdf/>
List-Post: <mailto:asdf@ietf.org>
List-Help: <mailto:asdf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/asdf>, <mailto:asdf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2020 13:18:16 -0000

Barry, I'm uncomfortable with a plan to have more than implementation draft
as a WIP.   While it seems that this where the IETF has evolved to, I'm
really not sure that planning it this way is in the right spirit.

I would significantly prefer to iterate at PS, but the hurdles seem higher
than ever.  I'd love to be wrong!
Maybe someone has some 3933 process experiment ideas that could be done.

Carsten Bormann <cabo@tzi.org> wrote:
    >> 1) What would you call a "release" here?

    > An Internet-Draft that is specifically marked as such (often called
    > “implementation draft” in other groups).

    > The intention would be to reach a periodic milestone where OneDM people
    > and ASDF agree that a specific I-D is useful as a basis for further
    > OneDM work, e.g., by using that I-D for validating models in the OneDM
    > playground and convergence processes, and by ecosystem tool builders
    > modifying their tools to target that I-D in their conversion processes
    > (which is what enables breaking changes).

    > This could be done in a tick-tock style, with a feature I-D and then a
    > period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so
    > on.

...
    >> Should publishing 1.0 ASAP be a goal, or should we just do 1.1?

    > 1.0 was “published” as an Internet-Draft.  I don’t think we should aim
    > for RFC status until we have at least a handful of SDOs that have put
    > the majority of their relevant models through the process.  1.0 is
    > intended to be quickly superseded by 1.1, and that might happen a
    > couple more times until returns start to diminish.

    > This rapid iterative process may be a bit unusual for IETF.
    > I’d assume we can stabilize the SDF core at 1.3 or 1.4 enough to go for RFC.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-