Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.

Warren Kumari <warren@kumari.net> Wed, 03 July 2019 22:32 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04FA1200D7 for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 15:32:31 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-net.20150623.gappssmtp.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 pysDuvY5Ns1q for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 15:32:28 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 8E419120096 for <ietf@ietf.org>; Wed, 3 Jul 2019 15:32:28 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id r21so3886069qke.2 for <ietf@ietf.org>; Wed, 03 Jul 2019 15:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dg0ZDEVpN+LlNSi6yzaQKqbH+vVpCuMKIyDUXnzEw4w=; b=axf6zECCxd6A7b8bTbMXAGWI2U/hydxhEqMXo9cD/tQbapo9fZSaj/aNHpwg0mjQ9e fEB6qZF6ezAHJuwbxtfQhACyadndrM/A++Fv2YFNdjzfomgxIlOArxMzyhmYR4pGt0dd rEjmKudOJygvsq2/MWo7gZ42W+RWeXi6eASxoMqpRYSPJTt2GBk7Leo+FHDVMy7r13Db 49JsB+mwSMrGQ3ZiONUTPEuAKLLJsERzMl4n6WsduJa0p3olocPOoNydDuB2cGmbWcEG feEWrZGodAGbHaJnBWOEYoQugf7PjgccMcjjcSLnR9UJom4088wYD8C+Ke74AoHk7hjF zLNg==
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=dg0ZDEVpN+LlNSi6yzaQKqbH+vVpCuMKIyDUXnzEw4w=; b=QJAYahsloxv/3S1STwQgjPZUwAa6HRIhCTk7j+IwbFo20xViBRykUfmmo5+EetyByg DpfpGrub8o0E1saJ2micatJUsGIF3UZaBL0msW4i2p/YScG0eQ9Xil0U4gIS6lKaETF/ d1u40TkCOTgyAkmlOyWljLzxNQjaKJnP36dzQ8PgRcAaUTQ5LvkZYwBVjBRTfvkN5AQl sedw2vB66GMxXtaNGPApH/jEZ9oMEGp9122yrDleNWrVDyXbXNFFT7Hj6uBtiy/FnpKA 0JZip59bAVxeUk4edExqoC279xA/+UK0vfqNVgOTDdVWArIB1THLnIcHiQ5zYGGNThK4 YUbA==
X-Gm-Message-State: APjAAAUMIoV+2SYfQ3QWJ10azx5VIZitIAbeMPOPRyM2mXlHaNpAP/+m uWz4ySt2KxcuatRMITxUpIrXpCb73qsWTT+Hh9yNjquQ4r0=
X-Google-Smtp-Source: APXvYqx5Jh5RsxRdg5KHw4l/dctOsLQxvh5H7dYzCmmzrC4RasyQ46HGswy8xKycTLbRfdtrgP1CxYvoN8KLtXWqzyI=
X-Received: by 2002:a05:620a:1661:: with SMTP id d1mr33140538qko.192.1562193147275; Wed, 03 Jul 2019 15:32:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKv7xDY-rT98F_BAEvGOGbWGL7UpXS42rSVLsHB+=SOZg@mail.gmail.com> <4567879e-aa29-aeae-72e9-33d148d30eed@network-heretics.com> <CAL02cgToQWmOrfOxS_dc4KRtT9e0PXNzmhWZHkRUyV_3V=E-mQ@mail.gmail.com> <0856af71-4d84-09d1-834d-12ac7252420c@network-heretics.com> <CAL02cgQ9qWVUTPW=Cpx=r32k3i1PLgfp5ax0pKMdH0nKObcKTg@mail.gmail.com> <e8d28a7f-128d-e8d0-17d3-146c6ff5b546@joelhalpern.com> <7A61E9CE-370F-4C09-A79D-0206B8467AD9@sobco.com>
In-Reply-To: <7A61E9CE-370F-4C09-A79D-0206B8467AD9@sobco.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 03 Jul 2019 15:32:16 -0700
Message-ID: <CAHw9_i+V5xVzQNhYV_Tt-J4Z2S_x5VARbg1naJToLqxS1qXnZA@mail.gmail.com>
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.
To: "Scott O. Bradner" <sob@sobco.com>
Cc: IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d40c0058cce6f5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/y1FBIjK50FF2H5gvrehx0KwroMw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 22:32:32 -0000

