Subject: ISSUE: Meeting scheduling

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 27 Jun 2003 09:53:25 -0700

>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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 28 Jun 2003 11:07:31 -0700

--On 27. juni 2003 09:53 -0700 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> 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.

actually there is ..... you can ask them.

We even did this formally some time ago - we had a BOF in Salt Lake City (I 
think) dedicated to "why do people invent UDP-based protocols".

As I remember, it was fairly entertaining, including people who said "next 
time I'll use TCP, so I don't have to bother adding all its stuff back into 
the protocol later"......

> Take a case in point, use of UDP for short transactional messages. TCP/IP
> is fine for longstanding persistent connections. It is clumsy and
> 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.

Old fogey mode.......

People tend to forget things like Belsnes' old proof that if you need two 
parties to exchange data, and both ends have to know that the data has been 
successfully transferred, it is IMPOSSIBLE to do it in less than five 
packets. Just because something's an engineering requirement doesn't mean 
it's possible. (the even older fogies will no doubt correct me if I got the 
details wrong....)

And, of course, networks have been brought to their knees by UDP-based 
"simple" protocols that just didn't think about congestion. I've had to 
debug some of those situations.

(DNS works because a server doesn't care whether the client got the answer 
or not - it's the client's business. But not all "quick" protocols are 
allowed to be that careless...)

Mumble.... I sometimes wonder whether part of our structural problem is 
that neither the IETF nor any other organization in the world (AFAIK) 
really teaches protocol design as an engineering skill.

               Harald