Re: [arch-d] Program issues

[John C Klensin <[e-mail]>]

Brian,

Certainly if what the separation really means is to eliminate
the bundling of [technical] Programs with administrative and
oversight functions, I'd consider it a good idea... and much
more consistent with what Olaf, myself, and the general
consensus of the IAB a decade ago thought we were doing.  My
concern was that the IAB might be taking another step in the
direction of substituting more internal structure, specific
definitions, and categories for getting substantive work done
(and, yes, for accountability).

If this is really "hey, some of this stuff that we identified as
"Programs" really doesn't match the original intent and is
creating confusion, so we are going to stop calling them that",
why doesn't the IAB just do it?  To take the longest-lived one
as an example, the IAB didn't need to consult the community or
make a big deal out of starting to call its liaison oversight
responsibilities (which existed long before programs existed) a
"Program" and doesn't need to make a big deal out of ceasing to
use that terminology.  

The problem there, as I see it, is that the IAB is feeling much
less responsible and (coming back to Subramanian's
question/point) accountable for liaison relationships than I
believe was intended when RFC 2850 was written in 2000 (and
indeed, although less specific, in RFCs 1358 and 1601 much
earlier).  If calling those liaison responsibilities a "Program"
helped cause that change then, IMO, the terminology change was a
bad idea because I think the IAB is responsible for consulting
the community when it is going to drop a responsibility.  But,
again, the terminology isn't really the problem, the actions are.

Granted that I'm getting a bit paranoid about such things but,
when I read that proposal, I saw, not a simple adjustment of
terminology but a further step in which the IAB becomes less a
single (and jointly accountable) body and, instead, more like
the IESG where different members are assigned primary
responsibility for different topic areas and keep that
responsibility for long periods of time.   Unlike the IESG,
where the necessity to have consensus about Last Calls and
documents force some cross-checking of each other's work, that
could easily turn the IAB into a collection of fiefdoms, a
decision on which the community should clearly be consulted.  

And, while the above was written before Bernard's note arrived,
I (perhaps obviously) agree with his analysis and the conclusion
that it is probably time to start examining the IAB's
administrative and oversight responsibilities to determine
whether they are necessary at all.  If they are necessary,
whether the IAB is the right place to house them if they are and
how they can be carried out in a way that is most effective and
transparent and accountable to the community.

   john


   john


--On Monday, November 16, 2020 10:10 +1300 Brian E Carpenter
<[e-mail]> 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-s
>> essa-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
>> <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>