On the other hand, that gateway and that use of MX records helped to unify
addressing and message formats and provide a more uniform user experience
and eventually a cleaner transition to pure Internet based mail. And once
the gateway was in place and the hosts on our DECnet got better internet
mail connectivity, I was able to get MX records setup in appropriate zones,
and have our gateway rewrite outgoing mail ...
sounds like a cool hack. it's good that you didn't need any standards work
to support your project, or it would have been killed by folks who thought
you shouldn't do it that way, because of some kind of latent harm you and
your fellow consenting adults might do each other.
I was pretty naive in those days about potential effects of such things. ...
thank goodness for that.
Today, one of my litmus tests for whether something that violates the
architecture is a Good Idea or not is to look at the likely end state. Will
the hack lead to an ugly end state or is there an attractive transition path
to a clean end state? ... Having "real" DNS names for those hosts (via MX
records in their own zones) pointing to the gateway was more attractive
still. And eventually, having native IP connectivity for those hosts was
even more attractive.
mark horton and a cast of hundreds did the same thing in the UUCP Project.
and this abuse of the MX RR brought thousands of sites to the internet since
"e-mail only" wasn't a desireable state once they had their own domain names.
NAT is an example of a hack that led to an ugly end state. But an alternate
version of NAT, call it NAT-prime, could perhaps have created a transition
path to IPv6.
was it offered? and with more specifics than that? or did the people who
said "NAT would be bad" pretty much say no more than that, expecting somehow
that the great unwashed masses, having been turned away from the temple, would
to back to their hovels and wait for the enlightenment?
I think we're maybe a bit too purist - but only a bit. We need to be
evaluating these things not in terms of how architecturally pure they are,
but by actually analyzing their effects. I seem to recall we've done that
for some hacks - like traffic shapers, maybe - but have been very reluctant
to do so for others, like ALGs. Analysis can be flawed, of course, but it's
better than religious arguments about purity.
only a bit? how much is too much and how would you prove it? analysis that
proves harm to third parties should be heard. hand-wringing about the dangers
to participants or the waste of time should not be heard so much.
But I do think that an analysis of the effects of a hack is in order. And I
think that for any proposal that has the potential to have widespread effect
on the Internet architecture, the burden is on the proposers to argue
convincingly that the hack will do no lasting harm and that it will
encourage a desirable end-state, before the IETF community should back it -
or even agree to publish it.
that's the current state, and owing in part to the impossibility of proving
a negative, it's not working very well.
surely I can make whatever recommendations I see fit, supporting those
recommendations with the best arguments that I can come up with. and people
can heed them or not as they see fit.
as for IETF: if something's a bad idea, IETF shouldn't be compelled to
endorse it by publishing it as an RFC. and if there's a community consensus
within IETF that it's a bad idea, IETF should be able to criticize it.
thanks for the chat, i'm even more sure where i stand now than i was before.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf