If we are going to have experiments in IETF week then lets do the thing right
and have a process. In particular -
Proposer MUST write an Internet Draft prior to the experiment stating:
1) Purpose - the information to be obtained
2) Method - what it to be done
3) Resources - what will be required of the organizers
4) Expected outcomes - what it is expected that the experiment will tell us
5) Forcing functions - if the experiment is intended to be a forcing function
for infrastructure deployment
6) Justification for spending the time and effort
Proposer MUST write up the results of the experiment and submit to the RFC
I don't think there is much point in just running the same experiment every
time. It will become a tradition and the last thing this institution needs is
more traditions that have outlived their utility cluttering up the process.
And we should probably have a separate mailing list to discuss such proposals.
IPv6 Next Steps
The Philadelphia IPv6 outage tested one specific aspect of the transition - is
there an IPv6 network on the other side to connect to in due course, is it
possible to run a pure IPv6 network?
I think that that is one useful data point to test but not the only significant
data point. In particular the biggest problem we have is the exhaustion of IPv4
space. The most important network test to make in my view is whether current
generation machines work acceptably on an IPv6+NATv4Share connection for
typical end user tasks.
By 'acceptably' I mean ZERO-click administration. No configuration tweaks
whatsoever. If a product does not run out of the box it has failed.
Secure WiFi Connection
I would like to see some demonstration of the fact that the default WiFi
configuration on all existing platforms provides zero protection against an
'evil twin' WiFi attack. Using WPA protection has little value unless you have
mutual authentication. The current specs don't allow for that.
IETF mailing list