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

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 7 May 2019 19:17:58 +0000

Not seeing much discussion on this document on the lists, I put a twist on the title-

I find the document (as currently written) is incorrectly interpreting the robustness principle as saying there is no need for clear rules on protocol evolvability/extensions. For example, section 6, "relying on implementations to consistently apply the robustness principle is not a good strategy for extensibility". In the routing area, we do have rules and we use the principle to ensure interoperability, as we don't have the luxury to do a "forklift". Section 8's "it is not always possible to produce a design that allow all current protocol participants to continue to participate", my question would be "but does it harm the network"?

Actually most of the document confusingly is not contradicting Postel's principle but supporting it (except for the nuances which seem to condone forklifts). It just erroneously blames Postel for sloppy implementations. For the document to summarize saying "the robustness principle can, and should, be avoided" as it is harmful (I think) will be harmful to the Internet.

Hopefully more folks will read it-
(probably discussion is more appropriate on the architecture-discuss list)
Deborah

-----Original Message-----
From: IAB <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, May 06, 2019 10:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: [IAB] I-D Action: draft-iab-protocol-maintenance-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Architecture Board IETF of the IETF.

        Title           : The Harmful Consequences of the Robustness Principle
        Author          : Martin Thomson
	Filename        : draft-iab-protocol-maintenance-03.txt
	Pages           : 11
	Date            : 2019-05-06

Abstract:
   Jon Postel's famous statement of "Be liberal in what you accept, and
   conservative in what you send" is a principle that has long guided
   the design and implementation of Internet protocols.  The posture
   this statement advocates promotes interoperability in the short term,
   but can negatively affect the protocol ecosystem over time.  For a
   protocol that is actively maintained, the robustness principle can,
   and should, be avoided.

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Diab-2Dprotocol-2Dmaintenance_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=Fxp9wRoCVRJ_8BZBzY1MoExjRlVCegLbFtq8txcr6F8&e=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=aCbWfZ2WFHlTnh7WeiI8hJ_N04EoyW90y-Wuml8gLuA&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=lBVwS9yzx9lBmBEMA0cIidmh_hgRqGFclGMt6iNTPfw&e=

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=JdV3Cux54CLr3GLrhc4SapVMu0mBchg-65xKrwqYPCo&e=

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=FA3-28RGBPX6oeQnIR42NBpfekSVh-BU7wyHCkuesdA&e=

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 May 2019 16:29:36 -0400

I think the questions Deborah raises are layer-dependent, and it's
likely that I agree with Martin more than Deborah does exactly because
Martin and I live at the same layers.

> It just erroneously blames Postel for sloppy implementations.

Blaming the principle isn't the same as blaming Postel; the point here
isn't so much that "Postel was wrong" as it is that there are many
consequences of adhering to that principle that Jon didn't anticipate.
The classic cases here are in email and web applications, where what
one might call "loose" use of the protocols has resulted in some real
messes.  Acceptance of badly formed messages has led to widespread
sending of badly formed messages, to the point that it's caused
problems with the integrity of the email system.  In web applications,
poor implementation of things like character set and content type
labelling has resulted in great difficulty in figuring out what
character sets and content types are really meant.

So the general thing is that if we were *not* liberal in what we
accepted, from the start, aberrant implementations would never have
worked in the first place, and would either have been fixed or died on
the vine.  And that would have been far better for the Internet as a
whole than what we have now, at least at the higher stack layers.

My sense is that at the lower stack layers, we're *not* actually very
liberal in what we accept, at least not in general.  Saying, there,
that the principle we're talking about is correct and good for the
Internet is really saying that the principle works only when it's used
sparingly and in targeted ways.

Barry

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 May 2019 21:38:05 +0100

Question for ya on that Barry - do you think that MUA
and mail server implementers would actually bounce
messages as strictly as Martin's document might call
for? I'm not one of those implementers, so I don't know,
but I'd not be surprised to hear that in fact they'd
continue to prioritise mail delivery (for non spam)
over protocol purity.

Cheers,
S.

On 07/05/2019 21:29, Barry Leiba wrote:
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 08:45:35 +1200

Hi Deborah,

On 08-May-19 07:17, BRUNGARD, DEBORAH A wrote:
> I find the document (as currently written) is incorrectly interpreting the robustness principle as saying there is no need for clear rules on protocol evolvability/extensions. For example, section 6, "relying on implementations to consistently apply the robustness principle is not a good strategy for extensibility".

Yes, thank you for saying that, I hadn't seen it so clearly. I do regret that we failed to discuss the robustness principle explicitly in RFC6709. However, it's in the background of https://tools.ietf.org/html/rfc6709#section-4.7 .

> In the routing area, we do have rules and we use the principle to ensure interoperability, as we don't have the luxury to do a "forklift". Section 8's "it is not always possible to produce a design that allow all current protocol participants to continue to participate", my question would be "but does it harm the network"?
> 

I agree. I think that as a warning against blind reliance on the principle, the document is correct and useful. But IMHO that doesn't justify the title, or the recommendation in the Abstract.

To be constructive, I suggest:

Title: The Unintended Consequences of the Robustness Principle

Abstract (last sentence): For a protocol that is actively maintained, the robustness principle can often be avoided.

If there was a Conclusions section, I expect I'd have a suggested change for that too.

> (probably discussion is more appropriate on the architecture-discuss list)

Yes, but that list is generally very quiet, unfortunately.

   Brian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 7 May 2019 16:48:20 -0400

Barry,

Except in the cases that you cite (badly formed messages in email and web
applications), the Postel principle isn't being followed, as the senders
are not being strict in what they send.

The intention, really, was to prevent implementations of a
particular version of a specification that, for example, had a field or bit
that Must Be Zero, from discarding an incoming message just because that
field or bit wasn't actually zero. This allows a protocol to be updated
without requiring a flag day or forklift.

So what you're trying to prevent is poor application programming that
doesn't follow the spec (any revision). I don't agree that poor application
programming is a result of the Postel principle, it's a result of
incompetence or laziness.

Cheers,
Andy

On Tue, May 7, 2019 at 4:30 PM Barry Leiba <[email-masked]> wrote:

> > I find the document (as currently written) is incorrectly interpreting
> the robustness principle as saying there is no need for clear rules on
> protocol evolvability/extensions. For example, section 6, "relying on
> implementations to consistently apply the robustness principle is not a
> good strategy for extensibility". In the routing area, we do have rules and
> we use the principle to ensure interoperability, as we don't have the
> luxury to do a "forklift". Section 8's "it is not always possible to
> produce a design that allow all current protocol participants to continue
> to participate", my question would be "but does it harm the network"?
> >
> > Actually most of the document confusingly is not contradicting Postel's
> principle but supporting it (except for the nuances which seem to condone
> forklifts). It just erroneously blames Postel for sloppy implementations.
> For the document to summarize saying "the robustness principle can, and
> should, be avoided" as it is harmful (I think) will be harmful to the
> Internet.
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 May 2019 16:53:52 -0400

> continue to prioritise mail delivery (for non spam)

No, of course not, not today, not with the history we have.  But if
they had *from the beginning*, we wouldn't be where we are.  And
that's the point.

Barry

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 May 2019 16:53:34 -0400

> consequences of adhering to that principle that Jon didn't anticipate.

s/consequences of adhering/consequences of blindly adhering/

It's the robustness *principle*, not the robustness law; as with most
principles, it should be applied with thought and consideration.

If the principle is completely ignored, one ends up with ossified
protocols; every bit has to be defined and checked - and we cannot easily
extend (things like GREASE exist so some extent to stop this). If it is
strictly followed then I should be able to send you "Hel ow Brry, hwz leye
f?" and expect you to be able to cope with it.

The principle should be applied judiciously (sometimes it isn't), not
discarded.

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Tony Li <[email-masked]>
Date: Tue, 7 May 2019 13:54:33 -0700

> I don't agree that poor application programming is a result of the Postel principle, it's a result of incompetence or laziness.

… or humanity.  Bugs happen.

Tony

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 May 2019 21:58:27 +0100

Hiya,

> they had *from the beginning*, we wouldn't be where we are.  And

Hmm. Even given that at the beginning interop with non Internet
mail was such a big deal? Again, I'll defer to those who do that
kind of code, but when I was involved with X.400 stuff back in
the '90s, (so not the beginning, but not recent either;-) I'm not
sure being so strict would've been at all feasible.

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Tue, 7 May 2019 16:00:09 -0500

On 5/7/19 3:48 PM, Andrew G. Malis wrote:
> I don't agree that poor application programming is a result of the 
> Postel principle, it's a result of incompetence or laziness.

For better or worse, significant portions of the Internet -- at least at 
the application layer -- run on what you're calling incompetence and/or 
laziness [1] . The question is: to what degree has Postel's Principle 
contributed to this state of affairs; and, if we think it's a major 
factor, can we change things so that future protocols don't suffer from 
this as much?

To be clear, I'm not reading this as trying to put the genie back in the 
bottle for already-deployed protocols like SMTP. I read this as 
suggesting that maybe future protocols should be a bit more picky about 
not accepting messages that are malformed or sequences of messages that 
are unorthodox, even if some degree of processing is technically possible.

/a

____
[1] More generously, they're probably more the result of things like 
cutting corners to meet deadlines and budgets, when the people cutting 
corners suffer no consequences for the resulting protocol pollution.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 May 2019 21:08:39 +0000

> I read this as 
  
Then perhaps change the title to something that doesn't act like a red flag.

"On the benefits of XML-style strictness in protocols" perhaps?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 May 2019 17:13:20 -0400

I note that both Adam and Barry in their emails talk about this being 
particularly applicable at the upper layers.

Except that is not what the document says.  If you want to write a 
document about application protocols, then the applications area can 
have the discussion.
But this document does not say that.

So in addition to seconding the comments from several other people, I 
would ask that the document be aligned with what the supporters say it 
is about.

Yours,
Joel

---

From: Adam Roach <[email-masked]>
Date: Tue, 7 May 2019 16:23:18 -0500

> particularly applicable at the upper layers.

Please don't confuse "at least" with "particularly" in my response. I'm 
just acknowledging that I don't have the expertise to speak to the other 
layers.

I know that lower layers *have* had issues with accepting and attempting 
to interpret, e.g., Christmas Tree Packets with varying degrees of issue 
arising, so the situation is certainly not *isolated* to applications.

/a

>> For better or worse, significant portions of the Internet -- at least 
>> at the application layer -- run on what you're calling incompetence 
>> and/or laziness [1] . The question is: to what degree has Postel's 
>> Principle contributed to this state of affairs; and, if we think it's 
>> a major factor, can we change things so that future protocols don't 
>> suffer from this as much?
>>
>> To be clear, I'm not reading this as trying to put the genie back in 
>> the bottle for already-deployed protocols like SMTP. I read this as 
>> suggesting that maybe future protocols should be a bit more picky 
>> about not accepting messages that are malformed or sequences of 
>> messages that are unorthodox, even if some degree of processing is 
>> technically possible.
>>
>> /a
>>
>> ____
>> cutting corners to meet deadlines and budgets, when the people 
>> cutting corners suffer no consequences for the resulting protocol 
>> pollution.
>>
>>
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 May 2019 14:32:38 -0700

> On May 7, 2019, at 1:38 PM, Stephen Farrell <[email-masked]> wrote:
> 

The alternative is what I see in "modern" specifications, like e.g. QUIC. Something like "MUST NOT" send extensions that have been previously negotiated and "MAY" terminate the connection with prejudice if the peer does something illegal. And yes, implementations follow the MAY path.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 May 2019 22:44:59 +0100

Hiya,

Just to clarify where I'm coming from...

On 07/05/2019 22:32, Christian Huitema wrote:
> The alternative is what I see in "modern" specifications, like e.g. QUIC.

ISTM taking the approach outlined in Martin's draft with QUIC
is a good plan. I also know that this approach has improved
TLS even though TLS didn't start out doing things this way.
And I can totally buy it being valuable to at least consider
taking this approach for any new work. So I do like the core
idea on which the draft is based.

I'm just not sure as to how generally it can be applied, nor
if we can really say that "if only protocol X had taken this
approach, things would have turned out better."

S.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 8 May 2019 07:50:41 +1000

> they had *from the beginning*, we wouldn't be where we are.  And
If the Internet (and particularly the web) hadn't "mostly just worked"
despite us doing it all wrong, it might not have taken off at all.

Cheers
Matthew Kerwin

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 7 May 2019 17:53:32 -0400

> continue to prioritise mail delivery (for non spam)

We *didn't*: back in the days when we were gatewaying messages between
the ARPAnet and CSnet and Usenet and everything else, we went out of
our way to shovel everything through no matter how awful it looked,
because we were happy (and relieved) (and sometimes mildly astonished)
that anything at all worked.

But now?  In the decades since, we've learned that every tiny opening
can be and will be exploited by someone, often in surprising ways.
The pendulum has swung a long way from "be liberal in what you accept"
because it's now dangerous.  When I think about Jon, and of what he
envisioned, I'm saddened by this.

But my sentiments aside, and all the history aside, anything new needs to
be nailed down as tightly as possible in specification and implementation,
because any gaps will be found and used.  Anything old needs to have the
holes fixed as best we can without breaking too much too fast.

Jon was right.  But the world is wrong, and now we have to cope with it.

---rsk

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 May 2019 18:05:38 -0400

I think the problem is an interaction of poor programming and inability to
reach implementers (and then the consequences). For example,

* Some major open source or big-company server implementation allows lots
of variation beyond the spec.
* Then, clients test against this implementation and declare "ready to
ship" when the bits flow without error messages. Programming is mostly done
based on examples and a casual reading of the spec. In text protocols,
spacing, line breaks, capitalization, ordering and other variations are
done by "feel" rather than ABNF.
* Since implementers usually have no good way to reach other implementers
(or assume a timely response or well-informed response), they have to make
expedient choices, making the problem worse over time.
* As noted in the draft, this now means that everyone has to be
bug-compatible, raising the complexity in code and testing, and probably
further entrenching dominant implementations.
* Buggy small-scale implementations become major clients or servers, so
what was excusable as a no-impact hobby project becomes a burden on
everyone else.

Thus, dominant implementation have a particular responsibility as their
"leakiness" pollutes the larger eco system. Low market-share
implementations have to go with the flow, as a random hobbyist has little
hope of getting a Fortune 500 company to change its errant ways.

It would be useful to have protocol syntax checkers that would indeed be
strict, just as we have for JSON (with the limits noted in the draft) and
XML and if there was a torture test for the legitimate variations in syntax
or protocol flow. It would be nice if the document made a few
recommendations besides the "don't do that" aspect.

The document doesn't mention this, but my perception is that this is
particular problematic for protocols that roll their own text-based or
complex, nested binary syntax. Hard to avoid for the early Internet
protocols; probably a bad idea now. Besides the TLS example mentioned, this
seems less of a problem for TLV and other binary protocols, but maybe there
are other examples of undocumented behavior that I'm not aware of.

A variation not mentioned is that we now often seem to have to have two
versions of the same encoding: a generic one that leaves lots of room for
"creativity" (white space and ordering and ...) and a canonical version for
signing with much tighter rules. This seems less than ideal. We have done
this now for ASN.1, XML, JSON and CBOR, I believe.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 May 2019 18:15:22 -0400

Arguing the alternative history is probably not all that productive and may
explain some of the disagreement in this discussion. (as in "Would protocol
X have taken off twenty years ago if all implementations had been strict or
if the spec had been less forgiving?") We do seem to have incurred a
technical debt - and maybe that's a related concept that should be
mentioned, as this is clearly not just a protocol or networking problem.

We now have better tools and a larger community of (more professional)
developers. Sometimes good advice that worked in 1990 is no longer as good
advice now.

Henning

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 May 2019 15:21:16 -0700

On 5/7/2019 3:05 PM, Henning Schulzrinne wrote:

> I think the problem is an interaction of poor programming and
> inability to reach implementers (and then the consequences). For example,
>
> * Some major open source or big-company server implementation allows
> lots of variation beyond the spec.
> ship" when the bits flow without error messages. Programming is mostly
> done based on examples and a casual reading of the spec. In text
> protocols, spacing, line breaks, capitalization, ordering and other
> variations are done by "feel" rather than ABNF.
> * Since implementers usually have no good way to reach other
> implementers (or assume a timely response or well-informed response),
> they have to make expedient choices, making the problem worse over time.

For an example of that, see the discussion on the IPv6 mailing list
about sticking random bits in the link local prefix. The specs do not
allow it, but the Linux implementation does. The experimenters tried on
Linux and it worked, hence concluded that it was a fine extension to the
standard...

And then for a counter example, also related to IPv6. The IPv6 specs
allows implementations to insert a variety of intermediate headers
between the IPv6 header and the transport packet, but many router
implementations just don't like that and slow down or drop packets if
such intermediate routers are present. A case where the spec is arguably
too permissive, or the implementations too strict.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 10:32:55 +1200

Hi Henning,
On 08-May-19 10:05, Henning Schulzrinne wrote:
> I think the problem is an interaction of poor programming and inability to reach implementers (and then the consequences). For example,
> 
> * Some major open source or big-company server implementation allows lots of variation beyond the spec.
> * Then, clients test against this implementation and declare "ready to ship" when the bits flow without error messages. Programming is mostly done based on examples and a casual reading of the spec. In text protocols, spacing, line breaks, capitalization, ordering and other variations are done by "feel" rather than ABNF.
> * Since implementers usually have no good way to reach other implementers (or assume a timely response or well-informed response), they have to make expedient choices, making the problem worse over time.
> * As noted in the draft, this now means that everyone has to be bug-compatible, raising the complexity in code and testing, and probably further entrenching dominant implementations.
> * Buggy small-scale implementations become major clients or servers, so what was excusable as a no-impact hobby project becomes a burden on everyone else.
> 
> Thus, dominant implementation have a particular responsibility as their "leakiness" pollutes the larger eco system. Low market-share implementations have to go with the flow, as a random hobbyist has little hope of getting a Fortune 500 company to change its errant ways.
> 
> It would be useful to have protocol syntax checkers that would indeed be strict, just as we have for JSON (with the limits noted in the draft) and XML and if there was a torture test for the legitimate variations in syntax or protocol flow. It would be nice if the document made a few recommendations besides the "don't do that" aspect.
> 
> The document doesn't mention this, but my perception is that this is particular problematic for protocols that roll their own text-based or complex, nested binary syntax.. Hard to avoid for the early Internet protocols; probably a bad idea now. Besides the TLS example mentioned, this seems less of a problem for TLV and other binary protocols, but maybe there are other examples of undocumented behavior that I'm not aware of.

I have a small amount of experience designing and implementing a CBOR-based protocol, and it is rather different in this respect than nested TLVs. Basically it's infinitely extensible and needs very careful parsing and checking as a result. So the implementer is faced with the problem of what to do *at any point in the syntax* if an unexpected data object shows up. It's hard to make a general recommendation; but blindly following the robustness principle would definitely be a mistake. However, for some protocols and some erroneous data objects, silent discard might be the correct answer. It's dangerous to generalize, IMHO.

   Brian

> A variation not mentioned is that we now often seem to have to have two versions of the same encoding: a generic one that leaves lots of room for "creativity" (white space and ordering and ...) and a canonical version for signing with much tighter rules. This seems less than ideal. We have done this now for ASN.1, XML, JSON and CBOR, I believe.
> 
> Henning
> 
> On Tue, May 7, 2019 at 4:48 PM Andrew G. Malis <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Barry,
> 
>     Except in the cases that you cite (badly formed messages in email and web applications), the Postel principle isn't being followed, as the senders are not being strict in what they send. 
> 
>     The intention, really, was to prevent implementations of a particular version of a specification that, for example, had a field or bit that Must Be Zero, from discarding an incoming message just because that field or bit wasn't actually zero. This allows a protocol to be updated without requiring a flag day or forklift.
> 
>     So what you're trying to prevent is poor application programming that doesn't follow the spec (any revision). I don't agree that poor application programming is a result of the Postel principle, it's a result of incompetence or laziness.
> 
>     Cheers,
>     Andy
> 
> 
>     On Tue, May 7, 2019 at 4:30 PM Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         On Tue, May 7, 2019 at 3:18 PM BRUNGARD, DEBORAH A <[email-masked] <mailto:[email-masked]>> wrote:
>         >
>         > From: IAB <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
>         > To: [email-masked] <mailto:[email-masked]>
>         > Cc: [email-masked] <mailto:[email-masked]>
>         > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>         >
>     [email-masked] <mailto:[email-masked]>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 May 2019 18:53:59 -0400

It's kind of the inverse robustness problem - lots of perfectly-well
documented protocol features are not usable in practice since they break
"lazy", but important, implementations. The SIP crowd will remember the
endless discussions about MIME multipart.

In those cases, it would probably be wise to simply declare that a
well-intentioned feature is no longer recommended for new implementations
and possibly look for alternative options. (We seem to get into the
circular arguments of "We need X", "use standard mechanism M to do X", "but
none of the major implementations do M and are unlikely to in the
foreseeable future", "but we cannot have two ways to do X and M is actually
a better idea"; wait two years; repeat. Alternative: people develop a
kludge that kind of works.)

The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to
catch this, but that process protocol path obviously was also rarely
exercised.

Henning

---

From: Mark Andrews <[email-masked]>
Date: Wed, 8 May 2019 09:52:42 +1000

The fix for that is to implement the new feature and get customers to log
bug reports against the other implementation.  It does work.  Even Fortune
500 companies listen to their customers.

Implementations can be fixed and with regular update mechanisms in place
the fixes do get deployed.

In early 2018 the open source DNS vendors declared a flag day on Feb 1, 2019.
We where no longer going to treat timeout as “the server doesn’t understand EDNS”.
I.e. we where intending to deliberately break interoperation with servers that
where stuck in the last century.  We set up a site where you could test your
servers to see if your servers where broken.   We also had that site report
a whole lot of other EDNS protocol violation.  You got RED if there was a
fatal fault, ORANGE if any other fault was detected and GREEN if the server
passed the test queries.  The number of sites which would get RED was << 1 in
10000.

We advertised this flag day, in a number of places.  The testing server got
overwhelmed and DNS vendors with broken servers got thousands of “this
site says your product is broken, when are you going to fix it” complaints.
Implementations got fixed and the fixes got deploy.  This included firewall
vendors fixing their default blocking rule.

https://ednscomp.isc.org/ has lots of graphs which show failures of various
populations of servers and how things changed in the lead up to Feb 1 and
later fixes being released and deployed.  In particular
https://ednscomp.isc.org/compliance/ts/au.optfail.html show Microsoft fixing
their servers (see the “echoed” line).  The Jan 28 was when they fixed their
Azure service.  The drop around April 11 is when fix pushed out in the March
patch Tuesday release started to take effect.

The March 1 failure spike was when one of the links from the testing site
started dropping DNS UPD packets but passed DNS TCP packets.  It took a
couple of days to track down the bad (wrong style for the conductor) RJ48
connector that caused that failure.

> On 8 May 2019, at 8:53 am, Henning Schulzrinne <[email-masked]> wrote:
> 
> It's kind of the inverse robustness problem - lots of perfectly-well documented protocol features are not usable in practice since they break "lazy", but important, implementations. The SIP crowd will remember the endless discussions about MIME multipart.
> 
> In those cases, it would probably be wise to simply declare that a well-intentioned feature is no longer recommended for new implementations and possibly look for alternative options. (We seem to get into the circular arguments of "We need X", "use standard mechanism M to do X", "but none of the major implementations do M and are unlikely to in the foreseeable future", "but we cannot have two ways to do X and M is actually a better idea"; wait two years; repeat. Alternative: people develop a kludge that kind of works.)
> 
> The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to catch this, but that process protocol path obviously was also rarely exercised.
> 
> Henning
>  
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 7 May 2019 22:06:04 -0400 (EDT)

> envisioned, I'm saddened by this.

Having done IKE/IPsec since the late 90s - so 30 years - I can tell you
that applying the "no Postel principle" strictly would only work under
special conditions.

The problem is not the Postel principle. The problem is that we have "too
big to fail" implementations and a lack of implementation diversity. The
Postel principle works fine if there is diversity. As soon as someone
can just do whatever they want, the principle breaks. But that does not
mean the answer is to blindly promote the opposite. That will just end
up with errata's or bis documents to follow the incumbents mistakes.

As an example, Microsoft IKEv2 completely breaks DH/PFS on rekeying. If
I apply the unforgiven stance, either my implementation dies because "it
does not work", or all Windows desktop VPN's die, or both. Additionally,
any Microsoft setup with an intermediate CA would get their CERT
payloads rejected for being in the wrong PKCS#7 format. Again, I am not
an incumbent so I have no choice but to apply the Postel principle for
my own survival.

Another example, if my implementation were strict on IPsec ESP with
SHA2_256 truncation, 1 billion Android devices would not have IPsec VPNs.

An RFC telling me not to do this, is going to get ignored by me.

If anything, Postel's principle was too binary. Sometimes it makes sense
to use, and sometimes it does not. But how to apply that is tricky too.
Should I allow Microsoft to do IKEv2 rekeying with DH using modp1024? It
severely degrades security. Am I in a position to do so? Not really. Can
I document this and tell people to enable a workaround and hope to shame
a vendor into compliance? Yes I can[*]. Without having to break everyone.
Can I put in an Android workaround option and tell the Android developers
everytime I see them they still do it wrong. Yes I can, and after 3
years of harassment they finally fixed it and added their own "legacy"
option to get their old behaviour back.

Now, picking up on the origin of the ESP SHA2_256 truncation bug, this
was caused by the linux kernel implementing a draft instead of the final
RFC. I pointed this out to the Linux maintainer in 2008 or so, long
before Android. Their fix was to keep the original broken behaviour and
add a new API for the new correct behaviour. But people kept using old
software that did not use the new API, including the giant Google. This
is clearly a broken strategy. I'd say you MUST fix your code to be RFC
compliant, and clearly mark such fixes in your changelog/release notes.
Yes, it might still break people, but you might prevent 1 billion future
people from being broken, and anyone who does an upgrade and sees a fail,
can do a downgrade and read up on why and what happened. That is, don't
keep on doing it wrong, because then the workarounds never die. You did
it wrong, then you take the extra work to do it right (and wrong) and
maybe in 10-15 years you can delete the workarounds for your own
mistakes.

It is hard for an old code base to still understand various bits of code
and workaround. This is where comments really help. To give another
example, a recent bug showed my implementation ignored VPN delete
requests within the first few seconds of an established VPN session. I
tracked down the problem and found a comment in the code, that allowed
me to make an informed  decision to remove it:

https://github.com/libreswan/libreswan/commit/82adf12106f4d3b44f80819f6e2858d5cd7dfb97

For people saying "that was 20 years ago, this is a different internet
age", I don't believe that. The incumbents might have changed, but the
scenario of the underdog has not changed.

Now, when we do something fairly new and experimental, and we are
doing our first interops, please reject everything that violates the
draft. Get the first implementations to be rigid and robust. The more
strict those first players are, the better we get compliance out of
the different vendors. But if you find something a year later, and you
can do a workaround based on the Postel principle, be a good citizen
and report the bug and implement the workaround clearly. And remove it
again in a number of years. (bonus: people get rewarded for upgrading
their systems!)

In principle, live according to the Postel principle.

Paul
[*] I'm still in the "hoping" phase on this one :(

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 May 2019 20:35:43 -0700

> idea on which the draft is based.

as a naggumite, being liberal in what one accepts seems too much
of a recipe for entropic chaos.  i would rather catch and fix my
(and your) bugs early.

randy

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 May 2019 21:17:27 -0700

> On May 7, 2019, at 1:29 PM, Barry Leiba <[email-masked]> wrote:
> 

I’ve already noted this in earlier versions of this thread, but to restate:

Protocols are, by definition, a set of rules - rules for BOTH sender and receiver - that enable communication (sharing of state) [Shannon/Weaver]. 

The point of the Postel Principle is to stay INSIDE the lines as a sender, and allow right up to the lines for the receiver.

It is about interpreting the (often unavoidable) aspects of protocol that are ambiguous.

*NONE* of it is about tolerating bugs or errors, nor is it about allowing arbitrary behavior for senders. 

It can’t be - again, protocols are rules. Take away the rules and you take away the ability to communicate.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 May 2019 07:26:23 +0200

Like the end-to-end principle, the robustness principle is one of the most misunderstood, misapplied design principles in networking.  That doesn’t make either principle wrong, it just seems they need good explanations.  Documenting the results of misapplying the robustness principle (including the degenerated end state that I call “soup”) is a good thing, but should be done under the correct heading.  “Deprecating” it is not.

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Wed, 8 May 2019 14:37:37 +0300

I find myself agreeing with many of the posts, but maybe Warren put it most nicely and compactly: "The principle should be applied judiciously (sometimes it isn't), not discarded."

And having seen some of the too-big-to-demand-compliant-interoperability situations that Paul and others mention, I’ve also felt the pain :-)

I find it interesting to compare the situation to analogue situations in other kinds of systems. For instance, I always like to program in defensive style, where my software is as brittle as possible to catch errors. Yet, for delivered software, one often switches to maximum survivability, and often your software components can at least attempt reasonable recovery from many situations that shouldn’t have occurred. More modern software development practices combine development with monitoring, feedback, instrumentation, tracking of new versions in small populations before enlarging their usage, etc. That is kind of a best of both worlds setup, because you can make things survivable but you’ll be receiving real-time feedback on what’s actually happening in the field, and can take corrective action.

This is obviously usable also in our protocol world, but there’s a problem. You can quite easily get a lot of feedback on your own thing working well. You can also get feedback about who you are having problems with. But it isn’t easy to send that feedback to where it might actually belong in many cases: the other implementation’s maintainers. Disconnecting or 4xxing is the crudest form of signal. Yes, sometimes effective. But it also an action between two parties (me as an implementor of my thing and you as an implementor of the peer) that hurts a third party: the user.

I wish there was some other option between the silent obedience and the refusal to talk. But I don’t know what it could be.

Jari

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 May 2019 09:10:30 -0400

Hi.

Having read through this long thread, I want to add one
perspective, very nearly contemporaneously with when the
robustness principle was first enunciated, that complements
several of the comments that have been made, especially by Rich,
Joe, and Jari.

When one is designing and writing standards in almost any field
that involves significant complexity, there is an almost
inevitable choice between: 

-- trying to specify every possible detail so that an
implementer knows what to do in every case and for every design
choice, including what is supposed to be done about each variety
of deviation from the standard by others.

-- specifying the normal cases and general philosophy of the
design or protocol and trust that, with a bit of guidance,
implementers who are reasonably intelligent and acting in good
faith will sort things out correctly. 

We know a few things about the first option.   It causes the
standards development process to take much longer than the
second.  Because standards designers are not infallible, it is
prone to errors, errors that could make the standard completely
unworkable.  For at least some protocols (or devices), it may
not even be possible unless there are complete and deployed
implementations around that can be examined and analyzed,
preferably in combination, in trying to build the standards.  

The IETF, its predecessors, and the Internet community more
generally, have tended to pick the second option.  As someone
else pointed out, the three-stage standards process was intended
as a mechanism to be clear about what we did and didn't know and
what we were prepared to pin down and insist on, with Proposed
being close to "preliminary specification for testing and
evaluation" and an assumption that no enterprise in its right
mind would deploy an implementation based on a Proposed Standard
into large-scale production.  In the context of that choice, the
robustness principle is a guideline about how to think about and
deal with the unanticipated cases and the cases that were not
considered important enough to specify in detail, enough detail
to cover "what happens if someone else sends bad stuff".  

It is not robust (sic) against grossly sloppy behavior,
stupidity, or fools, much less damn fools.  Any implementer who
effectively says "I know I sent you garbage, but the robustness
principle obligates you to accept it an cope" has missed the
point and deserves, at least, community derision.  Those aren't
problems with the principle itself, much less grounds for
deprecating it.  They might be arguments for specifying a bit
more (and, again, that is where the three-stage, or at least the
two-state, standards process were supposed to help).

By contrast, if one does want to deprecate the principle,
realize what that is likely to do to increase the requirement to
specify _everything_ exactly and, in the presence of almost
never using even the two-stage version of the standards process,
the requirement to get everything right the first time.  People
are already complaining about how long it takes the contemporary
IETF to develop and finish a standard (in some cases taking work
elsewhere as a result); consider the impact of an increase in
that time.  

Certainly we've seen enough abuses in the name of the robustness
principle that some clarification, especially about
applicability and context, are in order.  But those who want to
throw it away should start working on the IETF's epitaph.

best,
     john

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 May 2019 09:58:12 -0400

To a different degree, the security community has struggled with this in
the "responsible disclosure" discussion. The incentives are different, but
there seem to be three best practices that might generalize: (1) a
well-documented mechanism to reach the right part of the organization,
beyond the general support mechanism; (2) a reasonable time period to
address the problem; (3) public disclosure after that time period.

A related problem is that it is often difficult for developers to get
advice and help. If they are lucky, they find the IETF mailing list, but it
may no longer be active or such questions may be seen as out-of-scope. We
had the sip-implementors@ list for a while, and it generally seemed
helpful. But this requires somewhat-experienced people willing to help
relative newbies and does not scale well. Interop events (plugfests and the
like) are also helpful, particularly if these include torture tests.

Henning

On Wed, May 8, 2019 at 7:38 AM Jari Arkko <[email-masked]> wrote:

> I find myself agreeing with many of the posts, but maybe Warren put it
> most nicely and compactly: "The principle should be applied judiciously
> (sometimes it isn't), not discarded."
>
> And having seen some of the too-big-to-demand-compliant-interoperability
> situations that Paul and others mention, I’ve also felt the pain :-)
>
> I find it interesting to compare the situation to analogue situations in
> other kinds of systems. For instance, I always like to program in defensive
> style, where my software is as brittle as possible to catch errors. Yet,
> for delivered software, one often switches to maximum survivability, and
> often your software components can at least attempt reasonable recovery
> from many situations that shouldn’t have occurred. More modern software
> development practices combine development with monitoring, feedback,
> instrumentation, tracking of new versions in small populations before
> enlarging their usage, etc. That is kind of a best of both worlds setup,
> because you can make things survivable but you’ll be receiving real-time
> feedback on what’s actually happening in the field, and can take corrective
> action.
>
> This is obviously usable also in our protocol world, but there’s a
> problem. You can quite easily get a lot of feedback on your own thing
> working well. You can also get feedback about who you are having problems
> with. But it isn’t easy to send that feedback to where it might actually
> belong in many cases: the other implementation’s maintainers. Disconnecting
> or 4xxing is the crudest form of signal. Yes, sometimes effective. But it
> also an action between two parties (me as an implementor of my thing and
> you as an implementor of the peer) that hurts a third party: the user.
>
> I wish there was some other option between the silent obedience and the
> refusal to talk. But I don’t know what it could be.
>
> Jari
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 May 2019 10:02:52 -0400

Let's talk about how Disney Studios lost their way. They tried to continue
the methods of the great man after he died and it was a disaster. Then they
suddenly realized that the great man himself had never done things the way
they thought he did. Walt Disney did use storyboards, they were in his head
all the time. So now they use storyboards and if you invested in Disney
back in 2000 you are a very happy camper right now.

We get the end-to-end principle wrapped around the axle in the same way.
The argument is much more subtle than most imagine. The real principle
being *think* very carefully about where you put complexity.

The problems with the robustness principle became clear when we started to
try to extend HTML and found that it was almost impossible to do it right
because every implementation in the wild handled unknown input in different
ways.

The issues with SMTP are not the same because we have never really tried to
change SMTP in drastic ways and even the incremental extensions are all
working around the mass of legacy deployment.

My approach is to distinguish reference code from running code and reverse
the robustness principle. Reference code should be pedantic in what it
accepts and liberal in what it generates. In fact it should perform fuzzing
on its outputs deliberately sending maliciously formed messages to test for
security vulnerabilities.

We live in a different Internet today. There are well funded nation state
actors working to break it. That is their job. There is a full blown
cyber-war going on out there.

The other point I think relevant is that there are limits to re-use of
existing code or infrastructure. There comes a time when starting from
scratch is not just the best approach, it is the only viable approach.
Accepting the robustness principle means this point will be reached sooner.

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 8 May 2019 16:24:46 +0200

Hi,

> Like the end-to-end principle, the robustness principle is one of the most misunderstood, misapplied design principles in networking.  That doesn’t make either principle wrong, it just seems they n…

+1

I think that the interpretation of the Postel principle in
https://tools.ietf.org/html/draft-iab-protocol-maintenance-03
is somehow too rigid.

I always understood it in the way it is described in RFC 1122:

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.

and:

         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.

The latter paragraph shows that the Postel principle tries to ensure
extensibility. The "be liberal" part in reception mainly refers to
implementation robustness, whereas the "send conservatively part"
mainly to interoperability.

I remember a case where ATM switches were not able to setup a connection
because one switch required a specific option (that was non-mandatory)
for setup whereas the other one did not understood and accept the
option.
A more conservative switch implementation would not have sent the
option and a more liberal switch implementation would have ignored the
non-mandatory option.

I think that a major point of the draft
draft-iab-protocol-maintenance-03 is mentioned in section 3:

   An implementation that reacts to variations in the manner recommended
   in the robustness principle sets up a feedback cycle.  Over time:

   o  Implementations progressively add logic to constrain how data is
      transmitted, or to permit variations in what is received.

   o  Errors in implementations or confusion about semantics are
      permitted or ignored.

   o  These errors can become entrenched, forcing other implementations
      to be tolerant of those errors.

The second bullet is not a consequence of the Postel principle.
In the example above: such errors could be caught by corresponding
log messages and should be discussed in interoperability tests,
i.e., they should NOT be silently ignored by developers.
Usually, this should support the process of discovering
parts of the specification that are ambiguous.
Again, the Postel principle does not require to completely
ignore these problems:
they should be used as feedback for improving the specification.

Regards
 Roland

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 May 2019 07:36:46 -0700

> On May 8, 2019, at 7:24 AM, Bless, Roland (TM) <[email-masked]> wrote:
> 
>         ensue.

I’ve always agreed with that perspective, however...

>         …In general, it is best to assume that the network is

This is, IMO, where even one of the most cited interpretations goes off the rails.

Don’t assume malice where incompetence can suffice. 

Joe

---

From: "Henry S. Thompson" <[email-masked]>
Date: Wed, 08 May 2019 17:16:39 +0100

Paul Wouters writes:

> ...
> big to fail" implementations

A historical example may illustrate how high the (organisational) stakes
can be.

The W3C lost control of HTML as a result of a decision, late in the last
century, to commit to XML as the basis for the successor of HTML4 (for
the W3C's own account of this, see [1]).

The 'too big to fail' implementations in this case were initially those
of Apple, Mozilla, and Opera, with Google joining in a bit later.
Different aspects of XHTML2 (the proposed XML-based successor to HTML
4.01 and XHTML1.0) were problems for different constituencies and to
different degrees, but what its opponents regularly cited as XML's
insistence on a "halt and catch fire" approach to ill-formed documents
was the one that was argued with perhaps the most bitterness.

Postel's 'law' was regularly invoked in arguments against the XML
approach, and it lives on in the current version of what is now called
the "Living Standard" of HTML5, as published by the W3C, where we find,
_inter alia_, in the section entitled *Conformance requirements for
authors":

  "Unlike previous versions of the HTML specification, this
   specification defines in some detail the required processing for
   invalid documents as well as valid documents." [2]

One way of understanding the dynamic behind the transfer of effective
ownership of HTML from the W3C to the WHATWG (a quasi-consortium of
Apple, Mozilla, Opera and Google) is as a replay of (the mythology of)
the foundation of the W3C itself, namely, that back in 1988 Microsoft
and Netscape needed a way of managing HTML development that didn't
violate the anti-trust rules.  In the early part of this century, a
major part of browser interop problems lay in the area of error
recovery.  The W3C's XML-based approach was intended to solve this by
"cleaning up the Web":  XHTML2, by being XML, would require strict
enforcement of well-formedness and encourage strict enforcement of
validity.

The browser vendors, in contrast, were terrified of the cost of
increased support calls they predicted would arise, and preferred a
solution sometimes described using the phrase "paving the cow paths",
that is, standardising error recovery.  [see below at **]

The result is a 1069-page-long standard with no BNF or any other form of
concise grammar.  There are 11 pages of prose describing the low-level
'syntax' (angle-brackets and equal signs), and 100 pages of prose
describing the generic parsing _process_, including, of course, error
recovery. And there are just under 500 pages of prose describing, for
every allowed element, how to process its serialisation in detail,
including error recovery.

Would we have been better off with XHTML2?  Not in the short term, I
don't think.  But by now?  How can we know?  But, as Berners-Lee is fond
of saying, "The future is longer than the past"...  We will keep paying
the cost of the lack of incentives to clean up the Web for a long time...

ht

[1] https://www.w3.org/TR/html5/introduction.html#introduction-history
[2] https://www.w3.org/TR/html5/introduction.html#conformance-requirements-for-authors

** John Klensin's recent post arrived after I had written this.  I think
his description of "the first option" is perfectly borne out by what

> ...

> We know a few things about [this option].  It causes the standards
> development process to take much longer than [the alternative].
> Because standards designers are not infallible, it is prone to errors,
> errors that could make the standard completely unworkable.  For [HTML,
> it was only possible because] there are complete and deployed
> implementations around that [could] be examined and analyzed ... in
> combination, in [building] the standards.
-- 
       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]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 May 2019 14:28:46 -0400

One could argue that the Microsoft abandonment of IE and the now-oligopoly
of Chrome, Firefox and Safari is a consequence of that design choice. In
general, for complex protocols, we seem to "converge" to two or three
implementations, with two rolling up 80% of market, the third at maybe
10-15% and everybody else below that (and much of that remainder is usually
legacy, i.e., code no longer under active development). Postfix and
sendmail, bind and ?, httpd and nginx, etc.

The major difference for HTML was that a lot of content is still
hand-edited; telnet for SMTP is probably less common.

Henning

On Wed, May 8, 2019 at 12:17 PM Henry S. Thompson <[email-masked]> wrote:

> [2]
> https://www.w3.org/TR/html5/introduction.html#conformance-requirements-for-authors
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 May 2019 20:38:01 -0400

I'm glad to hear that this works, at least when there are resources
available to do all the things you did (test site, coordination, outreach,
...). I think it would be helpful if the draft could point to such
examples, and maybe failed examples, of how to get out of the
bad-liberalism condition. I suspect that this is workable where the
dominant implementations are open source and where the open source
developers maintain close ties to the IETF community. Maybe we do need a
protocol police in the IETF :-) ("Sir, do you know that you didn't signal
properly?")

Henning

On Tue, May 7, 2019 at 7:52 PM Mark Andrews <[email-masked]> wrote:

> > The old, rarely-exercised, promotion-to-Draft-Standard step was supposed
> to catch this, but that process protocol path obviously was also rarely
> exercised.
> >
> > Henning
> >
> >

---

From: S Moonesamy <[email-masked]>
Date: Thu, 09 May 2019 01:14:49 -0700

Hi Stephen,

[Cc trimmed]

>continue to prioritise mail delivery (for non spam)

My guess is that the implementer would continue to prioritise mail 
delivery by default.  There is some guidance in RFC 1123 (Section 
1.2.2) about the general rule.  I'd say that the rule is about 
handling error conditions gracefully while not replicating the error 
throughout the network.

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 May 2019 11:34:00 +0200

I like Martin’s draft, although I would frame things a bit differently.

There is an aspect of maturity to all of this.  Martin’s experience is with web-related protocols that are largely mature.  In those cases, it simply is not possible for FF/Chrone/… to accommodate most errors or ambiguities because the code path is already quite complex and represents a large attack surface.  I view QUIC largely as an evolution of the existing well known system.

On the other hand, early work is quite difficult to nail down.  Getting something to work at all requires Postel’s principle.  That’s not a matter of programmer or spec writer laziness, but simply a matter of lack of experience everyone’s part.

Let’s not emotionally claim that protocol immaturity introduces a “technical deficit”.  The bell telephone standard arguably had no technical deficits for what it delivered, but it delivered bubkas compared to what we have today, “deficits" and all.

In the next rev, what would be good to see is how and when the principle should be applied, and the other principles that may also conflict with or limit this one.

Eliot

> On 8 May 2019, at 07:26, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 May 2019 13:02:06 +0200

On May 9, 2019, at 11:34, Eliot Lear <[email-masked]> wrote:
> technical deficit

I think we were discussing Technical Debt.

https://en.wikipedia.org/wiki/Technical_debt

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.

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.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 May 2019 13:48:30 +0200

> On 9 May 2019, at 13:02, Carsten Bormann <[email-masked]> wrote:
> 
> https://en.wikipedia.org/wiki/Technical_debt <https://en.wikipedia.org/wiki/Technical_debt>

Yes.  I understood.

> 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!

> 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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 9 May 2019 14:20:24 +0100

Jari, Henning,

Altho long, this thread has been educational for me. Even better, this 
recent thread moves towards solution mode.

Let's explore the idea that incentives are needed to encourage senders 
to tighten-up, rather than permanently rely on the receiver's 
liberality. Henning's responsible disclosure example is a good one, but 
it relies on a lot of human intervention at both ends. The EDNS flag day 
example was also effort-intensive.

Perhaps we need something between Error and Warning, that says "Warning, 
Error imminent". Then, if the developer of the sender doesn't stop 
relying on the liberality of the receiver after a stated deadline, the 
receiver will stop being liberal, and communication will subsequently 
fail (or incrementally degrade, or publicly disclose the developer's 
laziness, etc).

The receiver might need to hold per sender state, but a single 
per-receiver deadline would also be possible (effectively automating a 
per-receiver flag-day).

These warning responses would have to be defined as part of the protocol 
(not necessarily when it was first defined). But how to collect the 
warnings from deployed implementations would be up to developers and 
operators - and they would have the incentive to work this out. The 
rationale is to minimize the work for good implementations, and bounce 
as much of the work as possible onto lazy developers.

At first I thought that an implementer would be unlikely to write the 
necessary warning code, cos they don't care as much about protocol 
purity as protocol designers do. However, if their own code is getting 
increasingly complex, because it's having to handle all the unexpected 
cases, they will have an incentive to encourage the remote ends to 
tighten up their act.

Bob

On 08/05/2019 14:58, Henning Schulzrinne wrote:
> To a different degree, the security community has struggled with this 
> in the "responsible disclosure" discussion. The incentives are 
> different, but there seem to be three best practices that might 
> generalize: (1) a well-documented mechanism to reach the right part of 
> the organization, beyond the general support mechanism; (2) a 
> reasonable time period to address the problem; (3) public disclosure 
> after that time period.
>
> advice and help. If they are lucky, they find the IETF mailing list, 
> but it may no longer be active or such questions may be seen as 
> out-of-scope. We had the sip-implementors@ list for a while, and it 
> generally seemed helpful. But this requires somewhat-experienced 
> people willing to help relative newbies and does not scale well. 
> Interop events (plugfests and the like) are also helpful, particularly 
> if these include torture tests.
>
> Henning
>
> On Wed, May 8, 2019 at 7:38 AM Jari Arkko <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I find myself agreeing with many of the posts, but maybe Warren
>     put it most nicely and compactly: "The principle should be applied
>     judiciously (sometimes it isn't), not discarded."
>
>     And having seen some of the
>     too-big-to-demand-compliant-interoperability situations that Paul
>     and others mention, I’ve also felt the pain :-)
>
>     I find it interesting to compare the situation to analogue
>     situations in other kinds of systems. For instance, I always like
>     to program in defensive style, where my software is as brittle as
>     possible to catch errors. Yet, for delivered software, one often
>     switches to maximum survivability, and often your software
>     components can at least attempt reasonable recovery from many
>     situations that shouldn’t have occurred. More modern software
>     development practices combine development with monitoring,
>     feedback, instrumentation, tracking of new versions in small
>     populations before enlarging their usage, etc. That is kind of a
>     best of both worlds setup, because you can make things survivable
>     but you’ll be receiving real-time feedback on what’s actually
>     happening in the field, and can take corrective action.
>
>     problem. You can quite easily get a lot of feedback on your own
>     thing working well. You can also get feedback about who you are
>     having problems with. But it isn’t easy to send that feedback to
>     where it might actually belong in many cases: the other
>     implementation’s maintainers. Disconnecting or 4xxing is the
>     crudest form of signal. Yes, sometimes effective. But it also an
>     action between two parties (me as an implementor of my thing and
>     you as an implementor of the peer) that hurts a third party: the
>     user..
>
>     I wish there was some other option between the silent obedience
>     and the refusal to talk. But I don’t know what it could be.
>
>     Jari
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 May 2019 19:41:28 -0400

This is how many programming languages work. For example, PHP defines error
handling along those lines:

https://www.php.net/manual/en/errorfunc.constants.php

E_DEPRECATED
Run-time notices. Enable this to receive warnings about code that will not
work in future versions.

E_STRICT
Enable to have PHP suggest changes to your code which will ensure the best
interoperability and forward compatibility of your code.

Having "soft errors" in protocols would indeed be useful. Both SIP and HTTP
have the "Warning" header, but it doesn't seem to be used much.

Henning

On Thu, May 9, 2019 at 9:20 AM Bob Briscoe <[email-masked]> wrote:

> Let's explore the idea that incentives are needed to encourage senders to
> tighten-up, rather than permanently rely on the receiver's liberality.
> Henning's responsible disclosure example is a good one, but it relies on a
> lot of human intervention at both ends. The EDNS flag day example was also
> effort-intensive.
>
> Error imminent". Then, if the developer of the sender doesn't stop relying
> on the liberality of the receiver after a stated deadline, the receiver
> will stop being liberal, and communication will subsequently fail (or
> incrementally degrade, or publicly disclose the developer's laziness, etc).
>
> rationale is to minimize the work for good implementations, and bounce as
> much of the work as possible onto lazy developers.
>
>
> necessary warning code, cos they don't care as much about protocol purity
> as protocol designers do. However, if their own code is getting
> cases, they will have an incentive to encourage the remote ends to tighten
> up their act.
>
>
> Bob
>
>
>> you as an implementor of the peer) that hurts a third party: the user..
>>
> Architecture-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> --

---

From: "Henry S. Thompson" <[email-masked]>
Date: Tue, 21 May 2019 11:14:15 +0100

Bob Briscoe writes:

> liberality. Henning's responsible disclosure example is a good one,
> but it relies on a lot of human intervention at both ends. The EDNS
> flag day example was also effort-intensive.
>
> Perhaps we need something between Error and Warning, that says
> "Warning, Error imminent". Then, if the developer of the sender
> doesn't stop relying on the liberality of the receiver after a stated
> deadline, the receiver will stop being liberal, and communication will
> subsequently fail (or incrementally degrade, or publicly disclose the
> developer's laziness, etc).

Further to this, and to some of Henning's points, the XHTML vs. HTML5
example I raised earlier [1] provides an example of a missed opportunity
to implement something very much along thos lines.  At the height of the
(X)HTML debate, in 2008, Berners-Lee made a presentation to the W3C
arguing for a feedback-and-incentive-based approach to getting people to
stop serving broken HTML.  The write-up of this is now (thanks!) 
publicly available [2], and I recommend it.  For the purposes of this
discussion, you may want to skip the historical/technical introduction
at the beginning and go straight to the *Robustness Principle*, near the
bottom of the first column.

ht

[1] https://mailarchive.ietf.org/arch/msg/architecture-discuss/UEio_fmkxDR8Uj4njD5ajb2e_DA
[2] https://www.w3.org/DesignIssues/HTML-XML.html
-- 
       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]