On 3 May 2020, at 19:19, IETF Executive Director wrote:
[1]
https://github.com/ietf-llc/strategy-2020-consultation/blob/master/DRAFT%20Strategic%20Plan%202020.md
Hi Jay,
Some specific comments on the document:
Under "Strategic Goals":
4. To ensure the value of the IETF is well understood by participants
and key stakeholders beyond.
I'm not convinced that explaining value to newcomers or other
participants is a goal of the LLC itself. Once someone is a participant,
or even is looking into participating, it is really the job of the
entire community, as led by the IESG and assisted by the EDU team, to
help participants make their best contributions and get the most out of
participating. Insofar as there might be administrative support that can
be given to the IESG or the EDU team to accomplish that goal, I would be
fine with stating the goal that way, but not worded as a goal of the LLC
itself.
Now, when it comes to explaining the value of IETF to potential funders,
I do see that as a specifically an LLC goal. However, describing
potential funders as part of the set of "key stakeholders" creeps me out
a bit. I think it's anathema to our mission to have funders hold a stake
in the IETF, or maybe more specifically the IETF standards process. They
can have a stake in promoting our success for sure, but "holding a
stake" brings up images of "ownership and control", which would not be
good.
Overall, I think goal 4 needs to be reworded, and the "Transformation:
Engagement" section updated to match, particularly the "Cutting edge
technologies" and "Newcomers" bullets, and making clear throughout that
these are IETF led and LLC supported.
6. To deliver a modern and universally well regarded toolchain
supporting all the steps of the standards development process.
On the surface, this seems quite reasonable, but I think we need to be
careful. Let's start with "universally well regarded": I certainly want
our toolchain for the standards development process to be well-regarded
by the folks using it (or potentially using it in the future), but
"universally" has an implication that anyone who might come along should
be impressed. That I'm not on board with. It needn't be slick; it
needn't impress by using the latest user interface bells and whistles,
and it needn't be viewed by the marketing department of a company that
has employees working in the IETF as "really cool" (not to pick
specifically on marketing people). It must only impress people who are
(or who might) be using it as part of working on standards.
As for "modern": I certainly want the toolchain to be up-to-date and
working well, but "modern" has another implication, in that the
toolchain should somehow use the latest and greatest technology or a
fancy modern UI. Pushing that the tools use the coolest new programming
language, or database format, or new web technology is
counter-productive; working reliably and easily far outweighs those
considerations. And a modern UI can be nice in some instances, but again
it is far outweighed by functionality and predictability for those who
use it on a day-to-day basis.
So I'd like to see something like "up-to-date and well-regarded by
users" instead of "modern and universally well regarded" in this item,
and a change of the uses of "modern" in the "Transformations: Tools"
section.
With regard to the "Transformations: Culture" section, I think the
overall goal of looking to data and evidence is laudable, but I think
this section missed an important bit. Looking at the example:
For example, someone has a good idea that we should provide X for
participants and rather than ask participants if they want X, how they
already obtain it and if it is a priority for them, a debate takes
place on the merits of us providing it or not. Sometimes this debate
results in stalemate and issues get put into the “too hard” basket
as a result.
Absolutely part of this is ignoring data. But part of it is also a
"tactics" vs. "strategy" problem. Every time someone makes this kind of
specific proposal, what they are failing to do is lay out a high-level
"value" proposition: How does doing this thing you propose meet one of
our strategic goals? If it is truly a "good idea", then it should be
easy to articulate what strategic goal it achieves. Of course developing
strategic goals means looking at the data and agreeing to what needs
fixing, but looking at data is the means, not the ends. The ends are to
come up with a set of values (aka strategic goals), so that the
discussion centers around whether or not a particular proposal is
meeting that goal or not. Make it clear that looking at the data is
meant to result in an articulable list of values/goals.
In "Transformations: Meetings", you say:
The first issue is the increasingly adverse impact of the complex set
of requirements that were developed by the community without relying
on empirical data on the impact on meeting cost and venue suitability.
I want to start by saying that I have no vested interest in any of the
particular criteria described in RFC 8718; I chaired the group and I
think many of the criteria correctly express values of the community,
but I was decidedly "in the rough" on several of the criteria, and I
would expect that others (including members of the secretariat) are in
the same boat. That said...
Let's be very clear that RFC 8718 only has three hard "requirements" for
meeting selection, and they are not particularly wild-eyed: 1) The
facility must have sufficient and appropriate space for all of us, 2)
the facility must have wheelchair access, and 3) it must be possible for
us to provision Internet Access to the facility of appropriate bandwidth
and configuration for our needs. All of the remaining listed criteria in
that document are labeled as "Important" or "Desirable", and the only
requirement is to inform the community if any of the "Important"
criteria cannot be met. The meeting planners are expected to use their
judgment to determine how to best meet these criteria and (judiciously)
deciding that some can't be met for any particular meeting. Now, there
is no doubt that if empirical data shows that any of these criteria are
consistently impossible to meet without unacceptable impact to venue
selection, that data should be brought back to the community, but
communicating back to the community should be happening if any of the
"Important" criteria are unable to be met, ostensibly so that the
community can update its list of desires. So I simply disagree with this
paragraph's (and item #16's) characterization of the problem. If this
were changed to say that the data is not being given to or evaluated by
the community at an appropriate interval, or that the communities list
of criteria is not being updated on a regular enough basis given the
data that has been sent, I would be fine with it.
In "Transformation: Tools", the last problem bullet says:
The implicit architecture of custom building everything seems
increasingly unrealistic and inefficient in a world of cloud apps,
APIs and web services.
I can't say one way or the other whether the implicit architecture is to
custom build everything, and insofar as we can integrate some
off-the-shelf stuff, I think that's probably a fine thing to do.
However, the mention of "cloud apps, APIs and web services" might imply
that we ought to be beholden to outside vendors without the ability to
keep and customize their code, or to services tied to a particular
vendor that we won't be able to extricate ourselves from should our
goals and theirs diverge. Insofar as this bullet reduces to "concerns
about performance, functionality and prioritization of changes", we
should simply remove it. If it implies that we should scrap custom code,
I disagree. If there's some other purpose for the bullet, please
explain.
----
Finally, a suggestion to try to allay some of the concerns from Stephen
and others: Perhaps a statement in the Introduction, elaborated in the
"Transformations: Strategic Planning" section, that makes it clear that
it is understood that the IETF community is a dynamic one, with leaders
and other participants changing at a higher rate than the 3-5 year plan,
and that the LLC takes it as understood that it must adjust its plan
should IETF consensus shift.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
