What problem is solved and why do we need to solve it? Re: Enough is Enough.

[Phillip Hallam-Baker <[e-mail]>]

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.