Subject: Re: deprecating Postel's principle - considered harmful

From: Keith Moore <[email-masked]>
Date: Thu, 9 May 2019 21:59:38 -0400

I'm another person who really doesn't want to see an RFC of the form 
"Jon Postel was wrong".   Part of the problem is that he was right in so 
many ways, that to single out in a particular way that he was "wrong" 
[*], conveys entirely the wrong impression.   Even if he was "wrong" [*] 
about the sentence most often attributed to him today.

[*] or lacking perfect foresight, or is being misunderstood, or taken 
out of context, or ...

Depending on where you mark the start of the Internet, it and the first 
protocols have existed for around forty years.   It's been around for so 
long, longer than most of its users have been alive, that it's easy to 
take for granted the accumulated wisdom that went into producing it - 
both Jon's contributions and others'. That's not to say that they got 
everything right, and today we're painfully aware of some of the 
shortcomings.    But that they got it working well enough to endure for 
40 years and counting, and to be able to evolve (to some extent) to 
continue to serve the whole world today, was a tremendous 
accomplishment.   Of course, different bits of wisdom become more (or 
less) applicable (or need to be interpreted in different contexts) at 
different points of evolution and scale.

I seriously doubt that Jon would have wanted us to be stuck in the past 
and stop learning.   But neither should we discard hard-won lessons of 
the past.

A lot of additional hard-won wisdom has been cited in this thread, and I 
think it could do a service to try to capture it and place it in the 
context of the earlier accumulated wisdom.

Keith

p.s.  I've often said that "the web" was optimized for deployability.   
Lots of "the web" was poorly designed, IMO, but enough of it was 
designed just well enough to make it attractive to users, and that very 
attractiveness is what has fueled the effort required to improve it.   A 
similar statement could be made of the Internet itself.  As an engineer, 
this bugs me a bit, but I think it's reality.   It's often said that the 
perfect is the enemy of the good, but maybe sometimes, the good is the 
enemy of the deployable.   Being liberal in what you accept is similar, 
in a sense, to optimizing for deployability.

---

From: Doug Royer <[email-masked]>
Date: Thu, 9 May 2019 22:16:33 -0600

He was not wrong. When Jon sent that email, the topic was mildly 
conflicting email systems. And it was referring to accepting something 
you know to be good, or not up to the latest spec. In fact that spec 
(maybe it was a draft) had 'accept' and 'generate' sections. It 
specified what was acceptable to 'accept'. You accepted option A or 
option B, but when sending out email, generate option B only.

I remember his comments to mean plan the migration and specify it in 
writing.

Sometimes I find mild bugs in the other endpoints implementation. So I 
tweak my code to accept their bug when I recognize their implementation. 
Networking code is full of 'bug compatibility switches'. Hopefully fewer 
over time.

As to draft-iab-protocol-maintenance-03:

I understand the robustness principle to mean, plan ahead and plan a 
migration from an old protocol to a newer one. The draft seem to be 
implying it means be able to read garbage when it arrives and not crash.
Which is a good programming goal, and a lousy protocol plan.

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2019 06:05:08 -0700

> Networking code is full of 'bug compatibility switches'. Hopefully fewer

I think this graf does a good job of bringing out the key point which I
take Martin to be pushing on. As you say, it would be nice to have fewer
bug "bug compatibility switches".

One way to achieve that is for the initial implementations to be very
strict about rejecting violations of the specification.Then, when new
implementations are introduced into the ecosystem, if they do not conform
to those aspects of the specification and are forced to implement the
protocol correctly. By contrast, if the early implementations are very
loose in their enforcement of protocol violations, then it is likely that
some set of implementations will also violate the specification in the data
they transmit, with the result that future implementations will have to
implement "bug compatibility switches" in order to be able to function
correctly.

These issues seem particularly relevant in the case of new protocol
migration. As you say, we often design our protocols with a specific plan
for migration but that plan depends on specific behavior by the
implementations of the older/current version, and if those implementations
are nonconformant, then it may be the case that our migration plans do not
work (as was the case with the TLS 1.3 migration). Here, too, then, having
implementations strictly enforce that their counterparties are implementing
the specification directly -- even up to testing it directly by mechanisms
such as "greasing", can smooth the path towards a future migration.

-Ekr

---

From: Doug Royer <[email-masked]>
Date: Fri, 10 May 2019 11:52:53 -0600

On 5/10/19 7:05 AM, Eric Rescorla wrote:
> 
> On Thu, May 9, 2019 at 9:17 PM Doug Royer <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> implementations are introduced into the ecosystem, if they do not 
> conform to those aspects of the specification and are forced to 
> implement the protocol correctly. .....

Great idea, until the other end is the most prolific implementation and 
their bug fix cycle is maybe a year away. So, sometimes you have to 
accept some noise to get to play.

And who's interpretation of 'strict'? That is where bugs show up. They 
worked very hard to write those specs, and others worked very hard to 
understand them and implement them. Then oops a misunderstanding.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 May 2019 13:58:48 -0400

On May 10, 2019, at 1:52 PM, Doug Royer <[email-masked]> wrote:
> their bug fix cycle is maybe a year away

This is perfectly fine.   If they aren’t maintaining their code, it’s better for it not to work.   Year-long bug fix cycles are a security vulnerability: the more pain that they cause before something gets hacked into, the better.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 May 2019 20:12:35 +0200

> On 10 May 2019, at 19:58, Ted Lemon <[email-masked]> wrote:
> 
> On May 10, 2019, at 1:52 PM, Doug Royer <[email-masked] <mailto:[email-masked]>> wrote:

This is a matter of market power and who really sets the standard.  If the choice is between not accepting a buggy implementation and selling product, guess which wins.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 May 2019 14:32:38 -0400

> This is a matter of market power and who really sets the standard.  If the choice is between not accepting a buggy implementation and selling product, guess which wins.

*cough* produce liability *cough*

Honestly, I get that this is how people think, but it’s extremely short-sighted.

---

From: Doug Royer <[email-masked]>
Date: Fri, 10 May 2019 12:56:09 -0600

On 5/10/19 12:32 PM, Ted Lemon wrote:
> On May 10, 2019, at 2:12 PM, Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> This is a matter of market power and who really sets the standard.  If 
>> the choice is between not accepting a buggy implementation and selling 
>> product, guess which wins.
> 

So the answer should be strict-only code, but reality.

I wish there was a way to publish bugs/issues with implementations 
(without publicly naming the company) , not as a criticism, but as a way 
to help the next guy implement. And to help with the next revision of 
the spec.

With iCalendar for example, there is more than one way to represent the 
same event. It is ambiguous and you have to examine other 
implementations objects to see how they do things. Then add code to also 
accept their way. Every time I try to point it out, it quickly escalates 
into a 'which way is better / you don't understand'. Which is 
implementer shorthand for "you change your code, I will not".

A recent Alexa tool sends out appointments with the entire 
VCALENDAR:DESCRIPTION in the SUMMARY line. Valid, but it really screws 
up UI's. Technically correct, but time for a new implementation specific 
switch in the UI code.

And many confuse user experience with data model. Sometimes members 
attempt to make the protocol represent the methods they need, like an 
extended API when in some cases the data should be expressed and 
specified separately.

I think SMTP needs a major overhaul. I am afraid of the noise generated 
from such a draft.

--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2019 12:50:18 -0700

> accept some noise to get to play.

Yes, I made precisely this point in my next sentence.

"By contrast, if the early implementations are very loose in their
enforcement of protocol violations, then it is likely that some set of
implementations will also violate the specification in the data they
transmit, with the result that future implementations will have to
implement "bug compatibility switches" in order to be able to function
correctly."

There seem to be two main equilibria:

1. There's a critical mass of very strict implementations; in this case
it's very hard for a non-conformant implementation to enter the ecosystem.
2. There's a critical mass of non-conformant implementations; in this case
it's very hard for a strict implementation to enter the ecosystem.

Once you're in one equilibrium or the other, it's very hard to get out.

> understand them and implement them. Then oops a misunderstanding.

You're certainly right that spec contain ambiguities (and as MT suggests,
having the thing everybody refers to be something that can't be updated to
remove those ambiguities doesn't help). However, my experience with the TLS
1.3 process is that most of the nonconformance we had wasn't actually
ambiguities but just implementation defects where the protocol
specification was pretty clear.  Also, at least in QUIC/TLS, etc. the early
adopters coordinate pretty well, so they mostly agree on how to interpret
the protocol.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 May 2019 13:32:04 -0700

