Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-00.txt

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Jun 2018 20:35:25 +1000

Up-leveling a little using Brian's email as a stepping point as good
as any other, because be makes a nice point here:

On Tue, May 29, 2018 at 9:15 AM Brian E Carpenter
<[email-masked]> wrote:
> My argument is really that designers need to bear in mind that if they
> leave loose ends of any kind, it is very probable that implementers
> *will* deal with those loose ends via the robustness principle, for reasons
> that Tony Li stated. If you argue that this is a bad thing, I won't disagree,
> but my conclusion is not that the robustness principle is a mistake - it's
> that specs should not leave loose ends.

I thoroughly agree with this, but I'm afraid that I've not
communicated my point, and I apologize for this.

The fundamental problem is not with the observation of the necessity
of this sort of compromise.  It's an ugly truth that you sometimes
have to do that (the draft says that).  For instance, this week we're
considering loosening our name validation to permit names that are
clearly invalid according to numerous RFCs [1].

That was never the point of the document, but I see now that I wasn't
successful in making the point sharp enough, because that message was
mostly lost in the defense of the principle (though that was a very
useful discussion for me, so thanks all).

Let me try different approach in the hopes that this illustrates my
point better:

Postel's Maxim as the Laws of Thermodynamics:

First: You can't win.

An implementation that seeks interoperability will encounter a
situation where they need to implement measures that follow Postel's
Maxim (and either be more conservative in sending, or more liberal in
receiving).

Second: You can't break even.

An implementation that seeks interoperability cannot remove any
measures it implements in following Postel's Maxim, at best, it can
only operate without adding new interoperability measures.

Third: You can't quit the game.

An implementation that ceases adding interoperability adaptations will
eventually become non-interoperable.

Like with Maxwell's demon, the fallacy here is hard to see at first.
That fallacy is that the system is closed.  But we don't leave
protocol implementers alone, and to the extent that we're able to
maintain protocols, we are able to inject new energy into the system.

Alone, an implementer of a specification ends up being forced to do
whatever is necessary to interoperate.  When it's interoperate or die,
the choice really isn't one.  So yes, do what you gotta.  And Postel
did a great job of describing exactly what you do in these situations.

But we can't hold that up as a guiding principle.  By saying that this
is a principled action, you ennoble the activity in ways that aren't
deserved; the "Robustness Principle" advocates a purely self-serving
action that only risks harm to the ecosystem as a whole.  And I remain
convinced of that.  This is not a principle that should guide protocol
design, but should be more useful as a caution to protocol designers.
That is, it describes the effect you get when the protocol is hard to
understand, build, and deploy; and that the best and only defense is
continued involvement and adjustment.

In the end, I still think that the best plan is to continue the
emphasis on what protocol and implementations maintainers can do to
work together.

I've been involved in a few projects that have successfully managed to
build and maintain a community [2] and thereby escape the "closed
system" trap on thinking.  The TLS 1.3 process is fresh though, and a
great example.  Sure, we have a new RFC coming that represents a
fairly remarkable achievement, which is terrific.  But a secondary
outcome of that process, which was probably a precondition for
success, was not the spec, but what has happened to the community.  5
years ago, getting TLS 1.2 shipped was really hard - a few people knew
each other but it was all somewhat insular.  A small few of those
managed to bootstrap the process of shipping TLS 1.2, just as work on
1.3 was starting.  But it was a risky proposition then and everyone
had their fingers on the "off" switch as it rolled out.  Now, I can
comfortably say that a very large proportion of the TLS implementer
community is actively participating in the IETF [3].  People know each
other and are now comfortable working together.  Shipping TLS 1.2 was
a simple task made hard, unshipping SSL 3 a year on was a risky task
that was barely successful, and now we're shipping TLS 1.3, which I
can say was a near-impossible task made possible thanks to the healthy
community we now have.

Enough digression though.  Obviously, this means that the draft needs
work.  It's probably going to take a few more rounds to sharpen the
thesis more and get the emphasis right. But now that I can see now
where the concerns are coming from, I think that I have a way forward.

The idea that you might be able to be virtuously intolerant is an idea
that I'd like to explore a little more.  I think that idea has merit,
but it needs more work to get right.  FWIW, I anticipate some
interesting results from the EDNS flag day proposed for next year [4]
and will watch with interest.  Exercising virtuous intolerance is a
risky proposition.

Cheers,
Martin

p.s., I still don't have a good example of ill-conceived
permissiveness that isn't also a spec violation.  But there are enough
now that I'm starting to think that it's worth finding and documenting
a few examples.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1184059
[2] I can personally claim very little of the credit in all cases.
[3] Along with great involvement from academics, whose contribution
was critical, though not particularly relevant to this discussion.
[4] https://dnsflagday.net/ - thanks to Suz for pointing this one out.

---

From: [email-masked] (Henry S. Thompson)
Date: Sat, 02 Jun 2018 15:37:14 +0100

A related point that this conversation reminded me of, which I owe to
Jonathan Rees:

  Underspecification (e.g. vagueness or gaps in a spec) often amount to
  implicit extension points.  People will eventually notice them, and
  take advantage of them for their own purposes, leading to
  interoperability failures if/when extended entities escape into public
  space.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]