Subject: Re: Interim meetings - changing the way we work

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 2 Mar 2015 12:58:31 -0600

I'm replying to Thomas's e-mail, but not particularly to Thomas - the
invitation is to anyone who can imagine "a better world" ...

If people want to keep leaning back on 10 year old process RFCs and arguing
> "well thats just the way we've always done things around here" then this
> organization is going to continue to slow its progress even more - and its
> descent into irrelevancy.  There are a lot of people here (myself included)
> that want to evolve things because they think the IETF still has a lot to
> offer the industry. But if the organization won't evolve, people will take
> the path of least resistance and go elsewhere as they have been doing if
> you haven't noticed.

As someone who has written a few BCPs that updated process docs that are at
least a decade old, I'd say, sure. But the best way to change things is to
write a draft proposing a change, and talk about it with people.

In the best case, people who can also imagine "a better world" will ask
awkward questions and make suggestions that will improve your proposal, and
things will get better for everyone, and we'll know how to manage the
updated process, etc.

The choices aren't binary (either engrave our process BCPs on an obelisk or
ignore them). I note that the Updates metadata for RFC 2026 says "Updated
by: 3667, 3668, 3932, 3979, 3978, 5378, 5657, 5742, 6410, 7100, 7127", and
that 2026 itself obsoleted 1602, which obsoleted 1310 (the title is "The
Internet Standards Process -- Revision 3", of course).

But please, give us something to consider that we can Last Call.

Spencer, as an AD who can sponsor proposals that make sense to him

---

From: Benoit Claise <[email-masked]>
Date: Mon, 02 Mar 2015 22:23:56 +0100

On 27/02/2015 16:03, t.p. wrote:
> Inline <tp>
>
> ----- Original Message -----
> From: "Thomas D. Nadeau" <[email-masked]>
> To: "Berger Lou" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, February 26, 2015 10:23 PM
>> On Feb 26, 2015:5:12 PM, at 5:12 PM, Lou Berger <[email-masked]>
> wrote:
>> Tom,
>> On 2/26/2015 4:48 PM, Thomas D. Nadeau wrote:
>>>> On Feb 26, 2015:4:30 PM, at 4:30 PM, Joel M. Halpern
> <[email-masked]> wrote:
>>>> Thomas, if participants who can not make the conference calls are
> obliged to listen to the full recordings to get the key points of what
> has happened, why, what are the questions, and similar issues that need
> to be visible to the WG, then we are not running an inclusive process
> that allows for participation by the range of individuals we need.
>>> That is the problem. We're really only geared to have full-on, in
> person meetings all the time. That does not lend itself to being
> flexible/agile.  That is not to say that I want to exclude anyone, but
> to be fair, if a subset of people want to move a pile of work forward,
> we shouldn't ENCOURAGE that behavior not stifle.
>> It sounds to that you are describing design team meetings (or, in some
>> cases, an authors meetings).  I'm not sure what makes folks think that
>> the only way folks can collaborate is via the mail list or full on
>> interim meetings.
> Yes.
>>>> There is a reason that the IETF distinguishes between design teams
> meetings, where the design team has to explain their work carefully to
> the WG, and working group meetings.  There has always been a problem of
> not getting as much context as we would like from the WG minutes.  But
> since we explicitly take all resolutions to the list, this is
> ameliorated by folks being able to ask for explanations, by those issues
> being taken to the list promptly, and by the fact that we only met 3
> times a year.  If you have bi-weekly calls and the WG can not tell what
> is going on with those calls, then what you have is a design team.  And
> then the folks involved need to own up to it as a design team,
> understand that they need to explain to the list what they have
> analyzed, their reasoning, and their conclusions.
>>> Design teams should be able to work asynchronously, but with fixed
> schedules and not have to have everything explicitly documented at every
> step.
>> 100% agree.
>>
>> I've been involved in many of such meetings (conf calls, webex, etc.)
>> and the key is that DT/authors' meetings need to be explained and
>> discussed on the list *at a time of their choosing*, which in my
>> experience is usually when a draft is published/updated.
>>
>>> If someone else is curious, they can get involved but not in order to
> slow things down or throw a monkey wrench into the works. If people want
> to keep leaning back on 10 year old process RFCs and arguing "well thats
> just the way we've always done things around here" then this
> organization is going to continue to slow its progress even more - and
> its descent into irrelevancy.  There are a lot of people here (myself
> included) that want to evolve things because they think the IETF still
> has a lot to offer the industry. But if the organization won't evolve,
> people will take the path of least resistance and go elsewhere as they
> have been doing if you haven't noticed.
>> This statement just confuses me as you note below we've always had
> ways
>> for folks to make progress fast -- when there's interest in doing so.
>> It just seems to me that many are enamored with interims and think
> it's
>> the sole/best way of demonstrating progress between full meetings.
>> Perhaps you're just saying that they're mistaken...
> Its not being enamored as much as it being one of the only
> obvious/acceptable vehicles to progress WG-level
> work forward - at least if the management is involved. In NETMOD for
> example, we've broken the interims into two "themes": Yang 1.1 work and
> modeling.  The former is like its own design team, and the latter is
> like many design teams coming to one place every other week.  The former
> not only meets every other week, but discusses issues on the list. But
> to the latter - that is more like a touch point for those subteams.
> Those subteams go off on their own for weeks at a time and iterate as
> needed. And they work without all of the overhead of a formal meeting.
> They may or may not discuss progress on the list until issues come up.
>
> <tp>
> Tom
>
> Take a small group of engineeers, expert in technology, get them to hold
> regular meetings focussed on a narrow range of topics and they can make
> faster progress, as you cite for 'netmod'.
>
> What is also likely to happen, and I see it with netmod, is that they
> will develop their own way of working, their own terminology, their own
> technology even, which de facto raises the bar for anyone else who wants
> to participate or to understand what happened.  They don't mean to
> exclude other people, they just do. (small groups, Psychology 101)
>
> I see 'netmod' as a poster child for this with its issue list, state
> machine for issues and so on.  Even though I was tracking the list when
> the 'Ynn' issue list was created, I don't know where its state machine
> came from.  In recent minutes, I don't know what
> "  AB: I am not sure YANG 1.0 specifies C1 explicitly somewhere.
>    JS: Does A3 not follow from A2?
>    KW: A3 is more a corollary of A2.
>    AB: The high-level problem is how to create and maintain the
>        information needed to achieve A4. "
>
> is about; a brief search of mailing list and I-Ds gave me no explanation
> for A2 to C1.
And what about an email to the NETMOD mailing list, asking this question?
How is this any different than meeting minutes on a physical meeting, on 
which you would have a question?

Regards, Benoit
>
> And if a different group of engineers works on different topics, then
> they will likely, in the absence of any guidance, use different
> technology, different terminology and end up with a way of working that
> is as alien to the first group.
>
> As I said, changing the way we work.
>
> Tom Petch
> </tp>
>
>
>
>
>
> --Tom
>
>
>> Lou
>>
>>> If you want a real example of how this can actually work, watch Anees
> explain how Open Config has done this with just weekly phone calls and a
> bunch of people typing on keyboards. They've done this in less than a
> year, and have rough consensus and (production) running code.  This is
> how the IETF used to operate: people got together, hacked code and got
> things working.  The goal was not having meetings, but producing code
> with rough consensus.
>>>
> https://code.facebook.com/posts/1421954598097990/networking-scale-recap
>>> --Tom
>>>
>>>
>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 2/26/15 4:21 PM, Thomas D. Nadeau wrote:
>>>>>> On Feb 26, 2015:4:16 PM, at 4:16 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>>>>> On 27/02/2015 09:08, Thomas D. Nadeau wrote:
>>>>>>>> On Feb 26, 2015:2:42 PM, at 2:42 PM, Benson Schliesser
> <[email-masked]> wrote:
>>>>>>>> Nico Williams wrote:
>>>>>>>>> Yes, but a record that a concall or other interim meeting took
> place,
>>>>>>>>> and who attended, even if there are incomplete or missing
> minutes, is
>>>>>>>>> important for IPR reasons.  Ensuring that such meetings are
> NOTE WELL
>>>>>>>>> meetings is (should be) a priority, and that includes ensuring
> that a
>>>>>>>>> record of that much exists.
>>>>>>>>>
>>>>>>>>> Ideally the concalls and other interims would be recorded.
>>>>>>>> I agree completely. My point was that meeting records (including
> minutes) will inevitably be incomplete, or possibly inaccurate, and that
> relying on the mailing list as an authoritative record is more
> effective.
>>>>>>>> Of course it is disappointing that we can't meaningfully
> translate voice discussions into text, in the minutes or in mailing list
> threads. If there were some magic tool e.g. that took better minutes
> then I'd be happy to use it. But otherwise, I think we just have to
> trust chairs to manage WG collaboration in whatever way is most
> effective for their WG's collaborators.
>>>>>>> The first step is to agree that an A/V recording is record
> enough.
>>>>>> It absolutely is not enough. Please see my previous message,
>>>>>> and the relevant rules in RFC 2418.
>>>>>>
>>>>>>   Brian
>>>>> You are missing my point. RFC or not, the IETF needs to evolve.
>>>>>
>>>>> --Tom
>>>>>
>>>>>
>>>>>
>>>>>>> Perhaps having meetbot/txt notes that at a min include
> actions/decisions like we do in the issue tracker we've used for
> NETMOD's Yang 1.1's issues.
>>>>>>> --Tom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> This will inevitably be suboptimal for some part of the
> population. (For instance, I've never been able to find an interim
> meeting time that fits the schedules of all attendees.) But if they (we)
> always revert to the mailing list for decision making then I suspect our
> work can remain open and transparent.
>>>>>>>> Cheers,
>>>>>>>> -Benson
>>>>>>>>
>>>>>>>>
>>
>>
>>
> .
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Mar 2015 20:41:44 -0800

> On 27/02/2015 16:03, t.p. wrote:
....

> which you would have a question?

IMO Juergen does a very good job of recording the minutes of every
NETMOD interim.
Here is the header from those minutes (that were taken out of context):

* YANG 1.1 Conformance
** https://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-00

This clearly indicates that the notes are about the draft identified above.
These identifiers A1, C2, etc. are in the draft.

The NETMOD and NETCONF WGs have been extra careful about
getting verification on the WG mailing list before proceeding with proposed
changes that originate in VI meetings.

> Regards, Benoit

Andy

---

From: Benoit Claise <[email-masked]>
Date: Thu, 05 Mar 2015 08:47:58 +0100

> changes that originate in VI meetings.
+100

Regards, Benoit

---

From: t.p. <[email-masked]>
Date: Thu, 5 Mar 2015 17:53:39 +0000

----- Original Message -----
From: "Benoit Claise" <[email-masked]>
To: "t.p." <[email-masked]>; "Thomas D. Nadeau"
<[email-masked]>; "Berger Lou" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 02, 2015 9:23 PM

> which you would have a question?

Benoit

Yes, I can do that, when I notice soon enough:-) But some time later,
wanting to know what was
agreed, that may not be feasible and that is what lies behind my
comment,
wanting to be able to look back and see what was agreed or not agreed,
and
how (and I do find myself doing that with the netmod WG, not often being
up
to date with its work).

My point too was that having got used to the netmod issue list (with its
state machine explained at the start of the list, and
identifiers of the form Ynn etc), this then appeared to be a new and
different way
of dealing with issues that I needed to get familiar with.  Sigh.

All making things that little bit harder to follow.

Tom Petch