> Once you're in one equilibrium or the other, it's very hard to get out.
And from the perspective of the IETF as a standards body, an additional
question may be whether an equilibrium has yet been reached.   If it has
not, and the implementing groups are actively participating in the
standards effort, then I believe Martin's analysis suggests Postel's
principle is still correct, though incomplete.  Be conservative in what you
send; be liberal in what you accept; be communicative about what went
wrong.

The advantage of that during the development process is that it allows you
to test past the error to see if other parts of the implementation are
correct and behaving as you expect.  Hard fails very early turn the testing
process into a fully serial process, which may be too slow.  But this
approach also comes with a very obvious cost, in that it forces
implementing groups to participate in the process at least enough to know
how to reach out to those whose implementations they are testing.  That
tends to favor the well-funded and the well-connected over others, and it
may mean that those who cannot participate will also find an equilibrium
already set before they get to play.

Lowering that cost is important, as is being honest about whether an effort
is currently in an exploratory phase or documenting an as-built system.
Having chaired working groups which moved between those two without an
intervening RFC publication, this is not as easy as looks, though I believe
we are working on some better signposts.

regards,

Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 May 2019 16:47:34 -0400

> in a sense, to optimizing for deployability.

Damn right it was. Deployability was the primary consideration. We did not
use SGML because any of us liked it or considered it to be a solid
technical specification. We hated it and we though it was crap. The reason
we went there was that we needed buy-in from the publishing world.

But equally importantly, we broke a lot of what people thought were the
rules. I knew that there wasn't a Content-Length header in MIME when I
added it to the HTTP spec and so did Tim. But we pretended it did because
we needed to make the POST method work and we were not going to introduce
mandatory content body framing or SMTP type escaping.

A lot of the reason that the Web is the way it was is that the exponent
kicked in the growth curve while we were still trying to work out the
architecture. And the Web grew much much faster than the bandwidth needed
to serve it. Back in 1994, caching proxy servers were essential
infrastructure needed to make the Web work. That isn't the case now. In
fact TLS-everywhere is rapidly making them obsolete.

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 May 2019 16:44:18 -0500

On Fri, May 10, 2019 at 04:47:34PM -0400, Phillip Hallam-Baker wrote:
> > [...]

Thankfully you did add chunked transfer-encoding.

> fact TLS-everywhere is rapidly making them obsolete.

Is that so?  Caching proxies merely need to become MITM proxies.  Those
exist, and in many corporate environments that require web access and
data loss protection (DLP), they must exist.  I know because I use one,
and also I maintain one (though the one I maintain is not a caching
proxy).  Middleboxen will be with us forever.

Now, an MITM proxy that exists to enforce policy and implement DLP
needn't be a _caching_ proxy, so perhaps your statement is correct after
all!   :^)

But seriously, I don't expect proxies to go away.  I expect them to be
MITM proxies.

I'd rather that, instead of MITM proxies, clients used HTTPS to speak to
the proxy and did not use CONNECT for HTTPS resources, but that's not
likely to happen (and even so, if the user-agent must use client
certificates, it will have to use CONNECT), so MITM proxies they shall
have to be.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 May 2019 18:20:45 -0400

> Thankfully you did add chunked transfer-encoding.

Chunked came after keep alive which I proposed at the first Web Conference
together with a different chunking and was told it wasn't needed. Then
people started going heavy on images and TCP teardowns started to be the
limiting issue.

> proxy).  Middleboxen will be with us forever.

Of course. The part that is going away though is the part we were focused
on in 1994-1996 because the Internet was melting under the load.

MITM proxies introduce their own horrors and they are an example of the
cost of trying to remain principled in an unprincipled world. We could do
MITM in a much better way than we have ended up with. But we can't come to
consensus on a protocol of that sort.

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 May 2019 17:47:47 -0500

> on in 1994-1996 because the Internet was melting under the load.

Ah yes, that's done, thankfully.  Indeed, the network is now faster than
the servers, so we scale out horizontally as much as possible.

> consensus on a protocol of that sort.

Consensus isn't the problem.  The problem is that HTTP/1.x was so
trivial to implement (bash + printf + nc can do it) that there are too
many "stacks" in which to implement something new, so it can't be done.

This is also why 3xx redirect-based authentication methods are winning
over as-originally-intended 401 / WWW-Authenticate / Authorization
methods.  It's easier to implement redirect chasing than to implement a
pluggable authentication method framework.  (Also, it's easier on server
devs to use redirects.)  I just wish 3xx and 401 weren't mutually
exclusive.  I posted to [email-masked] a few weeks ago about that got no
replies, sadly.

There's just no way to do better when we'd have to fix a few thousand
clients and a dozen or so proxies.  ETOOHARD is an understatement.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 May 2019 18:51:44 -0400

On 5/10/19 2:56 PM, Doug Royer wrote:

> With iCalendar for example, there is more than one way to represent 
> the same event. It is ambiguous and you have to examine other 
> implementations objects to see how they do things. Then add code to 
> also accept their way. Every time I try to point it out, it quickly 
> escalates into a 'which way is better / you don't understand'. Which 
> is implementer shorthand for "you change your code, I will not".

iCalendar may have been doomed from the start because every calendar app 
vendor had its own dysfunctional way of representing events before 
iCalendar existed, and few (if any) were willing to change.

Also, it's been hard to escape the impression that some of those 
glitches were deliberate by at least one vendor, that wanted to be able 
to claim standards compatibility without actually being effectively 
interoperable.

> I think SMTP needs a major overhaul. I am afraid of the noise 
> generated from such a draft.

Now there's a scary thought.

Keith

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 10 May 2019 18:57:12 -0400

> iCalendar existed, and few (if any) were willing to change.

Speaking of which, JSCalendar (a replacement format for iCalendar which removes many of the ambiguities) has just (re-)entered working group last call:

https://mailarchive.ietf.org/arch/msg/calsify/f0C_BRlpq-M5mQeXRLpPjPKjz7M

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 May 2019 19:14:52 -0400

> many "stacks" in which to implement something new, so it can't be done.

Number of implementations (which can be related to ease of 
implementations) is something that I suspect affects which of EKR's 
equilibrium points the situation ends up in.   A protocol that's easy to 
implement should be considered a success, IMO, but it does make it 
harder to evolve the protocol.

(These days there's a bit of religious dogma floating around the idea 
that everyone should keep all of their protocol stacks current.   While 
I understand the sentiment, and often agree in specific cases, I'm not 
sure it scales well especially into the IoT world.   There's something 
to be said for a protocol that's so well-designed and stable that it 
doesn't need to be upgraded, and stable enough that it's worth spending 
the time to get the implementation right the first time.  I'm sure some 
people regard that as heresy, but there are lots of negative 
consequences associated with constantly having to have upgrades, 
including increased development/maintenance cost, increased 
interoperability failures, and increased vendor lockin.)

> exclusive.  I posted to [email-masked] a few weeks ago about that got no

It has long seemed to me that the early available 401-based methods (by 
which I mean the ones available in browsers from mid to late 1990s) 
failed largely because of their inflexibility and relatively poor user 
experience provided by the browsers, and especially because avoiding 401 
altogether and using redirects and cookies instead allowed each site to 
customize the login user experience.   Then the latter became widely 
held mindshare that redirects and cookies are how you do 
authentication.   Which is very unfortunate, because cookies are an 
absolute disaster and it's very hard to see how to get rid of them.  
(Even though at least some of their problems were obvious from the 
start, and IETF tried to fix them multiple times.)

Keith

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 May 2019 18:34:24 -0500

On Fri, May 10, 2019 at 07:14:52PM -0400, Keith Moore wrote:
> which I mean the ones available in browsers from mid to late 1990s) failed
> largely because of their inflexibility and relatively poor user experience
> provided by the browsers, and especially because avoiding 401 altogether and
> using redirects and cookies instead allowed each site to customize the login
> user experience.   Then the latter became widely held mindshare that
> redirects and cookies are how you do authentication.   [...]

There are lots of problems with HTTP authentication driving the move to
3xx redirects, no doubt.

