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

[Bernard Aboba <[e-mail]>]

Martin said:

"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."

[BA] The Internet and related services are a utility today, just like water
and electricity.  So the Robustness Principle can also be thought of as an
observation about commercial reality, As such it isn't just a relic of the
1980s. There are plenty of more recent examples.

One that I recall occurred in the 1990s and early 2000s when a widely
deployed access equipment vendor decided to coopt most of an IANA registry
without registering the code points.  It has taken us years to even
partially document what those code points were used for (since they didn't
submit drafts documenting the protocols used either).  And as you might
imagine, the IETF community was not happy. However, the equipment was very
widely deployed and so implementers had to add a switch that when set would
recognize the ill-gotten code points.   It took almost a decade before the
offending equipment became rare enough to remove that switch.

Would it have made sense to tell customers "sorry we refuse to modify our
software to allow you to access the Internet because we are protesting the
behavior of vendor X"  I suspect the customers would not have been in
sympathy with that approach.

For egregious security violations, more spine is typically exhibited, but
even then we often see a classic deprecation notice/removal process,
lasting a considerable period. Look how long it has taken to go from
deprecation of TLS 1.0/1.1 to turning off those versions in deployments.

Martin said:

"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."

[BA] In the examples above, I actually do think that the Robustness
Principle was applied in a responsible way, although my definition may not
be the same as yours and "temporary" can represent a long time.

My view is that keeping the Internet running is job #1.  I do think we are
moving to a world where maintenance cycles are compressed and we can push
out fixes for vulnerabilities on much shorter time frames.  But there is a
lot of end-of-life equipment out there that can't be (inexpensively)
updated, and some ecosystems are dysfunctional because there is little
economic insentive to do long-term maintenance (consumer routers and device
drivers come to mind).

On Wed, Jul 13, 2022 at 5:03 PM Martin Thomson <[e-mail]> wrote:

> 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.
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>