hi pekka, it is interesting to hear your opinion on these issues. i would like to point out a few things: - there have been a number of discussions about the bandwidth broker concept in the past and the disadvantages are known. (my personal opinion) if it boils down to the protocol details then the difference between the rsvp architecture with a pep/pdp and a bandwidth broker is not hudge. the central entity which performs the authorization (or policy) decision was already mentioned. - from a signaling protocol point of view there is little difference between path-coupled and path-decoupled signaling in many cases. even path-decoupled signaling is path-coupled in some sense - you do not want to signal your messages to networks where the data traffic will never flow through. one big difference is the discovery mechanism. you are certainly right with your observation that you could use a number of different discovery mechanisms to communicate with devices along the path. if we can learn something from rsvp with this respect then it should that multiple mechanisms for discovering an node along the path has to be supported - not only router alert options. i think such a decision would increase the number of usage scenarios. btw, you might not know about the path-decoupled signaling (pads) bof (see http://www.ietf.org/ietf/03mar/pads.txt) where people spoke about reusing path-coupled signaling protocols in order to provide path-decoupled signaling. - denial of service issues with the router alert option: it is true that router alert option processing is slower than packets which do not have the router alert option set. however, i am not sure whether this is truely a big issue based on the most recent information i saw (see http://www.welzl.at/research/projects/ip-options/). furthermore, i always had the impression that other mechanisms even introduce more denial of service risks. for example: if you have your bandwidth broker example then you need to deal with dos issues against this device as well (and there are plenty of them). basically, you need to address denial of service issues at any place, regardless of the specific solution. - firewall issues: you argue that an operator might not allow users to open pinholes. why not? if you authenticate and authorize users then you can make a decision which user is allowed to open a pinhole. furthermore, you already do it today with more complex mechanisms based on sip signaling and midcom. it would be worth to have a discussion on the following issue: * path-coupled signaling is very benefitial if you have complex topologies where routing symmetry causes packets towards different destination addresses to hit different firewalls/nats. melinda shore raised this issue in midcom (i guess for the first time). you can find her draft at http://www.watersprings.org/pub/id/draft-shore-friendly-midcom-01.txt. * will people deploy firewalls in the future? (particularly since people tunnel everything through http)? (my personal opinion is yes, they will.) - nat issues: why do you think that nat handling is trickier? in fact the case of a data receiver being behind a nat is (based on our investigations) rather a nice case since you are assured that the data packets traverse this nat (if you publish the obtained ip address, transport protocol + port as your contact address). with a data receiver behind a firewall (in case of complex topologies and routing asymmetry) things are more complicated (without making additional assumptions). you mention some ipv6 specific solutions that would fix the problem automatically. could you please elaborate? - you mention a few issues with regard to qos and charging. this is a complex issue which we (engineers) are not really good in making a decision. i have read a number of papers by prof. odlyzko (see for example http://www.dtc.umn.edu/~odlyzko/doc/pricing.architecture.pdf). these papers are nice to read but it is hard to estimate how individual issues raised in these documents influence our work (and even in which time frame). ciao hannes _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf