Subject: Re: Consultation on IETF LLC Draft Strategic Plan 2020

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 May 2020 01:48:57 +0100

Hiya,

To be clear: I fully accept Jay's bona-fides here,
and those of whomever he has already had discussions
with about this. IOW, I think this is a well
intentioned, but fundamentally misguided, ask.

On 04/05/2020 01:19, IETF Executive Director wrote:
> This email now begins a two week consultation on this Draft Strategic
> Plan 2020, closing on Monday 18 May.
I don't think that deadline is acceptable. (*)

I think it's a fine idea for the LLC folks to be planning
how to do things better. I'm allergic to that being done
as a "strategic" review. The LLC needs to be mostly driven
by the wishes of the community. If the community do not
have a 3-5 year strategy (and we clearly do not:-) then I
don't see how the LLC can, without the LLC risking, or
being perceived to be risking, usurping the community's
control over the whole shebang.

I suggest we cancel this and find another way for the
community to set 3-5 year priorities for the LLC. That
should start by asking what the community think could
be improved maybe. (But it should start with questions
and not proposals.)

As a concrete example of why this 2 week review is (IMO)
not acceptable, I fundamentally disagree with this as a
positive proposition:

  "LLC strategy closely aligned with the strategic
   objectives of IESG, IRSG and IAB"

The IESG and IAB do not have objectives in a 3-5 year time
frame as personnel rotate more often than that. The IRSG
are the RG chairs and at-large members selected by the IRTF
chair, who is selected by the IAB. (To be open: I was on
the IESG, and am currently on the IAB and IRSG.) The people
with whom I've served on those bodies were almost all
ones with whom I'd happily work again, but neither I nor
they can IMO validly set "strategic objectives" in that
timeframe, nor could they act as entities with whom the
LLC's "strategy" could be aligned, in that timeframe.

No discussion of whether or not the concern I express here
is crazy or sane could be sorted out in 2 weeks. Therefore a
2 week deadline is unacceptable.

Cheers,
S.

(*) I'm only objecting to the deadline in this mail. I
plan a more substantive response where I might well object
to the entire concept of the LLC having a "strategy"
without that term being highly qualified.

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 May 2020 20:55:45 -0400

> 2 week deadline is unacceptable.

+1.  (the whole message, really, but especially this.)

Keith

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Mon, 4 May 2020 02:01:44 +0000

Jay

There is no mention of the ietf trust here.  While the IETF llc is not the only financial supporter of the ietf trust, it is still the largest. I would like to see explicit support for the ietf trust in the strategic plan. 

Glenn (wearing my IETF Trust chair hat)

> On May 3, 2020, at 5:20 PM, IETF Executive Director <[email-masked]> 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.
> 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.
> 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.
> 
> This email now begins a two week consultation on this Draft Strategic Plan 2020, closing on Monday 18 May.
> 
> If you have any comments or questions then you can submit those by any of the following methods:
> 
> * Raising an issue on the Github repository
> * Direct to me at [email-masked]
> * Direct to the IETF LLC Board (not including me) at [email-masked] 
> * To the [email-masked] list
> 
> [1] https://urldefense.com/v3/__https://github.com/ietf-llc/strategy-2020-consultation/blob/master/DRAFT*20Strategic*20Plan*202020.md__;JSUl!!PIZeeW5wscynRQ!4ax0SIlZFLAWaULgaRl8-IY3DvPbsHvpWQ7AJzKMHXZZqnplYsH0M5VYr7SjjwYk$ 
> 
> -- 
> Jay Daley
> IETF Executive Director
> [email-masked]
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!PIZeeW5wscynRQ!4ax0SIlZFLAWaULgaRl8-IY3DvPbsHvpWQ7AJzKMHXZZqnplYsH0M5VYr74RUR6D$

---

From: Jay Daley <[email-masked]>
Date: Mon, 4 May 2020 14:03:18 +1200

Stephen

I think you’ve read and reacted to this too quickly.  The LLC goal given to it by the community, to achieve a high level of transparency, means that there is a lot being presented for comment here all in one go.   If the time is too short to allow proper absorption and analysis then I’m more than happy to extend the deadline.

More detailed response below:

> On 4/05/2020, at 12:48 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> don't see how the LLC can,

