Ian Jackson <ian@davenant.greenend.org.uk> writes:
> Slavish adherence to standards, or to the views of mistaken upstreams,
> is a generally a mistake. This is particularly the case for the
> Debian Technical Committee.
>
> The TC's job is to decide what the correct behaviour is, by
> considering the technical merits. The TC's job is not to interpret
> standards documents. (Indeed, within our jurisdiction, our job
> includes changing them if we disagree with them.)
As there's no actual standard document that describes this behavior,
it's a bit weird you feel that you should be the one to change it.
While I agree that the RFC is proposing a sort order which isn't useful
(at all) in the actual implementation of internet routing, I believe
diverging from upstream and the standard without proposing a better way
to solve this problem to be a bad idea. A bad RFC is a (smallish)
problem, but a slightly different, probably under-documented [1]
behavior can lead to, eh, interesting problems as soon as applications
use the upstream behavior for something useful.
To avoid this, spending some time to come up with a better solution
that can be standardized seems like a good idea.
> As the implementor of a DNS resolver library, a past IETF participant,
> a DNS administrator, and someone who's followed some of the IPv6
> transition work, I'm convinced I have that understanding.
Reddening your cheeks and bouncing up and down to display your alpha
male self-image isn't really helpful in a technical discussion.
Marc
Footnotes:
[1] I haven't seen your patch, but I'm pretty sure it doesn't contain a
big fat "DANGER! WARNING! INCOMPATIBILITIES BE HERE!" disclaimer
Attachment:
pgpCkWW9z0eX7.pgp
Description: PGP signature