The problem I have is that a server that can do both, 3xx- and 401-based
authentication has to pick one without knowing which (if any) the
user-agent can also do.

"Only do 3xx" is not a good answer: it has driven "API keys" into
existence because non-browser, non-interactive apps can't do what
browsers with a human user in front of them can, and API keys are not a
step up, especially not if you have a Kerberos infrastructure that works
like a well-oiled machine.  Kerberos has a lot of problems, and is not
an Internet-scale protocol, but as it happens GSS-API w/ Kerberos is
quite well supported outside HTTP apps (and even there), so 3xx ends up
driving a step-down into API keys, and in some cases too a need to have
multiple names for the same service.

I do not object to 3xx-based authentication.  I just want a better way
to support everything that works.

Nico
--

---

From: [email-masked]
Date: Sat, 11 May 2019 09:34:19 -0700 (PDT)

> This is perfectly fine.   If they aren’t maintaining their code, it’s
> better for it not to work.   Year-long bug fix cycles are a security
> vulnerability: the more pain that they cause before something gets hacked into,
> the better.

It's even better to continue to have customers and stay in business.

Like it or not, sometimes that's the tradeoff.

				Ned

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 May 2019 12:48:09 -0400

Sent from my iPhone
> On May 11, 2019, at 12:34 PM, Ned Freed <[email-masked]> wrote:
> 

Why would you say this?  Of course we all understand that there will be pressure to do less work, and consequently produce less secure implementations. The question is, should the IETF assist or hinder this practice?

Should we normalize it or, not to put too fine a point on it, write our specs in such a way that when you do this it’s easy to demonstrate misfeasance when you are taken to court?

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 May 2019 18:59:00 -0400

Eric Rescorla <[email-masked]> wrote:
    > I think this graf does a good job of bringing out the key point which I take
    > Martin to be pushing on. As you say, it would be nice to have fewer bug "bug
    > compatibility switches".

I really like how you wrote this.
The worse case is where one vendor plows ahead (or has some legacy system),
and then everyone else has to adjust to their bugs, and that never goes away.

    > One way to achieve that is for the initial implementations to be very strict
    > about rejecting violations of the specification. Then, when new
    > implementations are introduced into the ecosystem, if they do not conform to
    > those aspects of the specification and are forced to implement the protocol
    > correctly. By contrast, if the early implementations are very loose in their
    > transmit, with the result that future implementations will have to implement
    > "bug compatibility switches" in order to be able to function correctly.

I wonder how we could, without really giving up the Postel principle, capture
this sense into our Internet Standard step.

    > 1. There's a critical mass of very strict implementations; in this case it's
    > very hard for a non-conformant implementation to enter the ecosystem.

    > Once you're in one equilibrium or the other, it's very hard to get out.

I am repeating what you said here, because I like the analysis of equilibria,
and maybe this is the clue to answering my question above.

    > was pretty clear. Also, at least in QUIC/TLS, etc. the early adopters
    > coordinate pretty well, so they mostly agree on how to interpret the
    > protocol.

And, if the running code is done early enough, then the rough consensus in
the document will reflect that majority view, and there won't be
compatibility bugs.  But, that requires multiple implementations, and it
requires implementing before RFC, and many vendors won't do that.

(ps: EKR great write-up/blog about the firefox add-on fix last weekend. Sorry
that everyone lost their weekend to that...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 May 2019 19:03:17 -0400

Ted Hardie <[email-masked]> wrote:
    > question may be whether an equilibrium has yet been reached. If it has not,
    > and the implementing groups are actively participating in the standards
    > effort, then I believe Martin's analysis suggests Postel's principle is still
    > correct, though incomplete. Be conservative in what you send; be liberal in
    > what you accept; be communicative about what went wrong.

While I think you mean to communicate to the WG/IETF about what went wrong,
there is also significant gaps in communicating to the operator, to the
remote end, etc. about why a given implementation didn't like that input.

We often cite security as a reason to just say "failed" on the wire, and
sometimes it is reasonable to do that, but I'd like our protocols to try to
say more about how to log things that were accepted (or rejected) as a result
of being liberal.  Of course, spamming the logs is bad, but the goal here is
to be able to match a (the optional) log entry to something the protocol
specifies so that new implementations can actually figure out where they had
trouble.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 May 2019 21:52:19 -0400

Several folks have mentioned early implementations.  In general, they 
are a great thing that gives us lots of feedback.

Having said that, I will note that if a major vendor invests too much in 
that early implementation, they get rather wedded to the version of the 
spec they implemented.  Which can create problems for the working group 
when it discovers that changes are needed.

In particular, if that early implementation is very strict, it is harder 
for it to work with something different that the IETF determines is needed.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 May 2019 20:22:35 -0700

> for it to work with something different that the IETF determines is needed.

Certainly this is a risk, but my experience with both TLS and QUIC has been
that this
has not really been the case, for two reasons:

1. The vast majority of the implementors in both cases have been very good
about
changing their implementations.

2. Because we are indicating separate version numbers for each draft
version,
there is an opportunity to debug interop issues at the time you rev your
version.

Of course, this may be a set of conditions which mostly apply to protocols
like
those on the Web where many of the vendors are able to quickly roll out each
new version. YMMV.

-Ekr

> conform to

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 May 2019 23:27:58 -0400

The particular examples I am most familiar with were cases where the 
vendor had implemented silicon to handle the protocol.  This is one of 
the differences between behaviors higher in the stack and some of the 
behaviors lower in the stack.
Yours,
Joel

On 5/11/19 11:22 PM, Eric Rescorla wrote:
> 
> 
> On Sat, May 11, 2019 at 6:53 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Certainly this is a risk, but my experience with both TLS and QUIC has 
> been that this
> 1. The vast majority of the implementors in both cases have been very 
> good about
> Of course, this may be a set of conditions which mostly apply to 
> protocols like
>      > Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>      >      > I think this graf does a good job of bringing out the key
>     point which I take
>      >      > Martin to be pushing on. As you say, it would be nice to
>     have fewer bug "bug
>      >      > compatibility switches".
>      >
>      >      > One way to achieve that is for the initial implementations
>     to be very strict
>      >      > about rejecting violations of the specification. Then,
>     when new
>      >      > implementations are introduced into the ecosystem, if they
>     do not conform to
>      >      > those aspects of the specification and are forced to
>     implement the protocol
>      >      > correctly. By contrast, if the early implementations are
>     very loose in their
>      >      > enforcement of protocol violations, then it is likely that
>     some set of
>      >      > implementations will also violate the specification in the
>     data they
>      >      > transmit, with the result that future implementations will
>     have to implement
>      >      > "bug compatibility switches" in order to be able to
>     function correctly.
>      >
>      > Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>      >      > There seem to be two main equilibria:
>      >
>      >      > 1. There's a critical mass of very strict implementations;
>     in this case it's
>      >      > very hard for a non-conformant implementation to enter the
>     ecosystem.
>      >      > 2. There's a critical mass of non-conformant
>     implementations; in this case
>      >      > it's very hard for a strict implementation to enter the
>     ecosystem.
>      >
>      >      > Once you're in one equilibrium or the other, it's very
>     hard to get out.
>      >
>      >      > was pretty clear. Also, at least in QUIC/TLS, etc. the
>     early adopters
>      >      > coordinate pretty well, so they mostly agree on how to
>     interpret the
>      >      > protocol.
>      >
>      > Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works

---

From: Keith Moore <[email-masked]>
Date: Sat, 11 May 2019 23:55:48 -0400

[discussion about implementations of TLS and QUIC]

> those on the Web where many of the vendors are able to quickly roll 

Yes,  I would expect the implementors' motivations to track changes 
during protocol development to vary considerably from one protocol to 
another.    I would also expect that implementors' motivations to track 
such changes during initial protocol development, to be different than 
their motivations to track changes after initial deployment.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 May 2019 11:56:37 +0200

Hi Ted,

First, I think Eric’s point about the two main equilibria is a good one.  Please see below.

> On 10 May 2019, at 22:32, Ted Hardie <[email-masked]> wrote:
> 
> 
> On Fri, May 10, 2019 at 12:51 PM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 1. There's a critical mass of very strict implementations; in this case it's very hard for a non-conformant implementation to enter the ecosystem.
> 2. There's a critical mass of non-conformant implementations; in this case it's very hard for a strict implementation to enter the ecosystem.
> 
> And from the perspective of the IETF as a standards body, an additional question may be whether an equilibrium has yet been reached.   If it has not, and the implementing groups are actively participating in the standards effort, then I believe Martin's analysis suggests Postel's principle is still correct, though incomplete.  Be conservative in what you send; be liberal in what you accept; be communicative about what went wrong.

Yes.  That allows people to learn.  This thread has already noted that the problem may lie with an implementation or the standard itself.  Again, the latter is considerably more likely with immature standards than with mature ones, for the simple reason that we know what we are doing with the stuff that has been around a while.  We learned how to properly do TCP congestion management well after the TCP standard was written, and we learned how best to handle different forms of Email well after RFC 822 came out.  There was a lot of slack in these standards at the beginning.  Things began to tighten up with the publication of RFCs 1122  and 1123, and they continued with successive revisions of 822.  Pete and friends even found a way to get 8 bits into a 7 bit protocol.  Beat that with a stick.  And you were there, as I recall.

> 
> The advantage of that during the development process is that it allows you to test past the error to see if other parts of the implementation are correct and behaving as you expect.  Hard fails very early turn the testing process into a fully serial process, which may be too slow.  But this approach also comes with a very obvious cost, in that it forces implementing groups to participate in the process at least enough to know how to reach out to those whose implementations they are testing.  That tends to favor the well-funded and the well-connected over others, and it may mean that those who cannot participate will also find an equilibrium already set before they get to play.

Indeed.  Those engaging in new technology areas need Postel’s Law in order to prove the concept.  The trick is catching the shift from PoC to real stuff such that you don’t end up in the wrong equilibrium, and there are two: stuck with poorly behaving implementations and underployed due to too much friction.

> 
> Lowering that cost is important, as is being honest about whether an effort is currently in an exploratory phase or documenting an as-built system. Having chaired working groups which moved between those two without an intervening RFC publication, this is not as easy as looks, though I believe we are working on some better signposts.

And that’s a good thing.  This thread points out again and again that Postel’s Law was not intended to be the last say on any of this.  It was written in several different contexts, but with an eye toward a particular goal at a particular point in time.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 13 May 2019 20:29:45 +1000

On Mon, May 13, 2019, at 19:57, Eliot Lear wrote:
> Indeed. Those engaging in new technology areas need Postel’s Law in 
> order to prove the concept. The trick is catching the shift from PoC to 
> real stuff such that you don’t end up in the wrong equilibrium, and 
> there are two: stuck with poorly behaving implementations and 
> underployed due to too much friction.

This might have been a fair analysis in the 80s or 90s, but I suspect that there has been a gradual shift away from deployment of less mature protocols.  Today, I'd say that it is more often the case that standardization is occurring closer to the "mature" end of things.  This is partly because activation energy for new stuff is fairly high, and so high-friction standardization isn't that much of a delta.

If nothing else, the security requirements the network imposes on new protocols is enough to make careful standardization look relatively cheap.

So I'd caution against following this line of reasoning too far.  Lessons of the distant past might not apply, even for those breaking (relatively) new ground.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 May 2019 13:49:16 +0200

Martin:

> On 13 May 2019, at 12:29, Martin Thomson <[email-masked]> wrote:
> 
> This might have been a fair analysis in the 80s or 90s, but I suspect that there has been a gradual shift away from deployment of less mature protocols.

It’s a fair analysis today.  We can and should encourage people to use mature protocols, where possible.  And let’s face it: HTTP+REST+JSON+TLS makes for a nice general model.  As a TCP/UDP port reviewer, I can tell you that my phone isn’t exactly ringing off the hook.  But even new uses of those technologies can have new implications that require tinkering.  I say this as someone tinkering with new stuff today.

> Today, I'd say that it is more often the case that standardization is occurring closer to the "mature" end of things.

I’m not talking about a new bell or whistle to an existing protocol.  I’m talking about new concepts.  They don’t come around too often, but they do come around.  This is happening today throughout the IoT space, in many dimensions.  Worse- IoT manufacturers will rarely implement without a standard, simply due to real estate constraints (mem, nvram, cpu).  But that doesn’t mean that the standard is all THAT mature.  Remember: HTTP got redone after 25 years of experience on non-constrained devices.  Think we’re going to get it all right on constrained devices in much less time?

> This is partly because activation energy for new stuff is fairly high, and so high-friction standardization isn't that much of a delta.
> 

Your opinion.  One of the biggest problems in the vertical I’m in is that of competing standards that drive up costs.

> If nothing else, the security requirements the network imposes on new protocols is enough to make careful standardization look relatively cheap.

With new concepts, and even new or aggregated uses of old concepts, security remains often the last concern.  The first concern is, “can we make the function work at all?”  The second concern is, “Can we make it scale?”  Security chimes in some time way after that.  That is reality.  You may not like it, but the newspapers are littered with this fact.  Don’t believe me?  Open today’s Wall Street Journal and read about the state of healthcare technology.

And so what are you writing this for?  A new knob or feature or for new concepts?  Maybe you’re writing it for both.  That’s okay, but be clear.

Eliot

---

From: [email-masked]
Date: Tue, 14 May 2019 10:34:13 -0700 (PDT)

> > It's even better to continue to have customers and stay in business.

First of all, this comment, as well as the comment from Doug you were
responding to, is in the context of whether or not to code around bugs in other
implementations, not failing to correct bugs in your own implementation.

Second, not everything is security related, and even things that are security
related aren't necessarily about weakening or strengthening security.

> Why would you say this?

I said it because I've been able to keep customers by adding workarounds and
lost customers by not doing so.

> Of course we all understand that there will be pressure to do less work, and
> consequently produce less secure implementations. The question is, should the
> IETF assist or hinder this practice?

Huh? I have no idea what this is supposed to mean. We're talking about  whether
or not to do *additional* work, and the pressure is usually to "make things
work, never mind how".

> Should we normalize it or, not to put too fine a point on it, write our specs
> in such a way that when you do this it’s easy to demonstrate misfeasance when
> you are taken to court?

The odds of this sort of thing landing any of the participants in court,
regardless of what they do or don't do, are quite small. (And when it does
happen, well, let's just say that technical merit doesn't count for as much as
it should.) But the almost certain lack of legal consequences doesn't mean
there aren't risks to consider.

Here's a (suitably anonymized) real world example. Some time back one of our
customers, after several weeks of extensive testing, decided to upgrade our
software across their deployment. Unfortunately, the testing managed to miss a
particular interaction with another vendor's software, with seriously bad
results.

I soon managed to figure out what was happening: We had added an optimization
to our code that made use of a particular protocol feature we hadn't used
before. Despite being a mandatory part of the protocol specification, the other
vendor's product did not implement the feature we now depended on.

The other vendor immediately acknowledged that this was their bug, so
finger-pointing was not an issue.

At this point we had three choices:

(1) Do nothing - it's the other vendor's problem so it's up to them to fix it.

(2) Remove the optimization entirely.

(3) Add a configuration switch to disable use of the option.

Now, by your logic the correct choice is (1). But here's the thing:
Implementing a missing feature is a lot harder than disabling a recently added
optimization. So much so that the customer would have had to back out the
upgrade, downgrade upgraded databases, etc. etc., wait for the new version of
the other vendor's software to come out, test that, upgrade that, and then
restart the original upgrade process.

In constrast, we could - and did - issue a patch to disable our use of the
feature in a matter of hours, salvaging the upgrade.

Of course there was risk in doing this: We could have introduced additional,
possibly worse, problems, problems which in our haste to deploy a fix might not
have been found until much later. And such a problem would have been entirely
our fault.

And maybe that risk are suffcient for you to still believe (1) was the correct
choice. But think for a moment about perception. Upper management types don't
care about specifications, who follows them, and who doesn't. All they are
going to hear is that a major upgrade of our software turned into a
catastrophe, costing lots of time while waiting for another vendor to step in
and solve the issue while we did nothing. Not exactly the record we want when
the time comes to renew our support contract.

By fixing the problem ourselves we managed to both minimize the consequences
and come across as the good guys.

Now, this is just an anecdote, and the plural of anecdote is not data. But I
could just as easily have described a dozen other similar cases, including a
couple where we got on our high horse and promptly crashed it into a wall.

				Ned