Re: [Iasa20] IASA 2.0 outcome properties

[Michael Richardson <[e-mail]>]

Alissa Cooper <[e-mail]> wrote:
    > Administration

    > 1. For each of the following functions, it should be clearly defined
    > and documented who is responsible for executing the functions and who
    > is responsible for overseeing those that do the execution. In cases
    > where execution or oversight are done by paid staff, contractors, ISOC,
    > or any paid entity, the mechanisms for obtaining community input and
    > involvement should be clearly defined and documented.

...

    > 2. Administration should have no influence over the technical decisions
    > of the IETF or over the technical contents of IETF work. (By
    > implication, suggestions for changes to standards development
    > processes, technical leadership, technical leadership appointments,
    > open participation, etc., are out of scope for this discussion.)

As written these distinctions are relatively clear.

There are some bits which I think are missing, and it relates to how we make
choices of tools, particularly communication tools.

**I think that we need to say something about dogfood**

I think that there are decisions which in other organizations would be
considered entirely administrative, which for the IETF are political.
(I say political in positive sense, and also more in the french sense of
involving policies.)

Some examples (my pet peeves) that I want to point to are:
     1) lock in to certain platforms via proprietary communication tools
        (somehow, my decade long screams about webex-windows are less
        seriously taken than when IE6-locked-in-users complain about JITSI...)
        Much of this is driven by an "in-kind" donation for which we have
        no SLA, and no support agreement.  How did that decision occur?
        I got a lot of push-back from a number of IESG members when I
        suggested they dogfood a webrtc solution.

     2) IPv6, DNSSEC, Javascript and anonymous access to the ietf.org web
        sites.  Thank god I never had to add ECN to that list.
     3) DMARC vs IETF mailing lists (4.5 year to get somewhere...)
     4) widespread abuse of text/plain to imply format=flowed in MLs.

My goal is not to rehash the above discussions (so please take them offlist),
just to put my point in context.  My goal here is to point out that in other
organizations these would be decisions made by "IT" management people who
report to CIOs or CFOs, and they would impose their decision upon the rest of
the workers (for good or bad).

Right now some of this decision making ability seems to rest in the IESG,
with implementation occuring via IAOC management of Secretariat and other
contractors.   I'm not clear that the IESG really has the bandwidth to deal
with these things in a timely fashion.

To the above list, I could add many other in-person meeting hassles from size
and frequency of cookies to temperature of meeting rooms.   Somehow, the
people writing the (hotel in this case) contracts need to be more visibly
accountable to the community and/or nomcom.

(Note: I said, "visibly". I think the much of the accountability is there,
but perhaps it is not visible enough to the community.)





--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-