A policy for removing named.conf options.

[Ondřej Surý]

> On 13 Jun 2019, at 17:55, Barry Margolin <barmar at alum.mit.edu> wrote:
> 
> In article <mailman.716.1560422804.711.bind-users at lists.isc.org>,
> Matthijs Mekking <matthijs at isc.org> wrote:
> 
>> ## 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.
>> Configuration options that are deprecated will be identified in the
>> Release Note for the release they are deprecated in.
> 
> As others have said, I'm not sure how effective this will be. I suspect 
> most people don't check the logs routinely, only when something goes 
> wrong.

The policy isn’t intended to take care of people who don’t really care. The
policy is here to have a transparent and careful way how to remove options.

> Is it really much of a hassle to leave the obsolete options in the 
> parser, but just ignore them?

Unfortunately, yes, it adds to overall entropy of the source code, and we aim
to fix the cruft that has accumulated in last 20 years. This is more of high
level design decision, but it is something that has to be done because it is
connected with maintenance burden. And it’s a burden we don’t have to really
carry on our shoulders.

Ondrej
--
Ondřej Surý
ondrej at isc.org