At Fri, 26 Jan 2018 17:32:33 +0100, Petr Špaček <petr.spa...@nic.cz> wrote:
> > as these are requirements without a user-configurable knob. If the > > actual intent was just to specify the default behavior with a > > configurable knob, I'd expect SHOULD-variants are used in cases like > > these. > > Oh, I can see your point. Let me rephrase what I'm trying to say: > I personally agree with the doc, it makes sense to me, and I do not > believe that its wording prevent anyone from adding knobs they want. > Software in the end will do whatever its developers wanted, which might > include knob to override any part of spec. > > An example: RFC 4033 clearly states what should be done if result of > validation is "Bogus". Nonetheless, Unbound has "val-permissive-mode: > yes" which enables admin to pass bogus answers. It's true that an implementer sometimes even ignore MUSTs. And it's also true that we (the IETF) can't do anything to prevent that; after all there's no protocol police. IMO, however, that doesn't mean we can casually use the fact to silence objections when the requirement level might actually be too strong. In my understanding and also according to my experiences, MUST requirements are in fact very strong. Even "I do whatever I want no matter what the standard says"-kind of customers often accept that something cannot be implemented when it's prohibited with a "MUST NOT". It's much more likely that implementations (especially open-source kinds, which tend to respect standard more literally) do not provide a knob to change a MUST behavior. And, if you write your own implementation that doesn't follow a MUST, the reputation risk is much higher than when you are just against a SHOULD. So, if we want to use the strongest requirement level, especially when it's somewhat controversial, I believe that the onus is on the authors (and the WG that supports them) to explain why that level is necessary more carefully and in detail. On the other hand, if we really mean silencing arguments against the requirements with the existence of a user-configurable knob, then IMO what we should actually do is to loosen the requirement level so that it explicitly allows such a knob. (I'm actually not sure whether those who showed support moving forward definitely wants to keep the MUSTs or they can live with SHOULDs). -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
