As longs as I've attended meetings (13 years) and followed the feedback on the IETF list re. meeting network support, the expectation has always been that there would be a very high priority set on creating and maintaining a smoothly operating network to support the meeting. New technologies were deployed along side of the production network and not in lieu of it. It is really absurd to disrrupt the master network to conduct an experiment. I spend a high percentage of my professional life configuring and debugging network hardware and software. There is no way I'll risk any configuration change to my 'production' laptop to attempt to adapt to an experiment/demonstration. The risk of system corruption is too high and I don't have the time or inclination to bring along an image backup/restore to make it safe. Find the funding to staff and equip an experimental lab and network. Make it available in the plenary if you wish as an alternative, but primarily provide it in a dedicated space for those with the time and inclination to experiment. Provide the software and system pre-req guildance ahead of time. Make sure you have Windows/Linux/Apple network experts in the room and we might have a really useful experiment. I for one would consider bringing an extra laptop which could be used on the experimental net and which I would willingly install software, etc. Otherwise forget it ... the direct and indirect cost incurred by each attendee dictates that the IETF make sure their time is well used. This experiment doesn't meet that objective. Dave Morris On Thu, 20 Dec 2007, Mark Andrews wrote: > > But the IETF network has for as long as I've attended (12 > years) been a proving ground for new technology. > > DHCP, multicast, wireless, IPv6, etc. > > I'm quite happy to see more testing of future technology / > configurations on the network. > > I'd like to see DNSSEC validation deployed on the recursive > DNS servers advertised by DHCP to the network. I'd like > to see IETF.ORG signed. I'd like to see SIG(0) deployed > on the recursive DNS servers. > > The IETF net should be a actively hostile network from a > security perspective once we have the technology to detect > and mitigate the attacks. If you ask a plain DNS question > you should expect to get a compromised answer. > > Most of us don't harden our systems nearly enough. We > should be able to do work with hardened system otherwise > we have failed as engineers. > > Mark > > > Expectations of support infrastructure change as technology evolves. > > > > In those days, we got along just fine without cell phones as well. > > > > Based on new technology our co-workers expect a level of internation not > > previously possible. We are also used to immediate access to reference > > material and as one person noted, they may take advantage of local laptop > > access to the presentation material to be able to read it. > > > > ... > > > > How things were done in the past really has little bearing on how we do > > then now. > > > > > > On Wed, 19 Dec 2007, Stephane Bortzmeyer wrote: > > > > > On Tue, Dec 18, 2007 at 01:45:24PM -0500, > > > John C Klensin <john-ietf@xxxxxxx> wrote > > > a message of 57 lines which said: > > > > > > > Between this and apparent efforts by the IAOC, IESG, and sponsor to > > > > deliberately disrupt the network, this is beginning to sound like > > > > the meeting to miss. > > > > > > I am not old enough to have personal experience of the oldest IETF > > > meetings but I've heard that there was no Internet connectivity at all > > > at these times and yet the IETF was able to work. > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf