Hi Harald, the problem with a number of the protocols is that they are later used in a different context. Take SCTP, for example. Initially, it was meant to be used for server-to-server communication. Now, some folks obviously want to use it in a different way. Whether this is a good idea or not is a separate question but then you obviously run into problems. The real problem, however, starts when you do not consider the best current practice in a certain environment. Folks working in the RAI area have noticed a couple of years back that it is a really good idea todo everything to deal with NATs even if the results are not beautiful nor lightweight. This has a lot todo with their deployment experience. When you go to other areas in the IETF this deployment experience is smaller or missing at all. Consider Mobile IP, for example, where many optimize the last hack out of the protocol in the believe that their extensions will run only in an IPv6 environment without any middleboxes. This has todo with the lack of deployment of many of the mobility protocols. When you want to design a protocol with extensibility in mind then you need to consider these aspects. Needless to say that protocols tend to get more complex when you support a lot of flexibility. I agree with your comment about SCTP running on top of UDP to a large extend. Ciao Hannes Harald Tveit Alvestrand wrote: > While I disagree with Jonathan's assertion that we should insert an > entirely useless (for all but NAT) UDP header in front of all new protocols > we design, I also disagree with Joel's (implicit) assumption that we can't > implement congestion control on top of UDP. > > SCTP mapped on top of UDP would have exactly the same congestion control > properties as SCTP mapped on top of IP. > > Once I've read the draft, I may have other opinions. > > Harald > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > http://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf