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

[Martin Thomson <[e-mail]>]

On Thu, Jul 14, 2022, at 00:33, Joel Halpern wrote:
> Your description of the Robustness Principle below does not match my 
> understanding at all.  It was never intended as an excuse for protocol 
> developers to do a bad job.

I agree, but then I don't.

The Robustness Principle was a totally appropriate tool for the Internet of the 1980s.  What passed for specification was necessarily loose.  That was OK because the people implementing and deploying were collaborators on a research project.  That sort of thing happens all the time when building something complex.  It was, in essence, the author setting out the high-level details and leaving the details to colleagues.  It was partly an embodiment of respect and an acknowledgment that everyone involved was still learning.

That doesn't pass for responsible today though.  People consuming RFCs aren't all respected colleagues who share a common goal and can be trusted to work it out for themselves.  Today, robustness *is* used as an excuse for protocol developers doing a bad job.

I've seen that people are very much willing to drop the excuse and do the work after some nudging.  And I've had to nudge less often recently.

The trick then is in determining what else robustness is good for.  Papering over a temporary interoperability issue is the best I've heard.  Of course, the number of problems I've witnessed arising from that practice makes me want to discourage that as strongly as possible.

Of course, if you have a better definition, please go ahead and produce one. Maybe what I've said makes no sense under an alternative definition.  The text in RFC 760 seems pretty clear to me if you want to rely on documented canon; the same applies to my observations of how it was interpreted.

I'm also not looking to change your mind.  Reasonable people can disagree on points like this.  You clearly have a well-established position based on lots of experience and careful thought.