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

["BRUNGARD, DEBORAH A" <[e-mail]>]

+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 <[e-mail]> On Behalf Of Brian E Carpenter
Sent: Monday, November 04, 2019 8:13 PM
To: [e-mail]; [e-mail]
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt

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, [e-mail] 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://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=
> 
> There are also htmlized versions available at:
> 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=
> 
> A diff from the previous version is available at:
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> 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=
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> 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
[e-mail]
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=