It’s nowhere near as simple as that.  The community has taken plenty of action that is strategic and is intended for 3-5 year timescale or longer.  The creation of the LLC is one of those strategic acts and in creating the LLC the community explicitly gave it some strategic objectives, which this draft tries to document as:

* To secure long-term funding for the LLC/IETF/IRTF/IAB that is more than sufficient to meet their plans.
* To provide the high quality planning and support services required for the IETF to hold productive meetings both in-person and online.

It’s true that there is no document entitled "IETF Community 3-5 year strategy" but there are plenty of strategic groups and strategic initiatives that have been completed or are underway, such as the whole IASA2 work or the current IAB program on the RFC Editor Future Development.  The lack of a single reference to the outputs of those doesn’t mean they can’t be used as strategic inputs.

There may be some elements where you feel the draft goes further than anything document, in which case let’s discuss it.

> without the LLC risking, or

The first safeguard against that is to enshrine community control as a core value.  This draft strategy does that with three core values just to be sure:

* Trusted.  The LLC will uphold the values and policies of the IETF/IRTF/IAB as if they were its own.
* Responsive.  The LLC will act consistently with the documented consensus of the IETF community, adapt its decisions in response to consensus-based community guidance, and engage with the community to obtain consensus-based guidance for how it operates where none exists.
* Focused.  The LLC will focus solely on its defined role and within its defined mandate.

The second safeguard is to define the strategy process in a way that ensures community control.  This draft strategy does that with two core transformations:

* LLC strategy closely aligned with the strategic objectives of IESG, IRSG and IAB
* Open, annual strategy process that captures community requests/suggestions in a structured process

If those safeguards are insufficient or badly worded then please recommend how they could be strengthened.

> be improved maybe. (But it should start with questions

The end goal we are all aiming for is a strategy that is community-led and delivers community requirements.  To achieve that, a balance has to be made between the time it takes to start with a blank page and the risk of leading the conversation by starting with a proposal.  Given the length of time the LLC has been operating, how long it took to appoint the permanent ED and the tasks facing it, it seemed appropriate to start with a detailed proposal rather than a blank page.

I should also note that much of this was already foreshadowed by the sharing of my goals [1]

> frame as personnel rotate more often than that.

The draft has multiple parts to it, only one of which is 3-5 year goals.  The bulk of it is the strategic transformations that are 1-3 years and so fit well with personnel rotation cycles.

> The IRSG

You’re missing the point.  The IESG/IRSG/IAB can choose whether or not to have a strategy, that is up to them.  If they choose to have one then we need to make sure that the LLC strategy aligns with their strategies and is not off in a different direction.

> 2 week deadline is unacceptable.

I’m more than happy to extend - can you suggest a deadline or would you like it open-ended?

Jay

> <0x5AB2FAF17B172BEA.asc>

[1]  https://mailarchive.ietf.org/arch/msg/ietf-announce/tlGE60p0HACGrP4osnQ1RAjc9Mw/

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Mon, 4 May 2020 14:05:32 +1200

Thanks Glenn.  I’ve captured this as an issue in the GH repo https://github.com/ietf-llc/strategy-2020-consultation/issues/1

Jay

> On 4/05/2020, at 2:01 PM, Deen, Glenn (NBCUniversal) <[email-masked]> wrote:
> 
> Jay
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 3 May 2020 23:24:56 -0400

While there are aspects of this to be concerned about, and details that 
need work, looking at the document as a whole it does a good job of 
laying out what it is about, and then going through the pieces.  And 
many of those pieces are ones that I would not have considered, and do 
agree are important.

Thank you,
Joel

On 5/3/2020 8:19 PM, IETF Executive Director wrote:
> [1] https://github.com/ietf-llc/strategy-2020-consultation/blob/master/DRAFT%20Strategic%20Plan%202020.md
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 May 2020 18:42:05 +1200

Stephen,

Apart from agreeing that 2 weeks isn't enough, I tend to disagree with you.
On the contrary, I'm delighted to see that the LLC is thinking about the
medium term. Somebody needs to. As you say,

>  If the community do not
> have a 3-5 year strategy (and we clearly do not:-)...

Shame on us, then. It's clear that COVID-19 and sustainability arguments
mean that "go on doing what we've been doing" isn't a plan.

Admittedly, that doesn't make IETF LLC's planning any easier. I won't say
more till I've had a chance to read the draft.

Regards
   Brian

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 4 May 2020 11:40:54 +0200 (CEST)

> Il 04/05/2020 02:19 IETF Executive Director <[email-masked]> ha scritto:
> 
>  

I'm not enough an insider in this community to really appreciate all the implications of this document, though I like the idea of some organized medium and long term planning. (I must confess that when I read that "The LLC will uphold the values and policies of the IETF/IRTF/IAB" I wondered where I could find the values of the IETF; it doesn't seem to be immediate.)

However, I noticed that in the transformations section there are references to making the IETF more welcoming to newcomers, but I found nothing about increasing the diversity of the participants in several possible dimensions (gender, geography, language, age, employer, stakeholder group...) This is a standard objective for almost any organization claiming a global role, and normally translates into specific organizational measures and programs, building on the assumption that diversity is necessary to legitimacy, fosters better results, promotes participation and helps build tomorrow's leadership, keeping the organization successful in the long term.

There are practical things that can be done with some investment; for example, I don't expect the IETF to start translating its sessions into multiple languages, but automated closed captioning of the presenter would be quite useful for non-native speakers; or, one could imagine outreach sessions in local language towards Internet communities in target countries, to explain what the IETF is, what it does, and how to participate.

I don't know if this was ever considered before, but a strategic plan is a typical context for this discussion.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 May 2020 12:54:30 +0100

Hiya,

On 04/05/2020 03:03, Jay Daley wrote:
> Stephen
> 
> I think youâ€™ve read and reacted to this too quickly. 

Possibly. But no deep thought was needed to object
to a 2 week deadline:-)

> The LLC goal
> given to it by the community, to achieve a high level of
> transparency, means that there is a lot being presented for comment
> here all in one go. 

I'm not sure if that "all in one go" part is a bad plan,
but we'll see.

>  If the time is too short to allow proper
> absorption and analysis then Iâ€™m more than happy to extend the
> deadline.

TBH, I don't think it should be your call as to what the
deadline might be, nor who sets it. Deciding how to get
community direction (not input) for the LLC over the next
3-5 years seems to me a thing the IESG ought control, not
the LLC. The practical difference is small, but I think
important. (Again, this is about the process, not the
content.)

>> To be clear: I fully accept Jay's bona-fides here, and those of
>> whomever he has already had discussions with about this. IOW, I
>> think this is a well intentioned, but fundamentally misguided,
>> ask.
>> 
>>> This email now begins a two week consultation on this Draft
>>> Strategic Plan 2020, closing on Monday 18 May.
>> I think it's a fine idea for the LLC folks to be planning how to do
>> things better. I'm allergic to that being done as a "strategic"
>> review. The LLC needs to be mostly driven by the wishes of the
>> community. If the community do not have a 3-5 year strategy (and we
>> clearly do not:-) then I don't see how the LLC can,
> 
> Itâ€™s nowhere near as simple as that.  The community has taken
> plenty of action that is strategic and is intended for 3-5 year
> timescale or longer.  The creation of the LLC is one of those
> strategic acts and in creating the LLC the community explicitly gave
> it some strategic objectives, 

Can you point at what you mean? No doubting you but I
don't recall such a list.

> which this draft tries to document as:
> 
> * To secure long-term funding for the LLC/IETF/IRTF/IAB that is more
> than sufficient to meet their plans. * To provide the high quality
> planning and support services required for the IETF to hold
> productive meetings both in-person and online.
> 
> Itâ€™s true that there is no document entitled "IETF Community 3-5
> year strategy" but there are plenty of strategic groups and strategic
> initiatives that have been completed or are underway, such as the
> whole IASA2 work or the current IAB program on the RFC Editor Future
> Development.  The lack of a single reference to the outputs of those
> doesnâ€™t mean they canâ€™t be used as strategic inputs.
> 
> There may be some elements where you feel the draft goes further than
> anything document, in which case letâ€™s discuss it.

Sure. Like I said, I'll send more comment later. For now,
I'm discussing the process only and not the content.

