ietf
[Top] [All Lists]

Re: ideas getting shot down

2007-09-18 23:22:38
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf