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

[Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx>]

Hi,

On Thu, Oct 12, 2017 at 2:44 AM, Eliot Lear <lear@xxxxxxxxx> wrote:

Hi Spencer,

Thanks to the IESG for focusing on how to better develop new work at the 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 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)?

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.

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? 

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

 

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.

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

 

Eliot

On 10/11/17 3:21 PM, Spencer Dawkins at IETF wrote:

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 iesg@xxxxxxxx. 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