Subject: RE: 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: Randy Presuhn <[email-masked]>
Date: Tue, 7 May 2019 15:19:47 -0700

Hi -

On 5/7/2019 2:50 PM, Matthew Kerwin wrote:
> On Wed., 8 May 2019, 06:56 Barry Leiba, <[email-masked]
> <mailto:[email-masked]>> wrote:
...
> despite us doing it all wrong, it might not have taken off at all.

The very early days of SNMP were plagued by subtle and not-so-subtle
issues resulting from overly-generous application of the Postel
principle.  Yes, it allowed a multiple implementations to be quickly
fielded and the whole thing appeared to work - for a while.  But it
also allowed oversights in the specification (e.g. how big can an
integer be?) to be glossed over, resulting in several interoperability
issues.  Fortunately, these problems were recognized fairly early in
the life of that protocol, and through a combination of industry-
accepted test suites as well as more precise specifications the
worst of the problems were resolved in the various code bases.

If the IETF (and the people writing the code) had not dealt with
those issues as quickly as they did, we'd still be battling those
problems today.

Randy

---

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: "Martin Thomson" <[email-masked]>
Date: Tue, 07 May 2019 22:17:39 -0400

(The discussion seems to have settled on ietf@, so I'm sticking to that.  Thanks to everyone who contributed to the now 70+ emails in my inbox.  Having to sleep while people are at work has that effect.  I'll try to respond to the main points, and to hell with my Narten score for this week.)

Though I think that I disagree with Deborah (and I'll explain why below), I think that her suggested title goes some way to capture the intent of this effort.  Yes, this is intended to deprecate the robustness principle.  To my mind, the meme that the robustness principle engendered is more of a problem than its application.  As Warren suggests, this is not an ideal, but a principle to be applied with due consideration, but that lesson gets lost.

In the time I've been doing the protocol-y thing and engineering more broadly, I've seen the principle abused more than it is applied with that sort of awareness.  To that end - and to Brian's request for a softening of the language - it's important to have a strong title.  I appreciate that this is less principled and more about marketing, but I won't apologize for that.

As Henning points out (and Barry also), application of the robustness principle results in technical debt.  I did consider using the phrase "technical debt" in the draft, but was unsure whether that term was well enough understood.  More seriously, "technical debt" has baggage that could be problematic in this context.  It's almost exactly the right concept - projects routinely take on technical debt in the process of getting stuff shipped and that is more or less what the robustness principle recommends.  As Matthew points out, we probably wouldn't have an Internet without it.  But the scale is different.  Individual implementations or deployments might be the ones to make the decision, but the cost of that decision can transfer to the entire protocol community.  If it were the decision of a protocol community to take on that debt, it would be less of a problem, but decisions are made by a few with fairly serious externalities.

Randy's anecdote about technical debt in SNMP was a good one.  Robert Sparks had a similar experience with SIP that we've discussed previously.  In these cases, the problem was eventually solved, but it wasn't cheap or fast.  Mark Andrews' example about DNS flag day shows that it doesn't have to be too expensive, but perhaps that you do have to be a little aggressive to get results.

Which comes to the Deborah's suggestion that this advocates for "forklifts".  I don't know how deploying patches turns into "forklifts".  Protocol changes don't necessarily imply big product changes.  What is relevant is time.  In a mail to the IAB, Stephen pointed out that the timescales on which changes can be made are highly relevant and that the document might be read as implying software update on the same timeframe as a browser might be updated.

While I firmly believe that software needs to be more responsive, in part because that is critical for security, I realize that some deployments are highly constrained in the pace at which fixes can be deployed.  In those environments it is appealing to have workarounds deployed rather than to find and agree upon systemic fixes.  The document could probably recognize constraints on deployment timelines better, but I don't think it invalidates the central argument.

As an aside, I've had the experience of meeting someone responsible a bug that our team spent weeks building and deploying workarounds for.  We quickly established that they were unaware of the problem, willing to fix it, and able to do so more effectively than we were.  It was intensely frustrating.  Several people attributed this sort of problem to incompetence/laziness, but I would never suggest that.  As both Tony and Adam were careful to point out, the reasons a bug manifests is not explained so trivially.

Christian pointed out that "modern" protocols are being better at defining error handling paths in an attempt to close off those opportunities for applications of the robustness principle.  (And yes, we have people being more strict.)  This misses what is, I think, the most positive change in how we build protocols.  Holes in specifications are being addressed collaboratively because people are talking to each other and because people are willing to make changes in implementations or specifications as appropriate.  That's not especially new (thanks again for the SNMP example Randy), but it is worth recognizing.

Brian lamented the unconstrained extensibility in CBOR, which I suggest is something that he should take up with the groups that are working on the protocol(s) he is talking about.  Even the idea that you might just go off and robustness principle the protocol until it works right is the whole reason I wrote this draft.

Christian also mentions IP extension headers and Henning multipart in SIP as potential counterexamples.  Cases where the spec is clear, but the implementations refuse to comply.  We've plenty of experience with this on the web also.  The remedy Henning suggests (have the community declare the feature dead and move on) is in my opinion the best thing to do; it's what CSS did and it worked out well, but it took ages to deal with the fallout.  Again, it took an active community with a shared understanding of the goals.

I'm very appreciative of the feedback you have all given on the draft.

---

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: Masataka Ohta <[email-masked]>
Date: Wed, 8 May 2019 15:30:30 +0900

It is merely that Postel's principle is not applicable to
relays, which sends what it accepts without modification.

				Masataka Ohta

---

From: Dave Cridland <[email-masked]>
Date: Wed, 8 May 2019 08:05:52 +0100

On Wed, 8 May 2019 at 05:17, Joe Touch <[email-masked]> wrote:

> 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.
>
Sure about that?

>From RFC 760:

That is, it should be careful to send well-formed datagrams, but should
accept any datagram that it can interpret (e.g., not object to technical
errors where the meaning is still clear).

The parenthetical example is explicitly stating that a datagram with a
technical error should still be accepted.

Now, I entirely agree that shouldn't be the case, but nevertheless it is
what was originally postulated by Postel. Luckily, alongside Kings,
Presidents and Voting, we also reject Sacred Texts and Prophets, so we're
free to say "this rule didn't work out".

I think the principle Postel postulated has a lot of use, but it needs a
narrower and more cautious rewording. The simplistic wording we tend to
lean on is far from the only wording - there are various rephrasings, some
good, some bad, over the years. RFC 1958 contains, in my opinion, one of
the worst of these, and Martin is quite right to criticise it.

RFC 1122, in section 1.2.2, has quite a good discussion of the principle,
and is worth re-examining before you declare the whole thing simply Wrong.

---

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: Joe Touch <[email-masked]>
Date: Wed, 8 May 2019 06:18:03 -0700

On May 8, 2019, at 12:05 AM, Dave Cridland <[email-masked]> wrote:

> That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear).
> 
> The parenthetical example is explicitly stating that a datagram with a technical error should still be accepted.

Your cut off the part about the meaning being clear.

And technical error doesn’t necessarily mean bug. It could mean specification error.

If you stick with the “meaning is clear” part, it’s safe. It’s when we get into what things might, could, or probably mean that there be dragons.

Joe

---

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: Paul Wouters <[email-masked]>
Date: Wed, 8 May 2019 10:11:03 -0400 (EDT)

> The parenthetical example is explicitly stating that a datagram with a technical error should still be accepted.

Many UDP encapsulations of IP packets do not recalculate the outer UDP
checksum. It's a good thing we accept these datagrams with technical
errors.

Paul

---

From: Dave Cridland <[email-masked]>
Date: Wed, 8 May 2019 14:13:09 +0100

On Wed, 8 May 2019 at 14:18, Joe Touch <[email-masked]> wrote:

> If you stick with the “meaning is clear” part, it’s safe. It’s when we get
> into what things might, could, or probably mean that there be dragons.
>

I accept your points, but if the meaning were genuinely unambiguously
clear, it'd likely have been in the specification - the problem is that
when there's some kind of technical error, what is and is not clear becomes
very much in the eye of the implementer.

So while I did indeed fixate on that "technical errors" to the exclusion of
"the meaning is still clear", that's because it's the technical error bit
that I think is the technical error here.

This is also why I drew attention to the RFC 1122 Section 1.2.2 restatement
and lengthy discussion - I don't see anything I could reasonably disagree
with there, yet both the first RFC to discuss the principle (RFC 760 above)
and the last (RFC 1958) both seem problematic to me.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 8 May 2019 14:16:40 +0100

> checksum. It's a good thing we accept these datagrams with technical

There's two observations to be made here, if I understand correctly:

a) The lack of properly checking the outer UDP checksum means that
implementations could avoid recalculating it.

b) We could not enforce such checking now, because of such implementations.

I appreciate what you're saying, but it's unclear if either is a good thing.

Dave.

---

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: Paul Wouters <[email-masked]>
Date: Wed, 8 May 2019 10:25:49 -0400 (EDT)

On Wed, 8 May 2019, Dave Cridland wrote:

> a) The lack of properly checking the outer UDP checksum means that implementations could avoid recalculating it.
> 

It is generally signaled by setting the checksum to 0.  I guess by now,
packet mangling has become so rare, that router implementers prefered
not to check at all and leave it up to the endpoint. We only know what
some of the well known endpoints do.

> I appreciate what you're saying, but it's unclear if either is a good thing.

To me, it makes sense that the endpoints are the only ones checking
these, but I'm not a router vendor and not really qualfied to speak
on these issues. So like you, I'm on the fence on whether this is a
good thing or not. But if it _is_ a good thing, than we only got there
via the Postel principle.

Paul

---

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

> On May 8, 2019, at 6:13 AM, Dave Cridland <[email-masked]> wrote:
> 
> 
> 
> On Wed, 8 May 2019 at 14:18, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On May 8, 2019, at 12:05 AM, Dave Cridland <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I accept your points, but if the meaning were genuinely unambiguously clear, it'd likely have been in the specification

Take a look at RFC errata; you’ll find many counterexamples. Few (if any) protocol specifications are not exhaustively complete.

> - the problem is that when there's some kind of technical error, what is and is not clear becomes very much in the eye of the implementer.

It’s true that the issues often come to light in implementations, but that’s a bit like saying spelling errors are caused by editing.

> So while I did indeed fixate on that "technical errors" to the exclusion of "the meaning is still clear", that's because it's the technical error bit that I think is the technical error here.
> 
> This is also why I drew attention to the RFC 1122 Section 1.2.2 restatement and lengthy discussion - I don't see anything I could reasonably disagree with there, yet both the first RFC to discuss the principle (RFC 760 above) and the last (RFC 1958) both seem problematic to me.

760 includes “where the meaning is still clear”.

1958 just says “tolerate” - which doesn’t mean “accept as valid”. 

In all cases, IMO the Postel Principle just expresses a level of agnosticism that, at a human level, is often expressed as “give others the benefit of the doubt” (when receiving) and “don’t push your luck” when sending.

When you get deep into trying to infer intent (as some in the IETF have done regarding defending against so-called “attacks” that are indistinguishable from benign errors), you end up in trouble. The same problem occurs if you’re too strict in every exchange in both directions.

Joe

---

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: "John Levine" <[email-masked]>
Date: 8 May 2019 11:50:34 -0400

In article <[email-masked]> you write:
>for?

I'm not Barry but I can say that increasingly we do.  We observe
that spamware is badly written, and there are mechanical errors
that are strong indicators that the sender is not someone you want
to hear from.

A common spamware error is "early talking", sending SMTP commands
before the server's initial banner.  If you wait a few seconds before
sending the banner, and hang up on anyone who sends a command first,
you'll lose a lot of spam at low cost.

Another is greylisting, deliberately soft-failing a new sender and
seeing if it retries, since spamware generally won't.

There's another whole can of worms about what to do with mail that
doesn't validate under SPF, DKIM, or DMARC but let's not go there now.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 May 2019 12:49:51 -0400

> Don’t assume malice where incompetence can suffice.

Except that today's network /is/ filled with deliberately malevolent 
entities who are sending traffic that is designed to act against the 
interests of the destinations of that traffic. And there's a such broad 
spectrum of such malevolence that there are essentially no white hats 
out there - only hats that look white if the sun angle is just right.

(and sure, some of the malevolent actors are incompetent, but they're 
getting more competent overall with each passing day)

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 11:04:50 +1200

On 09-May-19 02:33, Joe Touch wrote:
> 
> 
>> On May 8, 2019, at 6:13 AM, Dave Cridland <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>     **//___^

Also, RFC1958 says:

"Principles that seem sacred today will be deprecated tomorrow. The principle of constant change is perhaps the only principle of the Internet that should survive indefinitely." We (the IAB in 1996) didn't consider that we were laying down holy writ.

But yes, the word "tolerate" was carefully chosen. It doesn't say "ignore buffer overflow errors" or "use heuristics to guess what the sender meant". It means "don't throw a fatal exception when something unexpected arrives." And it suggests silent discard unless an error message "is required by the specification". That's entirely consistent with the RFC1122 text that Roland quoted.

We'd better stick to "don't throw a fatal exception when something unexpected arrives" unless we want several billion unhappy users.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 May 2019 16:51:00 -0700

> On May 8, 2019, at 9:49 AM, Keith Moore <[email-masked]> wrote:
> 
> Except that today's network is filled with deliberately malevolent entities.. 
> 

All we experience are behaviors; It’s more than sufficient to react to them.

Attributing intent isn’t any more useful here than in a courtroom.

Joe

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 May 2019 19:55:49 -0400

On 5/8/19 7:51 PM, Joe Touch wrote:

>> On May 8, 2019, at 9:49 AM, Keith Moore <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Except that today's network/is/filled with deliberately malevolent 
>> entities..
>>

I'm fairly confident that nearly everyone who attacks a system or 
network finds ways to justify their actions to themselves as promoting 
some version of a greater good.   But if you're trying to design a 
robust system or network or protocol, it's probably unwise to give the 
attackers the benefit of the doubt.

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 May 2019 19:59:20 -0400

--On Thursday, May 9, 2019 11:04 +1200 Brian E Carpenter
<[email-masked]> wrote:

> But yes, the word "tolerate" was carefully chosen. It doesn't
> say "ignore buffer overflow errors" or "use heuristics to
> guess what the sender meant". It means "don't throw a fatal
> exception when something unexpected arrives." And it suggests
> silent discard unless an error message "is required by the
> specification". That's entirely consistent with the RFC1122
> text that Roland quoted.
> 
> We'd better stick to "don't throw a fatal exception when
> something unexpected arrives" unless we want several billion
> unhappy users.

An observation that goes a little beyond the robustness
principle (but this threat seems to be have already drifted off
it)...    It may be useful to remember that one of the oldest
and most important principles in the design of what were then
called human interfaces to computers is that, when an error
occurs, the result should, if at all possible, provide
information about the cause, rather than either having the
program freeze up or die or generating an error message with the
same information content as "you lose".  As with the robustness
principle, failure to engage in thinking when apply this design
principle often has unfortunate effects, there may be sound
reasons for deciding how much information is too much, and a
good interpretation of the principle may be different for the
kinds and layers of protocols and implementations covered by
1122 than might be the case for those associated for 1123.  But
none of those considerations would be good reasons to discard or
deprecate the principle itself.  Doing so, like doing so with
the robustness principle, would almost certainly cause serious
harm to the perceived quality and usefulness of our protocols
and, in particular (as others have suggested in other contexts)
would increase customer support costs for those the user
community holds responsible when things don't work sufficiently
to cause protocol specifications to be either rejected in
practice or for non-conforming, but less costly to support,
alternatives to be introduced.

best,
   john

    john

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 May 2019 17:04:48 -0700

> On May 8, 2019, at 4:55 PM, Keith Moore <[email-masked]> wrote:
> 
>>> On May 8, 2019, at 9:49 AM, Keith Moore <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> I'm fairly confident that nearly everyone who attacks a system or network finds ways to justify their actions to themselves as promoting some version of a greater good.   But if you're trying to design a robust system or network or protocol, it's probably unwise to give the attackers the benefit of the doubt
> 

If you’re flooding my router I don’t care if you’re attacking me or misconfigured. Trying to determine the difference is a waste of time. Deal with the flood.

If you think you can manage the flood by inferring it was an attack, all you will accomplish is not protecting yourself from an accidentally flood.

What’s the point?

Joe

---

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: Stephen Farrell <[email-masked]>
Date: Thu, 9 May 2019 01:48:50 +0100

Hiya,

On 09/05/2019 01:04, Joe Touch wrote:
> 
> If you think you can manage the flood by inferring it was an attack,
> all you will accomplish is not protecting yourself from an
> accidentally flood.
That seems to make no sense at all to me. I doubt anyone
thinks they can manage DoS attacks by just "inferring."
If they do, they deserve all they get:-)

If someone deploys sensible countermeasures for that kind
of attack then I don't know of accidental behaviours that'd
not be as well handled by those. Or can you quote a concrete
example of such?

But perhaps there's no need really - it could be that you
are disagreeing with an argument that's not been made. The
argument I have seen made, and have made myself, is that
for a given attack behaviour, a network device cannot
sensibly allow/ignore some such events whilst protecting
against others since, at a given moment from a given
vantage point, it can't tell which is "ok" and which not.

So since those aren't distinguishable, no matter what you
think of what potential attackers, we ought treat the
behaviour as an attack. There have btw been people who
have argued that "it's ok that it's us breaking into
those systems as we are the good guys - you techies
should let us in and keep everyone else out."

So the "indistinguishable" argument I've seen used does
not seem to be the argument with which you're disagreeing.

I also don't recall that argument being used in the
context of deliberate vs. accidental threats myself. The
context is rather deliberate attack vs. "deliberate attack
but supposedly ok because we're on the same side." There
really is no way that GCHQ's attacks on Belgacom could
have been construed as an set of accidental events;-)

Cheers,
S.

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 May 2019 19:24:59 -0700

> On May 8, 2019, at 5:48 PM, Stephen Farrell <[email-masked]> wrote:
> 

My point is simple:

- if you’re running out of resources, do you care whether it’s a deliberate, malicious attack or just traffic that takes your site down?
- if you’re not running out of resources, what is really being attacked?

“attack” is irrelevant.

If you have resources you need to protect from over use or incorrect use, do so.

Stop trying to decide WHY; it’s enough to address HOW.

Joe

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 08 May 2019 23:25:30 -0400

> refusal to talk. But I don’t know what it could be.

I'm replying to Jari here because this pithy bit, taken out of context and - after having read John's well considered response - grabbed me.  I've known this exact feeling often, and it's deeply frustrating.

On Wed, May 8, 2019, at 23:10, John C Klensin wrote:
> [...] there is an almost inevitable choice between: 
> 

The choice John presents here is even more fundamental.  Like many others who were brought up on the IETF flavour of specification, I greatly prefer it.  I find WhatWG and W3C specifications incomprehensible for all the reasons Henry articulated.  They are very much in the first category.  Unquestionably thorough in detail, but obstinately inhospitable to the process of extracting higher meaning.  I would be the last person to advocate for following that path.

(I'm going to catch heat for saying that, so let me qualify it a little.  The web platform doesn't operate in quite the same way as the IETF and their choice of specification mode, abhorrent as I find it, does work for that community.  They had to deal with something of a post-robustness-principle technical debt the likes of which many people would have walked away from.  What you see is the result of dedicated, meticulous work that has restored functioning interoperability to that world.  The outcome is uneven, as might be expected, but it functions quite effectively.  Now more so due to the use of a shared test infrastructure that we should be envious of.)

In my opinion, the mistake here is presenting this as a binary choice.  The goal of teaching implementers the protocol remains - for me - the most important function of a specification.  Existing implementations don't need a spec, except to argue over when there are disagreements.  A spec is most helpful in serving in the creation of new implementations.  The state of web specifications might be an indication that the Web has given up on that (there it is again; Web people, you have my email address :), but I believe that to be the most important function of IETF specifications.

The trap that leads to the binary choice is - again - in the assumption of immutability of specifications and the unwillingness of others to amend their errant ways.  But we all come the IETF with the idea in mind that we can work together on improving things, and surely proper functioning of protocols that are important to us (and our businesses) is high on our list of priorities.  If I thought that RFC 2246 were set in stone, I'd have stayed home.  If I thought that other implementers were not prepared to consider changes to their implementation in response to a consensus decision on a protocol, I could have saved a lot time sitting in aeroplanes and airports.

Possibly the best thing that has come out of IETF involvement for me has been the communities I've joined as a result.  When presented with an interoperability challenge, my first reaction now is never to look for a workaround.  Once I determine that it isn't a local problem (i.e., my fault: a lot of the problems we see), I try contacting someone responsible for the problem.  And that's worked more often than not.  People are responsive to reports of problems with their systems.  If we conclude that we need to change specs, we work out how to do that.  As a result, I haven't built a workaround for a while now; we've even started to remove them from code, mostly as a result of better collaboration and continued protocol maintenance.  (To the earlier discussion about deployment timelines, I appreciate how much this is a privilege.)

Getting back to the binary choice, this is where the immutability of the RFC series and our processes work against us.  The view that the specification has to be "done" is a trap.  John points at the idea of progression from Proposed Standard to Internet Standard as being the intended way to capture the progression from "probably OK" to "more concretely OK" and "almost entirely good".  While that might have been the intent, I don't think that this has worked out all that well in practice, or that such a directly linear progression is always appropriate.  The maturity of many specs I've worked on is not always uniform in a way that suits that model.

Our highly discrete process hasn't been good at capturing and responding to the evolving needs of a protocol.  On the other hand, one of the good things with the gradual raising of the quality expectations for PS RFCs[1] is that protocols have spent more time in draft form, where changes are far more feasible.  But even in TLS 1.3, where the process was unnaturally extended to deal with the side effects it had on some forms of intermediation, the publication of an RFC is not a stopping point.

If we can, over time, capture all those little pitfalls and fence them in with MUST and SHOULD and whatnot in a specification, we aren't forced to make a choice between a timely spec and a thorough one.  Just start with timely and keep moving in the direction of better.  

[1] What it means to be suitable for the Internet has moved in the same direction as our expectations for PS quality, which is entirely appropriate in my opinion.  That doesn't really change the fundamental analysis of when to ship, just the thresholds.

On Thu, May 9, 2019, at 09:05, Brian E Carpenter wrote:
> But yes, the word "tolerate" was carefully chosen. It doesn't say 
> "ignore buffer overflow errors" or "use heuristics to guess what the 
> sender meant". It means "don't throw a fatal exception when something 
> unexpected arrives." And it suggests silent discard unless an error 
> message "is required by the specification". That's entirely consistent 
> with the RFC1122 text that Roland quoted.

RFC 1122 is my favourite articulation of the "robustness principle", because it isn't the robustness principle as much as it is just straight up common sense.  But the meme takes a different form.  The meme has the temerity of demanding that I design protocols to it, to the point that a response was necessary.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 May 2019 08:24:49 +0200

Hi Martin,

A hearty +1 to most of what you wrote.  Many IETFers now understand that it is important to prevent protocols from degenerating into soup, and we may be unique as an organization by actually started making that a part of our culture.  We should continue on this trajectory.

I think there is one detail missing from this dilemma:

>> — trying to specify every possible detail […]
>> — specifying the normal cases and general philosophy […]

In some parts of the specification, we actually can achieve the former without loss of the latter: Where we have formal description techniques (FDT) that are actually *usable*.

Admittedly, we are as far away from covering whole protocols with usable FDTs as we were 30 years ago when the misapplication of FDTs helped OSI fail.  But for those narrow parts where we have made progress, we should be embracing those usable FDTs, and should actively work on capability building.  We can already achieve good coverage of some areas where many implementation bugs previously tended to lurk.  And FDTs can be an effective bulwark against soupification.

Extending the (usable) reach of FDTs is research, and the new IRTF chair, Colin Perkins, has mentioned that FDTs are high on his agenda.  For IETF use, usability is key; as you say, a thousand pages of assembly language level detail without a big picture visible doesn’t cut it, and I’d add that is true independent of whether the “assembly language” is presented in stylized English or in an unusable FDT.

Grüße, Carsten

---

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: Lloyd Wood <[email-masked]>
Date: Thu, 9 May 2019 08:56:18 +0000 (UTC)

if we’re post Postel, and have seen the end of the end-to-end principle, what’s left?

Lloyd [email-masked],uk

On Wednesday, May 8, 2019, 16:30, Masataka Ohta <[email-masked]> wrote:

                Masataka Ohta

---

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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 May 2019 08:00:29 -0400

Trimmed to retain only one argument Martin made:

On 5/8/19 11:25 PM, Martin Thomson wrote:
...
> RFC 1122 is my favourite articulation of the "robustness principle", because it isn't the robustness principle as much as it is just straight up common sense.  But the meme takes a different form.…

I have never understood the principle to mean that.  I have no idea what 
the meme means, if anything.  If you want to write a document about how 
the Postel Principle is often misunderstood, and that such 
misunderstandings cause problems, I would have trouble disagreeing.
But that is not the document you wrote.

Yours,
Joel

---

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: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 May 2019 09:37:53 -0400

> if we’re post Postel, and have seen the end of the end-to-end principle,

Same as what the Physicists were left with after they moved from Newtonian
physics to Einstein.

Only Einstein does not actually rewrite Newton. 99% of the time it is
Newton's physics that are important and quantum mechanics and relativity
are irrelevant.

The cutting edge of a field MUST always focus on the parts that the
founders didn't get right or didn't get entirely right. Relativity is
actually a Newtonian concept it is at the heart of Newtonian gravity as
well. He just failed to determine that the speed of light was less than
infinite.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 May 2019 10:29:24 +0900

> if we’re post Postel, and have seen the end of the end-to-end principle, what’s left?

Don't mind as the end to end principle holds valid forever.

Those who think otherwise do not understand the principle (e.g.
the original paper includes examples of the principle applicable
to telephone networks).

Moreover, inapplicability of Postel's principle for relays does
not cause any interoperability problems if the original sender
is conservative and the final receiver is aggressive.

						Masataka Ohta

---

From: "Aaron Falk" <[email-masked]>
Date: Fri, 10 May 2019 11:33:01 -0400

The message below (including the bits from Jari, John, and Brian) is 
excellent and thoughtful and I think really advances the conversation.  
I don’t think we should throw out the current standards process but 
you have put your finger on something.

--aaron

On 8 May 2019, at 23:25, Martin Thomson wrote:

> I'm replying to Jari here because this pithy bit, taken out of context 
> and - after having read John's well considered response - grabbed me.  
> I've known this exact feeling often, and it's deeply frustrating.
>
> The choice John presents here is even more fundamental.  Like many 
> others who were brought up on the IETF flavour of specification, I 
> greatly prefer it.  I find WhatWG and W3C specifications 
> incomprehensible for all the reasons Henry articulated.  They are very 
> much in the first category.  Unquestionably thorough in detail, but 
> obstinately inhospitable to the process of extracting higher meaning.  
> I would be the last person to advocate for following that path.
>
> (I'm going to catch heat for saying that, so let me qualify it a 
> little.  The web platform doesn't operate in quite the same way as the 
> IETF and their choice of specification mode, abhorrent as I find it, 
> does work for that community.  They had to deal with something of a 
> post-robustness-principle technical debt the likes of which many 
> people would have walked away from.  What you see is the result of 
> dedicated, meticulous work that has restored functioning 
> interoperability to that world.  The outcome is uneven, as might be 
> expected, but it functions quite effectively.  Now more so due to the 
> use of a shared test infrastructure that we should be envious of.)
>
> In my opinion, the mistake here is presenting this as a binary choice. 
>  The goal of teaching implementers the protocol remains - for me - the 
> most important function of a specification.  Existing implementations 
> don't need a spec, except to argue over when there are disagreements.  
> A spec is most helpful in serving in the creation of new 
> implementations.  The state of web specifications might be an 
> indication that the Web has given up on that (there it is again; Web 
> people, you have my email address :), but I believe that to be the 
> most important function of IETF specifications.
>
> The trap that leads to the binary choice is - again - in the 
> assumption of immutability of specifications and the unwillingness of 
> others to amend their errant ways.  But we all come the IETF with the 
> idea in mind that we can work together on improving things, and surely 
> proper functioning of protocols that are important to us (and our 
> businesses) is high on our list of priorities.  If I thought that RFC 
> 2246 were set in stone, I'd have stayed home.  If I thought that other 
> implementers were not prepared to consider changes to their 
> implementation in response to a consensus decision on a protocol, I 
> could have saved a lot time sitting in aeroplanes and airports.
>
> Possibly the best thing that has come out of IETF involvement for me 
> has been the communities I've joined as a result.  When presented with 
> an interoperability challenge, my first reaction now is never to look 
> for a workaround.  Once I determine that it isn't a local problem 
> (i.e., my fault: a lot of the problems we see), I try contacting 
> someone responsible for the problem.  And that's worked more often 
> than not.  People are responsive to reports of problems with their 
> systems.  If we conclude that we need to change specs, we work out how 
> to do that.  As a result, I haven't built a workaround for a while 
> now; we've even started to remove them from code, mostly as a result 
> of better collaboration and continued protocol maintenance.  (To the 
> earlier discussion about deployment timelines, I appreciate how much 
> this is a privilege.)
>
> Getting back to the binary choice, this is where the immutability of 
> the RFC series and our processes work against us.  The view that the 
> specification has to be "done" is a trap.  John points at the idea of 
> progression from Proposed Standard to Internet Standard as being the 
> intended way to capture the progression from "probably OK" to "more 
> concretely OK" and "almost entirely good".  While that might have been 
> the intent, I don't think that this has worked out all that well in 
> practice, or that such a directly linear progression is always 
> appropriate.  The maturity of many specs I've worked on is not always 
> uniform in a way that suits that model.
>
> Our highly discrete process hasn't been good at capturing and 
> responding to the evolving needs of a protocol.  On the other hand, 
> one of the good things with the gradual raising of the quality 
> expectations for PS RFCs[1] is that protocols have spent more time in 
> draft form, where changes are far more feasible.  But even in TLS 1.3, 
> where the process was unnaturally extended to deal with the side 
> effects it had on some forms of intermediation, the publication of an 
> RFC is not a stopping point.
>
> If we can, over time, capture all those little pitfalls and fence them 
> in with MUST and SHOULD and whatnot in a specification, we aren't 
> forced to make a choice between a timely spec and a thorough one.  
> Just start with timely and keep moving in the direction of better.
>
> [1] What it means to be suitable for the Internet has moved in the 
> same direction as our expectations for PS quality, which is entirely 
> appropriate in my opinion.  That doesn't really change the fundamental 
> analysis of when to ship, just the thresholds.
>
> RFC 1122 is my favourite articulation of the "robustness principle", 
> because it isn't the robustness principle as much as it is just 
> straight up common sense.  But the meme takes a different form.  The 
> meme has the temerity of demanding that I design protocols to it, to 
> the point that a response was necessary.

---

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]

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