--On Friday, 18 January, 2002 07:14 -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
Squeezing time out of turnip...
Folks,
There has been some suggestion about having a working meeting
after the Sunday reception. I'm inclined to think that trying
to have it afterwards (after socializing
AHA! A modification of my prior suggestion that the sponsor
greetings, technical presentations, and routine reports (IANA, RFC
Editor, possibly IRTF) might should simply be presented via the WEB,
I here suggest an interesting addendum:
At the Registration, reception. do a presentation of
On Fri, 18 Jan 2002, Dave Crocker wrote:
There has been some suggestion about having a working meeting after the
Sunday reception. I'm inclined to think that trying to have it afterwards
(after socializing and alcohol) is problematic.
Yes, but (as others have suggested) moving the social to
On 1/17/02 12:03 PM, Michael Mealling [EMAIL PROTECTED] wrote:
...
The two negatives are that a) some people do not work on Sunday, and 2)
those currently traveling to the IETF on Sunday would be forced to do it on
Saturday.
That said, there are enough people who take advantage of the
--On Saturday, January 19, 2002 17:32 -0800 Lixia Zhang [EMAIL PROTECTED]
wrote:
If talking personal preference...
I would rather prefer not to have anything officially scheduled on Sunday
since that fundamentally requires we leave for the trip one day earlier.
Friday is not too good
John Klensin wrote:
* And should the IAB try to control microphone time, or is it
better to let people explain their views at whatever length that
takes?
One simple scheduling algorithm would be to have two microphone queues:
one for those speaking for the first time and one for those
Squeezing time out of turnip...
Folks,
There has been some suggestion about having a working meeting after the
Sunday reception. I'm inclined to think that trying to have it afterwards
(after socializing and alcohol) is problematic.
But what about having a 90-120 minute plenary
On Fri, 18 Jan 2002 07:14:24 PST, Dave Crocker [EMAIL PROTECTED] said:
Sunday reception. I'm inclined to think that trying to have it afterwards
(after socializing and alcohol) is problematic.
Geeks on booze is actually OK if you're socializing - you get the most
AMAZING war stories that
My two ag.
IETF Community,
During the London IETF Plenary, there was general consensus that
the IAB and IESG should separate their plenaries to give more
time for discussion of general architectural issues in the
former. We did that in Salt Lake City, with the IESG Plenary in
its
But what about having a 90-120 minute plenary
immediately BEFORE the Sunday reception?
Besides technical presentations, IANA report and the like, it could include
the IAB time, since the IAB is about 'strategic' issues. (Having the IESG
later in the week is useful
At 12:43 AM 1/17/2002, Rodney Thayer wrote:
If we seriously used the time on friday, thus making thursday
night more legitmate to schedule staying in town, that would help.
I'd be curious to know what would define using Friday seriously. We do
usually put meetings on Friday which also have a
On Wed, 16 Jan 2002, John Klensin wrote:
[snip]
* And should the IAB try to control microphone time, or is it
better to let people explain their views at whatever length that
takes?
Definitely. How aggressively is another question (mainly a function of
people's interest in the subject and
I think two plenary's is a good idea.
If we seriously used the time on friday, thus making thursday
night more legitmate to schedule staying in town, that would help.
also would mitigate the horrible double booking of wg meetings
I think devoting Thursday night to a plenary is one factor
* If so, should we continue with IESG on Wednesday and IAB on
Thursday, or should we alternate them (or adopt some more
radical schedule change -- probably too late for Minneapolis at
this point).
I like the idea of keeping to the two-plenary schedule at every IETF.
* And should the IAB
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred At 12:43 AM 1/17/2002, Rodney Thayer wrote:
If we seriously used the time on friday, thus making thursday night
more legitmate to schedule staying in town, that would help.
Fred I'd be curious to know what would define using
Matt == Matt Crawford [EMAIL PROTECTED] writes:
Matt I think devoting Thursday night to a plenary is one factor that
Matt helps to undermine Friday's status as a real working day.
Matt In most cases, Tuesday noght could have been used for a plenary
Matt with no adverse impact
A couple of things happen with Friday meetings.
One is, there aren't enough of them. It makes it hard to justify
staying the extra day.
The other thing is, recently, they've had a habit of scheduling
multiple common interest meetings on top of each other, like
PKIX and PGP, or two security
At 02:04 PM 1/17/2002 -0500, Jeffrey Altman wrote:
Sunday with little to do other than catch up on work that really
should have been done before I arrived. So maybe doing more on Sunday
would be a possibility.
This is an interesting suggestion.
The two negatives are that a) some people do not
At 01:42 PM 1/16/2002, John Klensin wrote:
* Should we continue with the two-plenary model? Should we do
so at every IETF, or consider some sort of periodic or
occasional schedule?
The two plenary model is good since it gives us time needed to address the
issues.
If people want to participate,
-BEGIN PGP SIGNED MESSAGE-
Rodney == Rodney Thayer [EMAIL PROTECTED] writes:
Rodney I think two plenary's is a good idea.
Rodney If we seriously used the time on friday, thus making thursday
Rodney night more legitmate to schedule staying in town, that would
Rodney
On Thu, Jan 17, 2002 at 11:34:35AM -0800, Dave Crocker wrote:
At 02:04 PM 1/17/2002 -0500, Jeffrey Altman wrote:
Sunday with little to do other than catch up on work that really
should have been done before I arrived. So maybe doing more on Sunday
would be a possibility.
This is an
Jeffrey Altman wrote:
Just to add my experience. I find that in order to get
better airline rates I am forced to travel into town on
Saturday. So I'm in town on Sunday with little to do
other than catch up on work that really should have been
done before I arrived. So maybe doing more on
On Thu, 17 Jan 2002 12:17:52 PST, Michel Py said:
Sacramento to Minneapolis, no connections:
- Arrive Minneapolis Sunday afternoon, leave friday afternoon: round trip $1049
- Arrive Minneapolis Saturday evening, leave friday morning: round trip $289
SAME AIRLINE (Northwest), same planes.
Sunday with little to do other than catch up on work that really
should have been done before I arrived. So maybe doing more on Sunday
would be a possibility.
This is an interesting suggestion.
The two negatives are that a) some people do not work on Sunday, and 2)
those currently
I've known several folks who have Sunday booked solid with
business/design-team/etc meetings weeks before the actual IETF begins.
I would personally prefer extending into Friday...
aol me too /aol
randy
I actually think our scheduling is within epsilon of optimal. Five days
(currently Sunday evening - Friday morning) seems to be about as much
as we can handle anyway. No matter which day of the week we end on,
many people are going to leave a bit early, and the last meeting slot
is going to
Responding to the total collection of this thread.
You all could save a lot of group meeting time by publishing all
those regular Reports (RFC-Ed, etc, et al) on the IETF Web site or
via EMail. After all they are mostly cut and dried with no
discussion, prepared long in advance.
Further,
proposal:
- each ietf: have the usual reports (rfc editor,...) on wednesday evening
- alternating IAB and IESG plenaries on wednesday (after reports) at each
IETF:
ie. minneapolis: IAB plenary on wednesday (after reports)
yokohama: IESG plenary on wednesday (after reports)
At 04:42 PM 1/16/2002 -0500, John Klensin wrote:
So, we have several questions and request comments and
discussion either to the IETF list ([EMAIL PROTECTED]) or the IAB
one ([EMAIL PROTECTED])...
I think two plenary's is a good idea.
If we seriously used the time on friday, thus making
29 matches
Mail list logo