> 
>> without the LLC risking, or being perceived to be risking, usurping
>> the community's control over the whole shebang.
> 
> The first safeguard against that is to enshrine community control as
> a core value.  This draft strategy does that with three core values
> just to be sure:
> 
> * Trusted.  The LLC will uphold the values and policies of the
> IETF/IRTF/IAB as if they were its own. * Responsive.  The LLC will
> act consistently with the documented consensus of the IETF community,
> adapt its decisions in response to consensus-based community
> guidance, and engage with the community to obtain consensus-based
> guidance for how it operates where none exists. * Focused.  The LLC
> will focus solely on its defined role and within its defined
> mandate.
> 
> The second safeguard is to define the strategy process in a way that
> ensures community control.  This draft strategy does that with two
> core transformations:
> 
> * LLC strategy closely aligned with the strategic objectives of IESG,
> IRSG and IAB * Open, annual strategy process that captures community
> requests/suggestions in a structured process
> 
> If those safeguards are insufficient or badly worded then please
> recommend how they could be strengthened.

Again, that's for another day.

> 
>> 
>> I suggest we cancel this and find another way for the community to
>> set 3-5 year priorities for the LLC. That should start by asking
>> what the community think could be improved maybe. (But it should
>> start with questions and not proposals.)
> 
> The end goal we are all aiming for is a strategy that is
> community-led and delivers community requirements. 

Yes.

> To achieve that,
> a balance has to be made between the time it takes to start with a
> blank page and the risk of leading the conversation by starting with
> a proposal.  Given the length of time the LLC has been operating, how
> long it took to appoint the permanent ED and the tasks facing it, it
> seemed appropriate to start with a detailed proposal rather than a
> blank page.
> 
> I should also note that much of this was already foreshadowed by the
> sharing of my goals [1]>
>> As a concrete example of why this 2 week review is (IMO) not
>> acceptable, I fundamentally disagree with this as a positive
>> proposition:
>> 
>> "LLC strategy closely aligned with the strategic objectives of
>> IESG, IRSG and IAB"
>> 
>> The IESG and IAB do not have objectives in a 3-5 year time frame as
>> personnel rotate more often than that.
> 
> The draft has multiple parts to it, only one of which is 3-5 year
> goals.  The bulk of it is the strategic transformations that are 1-3
> years and so fit well with personnel rotation cycles.
> 
>> The IRSG are the RG chairs and at-large members selected by the
>> IRTF chair, who is selected by the IAB. (To be open: I was on the
>> IESG, and am currently on the IAB and IRSG.) The people with whom
>> I've served on those bodies were almost all ones with whom I'd
>> happily work again, but neither I nor they can IMO validly set
>> "strategic objectives" in that timeframe, nor could they act as
>> entities with whom the LLC's "strategy" could be aligned, in that
>> timeframe.
> 
> Youâ€™re missing the point. 

I don't believe I am.

> The IESG/IRSG/IAB can choose whether or
> not to have a strategy, that is up to them.  If they choose to have
> one then we need to make sure that the LLC strategy aligns with their
> strategies and is not off in a different direction.

We need to ensure that the LLC does not set the strategy
for the community, given that we know the IESG/IAB change
personnel as they do and hence never have a 3-5 year
strategy. Hopefully the LLC doesn't see personnel change
nearly as often, so it can have some longer term plans,
and having those is a good idea. But it's far too easy
to end up with the tail wagging the dog in such situations,
even when everyone is acting in what they see as everyone's
best interests.

>> No discussion of whether or not the concern I express here is crazy
>> or sane could be sorted out in 2 weeks. Therefore a 2 week deadline
>> is unacceptable.
> 
> Iâ€™m more than happy to extend - can you suggest a deadline or would
> you like it open-ended?

More time is needed yes. I also think it needs to be the
IESG that own this process, and hence set any deadline,
should one be needed. Owning the process also means being
the one to decide how to handle feedback. Depending on
the feedback received, a simple deadline may or may not
be enough.

Cheers,
S.

> 
> Jay
> 
>> 
>> Cheers, S.
>> 
>> (*) I'm only objecting to the deadline in this mail. I plan a more
>> substantive response where I might well object to the entire
>> concept of the LLC having a "strategy" without that term being
>> highly qualified. <0x5AB2FAF17B172BEA.asc>
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/ietf-announce/tlGE60p0HACGrP4osnQ1RAjc9Mw/
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 May 2020 06:44:48 -0700

On Sun, May 3, 2020 at 11:42 PM Brian E Carpenter <
[email-masked]> wrote:

> Stephen,
>
> Apart from agreeing that 2 weeks isn't enough,

I also tend to think that 2 weeks isn't enough. This document isn't that
long so I don't think it's unreasonable to expect people to read it in a
few weeks, but I do think this will probably require >1 round of
consultation and feedback.

