Tom, WG:

Comments inline...


> [tp] Strange, I was thiinking quite the opposite, that we had 
> a fragile
> consensus which disappeared in
> Vancouver and has not been refound.  Looking back at the 
> messages posted in the
> past few days, about what should be in the header in what 
> order, I was thinking,
>  what now? because I see no consensus, rather the re-emergence of many
> different points of view.
> So while the proposed charter looks ok, because it does not 
> go into that detail,
> I do not see how we progress any further, into the next level 
> of technical
> detail, of what and
> how should be in the header.

I agree that we have not found consensus again. However, I think we are
in a better shape on the details than it it might look. My personal view
is that many items are shortly before reaching actual consensus. Let me
sum up the items I see. We might use that as a potential basis for
reaching consensus.

#1 testing and code review has shown that there is no point
   in trying to preserve more than <PRI>; RFC 3164 provides
   a false impression of common behaviour.
This is controversal, but the facts are suggesting this is the way it
We should try to reach consensus on this.

#2 The max message length issue resurfaces. There seems to be a
   fragile consensus that we can life with the compromise in
   syslog-protocol and eventualy open a debate if we (ever) go to
   a TCP transport.

Again, controversal, too.

#3 There is a question if NUL octets are to be supported in
   the MSG content.

No consensus yet.

#4 There seems to be a fragile consensus that MSG should 
   primarily contain textual data, including XMLified content.
   On the contrary, pure binary data should not be used.

This is somewhat controversal.

#5 Character encoding in MSG: due to my proof-of-concept
   implementation, I have raised the (ugly) question if we need
   to allow encodings other than UTF-8. Please note that this
   question arises from needs introduced by e.g. POSIX. So we
   can't easily argue them away by whishful thinking ;)

Not even discussed yet.

#6 field order

This is related to #1 and can, I think, quickly be fixed once #1 is

#7 Header fields: there seems to be a fragile consensus that
   MSGID, PROCID, APP-NAME, and VERSION should be in the header
   and TRUNCATE should not be in it.

This needs to be finalized, but I think we are very close.

#8 MSG-octet counting and/or trailer is resurfacing. I think
   this item is not well understood and well discussed.

We need to discuss it.

#9 I have found some minor items not already discussed during
   my proof-of-concept implementation (like "drop requirements"
   and such). These are not absolutely vital, but should be
   considered before a final text is issued (or even the next

This needs to be discussed. As it is new, I have no idea what the
discussion may lead to.

#10 STRUCTURED-DATA: there has been surprisingly few discussion
    about STRUCTURED-DATA. I conclude that this is non-controversal.

The good thing is that more people (especially implementors) are
expressing themselfs on the list. This is what finally makes me feel
positive about finally reaching our goal.

I think we can produce some useful documents if we manage to keep
discussing in the current paste. My whish would be that we focus more on
practical things in this discussion, especially when it comes to
compatibility with existing (deployed) technology. It does not help if
we theoretice things would be this and that when they are acutally
different - even though this "real world" is kind of dirty...

Also, we should try to "fry the small fish" and not solve any need that
might surface. I would also like to see this group moving in a direction
that focusses on results usable in practice. I personally prefer a
solution that is 80% theoretically "clean" but has a 95% chance of
implementation over a 95% "clean" solution with just a low chance of
getting implemented (hint: RFC 3195).

I am an IETF freshman. Anyhow, I often read that the IETF was driven by
"rough consensus and running code". I say "was", because my impression
is that this is no longer the case. I would prefer it were...

If this WG fails, what probably happens is that some implementors stick
together and implement something that is pretty similar to what we have
right now (or totally different - who knows). Just as syslog/tcp is
implemented in this "industry-standard" way. The IETF does not like
plain tcp syslog. Guess what? No implementor or end user cares... ;)
This often-violently-objected transport mode has brought more security
and reliability to the syslog community than anything this group has
done the past years. And yes, it is true, plain tcp syslog as it is
deployed is far from being a clean solution. It's only plus is it

So I think it would be a very helpful if we manage to produce a standard
that solves the currently horrible syslog format scenario. But we need
one that gets implemented...


Syslog mailing list

Reply via email to