On Wed, Jul 3, 2019 at 1:38 PM Scott O. Bradner <sob@sobco.com> wrote:

> see “stable snapshot” in
> https://tools.ietf.org/html/draft-bradner-ietf-stds-trk-01
>

Ah, nice, thanks. There are some definite parallels with this. What we were
proposing is similar, but less “strong” - it doesn’t have anything like
IETF / IESG consensus, rather just “this is what the *WG* currently thinks”.

W



> Scott
>
> > On Jul 3, 2019, at 4:34 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> >
> > Let me phrase it differently, with a similar point to Keith's
> >
> > An IETF working group can say "we think this has the right content, but
> we are not yet handing it to the AD because ..."
> > That is a form of stability
> > It is NOT a promise not to change the content before RFC publication.
> > As an example, I as co-chair thought the NSH spec was very stable, and
> then a technical issue was raised that required an incompatible change. It
> was still a working group document.  We made the change.
> >
> > Further, a working group can not label a draft in a way that suggests
> that there is IETF consensus in support of the document.  That is not its
> purview.  And is believe the implication that Keith is concerned about.
> >
> > I do not expect that either Heather or Warren were looking at the later
> interpretation.  But I can see how someone reading the email could
> reasonably be concerned about such over-ambition.
> > And your response that working groups can publish whatever they want is
> at best misleading.  It is true that the content of I-Ds is up to the
> working group.  The labeling of them is NOT up to the working group.
> > (We do, consciously, deliberately, and to significant advantage, make
> all our works-in-progress visible to the world.  They are labelled as such.)
> >
> > Yours,
> > Joel
> >
> > PS: I am not sure what the general benefit of marking an I-D as 'stable"
> would be.  We still would not want it normatively cited.  I tried to
> construct the most positive such label in teh example above.  I may or may
> not have time to join the side-meeting.
> >
> > On 7/3/19 4:23 PM, Richard Barnes wrote:
> >> On Wed, Jul 3, 2019 at 4:18 PM Keith Moore <moore@network-heretics.com
> <mailto:moore@network-heretics.com>> wrote:
> >>    On 7/3/19 4:15 PM, Richard Barnes wrote:
> >>>
> >>>    On Wed, Jul 3, 2019 at 4:10 PM Keith Moore
> >>>    <moore@network-heretics.com <mailto:moore@network-heretics.com>>
> >>>    wrote:
> >>>
> >>>        On 7/3/19 4:04 PM, Warren Kumari wrote:
> >>>
> >>>        > Hi there all,
> >>>        >
> >>>        > TL;DR: Being able to mark a specific version of an *Internet
> >>>        Draft* as
> >>>        > “stable” would often be useful. By encoding information in
> >>>        the name
> >>>        > (stable-foo-bar-00) we can do this.
> >>>        >
> >>>        > Heather and I will be holding a side meeting at IETF 105 to
> >>>        discuss
> >>>        > the idea and get feedback.
> >>>        > When: Tue, July 23, 3:00pm – 4:30pm
> >>>        > Where: C2 (21st Floor)
> >>>
> >>>        It seems to me that this would defeat the entire purpose of
> >>>        Internet-Drafts and serve to circumvent the IETF process. There
> >>>        should be no expectation of stability until a document has
> >>>        reached
> >>>        IETF-wide consensus.
> >>>
> >>>
> >>>    Why is it necessary to conjoin those two things?
> >>    Because a working group does not have the authority to make such
> >>    decisions on its own.   To the extent that it would be desirable to
> >>    invest such authority in some body for some specific purpose, a
> >>    working group is the wrong kind of body to do that.   The norms
> >>    around IETF WG operation aren't the right ones for such a body.
> >> Doesn't have the authority to publish stable specifications?
> Obviously, a WG can't publish something and claim it has consensus or is an
> RFC.  But WGs already have the ability to publish stable docs, by
> publishing them on github or on IPFS.  This is just about making them
> easier to find and reference.
> >> I think maybe you're over-inflating the significance of this proposal.
> >> --Richard
> >
>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf