Subject: Re: When presentations are a good idea (Re: IETF logistics)

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Jan 2001 13:37:44 -0500

>>>>> "Fred" == Fred Baker <[email-masked]> writes:
    Fred> discussion: present the issues that need to be hashed out, propose and 
    Fred> explain approaches, and generally lead the working group towards useful 
    Fred> consensus. If we were handfuls of engineers, we would use white boards to 
    Fred> hash out ideas; in groups of 500, you need something you can project to 
    Fred> accomplish the same thing. Presentations are that engineer's white board; 
    Fred> they should contribute to the discussion, but not replace it.

  White boards are interactive.  (i.e. one can draw on them in response to
a question, pass the marker on, etc.)

  PPT files are neither standard nor particularly interactive.

  Opening a good HTML editor with a "publish" button would also be better. 

  We really should be using "wb" so that the multicast can just pick that up. 

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jan 2001 09:33:19 -0800

At 11:59 PM 12/21/00 -0800, Fred Baker wrote:
>What we unfortunately commonly find is presentations *instead*of* 
>discussion. That's what people are being concerned about and saying is wrong.

Hence:

1.  IETF meetings should not be used for transmitting "news" that is 
relevant to the working group; use the list.

2.  IETF meetings should not be used for introducing ideas or 
specifications; use the list.

3.  If there is confusion or contention about something discussed on the 
list, THEN it is reasonable to make a presentation on the topic, attempting 
to provide clarification and coherence and as a basis for meeting discussion.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 3 Jan 2001 12:44:53 -0800

>relevant to the working group; use the list.

Right.

>specifications; use the list.

There are times where meetings can better for "introducing ideas" 
than the mailing lists are. If people in a WG think that the WG 
should attack a new problem, and many people have proposed solutions 
for that problem, hearing three different presentations of the 
problem and proposed solutions in a face-to-face meeting can be 
useful. On mailing lists, statements of problems that come with 
proposed solutions often devolve into confusion between the realness 
of the problem and the goodness of one of the proposed solutions. The 
IPsec WG dealt with this a few times last year with the keep-alive 
and the IPsec-through-NATs issues.

Agree on not using meetings for introducing new specs.

>3.  If there is confusion or contention about something discussed on 
>the list, THEN it is reasonable to make a presentation on the topic, 
>attempting to provide clarification and coherence and as a basis for 
>meeting discussion.

Right.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jan 2001 14:56:26 -0800

for reference, the rules I'm phrasing are intended to capture the rather 
strong consensus about needing to be extremely efficient with meeting 
time.  my own observation is that it is sometimes acceptable for a group to 
be less efficient.

however it is clear that the problem with meeting time is frequent and 
broad and serious enough to warrant starting with some rather severe 
rules.  those are what I'm trying to phrase.

At 12:44 PM 1/3/01 -0800, Paul Hoffman / IMC wrote:
>There are times where meetings can better for "introducing ideas" than the 
>mailing lists are. If people in a WG think that the WG should attack a new 
>problem, and many people have proposed solutions for that problem,

"have proposed" means they did it first somewhere else, presumably on the list.

the premise to the rule is ALWAYS to make the list the FIRST venue, with 
meetings used ONLY after the list has proved problematic.

>On mailing lists, statements of problems that come with proposed solutions 
>often devolve into ...

often.  not always.  the rules would not prohibit comparative presentations 
at the meeting, under the scenario you describe.  rather, they simply 
require that presentation via the list be tried first, with the comparative 
presentations done only if necessary.

d/

=-=-=-=-=

---

From: Pete Resnick <[email-masked]>
Date: Wed, 3 Jan 2001 16:08:19 -0600

On 1/3/01 at 12:44 PM -0800, Paul Hoffman / IMC wrote:

>useful.

As you might have anticipated, I strongly disagree. Three internet 
drafts of the three different presentations of problem and proposed 
solution are completely appropriate. If there are questions about 
those I-Ds that need to be discussed in a face-to-face, that is 
perfectly acceptable. However, dog and pony shows are a waste of time 
and only serve to lend more support to the person with the prettier 
dog and pony. If you can't write your proposal down in an I-D 
effectively, then it's not going to go into an RFC effectively and we 
might as well not waste face-to-face meeting time on the proposal at 
all.

pr

-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated

---

From: Scott Brim <[email-masked]>
Date: Wed, 3 Jan 2001 18:29:53 -0500

On  3 Jan 2001 at 16:08 -0600, Pete Resnick apparently wrote:
> If you can't write your proposal down in an I-D 

Agree completely.  That's when you find a co-editor.  The ultimate goal
is not powerpoint.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jan 2001 16:26:43 -0800

just to be thorough, let's explore a non-trivial matter of effort.

To write a complete specification can be an enormous effort.  Having 
contenders always have to write complete specifications, before there is a 
choice among them, is wasteful.  Sometimes necessary, but not always.

We need some sort of intermediate (or partial) "specification" which 
provides enough detail for making choice among approaches, but does not 
require a complete effort.

Perhaps things like introduction and architecture, along with a proposed 
rest of the table of contents, and maybe some samples?

d/

=-=-=-=-=

---

From: Pete Resnick <[email-masked]>
Date: Wed, 3 Jan 2001 18:51:02 -0600

On 1/3/01 at 4:26 PM -0800, Dave Crocker wrote:

>To write a complete specification can be an enormous effort.
[...]
>Perhaps things like introduction and architecture, along with a 
>proposed rest of the table of contents, and maybe some samples?

Maybe I missed something, but since when did I-D's need to be 
complete specifications? An introduction and architecture alone would 
make a fine I-D and a fine starting place for WG discussion.

pr

---

From: Scott Brim <[email-masked]>
Date: Wed, 3 Jan 2001 19:56:35 -0500

> rest of the table of contents, and maybe some samples?

These things used to be called RFCs, then I-Ds.  Can't they still be I-Ds?

...Scott

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jan 2001 17:15:04 -0800

At 06:51 PM 1/3/01 -0600, Pete Resnick wrote:
>Maybe I missed something, but since when did I-D's need to be complete 
>specifications? An introduction and architecture alone would make a fine 
>I-D and a fine starting place for WG discussion.

excellent.  convergence.

indeed I was not trying to suggest anything knew, but to find a description 
that would help folks know what level of effort suits such a situation.

d/

=-=-=-=-=