Re: updated version of XML doc

[by way of "Chris M. Lonvick" <[EMAIL PROTECTED]>]

On Fri, 29 Oct 1999, Kriss Andsten <[EMAIL PROTECTED]> wrote:
"First: Might be an idea to post an URL rather than attach the entire thing
as bloody HTML every time? (After all, that's what the things are for)"


It should definitely go onto the Rutgers web page,
http://njlug.rutgers.edu/projects/syslog -- Chris, could you correspond
with Rob Cermak <[EMAIL PROTECTED]>?

"Second: It's definitely a lot of junk to haul over the network, let alone
process. Yes, looks quite.. comperhensive/bloated (fine line there), but
-sending- the stuff as XML over the net (I get the impression that's the
genereal idea of that thing)..? It's not a very bandwidth considerate way
to send stuff in. It opens you up for a lot of nastyness issues (nesting
tends to do this - granted, sane implementations can avoid problems), if
you consider the data source untrusted."


This is supposed to be a full-fleged secure, robust replacement for syslog
in modern environments where neither network nor CPU bandwidth, nor disk
storage, is at a premium.  I think it is ideal for a TCP-based protocol
where log records can be delimited by "document" boundaries rather than
packets.  The "nastyness" is what provides flexibility in structuring the
log record, and it's the benefit of XML as well as the penalty.  Choosing
XML as an encoding for the record structure makes it possible to reuse the
large amount of available parser/constructor code for XML applications.  If
you invent your own encoding, you will have to do your own parsers;
because coding errors in such things are the most vulnerable feature of
existing protocol implementations (esp. syslogd) reusing documented,
well-exercised code is an important security feature.

"Would it not be a better idea to transform it into XML on the log server
end (as in 'implementation thing, for those who feel they need XML logs'),
keeping the transmission a bit.. dumber/simpler/more robust? Simply
tagging the data by something non-bastardly big (and not neccessarily
human readable) would work well enough, the rest of the spec looks nice,
'cept for a few things: date format should -really- be up to the thing
ultimately parsing the logs. There's No Bloody Use (TM) what-so-ever
sending the timezone (and the other date sugar) with the message itself,
or putting it down as a basic requirement, imo. If the human reading the
stuff wants the junk for some reason, this step can be performed on the
server."

The XML is intended to serve as a wire transport encoding, not necessarily
as a file representation of the log stream.  The reason:  it is possible to
encapsulate either all or small portions of the data in security wrappers,
according to needs, making IPSEC tunnels etc. unnecessary for the majority
of applications.  These XML security tags are not yet standardized,
unfortunately, but they will exist fairly soon, and can still remain the
main benefit of the approach.


"Lastly, it's -not sane- to send IP (or net in general) related stuff in
ascii. Bloody good way to DoS a firewall and log server if every packet
you haul to it that causes a log entry makes a ~400 byte impression with a
lot of ascii gunk to parse. If you force it to use another way of logging
that stuff, well.. it defeats the purpose of a standard logging format,
no? Rather than have a net specific part with source, dest, junk, junk,
format, it might be an idea to have a 'type' saying what the aux data is,
have a couple of defined types, say an ipv4 one that specifies source as a
six byte string (host.port), a mail one that specifies source as an ascii
string (sender). Maybe also spec'ing the fields that'll be sent for the
type of aux data. Yes, XML could do this nicely, but as mentioned above..
treating everything like ascii makes any kind of automatic handling more
of a pain than anything else. Not to mention hauling plain ole XML down
the pipe. All imo, of course. Anyone who thinks spec'ing the data
depending on the facility (type) and keeping it -slim- is a worse
approach?"


Again, it's a wire transport encoding, intended for high-security and
high-functionality logging systems, probably over TCP.  The receiver at the
log server daemon can save the records in XML as received, or encode into
some more compact form for storage economy, or some more verbose form (if
necessary) for readability, filtering, and presentation.  That's the set of
issues discussed in the ULM draft.



Chris Calabrese <[EMAIL PROTECTED]> wrote:

"So far, lots of people have mentioned "bloat" and "complexity", but
nobody's
actually come up with anything less bloated/complex that still gets the job
done.
I would love to see such a thing, but am not convinced I will.  Feel free
to prove
me wrong."


The only alternatives I can see for a different wire encoding that might
provide similar features are (1) a more complete set of <name>=<value> tags
as in ULM, providing for specific <named> items that correspond to security
wrappers etc.,  or (2) some form of TLV (type, length, value) binary or
ASCII encoding such as is found in RADIUS and many other modern protocols.
I don't see a clear benefit of either approach, but if anyone has a
specific proposal alternative to Calabrese's draft, I'd like to see it
developed and discussed.



Magosanyi Arpad <[EMAIL PROTECTED]> wrote:

"The idea that ULM being the subset of this is very neat.
I don't think it is bloated, it's much simpler than Your Average RFC(tm),
and it is elegant. Elegancy is a very important attribute of a protocol
IMO."


It's much more important that the methods used be widely accepted than
elegant!!  (This spoken as an aging ex-OSI guy.)  XML has this most
important property in spades, as we software gamblers say.


But yes, I agree, the approach is elegant, and I think Chris deserves a lot
of credit for contributing it.  I was not aware of the "unalog" XML tools
(www.unalog.com:  personal logging, not system logging) which gave him the
idea;  that stuff is hardly elegant but weeds after all can evolve into
magnificent forests.



Alex Brown <[EMAIL PROTECTED]> +1 508 323 2283