ISSUE: Meeting scheduling

[Hallam-Baker, Phillip]

>Moreover, the flexibility of the agenda is such that IMHO it is not 
>possible to make make reasonable part-time attendance plans after the 
>agenda has firmed up .. and then it is too late and costly (which 
>was the one of the most important motives to begin with) already.

This is a big issue if you are trying to arrange related meetings
at the same time. We had to arrange the JamSpam meeting the week
before the IETF rather than the same week because we could not know
which day the ASRG meeting would be held.

There is a real problem with last minute changes that occur to the
agenda. I have booked travel twice and had to rebook because the 
meeting I was going to attend had moved. Other times I would have 
made the visit much shorter. This is an important issue if you
have a 2 yr old who keeps telephoning you to ask 'where's daddy'.


I sense a mixed message here. On the one hand we have people who are
complaining about 'tourists' crusing by WGs for something that might
interest and on the other we have folk who are complaining that few people
have a high level overview of what the IETF as a whole is up to.

The most useful IETF sessions are frequently the plenaries when someone
actually gets up and presents an idea to the whole membership. I think it is
incredibly wasteful to bring 1400 people together in the same place at the
same time and then spend all the time broken into little groups.

A lot of times IETF discussions get rulled by standing predjudice and dogma
that there is no way to challenge. Mention PKI and you will get a speil
about how the PKI systems of ten years ago don't work. Mention security and
you get a confused application of the end to end principle to security that
is completely inappropriate. There are much better analyses of what is going
on.


There are a lot of complaints about groups re-inventing stuff that has
existed before. But the mechanisms for communicating are limited and tend to
be unidirectional. There is no way to ask why people have to reinvent.

Take a case in point, use of UDP for short transactional messages. TCP/IP is
fine for longstanding persistent connections. It is clumsy and
unsatisfactory for short term connections that require perhaps one to four
packets in each direction in a simple request/response format. It should not
be a surprise that people keep reinventing this type of mechanism, it is
supported by a valid engineering requirement.

		Phill