Hi Jay, On 04-May-20 12:19, IETF Executive Director wrote: The IETF Administration LLC has prepared its Draft Strategic Plan 2020 [1]. This is a significant expansion on the previous IETF LLC strategy and is intended to provide a comprehensive strategy both for the 2020 fiscal year and the long term.
The strategic plan is made up of the following elements, all of which are being presented for comment:
1. **Mission**. This is a literal definition of what the IETF LLC does. The mission rarely changes in the lifetime of the company.
2. **Values**. These define how the company behaves as it follows its mission. These may change over time to reflect broader social changes.
Transparent. The IETF community can expect the LLC to keep it informed...
I'd strike "IETF" here. It gets laborious to put IETF/IRTF/IAB every time. Also, the funders probably want to be kept informed too.
Should the Values also mention the international scope: no loyalty to any particular economic, geographical or cultural factors?
I think that’s an IETF consensus decision, which if articulated the LLC would of course uphold as set out in the 'Responsive' value. 3. **Strategic Goals**. The highest priority goals of the IETF LLC. These may be short-, medium- or long-term goals or a mix. These are the big picture of what the IETF LLC is aiming to do in the next 3-5 years and so are the key setting that the board expects the company to follow.
1. To support the IETF in being the predominant standards development organisation (SDO) of choice for those who want to develop Internet protocols that deploy at scale.
I'd delete "predominant". It sounds like a declaration of war against other SDOs, and that isn't appropriate; we have bilateral liaisons with them. Also, I wonder whether you should qualify "Internet protocols" because we do, in fact, have a limited scope. It's limited more or less by those liasons with other SDOs. We don't do link layers and we are very selective about the application layer. It's hard to summarise in a few words. Maybe "basic Internet protocols". The old newcomers' presentation had a slide on this: page 5 at https://www.ietf.org/proceedings/65/slides/newcomer-0.pdf
4. ... key stakeholders
I think it's better to avoid corporate buzzwords like this. I'd be more neutral: simply delete "key stakeholders" and replace it by nothing.
While I’m averse to avoiding corporate buzzwords, your comment at the top of this message made me see that this can be made more specific. So perhaps "To ensure the value of the IETF is well understood by participants, supporters and the broader community" ?
4. **Strategic Transformations**. These detail the changes that need to be made in order to achieve the strategic goals. Each transformation details the current state and the desired state to transform into. These transformations should be achievable within 1-3 years.
2. Multiple demands for spending throughout the year from individual requests and suggestions → Open, annual strategy process that captures community requests/suggestions in a structured process
OK, but you should leave scope for unplanned urgent requests that come up without warning. (Unless you mean "annual" in Internet years, which are generally reckoned to last about 10 weeks as far as Google can tell me.:)
3. Policy set partially complete and not yet bedded in → Policy set complete, fully bedded in and signed off by ISOC
I realise that ISOC has a word to say, but I think we need to get IETF/IRTF/IETF Trust/RFC Editor signoff first.
Community sign off is assumed. This is a very specific task because our operating agreement with ISOC requires us to get a specific set of policies in place and signed off by ISOC. The reason for that is that the IRS asks all US 501(c)(3) charities to declare if they have those policies on their form 990 and as the LLC is a disregarded entity, we are included on the ISOC form 990. There is also no public call for community input until near the end of the strategy process and only then indirectly by soliciting feedback on the draft budget.
I read this with alarm until I realised that these paragraphs describe what's wrong with the existing practice. Could you insert a short preamble, or make the first sentence ("Our overall strategy process has significant scope for development.") a bit more explicit ("Our existing strategy process has the following significant problems.")
5. Poor understanding of the entry points , stages and transitions of the participant journey
What's the "participant journey" in English? Also, this topic seems to overlap with the IETF's own Education and Mentoring Directorate (EMO), and the boundary needs to be closely defined. We had boundary problems in the past between the old EDU team and ISOC efforts. I see some more explanation underneath but I'd appreciate an effort to use plainer English.
6. Patchy externally focused content making it hard to demonstrate the value of the IETF to many stakeholders
Again, lose the "stakeholders". The word revives my nightmares about WSIS/WGIG.
Added to existing issue https://github.com/ietf-llc/strategy-2020-consultation/issues/1414. Limited number of ways in which we can receive funds and so we are leaving too much on the table. → Multiple “buckets” will be set up to receive funds, with multiple opportunities for contributions to be received
Be careful about multiple buckets. It's important to avoid money being given for very specific purposes such as favouring one particular topic or (worse) one particular standards effort. It would be OK to accept money for a topic-neutral purpose, but money with strings attached is worth less than plain money.
The multiple buckets here refers to multiple opportunities to donate rather than the uses it is put to. We already have multiple uses including an endowment, which cannot now be easily unpicked. The implicit architecture of custom building everything seems increasingly unrealistic and inefficient in a world of cloud apps, APIs and web services.
I have seen so many disasters caused by this dogma that I am now convinced that it's dangerous. Off the shelf software is often crap, even if its user interface looks pretty. I'm not saying we shouldn't use off the shelf solutions where they are better, but they are often worse than the home-brew that they replace. So this choice should be data-based, not $$-based or trend-based.
24. Operational processes don’t take advantage of the features and efficiency gains of modern cloud apps → Operational processes empowered by a suite of modern, efficient and feature rich cloud apps
What do you gain by the buzzword "cloud"? A few years ago the buzzword was "grid" or "web services", I've seen "fog", and next year it might be something else. The IETF apps have always been on-line, regardless of the buzzword of the year. I think this item would be equally valid and have a much longer lifetime with the word "cloud" simply removed.
But again: IETF participants are *very* sensitive to tooling changes, because we all have workflows set up. The datatracker is a great success precisely because it evolved over years in response to needs, and was largely implemented by experienced IETF participants. As a result, it's very much fit for purpose. Ain't broke, don't fix.
Jay
There are certainly other bits of sofware where this doesn't apply. Data-based decision making, right?
Regards,
Brian Carpenter
|
