[ folks interested in actual syslog stuff should skip this message... ]
> Ron Ogle said:
>
> >X.500 vs. LDAP
> >X.400 vs. SMTP
> >OSI vs. TCP/IP
> >SGML vs. HTML
> >CMIP vs. SNMP
> <snip>
> >You can spend your time and this list's time creating grandiose
> frameworks,
> >but history is against you for actually getting it used. Learn from
> history
> >this time.
>
> Of course, you know that many of these were killed by political fiat, not
> lack of presence/effectiveness, right?
first, thanks very much for providing some much needed comic
relief. your statement is reasonable, yet completely lacks any basis in
reality. (if satire was not your goal, then perhaps i misunderstood.)
i'm not familiar with the sgml/html thing, but having been in the
trenches throughout the 80's on the other items, here's the reality:
things in the left-hand column (e.g., cmip) were always blessed with
heaps of political backing from well-funded international organizations
(ccitt, itu, iso, etc.) that claimed to be able to regulate industries,
well-intentioned government organizations (us state department, uk mod,
etc.) that actually could regulate industries, and an all-encompassing
architectures.
things in the right-hand column (e.g., snmp) were blessed with a
limited and self-consistent architecture, a couple of well-heeled
advocates (typically researchers or independent consultants), and a lot
of implementations.
> And there's no definitive proof that the choices made were the right ones
> ( ever heard of complexity theory and Brian Arthur? )
since there is no universally-agreed upon definition of what a "right
choice" is, it is pointless to argue this.
> Look up GOSIP V3 ( U.S. ) - that took the rug right out from under OSI
> because instead of having Govts mandate using the complete OSI protocols
> and take the pain ( the protocols having been already fscked over by the
> "industry" players that stuffed the committees, but it ran, was functional
> and generic ) the Users could now run TCP/IP instead, which gave them a
> cheaper alternative.
actually, gosip was the us government's "last stand" to re-assert its
control over the way protocols got made and breathe life into the
decaying OSI industry. using the us nist as its pointman, the theory was
that if you could co-opt the purchasing decisions of the deepest pockets
in us industry, then the market would respond. i should know, i was the
token "internet" person at the organizing meeting (and thankfully, while
my employer did send me to a second meeting, i never had to go to a third.)
if osi had been able to compete on its own merits, it wouldn't have
needed a bailout from us govt. however, it's probably easier to turn a
sow's ear into a silk purse than get bottomline-oriented organizations
to buy substandard products...
> The fact that there is no Technical reason backing your argument should
> give you some insight into how these decisions have previously been
> derived.
there is actually a plethora of technical reasoning explaining why the
internet approach is superior to the osi approach, both from the
technical and organizational perspective.
for a thorough treatise, consult padlipsky's "the elements of networking
style". my copy was published in 1985, but it was reissued by
prentice-hall in april of 2000. padlipsky, while not the most accessible
writer in the world, has the benefit of being very clear as to what
constitutes good architecture.
alternatively, see if you can dig up a copy of my out-ofprint "the
internet message". given that it was published in 1993, you probably
don't want to spend any money on it, but appendix C contains a reprint
of a paper, "The Future of OSI: A Modest Prediction" presented at an
IFIP meeting back in May, 1992. it explains all the technical reasons in
a brief 14 pages.
> On a personal level, BEEP and syslog-ng show me where the "international
> bureaucrats" who ran the OSI committees went after it folded - they're now
> writing RFCs.
i've been called many things, but "international bureaucrat" is a new
one. here's what makes your statement "reality-challenged": the same
person who:
- helped out on the esmtp effort, and wrote numerous 822/esmtp
implementations (e.g., MH, safe-tcl)
- led the successful, and often amusing, "let's kill OSI" effort in
the IETF (after having spent time as the ietf/osi interworking guru)
- who ran the SNMP effort (with a cast of thousands), authored
dozens of SNMP RFCs and wrote what's now the most commonly-used
testframe for SNMP
also did the engineering on BEEP. but, alas, my arm is getting tired
from patting myself on the back and reminiscing about the legions of
groupies i had back in the wild 80's.
more seriously, the interesting questions are "why BEEP?" and "why BEEP
for reliable syslog?"
the "why BEEP?" part is pretty easy: today, folks are too quick to
design application protocols without thinking things through. you could
get away with that twenty years ago, but today the cost of doing so is
very high. BEEP frees the protocol designer from having to worry about
the administrative issues that all "real" protocols have to address, but
are often dealt with as an after-thought.
here's one simple example: folks are fond of saying that they'll need
support only TLS, or they won't need to support different authentication
technologies. and, for a given point in time in a given environment,
they're certainly right. however, as soon as either time or space
varies, those limitations become apparent.
all beep does is take a half-dozen or so "current practices" and
integrate them into a single framework. with the exception of the
framing protocol, if you don't need something, then you don't have to
implement it -- you just advertise what you support. this makes for a
specification that's larger than most of us would like, but still
small enough to implement. particularly, if you know enough to have the
code "just say no" when the peer asks for something you're not going to do.
the "why BEEP for reliable syslog?" part is a bit harder: if you take
one of the existing one-size-fits-all implementations of beep and try to
add it to your syslog infrastructure, you can get it to work, but you're
not going to be very happy. that's because those implementations were
written with a different set of requirements in mind than the one that
syslog imposes.
if, instead, you write a minimal beep stack that's customized towards
the syslog requirements, you'll probably do about the same amount of
overall work, but you'll be much happier.
of course, the syslog constituency represents one community with its own
set of biases. intellectually, i think the syslog-signed proposal is
much more interesting because it retains a lot of syslog's flavor while
allowing some scale-up in terms of integrity and gap detection.
but, just as you can't seem to find two syslog people who will
consistently agree on the relative importance of reliability, integrity,
privacy, or even timestamp formats, i doubt we're going to get agreement
on what the best protocol infrastructure is for a syslog service.
/mtr
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Jan 16 2003 - 10:22:44 PST