Like most I suppose, I have not been following any of the IPv10 comments, or at least trying not to. I do applications and for me it is not just a matter of profound disinterest to know how my packets are moving from A to B, it is a layering violation to care. (Or at least it is until it isn't. There are times when I do care but I try to avoid that).
So looking back on the thread, I think that there were some problems on both sides of the argument. When I look at some of the responses, I ask whether the same responses would have been made to the Web or to PKIX or SSH or to any of the application layer work that the IETF likes to consider success stories. And of course, they were.
So how do we distinguish between important and unimportant work? I don't think it can be through consensus alone. Consensus is the OUTPUT of the IETF process, it cannot be an input and it certainly can't be a gating function on deciding to work on problems at all. Nor do I agree that the same criteria should apply at every level in the stack. If the narrow waist means anything it is that we have to have very good reasons for making changes at the waist. And if the bar there needs to be higher, that argues it should be lower elsewhere.
So this seems like an opportunity to see if I am also tilting at windmills. What should the criteria be and how do I go about meeting them?
The fundamental flaw for me in IPv10 was that I never understood the problem it was supposed to solve let alone the reason it was important to solve it.
The Mesh is considerably more extensive than IPv10 but I do know the problems I am trying to solve and I can (and do) explain why those problems are important in the very short times I get to speak in the decision making venues. Venues where almost none of the participants are technical and I am usually the only person from the network standards community.
The third issue of course is establishing a community of interest to work on the proposal. Which is of course difficult until you have a working prototype to demonstrate. But this is a double edged sword as once you have such a prototype and people start to use it, most of your design is locked in and you are going to be able to change rather little.
Finally, there is the question of deployment and the question of whether the proposal has the support of a sufficient number of essential stakeholders to succeed. This is where the IETF has had a schizophrenic approach allowing dominant market players a veto in certain areas (e.g. Web browsers) and insisting on ignoring them in others (the IESG/IAB decision to prevent deployment of DNSSEC in 2001).
The particular problem I am trying to address is protecting the confidentiality of Data At Rest. This is an issue that has recently resulted in a nation state actor destroying the marriage of the CEO/founder of the dominant supplier of cloud services. So there is at least one party that cares. And Data at Rest breaches continue to be the largest source of serious security breaches (with ransomware rapidly catching up). But my deployment strategy is bottom up, not top down. I do not depend on any other organization as an essential participant.
So here is my checklist of criteria:
1) What problem are you trying to solve?
2) Why is this problem important?
3) Is there a community of interest to develop it?
4) Who are the essential participants (gatekeepers) and will they participate?
Notice that what the checklist does not include is does the proposal work. My assumption is that it probably won't but this probably doesn't matter as most things are fixable. Failing the four tests above is fatal unless the proposal can be modified so that they can be passed.
Next step for the Mesh will be the release of the new document set establishing the principles of Threshold Key Infrastructure and the realization of those principles in the Mesh. Hopefully, that will be followed shortly after by the release of the line mode tool.
