Re: [arch-d] deprecating Postel's principle- considered harmful

[Bob Briscoe <[e-mail]>]

Jari, Henning,

Altho long, this thread has been educational for me. Even better, this 
recent thread moves towards solution mode.

Let's explore the idea that incentives are needed to encourage senders 
to tighten-up, rather than permanently rely on the receiver's 
liberality. Henning's responsible disclosure example is a good one, but 
it relies on a lot of human intervention at both ends. The EDNS flag day 
example was also effort-intensive.

Perhaps we need something between Error and Warning, that says "Warning, 
Error imminent". Then, if the developer of the sender doesn't stop 
relying on the liberality of the receiver after a stated deadline, the 
receiver will stop being liberal, and communication will subsequently 
fail (or incrementally degrade, or publicly disclose the developer's 
laziness, etc).

The receiver might need to hold per sender state, but a single 
per-receiver deadline would also be possible (effectively automating a 
per-receiver flag-day).

These warning responses would have to be defined as part of the protocol 
(not necessarily when it was first defined). But how to collect the 
warnings from deployed implementations would be up to developers and 
operators - and they would have the incentive to work this out. The 
rationale is to minimize the work for good implementations, and bounce 
as much of the work as possible onto lazy developers.


At first I thought that an implementer would be unlikely to write the 
necessary warning code, cos they don't care as much about protocol 
purity as protocol designers do. However, if their own code is getting 
increasingly complex, because it's having to handle all the unexpected 
cases, they will have an incentive to encourage the remote ends to 
tighten up their act.


Bob


On 08/05/2019 14:58, Henning Schulzrinne wrote:
> To a different degree, the security community has struggled with this 
> in the "responsible disclosure" discussion. The incentives are 
> different, but there seem to be three best practices that might 
> generalize: (1) a well-documented mechanism to reach the right part of 
> the organization, beyond the general support mechanism; (2) a 
> reasonable time period to address the problem; (3) public disclosure 
> after that time period.
>
> A related problem is that it is often difficult for developers to get 
> advice and help. If they are lucky, they find the IETF mailing list, 
> but it may no longer be active or such questions may be seen as 
> out-of-scope. We had the sip-implementors@ list for a while, and it 
> generally seemed helpful. But this requires somewhat-experienced 
> people willing to help relative newbies and does not scale well. 
> Interop events (plugfests and the like) are also helpful, particularly 
> if these include torture tests.
>
> Henning
>
> On Wed, May 8, 2019 at 7:38 AM Jari Arkko <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     I find myself agreeing with many of the posts, but maybe Warren
>     put it most nicely and compactly: "The principle should be applied
>     judiciously (sometimes it isn't), not discarded."
>
>     And having seen some of the
>     too-big-to-demand-compliant-interoperability situations that Paul
>     and others mention, I’ve also felt the pain :-)
>
>     I find it interesting to compare the situation to analogue
>     situations in other kinds of systems. For instance, I always like
>     to program in defensive style, where my software is as brittle as
>     possible to catch errors. Yet, for delivered software, one often
>     switches to maximum survivability, and often your software
>     components can at least attempt reasonable recovery from many
>     situations that shouldn’t have occurred. More modern software
>     development practices combine development with monitoring,
>     feedback, instrumentation, tracking of new versions in small
>     populations before enlarging their usage, etc. That is kind of a
>     best of both worlds setup, because you can make things survivable
>     but you’ll be receiving real-time feedback on what’s actually
>     happening in the field, and can take corrective action.
>
>     This is obviously usable also in our protocol world, but there’s a
>     problem. You can quite easily get a lot of feedback on your own
>     thing working well. You can also get feedback about who you are
>     having problems with. But it isn’t easy to send that feedback to
>     where it might actually belong in many cases: the other
>     implementation’s maintainers. Disconnecting or 4xxing is the
>     crudest form of signal. Yes, sometimes effective. But it also an
>     action between two parties (me as an implementor of my thing and
>     you as an implementor of the peer) that hurts a third party: the
>     user..
>
>     I wish there was some other option between the silent obedience
>     and the refusal to talk. But I don’t know what it could be.
>
>     Jari
>
>     _______________________________________________
>     Architecture-discuss mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/