Re: [Mops] Confirming adoption consensus Re: draft-ietf-mops-streaming-opcons

Kyle Rose <krose@krose.org> Wed, 05 February 2020 15:40 UTC

Return-Path: <krose@krose.org>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584BA12010F for <mops@ietfa.amsl.com>; Wed, 5 Feb 2020 07:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 BSLL_XJ-FFeG for <mops@ietfa.amsl.com>; Wed, 5 Feb 2020 07:40:40 -0800 (PST)
Received: from mail-yw1-xc43.google.com (mail-yw1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (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 6E004120052 for <mops@ietf.org>; Wed, 5 Feb 2020 07:40:40 -0800 (PST)
Received: by mail-yw1-xc43.google.com with SMTP id f204so2688172ywc.10 for <mops@ietf.org>; Wed, 05 Feb 2020 07:40:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T8WVUd8cX2xWV9SSMz2oVYIH9Opi1e7+2DzOBN5oZ/M=; b=JthsXI1aAlvb2XuHELmiaqhLJ5Qqp/AVxGSgqmldQZSgqkJimw44aLcGNU4Csv3PKQ Qj0pjeEWlGEeDyLTx9XneoeUd+juzqyCyfVu9rIIQDxlIppawqslOMv/Dys49jEelUUK w+A5TLnb42RQZIyf6G8nq6KL2vBj54ZVP3rV8=
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=T8WVUd8cX2xWV9SSMz2oVYIH9Opi1e7+2DzOBN5oZ/M=; b=E9TB2xCYCCKa4aH957dE+1KprcN+gMAPNatITjrq12MZhreChftAnrumVSJd0Uo6uA 7evn9ooLKTM9bfb5yhts8RSWT1eQtFi6NuxbmZZWyA3zslWaxRl0P6yzH0XIpP9Y9qaC 6St2eBuPKemgINS46zt+T41BvIRMmoXeO1HeUK3rRzdvWmy3Pyj8BhSeTasa9PMkHmQB 0G2uPfhF2W5tDAsTSITHsug/Ob5yDeVjPKERvfFjQEcPZhauwFoGIVFG7Fb2mKFLC8yg OkuTMVdJq2TC/OBBgCzEKtz/0Ol03DEu1Aw82mk2AKBw7uhcGORvICQO9Iy20aKOu2kq DfHQ==
X-Gm-Message-State: APjAAAWq9+hdY6IFiyMOcZqWD9V0sd9aX0TWwVrNWviRCpam4e6lKiTi PFdK7/0/R1VsUK7HBo6zvStinuFA6QGrpq0tXx3a+vEadNggyw==
X-Google-Smtp-Source: APXvYqz2bjeJy6eyrs4G5VXK+WqAS/sw2GB7Kgg8FdbSLiq9dFx1xMVAGXFcgPa25aljw6Ed2TWG4jjYcB8VU8HGUkg=
X-Received: by 2002:a81:50d6:: with SMTP id e205mr10358561ywb.208.1580917239340; Wed, 05 Feb 2020 07:40:39 -0800 (PST)
MIME-Version: 1.0
References: <C6919186-0074-450C-8E0B-02F09E28574F@thinkingcat.com> <CACq2X+=qUDAumGhBP7k9+WQTo6OrjcKWaOy74ssHrPGRgRAQGw@mail.gmail.com> <CAKKJt-f5sR6X9U7CCRn-uBKc6H5MJEaaRU+Pt-vTF2+MfkfJcA@mail.gmail.com> <B72C34B4-1032-4F08-B5F4-B7CEC3AB8D42@thinkingcat.com> <CAKKJt-e6BeToRFWvOEOVurPo1k4cghDnkDeS4LkTjhKP32Oa7Q@mail.gmail.com> <CAJU8_nUj9UJhqRpHoa7qCxmnesvGF0WavGT1KCigUJ8E4G2dbA@mail.gmail.com> <CAKKJt-e4N=qhBDqW=bLCv+vJx_JRjhobCSq=GZc5HUakHT+V+Q@mail.gmail.com> <84629438-89A5-4E41-A80D-0DEAA34394F9@thinkingcat.com> <CAKKJt-cAEdA-tCHGF06EujUB8FkQy-Hov0Rsyixuki6EuX1Ydw@mail.gmail.com> <B28F169B-0AF3-495B-8EA3-152A264A135E@thinkingcat.com>
In-Reply-To: <B28F169B-0AF3-495B-8EA3-152A264A135E@thinkingcat.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 05 Feb 2020 10:40:28 -0500
Message-ID: <CAJU8_nXhkbGAk7uOhVYua=gOG_atvGPZN2ceXJcZ=wnWJFD1Tg@mail.gmail.com>
To: Leslie Daigle <ldaigle@thinkingcat.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Matt Stock <mstock@llnw.com>, mops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007872fa059dd5fac7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/_LW9IOT1GuhZX8FdCK3Z1-6Y5pE>
Subject: Re: [Mops] Confirming adoption consensus Re: draft-ietf-mops-streaming-opcons
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2020 15:40:44 -0000

I think ownership might be covered, at least from a policy perspective, by
some text from the git draft (notwithstanding the weaselly use of the
passive voice):

   When an area director or working group chair makes a request to
   create a GitHub organization, the following process would be
   initiated:

   1.  Create a GitHub organization for the working group.

   2.  Name the organization as ietf-wg-<wgname>

   3.  Initialize the organization by designating the IETF Secretariat
       and the area directors in the working group's area as owners.  If
       the responsible AD for the working group is from another area,
       that AD will be an owner as well.

   4.  Initialize the organization with a team that has administrator
       access.  This team will consist of the working group chairs and
       working group secretary, if one exists.

   After the organization is created, the URL for the organization would
   be added to the working group's page in the Datatracker.

   Steps 3 and 4 above imply that the GitHub identities of the
   organization owners and administrators are known.  Recording GitHub
   identities in the Datatracker (see
   <https://trac.tools.ietf.org/tools/ietfdb/ticket/2548>) would
   facilitate this.  The person requesting the organization would need
   to be notified if the GitHub identities of any of the people meant to
   be owners or administrators were not available.

Maybe less inspiring is the wording from the following section, which uses
something very close to RFC 6919 "REALLY OUGHT TO" language:

   If a working group already has an organization, it would be useful to
   be able to make it have the same management as one would get with
   going through the steps in Section 2.1
<https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-05#section-2.1>.
That is, it would be good to
   be able to run steps 3 and 4 from Section 2.1
<https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-05#section-2.1>
so that the rest of the
   activities in this section such as personnel work the same for the
   organizations that were created on their own.

I'm inclined to go forward with creating a mops-wg organization on the
assumption that, at worst, we're in the same boat with other WGs using
GitHub, but maybe we should have a consensus call on whether participants
want to incorporate an official GitHub org into their workflows. Otherwise,
individual document teams are still free use unofficial GitHub repos for
revision control and manageability of collaboration, but we would probably
need to be more strict about conducting official work on the mailing list,
which could negate some of the advantages of using GitHub.

Kyle

On Tue, Feb 4, 2020 at 2:29 PM Leslie Daigle <ldaigle@thinkingcat.com>
wrote:

> Hi Spencer,
>
> On 4 Feb 2020, at 11:04, Spencer Dawkins at IETF wrote:
>
> Hi, Leslie,
>
> On Mon, Feb 3, 2020 at 10:40 PM Leslie Daigle <ldaigle@thinkingcat.com>
> wrote:
>
> Spencer,
>
> One thing I’ve been trying to find out is: how to tie a git repo to the
> IETF. Looking at the CELLAR example, it seems like one just makes the
> assertion that it is the WG git repo? And, it seems odd that there are no
> visible members, let alone owner, of the git repo?
>
> Apologies if I’m missing the obvious.
>
> I don't think you are.
>
> I believe the current state of play is described in
> https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-05,
> especially in Section 2.1 and following sections (note that this draft is
> in PUBREQ state, so it's probably mostly right, but hasn't even been
> through AD review yet). Some of the text is input to the tools team, but
> most (selecting organization names, etc.) isn't dependent on datatracker
> support.
>
> Yep, I had read through that.
>
> I believe you are correct that in Github, that's an assertion. In the
> datatracker, co-chairs can add the URL for the organization (I think you
> can just stick this on the working group page now, but apparently there's
> development underway that would allow the datatracker to know that URL is a
> GitHub repository).
>
> That’s a good point — it leaves it within the IETF’s purview to identify
> any “authentic” repo.
>
> I've only been watching CELLAR for a few weeks, so don't know the history
> on defined users, etc. - sorry!
>
> I hope that's helpful.
>
> I’m confident GitHub isn’t going away any time soon, but my general
> concern follows on from the IETF’s experience when everybody hosted their
> own WG mailing list (federated responsibility! No single point of failure!)
> and archives were lost when people got irritated with the IETF or companies
> went belly-up.
>
> I think it would be good if the IETF had a more persistent role in the
> administration of the git repos, if a group’s work is going to depend on it.
>
> As a co-chair of MOPS, I don’t want to get in the way of providing a tool
> that current participants actually want to use! But, I also want to make
> sure we use it in a way that is going to stand up to the test of time.
>
> Leslie.
>
<quote trimmed>