I tend to disagree with you.
> medium term.

+1.

Moreover, I would say that I think this sort of "we propose this kind of
plan but want to see what the community thinks" is precisely what I would
have expected the LLC board to do. I certainly do not think that, as
Stephen suggests, the IESG should be doing this work. The reason we have an
LLC with a separate board is precisely to have that board handle this kind
of administrative work.

Perhaps some of the allergy here is to the word "strategy" here and that
one might read that as the LLC setting the strategy for the IETF? What I
take the appropriate subject matter here is the long term planning for the
IETF LLC. This is not only appropriate but necessary. Consider, for
instance, our software toolchain, where we have considerable investment and
which needs to have a roadmap well in advance (i.e., a strategy).

-Ekr

Somebody needs to. As you say,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 May 2020 15:12:21 +0100

Hiya,

On 04/05/2020 14:44, Eric Rescorla wrote:
> one might read that as the LLC setting the strategy for the IETF?

That is certainly a part of what triggered my response.
As I said in my first mail, if the term were properly
qualified, this could be a good bit easier to handle.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 May 2020 14:40:45 +0000

I agree with some others; two weeks *might* be enough for a single go-around, but I want the LLC to do multiple round-trips with the community on this document.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 04 May 2020 10:32:06 -0700

Hi Stephen,
>intentioned, but fundamentally misguided, ask.

Could you please ask the Internet Architecture Board to publish its 
strategic objectives for the next three to five years?  The rationale 
for the request is that the information could useful to help in 
responding to the current IETF Administration LLC consultation?

A few days ago, I looked up the LLC status.  It was a bit surprising 
to find out that it is not a recognized not-for-profit legal entity 
even though it was incorporated in 2018.   I did not ask whether that 
would have an impact on IETF operations.

The LLC Directors would have discussed the matter.  I could not 
locate when that happened.  It looks like a consultation on a 
theoretical paper as there isn't any evidence to back what is in 
it.  That does not mean that the problems which the 
Executive  Director is tasked to work on are not real problems.  As 
an example, an IETF attendee is only charged for half the cost of the 
services he/she is provided with.  Where does the other half of the 
money come from might be one of the questions a person might ask.  If 
it is from the Public Interest Registry, does the fact that the 
Internet Engineering Steering Group [1] appoint a few members on the 
board of its holding company mitigate the risk of the IETF LLC 
posting a significant loss?

Regards,
S. Moonesamy

1. I did not verify the details for accuracy.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 4 May 2020 11:57:33 -0700

> would have an impact on IETF operations.

The LLC inherits ISOC's not-for-profit status, as it is a disregarded
entity under ISOC's umbrella; see section 9 of the IETF-LLC Agreement:

The Company and the Member intend that the Company be treated as a
disregarded entity for all federal and relevant state tax purposes. Neither
the Company nor the Member shall take any action or make any election which
is inconsistent with such tax treatment. All provisions of this Agreement
are to be construed so as to preserve the Company’s tax status as a
disregarded entity

regards,

Ted

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 May 2020 20:08:33 +0100

Hi SM,

On 04/05/2020 18:32, S Moonesamy wrote:
> strategic objectives for the next three to five years? 

Eh, well I could ask. But given ~50% of the IAB may or may
not be members a year later I'm not sure there's a useful
(positive) answer to be had.

> The rationale

Even if the IAB could and did produce what you're asking
for, it'd not be done in 2 weeks;-)

S.

---

From: Jay Daley <[email-masked]>
Date: Tue, 5 May 2020 07:22:39 +1200

> However, I noticed that in the transformations section there are references to making the IETF more welcoming to newcomers, but I found nothing about increasing the diversity of the participants in…

While I fully agree with you, in the absence of any community guidance we did not want to assume a particular path.  If there is such guidance or you think adding something as you suggest would be uncontroversial then please let me know.

> 
> There are practical things that can be done with some investment; for example, I don't expect the IETF to start translating its sessions into multiple languages, but automated closed captioning of the presenter would be quite useful for non-native speakers;

I have added the suggestion about closed captioning as an issue in GH.  While it is a bit specific, it is a useful placeholder for a wider point about accessibility.

> or, one could imagine outreach sessions in local language towards Internet communities in target countries, to explain what the IETF is, what it does, and how to participate.

That is something that ISOC does and does well.  I would prefer we left it to them (as a formal role) as they have the organisation and resources to do that and replicating that is both very costly and unnecessary.  Informally, there are many community members who do this and we are looking more at supporting them.  I have added this last point as an issue in GH as something that could be explicitly stated.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 5 May 2020 07:28:51 +1200

> A few days ago, I looked up the LLC status.  It was a bit surprising to find out that it is not a recognized not-for-profit legal entity even though it was incorporated in 2018.   I did not ask whether that would have an impact on IETF operations.

As Ted has explained, the LLC is a 501(c)(3) but does not have a separate registration, instead it gets that status from ISOC.

> The LLC Directors would have discussed the matter.  I could not locate when that happened.  It looks like a consultation on a theoretical paper as there isn't any evidence to back what is in it.  

The LLC Chair wrote a blog about our f2f strategy meeting and sent an ietf-announce message about it: https://www.ietf.org/blog/recap-january-2020-ietf-llc-board-retreat/

> That does not mean that the problems which the Executive  Director is tasked to work on are not real problems.  As an example, an IETF attendee is only charged for half the cost of the services he/she is provided with.  Where does the other half of the money come from might be one of the questions a person might ask.  If it is from the Public Interest Registry, does the fact that the Internet Engineering Steering Group [1] appoint a few members on the board of its holding company mitigate the risk of the IETF LLC posting a significant loss?

Roughly 50% of LLC income comes in the form of support from ISOC. There is a major section of the strategy that discusses this.

As a reminder, the LLC is a sole-member organisation and ISOC is that sole member.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Mon, 04 May 2020 13:04:18 -0700

Hi Stephen,
>(positive) answer to be had.

Well, I asked and you replied.  That should be good enough. :-)

>for, it'd not be done in 2 weeks;-)

Let's assume that there are X IAB members where X is a number which 
is greater than two.  It is unlikely that the task is doable in two 
weeks as it usually take more time than that to resolve committee debates.

Regards,
S. Moonesamy

---

From: "Pete Resnick" <[email-masked]>
Date: Mon, 04 May 2020 15:49:58 -0500

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 May 2020 09:25:14 +1000

On Mon, May 4, 2020, at 19:40, Vittorio Bertola wrote:
> (I must confess that when I 
> read that "The LLC will uphold the values and policies of the 
> IETF/IRTF/IAB" I wondered where I could find the values of the IETF; it 
> doesn't seem to be immediate.)

See RFC 3935.  The others have prominent statements on their websites that seem clear.

> IESG that own this process, and hence set any deadline,

I am OK with round 1 being 2 weeks on the basis that it not be the only iteration.

> https://github.com/ietf-llc/strategy-2020-consultation/blob/master/DRAFT%20Strategic%20Plan%202020.md

If the LLC supports IETF/etc, then a clear pointer to what you believe their missions are (see RFC 3935, above, for an example).  The IAB have a mission on iab.org.  Etc...

Otherwise, I think that this is broadly reasonable.  These are the things that I would expect the LLC to build a strategy around.  I would like to thank Jay and the board for doing the hard work here.

It is hard to see how the board views the priority of these without more context.  As presented, I don't know how each item factors in, both in terms of a) the amount of time, energy, and money that is dedicated to the effort, and b) the amount that it contributes to supporting the mission of the IETF and others.  It might be easier to understand this if it were possible to see how the board considers the relative weight of (for instance) the operational piece vs. the meetings piece.

---

From: Jay Daley <[email-masked]>
Date: Tue, 5 May 2020 12:29:41 +1200

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

>> 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.

>> 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

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 5 May 2020 12:40:28 +1200

> On 5/05/2020, at 11:25 AM, Martin Thomson <[email-masked]> wrote:
> 

I will add that as an issue.

> Otherwise, I think that this is broadly reasonable.  These are the things that I would expect the LLC to build a strategy around.  I would like to thank Jay and the board for doing the hard work he…

Thanks.

> It is hard to see how the board views the priority of these without more context.  As presented, I don't know how each item factors in, both in terms of a) the amount of time, energy, and money tha…

That would be found at the next level down from this, which includes the budget and the list of projects it supports, the ED goals, and any operational plans that we develop.  It’s not yet clear when/how we will able to provide the operational plans with that level of detail or if that level of detailed planning is appropriate.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 6 May 2020 06:46:02 +0200

On Mon, May 4, 2020 at 2:20 AM IETF Executive Director <
[email-masked]> wrote:

> The IETF Administration LLC has prepared its Draft Strategic Plan 2020
> [1].

I think this drfat should be an ID best practice to become updated if
needed, but there may be reasons why it was not. If there was a reason,
then this plan should follow with all IETF RFC best practices. Therefore,
IMO this draft needs to refer to some best practices documents (ex,
RFC8711).

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.
>

how review or comment become productive if the plan was not input as ID or
within IETF process? however, I think this strategy plan is the
responsibility of LLC board as RFC8711-sec5.2.

>
> 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.
> 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.
> 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.
>

The strategy mostly depends on IETF community Needs, as mentioned in
RFC8711:

he role of the Board is to ensure that the strategy and conduct of
   the IETF LLC is consistent with the IETF's needs -- both its concrete
   needs and its needs for transparency and accountability.  The Board
   is not intended to directly define the IETF's needs; to the extent
   that is required, the IETF community should document its needs in
   consensus-based RFCs (e.g., as the community did in [RFC8718
<https://tools.ietf.org/html/rfc8718>]) and
   provide more detailed input via consultations with the Board (such as

   takes place on email discussion lists or at IETF meetings).

So IMHO, the IETF community should create an RFC for year 2020 to include
the IETF community Needs, so then this strategy plan can be more focused
and more productive. Therefore, this plan draft must reference the IETF
community Needs document (i.e. I was not sure if we have one or not, but if
we have one then please add it so we can comment while seeing the needs).

Best Wishes,

AB

> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 May 2020 17:03:38 +1200

Hi Jay,

>>> 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?

>>> 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.

>>> 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.

>>> 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.

>>> 14.	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 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.

There are certainly other bits of sofware where this doesn't apply. Data-based decision making, right?

Regards,
    Brian Carpenter

---

From: Jay Daley <[email-masked]>
Date: Tue, 12 May 2020 12:17:20 +1200

Apologies for the delay in responding

> On 6/05/2020, at 4:46 PM, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> 
> On Mon, May 4, 2020 at 2:20 AM IETF Executive Director <[email-masked] <mailto:[email-masked]>> wrote:
> The IETF Administration LLC has prepared its Draft Strategic Plan 2020 [1]. 
> 
> I think this drfat should be an ID best practice to become updated if needed, but there may be reasons why it was not. If there was a reason, then this plan should follow with all IETF RFC best practices. Therefore, IMO this draft needs to refer to some best practices documents (ex, RFC8711). 
> 
> 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.
> 
> how review or comment become productive if the plan was not input as ID or within IETF process? however, I think this strategy plan is the responsibility of LLC board as RFC8711-sec5.2.

I think it is important to differentiate between documents that specify the community consensus requirements that the LLC delivers and those documents that record how the LLC will deliver those requirements because they need to created and modified quite differently.  The LLC "delivery" documents, such as this strategy, need to bridge gaps in the community consensus requirements (hopefully only temporarily), which by definition cannot be done in a consensus document.  They also need to change regularly and sometimes rapidly (such as in response to COVID-19), which can be done through a consensus document but as an exception not the norm.  Finally, the LLC delivery documents go into much more detail than is appropriate for consensus requirements as those work best at the level of principles, criteria etc.

> The strategy mostly depends on IETF community Needs, as mentioned in RFC8711:
> 
> The role of the Board is to ensure that the strategy and conduct of
>    consensus-based RFCs (e.g., as the community did in [RFC8718 <https://tools.ietf.org/html/rfc8718>]) and
> So IMHO, the IETF community should create an RFC for year 2020 to include the IETF community Needs, so then this strategy plan can be more focused and more productive. Therefore, this plan draft must reference the IETF community Needs document (i.e. I was not sure if we have one or not, but if we have one then please add it so we can comment while seeing the needs).

My reading of the above is entirely consistent with the approach being taken in this consultation.

thanks for your feedback.

Jay

> * Direct to me at [email-masked] <mailto:[email-masked]>
> * Direct to the IETF LLC Board (not including me) at [email-masked] <mailto:[email-masked]> 
> * To the [email-masked] <mailto:[email-masked]> list
> 
> [1] https://github.com/ietf-llc/strategy-2020-consultation/blob/master/DRAFT%20Strategic%20Plan%202020.md <https://github.com/ietf-llc/strategy-2020-consultation/blob/master/DRAFT%20Strategic%20Plan%202020.md>
> 
> -- 
> Jay Daley
> IETF Executive Director
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 12 May 2020 13:59:37 +1200

> On 6/05/2020, at 5:03 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Jay,
> 

Added as an issue https://github.com/ietf-llc/strategy-2020-consultation/issues/12

> 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.

> https://www.ietf.org/proceedings/65/slides/newcomer-0.pdf

This is the LLC Board’s understanding of our role in the SDO ecosystem so I will need to find a path for this to be reconciled.    Added as https://github.com/ietf-llc/strategy-2020-consultation/issues/13

> 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" ?

Added as https://github.com/ietf-llc/strategy-2020-consultation/issues/14

> 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…

"… while still allowing for urgent requests during the year".  Added https://github.com/ietf-llc/strategy-2020-consultation/issues/15  

> 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.

> 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…

Added as https://github.com/ietf-llc/strategy-2020-consultation/issues/16

> I see some more explanation underneath but I'd appreciate an effort to use plainer English.

Added as https://github.com/ietf-llc/strategy-2020-consultation/issues/17

The integration with EDU is covered by earlier issue https://github.com/ietf-llc/strategy-2020-consultation/issues/5

> 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/14

> 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 b…

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.

> 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 shou…

Dogma either way is the issue.  I think the balance you are after is already expressed in https://github.com/ietf-llc/strategy-2020-consultation/issues/9

> I think this item would be equally valid and have a much longer lifetime with the word "cloud" simply removed.

I agree.  Captured as https://github.com/ietf-llc/strategy-2020-consultation/issues/18

> 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.

There are parts of datatracker that others regard as broken, performance for example.  However, this is specifically about LLC operations, not community facing, which I will make clear.  https://github.com/ietf-llc/strategy-2020-consultation/issues/19

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2020 17:22:23 +1200

Thanks Jay.

> I think that’s an IETF consensus decision, which if articulated the LLC would of course uphold as set out in the 'Responsive' value.

According to the IETF mission statement (RFC3935):

"Open process - any interested person can participate in the work..."
and
"The
Internet is a truly global network, reaching into just about every
country in the world.
The IETF community wants the Internet to succeed because we
believe that the existence of the Internet, and its influence on
economics, communication, and education, will help us to build a
better human society."

That pretty much implies what I wrote, IMHO. I don't see any other
interpretation.

Regards
   Brian Carpenter

On 12-May-20 13:59, Jay Daley wrote:
> 
> 
>> On 6/05/2020, at 5:03 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Jay,
>>
>>>>> 14.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
>>
> [email-masked] <mailto:[email-masked]>
>

---

From: Jay Daley <[email-masked]>
Date: Wed, 13 May 2020 07:13:39 +1200

> On 12/05/2020, at 5:22 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Thanks Jay.
> 
> On one point only:
> 

Two things

- Any value should be restricted to the LLC and how it operates and not a value aimed any wider.  So having a value about how the LLC deals with anyone in a neutral fashion, for a range of factors, is appropriate but having one about broader participation is not. 

- Whatever is added needs to avoid to unexpected consequences and as phrased I don’t think that it does because the LLC is a US based company and so subject to US laws and wherever possible contracting under US law and that situation, it could be argued, violates your proposed addition.

I’ve captured the issue here: https://github.com/ietf-llc/strategy-2020-consultation/issues/20 but I’m not sure yet what text would address it.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2020 13:22:29 +1200

On 13-May-20 07:13, Jay Daley wrote:
> 
> 
>> On 12/05/2020, at 5:22 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Thanks Jay.
>>
>> On one point only:
>>

Well, I will take that to gendispatch.

> - Any value should be restricted to the LLC and how it operates and not a value aimed any wider.  So having a value about how the LLC deals with anyone in a neutral fashion, for a range of factors,…

OK

> - Whatever is added needs to avoid to unexpected consequences and as phrased I don’t think that it does because the LLC is a US based company and so subject to US laws and wherever possible contrac…

Right, which is one of the reasons why the water under the bridge includes my rejected suggestion that the LLC should not be incorporated in the USA.

    Brian

>>>> On 6/05/2020, at 5:03 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi Jay,
>>>>
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>
>>
> 
> -- 
> Jay Daley
> IETF Executive Director