> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf