Paul Vixie wrote:
... If we fail to provide good ways, consenting adults might (and
usually do) come up with worse ways.
is that how you characterize NAT, firewalls, and application layer gateways?
utk-mail11 may have seemed to you like a way to extend the internet, but
to the greybeards of the time who had crapped upon bitnet and uucp, decnet
mail11 (for example, DECWRL.ENET.DEC.COM) was an abuse of the MX RR, not a
"good way" to use the technology.
boy, that takes me back...
Actually, it probably _was_ an abuse of the MX RR - perhaps not so much
in the case of ENET.DEC.COM (presuming that everything connected to
DEC's DECnet belonged to DEC, it was reasonable for DEC.COM to create
alternate names for its own user communities), but moreso when a single
zone like DNET.UTK.EDU was used to map to hosts like UTMEM that were
connected to UTK's DECnet but which weren't administratively under UTK.
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
to use those DNS names. You could still send mail to
user(_at_)xxx(_dot_)DNET(_dot_)UTK(_dot_)EDU and it would get forwarded to
xxx::user, but
people pretty quickly adopted the new names. That wasn't part of the
original plan for the gateway, but the gateway made it easy to do that.
(And actually I think that somewhere along the way, the idea for doing
that might have come as a result of some feedback from one of those
greybeards.)
I was pretty naive in those days about potential effects of such
things. 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? In the case of
utk-mail11, there was an attractive path to a clean end state. Having a
DECnet gateway that allowed exchange of mail with the Internet without
needing a percent-hack or bangpath or ugly quoted address with an
embedded "::" was more attractive than the alternatives. 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.
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.
firewalls and NAT, by making it harder
to carry real packets from one endpoint to another, were seen as heresy.
do you think that these are "worse ways" that wouldn't've come about had
the IETF provided "good ways"? if so can i hear an example of a better way
that wouldn't be seen as a total departure from "the internet way of doing
things", just to help me frame your position?
Today, I think I could describe a better NAT (and I might try to do that
before Vancouver). I would have had a harder time doing so in the mid
1990s. But even then, if we had had the notion of trying to build
temporary fixes that help to promote a more desirable end-state, NAT
could have been a lot better than it turned out to be. Also I don't
think we did a good job of analyzing the likely effect of NAT - actually
I think there was a fair amount of denial there, or at least a tendency
to pull punches and avoid saying just how bad they were.
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.
It's not that consenting adults shouldn't be able to solve their own
problems, it's that some kinds of solutions can and do cause harm for the
Internet, particularly when they're widely deployed.
i can see how a *.COM wildcard, or any TLD wildcard, fits that description.
i can't see how DNSSEC DLV, or ULA-C, fits that description.
at the moment, they are all condemned using the same buzzwords. i'm asking
that the ones without objectively verifiable immediate harm not be crapped on.
"objectively verifiable" may be too strong. ("immediate harm" certainly
is.) It's like demanding that global warming be objectively verifiable
by watching the polar ice caps melt and proving that it's due to
pollution. (Even if the ice caps do melt, there will still be people
claiming that it's an entirely natural phenomenon. Either that or
divine will.)
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.
p.s. And FWIW, in the message where I said 'It's hard for me to buy the idea
of there not being a "core" portion of the Internet from which all public
addresses are reachable' what I meant was that I have a hard time imagining
the conditions which would make it happen, not that I would try to stop it
from happening. I'd be hard pressed to support it given my current
understanding of it (not that either my support or opposition is worth very
much). But I'd be curious to explore the idea further and see where it
might lead.
that's a useful clarification. but it changes nothing. if other people, who
are not you, and who are consenting adults, want to interoperate using
prefixes under the ULA /7 prefixes but having, unlike RFC 4193 ULA prefixes,
globally visible whois and in-addr support, then it's not your place to tell
them they shouldn't want that or shouldn't have that.
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.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf