Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[神明達哉 <[e-mail]>]

At Fri, 26 Jan 2018 17:32:33 +0100,
Petr Špaček <[e-mail]> 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