Re: Newcomers at the IETF
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Newcomers at the IETF
Fred,
the idea of a newcomer briefing has a lot of appeal - we might
even go so far as to try to make this available in some on-line
form (hmm - I wonder if this is the equivalent of the story-teller,
minstrel who provided a kind of oral history; recast in modern
times...). Perhaps it would help to modulate the behavior of
folks who are new to the process.
All,
Does anyone on the list still remember when this was all new to them?
Would an introduction that talks about ietf cultures, stds procedures,
and the like have been helpful?
Vint
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00767;
25 Jul 92 7:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04646; 25 Jul 92 7:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21351>; Thu, 23 Jul 1992 07:24:10 -0700
Received: from kona.CC.McGill.CA by venera.isi.edu (5.65c/5.65+local-6)
id <AA21332>; Thu, 23 Jul 1992 07:23:56 -0700
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA21283 (mail destined for owner-ietf at isi.edu) on Thu, 23 Jul 92 10:21:52 -0400
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
id AA09868; Thu, 23 Jul 92 10:21:50 EDT
Message-Id: <9207231421.AA09868 at expresso.cc.mcgill.ca>
In-Reply-To: April Marine's message as of Jul 22, 10:41
From: Peter Deutsch <peterd at bunyip.com>
Date: Thu, 23 Jul 92 14:21:49 GMT-0:02
In-Reply-To: April Marine's message as of Jul 22, 10:41
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: April Marine <owner-ietf at isi.edu>,
Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: thoughts on the Boston meeting (and a joke...)
Cc: ietf at isi.edu
[ April Marine writes: ]
>
> I have a few quick thoughts/suggestions re IETF growth too.
>
> 1. Change the evening slot from 7-10 to 7:30-10, thus allowing at
> least as much time for dinner as lunch, and restricting the BOF
> slots to the longest amount of time given a WG during the day.
Hear, hear!
> 2. Ask the Area Directors to submit their summaries online to the IETF
> list rather than presenting them on Friday morning, thus allowing
> those who couldn't attend to see in a timely manner what happened.
> This would also free that time on Friday morning, into which we could
> offload a few WGs or the IESG plenary or something that would be more
> heavily attended than the summaries. The final summaries are currently
> very sparsely attended.
>
Yes! The working groups submit their minutes
electronically, and the Area Directors could do the same.
Given that there is no time allocated for discussion of
what they say anyways, I might as well read what they have
to say when my head has cleared and spend that time
becoming even more saturated... :-)
I would still think a brief "wrap-up" would be in order.
Maybe a 30-45 minutes report by Phil Gross on milestones
and administriva before the wrap is all we need.
> survey asking people why they are there and what they hope to
> accomplish during the IETF. This should be a short checklist
> format as someone suggested during the plenary, but with the
> aim of finding out just why people *are* there, which would help
> us to better figure out how to handle the growth.
I went on at length about my views on growth in my last
post, but I just want to repeat an old joke my dad is
fond of telling that seems relevant here.
"The nervous young lieutenant rushes into the captain's
cabin and cries out "Captain! Captain! We have a serious
problem down below!"
The Captain stops him in his tracks, and in a calm and
fatherly voice intones "Son, there are no problems, only
opportunities."
The young shavetail thinks about this for a moment,
swallows nervously and then says slowly "Well
Captain, then I guess we have a serious opportunity here."
The point? I guess the message I keep hearing is that
there is something inherently wrong with growth. There
isn't. It can be a great opportunity, if we can only
manage it properly. The job of the people in charge of the
process is to put all these new volunteers to work. If we
can't do that, it's not necessarily the fault of the
volunteers.
[* rest deleted *]
I found myself writing "I agree" after each paragraph, so
I'll stop now. Good piece, April.
- peterd
--
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00767;
25 Jul 92 7:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04646; 25 Jul 92 7:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21351>; Thu, 23 Jul 1992 07:24:10 -0700
Received: from kona.CC.McGill.CA by venera.isi.edu (5.65c/5.65+local-6)
id <AA21332>; Thu, 23 Jul 1992 07:23:56 -0700
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA21283 (mail destined for owner-ietf at isi.edu) on Thu, 23 Jul 92 10:21:52 -0400
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
id AA09868; Thu, 23 Jul 92 10:21:50 EDT
Message-Id: <9207231421.AA09868 at expresso.cc.mcgill.ca>
In-Reply-To: April Marine's message as of Jul 22, 10:41
From: Peter Deutsch <peterd at bunyip.com>
Date: Thu, 23 Jul 92 14:21:49 GMT-0:02
In-Reply-To: April Marine's message as of Jul 22, 10:41
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: April Marine <owner-ietf at isi.edu>,
Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: thoughts on the Boston meeting (and a joke...)
Cc: ietf at isi.edu
[ April Marine writes: ]
>
> I have a few quick thoughts/suggestions re IETF growth too.
>
> 1. Change the evening slot from 7-10 to 7:30-10, thus allowing at
> least as much time for dinner as lunch, and restricting the BOF
> slots to the longest amount of time given a WG during the day.
Hear, hear!
> 2. Ask the Area Directors to submit their summaries online to the IETF
> list rather than presenting them on Friday morning, thus allowing
> those who couldn't attend to see in a timely manner what happened.
> This would also free that time on Friday morning, into which we could
> offload a few WGs or the IESG plenary or something that would be more
> heavily attended than the summaries. The final summaries are currently
> very sparsely attended.
>
Yes! The working groups submit their minutes
electronically, and the Area Directors could do the same.
Given that there is no time allocated for discussion of
what they say anyways, I might as well read what they have
to say when my head has cleared and spend that time
becoming even more saturated... :-)
I would still think a brief "wrap-up" would be in order.
Maybe a 30-45 minutes report by Phil Gross on milestones
and administriva before the wrap is all we need.
> survey asking people why they are there and what they hope to
> accomplish during the IETF. This should be a short checklist
> format as someone suggested during the plenary, but with the
> aim of finding out just why people *are* there, which would help
> us to better figure out how to handle the growth.
I went on at length about my views on growth in my last
post, but I just want to repeat an old joke my dad is
fond of telling that seems relevant here.
"The nervous young lieutenant rushes into the captain's
cabin and cries out "Captain! Captain! We have a serious
problem down below!"
The Captain stops him in his tracks, and in a calm and
fatherly voice intones "Son, there are no problems, only
opportunities."
The young shavetail thinks about this for a moment,
swallows nervously and then says slowly "Well
Captain, then I guess we have a serious opportunity here."
The point? I guess the message I keep hearing is that
there is something inherently wrong with growth. There
isn't. It can be a great opportunity, if we can only
manage it properly. The job of the people in charge of the
process is to put all these new volunteers to work. If we
can't do that, it's not necessarily the fault of the
volunteers.
[* rest deleted *]
I found myself writing "I agree" after each paragraph, so
I'll stop now. Good piece, April.
- peterd
--
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00805;
25 Jul 92 7:44 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa05039; 25 Jul 92 7:44 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24967>; Thu, 23 Jul 1992 08:25:03 -0700
Received: from is.rice.edu ([128.42.42.24]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA24962>; Thu, 23 Jul 1992 08:24:56 -0700
Received: by is.rice.edu (AA27203); Thu, 23 Jul 92 10:22:02 CDT
From: "Evan R. Wetstone" <evan at is.rice.edu>
Message-Id: <9207231522.AA27203 at is.rice.edu>
Subject: Re: thoughts on the Boston meeting
To: April Marine <april at nisc.sri.com>
Date: Thu, 23 Jul 92 10:21:59 CDT
Cc: dcrocker at mordor.stanford.edu, ietf at isi.edu
In-Reply-To: <9207221741.AA17120 at phoebus.nisc.sri.com>; from "April Marine" at Jul 22, 92 10:41 am
X-Mailer: ELM [version 2.3 PL11]
A few thoughts on April's thoughts on the Boston IETF:
Point number one (changing the time slot of the 7-10 sessions) is an
excellent idea...I was at a few BOF's in that time-slot in which
a fair number of attendees had not had a chance to eat dinner. And there
were some in which I came in late because I couldn't make it back
from dinner in time....
The other ideas are also very good. I like the ideas of on-line summaries
of the area directorates and the survey. Until we know more about
the attendees, it will be difficult to come up with intelligent ways
of managing the growth.
And I wholeheartedly support point number 5, "WGs should be as open as
possible. Competent people do not appear ready-made; people grow to be
competent. The IETF should foster the growth of our future leaders."
If we try to limit (close) the WGs, we stand an excellent chance of
crippling ourselves down the road. It's important to keep a flow
of "new blood".
--
Evan Wetstone
Rice University/SESQUINET
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00830;
25 Jul 92 8:03 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa05291; 25 Jul 92 8:03 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25089>; Thu, 23 Jul 1992 08:28:30 -0700
Received: from iesl.mit.edu ([18.58.0.76]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA25084>; Thu, 23 Jul 1992 08:28:25 -0700
Message-Id: <199207231528.AA25084 at venera.isi.edu>
Received: from iesl-b.mit.edu by iesl.mit.edu id AA29739g; Thu, 23 Jul 92 11:31:10 EDT
Date: Thu, 23 Jul 92 11:31:10 EDT
From: Jim Culbert <culbert at iesl.mit.edu>
Received: by iesl-b.mit.edu (4.1/SMI-4.1)
id AA14795; Thu, 23 Jul 92 11:29:24 EDT
To: vcerf at NRI.Reston.VA.US
Cc: fbaker at acc.com, atkinson at itd.nrl.navy.mil, ietf at isi.edu, scott at ftp.com,
culbert at iesl.mit.edu
In-Reply-To: vcerf at NRI.Reston.VA.US's message of Wed, 22 Jul 92 14:49:25 -0400 <9207221449.ac02198 at IETF.NRI.Reston.VA.US>
Subject: Newcomers at the IETF (One account from a "real live one")
After sitting quitely listiening to the debate over newcommers to the
IETF for a while I figured that my contribution might be useful.
___
I have been involved in the development of distributed systems for
the last five years (the extent of my non-academic career). Over
the last two years I have been desigining and implementing systems
using OO techniques and languages. I have developed an OO communication
mechanism which about a year ago I started questioning "how this fits in".
Suffice to say that after about 8 months of haphazardly searching through
OSI information and OMG information (and doing my regular job ;) I came
accross what I was looking for; a group of people doing *real* work on the
topics that I felt would drive the future of information technology. Yes,
that would be the IETF.
Anyway, I plowed through this virtual gold mine of informaiton contained
in the online RFCs filling in the gaps in my understanding of the way the
internet world was built and works.
I was very impressed with what I had "discovered" and with the philosophy
and management that was evident in the organization.
So along comes this announcement on my newly subscribed ietf mailing
about this IETF thing. Given the tone of the announcement, I felt that
I might be "in the way" if I attended. I tried mailing
the list manager to find out whether it was appropriate for me to
attend but the end result was that I was uncertain and I opted not to
go.
Now after seeing the comments on the number of suits that attended and
the size of the meeting, I wish that I had gone. My major objectives in
attending are,
1) Find out how my work could fit into the grand scheme of things
2) Understand what the holes are in my knowledge about the Internet
3) Learn where I could meaningfully contribute to IETF work
I (believe that I) represent the "new generation", so to speak of,
computer/networking/information professionals. We are bound to be "neophytes"
to this technology as our professional careers are only just getting underway.
So while I agree that maintaing reasonable signal to noise in your process
is important, there needs to be a way for technical people like myself to
penetrate your ranks some how to determine how (and if) we can contribute.
I don't mean to be taking up your time just to hear myself talk, but
most of the comments I have seen on this list are from people who are
well familiar/established in the internet community and with the ietf
in specific. As people out there have been speculating as to what newcomers
to the ietf are faced with, I figured that I could give you a first hand
account about how one newcomer learned about your existence and the
questions that he is dealing with.
The post that finally prompted my response was from Vint Cerf which asked,
> Does anyone on the list still remember when this was all new to them?
> Would an introduction that talks about ietf cultures, stds procedures,
> and the like have been helpful?
In answer to the first question; Yes, I still am a newcomer. I remember it well.
In answer to the second question; Yes, an introduction "packet" with
the history, diagrams, etc, etc would helpful. I know information like
this exists in many of the RFCs but a current document with diagrams,
and names would help put this beast into perspective for those of
us not intimately familiar with it (its the same old blind-men-and-the-elephant
thing. Kinda fits in with your surfing elephant analogy :)
Anyway, hope this was useful information to somebody out there.
-Jim
===========================================================================
> Jim Culbert <
> Research Engineer <
> M.I.T Intelligent Engineering Systems Laboratory <
> Department of Civil Engineering <
> Room 1-270 <
> Cambridge, Ma. 02139. <
> <
> Phone (617) 253-7134 <
> e-mail: culbert at iesl.mit.edu <
===========================================================================
* When cows laugh does milk come out their nose? *
===========================================================================
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00872;
25 Jul 92 8:36 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa05760; 25 Jul 92 8:36 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25586>; Thu, 23 Jul 1992 08:39:16 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA25574>; Thu, 23 Jul 1992 08:39:11 -0700
Received: by ftp.com
id AA19715; Thu, 23 Jul 92 11:36:57 -0400
Date: Thu, 23 Jul 92 11:36:57 -0400
Message-Id: <9207231536.AA19715 at ftp.com>
To: Stef at nma.com
Subject: Re: thoughts on the Boston meeting
From: Frank Kastenholz <kasten at ftp.com>
Cc: dcrocker at mordor.stanford.edu, ietf at isi.edu
stef
the "call-for-contributions" idea is the way that we can deal with
large-scale efforts.
this may be one of the iab's major roles in life -- to identify
an area of the internet in which we have problems and issue such a
call. it is important, however, that such a call be made unambiguously.
many people have said that the "call" that produced smp was not made
clear enough.
a second problem is how do we deal with multiple contributions (ala the
current ipv7 effort)? in many cases we will have to look at all of the
contributions and pick one of them (e.g. when picking a common
interior routing protocol (the ospf vs is-is debate) there can only
be one such protocol, so one would have to win and the other lose).
making this decision may not always be easy -- there may not be a clear
"best" choice. i am concerned as to how we can do this. perhaps one of
the jobs of the w.g. as a whole would be to pare down the number of
contributions (e.g. "can you two merge your separate contributions into
one?").
> What is important is to find ways to adopt and shape this kind of
> contribution production behavior (the SMP contribution model) to
> provide us with regular ways to form ad hoc development groups which
> deliver contributions into the Open IETF Working Group Process.
perhaps the isb/iesg could determine that there is a need someplace
in the internet. they could write a call for contributions. a single w.g.
meeting could be held where the call would be made public and the
call "accepted" by the ietf (maybe even this could be done via email).
i think that it is important that a call itself be given a review by the
community (the general call for a new ip certainly has benefied by having
a public review of the iab's call that seemed to say "use clnp":-).
an alternate model is that someone goes off and does something and then
comes to the ietf and says "you had this problem and here is something
to fix it" -- in effect an unsolicited contribution. these contributions
must not be rejected because the iab did not first make a call for it.
it must be brought into the process, a working group formed, and so on...
--
frank kastenholz
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab00933;
25 Jul 92 9:31 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06560; 25 Jul 92 9:31 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA28816>; Thu, 23 Jul 1992 09:53:00 -0700
Received: from xap.xyplex.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA28806>; Thu, 23 Jul 1992 09:52:54 -0700
Received: by xap.xyplex.com id <AA06498 at xap.xyplex.com>; Thu, 23 Jul 92 14:49:50 -0500
Date: Thu, 23 Jul 92 14:49:50 -0500
Message-Id: <9207231949.AA06498 at xap.xyplex.com>
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: april at nisc.sri.com
Cc: ietf at isi.edu
In-Reply-To: April Marine's message of Wed, 22 Jul 92 10:41:02 PDT <9207221741.AA17120 at phoebus.nisc.sri.com>
Subject: Re: thoughts on the Boston meeting
At the open plenary, someone suggested that with all these intelligent people,
we MUST be able to solve some of these problems. As long as we're willing to
make some real changes, the good suggestions are certainly appearing, like
April's.
Allowing time for dinner and keeping slots the same size: fine idea. I came
to this IETF with a back problem, and spent a LOT of time in my room instead
of all the meetings I'd usually go to. I was booked solid for long sessions,
EVERY evening. My aching back, literally. It seemed the balance had shifted
to the evening sessions.
Area summaries on-line and freeing up Friday morning: another fine idea.
There were sure a LOT less than 700 people there for the summaries, and most
of the summaries were the speaker reading the slides to us, and people were
mostly too used up to ask questions. Open plenary Friday morning might be the
right thing.
Survey in next attendance packet? Yes! And include a mechanism for really
getting them filled out, like you can't get your badge until you do. (That's
approximately half serious.) It would be really really good to know what
people are looking for.
I agree that WG chairs are one of the keys to high quality productivity. It
is unfortunate that putting pressure on them will probably lose some, but I
don't see any other way. If you can find time to submit an agenda or new
drafts 5 minutes before you leave for the airport, why can't you just find
exactly that same time 2 weeks before? We need chairs that will run the
meetings fairly but firmly, and perhaps refuse to spend large amounts of time
in discussion that could have been avoided if people had simply read documents
that were submitted at least 2 weeks before the meeting.
April, good work.
Bob
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00951;
25 Jul 92 9:32 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06584; 25 Jul 92 9:32 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00409>; Thu, 23 Jul 1992 10:21:55 -0700
Received: from wc.novell.com ([130.57.64.11]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA00397>; Thu, 23 Jul 1992 10:21:48 -0700
Received: from localhost.wc.novell.com by wc.novell.com (4.1/smi4.1.1.v91190)
id AA19725; Thu, 23 Jul 92 10:18:59 PDT
Message-Id: <9207231718.AA19725 at wc.novell.com>
To: Fred Baker <fbaker at acc.com>
Cc: ietf at isi.edu
Subject: Re: IETF Structure
In-Reply-To: Your message of "Wed, 22 Jul 92 10:27:50 PDT."
<9207221727.AA09535 at saffron.acc.com>
Date: Thu, 23 Jul 92 10:18:58 -0700
From: minshall at wc.novell.com
Fred,
Two things:
First, on IETF and first time attendees: SHARE (the IBM users group) has
had "first time attendee" meetings. In addition (and, perhaps more
important) they affix some sort of visible indicator to first time
attendees' badges. Ostensibly, this is to allow old-timers to pick out
new people and provide them with some "mentoring".
Second, on your proposal for restructuring the IETF: I don't know what
problem you are trying to solve and, thus, would just as soon keep
things the way they are (in terms of structure).
Greg Minshall
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00975;
25 Jul 92 9:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07161; 25 Jul 92 9:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00561>; Thu, 23 Jul 1992 10:25:32 -0700
Received: from SAFFRON.ACC.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA00554>; Thu, 23 Jul 1992 10:25:26 -0700
Received: by saffron.acc.com (4.1/SMI-4.1)
id AA19879; Thu, 23 Jul 92 10:22:47 PDT
Date: Thu, 23 Jul 92 10:22:47 PDT
From: Fred Baker <fbaker at acc.com>
Message-Id: <9207231722.AA19879 at saffron.acc.com>
To: dcrocker at mordor.stanford.edu
Subject: Re: Newcomers at the IETF
Cc: ietf at isi.edu
>> I like your suggestion to have an introduction to the ietf so much
>> I'll ask a follow-on: How much time/energy should be devoted to
>> tutorials about specific working groups? Assuming that this should
>> be done outside of working group sessions, when should this be done?
There's a couple of ways to go at that. My take is that the area
directors could summarize the working progress in their areas, and then
folks could button-hole individual working group chairs for the ones
that they were interested in. Getting 80-odd working group chairs to
stand up and say "Hi, I'm me, and we in the YARP-WG are working on yet
another routing protocol" could be a dull drone.
Maybe a handout containing all of the working group charters would be
helpful. Perhaps selecting the most popular working groups and
having those five or ten chairs breifly summarize their work would be
worthwhile.
April commented that most Working Group Chairs are doing it on their
own time, and are volunteers. This is true of me; everything I write
is written after my wife goes to bed. However, I personally feel a
little odd chairing a meeting where I have no idea who half the people
in the room are, and would welcome the chance to associate names with
the faces. Also, let me relate an experience.
At the Honolulu IETF (my second), I attended a number of meetings. At
one point, I dropped in to observe one of the policy-based routing
architecture working groups. Someone (I don't recall whom, but I
assumed at the time that it was the chair) ejected me from the room
with the assertion "this working group is a closed group," and I forever
since have had the irrational feeling that I am not welcome in that
particular domain. The person, by the way, seemed as uncomfortable
ejecting me as I felt being ejected. Had I been able to talk with the
person earlier, learn the ground rules, and find out what was probably
the truth, that only one session of that working group was going to be
closed during the whole week, the incident could have been avoided.
So, I think that the chairs could probably be prevailed upon with a
call to reason; it's a benefit both ways.
Fred
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00987;
25 Jul 92 9:54 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07197; 25 Jul 92 9:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21841>; Thu, 23 Jul 1992 07:31:22 -0700
Received: from watson.ibm.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA21835>; Thu, 23 Jul 1992 07:31:18 -0700
Message-Id: <199207231431.AA21835 at venera.isi.edu>
Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1034;
Thu, 23 Jul 92 10:28:54 EDT
Date: Thu, 23 Jul 92 09:48:22 EDT
From: perk at watson.ibm.com
To: ietf at isi.edu
Cc: w2pravin at watson.ibm.com
Subject: A newcomer speaks up
I attended my first real IETF recently in Boston, except
for dropping in briefly at the meeting in Atlanta last
year. I've been following the recent pile of comments
about growth and structure, and would like to add a few,
possibly naive, comments.
First, there is a huge demand for education. If you want
to make a lot of money, organize some tutorials -- preferably
by WG chairs, or contributors.
Note that the plenary addresses often seemed tutorial in
nature. And, note that these talks along with any
discussions that seemed tutorial in nature were far and
away the most popular.
Although not completely clueless, I did not find it easy
to get the information I wanted about what was going on.
It is almost a given that no one can follow all the
mailing lists of interest, and still get any work done.
So, it is also a given that even the most competent among
us need a little help now and again -- most immediately
in understanding what in the hell all the acronyms mean,
and then most importantly in gathering the appropriate
context for discussion.
A simple remedy for the abovementioned evil, is to have
each WG prepare and maintain a statement of mission, along
with a current summary of its "progress". New attendees
would gratefully read that document, understand the acronyms,
understand the concerns, and even be able to contribute
without embarrassing themselves. And, being honest, we
would all agree that maintaining such a document to be
handed out at the IETF meetings would help even the
experts regain their focus on the appropriate problems.
I'd even *pay* for these documents!
Another evil, almost inherent in organizations subjected
to rapid growth, is the build-up of cliques and the
consequent exclusion of neophytes (who are not always
dummies). I don't have any suggestions about how to
fix this. But if nobody says anything about it, no one
else will suggest cures, either.
I really do support keeping WG meetings at a high level
of technical detail, while allowing Martian comments.
Outrageous new ideas really get open-minded people bubbling
mentally with new contributions - but again there is a
strong need to keep out ugly, ad-hominem controversy.
So, the job of a WG chair is hard. Nevertheless, it
also carries with it the ability to help shape the future,
and the glory that goes along with that power. The only
thing I can recommend is to distribute evaluation forms
at (some or all) WGs, and if a chairperson is not performing
these difficult tasks well enough, some appropriate action
taken. These evaluation forms could also be used to
suggest additions or clarifications to the WG orientation
documents previously suggested.
I recommend some discussion about possibly hiring a
"director". This person would be paid well to further
the goals of the organization. No specific technical
expertise would be necessary; but to compensate, the
director would have to come equipped with a larger than
average supply of altruism and people-skills. A director
would follow the progress of the WGs, organize tutorials,
understand the overall goals of the organization, know
everybody, and leap over tall buildings. A director would
lack a specific technical agenda, but be fascinated and
respectful enough for Internet technology to want to see
this openness blossom to its fullest flowering. Oops,
I guess I got carried away there :-)
Lastly, I must say that even with all its faults, an
IETF meeting is an exhilarating way to spend one's week.
Thanks for your consideration of my thoughts.
Charlie P.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00999;
25 Jul 92 9:57 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07256; 25 Jul 92 9:57 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20604>; Thu, 23 Jul 1992 07:09:42 -0700
Received: from kona.CC.McGill.CA by venera.isi.edu (5.65c/5.65+local-6)
id <AA20598>; Thu, 23 Jul 1992 07:09:33 -0700
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA21154 (mail destined for ietf at isi.edu) on Thu, 23 Jul 92 10:07:19 -0400
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
id AA09829; Thu, 23 Jul 92 10:07:15 EDT
Message-Id: <9207231407.AA09829 at expresso.cc.mcgill.ca>
In-Reply-To: vcerf at nri.reston.va.us's message as of Jul 22, 14:49
From: Peter Deutsch <peterd at bunyip.com>
Date: Thu, 23 Jul 92 14:07:14 GMT-0:02
In-Reply-To: vcerf at nri.reston.va.us's message as of Jul 22, 14:49
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: vcerf at NRI.Reston.VA.US, Fred Baker <fbaker at acc.com>
Subject: Re: Newcomers at the IETF
Cc: atkinson at itd.nrl.navy.mil, ietf at isi.edu, scott at ftp.com
[ vcerf at nri.reston.va.us writes: ]
>
> Fred,
>
> the idea of a newcomer briefing has a lot of appeal - we might
> even go so far as to try to make this available in some on-line
> form (hmm - I wonder if this is the equivalent of the story-teller,
> minstrel who provided a kind of oral history; recast in modern
> times...). Perhaps it would help to modulate the behavior of
> folks who are new to the process.
Count this as another vote for a newcomers' tutorial. As
a working group co-chair I would also be happy to show up
at a "meeting the working groups" session before the Sunday
night reception to let newcomers get to see what people
are working on.
I would only add one caveat - I think that the last two
locations contributed a great deal to the explosive growth
we have seen and I suspect that when we go to someplace
like Columbus or Amsterdam we will see an easing of this
particular problem. Although certainly growth wont stop, I
believe it will slow down over the next couple of meetings.
BTW, do we have any stats on where people are coming from?
If the theory of locality is valid, then we should have
seen a disproportionate number of people from California
in San Diego and a disproportionate number of people from
the states around Mass. in Boston. Any figures to back
this up? If not then it would seem that the growth is real
and we can expect it to continue apace.
Of course, if it turns out that the growth is real, we
should also not be too alarmed or surprised. Sure the
pioneers built a network of hundreds of machines with only
a few dozen people, but we now have a network of a million
machines, which is still growing exponentially and we are
now seeing the first stirrings of an impending explosion in
new tools and services. There's lots to do and lots of
people who want to help.
Given that the net has grown by four orders of magnitude,
we should perhaps be pleased that the IETF has grown by
less than two (ie from dozens to hundreds of participants).
> All,
>
> Does anyone on the list still remember when this was all new to them?
> Would an introduction that talks about ietf cultures, stds procedures,
> and the like have been helpful?
I certainly still remember and such an introduction would
have been wonderful.
I've been coming to the IETF for just over a year now.
When I arrived at my first meeting in Atlanta, I had a few
specific things I'd wanted to talk about, but only the
vaguest idea about how the whole process worked and where
I would fit into it. I wanted to find out what was
happening, I wanted to learn and I wanted to help,
although I had no idea what I could do that wasn't already
being done.
I managed to make contact with people from the right area
by guessing at what the various acronyms meant on the
timetable and interpreting the working group names, and
was quite surprised (and pleased) to find out how open the
entire process was if I was prepared to participate,
contribute and learn. One of the first things I
discovered that if you suggested something that others
were not working on, you were in fact volunteering to help
see your ideas through and if your ideas have merit you
will be given the chance to do something about them.
By the following IETF Alan Emtage and I were chairing a
Working Group and helping on a number of other projects. A
year later we are hard at work at a number of initiatives
and are producing not one but several documents in the
user services area, working with others on new tools and
helping to set the stage for a push to standardize NIR
tools and information.
I would caution against trying too hard to preserve the
old boy network. Quite frankly if I had had to pass a means
test that first time, I might not even have considered
coming. If we want new ideas, we should be prepared to
accept newcomers. Of course, we want to educate them into
the culture and show them how the process works, but I
personally think there's still plenty of for all those new
hands to work on and we shouldn't be turning people away
because of institutional agoraphobia or an inability to
manage growth.
As someone said so elegantly in the open plenary, if we
are having continual problems with the large numbers of
people in the system, perhaps we have a systemic problem,
not a people problem. Our structure needs work, so lets
work on it. Let's not try to manage our growth by
outlawing it.
- peterd
--
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01024;
25 Jul 92 10:16 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07541;
25 Jul 92 10:17 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25602>; Thu, 23 Jul 1992 08:39:36 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA25597>; Thu, 23 Jul 1992 08:39:29 -0700
Received: by ftp.com
id AA19722; Thu, 23 Jul 92 11:37:01 -0400
Date: Thu, 23 Jul 92 11:37:01 -0400
Message-Id: <9207231537.AA19722 at ftp.com>
To: vcerf at NRI.Reston.VA.US
Subject: Re: Newcomers at the IETF
From: Frank Kastenholz <kasten at ftp.com>
Cc: fbaker at acc.com, atkinson at itd.nrl.navy.mil, ietf at isi.edu, scott at ftp.com
> All,
>
> Does anyone on the list still remember when this was all new to them?
> Would an introduction that talks about ietf cultures, stds procedures,
> and the like have been helpful?
>
> Vint
whenever anyone starts out in a new environment, introductions always
help -- whether it is going to an ietf meeting for the first time or
starting a new job. however, part of the problem of introductions is
that one usually gets brain-overload real fast. remember what it is like
when starting at a new job and you are introduced to 96 people the first
day -- how many of them do you remember at the end of the day? we have our
nerd-badges with there dots so it is easier to remember who is who -- but
all of the rest of the introductory material would probably just get jumbled
and lost.
plus, a special introductory session would not deal with the people who
only come in for a single meeting at a single time.
--
frank kastenholz
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01066;
25 Jul 92 10:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07881;
25 Jul 92 10:39 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06379>; Thu, 23 Jul 1992 14:40:06 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA06370>; Thu, 23 Jul 1992 14:40:02 -0700
Received: from SPECTRUM.CMC.COM by NRI.Reston.VA.US id aa02968;
23 Jul 92 17:25 EDT
Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum))
id AA29788; Thu, 23 Jul 92 14:25:15 PDT
Date: Thu, 23 Jul 92 14:25:15 PDT
From: Lars Poulsen <lars at cmc.com>
Message-Id: <9207232125.AA29788 at Spectrum.CMC.COM>
To: Internet-Drafts at NRI.Reston.VA.US
Subject: Weeding Out of I-D FTP directories
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA
Cc: ietf at NRI.Reston.VA.US
I presume this question is for Greg Vaudreil:
Is there a set procedure for weeding out the I-D directories,
and how often is it performed ?
I have a batch job that periodically retireves a list of file names
on the nearest I-D FTP host, and retrieves any file which I don't
already have. I am sure that many others do the same.
I find that my shadow directory keeps growing, so I have tried to
delete obsolete versions of the files, only to see them reappear
later, because they were still on the FTP site.
Under current procedures, a draft expires after six months. Each
draft also expires when a newer version of the same title is posted.
Finally, drafts expire when they are republished as RFCs.
It would be really helpful to have the I-D directories cleaned out
every other month or so.
Comments solicited.
--
/ Lars Poulsen, SMTS Software Engineer Internet E-mail: lars at CMC.COM
CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262
Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01104;
25 Jul 92 10:53 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08128;
25 Jul 92 10:53 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23500>; Thu, 23 Jul 1992 07:55:42 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA23450>; Thu, 23 Jul 1992 07:54:46 -0700
Received: by ftp.com
id AA17387; Thu, 23 Jul 92 10:52:24 -0400
Date: Thu, 23 Jul 92 10:52:24 -0400
Message-Id: <9207231452.AA17387 at ftp.com>
To: sollins at lcs.mit.edu
Subject: Re: thoughts on the Boston meeting
From: Frank Kastenholz <kasten at ftp.com>
Cc: vcerf at NRI.Reston.VA.US, ietf at isi.edu
karen
i think the idea of telecasting the sessions is orthogonal to what i
have perceived as "the major real problem".
the "major real problem" seems to be, to put it impolitely, that people
show up in wg's and do not know what is going on, may not even understand
the technology being discussed, and insist on taking up the wg's time
with education, bringing up long-dead issues, etc, etc. all a telecast
will do is to let more of these types of people, spread over a very wide
area, cause these problems.
the people who come and listen do not cause problems (other than seat
exhaustion). they may just listen, they may learn and become contributors,
they may get scared and run away in sheer terror. i am not worried about them.
the problem is how do we get the best technical contribution to a
w.g. that we can without wasting inordinate amounts of time doing
"other" stuff. the more i follow this discussion, the more i ponder
the issue, the more i think that there is no single answer that will
solve the problem. some techniques that i have seen that work:
1. divide the w.g. session up into talkers and listeners and make a
set of qualifications for talker along the lines that we have
been discussing here (e.g., must have attended one previous
w.g. meeting, has read the document, etc). this worked amazingly
well in the router requirements sessions where i saw it used.
of course, this requires either testing attendees (yuck) or honesty.
2. have a well written w.g. charter. the charter could tightly bound
the space in which the w.g. can work. discussions that stray too
far out of the space can be summarily chopped off with a "we are
not supposed to discuss that" from the chair. this runs the risk
of too tightly bounding the w.g., eliminating some of the free-
association that sometimes is quite useful. this can be addressed
by getting a new charter, or holding the "out of bounds" discussions
after the regular meeting of the w.g.
this technique was used for the second enet mib working group. the
w.g. was very limited in what it could do. this effort has had a
very contentious history. i was the chair and was able to keep the
w.g. focused on its job. our work went quite easily, quite painlessly.
we had one meeting and finished our work before the time was up.
3. set an agenda for the w.g. meeting and stick to it. topics not on the
agenda are not discussed.
all of these methods require a strong chair. this may be the problem.
our chairs have been chosen for their technical abilities, for their
interest in the problem, etc. our chairs have NOT been chosen for
their abilities to get the working group moving and produce results.
perhaps this is what the iesg should do when chartering a w.g. and
selecting a chair. if we look at past chairs and see who let a w.g.
wander and who kept it focused and tried to select chairs out of
the later group we would improve things a lot. the problem is
how do you build up the group of "good" chairs? when a wg is formed,
the chair could be selected as it is done now -- but the iesg must
keep an eye on the wg and if the chair lets things wander, the
chair should be replaced. eventually good chairs will be found.
now that i think of it, i can see a case that the chair should not
directly be on of the people trying to solve the problem that the
w.g. is trying to address. the job of the chair is to keep the w.g.
moving -- an administrative job. the chair should not also be the
primary engineer on the problem, otherwise the chair may end up being
biased in an unacceptable way.
don't get me wrong, i think that telecasting the sessions is a great idea.
there are the problems -- who pays for it? who runs it (if i remember right,
there were always two or three people working on the system in the
plenary sessions)? what about the network bandwidth -- is there enough? and
so on.
with cheap bulk storage, we could archive the entire w.g. session on disk,
tape or cdrom. imagine -- the proceedings could be a cd rom with the
sessions on them! this might lead to some interesting technology (how do
i find the spot where that bozo asked "what is the iab's role?" without
fast-forwarding through hundred's of hours of goop? :-)
--
frank kastenholz
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01171;
25 Jul 92 11:53 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09019;
25 Jul 92 11:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA02848>; Thu, 23 Jul 1992 11:05:52 -0700
Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.65+local-6)
id <AA02841>; Thu, 23 Jul 1992 11:05:43 -0700
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15146; Thu, 23 Jul 92 14:03:44 -0400
Received: from practic.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 140232.2489; Thu, 23 Jul 1992 14:02:32 EDT
Received: from localhost
by practic.practic.com (5.61/smail2.5/04-23-91)
id AA08177; Thu, 23 Jul 92 09:48:34 -0700
Message-Id: <9207231648.AA08177 at practic.practic.com>
To: uunet!ISI.EDU!ietf at uunet.uu.net
Cc: brunner at uunet.uu.net
Subject: thoughts on the Boston meeting
Date: Thu, 23 Jul 92 09:48:31 PDT
From: "practic!brunner at uunet.uu.net" <brunner at practic.practic.com>
In discussing the problems (or perceived problems) with due to
the growth in attendees over the past year or so of IETF meetings,
I made mention of the physical venue (Kyoto) of the ISOC decision
w.r.t. ipv7 as a contributing factor in Fear Uncertainty and Doubt
(aka "FUD") in the networking trade (and to an extent, networking
R&D). Mr. Carpenter has written, "Hey!! The Internet is international
and there is nothing, repeat nothing, peculiar about taking decisions
in Japan, or Europe, or New Zealand." Well, in an attempt to head off
the non-issue of physical venue, I'll expand on my earlier remark on
the "peculiarity" of the Kyoto venue.
What struck me as "peculiar" was the absence of prior notice of the
technical issue under consideration, the pre-meeting announcement of
the ISOC adgenda contained no mention of any technical issue which
would give rise to the ipv7 statement of 01/07/92. Also absent was
any notice to non-road/big-i lists that technical proposals under
discussion there were under serious consideration for "fast track"
adoption, by anyone outside of some several limited research engineering
test-bed implementations. Further, the absence of announcement of an
inate ability to reach binding decisions by the Kyoto-meeting attendees
Had all of these absences been repaired, the only thing "peculiar" about
meeting in Kyoto would have been the absence of a simultanious kanji
MIME minutes to the ietf list and releated lists. With these absences,
even had the meeting been held at CERN or in San Jose it would remain
something of a peculiarity.
Please spare me tacit approvals of decisions based on the political
correctness of their non-CONUS local, I'd prefer other reasons for
reaching decisions.
On tutorials, another aspect of my set of suggestions, Fred Baker's proposal
to have an "orientation" tutorial is a good idea, good in several aspects.
First, it is the easiest to accomplish, second, it may address the largest
perceived problem or need presented by new attendees, whether technically
"prepared" or not, and third, it is awfully hard to think of a reason why
this ought not be done. It may well be that two meetings hence, tutorials
per-se will be a non-issue as growth-related obstruction or encumberment
of process will be back to a tolerable level. If not, then more thought
will be needed. Mr. Rajagopalan's point that the ill-equiped will drop out
is noted, but it is somewhat offset by the numerous observations that many
companies are now sending product management, that the IETF is perceived
as being "the in thing", and the fact that networks are a large, growing,
and rather competitive market -- a far cry from things when I for one first
got interested.
While not actually addressing tutorials per-se, Karen Sollins points out
that there are two "groups" involved in IETF meetings, those who "come mostly
to listen and learn", and Scott Kaplen points out that we have not as yet
"(made) a conscious decision to get into the education business (and it
*is* a business)". The needs of the second group, and the business aspects
of meeting some of their needs via education, was discussed when the ISOC
was first being floated, but is still left to the market, which to my
limited exposure (InterOp, NetWorld, CommNET, and several tutorial-mostly
non-show-providors), isn't a close enough match (nor are traditional CS
programs, which depricate network and protocol "engineering").
In summary (ignoring the bogus physical venue non-issue), we are a walk-in
body, with enough new walk-ins to be experiencing what most rapid-growth
entities experience, and we can choose to do something, or nothing, which
is something, about the consequences of growth. Much of what defines our
working parameters -- the world outside of our peer review R&D, is not
something we take a concious roll in affecting, whether teaching or showing
interoperation or utility of technology, or in any other form.
I'm still hope to get unsollicited ideas on how (or how not) to get host
software implementations into the hands of the end-users and their vendors
so that less actual malfunction exists, and how (or how not) to provide
a level playing field for honest self-interest, as well as the whys (and
why nots) of considering either.
Thanks to all who wrote in reply,
#include <std/disclaimer.h>
Eric Brunner, Tule Network Services
uunet!practic!brunner or practic!brunner at uunet.uu.net
trying to understand multiprocessing is like having bees live inside your head.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01195;
25 Jul 92 12:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09165;
25 Jul 92 12:00 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA11061>; Thu, 23 Jul 1992 16:10:31 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA11057>; Thu, 23 Jul 1992 16:10:29 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08370;
23 Jul 92 19:01 EDT
To: Jim Culbert <culbert at iesl.mit.edu>
Cc: fbaker at acc.com, atkinson at itd.nrl.navy.mil, ietf at isi.edu, scott at ftp.com
Subject: Re: Newcomers at the IETF (One account from a "real live one")
In-Reply-To: Your message of "Thu, 23 Jul 92 11:31:10 EDT."
<9207231125.aa17302 at NRI.Reston.VA.US>
Date: Thu, 23 Jul 92 19:01:11 -0400
From: vcerf at NRI.Reston.VA.US
Message-Id: <9207231901.aa08370 at IETF.NRI.Reston.VA.US>
Jim,
thanks for sharing your experiences - I'm convinced by all the
good feedback that we should prepare introductory material and
offer some introductory briefings.
Vint
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab01288;
25 Jul 92 13:19 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10514;
25 Jul 92 13:19 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14377>; Thu, 23 Jul 1992 17:38:37 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA14360>; Thu, 23 Jul 1992 17:38:26 -0700
Date: Thu, 23 Jul 1992 17:36:14 -0700
Posted-Date: Thu, 23 Jul 1992 17:36:14 -0700
Message-Id: <199207240036.AA02855 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA02855>; Thu, 23 Jul 1992 17:36:14 -0700
To: ietf at isi.edu
Subject: IAB Protocol Action: Echo function for ISO 8473 to Remain a Proposed Standard
Cc: iab at isi.edu, iab-stds at isi.edu, iesg at isi.edu, iesg-secretary at isi.edu
The IAB has accepted the IESG recommendation that RFC-1139 "Echo
function for ISO 8473" (CLNP Echo) remain a Proposed Standard.
Rationale:
New work has begun on a revision intended to become a Draft
Standard. This version should be ready for submission to the
IAB in the near future. Until a new version is prepared, RFC-1139
will be listed as a Proposed Standard protocol expired in grade.
Bob Braden
for the IAB
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01309;
25 Jul 92 13:41 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10927;
25 Jul 92 13:41 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06600>; Thu, 23 Jul 1992 14:43:20 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA06596>; Thu, 23 Jul 1992 14:43:18 -0700
Received: from nma.com by q2.ics.uci.edu id ab29504; 23 Jul 92 12:50 PDT
Received: from ics.uci.edu by odin.nma.com id aa08094; 23 Jul 92 9:39 PDT
To: vcerf at NRI.Reston.VA.US
Cc: Dave Crocker <dcrocker at mordor.stanford.edu>, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
In-Reply-To: Your message of Thu, 23 Jul 192 07:10:23 -0400.
<9207230710.aa00813 at IETF.NRI.Reston.VA.US>
Reply-To: Stef at nma.com
From: Einar Stefferud <Stef at nma.com>
Date: Thu, 23 Jul 1992 09:39:08 -0700
Message-Id: <8092.711909548 at nma.com>
Sender: stef at nma.com
Hi Vint, et al -- I put my ideas forward to be used in any useful way...
> I'd like to share the substance of your suggestions with
> the people who specialize in dealing with standards making
> (counsel) to get their reactions in parallel with the
> discussion which I hope will unfold on ietf (or a special
> list if the ietf distribution would prefer).
I would very much welcome exposure to (and discussion with) the legal
folk who understand the liability issues. Parallel is better than
serial.
In my mind, and in the context of my own experience in other standards
activities, I am personally convinced that openness of the process and
perceived fairness of the outcomes are the paramount issues.
Thus, it seems very clear to me that any kind of competence testing or
judgemental restriction on attendance and participation at consensus
measurement time is detrimental to our cause, and could/would lead to
legal problems.
In fact, as I read the leaves in the bottom of our Boston Tea Cup, the
lurking perception that our current process is not sufficiently open
is driving the working level rebellion. We are already facing a
perceivable risk with our present (new) ISOC/IAB/IESG/IETF
organizational arrangements.
I should hasten to say that I cannot imagine anyone considering any
specific legal action in the context of our Boston Tea Party, but I
feel that all this is lurking beneath the surface. It is very
important to me to find a perceptibly more open and obviously fair and
unassailable set of arrangements.
Now then, I also believe that all of this is a matter of perception,
which may or may not fully reflect fact. None-the-less, perceptions
will govern the legal exposure question, in that if anyone really
believes they have been sufficiently wronged, they will seek redress.
We should strive to make it patently obvious that such claims will be
judged to be false.
To, me, it is critically important that we (IAB/IESG/IETF and ISOC)
collectively generate wide spread perceptions of openness and
fairness.
I do not see this as a difficult thing to arrange, as long as we agree
on the desired results. I hope that our legal advisors also see it
this way.
We need simple openness and fairness, without legal complexities. We
should be able to claim and demonstrate openness and fairness based on
simply stated behavior rules which ordinary people can understand
without consulting their own lawyers to be sure.
This includes the fact of an ISOC legal entity umbrella, plus working
level behavior rules, work progression rules, and everything in between.
Cheers...\Stef
PS: How about naming the new Ad Hoc Working Group the IETF-BTP;-)...
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01334;
25 Jul 92 13:54 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11165;
25 Jul 92 13:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14849>; Thu, 23 Jul 1992 17:44:02 -0700
Received: from spock.retix.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA14845>; Thu, 23 Jul 1992 17:44:00 -0700
Received: by spock.retix.com
id AA15218; Thu, 23 Jul 1992 17:41:40 -0700
Date: Thu, 23 Jul 1992 17:41:40 -0700
From: Mondo <des at spock.retix.com>
Message-Id: <199207240041.AA15218 at spock.retix.com>
To: ietf at isi.edu
Could you please add me to the mailing list.
---------------------------------------------------------------------
Desmond Borresen.
RETIX : The open newtorking company.
email: des at retix.retix.com
phone: (310) 828-3400
snail-mail: c/o Retix, 2401 Colorado Ave., Santa Monica, CA 90404.
---------------------------------------------------------------------
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01346;
25 Jul 92 13:57 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11233;
25 Jul 92 13:57 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA11463>; Thu, 23 Jul 1992 16:27:24 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA11459>; Thu, 23 Jul 1992 16:27:22 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08525;
23 Jul 92 19:20 EDT
To: ietf at isi.edu
Subject: Introduction for new members - a good idea
Date: Thu, 23 Jul 92 19:20:24 -0400
From: vcerf at NRI.Reston.VA.US
Message-Id: <9207231920.aa08525 at IETF.NRI.Reston.VA.US>
Many people have responded positively - mostly to me, to
avoid bothering the list (a nice point of netiquette).
Some combination of user services, ietf secretariat,
and interested parties will be invited to help (watch
this space...)
and thanks for all the helpful comments.
Vint Cerf
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab01425;
25 Jul 92 14:44 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12211;
25 Jul 92 14:44 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29104>; Fri, 24 Jul 1992 00:57:22 -0700
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.65+local-6)
id <AA29100>; Fri, 24 Jul 1992 00:57:19 -0700
Message-Id: <199207240757.AA29100 at venera.isi.edu>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.23597-0 at bells.cs.ucl.ac.uk>; Fri, 24 Jul 1992 08:53:43 +0100
To: vcerf at NRI.Reston.VA.US
Cc: Dave Crocker <dcrocker at mordor.stanford.edu>, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
In-Reply-To: Your message of "Wed, 22 Jul 92 18:24:12 EDT." <9207221824.aa05891 at IETF.NRI.Reston.VA.US>
Date: Fri, 24 Jul 92 08:53:39 +0100
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
>hmm - maybe the audio/video set up will lead to the attendees
>paying for some people not to attend...!!!
one thing we conspicuously didnt coordinate this time around was a
distributed measurement excercise - since many of the sites were
sun-experts, and close to network operations centers/fixes, they could
have monitored all traffic 9e.g. via tcpdump) from each audio/video
sender site to 224.x.y.z
if someone taught tcpdump about vat's protocol, and we wewre all ntp
synced up, it could even lead to a VERY interesting distributed
traffic paper! (depends on the findings obviously!)
this would be slightly valuable in estaimating what the internet
really could support NOW, rather than speculating -
for instance, several sites left open channel video on, and most sites
defaulted to 64kbps PCM audiop - however, we had a few outlying
friends on the end of vat relays at LPC4 - which you can support 16
times as many as as PCM - i.e. if we can handle even 4 64 kbps session
we could certainly _consider_ all the sessions (at least audio)
with a little more coordination, we could also have more video (e.g.
for slides, i believe paul milazzo's threshold on changes being sent
could be tuned right down so we really ony got slide changes...
this is all so similar to the first days of email - but look what we
trust that with now!
j.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab01456;
25 Jul 92 15:10 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12685;
25 Jul 92 15:10 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA02191>; Fri, 24 Jul 1992 03:04:26 -0700
Received: from kauai.mcl.unisys.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA02187>; Fri, 24 Jul 1992 03:04:08 -0700
Received: by kauai.MCL.Unisys.COM (4.1/mls/3.2)
id AA01110; Fri, 24 Jul 92 05:59:24 EDT
Date: Fri, 24 Jul 92 05:59:24 EDT
From: Dennis Perry <perry at mcl.unisys.com>
Message-Id: <9207240959.AA01110 at kauai.MCL.Unisys.COM>
To: scott at ftp.com, vcerf at NRI.Reston.VA.US
Subject: Re: thoughts on the Boston meeting
Cc: atkinson at itd.nrl.navy.mil, ietf at isi.edu, perry at mcl.unisys.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01468;
25 Jul 92 15:13 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12737;
25 Jul 92 15:13 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23429>; Thu, 23 Jul 1992 21:01:48 -0700
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA23422>; Thu, 23 Jul 1992 21:01:45 -0700
Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0)
id AA02324; Thu, 23 Jul 92 20:59:40 PDT
Message-Id: <9207240359.AA02324 at Mordor.Stanford.EDU>
To: Stef at nma.com
Cc: Frank Kastenholz <kasten at ftp.com>, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
Org: The Branch Office
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 23 Jul 92 13:35:15 -0700.
<8473.711923715 at nma.com>
Date: Thu, 23 Jul 92 20:59:39 -0700
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Stef,
In the interest of working through the details of a good theory, would
you suggest how the approach you are suggesting, for resolving
the conflict caused by having too many specifications, could have
been used to resolve the SNMP/CMOT or OSPF/IS-IS difficulties, or
better still how we might apply it to the upcoming ROAD show in
November?
Eagerly,
Dave
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01480;
25 Jul 92 15:14 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12775;
25 Jul 92 15:14 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10666>; Thu, 23 Jul 1992 16:00:06 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA10645>; Thu, 23 Jul 1992 15:59:58 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id ab08315;
23 Jul 92 18:56 EDT
To: Frank Kastenholz <kasten at ftp.com>
Cc: fbaker at acc.com, atkinson at itd.nrl.navy.mil, ietf at isi.edu, scott at ftp.com
Subject: Re: Newcomers at the IETF
In-Reply-To: Your message of "Thu, 23 Jul 92 11:37:01 EDT."
<9207231537.AA19722 at ftp.com>
Date: Thu, 23 Jul 92 18:56:38 -0400
From: vcerf at NRI.Reston.VA.US
Message-Id: <9207231856.ab08315 at IETF.NRI.Reston.VA.US>
Frank,
several people have suggested having the intro material available
on-line as rfcs in addition to providing some briefings during
ietf. Your point that not all come for the full week is a good one.
vint
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01539;
25 Jul 92 16:06 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13760;
25 Jul 92 16:06 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA13648>; Thu, 23 Jul 1992 17:28:02 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA13643>; Thu, 23 Jul 1992 17:28:00 -0700
Received: from nma.com by q2.ics.uci.edu id aa19170; 23 Jul 92 16:20 PDT
Received: from ics.uci.edu by odin.nma.com id aa08475; 23 Jul 92 13:35 PDT
To: Frank Kastenholz <kasten at ftp.com>
Cc: dcrocker at mordor.stanford.edu, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
In-Reply-To: Your message of Thu, 23 Jul 1992 11:36:57 -0400.
<9207231536.AA19715 at ftp.com>
Reply-To: Stef at nma.com
From: Einar Stefferud <Stef at nma.com>
Date: Thu, 23 Jul 1992 13:35:15 -0700
Message-Id: <8473.711923715 at nma.com>
Sender: stef at nma.com
Hi Frank -- All good thoughts. Let me try to rationalize all this
into a unified theory of IETF operation.
1. Both solicited and unsolicited contributions should always be welcome!
Solicited contributions should involved a reviewed call.
A regular mechanism needs to exist for handling unsolicited
contributions that do not fit into an existing (or planned-to-
exist) WG. This same mechanism should also refer incoming
contributions to their appropriate WG in the case where the
appropriate WG is not obvious. Mis-routed contributions
should be expeditiously rerouted. Routing is a problem;-).
2. When some issue suffers from having too many divergent
contributions, and hence to many divergent working groups,
then we should use the old "bump-it-up-a-meta-level trick".
By this I mean that a call for contributions on "How to get
out of this Divergence Box" should be issued, to focus
attention on the meta problems of resolving the divergence.
This will spread the responsibility beyond the confines of the
Lonesome IAB at the pinnacle, and will serve to focus
everyone's attention on the great fact of the existence of a
great problem to be solved by the IETF, et al.
What should not happen is for a parentally minded IAB to reach
down and take the matter into its own hands (ala IPv7). For
one thing, doing this pretty well "closes" the process to
reasonably wide participation, even if the IAB meetings are
made fully open, and for another, it removes any sense of
responsibility that might have rested on the IETF to get and
keep its act together.
So, in summary, I see no problems with forcing ourselves to keep the
pressure on the working levels of the IETF to make hard decisions,
even when they look like they might blow it. The proper use of
management should be to arrange things so the IETF understands who is
in the hot seat, and understands what will happen if the IETF fails to
do the right thing.
The name of the game is to make the penguins go home to roost in the
right place, on the heads of the IETF working group folk. If they
find it too hot in there, they should get out of the kitchen.
Cheers...\Stef
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01563;
25 Jul 92 16:10 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13831;
25 Jul 92 16:10 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05642>; Fri, 24 Jul 1992 07:51:50 -0700
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA05623>; Fri, 24 Jul 1992 07:51:09 -0700
Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0)
id AA04746; Fri, 24 Jul 92 07:48:40 PDT
Message-Id: <9207241448.AA04746 at Mordor.Stanford.EDU>
To: Stef at nma.com
Cc: Fred Baker <fbaker at acc.com>, vcerf at NRI.Reston.VA.US,
atkinson at itd.nrl.navy.mil, ietf at isi.edu, scott at ftp.com
Subject: Re: IETF Structure
Org: The Branch Office
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 23 Jul 92 02:29:50 -0700.
<7900.711883790 at nma.com>
Date: Fri, 24 Jul 92 07:48:39 -0700
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Stef,
Currently, the only way someone concerned about "architectural"
issues can monitor and participate in that category of a group's
activities is by monitoring _all_ of the group's activities. On
the average, we don't distinguish such topics from other ones.
I wonder whether it would not be helpful, to one and all, to note
working group efforts which are likely to have significant architectural
issues and encourage the direct specification of those choices prior
to more detailed issues. This would allow early review of the
architectural topics. (subject to later change, of course.)
Dave
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ac01575;
25 Jul 92 16:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13912;
25 Jul 92 16:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05540>; Fri, 24 Jul 1992 07:46:37 -0700
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA05536>; Fri, 24 Jul 1992 07:46:33 -0700
Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0)
id AA04707; Fri, 24 Jul 92 07:44:23 PDT
Message-Id: <9207241444.AA04707 at Mordor.Stanford.EDU>
To: petrilli at gnu.ai.mit.edu
Cc: braja at qsun.att.com, ietf at isi.edu
Subject: Re: Re; thoughts on Boston IETF meeting
Org: The Branch Office
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 22 Jul 92 23:33:49 -0600.
<9207230433.AA51181 at hal.gnu.ai.mit.edu>
Date: Fri, 24 Jul 92 07:44:22 -0700
From: Dave Crocker <dcrocker at mordor.stanford.edu>
In the realm of using IETF meeting time efficiently:
Would folks find it useful to have the "program guide" list a description
of each working group/bof meeting, such that there would be a brief
paragraph about the purpose and then an agenda, with a timeline to
show what details will be convered and about how long each should
take?
Would the wg/bof chairs be willing to write these, ahead of time?
I find that I sometimes am unclear about the intentions of a particular
meeting. For example, at this last IETF meeting, I was particularly
interested in any discussions about long-term addressing, but didn't
feel I needed to track the short term (CIDR) issues. But there was
no way to distinguish these on the program.
Dave
P.S. I could imagine reactions against the idea of a timeline, assuming
that one can't predict exactly how long a topic will take. And I
think that is true for some discussions and not for others. A BOF
may truly need some open discussion about a general issue. On the
other hand, a working group that is reaching closure could well have
specific items to work on, needing to reach closure. In any event,
the more concrete and detailed an agenda, the easer it can be for
the session chair to keep discussion focussed, I feel.
D/
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab01623;
25 Jul 92 16:36 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14248;
25 Jul 92 16:36 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05415>; Fri, 24 Jul 1992 07:36:25 -0700
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA05410>; Fri, 24 Jul 1992 07:36:12 -0700
Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0)
id AA04619; Fri, 24 Jul 92 07:33:57 PDT
Message-Id: <9207241433.AA04619 at Mordor.Stanford.EDU>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: vcerf at NRI.Reston.VA.US, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
Org: The Branch Office
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Fri, 24 Jul 92 08:53:39 +0100.
<9207240755.AA02869 at Mordor.Stanford.EDU>
Date: Fri, 24 Jul 92 07:33:56 -0700
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Jon,
Your comments trigger a question about the lower end of video
utility. For circumstances requiring consumption of a bare minimum
of channel capacity, I am wondering whether occasional snapshots of
higher resolution would be acceptible, in place of 4 frames/second.
That is, would people find it useful to get a picture of greater
resolution, but with no attempt at motion, so that overheads
and pictures of the speaker would be clearer?
Dave
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01635;
25 Jul 92 16:48 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14390;
25 Jul 92 16:48 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08561>; Fri, 24 Jul 1992 09:05:07 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA08539>; Fri, 24 Jul 1992 09:05:02 -0700
Received: by ftp.com
id AA11570; Fri, 24 Jul 92 11:53:07 -0400
Date: Fri, 24 Jul 92 11:53:07 -0400
Message-Id: <9207241553.AA11570 at ftp.com>
To: dcrocker at mordor.stanford.edu
Subject: Re: thoughts on the Boston meeting
From: Frank Kastenholz <kasten at ftp.com>
Cc: Stef at nma.com, ietf at isi.edu
> In the interest of working through the details of a good theory, would
> you suggest how the approach you are suggesting, for resolving
> the conflict caused by having too many specifications, could have
> been used to resolve the SNMP/CMOT or OSPF/IS-IS difficulties, or
> better still how we might apply it to the upcoming ROAD show in
> November?
sometimes someone has to make a tough decision. the people on the iab
and iesg derive a certain amount of prestige, power, and respect (no
smiley face!) by virtue of their position. if the ietf's wgs can not
make a single ipv7 recommendation, then that decision will need to be
made by the iab/iesg. it does not take a lot of brain cells to do the
more mundane aspects of the iab's and iesg's jobs. what we "pay" them
for with the prestige, etc, is to do these tough jobs. the iab and
iesg may have to earn their "pay" on this one.
the iab and iesg can make this process easier by (at least) 2
mechanisms:
1) try to develop (and publish) a set of criteria which will form the
basis for making such a decision. running code is one such criterion.
a list of the problems that we expect ipv7 to address would be another.
2) encourage efforts to merge or disband. some efforts may really be
duplicates of other efforts, some may complement other efforts, and
so on. at this stage of the effort, anything that reduces the number
of proposals would be a good thing.
--
frank kastenholz
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01685;
25 Jul 92 17:23 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14929;
25 Jul 92 17:23 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08150>; Fri, 24 Jul 1992 08:58:30 -0700
Received: from AQUA.WHOI.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA08144>; Fri, 24 Jul 1992 08:58:27 -0700
Received: by aqua.whoi.edu (5.57/Ultrix3.0-C)
id AA27860; Fri, 24 Jul 92 11:56:13 -0400
Date: Fri, 24 Jul 92 11:56:13 -0400
Message-Id: <9207241556.AA27860 at aqua.whoi.edu>
To: swb at nr-tech.cit.cornell.edu, vcerf at NRI.Reston.VA.US
From: arm at aqua.whoi.edu
Subject: Re: Newcomers at the IETF
Cc: ietf at isi.edu
As another newcomer to IETF my overall impression of an IETF meeting was
quite positive. My feeling was that the group had evolved a powerful,
unique way of working together. I was particularly impressed and
interested in the importance and attention paid to the appropriate use of
different communication tools. These include 1) the ietf mailing list, 2)
3 meetings a year, 3) video/audio conferencing, 4) working group charters,
internet-drafts and other working documents 5) BOF and working group
sessions, 6) socializing, and 7) application demos.
My other strong impression is that members generally respect one another
and move towards that "rough concensus" talked about.
I agree with the idea of an introductory session at IETF meetings, but I
would call it a training session instead. It should be made a prerequisite
to attending the other sessions. During a training session people would
learn what communication tools are used in the IETF process as well as
they're appropriate use. People would be taught how a "Task Force" and a
standards body are different.
It would be emphasised that standards are only one product of the task
force. Equal (perhaps more?) importance for the Task Force is that
effective "bumping of heads" and writing of code happen during the process.
Most concerns about too many people coming to the meeting stem from a
concern of this process being diluted or mutated. We "outsiders" would
appreciate training and hints about how to "do it" the IETF way. I,for
one, would like to learn. I am thinking of how I might even use the IETF
process in different arenas.
Perhaps more money would be charged for this one-time prerequisite session
so that excellent "trainers" and materials could be made available.
Andrew Maffei, Network Manager | amaffei at whoi.edu
Woods Hole Oceanographic Institution | 508/457-2000 x2764
Woods Hole, MA. 02543 | 508/457-2174 (FAX)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01702;
25 Jul 92 17:36 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15118;
25 Jul 92 17:37 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06366>; Fri, 24 Jul 1992 08:25:22 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA06360>; Fri, 24 Jul 1992 08:25:16 -0700
Received: by ftp.com
id AA10616; Fri, 24 Jul 92 11:22:59 -0400
Date: Fri, 24 Jul 92 11:22:59 -0400
Message-Id: <9207241522.AA10616 at ftp.com>
To: jnc at ginger.lcs.mit.edu
Subject: Re: Re; thoughts on Boston IETF meeting
From: Frank Kastenholz <kasten at ftp.com>
Cc: braja at qsun.att.com, vcerf at NRI.Reston.VA.US, ietf at isi.edu
noel,
aren't today's bofs the equivalent of the speculative sessions?
many of the bofs i've been to end with a "should we form a w.g. to address
this issue?" discussion.
frank
> I agree with all of this (that people who don't have a good reason to
> be there will drop out, and that people who think they are tutorials are soon
> disabused). In general, a lot of the proposed cures might well prove worse
> than the disease.
> The only possible exception to my agreement is your last comment about
> getting rid of speculative sessions. These are an important step in getting
> people started thinking about where we are going in the future, and are much
> better than papers and mailing lists for getting new ideas going. The sessions
> provide instant feedback to people on how to present their ideas in a way
> which is accessible, etc. I agree they need to be controlled to make sure they
> are not inefficient, though.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01751;
25 Jul 92 18:33 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15996;
25 Jul 92 18:33 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA15786>; Fri, 24 Jul 1992 11:23:59 -0700
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA15769>; Fri, 24 Jul 1992 11:23:48 -0700
Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0)
id AA06412; Fri, 24 Jul 92 11:21:38 PDT
Message-Id: <9207241821.AA06412 at Mordor.Stanford.EDU>
To: Frank Kastenholz <kasten at ftp.com>
Cc: Stef at nma.com, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
Org: The Branch Office
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Fri, 24 Jul 92 11:53:07 -0400.
<9207241553.AA11570 at ftp.com>
Date: Fri, 24 Jul 92 11:21:37 -0700
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Frank,
Let's keep traveling down your line of logic...
sometimes someone has to make a tough decision
There is a clarity and a kind of comfort in having a model which,
ultimately, specifies an authority to resolve the unresolvable. To
the extent the "community" empowers such an agency, life gets
simpler.
My perceptions of the IETF community, over the years, leaves my
highly skeptical that we will allow ourselves the luxury of this
option. Imagine that two vendors are the major proponents of
competing proposals. Imagine that each is sufficiently credible
to have a serious consituency among the IETF. That is, there is
no "easy" way to declare a winner.
How do we choose?
I am a big fan of developing selection criteria and I think that
they greatly help crystalize the community's basis for analyzing
alternatives. Ultimately, however, they don't make the decision
for us. They simply help us discriminate among clear contenders
and the also-rans.
How do we resolve among multiple clear contenders?
If I may step onto dangerous territory, I will offer my opinion
that SNMP/CMOT and OSPF/IS-IS primarily resolved themselves by
virtue of having only one option stay the course. (This is not
a commentary or criticism on _any_ of the options or of the
politics of either debate. I am merely trying to observe a
"behavioral" characteristic.) If the CMOT proponents or the IS-IS
proponents had delivered software and testing as aggressively as
their opponents, how would we have decided?
This isn't easy stuff. If there is any way that we can develop
a "supreme court" for making final decisions, I think that would be
great. But it is completely unclear to me a way that we can assert
such an authority which will be acceptable to the community (and, by the
way, to the legal system, since the loser of such a decision may
well claim unfairness.)
Ball in your court...
Dave
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01763;
25 Jul 92 18:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16148;
25 Jul 92 18:39 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16974>; Fri, 24 Jul 1992 11:46:58 -0700
Received: from uwm.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA16966>; Fri, 24 Jul 1992 11:46:49 -0700
Received: by uwm.edu; id AA24473; Fri, 24 Jul 92 13:44:39 -0500
Received: from babymf.techdev by techdev (4.1/SMI-4.1)
id AA16246; Fri, 24 Jul 92 13:22:22 CDT
Date: Fri, 24 Jul 92 13:22:22 CDT
From: Mike Migliano - Bell Atlantic <bellmf!mike at uwm.edu>
Message-Id: <9207241822.AA16246 at techdev>
To: uwm!isi.edu!ietf at isi.edu
Subject: Newcomers at the IETF
merlin.dev.cdx.mot.com!whay writes:
> I think it would be nice to tell the newcomers (perhaps the invited
> speakers as well) beforehand to come in casual attire. ;-)
I agree, since I managed to wear a tie on Tuesday and felt
kind of strange doing so..
To me it looked like Marshall and some others were getting
ready to host a luau. Was there one?
Mike
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab01806;
25 Jul 92 19:10 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16753;
25 Jul 92 19:10 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10898>; Fri, 24 Jul 1992 09:46:34 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA10891>; Fri, 24 Jul 1992 09:46:29 -0700
Received: by ftp.com
id AA12916; Fri, 24 Jul 92 12:44:11 -0400
Date: Fri, 24 Jul 92 12:44:11 -0400
Message-Id: <9207241644.AA12916 at ftp.com>
To: Stef at nma.com
Subject: Re: thoughts on the Boston meeting
From: Frank Kastenholz <kasten at ftp.com>
Cc: dcrocker at mordor.stanford.edu, ietf at isi.edu
stef
we have a mechanism for dealing with unsolicited contributions.
someone walks up to the iesg and says "i want to form a w.g. to
do foo" and one is created (or maybe a bof to decide whether a wg
is warranted). maybe an rfc saying this is needed.
> 2. When some issue suffers from having too many divergent
> contributions, and hence to many divergent working groups,
> then we should use the old "bump-it-up-a-meta-level trick".
>
> By this I mean that a call for contributions on "How to get
> out of this Divergence Box" should be issued, to focus
> attention on the meta problems of resolving the divergence.
i'd rather solve this in the reverse order -- part of a call should include
what we will do to resolve multiple solutions. the iab/iesg can also
work to reduce the number of active proposals by trying to get some
of them to merge, or voluntarily disband as being redundant...
> What should not happen is for a parentally minded IAB to reach
> down and take the matter into its own hands (ala IPv7). For
> one thing, doing this pretty well "closes" the process to
> reasonably wide participation, even if the IAB meetings are
> made fully open, and for another, it removes any sense of
> responsibility that might have rested on the IETF to get and
> keep its act together.
certainly the iab/iesg should not present the solution first. they should
be the decision makers of last resort. only when the ietf's wgs fail to
come to agreement should the iab/iesg be used. the main role of the iab
and iesg should be to try to get the ietf to come to agreement without
having to resort to an iab/iesg decision.
--
frank kastenholz
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01829;
25 Jul 92 19:40 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa17255;
25 Jul 92 19:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16013>; Fri, 24 Jul 1992 11:27:55 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA16007>; Fri, 24 Jul 1992 11:27:53 -0700
Received: from nma.com by q2.ics.uci.edu id ab20688; 24 Jul 92 8:55 PDT
Received: from ics.uci.edu by odin.nma.com id aa09286; 24 Jul 92 8:31 PDT
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: Frank Kastenholz <kasten at ftp.com>, ietf at isi.edu
Subject: theory of IETF operation (was: thoughts on the Boston meeting)
In-Reply-To: Your message of Thu, 23 Jul 1992 20:59:39 -0700.
<9207240359.AA02324 at Mordor.Stanford.EDU>
Reply-To: Stef at nma.com
From: Einar Stefferud <Stef at nma.com>
Date: Fri, 24 Jul 1992 08:31:00 -0700
Message-Id: <9284.711991860 at nma.com>
Sender: stef at nma.com
Time for a new subject field! Dave responded to my message where I
attempted to articulate "a unified theory of IETF operation"...
> In the interest of working through the details of a good theory,
> would you suggest how the approach you are suggesting, for resolving
> the conflict caused by having too many specifications, could have been
> used to resolve the SNMP/CMOT or OSPF/IS-IS difficulties, or better
> still how we might apply it to the upcoming ROAD show in November?
I was not directly involved enough in the CMOT or OSPF difficulties,
so I cannot safely speak to them. So, I will tackle the ROAD show
case.
At this point, I am speculating, and thinking with my fingers...
The "bump-it-up-a-meta-level" trick implies that the task is to find a
new higher (more abstract) plane or dimension in which to cast the
problem and attempt to find the right questions to ask.
I often claim that if you ever get the questions right, the answers
fall out easily. So, I think I am suggesting that one reason why we
have so many alternative answers is that we have not yet stated the
question "correctly".
So, one of the main aspects of the "Meta Problem WG" must be the
search for a better question (or questions) to be answered. What we
need is a framework that puts the alternatives into a rational and
acceptable perspective.
Now then, it might be that this is exactly what the ROAD group
attempted to do. Perhaps it also means that they are not yet done
with the question search part of the task.
Again, I have not been paying enough attention to exactly what the
ROAD group has been doing to dig any deeper into what they have or
have not done. I am being purposefully abstract at this point. You
asked me to address the meta-meta level.
So, rather than blather on, does this give you any better ideas for
how to proceed? Can anyone see how to form a META ROAD Group, or to
focus the current ROAD Group effort on how to cope with having too
many alternatives?
Best...\Stef
PS: One possible idea is to set about developing the framework for
what Marshall has called a "cost/benefits distribution analysis".
That is, determine what are the local gains and pains in the
relevant "localities", and determine if they are reasonably and
commensurately distributed.
One of our primary sources of conflict comes from one "locality"
advocating big gains for itself and big costs for others, and
vice versa. The SMTP Extensions "Just Send 8 Bits" argument is a
case in point...
In the IPv7 case, I think that much of the bad reaction came from
those who foresaw big costs and little gain for themselves, and
thus felt that they were set up for sacrifice on the alter of
progress that would greatly benefit others.
In response to those who will say "That will take too long!" and
"We need an answer now!" i can only say "Of course it is too
late already, but it is not as late is it is going to be later!"
In short, if not doing the required analysis is what is blocking
resolution, then continuing to not do it will continue to block
the decision, indefinitely.
Conflict resolution is really all about identifying stakeholders
and their stakes, and then finding an equitable solution. This
is required whenever a problem moves from the techno-engineering
context to the political context. It cannot be avoided.
PPS: Time for me to stop. Its your turn...\s
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01991;
25 Jul 92 20:38 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa18072;
25 Jul 92 20:39 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00322>; Fri, 24 Jul 1992 13:31:21 -0700
Received: from watson.ibm.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA20060>; Fri, 24 Jul 1992 12:46:28 -0700
Message-Id: <199207241946.AA20060 at venera.isi.edu>
Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5794;
Fri, 24 Jul 92 15:44:00 EDT
Date: Fri, 24 Jul 92 15:41:51 EDT
From: perk at watson.ibm.com
To: ietf at isi.edu
Subject: A newcomer speaks up
I attended my first real IETF recently in Boston, except
for dropping in briefly at the meeting in Atlanta last
year. I've been following the recent pile of comments
about growth and structure, and would like to add my own
few comments.
First, there is a huge demand for education. If you want
to make a lot of money, organize some tutorials -- preferably
by WG chairs, or contributors.
Note that the plenary addresses often seemed tutorial in
nature. And, note that these talks along with any
discussions that seemed tutorial in nature were far and
away the most popular.
Although not completely clueless, I did not find it easy
to get the information I wanted about what was going on.
It is almost a given that no one can follow all the
mailing lists of interest, and still get any work done.
So, it is also a given that even the most competent among
us need a little help now and again -- most immediately
in understanding what in the hell all the acronyms mean,
and then most importantly in gathering the appropriate
context for discussion.
A simple remedy for the abovementioned evil, is to have
each WG prepare and maintain a statement of mission, along
with a current summary of its "progress". New attendees
would gratefully read that document, understand the acronyms,
understand the concerns, and even be able to contribute
without embarrassing themselves. And, being honest, we
would all agree that maintaining such a document to be
handed out at the IETF meetings would help even the
experts regain their focus on the appropriate problems.
I'd even *pay* for these documents!
Another evil, almost inherent in organizations subjected
to rapid growth, is the build-up of cliques and the
consequent exclusion of neophytes (who are not always
dummies). I don't have any suggestions about how to
fix this. But if nobody says anything about it, no one
else will suggest cures, either.
I really do support keeping WG meetings at a high level
of technical detail, while allowing Martian comments.
Outrageous new ideas really get open-minded people bubbling
mentally with new contributions - but again there is a
strong need to keep out ugly, ad-hominem controversy.
So, the job of a WG chair is hard. Nevertheless, it
also carries with it the ability to help shape the future,
and the glory that goes along with that power. The only
thing I can recommend is to distribute evaluation forms
at (some or all) WGs, and if a chairperson is not performing
these difficult tasks well enough, some appropriate action
taken. These evaluation forms could also be used to
suggest additions or clarifications to the WG orientation
documents previously suggested.
I recommend some discussion about possibly hiring a
"director". This person would be paid well to further
the goals of the organization. No specific technical
expertise would be necessary; but to compensate, the
director would have to come equipped with a larger than
average supply of altruism and people-skills. A director
would follow the progress of the WGs, organize tutorials,
understand the overall goals of the organization, know
everybody, and leap over tall buildings. A director would
lack a specific technical agenda, but be fascinated and
respectful enough for Internet technology to want to see
this openness blossom to its fullest flowering. Oops,
I guess I got carried away there :-)
Lastly, I must say that even with all its faults, an
IETF meeting is an exhilarating way to spend one's week.
Thanks for your consideration of my thoughts.
Charlie P.
PS. My first attempt at posting this did not succeed.
I hope this is not a duplication.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02030;
25 Jul 92 21:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa18395;
25 Jul 92 21:00 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA02558>; Fri, 24 Jul 1992 14:07:31 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA02553>; Fri, 24 Jul 1992 14:07:29 -0700
Received: from nma.com by q2.ics.uci.edu id ac13787; 24 Jul 92 13:55 PDT
Received: from ics.uci.edu by odin.nma.com id aa09461; 24 Jul 92 9:42 PDT
To: raiken at nsf.gov
Cc: ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
In-Reply-To: Your message of Thu, 23 Jul 1992 08:28:05 -0400.
<9207231228.AA11664 at hub.nsf.gov>
Reply-To: Stef at nma.com
From: Einar Stefferud <Stef at nma.com>
Date: Fri, 24 Jul 1992 09:42:28 -0700
Message-Id: <9459.711996148 at nma.com>
Sender: stef at nma.com
Hi Bob -- The OIW rules are not generally used in so draconian a mode
as you suggest in, though they do provide a basis for a SIG Chair to
act or respond on a point of order when participation becomes an
issue. In some cases, a SIG will use this rule in a strict manner.
> Yes, actually - one possible method is to adopt something like the
> rule that the NIST implementors workshop (OIW) adopts - which is that
> a person or organization is not allowed to VOTE on a matter unless they
> have signed a statement that they are familiar with the issues and
> that they have attended at least 2 of the last 3 sessions (in this case
> the IETF meetings) in order that they are upto date on developments.
> Then leave it to the WG chair or peers to make sure that all are familiar
> with this and adhere to it.
And, to clarify, OIW does not require the signed statement attesting
to all that you called out, to attend the SIG meetings.
They do require signing for a "voting card" for the plenary, but this
is mostly to assure that any one company (or major division) is not
voting more than once on any issue. Once upon a time, they did not
use voting cards, and there was always a nawingthougt that they had no
idea who was voting. Signed voting cards resolved this feeling.
Like the IETF, there is no barrier of any kind to anyone who wishes to
attend, other than that they register and pay the fee, currently $220
for the week, or $180 daily. Late registration is higher.
It requires that same kind of strong SIG/WG Chair to deal with new
attendees. I recall at least one SIG thrashing for more than a year
in TUTORIAL mode before getting around to generating some text.
A big difference between OIW and IETF is that all decisions of the
OIW, other than appointment of the OIW Chair, are made in the OIW
plenary. All actions taken are thus actions of the whole OIW, and
there is no one at any higher level to rethink (and remake) any
decision. In this situation, it is required to have some definite
rules about who is entitled to vote.
But, I am drafting over from the "attendee quality" question into the
"IAB/ISOC Role" question. So it is time to stop. Cheers...\Stef
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02049;
25 Jul 92 21:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa18605;
25 Jul 92 21:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09042>; Fri, 24 Jul 1992 16:11:48 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA09036>; Fri, 24 Jul 1992 16:11:44 -0700
Received: from nma.com by q2.ics.uci.edu id af26426; 24 Jul 92 15:53 PDT
Received: from ics.uci.edu by odin.nma.com id aa09877; 24 Jul 92 14:47 PDT
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: Frank Kastenholz <kasten at ftp.com>, ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
In-Reply-To: Your message of Fri, 24 Jul 1992 11:21:37 -0700.
<9207241821.AA06412 at Mordor.Stanford.EDU>
Reply-To: Stef at nma.com
From: Einar Stefferud <Stef at nma.com>
Date: Fri, 24 Jul 1992 14:47:42 -0700
Message-Id: <9874.712014462 at nma.com>
Sender: stef at nma.com
I have to agree with Dave that reliance of the IETF on some Supreme
Authority (IAB, ISOC, The POPE, GOD) to make decisions for us when we
are unable (or unwilling) to make the hard choices at the working
level is not likely to work in our brave new open world.
Our problem is one of focusing the responsibility for mature hard
choice decision behavior right back down on the IETF. The IAB and the
IESG should conspire in this focusing effort to make the IETF workers
understand that they have a problem, and that they have to solve it,
cause no one else will be able to make a decision stick.
Provision of the required focus is what leadership is all about, so
saying that we don't want the IAB to make the hard decisions for us is
not the same as saying "IAB, go away, we don't like you!"
What we need is the meta level guidance that will help to sift the
decisions out of the pile of alternatives. thsi is what I am
suggesting be the purpose and the focus of the so called "meta-level"
call for proposals.
Best...\Stef
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02099;
25 Jul 92 22:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19490;
25 Jul 92 22:00 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA13342>; Fri, 24 Jul 1992 17:35:10 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA13337>; Fri, 24 Jul 1992 17:35:08 -0700
Received: from p.lanl.gov by NRI.Reston.VA.US id aa12778; 24 Jul 92 20:20 EDT
Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14)
id AA01928; Fri, 24 Jul 92 17:42:08 -0600
Received: by goshawk.lanl.gov (4.1/5.17)
id AA06807; Fri, 24 Jul 92 17:42:07 MDT
Date: Fri, 24 Jul 92 17:42:07 MDT
From: "Peter S. Ford" <peter at goshawk.lanl.gov>
Message-Id: <9207242342.AA06807 at goshawk.lanl.gov>
To: big-internet at munnari.oz.au, ietf at NRI.Reston.VA.US, noop at merit.edu
Subject: TUBA mailing list announcement.
The TUBA/TUCAN mailing list has been established. The purpose of this
mailing list is to discuss transitioning the Internet to using
addresses longer than 32 bits. The nature of the proposed transition
is that hosts will be dual-network stacked. CLNP (ISO-IP) is the candidate
network layer protocol at this time. It is envisioned that the
"regular" suite of Internet protocols and tools would run on
top of TUBA systems including SMTP, Telnet, FTP, various and sundry RPCs,
etc.
The mailing list is:
tuba at lanl.gov
and the mailing list maintenance address is:
tuba-request at lanl.gov
*** PLEASE SEND ALL REQUESTS TO BE ADDED TO THIS LIST
*** TO THE tuba-request at lanl.gov address
A starting point for discussion is RFC 1347 by Ross Callon
titled: ``TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal
for Internet Addressing and Routing.'' This can be retrieved from
nic.ddn.mil using anonymous ftp.
Current Agenda for discussion on mailing list (which is open to agenda bashing):
Establish overall vision of what TUBA is.
What is an "internet address".
id- entity identifier
loc-where the entity is in the routing topology
What is a Tuba Address, what can be done in the
context of CLNP.
How to route the Internet.
what is the hierarchy
what are the protocols: now and in the future
ES-IS, IS-IS, IDRP (?RIP,OSPF, IGRP?)
Impact on infrastructure:
DNS, SNMP/SMP, Routers, Operations, Management
Impact on Internet Protocol Suite:
IP, UDP, TCP, Telnet, FTP, etc.
Impact on Host Software:
OS interfaces
system libraries (socket, gethostby .., etc.)
toolkits (Novell, Apple comm toolkit, etc.)
What about OSI stack (TP-4 getting graveful close?)
Encapsulation on "everything".
Nature of Internet connectivity over time.
Prospects for Network address translation (nat).
Establish work plan to include:
trial implementations on a variety of platforms
routing and addressing plan
proposal for AFI==ISOC
Establish Working Group charter and submit to IESG.
I would like to especially encourage people who work on OS systems,
libraries, and toolkits to join this list since a major point of the
current TUBA RFC is that hosts will need to be dual network layer
stacked.
If you are interested in developing a trial implementation of TUBA systems on
*any* platform, please let me know.
Please feel free to add, delete and comment on anything in the agenda
listed above.
cheers,
peter
Peter Ford
peter at lanl.gov
Los Alamos National Laboratory
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ac02148;
25 Jul 92 22:25 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19981;
25 Jul 92 22:26 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA18332>; Fri, 24 Jul 1992 19:56:54 -0700
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA18328>; Fri, 24 Jul 1992 19:56:52 -0700
Date: Fri 24 Jul 92 19:56:51-PDT
From: Stephen Casner <CASNER at isi.edu>
Subject: Constructing the MBONE
To: IETF at isi.edu, members at farnet.org
Message-Id: <712033011.0.CASNER at ISI.EDU>
Mail-System-Version: <VAX-MM(219)+TOPSLIB(128)@ISI.EDU>
Those of us who worked on the audio/videocast of the Boston IETF were
gratified by the positive response. It is amazing that people are
already suggesting that this become a real service! We'd like to see
the experiment grow in coverage and functionality, and for that we
need help.
Since it may be a while yet before IP multicast routing support is
integrated into many production routers, we would like to construct a
semi-permanent virtual multicast network layered on top of the
physical backbone and regional networks. We've dubbed this the
Multicast Backbone, or MBONE.
An embryonic version of the MBONE was what we set up for the IETF
audiocast, and parts of it remain in operation since IETF. To extend
this network to the many more places that would like to participate,
we need a more carefully constructed topology. We need sufficient
hierarchy so that we can reach all the desired destinations with the
limited fanout (around 5) available from each multicast forwarder, and
so we can avoid sending more than one copy of any packet over T1 or
smaller links.
This is where all you forward-looking regional and backbone network
providers come in. You can provide access to the "DMZ" Ethernets and
other points near network nodes where the multicast forwarders should
be attached for best performance and lowest load. We're hoping that
you can also provide some of these machines to run the IP multicast
kernel and mrouted software (we're using mostly Sun SPARCstations now,
but other platforms are also possible) to distribute the multicast
traffic on to your customers.
Construction of the MBONE needs to begin NOW so that by the next IETF
the we will be ready to support an expanded audio/video/imagecast.
To organize this effort, we've established some regional email lists.
If you are willing to help, please send a message to the appropriate
request-list for your area:
ozaudio-request at internode.com.au Australia
mbone-eu-request at sics.se Europe
mbone-request at isi.edu US & other
NOTE TO END-USER SITES who want to participate in IETF multicasts:
We'd like to concentrate these lists on organizing the multicast
backbone itself. We ask that you contact your network provider
directly and encourage them to participate!
A few important points:
- Production network hardware and software need not be disturbed
since the multicast forwarding is handled by separate machines.
- Routing areas running MOSPF can join in, too, even better!
- We want this virtual network to remain in place to support
experimentation between IETF meetings, too, so the effort to set
it up is justified by more than three weeks per year of use.
- This is an experiment, not a production facility.
As Terry Gray pointed out in his message to ietf, this multicast
capability is being deployed "in advance of the sociological and
resource capacities of the Internet". Granted, there is the
possibility of over-use or abuse of this facility, so we need to work
together on mechanisms for monitoring and control as well.
We look forward to your participation.
-- Steve Casner, Steve Deering, Hans Eriksson
-------
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02161;
25 Jul 92 22:34 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa20136;
25 Jul 92 22:34 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20906>; Fri, 24 Jul 1992 22:18:25 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA20902>; Fri, 24 Jul 1992 22:18:24 -0700
Received: from nma.com by q2.ics.uci.edu id ac25526; 24 Jul 92 21:42 PDT
Received: from ics.uci.edu by odin.nma.com id aa10615; 24 Jul 92 21:35 PDT
To: Frank Kastenholz <kasten at ftp.com>
Cc: ietf at isi.edu
Subject: Re: Newcomers at the IETF
In-Reply-To: Your message of Thu, 23 Jul 1992 10:08:25 -0400.
<9207231408.AA15448 at ftp.com>
Reply-To: Stef at nma.com
From: Einar Stefferud <Stef at nma.com>
Date: Fri, 24 Jul 1992 21:35:28 -0700
Message-Id: <10613.712038928 at nma.com>
Sender: stef at nma.com
Frank -- How about signing up with INTEROP to do tutorial on the
workings of the IETF/IESG/IAB, et al?...\Stef
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02272;
25 Jul 92 23:30 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa21002;
25 Jul 92 23:30 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA28399>; Sat, 25 Jul 1992 05:59:13 -0700
Received: from GINGER.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA28395>; Sat, 25 Jul 1992 05:59:10 -0700
Received: by ginger.lcs.mit.edu
id AA11782; Sat, 25 Jul 92 08:57:04 -0400
Date: Sat, 25 Jul 92 08:57:04 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9207251257.AA11782 at ginger.lcs.mit.edu>
To: kasten at ftp.com, sollins at lcs.mit.edu
Subject: Re: thoughts on the Boston meeting
Cc: ietf at isi.edu, jnc at ginger.lcs.mit.edu
Frank, I agree with 98% of what you say about the need to be careful
in selecting chairs. The one point I would have to think about is this issue
of the chairs "not also be[ing] the primary engineer on the problem". I think
that your caution that the chair not have an ax to grind is a good one, but I
do think the chair ought to be technically knowledgeable about the area under
discussion.
If the WG goes off in a crazy direction (perhaps led by one strong
personality who has gone astray), or if the WG is unable to come to a consensus
on a lesser (and probably non-critical) point, it is my view that the chair
ought to have the latitutude to do something, and to do this he needs to have
the technical knowledge of the subject to do something reasonable.
Other than that, all good points. I hope someone is writing the
important points down! Oh well, I guess there's always the mail archive!
Noel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02284;
25 Jul 92 23:31 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa21021;
25 Jul 92 23:31 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29530>; Sat, 25 Jul 1992 07:22:18 -0700
Received: from shark.mel.dit.CSIRO.AU by venera.isi.edu (5.65c/5.65+local-6)
id <AA29526>; Sat, 25 Jul 1992 07:22:06 -0700
Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA02714
(5.65c/IDA-1.4.4/DIT-1.3 for <ietf at isi.edu>); Sun, 26 Jul 1992 00:20:13 +1000
Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0)
id AA08618; Sun, 26 Jul 92 00:19:55 EST
Message-Id: <9207251419.AA08618 at wanda.mel.dit.CSIRO.AU>
To: ietf at isi.edu
Cc: smart at mel.dit.csiro.au
Subject: Effective Working Groups
Date: Sun, 26 Jul 92 00:19:55 +1000
From: Bob Smart <smart at mel.dit.csiro.au>
For simple WGs it might be OK for the Chairman to do everything. For
more difficult cases it is better to split the work. Some aspects of
the MIME WG seem worth repeating:
1. Have a chairman who is separate from the RFC author(s) to push things
along, control unruly WG members, organize the rfc process.
2. Have more than one author. Then you have a ready made inner cabinet.
There is always pressure for kitchen-sink standard making, and it is
easier for 2 (or more) authors to stand up to the demand for just
one more feature to keep X and Y happy. If there is one author it is
more likely to seem that she is using her position unfairly to block
some idea.
Even if I could attend IETF meetings I'd still be more of a mailing-list
person. It is easier to think about someone else's contribution for
an hour or a day and then give a reasoned response. I'd like to see the
IETF make better use of electronic communication. The first step is
to make the mailing list of a WG work by having somebody look after it:
a. New people joining should get more than "you are on the list". They
should be told to read the archive ["Yes there is a lot of it but the
other people on the list have had to read it"]. They should ideally
be given some statement of the current state of the discussion, though
obviously that will be prone to get out of date very quickly.
b. The first posting of each person should get moderated. If it is at
all reasonable it can be forwarded to the list and she never knows it
was moderated. If it is complete rubbish or "please subscribe" it can
be intercepted and a bit of private discussion can take place first.
c. The problem with mailing lists compared with face to face meetings is
that it is very hard to get a feeling for what the group is thinking.
You need someone who can conduct surveys. Results should always be
posted to the list, with breakdown by participation rate [votes by
people contributing to the discussion can then be given more weight than
those of people just listening in]. This should perhaps not be done by
a partisan member of the group. It would be nice if the IETF had someone
obviously impartial who conducted these surveys on behalf of WGs.
d. It is important to do _something_ about people who are off the track
of the discussion or they'll just keep causing trouble. If they don't
understand what is going on they need to be straightened out. If they
have some idea and they aren't talking the language of the group then
someone needs to have a private discussion with them to get them in
tune. Typically this reveals that the person doesn't understand some
crucial point after which they shut up, or start thinking about the
real issues.
WGs might well profit by having a mailing list minder to do these jobs.
This is something that might be done by people away from the centre of
things who can't often attend IETF meetings but would like to contribute.
If there were a number of such people we might start discussing other
ways to use the Internet to improve the functioning of IETF WGs.
Bob Smart
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02590;
26 Jul 92 0:42 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa23046; 26 Jul 92 0:42 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03749>; Sat, 25 Jul 1992 10:01:52 -0700
Received: from kona.CC.McGill.CA by venera.isi.edu (5.65c/5.65+local-6)
id <AA03742>; Sat, 25 Jul 1992 10:01:42 -0700
Received: from expresso.CC.McGill.CA by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA16422 (mail destined for ietf at isi.edu) on Sat, 25 Jul 92 12:59:33 -0400
Received: by expresso.cc.mcgill.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
id AA17443; Sat, 25 Jul 92 12:59:29 EDT
Message-Id: <9207251659.AA17443 at expresso.cc.mcgill.ca>
In-Reply-To: Fred Baker's message as of Jul 23, 10:22
From: Peter Deutsch <peterd at bunyip.com>
Date: Sat, 25 Jul 92 16:59:27 GMT-0:02
In-Reply-To: Fred Baker's message as of Jul 23, 10:22
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: Fred Baker <fbaker at acc.com>, dcrocker at mordor.stanford.edu
Subject: A plan for the introductory session (was Re: Newcomers at the IETF)
Cc: ietf at isi.edu
[* You don't have to read this unless you're interested in a proposal
for thhe new-comer's tutorial session. It's over 200 lines long. < sigh >
I really should go outside and play... *]
[ Fred Baker writes: ]
>
> >> I like your suggestion to have an introduction to the ietf so much
> >> I'll ask a follow-on: How much time/energy should be devoted to
> >> tutorials about specific working groups? Assuming that this should
> >> be done outside of working group sessions, when should this be done?
>
> There's a couple of ways to go at that. My take is that the area
> directors could summarize the working progress in their areas, and then
> folks could button-hole individual working group chairs for the ones
> that they were interested in. Getting 80-odd working group chairs to
> stand up and say "Hi, I'm me, and we in the YARP-WG are working on yet
> another routing protocol" could be a dull drone.
I don't think we necessarily need 80 WG chairs to attend
the session. The way I see it, the goal is primarily to
educate new-comers into the _process_ of the IETF, not
necessarily educate them into all of the specifics of each
WG. You can't make instant experts of people by
summarizing months or years of work in one afternoon.
With this in mind, I see such a presentation following the
following structure:
1) A structural overview of the IETF process.
2) An overview of the IETF Secretariat.
3) A survey of current major issues.
4) A brief overview of each Area's current goals and activities.
5) Introduce a sampling of participants who are willing to
act as "Welcome Wagon" staff or mentors for newcomers.
Now some details.
The way I see it someone should give an overview of the
entire IETF/IESG/IAB process, its history and current
structure. This would include details on the types of RFC,
how Working Groups come into existance and function (and
what little is known about how to kill them!:-). This
should be followed by an overview of the complete
lifecycle of a particular document that is typical of the
process (or maybe a couple, to show the variety possible).
This would obviously need to be accompanied by some
written material so people don't have to remember it all
in one shot.
Of course, we should also give an overview of the IETF
Secretariat and the names of Megan, Steve and the others
who actually make it all happen with their sterling work
in the trenches (they don't have to be present, as long as
people learn that there is a division of labour and get
some vague idea about who does what). Giving the
new-comers these kinds of little details should hopefully
make things go more smoothly for both the hard-working
ground crew and the newcomers themselves.
Following this structural overview, I believe that a
summary of some of the current "hot button" topics would
be in order, along with pointers to the appropriate
on-line caches of relevant discussions, papers, etc.
For example, the intro for Boston might have mentioned the
coming address space/router table meltdown, the
controversies over IPv7/IAB actions and IDENT/AUTHD and
the fact that we are facing exponential growth in just
about any area touched upon by networking. There are
stirrings of new work at the applications layer (eg the
well-attended BOFs on resource location, NIR, etc) and
still a burning need for a deployed Directory Service. We
would also have mentioned the experiments in audio/video
multicast, which seem to have crept up on a lot of people
and taken them by surprise.
Such an summary of the hard issues can certainly be done
without taking sides. Continuing with my mythical Boston
agenda, it would have been useful to mention that there
are a number of proposals on the table for addressing with
pointers to the appropriate documents, along with pointers
to the appropriate mailing list archives for the history
of the Bernstein controversy. We would then mention which
sessions will be addressing each issue, if appropriate.
People would thus have a chance, if they wish, to play a
little catch-up, or at least ask more informed questions
from the start (of course, there is a danger that this
"setting the agenda" would in fact influence the whole
week's focus, but I think there are enough people milling
around that this is not really going to be a problem).
After this combination structural and issues overview, we
should present an overview of the goals and objectives of
each individual Area. For this, I suggest that we have
each of the Area Directors (or a designate) present an
overview of their current activities in support of those
goals and objectives. I'd like the Area Directors
themselves, just so people can get to know their faces and
this is an exception to my general feeling that we don't
need specific people to be present.
At this point we could wrap up with a sampling of informed
participants from each area who have been certified as
"user friendly". These could be working group chairs, or
just old-timers who want to help and who can avoid calling
newcomers "bozos" to their faces.
At this time, I think it appropriate for someone to say to
the new-comers (politely) "you are now welcome to
participate when you have something relevant say, but be
aware that there is usually considerable history you will
need to absorb before you are able to understand the
entire process. Please keep this in mind and try to
buttonhole people before the meeting if possible to get a
feel for where the group is coming from. this will help
things run more smoothly". At that point, we certify the
newcomers as "booted and running".
As for the proposal that we make new-comers wear a
particular coloured dot or silly beenie, well that does
seem just a tad like some kind of old-fashioned fraternity
hazing ceremony to me. It would allow curmudgeons to avoid
new-comers, and certainly would seem a priori to prejudice
the value of new-comers' contributions.
One of the things I think is most revolutionary and
wonderful about the Internet is that it shows how
irrelevant is so much of the information we use to judge
people. When I read a posting or respond to email, I most
often don't know the age, sex or educational background of
the poster and thus must consider their arguments on their
merits. If we stick a beenie on some people, we might be
blinded to the value of their contributions because of
our prejudices against "beginners".
Just think about it - that person may have the solution to
the address and routing table problems, but we would be
inclined to ignore their advice because they don't
remember CSnet or know what a Fuzzball is. Seems to me
like it goes against what makes the whole process work and
leads us to osteoporosis of the Internet backbone and
sclerosis of the regionals.
> Maybe a handout containing all of the working group charters would be
> helpful. Perhaps selecting the most popular working groups and
> having those five or ten chairs breifly summarize their work would be
> worthwhile.
Given that the almost entire process is staffed by
volunteers, I don't think we can force people to
participate in this. Even worse, some Working Group
chairs come equipped with more "user-friendly" interface
modules than others. The way I see it, the most pressing
need is not to bring new-comers up to speed on all of the
issues, but rather to educate them into the process. For
this you need people who communicate well, not necessarily
the most technically brilliant IETF contributors. I think
it is axiomatic that there is often little or no
correlation between these two skills (unless it is a
negative one. A lot of bright minds don't "suffer fools
gladly" and come across as hard and distant to new-comers.
:-)
I'm not arguing that we need the second string for the
initiation sessions, but rather that we should keep in
mind what we are trying to accomplish and use people with
the appropriate skills.
> April commented that most Working Group Chairs are doing it on their
> own time, and are volunteers. This is true of me; everything I write
> is written after my wife goes to bed. However, I personally feel a
> little odd chairing a meeting where I have no idea who half the people
> in the room are, and would welcome the chance to associate names with
> the faces. Also, let me relate an experience.
Well, once the new-comers have had a chance to hear about
the process and are equipped with the agenda for each
scheduled meeting, they should be pointed at the evening
social, with instructions to seek out the Working Group
chairs for the sessions they will be attending (finally, a
use for those coloured dots!) This is their chance to get
to know you and you them.
Given that we keep hearing about sessions with 200 people
and the reported 1/3 newcomer rate it doesn't seem
realistic that any Chair can get to know 1/3 of 200 people
in an afternoon and still touch base with all of the
old-timers as well. The best you could hope for is to
exchange words with some fraction of the interested
new-comers while they identify the players in the areas
they are interested in. Still, that's a pretty good start.
At least they will all have a somewhat better idea of how
the system works and might thus be less inclined to be
unintentionally disruptive.
So there's my 28 cents worth. Sorry for the length but in
the finest traditions of the IETF, a practical proposal to
shoot down seems better than idle speculation about what
"could be".
So, ready on the left? Ready on the right? ready on the
firing line......
- peterd
--
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02737;
26 Jul 92 1:22 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa24600; 26 Jul 92 1:21 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07566>; Sat, 25 Jul 1992 13:30:12 -0700
Received: from LANSLIDE.HLS.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA07562>; Sat, 25 Jul 1992 13:30:09 -0700
Received: from nms.netman (nms.hls.com) by lanslide.hls.com (4.1/SMI-4.0)
id AA01948; Sat, 25 Jul 92 13:28:27 PDT
Received: by nms.netman (4.1/SMI-4.1)
id AA19750; Sat, 25 Jul 92 13:17:33 PDT
From: Keith McCloghrie <kzm at hls.com>
Message-Id: <9207252017.AA19750 at nms.netman>
Subject: Re: Newcomers at the IETF
To: vcerf at NRI.Reston.VA.US
Date: Sat, 25 Jul 92 13:17:32 PDT
Cc: ietf at isi.edu
In-Reply-To: <9207231856.ab08315 at IETF.NRI.Reston.VA.US>; from "vcerf at NRI.Reston.VA.US" at Jul 23, 92 6:56 pm
Organization: Hughes LAN Systems
X-Mailer: ELM [version 2.2 PL0]
Vint,
> several people have suggested having the intro material available
> on-line as rfcs in addition to providing some briefings during
> ietf. Your point that not all come for the full week is a good one.
Newcomers may not be fully familiar with the mechanisms for obtaining
RFCs, and RFCs may not be fully uptodate. Thus, I think the suggestion
someone made to include introductory material in a newcomer's registration
packet (along the badge etc.) is a better mechanism which will also cater
to the folk who attend for less than the full week. Perhaps the registration
form could ask the question: "would you like to have introductory information
in your registration packet ?".
Keith.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02784;
26 Jul 92 1:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa25279; 26 Jul 92 1:49 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06880>; Sat, 25 Jul 1992 12:42:06 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA06876>; Sat, 25 Jul 1992 12:42:04 -0700
Received: from nma.com by q2.ics.uci.edu id aa11322; 25 Jul 92 12:29 PDT
Received: from ics.uci.edu by odin.nma.com id aa10917; 25 Jul 92 10:31 PDT
To: ietf at isi.edu
Subject: Re: Newcomers at the IETF
In-Reply-To: Your message of Thu, 23 Jul 1992 11:32:05 -0600.
<9207231632.AA53305 at hal.gnu.ai.mit.edu>
Reply-To: ietf at isi.edu
From: Einar Stefferud <Stef at nma.com>
Date: Sat, 25 Jul 1992 10:31:55 -0700
Message-Id: <10915.712085515 at nma.com>
Sender: stef at nma.com
I expect that what we need here is to synthesize an action plan from
all these good ideas. So, I see a theme in this thread that I want to
sift out. Here is a try...
> From: Jeff Hughes <jeff at col.hp.com>
>
> I understand that there are some RFCs that describe some of the standards
> process (RFC1310?). Still, it would be nice to have some kind of introduction
I find that being told at the meeting that there is an RFC that I
should have read, or worse, a set to read, that would have given me
general background for how to behave and how to contribute, is not an
actionable idea, at that time at the meeting, unless that document is
also available at the meeting.
So, how about making copies of such stuff available for whoever (new
or old timers) wants/needs it at the meeting. For efficiency, this
material should be condensed into a "Working With the IETF" RFC, which
people can get read before attending, or get and read while attending.
It can also contain additional info on how to deal with working groups
via netmail.
In short, it seems to me that much of the desired information could be
placed in an RFC and not require oral presentations at the IETF. Oral
presentations, with graphics are nice, but they require attendance at
specific times, which are not always convenient (or even possible),
and they reduce us to oral history technology in an age of mobile
text/graphic technologies. We need handouts in any case.
> From: Jim Culbert <culbert at iesl.mit.edu>
>
> Anyway, I plowed through this virtual gold mine of information contained
> in the online RFCs filling in the gaps in my understanding of the way the
> internet world was built and works.
>
> I was very impressed with what I had "discovered" and with the philosophy
> and management that was evident in the organization.
>
> So along comes this announcement on my newly subscribed ietf mailing
> about this IETF thing. Given the tone of the announcement, I felt that
> I might be "in the way" if I attended. I tried mailing
> the list manager to find out whether it was appropriate for me to
> attend but the end result was that I was uncertain and I opted not to
> go.
Anyone that puts this kind of effort into learning about the IETF and
how it works, should always feel welcome. This kind of participation
is not any kind of problem! This point should be made in the
handouts.
> From: Fred Baker <fbaker at acc.com>
>
> At the Honolulu IETF (my second), I attended a number of meetings. At
> one point, I dropped in to observe one of the policy-based routing
> architecture working groups. Someone (I don't recall whom, but I
> assumed at the time that it was the chair) ejected me from the room
> with the assertion "this working group is a closed group," and I forever
> since have had the irrational feeling that I am not welcome in that
> particular domain. The person, by the way, seemed as uncomfortable
> ejecting me as I felt being ejected. Had I been able to talk with the
> person earlier, learn the ground rules, and find out what was probably
> the truth, that only one session of that working group was going to be
> closed during the whole week, the incident could have been avoided.
It should be quite simple to mark closed sessions on the time
schedule, and to put "Closed Meeting" on a meeting room door. Such
signs should note that other meetings at noted times/dates are not
open. In fact, I noticed no signs on any doors at the Boston Meeting,
and found it very hard to determine what room I wanted to be in.
This kind of problem is simply solved with a bit of thoughtful
signing. (Handwritten should be fine!)
> From: petrilli at gnu.ai.mit.edu
>
> Points that would have helped (or at least been of interest) when
> starting with IETF/IAB, in my opinion:
>
> 1) History of IAB/IETF, and WHY they are there, and perhaps an
> explanation of why they are so different from the ISO
> groups. This should also include perhaps a 5-10 minute
> ``History of ARPANET/Internet,'' for those who don't know.
This can be provided in written handout form.
> 2) How an RFC is created, start to finish, and a closer look
> at what it has to go through to become an Official
> Protocol.
This can be provided in written handout form.
> 3) Expected behavior and qualifications when you participate
> in a WG. While not everyone may have these qualifications,
> it should let people know who should participate, and who
> should just sit there and listen.
This can be provided in written handout form.
> 4) REINFORCE the idea that you should READ the working-draft
> before entering the WG.
This can be provided in written handout form.
In summary, it seems to me that we need not make a big production of
this introduction business. Much of it can be condensed into a
readable RFC. The key, as I see it, is to also make it easy to ...
GET A COPY AT THE MEETING!
Now, with this basic document available, I think an Intro Session on
Sunday PM, to make newcomers feel more welcome, to help them identify
some (but not all) of the players, and to offer a question/answer
opportunity, and to get them into the feel of the whole thing, would
be a great idea. It should be followed with the traditional informal
Gathering of Old and New Friends, which I always try to attend.
This session should also provide some background information on the
currently hot topics that are being addressed, etc. Let the attendees
all get to know what is going on in the ensuing melee.
Just lets not overload this Intro Session idea right away with stuff
that should be available and consumed in readable text form.
Cheers...\Stef
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02925;
26 Jul 92 3:45 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa27122; 26 Jul 92 3:46 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06886>; Sat, 25 Jul 1992 12:42:10 -0700
Received: from ics.uci.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA06881>; Sat, 25 Jul 1992 12:42:06 -0700
Received: from nma.com by q2.ics.uci.edu id ab11322; 25 Jul 92 12:29 PDT
Received: from ics.uci.edu by odin.nma.com id aa10934; 25 Jul 92 12:23 PDT
To: ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
In-Reply-To: Your message of Thu, 23 Jul 1992 14:49:50 -0500.
<9207231949.AA06498 at xap.xyplex.com>
Reply-To: ietf at isi.edu
From: Einar Stefferud <Stef at nma.com>
Date: Sat, 25 Jul 1992 12:23:01 -0700
Message-Id: <10932.712092181 at nma.com>
Sender: stef at nma.com
Another theme seems apparent in this thread. I hope I captured it here...
> From: Frank Kastenholz <kasten at ftp.com>
>
> i think the idea of telecasting the sessions is orthogonal to what i
> have perceived as "the major real problem".
I absolutely agree. This is fascinating technology, but it is not a
solution to the problems of WG Productivity!
Frank is also right on the mark to observe that the solution involves
a mix of things to be done...
> 1. divide the w.g. session up into talkers and listeners and make a ...
> 2. have a well written w.g. charter. the charter could tightly bound ...
> 3. set an agenda for the w.g. meeting and stick to it. topics not on the ...
>
> all of these methods require a strong chair. this may be the problem
> our chairs have been chosen for their technical abilities, for their
> interest in the problem, etc. our chairs have NOT been chosen for
> their abilities to get the working group moving and produce results.
> perhaps this is what the iesg should do when chartering a w.g. and
> selecting a chair. if we look at past chairs and see who let a w.g.
> wander and who kept it focused and tried to select chairs out of the
> later group we would improve things a lot.
Well, I doubt that ALL CHAIRS have NOT been chosen for their ability
to be A GOOD CHAIR, and we need to have ways to grow NEW GOOD CHAIRS.
> .............................................the problem is how do you
> build up the group of "good" chairs? when a wg is formed, the chair
> could be selected as it is done now -- but the iesg must keep an eye
> on the wg and if the chair lets things wander, the chair should be
> replaced. eventually good chairs will be found.
I think we will get a lot of mileage out of just making the obvious
point that there are good chairs and not good chairs, and the good
chairs have certain things in common. Do we have an RFC on "How to be
a GOOD WG CHAIR? Sounds like a good thing from someone to write.
In this regard, I want to recall my own experience at taking a SIG
Chair in the OIW, at a time when I was the obvious choice for the
Registration Authority SIG, but had no experience as a Chair. I did
not fair too well for my first meeting or two. But, I identified a
mentor to give me advice. An ExChair of another SIG, whom I respected
for being able to progress things no matter what happened. So, I was
able to learn what I needed to learn, with quiet mentoring by my own
arrangement.
Now, I do not think we should appoint a mentor for all new WG Chairs,
but we should encourage New WG Chairs to select a mentor from among
those Chairs that they have found to be properly effective. When
needed, we can all help a new Cahir to find the right mentor. Thus,
we could put in place a formally informal means for growing New WG
Chairs as needed.
I don't generally like the idea of setting up bureaucratic means for
making chairs more effective, such as hard requirements for getting
documents out well before meetings, etc, et al. Much better to use a
mentoring approach and back it up with documented advice about the
value of getting meeting materials out well in advance of the
meetings. This documentented advice, coupled with peer pressure
should do the trick.
Post IETF evaluation sheets would also provide powerful inducements.
They should be anonymous, and should be taken seriously, with a grain
of salt.
> now that i think of it, i can see a case that the chair should not
> directly be one of the people trying to solve the problem that the w.g.
> is trying to address. the job of the chair is to keep the w.g. moving
> -- an administrative job. the chair should not also be the primary
> engineer on the problem, otherwise the chair may end up being biased
> in an unacceptable way.
This is very true! But the Chair had best understand the technology.
> don't get me wrong, i think that telecasting the sessions is a great
> idea... with cheap bulk storage, we could archive the entire w.g.
> session on disk ...
This sounds very useful, but how are we going to maintain the Video
Crews, after they have tired of playing camera-person? I can see how
they will do this as part of the effort to explore and experiment, but
as permanent IETF Meeting Duty, we will need to hire the help.
Lets see, 11 union cameramen, with 11 camera and recoding setups, for
five 10 hour days = $$$$$?
Can we recover costs by the sale of recordings?
> From: "Evan R. Wetstone" <evan at is.rice.edu>
> A few thoughts on April's thoughts on the Boston IETF:
>
> Point number one (changing the time slot of the 7-10 sessions) is an
> excellent idea...I was at a few BOF's in that time-slot in which a
> fair number of attendees had not had a chance to eat dinner. And
> there were some in which I came in late because I couldn't make it
> back from dinner in time....
Yea, Verily. Also, we should try to get the hotel to cater to our
schedule, or adjust our schedule to their restaurant hours. One of
the main Hyatt Restaurants did not open till 6PM, and it was barely
possible, with serious effort and attention, to get in and complete
dinner before the 7 PM meeting time. A High Stress Generator!
> And I wholeheartedly support point number 5, "WGs should be as open as
> possible. Competent people do not appear ready-made; people grow to
> be competent. The IETF should foster the growth of our future
> leaders."
>
> If we try to limit (close) the WGs, we stand an excellent chance of
> crippling ourselves down the road. It's important to keep a flow of
> "new blood".
Absolutely! Furthermore, closure puts us in risk of unfairness charges.
> From: Bob Stewart <rlstewart at eng.xyplex.com>
>
> Yes, yes, yes. Noel is right. As long as the real designers and
> implementors actively and aggressively participate in meetings and
> mailing lists, with, as he put it, the engineers' shared goal of
> "let's pick the best design we can on a technical basis" we can
> maintain technical control. But that means discussions have to be
> moderated by people who will speak up when the topic wanders or
> becomes too self-serving. And I don't mean by an IESG or an IAB, I
> mean by working group members and chairs. Such speaking up is best
> when it comes across as group consensus, objectively motivated, and
> NOT a personal attack. It's an iron fist in a velvet glove. It has
> to be a clear constraint that we will NOT compromise technical quality
> just to shut people up. An open process does not mean all our brains
> have to fall out.
Yes, of course, consensus decision rules also apply to decisions about
the mode of operation in the WG meetings. The WG Chair should not be
left twisting in the wind by the others when confronted by
inappropriate attendee behavior.
But, the Chair must still act as Chair! As I read all this, FOCUS is
critical, and the CHAIR has the job of guiding the development of
consensus based focus.
Just having a well focused Chair is powerful, but having a well
focused WG is awesome. Focus, Focus, Focus!
Cheers...\Stef
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03521;
26 Jul 92 9:46 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa02141; 26 Jul 92 9:46 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14153>; Sat, 25 Jul 1992 22:09:01 -0700
Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.65+local-6)
id <AA14149>; Sat, 25 Jul 1992 22:08:54 -0700
Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
for ietf at venera.isi.edu id AA00552; Sat, 25 Jul 92 22:06:46 -0700
Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI)
for @sgi.sgi.com:ietf at venera.isi.edu id AA07535; Sat, 25 Jul 92 23:06:43 -0600
Date: Sat, 25 Jul 92 23:06:43 -0600
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Message-Id: <9207260506.AA07535 at rhyolite.wpd.sgi.com>
To: ietf at isi.edu
Subject: Re: thoughts on the Boston meeting
jnc at ginger.lcs.mit.edu (Noel Chiappa) writes:
> ... the way the people who *are* the
> IETF act and think) itself is very resistant to people who come in with the
> goal of getting X for their company. ...
In time implementors often become managers and even product managers,
and are compelled to think nasty commercial thoughts. Even some who
consider themselves purely technical can allow concerns about
development and other business costs to affect their preferences. An
entrance exam would not exclude people with non-technical concerns.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
