Re: [arch-d] Program issues

Bernard Aboba <bernard.aboba@gmail.com> Sun, 15 November 2020 22:06 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1AB3A0E96; Sun, 15 Nov 2020 14:06:13 -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, HTML_MESSAGE=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 ZsKoyO2-HtUW; Sun, 15 Nov 2020 14:06:10 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 20D033A0E94; Sun, 15 Nov 2020 14:06:10 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id i17so16840000ljd.3; Sun, 15 Nov 2020 14:06:09 -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=H5Z7p8RbBSv6vN/AMJ5MIwlEwlpuyTK/721W6/3wMew=; b=VRNqyidJbY0q5dYaPcRgqPGeCWwN8aC39nCGFYPgu8QA2hEjOJMyO326OKjhhjxfe4 TT8TqiiP8Z83XzeytfsuLAiMZYccGb+8XMhQIQ4Z3RygkJ4AmXdzjb5OTP1uMIp8ijPM 3Gk9OTzSQT1P+1fkWvW0dKqlykey2NESPbNIhqq1x0czaTd1ZhJ8MoClwYu1VMIpIVGj KaVs1UMYePSIEVniuSKAKf6kzJH6ZyE8pQ0HU6eKmoUR5zPXmU42KpuFcfmGEPZsvgog D6+RTflNOqGmWsZgrJOKr+FIKc0Bbzkbi74VW0ztFMRhVzqxlhy/dnSruZIbqRNUEVBe N6Vw==
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=H5Z7p8RbBSv6vN/AMJ5MIwlEwlpuyTK/721W6/3wMew=; b=AA8p2VMQqWltP/5/1k+9wrnZq/qt4xFxqnXo2hPGxJjeQLt1eBEkP+zG3bNdYcs9iU G9FNt9PskIg434IoJ2cJGcRfcI6GU+7+klZiYO9zx62UEGHGyRoLRtSPlWUc4fQ73exH QAKPrMZsr6P+7M839b2JRtV+ZYWMlWXgHpkevuV6roayaXYV2T7+xG4z2Mvu5m25ZRkW FOcOsPN3Cvhi/HGEwJtjfnNlI8Tz2ucKabTSJN43DiUAQ2usm1QIlCuRFCmEFwm0BxwV Uki+W5Sr+KC+Yl1TuBnPUzEF4RZnELpJSNAqqaSwPNYkgCN9NRc3ZBVjXuYnuGjBXC3b M7nA==
X-Gm-Message-State: AOAM530NmQx/+l+dSDfCcZQxqSwgkilgZYiUfVhcPVhPmruKsv1cYPPl k78GcKyL/cQ0whyoIwX6gmb8fZpBXlgslxf59GY=
X-Google-Smtp-Source: ABdhPJzMX+SHKR+AdSle+Lv7VC7+IdHxLnQLhNqvsGKtq0N0VEx1xvc29b2jN/mFlwk5dat+b4MeHgpxdFF0bof9ngQ=
X-Received: by 2002:a2e:b70d:: with SMTP id j13mr5395430ljo.240.1605477967904; Sun, 15 Nov 2020 14:06:07 -0800 (PST)
MIME-Version: 1.0
References: <1B3F8503-7346-4CBC-8553-140E280ECCA3@iab.org> <6.2.5.6.2.20201115050800.0b08eb08@elandnews.com> <891AEA3010444F9099444E76@PSB> <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com>
In-Reply-To: <0a73975a-eea8-a356-aec4-6fe04a4f3816@gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 15 Nov 2020 14:05:58 -0800
Message-ID: <CAOW+2dvDch6q_RQZ-EosAMzF3j90vPYtveaUeNpWmjwc5UmRdg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: John C Klensin <john-ietf@jck.com>, S Moonesamy <sm+ietf@elandsys.com>, IAB Chair <iab-chair@iab.org>, architecture-discuss@iab.org
Content-Type: multipart/alternative; boundary="000000000000f8c30305b42c77af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/ZfUf2OFvqi6448OlpnfKd6t0aKs>
Subject: Re: [arch-d] Program issues
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2020 22:06:13 -0000

Brian said:

"As for admin tasks, I would always prefer that the IAB minimises that part
of its efforts."

[BA] In practice, the administrative programs have not worked well. The
RSOC is perhaps the most prominent example, but by no means the only one.

IMHO, the problem is not with the Program Model, but with the IAB itself.
With technical programs, post-Kobe there are checks and balances, so that
the IAB merely has the "power of the pulpit" - the ability to attempt to
convince the IETF community to move in a particular direction.

But with administrative programs, those checks and balances are often not
present.  This is because in some areas (such as RSOC and IANA), the IAB is
to represent interests beyond those of the IETF.  While that is good in
theory, those non-IETF interests are not well defined, nor do they in
practice have the ability to provide a check on IAB actions. Even if a way
could be found to represent those interests within an IAB program (for
example through appointment of non-IAB members), only IAB members have
voting rights.

Given these inherent problems, I would agree that the IAB needs to minimize
that part of its efforts.  The best way to ensure that this happens is for
the IAB's administrative programs to be examined one by one, with an eye to
removing them from the IAB's charter.

On Sun, Nov 15, 2020 at 1:10 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> fwiw, I think that the separation of technical programs from
> administrative tasks is a great step forward, and overcomes
> the slight discomfort I've always had about the IAB program
> concept.
>
> I think we can regard an IAB technical program as rather like
> an IAB workshop that goes on for several years, with the same
> properties: it's invitational, it has no authority, and it
> is supposed to report back to the community with some
> interesting information and suggestions. As John says, it
> also has the virtue of surviving changes in IAB membership.
>
> I don't think it changes accountability at all. The IAB
> remains accountable for its formal decisions, statements
> and publications.
>
> As for admin tasks, I would always prefer that the IAB minimises
> that part of its efforts.
>
> Regards
>    Brian Carpenter
>
> On 16-Nov-20 09:29, John C Klensin wrote:
> > Hi.
> > I trust you figured out by now that the notice of the report
> > contained the wrong link, presumably through the use of a
> > template that was not updated.  These things happen although why
> > no one on the IAB spotted it might be an interesting question.
> > The correct link, posted by Ole a couple of days ago, is
> >
> >
> https://www.ietf.org/proceedings/109/slides/slides-109-ietf-sessa-iab-report-to-the-community-for-ietf-109-00
> >
> > However, one additional comment, prompted by your note, below...
> >
> > --On Sunday, November 15, 2020 06:12 -0800 S Moonesamy
> > <sm+ietf@elandsys.com> wrote:
> >
> >> The concept of "program" creates opaque accountability.  Has
> >> the IAB considered that?
> >
> > I have the dubious distinction of having written the first
> > proposal for what evolved into the Program model.  That proposal
> > was far more radical than there was any chance of the community
> > accepting and probably just a bad idea, but both it, and the
> > version the IAB adopted and put into use around 2011, were
> > intended to respond to one key problem.  The problem was that,
> > as the issues facing the Internet became more diverse and many
> > of the participants in the IETF became more specialized in their
> > skills and interests, the IAB could decide some effort was
> > important and start work on it but then, as membership rotated,
> > discover that it no longer had the expertise to effectively
> > pursue that topic.  That had happened in the past; it was not
> > just a hypothetical problem.  Asking the Nomcom to select people
> > for expertise on one particular subject didn't work well either
> > -- there were a few cases in which someone was selected on that
> > basis who didn't want, or wasn't able, to contribute to the
> > IAB's other work.
> >
> > So the idea was that, if the IAB felt that some topic was
> > important to pursue but didn't have the expertise to do so
> > internally, it could find relevant (and expert) people in the
> > community, pass the responsibility on to them, treat them as if
> > they were (non-voting) part of the IAB when that was important,
> > and arrange for reporting as needed.  It was not a requirement
> > that the IAB have more involvement than general oversight; if
> > several IAB members were actively interested in the topic and
> > considered themselves either expert or willing to learn, there
> > was no real need for a Program (even if the model might prove
> > useful organizationally).  By contrast, if IAB members became
> > part of a particular Program, the assumption was that they would
> > have no status except based on their expertise, i.e., that IAB
> > members would be no "more equal" than anyone else.
> >
> > Finally, because the idea was shaped around Programs doing
> > technical/ architectural work, accountability didn't change: the
> > IAB should be judged on the basis of its technical and
> > architectural work; especially good(or bad) work should be
> > brought to the attention of the Nomcom; and the ultimate
> > evaluation of quality would be adoption of ideas and topics by
> > the IETF or the broader community.   Just as with workshops, a
> > report that was generally ignored and had no impact should be
> > taken as reflecting badly on the whole IAB with the Nomcom
> > having the unenviable job of figuring out who to blame.
> > Implicitly, if a Program failed, the necessary assumption would
> > be that either the IAB had not found the right people or had not
> > defined the topic appropriately.  In either case, I think there
> > was an assumption that the community was owed a more detailed
> > explanation than "shutting that one down" [1].
> >
> > Because the RSOC had (or was perceived as having) administrative
> > and management responsibilities rather than technical ones, it
> > was never a good match for the Program model (at least as
> > originally conceived).  The accountability problems there were,
> > IMO, just one issue (or symptom) of the mismatch.
> >
> > After almost ten years, the Program model has evolved
> > significantly from the original conception.  If that evolution
> > has taken us to the point where accountability is a large issue
> > --or to where they Program needs "refactoring"-- I wish the IAB
> > would address the question of whether, while it seemed like a
> > good idea at the time, it just didn't work out and the whole
> > idea should be dropped rather than assuming that surrounding it
> > with more process and rules would improve things.
> >
> >     john
> >
> > [1] Same observation about workshops that never lead to reports,
> > even if the report is only an explanation of why no conclusion
> > or recommendations are possible.
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>