A policy for removing named.conf options.

[Warren Kumari]

On Thu, Jun 13, 2019 at 6:46 AM Matthijs Mekking <matthijs at isc.org> wrote:
>
> Dear BIND 9 users,
>
> BIND 9 has a lot of configuration options.  Some have lost value over
> the years, but the policy was to keep the options to not break old
> configurations.
>
> However, we also want to clean up the code at some point.  Keeping these
> options increases the number of corner cases and makes maintenance more
> cumbersome.  It can also be confusing to new users.  We are trying to
> establish an orderly, staged process that gives existing users ample
> time to react and adapt to deprecated options.
>
> The policy below describes our proposal for the procedure for removing
> named.conf options. We would like to hear your feedback.
>
> Thanks, best regards,
>
> Matthijs
>
>
> # Policy for removing named.conf options
>
> A named.conf option will first become deprecated before it is removed
> from the code and becomes an unknown option.
>
> ## Deprecating
>
> A configuration option that is candidate for removal will be deprecated
> first.  During this phase the option will still work, but we will be
> communicating to users that the option is going to be removed soon. A
> user that has deprecated options configured will see warnings in their
> logs and needs to take action to get rid of those log messages.

Many many people don't look at their logs -- could named also print
stuff to (stdout, stderr) when starting?

Note that this will require some testing -- various distributions use
various init scripts - in many cases things printed at startup don't
actually make it to the console, and I'm suspecting some init systems
will barf, but...

Another phased approach would be to require users to acknowledge that
the feature is being deprecated -- initially it could warn, and then
named could require command line flags to enable the (being)
deprecated features, and then in the next release they would stop (e.g
named --enable_deprecated_cleaning-interval). I think that this is way
overkill, but just a thought.

W


> Configuration options that are deprecated will be identified in the
> Release Note for the release they are deprecated in.
>
> Deprecating an option can be done at any time, but preferably before the
> next ESV release.  For example, an option that that needs to be
> deprecated before the ESV 9.16 will need to flagged so in the 9.15
> development or the 9.14 stable release.
>
> ## Removing
>
> A user that has a removed option configured will be unable to start
> `named` because the configuration option is no longer known.  We plan to
> remove options first in an annual stable release, so that we will learn
> what the impact is of removing a certain option before the change hits
> the more popular ESV release.  Configuration options that are removed
> from BIND 9 will be noted in the Release Note for the first version they
> are removed from.
>
> For example, an option that has been marked as deprecated before 9.16
> could be removed in the 9.17 development release (that will become the
> stable ESV release, 9.18).
>
> If it is not removed in the stable release it should also not be removed
> in the following ESV release.  Following the example, it thus should
> also stay in 9.19/9.20.
>
> ## Removing related code
>
> The code that relates to a configuration option that is to be removed
> will in general be deleted at the same time as the configuration option
> is removed.  The BIND 9 team may decide to remove the related code at an
> earlier stage if it is considered harmful to keep. In that case the
> option will become obsolete rather than deprecated.
>
> ## Candidate options to be deprecated/removed
>
> We certainly don't want to remove any options that are still in
> widespread use. Before making the decision to go ahead with removing an
> option, we plan to post a notice on the bind-users mailing list to
> solicit feedback. Depending on the level of concern from the list, we
> may move ahead or decide to defer deprecating the option.
>
> Below is a table of candidate options we may deprecate and remove.  This
> list is by no means set in stone. Feel free to add suggestions, or add
> comments.
>
> | option | will be deprecated in | comments                  |
> | ------ | --------------------- | ------------------------- |
> | cleaning-interval  | 9.15/9.16 | obsolete                  |
> | dnssec-update-mode |           | use auto-dnssec instead   |
> | dialup             |           |                           |
> | managed-keys       | 9.15/9.16 | replaced with dnssec-keys |
> | trusted-keys       | 9.15/9.16 | replaced with dnssec-keys |
>
> In addition, there are already quite some options that are ancient,
> obsoleted, or never implemented before 9.15. They are listed in this issue:
>
>   https://gitlab.isc.org/isc-projects/bind9/issues/1086
>
> and may be removed in the next stable release after 9.16.
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf