Paul Vixie wrote: >> 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. > well, the MX standard _did_ support that project. if MX support hadn't been widespread by then, it wouldn't have worked. (and indeed, it wouldn't have worked in the mid-1980s as too many systems at that time still relied on HOSTS.TXT. really, it was only after the Morris Worm forced people to upgrade their sendmails that MX really started to take hold. even then, a lot of vendors didn't ship sendmails with MX support turned on by default.) >> 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? > something you are missing is that a lot of the "NAT would be bad" messages also got suppressed. it's not as if NAT got killed because people in IETF objected to it. it's more like IETF's unwillingness to look beyond NAT to the underlying problems (other than address space exhaustion) that made NAT attractive caused IETF to miss an opportunity to produce something better. (something we really have a hard time doing in IETF is packaging a solution in such a way that it will be attractive. we tend to work on things in a piecemeal fashion, leaving some parts of the problem unsolved, and hoping that vendors will fill in the gaps) >> 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. > again, I think the burden needs to be on the proposers to demonstrate that what they're proposing is overall a good thing. I think the community, and IESG, should expect thorough analysis of anything that could potentially have widespread effect. hand-waving about the benefits of an idea is no more useful than hand-wringing about the dangers. but analysis beats hand-wringing. >> 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. > as far as I can tell, the current state is that we don't expect such analysis in the vast majority of cases, the proposers don't provide it, and the decision gets made by handwaving and handwringing. >> 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. > well, I have to wonder why you think that someone should be able to compel IETF to support his proposal without getting community consensus. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf