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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Nov 2019 14:13:24 +1300

Hi,

Thanks for the updates, but I still have concerns about this draft.

> Abstract
...
>    For a protocol
>    that is actively maintained, the robustness principle can, and
>    should, be avoided.

To be blunt, I don't think there is community consensus for this
statement. Now the IAB can of course express an opinion, but for
something as contentious as this, I think it needs to be labelled
as an opinion statement, especially in the Abstract which tends
to bias the reader's mindset. Or a more neutral phrasing could
be used; for example:

For a protocol that is actively maintained, the impact of
applying the robustness principle should be carefully considered.

> 1.  Introduction
...
>    Ideally, protocol implementations never have to apply the robustness
>    principle.  Or, where it is unavoidable, use of the robustness
>    principle is viewed as a short term workaround that needs to be
>    quickly reverted.

In an ideal world, all implementations would be perfect, so the
robustness principle would be unnecessary. But the very basis for
it is that the world *is not* ideal and many implementations *are 
not* perfect. So, really, what is the point of the first sentence?

And no, I don't believe it's a short term workaround. That's like
saying: when I've finished testing my Python program, I can take
out all the try:... except:... statements because I've fixed
all the errors, so I don't need the except: cases any more.

On the contrary - good engineers leave the exception handling
in for ever. When they don't, planes crash.

Is there really a consensus view in the community that 
"the robustness principle is viewed as a short term workaround"?
I don't believe it.

> 4.  Ecosystem Effects
> 
>    Once deviations become entrenched, it can be extremely difficult - if
>    not impossible - to rectify the situation.

I take the point. Sloppy usage of the robustness principle can indeed
allow sloppy errors in the spec or in an implmentation to survive. But
there's a trade-off that, IMHO, the draft does not recognize: non-robust
implementations that do not tolerate sloppy inputs are bad for users
trying to accomplish something.

It's perfectly reasonable to argue that an implementation should have
a strict mode, in which it logs errors etc., in a way that allows the
detection of sloppiness at the other end. And I agree that this is of
particular value during active development of the protocol and its
ecosystem**. But I don't see any developer shipping code to the mass
market that has strict mode on by default. I don't see any recognition
of this reality in the draft.

It's also correct to argue that sloppiness in certain security
functions such as algorithm negotiation is never OK.

** If anyone here is masochistic enough to try my prototype
of GRASP, they'll discover that its first two questions to
the user are:

Test mode (many extra diagnostics)? Y/N:
Diagnostics for inbound message parse errors? Y/N:

So yes, I agree with a lot of the points this draft makes.

Regards
   Brian Carpenter

On 04-Nov-19 19:36, [email-masked] wrote:
> 
> 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-04.txt
> 	Pages           : 12
> 	Date            : 2019-11-03
> 
> Abstract:
>    The robustness principle, often phrased as "be conservative in what
>    you send, and liberal in what you accept", 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://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-iab-protocol-maintenance-04
> https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-04
> 
> 
> 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:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Nov 2019 17:24:19 -0800

> On Nov 4, 2019, at 5:13 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> ....

FWIW, even that should have the “in the IAB’s opinion’ as a preface.

However, if that’s not a requirement for ALL such docs out of the IAB, then it should be. These aren’t consensus documents.

Joe

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 6 Nov 2019 21:14:08 +0000

+1 on Brian's points

I may be mis-reading Brian's conclusion, and will take the liberty to re-phrase - "even for a protocol actively maintained, we are not perfect".

I still have difficulty with the title of this document. As Brian says, much of the content of the draft is good. Active/responsible maintenance on our protocols - nothing wrong - totally agree. But to say "the robustness principle is harmful" because it encourages interoperability and discourages proper maintenance/new implementations doesn't parse for me. The title, while attention getting, simply doesn't make sense.

For me, the robustness principle has nothing to do with preventing new extensions on a protocol, it has everything to do with protecting existing deployments. The document's proposal "Choosing to generate fatal errors for unspecified conditions" may be appropriate for some protocols, it would cause a melt down of the network for other protocols. One of my working groups currently is doing a "fix" - and only because of the robustness principle, there have been no issues with current deployments. Sure, when the document was first done, it should have all been perfect. But we are not perfect, even after all the Area Directorate reviews and IESG reviews😊 Theory vs. practice.

RFC1958 is not the only RFC citing the robustness principle - it is in many many documents. How about this one on "The Twelve Networking Truths", unfortunately it is not as easily set to tune as a similar 12-days tune:
https://datatracker.ietf.org/doc/rfc1925/

Regards,
Deborah

-----Original Message-----
From: Architecture-discuss <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Monday, November 04, 2019 8:13 PM
To: [email-masked]; [email-masked]
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt

Hi,

....
>    that is actively maintained, the robustness principle can, and

To be blunt, I don't think there is community consensus for this statement. Now the IAB can of course express an opinion, but for something as contentious as this, I think it needs to be labelled as an opinion statement, especially in the Abstract which tends to bias the reader's mindset. Or a more neutral phrasing could be used; for example:

For a protocol that is actively maintained, the impact of applying the robustness principle should be carefully considered.

....
>    principle is viewed as a short term workaround that needs to be

In an ideal world, all implementations would be perfect, so the robustness principle would be unnecessary. But the very basis for it is that the world *is not* ideal and many implementations *are
not* perfect. So, really, what is the point of the first sentence?

And no, I don't believe it's a short term workaround. That's like
saying: when I've finished testing my Python program, I can take out all the try:... except:... statements because I've fixed all the errors, so I don't need the except: cases any more.

On the contrary - good engineers leave the exception handling in for ever. When they don't, planes crash.

Is there really a consensus view in the community that "the robustness principle is viewed as a short term workaround"?
I don't believe it.

>    not impossible - to rectify the situation.

I take the point. Sloppy usage of the robustness principle can indeed allow sloppy errors in the spec or in an implmentation to survive. But there's a trade-off that, IMHO, the draft does not recognize: non-robust implementations that do not tolerate sloppy inputs are bad for users trying to accomplish something.

It's perfectly reasonable to argue that an implementation should have a strict mode, in which it logs errors etc., in a way that allows the detection of sloppiness at the other end. And I agree that this is of particular value during active development of the protocol and its ecosystem**. But I don't see any developer shipping code to the mass market that has strict mode on by default. I don't see any recognition of this reality in the draft.

It's also correct to argue that sloppiness in certain security functions such as algorithm negotiation is never OK.

** If anyone here is masochistic enough to try my prototype of GRASP, they'll discover that its first two questions to the user are:

Regards
   Brian Carpenter

On 04-Nov-19 19:36, [email-masked] wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_draft-2Diab-2Dprotocol-2Dmaintenance_&d=DwICAg&c=LFYZ-o9_HUMeM
> TSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsRmSzCBeDJz
> yoVaPHVhcM&s=kbSZMir2ED-982IgMsZSmq2G0iPUdthSM2OmHkm7W44&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_draft-2Diab-2Dprotocol-2Dmaintenance-2D04&d=DwICAg&c=LFYZ-o9_HUMeMT
> SQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsRmSzCBeDJzy
> oVaPHVhcM&s=yOBYHio-zq9drjV-NoYsh-7zDm1dbhVtWGDnXX-sQt4&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D04&d=DwICAg&c=LFYZ
> -o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsR
> mSzCBeDJzyoVaPHVhcM&s=cfqDe8UOdKMLYOSZayKW5qXoRtgv_fOKJJVqzXbIc28&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcd
> iff-3Furl2-3Ddraft-2Diab-2Dprotocol-2Dmaintenance-2D04&d=DwICAg&c=LFYZ
> -o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsR
> mSzCBeDJzyoVaPHVhcM&s=_2Gg5j9lE4NJ-fC5UpvjR92DL87-FMEznk37rlLFf50&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.
> 
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern
> et-2Ddrafts_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8
> w&m=Kbpfbfhq9PliTP86bV5fWjsRmSzCBeDJzyoVaPHVhcM&s=fKiTxTwdBtv-0D5ZdWSX
> _yLBdgAV-wejt4IHzTAqnec&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_i-2Dd-2Dannounce&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhG
> pW9lwi9dM7jYlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsRmSzCBeDJzyoVaPHVhcM&s=iZ-
> UvHWovm7zLcAC4hCujoaOsShUADQtZ6qP7jZ_tZ8&e=
> Internet-Draft directories: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shado
> w.html&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Kb
> pfbfhq9PliTP86bV5fWjsRmSzCBeDJzyoVaPHVhcM&s=cReF-yA9QwtrV64dgHdCDDHGMg
> FIWD12ew4N1pCgY7M&e= or 
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1
> shadow-2Dsites.txt&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7j
> YlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsRmSzCBeDJzyoVaPHVhcM&s=ZaMAMODG1LYT-6
> -vEcjh4adopGO4zky8Kbb0pPsVVn0&e=
> 

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_architecture-2Ddiscuss&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Kbpfbfhq9PliTP86bV5fWjsRmSzCBeDJzyoVaPHVhcM&s=kgdQSQezCV64A81czxxBKDaCq-wDS0lG8yl_XwvYRRc&e=

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Nov 2019 22:46:21 +0100

On Nov 6, 2019, at 22:14, BRUNGARD, DEBORAH A <[email-masked]> wrote:
> 
> But to say "the robustness principle is harmful"

(I apologize if I sound like a broken record:)

“Common misunderstandings of the robustness principle are harmful”

Or misapplications.  As with all principles, the robustness principle has its proper domain.
And we now know more about the harmful effects of misapplying it than we did in 1983.

Grüße, Carsten

---

From: Ted Hardie <[email-masked]>
Date: Wed, 6 Nov 2019 14:25:50 -0800

Hi Deborah,

On Wed, Nov 6, 2019 at 1:15 PM BRUNGARD, DEBORAH A <[email-masked]> wrote:

>
>
> For me, the robustness principle has nothing to do with preventing new
> extensions on a protocol, it has everything to do with protecting existing
> deployments. The document's proposal "Choosing to generate fatal errors for
> unspecified conditions" may be appropriate for some protocols, it would
> cause a melt down of the network for other protocols. One of my working
> groups currently is doing a "fix" - and only because of the robustness
> principle, there have been no issues with current deployments.
>
> As Carsten says downthread, some of the applications of the robustness
principle are obviously good.  Some, not so much.  I think we all agree,
though, that maintaining points of extension is both good and, ultimately,
necessary if the Internet is going to continue to change and grow.  One
issue is that some of the points of extension get eaten up by poor
applications of the robustness principle.  If you reserve a code point but
ignore its use in deployments because it has no meaning, it can really
never have a meaning until a forklift upgrade arrives, as you can't tell
which bits ignore it and which use it.  Given our current rate of
ossification, that is a problem.

I don't know the situation you allude to above, and it may not apply
there.  If you can send text on how to distinguish the situation you see
and the doc describes, we'd be grateful.

regards,

Ted

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 11 Nov 2019 21:28:20 +0000

Hi Ted,

With the upcoming meeting, I’ve been swamped with preps, hopefully during the meeting week, can find some time to talk as much easier than email.

I agree with what you have below as likely to be applicable for some protocols but I would be very uncomfortable to say it is universally applicable. In routing, we do many times generate responses for non-recognized requests but the response does not necessarily result in a fatal error. And for many “bits” e.g. flags, depending on the impact, routing may/may not have an error message, :
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/

An example of where we were not “perfect” on first specifying (and assume tolerant receivers):
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/

Maybe I’m a bit more pessimistic than optimistic, I find it hard to parse that generating fatal errors will promote interoperability (if this is what is meant). I think one needs to allow for unexpected behavior and allow graceful failure. One can never be sure all the error cases/delay impacts have been sorted out, especially coming from outside of one’s domain/state machines/microservices. E.g. for a router, one needs first to ensure the integrity of the system is maintained and useful. One can have a beautiful architecture vs. deployment reality.

Carsten – a re-phrasing to clarify would be very helpful.

Cheers,
Deborah

From: Ted Hardie <[email-masked]>
Sent: Wednesday, November 06, 2019 5:26 PM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [IAB] [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt

Hi Deborah,

On Wed, Nov 6, 2019 at 1:15 PM BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> wrote:

For me, the robustness principle has nothing to do with preventing new extensions on a protocol, it has everything to do with protecting existing deployments. The document's proposal "Choosing to generate fatal errors for unspecified conditions" may be appropriate for some protocols, it would cause a melt down of the network for other protocols. One of my working groups currently is doing a "fix" - and only because of the robustness principle, there have been no issues with current deployments.
As Carsten says downthread, some of the applications of the robustness principle are obviously good.  Some, not so much.  I think we all agree, though, that maintaining points of extension is both good and, ultimately, necessary if the Internet is going to continue to change and grow.  One issue is that some of the points of extension get eaten up by poor applications of the robustness principle.  If you reserve a code point but ignore its use in deployments because it has no meaning, it can really never have a meaning until a forklift upgrade arrives, as you can't tell which bits ignore it and which use it.  Given our current rate of ossification, that is a problem.

I don't know the situation you allude to above, and it may not apply there.  If you can send text on how to distinguish the situation you see and the doc describes, we'd be grateful.

regards,

Ted

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Nov 2019 16:33:22 -0800

Brian said:

">    For a protocol

statement. "

[BA] Actually, I don't think you are being blunt enough.

The robustness principle is *fundamental* to the operation of the Internet,
which is about the interconnection of vast numbers of disparate
implementations.  With such diversity (and with the increasing complexity
of protocol specifications) it is inevitable that interoperability problems
will arise frequently.  The robustness principle says "regardless of
whether your interpretation of the specifications is the "right" one" - get
over yourself and make it work.

The idea that "the robustness principle should be avoided" sounds like
something that would belong in a modern remake of a 1960s movie by Stanley
Kubrick:

"Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb"
We could rename it "Dr. NoPackets or: How I Learned to Stop Worrying and
Love Loss of Connectivity"

Brian also said:

"Now the IAB can of course express an opinion, but for something as
contentious as this, I think it needs to be labelled
as an opinion statement"

[BA]  You are being far too kind here.  This is an opinion that just can't
be taken seriously.  Are we sure that it wasn't intended for publication on
April 1?

On Mon, Nov 4, 2019 at 5:13 PM Brian E Carpenter <
[email-masked]> wrote:

> submission
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 12 Nov 2019 17:41:48 -0700

b.aboba> The robustness principle is *fundamental* to the operation of
b.aboba> the Internet, which is about the interconnection of vast
b.aboba> numbers of disparate implementations.

+1

Anyone who thought they were getting interoperability but were sold
protocol conformance can tell you why the robustness principle is vital.
While it may sometimes more resemble bondo or duct tape than we'd like,
interoperability is what the internet runs on.

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Nov 2019 16:58:47 -0800

while i do not think the robustness principle should be avoided per se,
i am not comfortable with enshrining it in concrete.

> The robustness principle is *fundamental* to the operation of the
> Internet

being a naggumite, imiho being liberal in what you accept can be
entropic to the point of breakage.

i would take the principle as guidance, not law.

and i will pretend not to have read your hyperbole

randy

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2019 20:18:23 -0500

In article <CAOW+2duvc21ss5cxXM1Kr94HW3Fpn5nOYu=[email-masked]> you write:
>implementations. ...

Yes, different implementations need to interoperate, but the best way
to make that happen isn't necessarily to program around other people's
mistakes.

In the e-mail world, I can assure you that SMTP implementations are
ever more strict about what they accept, since we've all observed that
real mail software implements SMTP correctly, and the stuff that makes
mistakes is spamware.  By being stricter about what we accept, we more
reliably deliver the mail our users want.

I think you can also distinguish between being liberal about things
that are ambiguous and things that are wrong.  For example, there's no
guidance about whether to send mail addresses in upper or lower case,
so in practice everyone accepts them interchangably.  (Even this turns
out to have less than ideal consequences since in mail with UTF-8
addresses, you can't reliably do case folding until you know what
language the address is supposed to be in, which you usually don't.)
On the other hand, if a mail client sends something that is just
wrong, leaving out required punctuation, or sending out of sequence,
that's just wrong, and generally is fatal for mail senders.

I think there is a lot to be said for Virtuous Intolerance, in at
least some contexts.  Figuring out which contexts the are will be an
interesting challenge.

R's,
John

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Nov 2019 18:33:45 -0800

John said:

“ I think you can also distinguish between being liberal about things that are ambiguous and things that are wrong.”

[BA] Good point. One might not be liberal about potentially malicious activity (your spam example). Ambiguities tend to be resolved over time as standards advance. 

In terms of code complexity, “accept” may just mean “ignoring” and continuing on instead of failing. Sometimes that’s a perfectly fine approach, and one that can result in less maintenance over time. So the robustness principle doesn’t always imply a growing maintenance problem.

> On Nov 12, 2019, at 17:18, John Levine <[email-masked]> wrote:
> 
> that are ambiguous and things that are wrong.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 Nov 2019 10:50:46 +0000

> On 13 Nov 2019, at 00:41, Paul Ebersman <[email-masked]> wrote:
> 

No matter how correct the implementation of a protocol was, from time to time an instantiation will break, be it from human or natural causes. Robustness is what causes the system as a whole to continue to operate despite the (accidental) milevance of a small number of actors. As such it is essential to the operation of any complex system.

- Stewart