Subject: Request for feedback - IESG thoughts about new work proposals

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Oct 2017 08:21:01 -0500

The IESG has spent considerable time discussing how we can improve our
ability to charter new work as soon as it’s ready and ensure proposals have
the resources needed for success. We want to share our expectations about
BOF requests and new work proposals with the community because we are
interested in feedback.

We ask for feedback, either on the IETF Discussion List (so, replies to
this note are fine), or optionally, to the IESG at [email-masked]. We would
like to put this in place soon after IETF 100.

We would like to see earlier notice about proposals for new work, and more
attention to specific work products in proposals.

*** Earlier notice to ADs about proposals for new work to enable better
support and improving chances of success

We ask that proponents provide BOF requests and proposals for new work as
early as possible so that your area directors can begin evaluating these
requests long before our coordination call with the IAB each IETF meeting
cycle.

Earlier notice about new work proposals will give area directors more time
to provide direction, to involve other IETF participants with relevant
backgrounds and related interests, and to confirm whether a BOF would be
required to consider a proposal for new work.

Earlier notice about new work proposals will also give area directors more
time to request that the IAB provide BOF shepherds to help improve BOF
requests, when that is appropriate, and more time for BOF shepherds to help
to improve the BOF proposal.

The IAB's expectations are described in their statement on "IAB Member
Roles in Evaluating New Work Proposals"[1].

*** More focus on specific work products in new work proposals

The IESG has received some BOF requests that describe interesting problems
at considerable length but do not clearly identify what the BOF proponents
want the IETF to do. When that happens, we cannot approve a BOF intended to
form a working group.

In some cases, area directors might approve a non-WG-forming BOF to tease
out the details of the BOF proposal, but often that isn’t the best way
forward. However, we also want to put ideas in front of the IETF community
early in the process, in order to gauge community interest and feasibility.

The BOF Wiki at https://trac.tools.ietf.org/bof/trac/wiki, where we collect
BOF requests for each upcoming IETF meeting cycle, will be using this
template:

- Long name and abbreviation

- Description, including whether the BoF is intended to form a WG or not

- The responsible Area Director (AD)

- Suggested BoF Chairs (or the ADs as placeholders)

- Number of people expected to attend

- Length of session (1, 1.5, 2, or 2.5 hours)

- Conflicts to avoid (whole Areas and/or WGs)

- Links to the mailing list, draft charter if any, relevant
Internet-Drafts, etc.

Proponents are encouraged to add new entries in the BoF wiki even if they
don't have all information that the template is asking for yet. The entry
can be modified until the Cut-off date for BOF proposal requests to Area
Directors, which is available from
https://ietf.org/meeting/important-dates.html.

When writing the description, the IESG strongly encourages BOF proponents
to focus on the work that would be reflected in an approved working group
charter. What we are looking for is:

- What protocols or practices already exist in this space?

- What modifications are required for the purpose described in the BOF
request?

- What entirely new protocols or practices must be developed?

We prefer that BOF proponents do this mapping, and gap analysis, rather
than relying on the IESG, the IAB, and the broader community. That will
help us make better decisions more quickly about approving BOFs, and to
charter new work more quickly, that produces solutions more quickly. As we
said in "Support Documents in IETF Working Groups" [2],

"In order to speed up the time period from idea to running code, the IESG
supports working groups that commence solution work early in the working
group timeline, and do not wait for completion and publication of the
support documents. When the problem scope is well understood and agreed
upon, charters focused on solutions work are extremely efficient."

Spencer Dawkins, for the IESG

[1]
https://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/

[2] https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Oct 2017 09:44:58 +0200

Hi Spencer,

Thanks to the IESG for focusing on how to better develop new work at the
IETF.  The note is a good start, but let me ask a question:  Our working
methods are evolving.  Should your note be focused on bofs or on new
work as a whole?  For instance, is it worth doing a broader message that
answer some more general questions, like these:

  * How best to determine which area to bring work to in the first place?
  * How can the IESG facilitate nascent ideas prior to their entering
    the formal standardization (e.g., non-wg mailing lists, bar bofs,
    presentation at one of the area meetings, etc) and how to arrange
    for these activities?
  * When to use a bof and when to use a wg like dispatch (or perhaps
    secdispatch)?
  * When to (not) approach an AD to do AD-sponsored work?
  * Can one make use of shepherds and what is their role?
  * What to do when you believe you've hit a wall.

As perhaps a trivial example of why the timing is good to do such a
thing, were one to look at the Tao, one would see that it does not even
list the current set of IETF areas, nor does it have contacts for those
areas.  There are other issues.  Same holds true for the new work
tutorial from IETF 81.  Fine documents when they were written, but time
as passed.

The role of the IAB could also use a dusting off here.  For instance,
should one have to wait for a bof to get a shepherd out of the IAB? 
Should the IAB members themselves have to perform that role or could
they perhaps make use of program members or other members of the
community to assist?

By taking this broader approach it helps to start from the position of a
new participant who has some bright idea and is trying to figure out a
road to success.  Having both positive and negative examples would
help.  A lot.

Yes, this is more work.  No, you probably don't have the time.  You
might want to ask the community for help along these lines. 

Eliot

On 10/11/17 3:21 PM, Spencer Dawkins at IETF wrote:
> ability to charter new work as soon as it’s ready and ensure proposals
> have the resources needed for success. We want to share our
> expectations about BOF requests and new work proposals with the
> community because we are interested in feedback. 
>
>
> We ask for feedback, either on the IETF Discussion List (so, replies
> to this note are fine), or optionally, to the IESG at [email-masked]
> <mailto:[email-masked]>. We would like to put this in place soon after
> IETF 100.
>
>
> We would like to see earlier notice about proposals for new work, and
> more attention to specific work products in proposals.
>
>
> *** Earlier notice to ADs about proposals for new work to enable
> better support and improving chances of success
>
>
> We ask that proponents provide BOF requests and proposals for new work
> as early as possible so that your area directors can begin evaluating
> these requests long before our coordination call with the IAB each
> IETF meeting cycle. 
>
>
> Earlier notice about new work proposals will give area directors more
> time to provide direction, to involve other IETF participants with
> relevant backgrounds and related interests, and to confirm whether a
> BOF would be required to consider a proposal for new work.
>
>
> Earlier notice about new work proposals will also give area directors
> more time to request that the IAB provide BOF shepherds to help
> improve BOF requests, when that is appropriate, and more time for BOF
> shepherds to help to improve the BOF proposal. 
>
>
> The IESG has received some BOF requests that describe interesting
> problems at considerable length but do not clearly identify what the
> BOF proponents want the IETF to do. When that happens, we cannot
> approve a BOF intended to form a working group.
>
>
> In some cases, area directors might approve a non-WG-forming BOF to
> tease out the details of the BOF proposal, but often that isn’t the
> best way forward. However, we also want to put ideas in front of the
> IETF community early in the process, in order to gauge community
> interest and feasibility. 
>
>
> The BOF Wiki at https://trac.tools.ietf.org/bof/trac/wiki, where we
> collect BOF requests for each upcoming IETF meeting cycle, will be
> using this template:
>
>
> Proponents are encouraged to add new entries in the BoF wiki even if
> they don't have all information that the template is asking for yet.
> The entry can be modified until the Cut-off date for BOF proposal
> requests to Area Directors, which is available from
> When writing the description, the IESG strongly encourages BOF
> proponents to focus on the work that would be reflected in an approved
> working group charter. What we are looking for is:
>
>
> We prefer that BOF proponents do this mapping, and gap analysis,
> rather than relying on the IESG, the IAB, and the broader community.
> That will help us make better decisions more quickly about approving
> BOFs, and to charter new work more quickly, that produces solutions
> more quickly. As we said in "Support Documents in IETF Working Groups"
> [2], 
>
>
> "In order to speed up the time period from idea to running code, the
> IESG supports working groups that commence solution work early in the
> working group timeline, and do not wait for completion and publication
> of the support documents. When the problem scope is well understood
> and agreed upon, charters focused on solutions work are extremely
> efficient."
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Oct 2017 09:39:10 -0400

Eliot Lear <[email-masked]> wrote:
    > The role of the IAB could also use a dusting off here. For instance, should
    > one have to wait for a bof to get a shepherd out of the IAB? Should the IAB
    > members themselves have to perform that role or could they perhaps make use
    > of program members or other members of the community to assist?

To respond to this specific question.

I was really pleasantly surprised when I first observed the IAB shepherds at
work.  They were awesome: patient and constructive and really really useful.
They removed a whole lot of potential flame wars that would have been about
process, but would have sounded like technical objections to a newcomer.

Why were they able to do this?  Because the shepherds:
  1) had been WG chairs.
  2) had started new work.
  3) had written documents and experienced the entire process
  4) had visible marks of authority, lending weight to a newcomer unfamiliar
       with our internal symbols of merit(ocracy).
  5) maturity to be able to put their own views/feelings aside and mediate
     among differing interests

It's unlikely that someone can become an IAB member without (1),(2),(3).
So, the IAB badge important for (4) is the communities' agreement that you
have 1-3.   There are many other people who have 1-3, including, of course,
former IAB members.

[I've purposely said nothing about (5), and anyway I added the point when
re-reading my email]

Some years ago, Klensin had half-humourously proposed the grey-beard club
(offering prostetic beards to those the lacking the right balance of hormones
to grow facial hair).  While the name might be improved upon, the essential
concept, and the idea of staffing in essentially the way Klensin proposed is
good.

So my answer is that the IAB has to continue to do this themselves.  That it
can leverage former IAB members once it finds a way to make them externally
recognizable (a badge of some kind), and/or Klensin's club becomes official.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 12 Oct 2017 08:52:43 -0500

Hi,

On Thu, Oct 12, 2017 at 2:44 AM, Eliot Lear <[email-masked]> wrote:

> IETF.
Oh, thank you for the feedback!

I'm answering only for myself - the IESG agreed to send the first message
in this thread, and I've been chatting with a smaller collection of ADs
about the details, but obviously I haven't talked with anyone else before
responding.

> The note is a good start, but let me ask a question:  Our working methods
> are evolving.  Should your note be focused on bofs or on new work as a
> whole?
>
This note started out focused on BOF ideas that resulted in BOF requests,
and broadened to include the idea that some BOF requests would be
revectored into existing working groups, but did not go as far as "so,
you've got an idea ..."

I note your point below that it may also be time to work on "so, you've got
an idea".

> For instance, is it worth doing a broader message that answer some more
> general questions, like these:
>
>    - How best to determine which area to bring work to in the first place?
>
> I've been telling people that a bunch of the ideas we see now span at
least two areas(*), so I'm wondering what we can do to handle these ideas
more efficiently.

We didn't try to address that in our pre-IETF 100 note, but it's on my list.

(*) TCPINC would be the canonical example - IIRC, we waited until we had
that charter out for review before making what turned out to be the final
decision to proceed in TSV, and not in SEC, but it really was a tough call
for the ADs involved.

>
>    - How can the IESG facilitate nascent ideas prior to their entering
>    presentation at one of the area meetings, etc) and how to arrange for these
>    activities?
>    - When to use a bof and when to use a wg like dispatch (or perhaps
>    secdispatch)?
>
> I suspect that practice among areas differs too much to allow much
guidance on this, although whether we could differ less and do better is a
reasonable question. Note that https://tools.ietf.org/html/rfc7957 was an
effort to make the RAI/ART DISPATCH process less area-specific, and two of
the three authors are sitting ADs today, so we're equipped to have that
conversation if the community wanted to have it.

>
>    - When to (not) approach an AD to do AD-sponsored work?
>    - Can one make use of shepherds and what is their role?
>
> The IESG has verified with the IAB that the IAB's commitment is still
https://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/,
which includes providing shepherds.

>
>    - What to do when you believe you've hit a wall.
>
> As perhaps a trivial example of why the timing is good to do such a thing,
> were one to look at the Tao, one would see that it does not even list the
> current set of IETF areas, nor does it have contacts for those areas.
> There are other issues.  Same holds true for the new work tutorial from
> IETF 81.  Fine documents when they were written, but time as passed.
>

If this wasn't clear - the IESG's goal is to get visibility on proposals
for new work as soon as possible, and one of the stated reasons is to
provide better guidance earlier in the process. That includes, but is not
limited to, requesting IAB shepherds. So, the current answer is "no, you
shouldn't have to wait".

> Should the IAB members themselves have to perform that role or could they
> perhaps make use of program members or other members of the community to
> assist?
>

That's a very reasonable question for the IAB. One assumes that the IAB and
IESG would talk (it's not like there aren't past members of each body
sitting on the other body, and that's ignoring overlapping chair membership
and liaison representatives in both directions, which ought to be enough
bandwidth to talk anyway).

> new participant who has some bright idea and is trying to figure out a road
> to success.  Having both positive and negative examples would help.  A lot.
>

So, this probably lays out in two dimensions - positive and negative
examples.

For positive examples, ISTM that at the very minimum, we could point to
working groups like TRAM, that didn't even require a BOF before sending a
proposed charter to the community for feedback. There's probably more we
could say.

For negative examples, it would be better if proponents volunteered their
own experiences. I believe some would be willing to do so (I was a
proponent for a BOF where the feedback included "the AD should be recalled
for approving that BOF, and the proponents should be arrested for proposing
it", so there's at least one example that could be included).

> Yes, this is more work.  No, you probably don't have the time.  You might
> want to ask the community for help along these lines.
>

Yeah, this also lays out in two dimensions - when we change what we do, and
when we document what we are already doing.

I was focusing on what the IESG plans to do differently, and that is harder
to delegate, but we ABSOLUTELY could ask for help in documenting what we're
already doing, and I'd bet the community would be better served if that
happened.

Speaking only for myself, of course. Mileage for other ADs may vary.

Spencer

> this note are fine), or optionally, to the IESG at [email-masked]. We
> would like to put this in place soon after IETF 100.
>
>
> collect BOF requests for each upcoming IETF meeting cycle, will be using
> this template:
>
>
> Directors, which is available from https://ietf.org/meeting/
> important-dates.html.
>
>
> [1] https://www.iab.org/documents/correspondence-reports-
> documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Oct 2017 08:44:40 +1300

Spencer,

On 12/10/2017 02:21, Spencer Dawkins at IETF wrote:
> the resources needed for success.

I pretty much support the proposed approach as far as WG-forming BOFs
are concerned; and I think we should also support the IESG's right to
Just Say No too. I've been amazed for years by this apparent constant
of nature: the number of IETF WGs is approximately 120. Why?

However:
...
> forward.

This bothers me, because it makes non-WG-forming BOFs sound like second
class citizens, and I think that's wrong. A non-WG-forming BOF has two
possible outcomes (in general terms):

1. There's something here that seems to need doing. Start working towards
a WG-forming BOF.

2. There's nothing coherent here. Forget about it for now, as far as
the IETF is concerned. (There may be subsidiary outcomes here, like
suggesting some IRTF activity, but as far as IETF resources go, it's
over.)

Both of these are good outcomes from the IETF's viewpoint.

    Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 12 Oct 2017 15:28:45 -0500

Hi, Brian,

On Thu, Oct 12, 2017 at 2:44 PM, Brian E Carpenter <
[email-masked]> wrote:

> have

I assumed it was a natural law :-) ...

> problems
> class citizens, and I think that's wrong.

Then the text is giving the wrong impression. My apologies for that.

I think they're important.

Every area is different, but in TSV, I've approved about as many
non-WG-forming BOFs as WG-forming BOFs. They're not consolation prizes.

> A non-WG-forming BOF has two

I'd broadly agree, with a couple of additions.

It's worth reminding the community that BOFs aren't required to form a
working group, so I think this is "start working towards a new (or revised)
charter, and that might lead to a WG-forming BOF, or to a charter that is
ready to be approved without a BOF".

I've been saying for a while that much of the new work proposals we see
that's interesting, spans working groups and even areas, so I think this is
"one or more new or revised charters".

> suggesting some IRTF activity, but as far as IETF resources go, it's

I agree, and "for now" is important. Even in the BOF wiki, we say "not
approved for this IETF", rather than "rejected until the end of time". If
the outcome should change at some point in the future, we're listening.

> +1.

Spencer

---

From: George Michaelson <[email-masked]>
Date: Thu, 12 Oct 2017 15:29:05 -0700

I think we should enforce proscriptive end of life. WG should be cheap
to spin up, short lived, and killed early. We want a coppice, not a
redwood forest.

What we do now, is we breed WG and associated chairs as long lived
redwood trees and they shade the forest floor killing off new growth.

If we couple that with forced WG chair selection by rote, we'd soon
get to the nub of the matter.

On Thu, Oct 12, 2017 at 1:28 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
> Hi, Brian,
>
> On Thu, Oct 12, 2017 at 2:44 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>
>> Spencer,
>>
>> > tease

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Oct 2017 18:54:30 -0400

Floggings will continue until morale improves!

Killing a wg before it's done is also bad. I think we should trust the iesg
to do that when it's time.

On Oct 12, 2017 18:29, "George Michaelson" <[email-masked]> wrote:

On Thu, Oct 12, 2017 at 1:28 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
>> > want the IETF to do. When that happens, we cannot approve a BOF
intended
>> > to

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Oct 2017 06:35:39 +0100

We need a contingency approach.

One size does not fit all!

Stewart

Sent from my iPad

> On 12 Oct 2017, at 23:54, Ted Lemon <[email-masked]> wrote:
> 
> Killing a wg before it's done is also bad. I think we should trust the iesg to do that when it's time. 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Oct 2017 13:23:41 -0400

> "one or more new or revised charters".

I am of the opinion that the decision as to which area it belongs in is among
the lowest order bits of the decision, particularly in light of ADs may
manage groups outside of their area.

To me the AREA tag only really determines some bits of culture (which is
slightly different across areas), and some minor assumptions about conflict
scheduling.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Oct 2017 13:24:47 -0400

George Michaelson <[email-masked]> wrote:
    > I think we should enforce proscriptive end of life. WG should be cheapy

And ressurect!
I like your forest analogy.

---

From: "tom p." <[email-masked]>
Date: Sat, 14 Oct 2017 12:43:29 +0100

----- Original Message -----
From: "George Michaelson" <[email-masked]>
To: "Spencer Dawkins at IETF" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 12, 2017 11:29 PM

<tp>
mmmmm so you would kill IDR, ISIS, CCAMP, MPLS, NETCONF, NETMOD, v6ops,
OPSAWG,  TCPM, PCE ....

I would have rather a quiet life!

Tom Petch

intended

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Oct 2017 08:17:57 -0400

> community because we are interested in feedback.

So I understand the scope of this request for feedback to be about 
improving IESG's ability to charter new work, and that's an admirable 
goal on IESG's part.

However, I wonder if IESG has come to think of the purpose of BOFs as 
being to lead to new WG charters in the short term.   If true, I think 
it's unfortunate.

One of IETF's biggest problems IMO is the tendency to silo work, to fail 
to recognize when there is a need for broadly applicable work rather 
than point solutions.   This in turn leads to a great deal of 
unnecessary complexity in network code and applications, and a 
tremendous amount of wasted effort.   The resulting tendency is to 
produce too many working groups, too many standards documents, and 
standards documents with too-limited scope or applicability.

