Re: [arch-d] deprecating Postel's principle- considered harmful

[Eliot Lear <[e-mail]>]

> On 9 May 2019, at 13:02, Carsten Bormann <[e-mail]> wrote:
> 
> On May 9, 2019, at 11:34, Eliot Lear <[e-mail]> wrote:
>> 
>> technical deficit
> 
> I think we were discussing Technical Debt.
> 
> https://en.wikipedia.org/wiki/Technical_debt <https://en.wikipedia.org/wiki/Technical_debt>

Yes.  I understood.

> 
> The term is widely used to describe code bases in software development that, through lack of oversight, have acquired properties that make them hard to move forward (or even fix).
> It doesn’t quite transfer to protocols, because here it is often different parties that incur the debt and that ultimately have to pay it up.


As you point out it is those who use the protocols who really incur the debt.  Anyone can have a bad – or immature – idea.  HTTP was loaded with them, and my point is that it is at least in part because we were learning. and let’s recall that HTTP and HTML were really evolutions on existing work, themselves.  RFC 5218 points out that this was wild success.  We saw more than our fair share of adoption failures because people took the other road that John Klensin described.  A great many times (our RFC directory is littered with all sorts of attempts).  Again, I find the term emotional.

On the other hand, if we are going to think in accounting terms, I would argue that from an economics standpoint, there its a credit associated with rapid development that we have accrued, and that we must continue to accrue under the assumptions we operate today, which is that of economic productivity associated with technology advances.  No matter how you evaluate cybersecurity losses, they come nowhere near the productivity gains that we account for as part of GDP in advanced economies.  Sooooo….  Technical debt can be economically good!


> A protocol that has turned into soup has acquired technical debt.
> It is very hard to pay back that debt: that requires coordinated effort throughout the ecosystem.  It occasionally can be done, but these are the hero stories of our time.

The worst case I know of is SMTP, and the reason it is the worst case is that its purpose is to enable non-prearranged communications, which lends themselves to any kook with associated malware getting into your mailbox.  So long as that requirement holds, we cannot entirely supplant that protocol, although casual communications have gradually moved elsewhere.  This, despite what I would consider very strong coordination within the ecosystem.  Is there a measurable debt?  Sure.  Let’s call it harm caused by spam and phishing, but that is based not on sloppy or lazy design or even on maturity (thus far), but rather on market desire.

Eliot