Re: TM/UCC distractions [Was Re: in support of axfr-clarify]

[Kevin Darcy <kcd@daimlerchrysler.com>]

ahaukin@hushmail.com wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Danny Mayer wrote:-
> > So, once a change is made how many systems are really impacted,
> > especially given that good admins regularly upgrade the software
> > on their systems anyway?

"All generalizations are false. Except this one" :-)

> I work for a bank. We have a very high level of risk-aversion, which extends to not upgrading software and operating systems unless mission critical -- upgrades which others might consider routine. We ditched BIND (at least on internet facing systems) because of the difficulties of running a secure version of it in production that had also passed through the painfully slow testing and change control process here.

You always have the option of running a non-standards-compliant version of your DNS software, as long as you're not polluting the Net. Specifically, if the only non-conformant part of djbdns is the AXFR client, and you're not using the AXFR client, or if djbdns'es AXFR client deals gracefully with the scenarios we've been discussing here, then I don't think anyone will really care that much that you're running
something that is technically non-standards-compliant.

Or are your PHBs overly strict about RFC standards-conformance as well? They can't have their cake and eat it too: standards evolve, and software needs to change to reflect that evolution. They can't be anti-software-change and pro-continuous-standards-conformance at the same time: something has to give.

                                                                                                                            - Kevin



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>