Note that I said this is IETF's problem, not specifically IESG's 
problem.   But I see essentially no effort within IETF to try to 
identify common ground between different concerns, or to look for 
opportunities to address multiple concerns with a common framework.   
And it's much easier to do this before working groups are chartered, 
than after.   IAB has sometimes tried to do this by holding meetings, 
but the meetings have seemed fairly exclusive (there are high barriers 
to participation) and also have taken a long time to produce results.

I'd like to see an effort to encourage IETF participants in general (not 
just a few handpicked people) to think more broadly.   I'd like to see 
more meeting time devoted to identifying common ground and opportunities 
for more broadly applicable work.   Such efforts should NOT be expected 
to propose working groups, at least not in the near term.   It's fine if 
they do, but the expectation should not be there.   And I don't care 
what such sessions are called, but I think BOFs were originally supposed 
to be able to serve such purposes.

And maybe IESG is too busy to charter them, because it needs to be 
focused on working groups.   Maybe that should be left to IAB or some 
committee appointed for that purpose.   But there should be a clearly 
visible path by which IETF participants can request such sessions.

Keith

p.s. It is tempting, if the only tool you have is a working group, to 
treat every problem as if the solution were more protocol specifications.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Oct 2017 20:51:50 +0200

Hi,

> manage groups outside of their area.

Except that you have to start somewhere.  And our documentation isn't up
to date.

Eliot

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Oct 2017 08:51:58 -0500

Hi, Eliot,

> Except that you have to start somewhere.  And our documentation isn't up

Could you say more about that? It sounds like something needs to be fixed.

Thanks,

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Oct 2017 16:18:00 +0200

Hi Spencer,

> Could you say more about that? It sounds like something needs to be fixed.

Yes, the Tao needs a dust off.[1]  See Section 2.2.2 of that document. 
There are probably other areas that need work.  Similarly, "Bringing New
Work into the IETF"[2] needs a dust off* (see slides 6 and 7).   I will
also add that these documents are not exactly prominent, either on our
current web site or on beta.ietf.org.  Might I suggest that "Getting
Involved" be just a bit more prominently featured?

Eliot
[1] https://www.ietf.org/tao.html
[2] https://www.ietf.org/edu/documents/81IETF-New-Work.pdf
* (Both of these works were fine documents and remain mostly fine, and
it was awfully generous of those who put them together to have done so).

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 Oct 2017 10:22:42 -0400

Hi Keith,

On Sat, Oct 14, 2017 at 8:17 AM, Keith Moore <[email-masked]>
wrote:

> improving IESG's ability to charter new work, and that's an admirable goal
> on IESG's part.
>
> being to lead to new WG charters in the short term.   If true, I think it's
> unfortunate.
>
> to recognize when there is a need for broadly applicable work rather than
> point solutions.   This in turn leads to a great deal of unnecessary
> complexity in network code and applications, and a tremendous amount of
> wasted effort.   The resulting tendency is to produce too many working
> groups, too many standards documents, and standards documents with
> too-limited scope or applicability.
>

Yes, I agree.  In routing, there are more targeted point solutions - partly
because the general protocols aren't sufficient, partly because proponents
are interested in one domain, and partly because it is incredibly hard to
join different solutions together or select one after work has started.

Note that I said this is IETF's problem, not specifically IESG's problem.
> But I see essentially no effort within IETF to try to identify common
> ground between different concerns, or to look for opportunities to address
> multiple concerns with a common framework.   And it's much easier to do
> this before working groups are chartered, than after.   IAB has sometimes
> tried to do this by holding meetings, but the meetings have seemed fairly
> exclusive (there are high barriers to participation) and also have taken a
> long time to produce results.
>
> just a few handpicked people) to think more broadly.   I'd like to see more
> meeting time devoted to identifying common ground and opportunities for
> more broadly applicable work.   Such efforts should NOT be expected to
> propose working groups, at least not in the near term.   It's fine if they
> do, but the expectation should not be there.   And I don't care what such
> sessions are called, but I think BOFs were originally supposed to be able
> to serve such purposes.
>

As Spencer mentioned, the challenging ideas tend to touch on multiple areas
or be so broad as to be hard to break down to concrete work items.  How do
we, the IESG, encourage proponents and others to do the map-and-gap wok and
describe the framework that is more broadly applicable?  Since I started on
the IESG, we've pushed back against unnecessary "process" or information
documents such as too many/poor use-cases, architectures, frameworks, and
requirements - but it feels like those are what is needed to adequately
explain and map the space for more broadly applicable work.  What happens
if a BoF isn't sufficient to help that work happen?
Does it make sense to charter WGs just focused on the map-and-gap?   What
about applicability?

Regards,
Alia

> And maybe IESG is too busy to charter them, because it needs to be focused
> on working groups.   Maybe that should be left to IAB or some committee
> appointed for that purpose.   But there should be a clearly visible path by
> which IETF participants can request such sessions.
>
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Oct 2017 11:36:57 -0400

>> I'd like to see an effort to encourage IETF participants in general (not just a few handpicked people) to think more broadly.   I'd like to see more meeting time devoted to identifying common ground and opportunities for more broadly applicable work.   Such efforts should NOT be expected to propose working groups, at least not in the near term.   It's fine if they do, but the expectation should not be there.   And I don't care what such sessions are called, but I think BOFs were originally supposed to be able to serve such purposes. 
> 
> As Spencer mentioned, the challenging ideas tend to touch on multiple areas or be so broad as to be hard to break down to concrete work items.  How do we, the IESG, encourage proponents and others to do the map-and-gap wok and describe the framework that is more broadly applicable?  Since I started on the IESG, we've pushed back against unnecessary "process" or information documents such as too many/poor use-cases, architectures, frameworks, and requirements - but it feels like those are what is needed to adequately explain and map the space for more broadly applicable work.  What happens if a BoF isn't sufficient to help that work happen?
> Does it make sense to charter WGs just focused on the map-and-gap?   What about applicability?
> 
> Regards,
> Alia

Working groups are good at identifying and fixing bugs, holes, and edge cases, but bad at architecture and design.  So I think I'd recommend having a BOF to introduce the topic, and requesting that individuals or small groups of people submit proposals via Internet-draft.  Then plan to hold another BOF at a subsequent meeting, if there are any proposals, to discuss those proposals.  Repeat as necessary until there's a sense that there's a viable path forward (at which point it's time to charter a working group), or until no progress is being made. 

Keith

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Oct 2017 12:05:24 -0500

Keith has tagged the tension here. That's worth a specific mention.

On Mon, Oct 16, 2017 at 10:36 AM, Keith Moore <[email-masked]>
wrote:

> As Spencer mentioned, the challenging ideas tend to touch on multiple
> areas or be so broad as to be hard to break down to concrete work items.
> How do we, the IESG, encourage proponents and others to do the map-and-gap
> wok and describe the framework that is more broadly applicable?  Since I
> started on the IESG, we've pushed back against unnecessary "process" or
> information documents such as too many/poor use-cases, architectures,
> frameworks, and requirements - but it feels like those are what is needed
> to adequately explain and map the space for more broadly applicable work.
> What happens if a BoF isn't sufficient to help that work happen?
> Working groups are good at identifying and fixing bugs, holes, and edge
> cases, but bad at architecture and design.  So I think I'd recommend having
> a BOF to introduce the topic, and requesting that individuals or small
> groups of people submit proposals via Internet-draft.  Then plan to hold
> another BOF at a subsequent meeting,
>

If you do what https://tools.ietf.org/html/rfc5434#section-2 suggests,

   It is also important to recognize the timing constraints.  As
   described in detail below, the deadline for scheduling BOFs is
   approximately six weeks prior to an IETF meeting.  Working backwards
   from that date, taking into consideration the time required to write
   drafts, have public discussion, allow the ADs to evaluate the
   proposed BOF, etc., the right time to start preparing for a BOF is
   almost certainly the meeting prior to the one in which the BOF is
   desired.  By implication, starting the work aimed at leading to a BOF
   only 2 months prior to an IETF meeting is, in most cases, waiting too
   long, and will likely result in the BOF being delayed until the
   following IETF meeting.

That's roughly four months from first contact to first BOF. If this is a
"big project", assume that one's not working group-forming, but launches
investigations that result in a second BOF. So, now, 8 months from first
contact to second BOF.

If an effort doesn't coalesce in one IETF meeting cycle, that's now coming
up on a year from first contact to second BOF. I note that both TEEP and
FUD/SUIT fall into this category (requested for IETF 98, approved as
WG-forming for IETF 100), so that's not an unusual path forward.

I've been saying to the IESG that if we want to finish work sooner,
changing the way we doing things so we can start that work sooner seems
like the most obvious change we can make.

That's why (speaking only for me) I'm hoping that some proposals can be
chartered based on maps and gaps and a charter proposal, which might or
might not require a BOF.

That's why (speaking for the IESG) we want to find out about BOF proposals
early enough to steer (in a helpful way).

And thanks for the feedback. I am watching, even if I don't reply to every
e-mail in this thread.

Spencer

> if there are any proposals, to discuss those proposals.  Repeat as
> necessary until there's a sense that there's a viable path forward (at
> which point it's time to charter a working group), or until no progress is
> being made.
>
> Keith
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Oct 2017 08:35:53 +1300

> Involved" be just a bit more prominently featured?

There are also a number of fixes pending in [3]. I sort of went on strike
about maintaining it when we were promised that the new web site was almost
ready, so it hasn't been updated since 2015-08-25. Just to give an idea
of the rate of churn in process-related documents, here's the list of
pending updates since then:

      RFC 7649, The Jabber Scribe Role at IETF Meetings
      BCP 25, RFC 7776, IETF Anti-Harassment Procedures
      BCP 101, RFC 7691, Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members
      BCP 205, RFC 7942 on Improving Awareness of Running Code: The Implementation Status Section
      BCP 97, RFC 8067 on Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level
      BCP 14, RFC 8174 on RFC 2119 Key Words: Clarifying the Use of Capitalization
      BCP 79, RFC 8179 on Intellectual Property Rights in IETF Technology
      BCP 26, RFC 8126 on Guidelines for Writing an IANA Considerations Section in RFCs

Brian

[3] https://www.ietf.org/about/process-docs.html

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Oct 2017 20:00:35 -0400

On 10/16/2017 01:05 PM, Spencer Dawkins at IETF wrote:

> On Mon, Oct 16, 2017 at 10:36 AM, Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>         I'd like to see an effort to encourage IETF participants in
>>         general (not just a few handpicked people) to think more
>>         broadly.   I'd like to see more meeting time devoted to
>>         identifying common ground and opportunities for more broadly
>>         applicable work.   Such efforts should NOT be expected to
>>         propose working groups, at least not in the near term. It's
>>         fine if they do, but the expectation should not be there.  
>>         And I don't care what such sessions are called, but I think
>>         BOFs were originally supposed to be able to serve such purposes.
>>
>>
>>     As Spencer mentioned, the challenging ideas tend to touch on
>>     multiple areas or be so broad as to be hard to break down to
>>     concrete work items.  How do we, the IESG, encourage proponents
>>     and others to do the map-and-gap wok and describe the framework
>>     that is more broadly applicable?  Since I started on the IESG,
>>     we've pushed back against unnecessary "process" or information
>>     documents such as too many/poor use-cases, architectures,
>>     frameworks, and requirements - but it feels like those are what
>>     is needed to adequately explain and map the space for more
>>     broadly applicable work.  What happens if a BoF isn't sufficient
>>     to help that work happen?
>     Working groups are good at identifying and fixing bugs, holes, and
>     edge cases, but bad at architecture and design.  So I think I'd
>     recommend having a BOF to introduce the topic, and requesting that
>     individuals or small groups of people submit proposals via
>     Internet-draft.  Then plan to hold another BOF at a subsequent
>     meeting,
>
>
>    It is also important to recognize the timing constraints.
[...]
agree.   And I also agree that this tends to mean that the likely 
minimum time between "topic BOF" and "possible WG forming BOF" would be 
eight months.   But sometimes it will be a year or more, and sometimes 
there will be multiple topic BOFs, and sometimes there will never be a 
WG formed.  That should not be taken as an indication of failure.

Some things take time.  In particular, it takes time to develop 
mindshare between people with very different views of a problem; or 
alternatively, it takes time for someone to go and talk to people with 
lots of different views on a problem and synthesize a solution that 
attempts to consider all of their needs.

There are several pitfalls to avoid.

One pitfall is creating any expectation that topic BOFs and follow-on 
efforts will definitely lead to WG creation.   If someone can come up 
with a good solution that attracts broad interest, a WG should be 
created.  But there might be no solution, and there might be conflicting 
solutions where the conflicts aren't easily resolved - sometimes because 
a Major Player doesn't want a standard that competes with its 
proprietary and/or siloed solutions.

Another pitfall is the potential for people to torpedo such efforts - 
though I think it's harder to torpedo self-organizing design teams than 
it is to torpedo working groups.

Another pitfall is that "we're hoping we can find a common solution to 
these separate problems" can be taken as a threat of the form "we're not 
going to charter work on solutions to any of these separate problems 
until we see if someone can propose a common solution".   I'm not sure 
what the answer to that is, though it's not necessarily the case that a 
siloed WG will come up with a solution more quickly.  It's amazing how 
long WGs can sit in FIN-WAIT.   So maybe let the siloed WGs spin up too 
and invite people to come up with a more general solution before they 
finish?    Not sure.

> changing the way we doing things so we can start that work sooner 
> seems like the most obvious change we can make.

"sooner" may not be the best definition of the goal.  IETF produces many 
more RFCs these days than it did in the late 1990s with many fewer 
regular meeting attendees.   Some of the difference is in remote 
participation, but some of it is in the work being fragmented - 
producing more RFCs many not be an improvement if those RFCs are less 
relevant/useful.

As far as I can tell, the biggest reasons for the delay are that the 
active participants are overtaxed.  WGs take on too many work items 
often without regard for how important those items are or how much 
energy there is to actually do the work.   There are too many documents 
being written and not enough reviewers.   People lack the energy and 
travel budget to revise drafts year after year and attend meeting after 
meeting when quite often there's very little feedback and thus very 
little sense of progress.   And because there's so little feedback, even 
the slightest bit of negative feedback (no matter how irrelevant or 
poorly informed) has to be taken as a serious threat.

In other words the problem might not be so much that it's hard to start 
a WG, as that it's hard to finish one.   Trying to narrow the focus to 
fewer efforts that are each more relevant might help.

Keith

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Oct 2017 19:21:39 -0500

Hi, Keith,

On Oct 16, 2017 19:00, "Keith Moore" <[email-masked]> wrote:

[...]
agree.   And I also agree that this tends to mean that the likely minimum
time between "topic BOF" and "possible WG forming BOF" would be eight
months.   But sometimes it will be a year or more, and sometimes there will
be multiple topic BOFs, and sometimes there will never be a WG formed.
That should not be taken as an indication of failure.

Some things take time.  In particular, it takes time to develop mindshare
between people with very different views of a problem; or alternatively, it
takes time for someone to go and talk to people with lots of different
views on a problem and synthesize a solution that attempts to consider all
of their needs.

One pitfall is creating any expectation that topic BOFs and follow-on
efforts will definitely lead to WG creation.   If someone can come up with
a good solution that attracts broad interest, a WG should be created.  But
there might be no solution, and there might be conflicting solutions where
the conflicts aren't easily resolved - sometimes because a Major Player
doesn't want a standard that competes with its proprietary and/or siloed
solutions.

Another pitfall is the potential for people to torpedo such efforts -
though I think it's harder to torpedo self-organizing design teams than it
is to torpedo working groups.

Another pitfall is that "we're hoping we can find a common solution to
these separate problems" can be taken as a threat of the form "we're not
going to charter work on solutions to any of these separate problems until
we see if someone can propose a common solution".   I'm not sure what the
answer to that is, though it's not necessarily the case that a siloed WG
will come up with a solution more quickly.  It's amazing how long WGs can
sit in FIN-WAIT.   So maybe let the siloed WGs spin up too and invite
people to come up with a more general solution before they finish?    Not
sure.

"sooner" may not be the best definition of the goal.

Agreed. I think it is *a* goal, and I know it's not the only goal.

IETF produces many more RFCs these days than it did in the late 1990s with
many fewer regular meeting attendees.   Some of the difference is in remote
participation, but some of it is in the work being fragmented - producing
more RFCs many not be an improvement if those RFCs are less
relevant/useful.

As far as I can tell, the biggest reasons for the delay are that the active
participants are overtaxed.  WGs take on too many work items often without
regard for how important those items are or how much energy there is to
actually do the work.   There are too many documents being written and not
enough reviewers.   People lack the energy and travel budget to revise
drafts year after year and attend meeting after meeting when quite often
there's very little feedback and thus very little sense of progress.   And
because there's so little feedback, even the slightest bit of negative
feedback (no matter how irrelevant or poorly informed) has to be taken as a
serious threat.

In other words the problem might not be so much that it's hard to start a
WG, as that it's hard to finish one.   Trying to narrow the focus to fewer
efforts that are each more relevant might help.

We certainly have more to talk about ...

Spencer

Keith

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Tue, 17 Oct 2017 02:57:54 +0000

I have long been surprised how tightly regulated BoFs are at the IETF, while I understand the thinking behind it, it still surprises me that such an open organization that doesn't even have "members" has a very regimented process for bringing people of shared interests together.

In Prague there was the ability to request and book a room for adhoc and non-official discourse and meetings.  This was a great idea and I'd like to see if done at every IETF.

The BoF process as it currently stands is a useful tool to share to the broader IETF community workgroup ideas that are fairly fleshed out, have an existing problem/solution/deliverable plan and an established set of proponents.

What they don't do is easy enable discussion, concept building, and proponent base building of new work that isn't as yet as clearly defined.

To put it another way: the current process is good at filtering, refining, and defining extensions of stuff we already do, but it's not conducive to new work that is not easily mapped to what we already have in progress.

Birds of a feather in many orgs serve as informal opportunities to float half backed ideas as well as problems you are encountering but done yet have formed solution proposals for.

It's often the vague problems and half baked ideas where the major new, useful, and interesting work come from, and that is one aspect we are currently missing.

The bookable adhoc rooms are a great start to enabling people to just get together and talk.  I encourage more of this based upon my personal positive experience in Prague.

Going beyond that there are a couple other ways to improve this stuff:

 o a way to announce adhoc meetings would be great, beyond blasting a generic email to either the main IETF list or to the attendees list.  Perhaps a calendar channel people can subscribe to to receive invites to the adhocs.

o some means to display in a public place the schedule of adhocs so people can look at the schedule of adhocs.   Perhaps a webpage and some space at the IETF meeting itself.

o some means to spin up ongoing communications with adhoc attendees and interested parties to share the adhoc discussion, and to build a community around the issue,problem
, or idea.

o a means to fast fail proposals, without discounting or ending discussion on the core problem/issue.

Part of this is like the way twitter builds on the fly communities with users abilities to define new hashtags and others ability to follow it. post to it ,and to retweet posts to it.

It's the easy, low cost, fast fail ability of new communities which is useful in capturing and growing news ideas that we would benefit from.

-glenn 

Sent from my iPad