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

["Bless, Roland (TM)" <[e-mail]>]

Hi Martin,

I think that you attribute properties to Postel's robustness principle
that are not implied by it. Please reread RFC1122 section 1.2.2.
The robustness principle is not an obstacle for protocol evolution.
I think that we have enough examples of protocols
that have built-in extensible protocol objects (like IPv6's extension 
header)
while there implementations can still adhere to the robustness principle.
So older implementations can still handle new and unknown objects
in a useful manner, thereby not impeding protocol evolution (sec. 6.1
talks also about this, but I don't agree with "In contrast, relying on 
implementations
to consistently apply the robustness principle is not a good strategy 
for extensibility."
as they do not exclude each other).

Your draft says:
"Time and experience shows that negative consequences to 
interoperability accumulate over time if implementations apply the 
robustness principle. This problem originates from an assumption 
implicit in the principle that it is not possible to effect change in a 
system the size of the Internet. It assumes that once a protocol 
specification is published, changes that might require existing 
implementations to change are not feasible."

I cannot find any evidence for the above statements in any formulation
of the robustness principle. You also state
"Today, robustness *is* used as an excuse for protocol developers doing 
a bad job.",
but this is not related really to the robustness principle you are 
referring to.

As I wrote in an earlier mail:
* one aspect of the robustness principle is security: the implementation
   should not crash or be vulnerable to faulty inputs.
   Why shouldn't this be valid anymore in face of protocol evolution?
* another aspect is interoperability (conservative sending) and avoiding
   unnecessary overhead. I also don't see any problems here for protocol
   evolution. The robustness principle would always be applied to the
   corresponding (evolved) protocol specification. If there is an 
evolutionary
   path in the base spec, fine! The protocol can then evolve inside the 
given
   boundaries while the robustness principle still holds for the 
corresponding
   implementation.

The draft also says:
"A flaw can become entrenched as a de facto standard. Any implementation 
of the protocol is required to replicate the aberrant behavior, or it is 
not interoperable."
Obviously, either the protocol spec is not clear enough or the 
robustness principle wasn't really applied
on the sender's side. Instead of diluting the protocol specification by 
adapting other implementations
to the flaw(s) of a single implementation, the aberrant implementation 
should be fixed.
So in this case if the statement "it is necessary for both 
specifications and implementations to be responsive to changes"
this could be applied to the aberrant implementation straight away: go 
and fix it!
More conservative implementations could refuse to interoperate with the 
faulty implementation also due to adherence
to the robustness principle.

Regards,
  Roland

On 14.07.22 at 02:02 Martin Thomson 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