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

[Spencer Dawkins at IETF <[e-mail]>]

Hi,

On Thu, Oct 12, 2017 at 2:44 AM, Eliot Lear <[e-mail]> 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 [e-mail]. 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
>
>
>