Pete
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.
Understood and I will add an issue as a reminder to make that distinction and clarification. 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.
On the substantive issue, yes funders only fund for a purpose and the purpose we want them to support needs to be the higher purpose of an Internet built on open standards, which our success contributes to.
On the language issue, I’m wary of changing a word based on a localised creepiness factor, so I would rather aim for better clarification and explanation of the use of the word first.
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.
Understood. 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.
Seems reasonable. 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.
Understood. I suspect this will need to be address by a new transformation that crudely reads:
FROM: Requirements for LLC services sometimes expressed in terms of solutions TO: Requirements for LLC services always expressed in terms of 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.
Understood. I will aim to change this as you suggest to focus on improving the feedback loop around requirements to make it more regular and based on data etc. 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.
This concerns about being beholden, the need to customise and being locked are all valid but they need to be balanced with the many advantages that come from cloud apps and using APIs to integrate things. That means moving from an implicit architecture of building everything to an architecture of interoperability that allows us to either build, customise or purchase. I will aim to adjust that to reflect that better. 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.
The purpose of that bullet is to recognise the concerns that have been raised and ensure there is a plan to address them. The strategy deals with how to achieve that.
----
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.
Good suggestion. Thanks.
Jay
|
