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

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

+1

Some specifics:

The tone of the document is different. Previously, the emphasis was about protocol implementations being strict in following specifications, and concluding, if maintained, then the robustness principle was harmful. The new Applicability section says “in practice, not all protocol deployments are continuously maintained” and “where implementations are not updated, there is no opportunity ..to update..their implementations.” This new section is now about deployments, placing the blame on the operator for not maintaining their network. Not the first time an operator heard that from a vendor. Also ignores today’s deployments, there are no end-to-end Internet networks that are “one” operator or “one” vendor.

Overall, the document does not address my previous concern – I don’t think this document is correctly interpreting the robustness principle. As someone else said on this thread “the robustness principle doesn’t preclude that either.”

Recommend:

- Rename document “The Harmful Consequences of the Robustness Principle”/s/”Recommendations on Protocol Maintenance” or “How to make a Protocol Robust”: as email discussion has indicated, there are many interpretations of the robustness principle, and there is no agreement it has caused harm.

- Brian’s (June 1) comment: “"[The robustness principle] assumes that once a protocol specification is published, changes that might require existing implementations to change are not feasible."
I don't think that is even close to accurate.” This statement is still present in this current version and still refers to RFC1958. It needs to be removed as there has been no rationale given on this interpretation of RFC1958.

- Applicability section needs a rewrite. Scope to protocol (IETF specifications) vs. network operational practices.

- Remove references to the “robustness principle” as evil. There is no need to blame it as the blocker.

Deborah
(no hats)

-----Original Message-----
From: Architecture-discuss <[e-mail]> On Behalf Of Joel Halpern
Sent: Wednesday, July 13, 2022 10:34 AM
To: Martin Thomson <[e-mail]>; [e-mail]
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-08.txt

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.

If that is what you object to, write a draft that objects to that.  And 
provide examples where you consider that happened. Your current draft 
does something different, asking us to give up a tool that has proven at 
least in the Internet and Routing areas to be very useful.

Yours,

Joel

On 7/13/2022 12:14 AM, Martin Thomson wrote:
> This idea that the robustness principle might step in where the 
> protocol design falls short is exactly the sort of thing that needs to 
> stop. We can do better (see above), but relying on implementers to 
> just get it right was a poor strategy even when we didn't know much 
> better. Collectively, we are a group experts who are equipped with the 
> best knowledge and tooling, so there really isn't any excuse for 
> shipping specifications that fall over when they encounter something 
> as trivially predictable as a race condition.
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/architecture-discuss__;!!BhdT!jtA-CS7aZZJm67fVbliHd3cZcVUuJntM6A2pgcFPYD1HrcSaHMI3MkSdx_7FXWzuaFmBEXpG-TAIXA$ 

_______________________________________________
Architecture-discuss mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/architecture-discuss__;!!BhdT!jtA-CS7aZZJm67fVbliHd3cZcVUuJntM6A2pgcFPYD1HrcSaHMI3MkSdx_7FXWzuaFmBEXpG-TAIXA$