Subject: RE: SyslogMIB Issue-#6
From: Andrew Ross <[email-masked]>
Date: Sun, 1 Feb 2004 10:58:35 +1300

Cool.

If we work on using a text file type config system, we will still need
to work out an identifying format.

Maybe something like...

Syslog Config File
Vendor: Company Syslog
Version: x.x

# This configures the rule set
Rules...

# This configures the inputs
Inputs/Listeners

Etc

Any line beginning with a # is a comment.

The first line "Syslog Config File" is the magic cookie. This ensures we
have a valid config file type.
The vendor line identifies the syslog daemon vendor.
The version line identifies the version of the syslog daemon that the
rule set / config refers to.

Apart from that, it could all be free form text.

Comments?

Cheers

Andrew

- -----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]]
Sent: Saturday, 31 January 2004 11:06 p.m.
To: [email-masked]
Subject: RE: SyslogMIB Issue-#6

On the ipaq, thus brief...

Yes, this would be fine with me.

- ----- Ursprüngliche Nachricht -----
   >Von: "Andrew Ross"<[email-masked]>
   >Gesendet: 31.01.04 00:09:09
   >An: "'Rainer Gerhards'"<[email-masked]>, "'Glenn Mansfield
Keeni'"<[email-masked]>,
"[email-masked]"<[email-masked]>
   >Betreff: RE: SyslogMIB Issue-#6
   >
   >
   >I concur on this point. I think read only would be fine. The rules,
   >filters and settings in the new syslog products are too different
and
   >complex to map into a generic SNMP system at this stage.
   >
   >The only possibility I can think of would be the ability to dump the
   >rule set and configuration in the form of a text file. In this way,
you
   >would rely on the syslog daemon app to process the text and extract
   >rules and settings from the file.
   >
   >Sort of a GetConfigFile and SetConfigFile system. The size of the
file
   >could be an issue.
   >
   >Since most syslogs out there (WinSyslog, Kiwi Syslog, SDSC,
Syslog-ng
   >etc) use a config file, or can be made to read from a config file,
the
   >get/set system might work. You would have to place a meaningful tag
at
   >the beginning of the file to identify the format etc.
   >
   >Would that work for you Rainer?
   >
   >Regards
   >
   >Andrew
   >
   >
   >
   >
   >-----Original Message-----
   >From: [email-masked]
   >[mailto:[email-masked]] On Behalf Of Rainer Gerhards
   >Sent: Saturday, 31 January 2004 3:20 a.m.
   >To: Glenn Mansfield Keeni; [email-masked]
   >Subject: RE: SyslogMIB Issue-#6
   >
   >
   >Sorry for the late follow up...
   >
   >I am not sure if we really desire this. As of my knowledge, most
   >existing syslogds have far more sophisticated rules than the stock
   >syslogd implementtions with just filtering on facility and severity.
And
   >they have, because there is a customer demand.
   >
   >You now can argue that by providing the generic configuration way,
an
   >administrator can at least configure all devices (in a
vendor-ignorant
   >way) to some desired common basic configuration. I just doubt that
this
   >"basic configuration" would just be too limited to be actually
useful
   >for the administrator. So I am not sure if it is really worth
putting
   >this effort in....
   >
   >I have no strong opinion on this, though. But I am a bit on the "we
   >should stick with read-only" side...
   >
   >Rainer
   >
   >> -----Original Message-----
   >> From: Glenn Mansfield Keeni [mailto:[email-masked]]
   >> Sent: Friday, January 16, 2004 10:49 AM
   >> To: [email-masked]
   >> Subject: SyslogMIB Issue-#6
   >>
   >> Issue #6. Configuration Stuff - should it be there ?
   >>
   >> If the MIB is made read-only we cannot use it for configuration
   >> of syslog processes. That is a disadvantage if we wanted to
   >> configure our syslog processes in the first place. Otherwise,
   >> the consequences are
   >>       - implementations would be simpler
   >>       - security implications are lesser
   >>       - passage through the IESG-review process may be smoother
(?)
   >>
   >> So, do we want to be able to configure Syslog processes? Community
   >> input is required here.
   >>
   >> Status: Waiting on community input
   >
   >
   >
   >
   >
   >

------------------------------

Date: Tue, 3 Feb 2004 11:42:47 +0100
From: Rainer Gerhards <[email-masked]>
Subject: -protocol: transport mappings

Hi WG,

I had a recent off-list discussion regarding transport mappings. This
discussion targeted the quite important point what transport mappings
are good for - and wether or not -protocol should contain an UDP
transport mapping.

My position is that -protocol should NOT contain any transport mapping
and that there should be a short RFC outlining how -protocol is to be
mapped on UDP transport. Just as it is done in RFC3080 and 3081 for
BEEP. I would like to do this, because this will make crystal-clear that
- -protocol is transport ignorant. This is the comment I received (poster
requested to remain anonymous):

> I'm a bit doubtful about doing that
> as it would
> allow people to do syslog-protocol/tcp, or
> syslog-protocol/sctp, etc.  In
> one sense, I'd prefer to not open that opportunity as various
> factions may
> start doing things their own way which would not promote
> interoperability.
> Perhaps one company would choose to implement
> syslog-protocol/soap while
> another implements syslog-protocol/http.  If we do this, I'll probably
> insist that syslog-protocol/udp be a REQUIRED implementation
> and others
> are OPTIONAL.

I think this is an very important comment in regard to the overall
design. I think it is of advantage to facilitate the creation of other
transport mappings, as for example is currently being discussed for SNMP
inform messages. I agree that it makes it easy to "abuse" -protocol to
create non-standard transport mappings.

On the other hand, those doing this would most probably do it anyhow,
just not only with their own transport but with their own message
format, too. I think even if a vendor goes ahead and creates
syslog-protocol/tcp, this is advantagous over him creating just a plain
TCP implementation with a different message format. And as a reminder,
this is current state of the art, there ARE many syslog/raw tcp
implementations in the wild. So the lack of a standard way to do it
obviously did not stop the implementation. I think it is an advantage if
such non-standard implementations at least abide to the same message
format.

I would deeply appreciate all feedback from the WG on this important
topic.

Rainer

------------------------------

Date: Tue, 03 Feb 2004 15:51:34 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-protocol-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: The syslog Protocol
	Author(s)	: R. Gerhards
	Filename	: draft-ietf-syslog-protocol-02.txt
	Pages		: 41
	Date		: 2004-2-3

This document describes the syslog protocol. The syslog protocol has
been used throughout the years to convey event notifications. This
documents describes a layered architecture for a backwards-compatible
and easily extensible syslog protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-02.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-protocol-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-protocol-02.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------------------------------

Date: Wed, 4 Feb 2004 09:07:20 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog-protocol-01 posted & comments

Anton,

I am using your initial message as an additional guide during my edit to
- -protocol-02. I will provide some comments on what I did in reply to
your post, so that everyone finds the reasoning. I will eventually leave
some issues open...

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]

> 2. Section 2 refers to "machines" and "devices" which is
> misleading.  I
> think we need to talk about "applications". After all a sender and
> collector can both be on the same machine.

postponed edit for -03, taken note of it. I agree, but liked to push out
- -02 to finish on the format stuff
>
> 3. Section 4. HOSTNAME.  I think "." and "-" characters are allowed in
> FQDN (except no trailing "-") per RFC 1123. Also, the limit of 64
> characters is inappropriate. It should be 255 per same RFC.

changed to 255. I think I am not prohibiting any characters ... but I
might have overlooked the obvious. I'd appreciate if you could direct me
to where I do this ;) (in -02, please)

>
> 4. Section 4. The time-secfrac field should be specified as 1*4DIGIT.
> This is the only number of digits that would be allowed given the 32
> character limit you specified for TIMESTAMP field. This just makes it
> more explicit and actually removes the need to specify the
> length of the
> TIMESTAMP field.

Done. I kept the TIMESTAMP field length restrition in, too. I think it
doesn't hurt but gives the app developer an additional warning.

>
> 5. Section 4. MSG. I think the character set specified here is not
> consistent with specifying that UTF-8 is supported.  UTF-8
> character can
> consist of multiple bytes and each byte can be any 8-byte value. Also
> you refer to "PRINTABLE" in the comment, which is not defined
> anywhere.

done partly ... may needs refinement. Comments welcome.

>
> 6. Section 4.1. PRI field.  First, I support Albert's
> proposal of a new
> format which increases the number of facilities and provides a format
> that is easier to handle.  I just don't know why stop at 999
> facilities
> and not allow say 2bln (signed 32-bit).  An alternative (less optimal
> for performance) is defining a structured content parameter "facility"
> or "channel" and assuming new syslog collectors/relays will use it in
> configurations.

I re-specified it, together with the new header.

>
> 7. Section 4.1. PRI field.  I think naming facilities 16-23 "local" is
> misleading.  In fact, remote logging uses those almost
> exclusively. So,
> how are they local? I'd call them "custom facility 1,2,..."
> or something
> like that.

Facilities are currently not in with a specific semantic. This probably
needs some
more discussion, though. The -02 draft is meant to provoke a little in
this regard ;)

>
> 8. Section 4.1. Note 1.  I think here and in many other places in this
> draft RFC we should avoid using language such as "...have
> been seen...",
> etc.  This is not intended to be an informational RFC like
> 3164. I think
> it would be more appropriate to be talking about what SHOULD or MUST
> happen instead of what has been seen to happen.

done

>
> 9. Section 4.2. Here and thereafter you use the term "visible
> (printing)
> characters".  Although you clarify everywhere the specific character
> range, I think this term is imprecise.  A Chinese character encoded in
> UTF-8 will be visible if you have the right viewer and not visible if
> you don't.  Maybe you should refer to "non-control
> characters" instead.

partly changed in -02.

>
> 10.  Section 4.2 Last 3 sentences. Again you mention "has usually been
> seen".  Do we actually want to recommend the use of one IP or
> the other
> or at least the consistent use of one?

changed to hostname with FQDN

>
> 11. Section 4.2.1. In the note, you mention "single syntax".  In fact,
> use of second fractions is optional. Yes, technically it is one ABNF
> syntax. But then so is the RFC 3339 which you claim provides "multiple
> syntaxes".

changed to "restricted set of syntaxes"

>
> 12. Section 4.2.1. My feeling is we should not support the
> old timestamp
> format in this RFC.  If some collector wants to support it,
> they can be
> both RFC3164 and RFC.new compatible, right?  Why give more
> prominence to
> the old legacy timestamp which we know is bad?
>

removed old timestamp

> 13. Section 4.2.1. Bullet point talking about time-secfrac should
> mention that performance considerations is another condition for the
> recommendation, not just availability of clock accuracy.

added

>
> 14. Section 4.2.2.  Again, I am not convinced that supporting
> the legacy
> of just the hostname instead of FQDN is the good reason to
> have. We may
> still want just the hostname option for local logging though.

removed plain hostname
I think "just hostname" is so troublesome that we should no longer allow
it (now, that we are no longer in the backward compatibility business)

>
> 15. Section 4.2.2.  Do we want to make a recommendation as to what is
> preferred hostname-only or IP?

change to preferred FQDN

>
> 16. Section 4.2.2. Where we mention IPv6 RFC 2373, we should mention
> specifically the section on "Textual representation" of that RFC -
> section 2.

changed

>
> 17. Section 4.2.3.  We never say what the purpose of the TAG field is
> nor give any guidance to what should be put there. This field of the
> syslog specification is, to me, very strange.  I understand
> the legacy,
> but see my concerns about backward-compatibility.  The fact that no
> spaces are allowed is not optimal.  Recommendation of a
> trailing ":" can
> only mislead casual observers into believing it is used as a separator
> character while it is not.  Then, what's the purpose of this
> recommendation?

totally revamped, colon is a regular character now and it is SP
terminated as usual.

>
> 18. Section 4.2.3.  We never explain what's the difference between
> static and dynamic portions of TAG.  The last sentence talks about use
> of "consistent tag value", but I don't understand what it means.
> Consistent between what and what? This needs clarification.

I have to admit I am not sure myself. However, I would like to adress
this in -03, so that -02 can focus on the broader questions of the new
format. I have taken note of this.

>
> 19.  Section 4.3. The phrase "traditionally and most frequently used"
> should be replaces with SHOULD, MUST or RECOMMENDED I think.

removed

>
> 20. Section 4.3. The last two paragraphs are talking about some "code
> sets".  I think if we are talking about UTF-8, we are talking about
> *one* code set -- UNICODE -- and one encoding -- UTF-8.  I thought
> UNICODE and UTF-8 obsoleted all that code set business, or am I wrong?

I guess you are not wrong ;) - changed to UNICODE/UTF-8.

>
> 21. Section 4.4. TRAILER. This says that some receivers may require a
> trailer.  Aren't we supposed to specify here what compatible
> receiver is
> allowed to require and what not? Why are we allowing this?  I think
> nobody should require trailer and we should drop this from format.

created an issue out of this - let's see how further discussion goes

LINK-TO-ISSUE-HERE

>
> 22. Section 4.5. Sentence "..locally defined facility (local4)...".
> Again, I am confused by term "locally-defined".

section 4.5 was not updated - now it is.

>
> 23. Section 5 & beyond. Why is there a need to specified
> structured data
> *anywhere* within the message.  I thought we will designate a special
> field like TAG for the structured data.  This way we won't need a
> special sequence to identify it.  Also, I think allowing it everywhere
> gives too much unnecessary freedom. Harder to evolve protocol later.

I created an issue out of this: Not touched it in -02.

>
> 24. Section 5.1.  Like with the MSG, I think the character set of
> parameter value is any non-control character with some
> characters being
> escaped. We are supporting UTF-8 within the parameter values, right?

I think I have not forbidden that - have I? The ABNF - I think - allows
all
valid printable UTF-8 values. Please correct me if I am wrong.

I would like to address the other "section 5 bullet points" in -03 -
again, I try to focus -02 on a primarily section 4 update, which in
itself is considerable enough. I would like to stabilize this first,
then move on to the other topics.

>
> 25. Section 5.1. I think the fact that each structured data item which
> has a different IANA dictionary needs to be in a different block is
> somewhat cumbersome and limiting. For example, if I want to put the
> msgid parameter in all of my messages regardless of use of
> fragmentation, then when I do use fragmentation, do I have to put this
> parameter twice?
>
> 26. Section 5.1.  I think dictionary identifier can be made
> into a just
> another key-value parameter. This would be more consistent with
> providing a general mechanism key-value pairs and idea of using []
> brackets to group related tags.
>
> 27. Section 5.1. Can the SD-ID be optional for experimental
> parameters.
> This way I don't have to put "x-cisco" in front of all tags.  I don't
> see any value in this.  We can just assume experimental tags.  If a
> given vendor needs to identify his tags they can do this with
> their own
> parameters like "vendor", "product", "version", or whatever else the
> vendor wants.  Vendor tags are for vendor use only, right? General
> syslog collector won't use them anyway, correct?
>
> 28. Section 5.1. I would also consider the following approach which
> eliminates dictionaries.  If we only need parameter namespace
> so we can
> avoid conflicts between current & future syslog RFCs and vendor
> parameters, then we can just define some prefix for current and future
> syslog protocol parameters. For example "sys.msgno", "sys.fragcount",
> etc.  Then, we will control the tags in this namespace using IANA or
> RFCs.  If some vendor wants to re-use the "sys.msgno" tag because the
> definition of the tag suites them for a different use case, then they
> don't need to duplicate it.
>
> 29. Section 5.1. I think we should require a space character
> after each
> structured data block closing bracket.  This will make it
> more readable
> while eliminating the ambiguity as to whether or not the space is part
> of the message.  Even you examples will look nicer. I think
> we can make
> the space optional between two structured blocks of data.
>
> 30. Section 6. Paragraph 3 call for not using fragmentation
> when message
> can fit in a single message.  I think, in general, we assume
> the use of
> fragmentation *only* for splitting long messages.  We had some
> discussion on this a long time ago, but I don't remember the
> conclusion.
> The other use case for fragmentation (or better named multi-part
> messages in this case) is when the message is inherently multi-line.
> For example, a stack trace:
>
> LockConflictException
>  at com.cisco.csrc.db.LockTable.obtainUpdateLock(LockTable.java:199)
>  at
> com.cisco.csrc.db.indexes.OidIndex.obtainUpdateLock(OidIndex.java:448)
>  at
> com.cisco.csrc.db.PObjectImpl.obtainUpdateLock(PObjectImpl.java:1184)
>
> How can I send such message with current draft?  I would have
> to come up
> with some new parameters likely.  I think this needs to be
> standardized.
> The distinction here is that the original message is not a
> single line.
> Rather the original message is a multi-part message with each
> part being
> a separate line.
>
> To handle the above we need to differentiate the case when
> message does
> not need to be assembled.

I created a new issue out of that.

>
> 31. Section 6.  Again we had discussion on this before... It would be
> useful if message parts could be sent before the total length of the
> message is know.  We have one message in our system which is
> about 2000
> lines long. It dumps all kinds of properties on crash.  It
> would be nice
> if I could send parts of this message without knowing the
> total message
> part count.  Otherwise, I would need to assemble the whole message
> before sending it.  This can be problematic if I am crashing
> due to out
> of memory condition, for example.  To address this, we simply need to
> sate that recount parameter is optional in all fragments
> except for the
> last message.  This will designate the end of the fragmented message.

This sounds reasonable. I have created an issue out of that:

>
> 32. Section 6.2.  The above suggestions would mean that you can't sign
> the whole message, only parts.  You suggest that signing all parts is
> not as safe as signing the whole message.  Why?  We know exactly the
> message to which each part belongs and this information is  signed,
> right?

I was thinking about an offline log parser/verifier. At at high level
view, it could happen/be required that the parser app needs to
reassemble the parts before they can be processed. At this stage, the
part signatures get lost. So it would definitely be a plus to have the
full message sigend, too. Of course, this raises the same issue as
#31...

>
> 33. General. What do we do with non-conforming messages.  Do
> we want to
> recommend that collectors/relay agent fire some diagnostic
> message which
> embeds the offending message?

partly addressed. -02 says: log diagnostic, discard (by default) or do
operator-configured action (recommended: treat as 3164).

>
> 34. Do we want to introduce more standard parameters? Good candidates
> are "facility" and "severity".  Yes, this will duplicate information,
> but we can make them optional.  At least this will overcome
> the problem
> of syslog servers only storing the message and not the PRI field which
> leads to then not knowing what facility or severity the message had if
> you store multiple facilities/severities in the same log file.

I am not sure if we are really after this... It requires additional
space in the (signed!) message. I am about to specify that the syslogd
MUST have a way to store raw messages, without any part removed or
changed. This is vital for signed messages - otherwise you are unable to
verify them. So I think this should be a requirement for the application
(or at least a very important implementor's note, if the IETF does not
allow for the other).

Rainer

------------------------------

Date: Wed, 4 Feb 2004 06:30:09 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: Re: -protocol: transport mappings

Hi Folks,

We need to get this resolved.  If you have an opinion on this, please
speak up.  If I don't hear anything about this then I will assume that
"0 responses" = "0 interest" and we'll ask Rainer to keep the mapping
as part of syslog-protocol.

Thanks,
Chris

On Tue, 3 Feb 2004, Rainer Gerhards wrote:

> Hi WG,
>
> I had a recent off-list discussion regarding transport mappings. This
> discussion targeted the quite important point what transport mappings
> are good for - and wether or not -protocol should contain an UDP
> transport mapping.
>
> My position is that -protocol should NOT contain any transport mapping
> and that there should be a short RFC outlining how -protocol is to be
> mapped on UDP transport. Just as it is done in RFC3080 and 3081 for
> BEEP. I would like to do this, because this will make crystal-clear that
> -protocol is transport ignorant. This is the comment I received (poster
> requested to remain anonymous):
>
> > I'm a bit doubtful about doing that
> > as it would
> > allow people to do syslog-protocol/tcp, or
> > syslog-protocol/sctp, etc.  In
> > one sense, I'd prefer to not open that opportunity as various
> > factions may
> > start doing things their own way which would not promote
> > interoperability.
> > Perhaps one company would choose to implement
> > syslog-protocol/soap while
> > another implements syslog-protocol/http.  If we do this, I'll probably
> > insist that syslog-protocol/udp be a REQUIRED implementation
> > and others
> > are OPTIONAL.
>
> I think this is an very important comment in regard to the overall
> design. I think it is of advantage to facilitate the creation of other
> transport mappings, as for example is currently being discussed for SNMP
> inform messages. I agree that it makes it easy to "abuse" -protocol to
> create non-standard transport mappings.
>
> On the other hand, those doing this would most probably do it anyhow,
> just not only with their own transport but with their own message
> format, too. I think even if a vendor goes ahead and creates
> syslog-protocol/tcp, this is advantagous over him creating just a plain
> TCP implementation with a different message format. And as a reminder,
> this is current state of the art, there ARE many syslog/raw tcp
> implementations in the wild. So the lack of a standard way to do it
> obviously did not stop the implementation. I think it is an advantage if
> such non-standard implementations at least abide to the same message
> format.
>
> I would deeply appreciate all feedback from the WG on this important
> topic.
>
> Rainer
>
>
>

------------------------------

Date: Wed, 4 Feb 2004 15:35:57 +0100
From: Rainer Gerhards <[email-masked]>
Subject: -protocol open issues

Hi WG,

I have updated my page of open issues in -protocol. I would appreciate
if you could comment on the open issues. They can be found here:

http://www.syslog.cc/ietf/protocol.html

Please note that these are just the issues which have definitely been
identified. Others are lurking around, so I will add them when they are
discovered ("other things to do" beneath the issues may provide an
idea). I try to solve those issues before creating new ones, just so
that it is easier to keep track and stay focussed.

Any feedback is highly appreciated.

Rainer

------------------------------

Date: Wed, 4 Feb 2004 12:15:40 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol: transport mappings

Hi,

I believe it is important to define at least one transport mapping, and
to identify this transport mapping as the "required minimum" mapping for
compliance to the standard, to ensure that all systems can be expected
to support the use of this mapping. This should probably be the simplest
transport to implement.

Then we can define additional optional transport mappings, designed to
meet specific needs. For example, particular types of systems, as a
result of their device type (high end routers, or IDS systems, for
instance), might generate a large number of messages compared to most
systems; if you exceed X number of messages per minute, you might want
to support a streaming protocol where the throughout is known to be
better for large amounts of messaging. For systems that are likely to be
used over the big-I Internet, where congestion control is critical, it
might be important to support SCTP (this extra mapping might also help
get it approved by the IESG).

But every implementation should support one basic transport mapping.

In MIBs, we often define multiple levels of conformance/compliance
because different implementations are designed for different purposes. I
recommend doing the same for syslog transport support, if the WG is
willing to define the various transport mappings. If the WG wants to
only define one mappong and leave alternate transports to others to do,
then only one required compliance level can be defined.

dbh

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Wednesday, February 04, 2004 9:30 AM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: -protocol: transport mappings
>
> Hi Folks,
>
> We need to get this resolved.  If you have an opinion on this, please
> speak up.  If I don't hear anything about this then I will assume that
> "0 responses" = "0 interest" and we'll ask Rainer to keep the mapping
> as part of syslog-protocol.
>
> Thanks,
> Chris
>
> On Tue, 3 Feb 2004, Rainer Gerhards wrote:
>
> > Hi WG,
> >
> > I had a recent off-list discussion regarding transport
> mappings. This
> > discussion targeted the quite important point what
> transport mappings
> > are good for - and wether or not -protocol should contain an UDP
> > transport mapping.
> >
> > My position is that -protocol should NOT contain any
> transport mapping
> > and that there should be a short RFC outlining how
> -protocol is to be
> > mapped on UDP transport. Just as it is done in RFC3080 and 3081 for
> > BEEP. I would like to do this, because this will make
> crystal-clear that
> > -protocol is transport ignorant. This is the comment I
> received (poster
> > requested to remain anonymous):
> >
> > > I'm a bit doubtful about doing that
> > > as it would
> > > allow people to do syslog-protocol/tcp, or
> > > syslog-protocol/sctp, etc.  In
> > > one sense, I'd prefer to not open that opportunity as various
> > > factions may
> > > start doing things their own way which would not promote
> > > interoperability.
> > > Perhaps one company would choose to implement
> > > syslog-protocol/soap while
> > > another implements syslog-protocol/http.  If we do this,
> I'll probably
> > > insist that syslog-protocol/udp be a REQUIRED implementation
> > > and others
> > > are OPTIONAL.
> >
> > I think this is an very important comment in regard to the overall
> > design. I think it is of advantage to facilitate the
> creation of other
> > transport mappings, as for example is currently being
> discussed for SNMP
> > inform messages. I agree that it makes it easy to "abuse"
> -protocol to
> > create non-standard transport mappings.
> >
> > On the other hand, those doing this would most probably do
> it anyhow,
> > just not only with their own transport but with their own message
> > format, too. I think even if a vendor goes ahead and creates
> > syslog-protocol/tcp, this is advantagous over him creating
> just a plain
> > TCP implementation with a different message format. And as
> a reminder,
> > this is current state of the art, there ARE many syslog/raw tcp
> > implementations in the wild. So the lack of a standard way to do it
> > obviously did not stop the implementation. I think it is an
> advantage if
> > such non-standard implementations at least abide to the same message
> > format.
> >
> > I would deeply appreciate all feedback from the WG on this important
> > topic.
> >
> > Rainer
> >
> >
> >
>
>

------------------------------

Date: Wed, 4 Feb 2004 13:20:08 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -protocol open issues

On issue #7 - enterprise ID:

I am relatively neutral to this idea. But I am trying to understand how
it will be used. What are the anticipated use cases for it?

If we want to use it to differentiate messages from a specific vendor
because it may provide some additional formatting, then one could also
argue that we also need vendor version and potentially vendor product
and on and on.

If we do provide enterprise ID, does it have to be required and in the
header as opposed to structured content?  Is filtering on vendor going
to be a common use-case?

One area of ambiguity, I think, is a situation where components are
integrated into other applications.  Say component X from one company is
integrated into product Y of another company.  Component X already does
- -protocol compliant syslog logging. Which enterprise ID should it use?
Should we leave this as nondeterministic or provide recommendations?

Another area of potential ambiguity is relaying. Suppose a relay gets a
bad message from a Cisco device and needs to fire a diagnostic error
message.  Does it use its own enterprise ID for this?  If so, my
collector which catches messages only for vendor Cisco won’t catch this,
right?

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Wednesday, February 04, 2004 9:36 AM
> To: [email-masked]
> Subject: -protocol open issues
>
>
> Hi WG,
>
> I have updated my page of open issues in -protocol. I would
> appreciate if you could comment on the open issues. They can
> be found here:
>
http://www.syslog.cc/ietf/protocol.html

Please note that these are just the issues which have definitely been
identified. Others are lurking around, so I will add them when they are
discovered ("other things to do" beneath the issues may provide an
idea). I try to solve those issues before creating new ones, just so
that it is easier to keep track and stay focussed.

Any feedback is highly appreciated.

Rainer

------------------------------

Date: Wed, 4 Feb 2004 12:34:11 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol: transport mappings

Hi

Comments inline.

> My position is that -protocol should NOT contain any transport mapping
> and that there should be a short RFC outlining how -protocol is to be
> mapped on UDP transport.

I think it is important to have at least one transport mapping to ensure
interoperability.

>
> > I'm a bit doubtful about doing that
> > as it would
> > allow people to do syslog-protocol/tcp, or
> > syslog-protocol/sctp, etc.

SNMP has had one required transport mapping, and permitted additional
mappings. In fifteen years of use, no attempt to add transport protocols
has gathered enough industry interest to really succeed, and SNMP is a
protocol with many known problems directly caused by the UDP transport
limitations. I suspect your fears will not be realized.

> If we do this,
> I'll probably
> > insist that syslog-protocol/udp be a REQUIRED implementation
> > and others
> > are OPTIONAL.

I think having one required is the right way to go, and I think it would
be useful to have the WG define at least one alternate protocol mapping,
which addresses the major shortcomings of the required transport, to
help ensure that we don't end up with a bunch of proprietary
implementations for the same alternate transport.

>
> I think this is an very important comment in regard to the overall
> design. I think it is of advantage to facilitate the creation of other
> transport mappings, as for example is currently being
> discussed for SNMP
> inform messages.

Where is this discussion taking place? In the syslog WG or in the SNMP
community? As an active member of the SNMP community, I don't think I'm
aware of this discussion. I am aware of discussions about adding TCP
transport for all types of SNMP messages, not just informs, but that
effort is dying the slow death of apathy.

> I agree that it makes it easy to "abuse" -protocol to
> create non-standard transport mappings.

See my comment about the slow death of apathy. I think people may be way
too worried about a proliferation of transport mappings. New transport
mappings will only be supported if there is a solid economic benefit
involved. Again, the SNMP community has permitted alternate transport
mappings for years, but few if any vendors have actually supported them
in their equipment.

> this is current state of the art, there ARE many syslog/raw tcp
> implementations in the wild.

I recommend that we work to standardize these additional mappings if
they already exist in the wild and have proven truly useful. I recommend
checking to see how many operators actually enable and USE those
syslog/raw tcp implementations.

dbh

------------------------------

Date: Wed, 4 Feb 2004 11:38:40 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: RE: -protocol: transport mappings

Hi David,

On Wed, 4 Feb 2004, Harrington, David wrote:

> Hi
>
> Comments inline.
>
> > My position is that -protocol should NOT contain any transport mapping
> > and that there should be a short RFC outlining how -protocol is to be
> > mapped on UDP transport.
>
> I think it is important to have at least one transport mapping to ensure
> interoperability.
>
> >
> > > I'm a bit doubtful about doing that
> > > as it would
> > > allow people to do syslog-protocol/tcp, or
> > > syslog-protocol/sctp, etc.
>
> SNMP has had one required transport mapping, and permitted additional
> mappings. In fifteen years of use, no attempt to add transport protocols
> has gathered enough industry interest to really succeed, and SNMP is a
> protocol with many known problems directly caused by the UDP transport
> limitations. I suspect your fears will not be realized.
>
> > If we do this,
> > I'll probably
> > > insist that syslog-protocol/udp be a REQUIRED implementation
> > > and others
> > > are OPTIONAL.
>
> I think having one required is the right way to go,

Would you recommend that to be in the syslog-protocol document, or a
separate document?

> and I think it would
> be useful to have the WG define at least one alternate protocol mapping,
> which addresses the major shortcomings of the required transport, to
> help ensure that we don't end up with a bunch of proprietary
> implementations for the same alternate transport.

I believe that's RFC 3195.  :-)  Any major changes coming from
syslog-protocol (such as the improved TIMESTAMP) will go into an update of
that RFC when we're ready.

Thanks,
Chris

>
> >
> > I think this is an very important comment in regard to the overall
> > design. I think it is of advantage to facilitate the creation of other
> > transport mappings, as for example is currently being
> > discussed for SNMP
> > inform messages.
>
> Where is this discussion taking place? In the syslog WG or in the SNMP
> community? As an active member of the SNMP community, I don't think I'm
> aware of this discussion. I am aware of discussions about adding TCP
> transport for all types of SNMP messages, not just informs, but that
> effort is dying the slow death of apathy.
>
> > I agree that it makes it easy to "abuse" -protocol to
> > create non-standard transport mappings.
>
> See my comment about the slow death of apathy. I think people may be way
> too worried about a proliferation of transport mappings. New transport
> mappings will only be supported if there is a solid economic benefit
> involved. Again, the SNMP community has permitted alternate transport
> mappings for years, but few if any vendors have actually supported them
> in their equipment.
>
> > this is current state of the art, there ARE many syslog/raw tcp
> > implementations in the wild.
>
> I recommend that we work to standardize these additional mappings if
> they already exist in the wild and have proven truly useful. I recommend
> checking to see how many operators actually enable and USE those
> syslog/raw tcp implementations.
>
> dbh
>
>
>

------------------------------

Date: Wed, 4 Feb 2004 13:37:44 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: 59th IETF Agenda - As of 2/4/2004

Hi Folks,

It appears that we've got a 2 hour slot on Wednesday.  Does this cause
heartburn with anyone?

Thanks,
Chris

- ---------- Forwarded message ----------
Date: Wed, 04 Feb 2004 16:26:02 -0500
From: Marcia Beaulieu <[email-masked]>
To: [email-masked], [email-masked]
Subject: 59th IETF Agenda - As of 2/4/2004

DRAFT Agenda of the Fifty-ninth IETF
February 29 - March 5, 2004

SUNDAY, February 29, 2004
1000-1700 IEPG Meeting -
1200-1900 Registration
1300-1400 Newcomer's Training (English)
1300-1400 Newcomer's Training (Korean)
1300-1500 Editor's Training
1300-1500 Intro WG Chairs Training
1500-1700 Security Tutorial
1700-1900 Welcome Reception

MONDAY, March 1, 2004
0800-2000 IETF Registration
0800-0900 Continental Breakfast
0900-1130 Morning Sessions
APP   apparea   Applications Open Area Meeting
OPS   mboned    MBONE Deployment WG *
TSV   nsis      Next Steps in Signaling WG *

1130-1300 Break
1300-1500 Afternoon Sessions I
INT   mip6      Mobility for IPv6 WG
OPS   dnsop     Domain Name System Operations WG *
RTG   mpls      Multiprotocol Label Switching WG
SEC   pki4ipsec Profiling Use of PKI in IPSEC WG

1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
APP   iea       Internationalizing Email Address BOF
INT   pana      Protocol for Carrying Authentication for Network Access WG
OPS   v6ops     IPv6 Operations WG *
RTG   idr       Inter-Domain Routing WG
TSV   xcon      Centralized Conferencing WG

1730-1930 Break
1930-2200 Evening Sessions
APP   simple    SIP for Instant Messaging and Presence Leveraging Extensions WG
INT   mip4      Mobility for IPv4 WG
OPS   rmonmib   Remote Network Monitoring WG
RTG   rtgarea   Routing Area Meeting *

TUESDAY, March 2, 2004
0800-1800 IETF Registration
0800-0900 Continental Breakfast
0900-1130 Morning Sessions
APP   crisp    Cross Registry Information Service Protocol WG
INT   dhc      Dynamic Host Configuration WG *
INT   mipshop  MIPv6 Signaling and Handoff Optimization WG
OPS   psamp    Packet Sampling WG
RTG   forces   Forwarding and Control Element Separation WG
TSV   avt      Audio/Video Transport WG *

1130-1300 Break
1300-1400 Afternoon Sessions I
APP   webdav   WWW Distributed Authoring and Versioning WG
INT   l3vpn    Layer 3 Virtual Private Networks WG
OPS   dnsop    Domain Name System Operations WG *
SEC   sasl     Simple Authentication and Security Layer WG
TSV   nsis     Next Steps in Signaling WG *

1415-1515 Afternoon Sessions II
APP   calsch   Calendaring and Scheduling WG
INT   magma    Multicast and Anycast Group Membership WG *
OPS   aaa      Authentication, Authorization and Accounting WG
TSV   midcom   Middlebox Communication WG

1515-1545 Break (Refreshments provided)
1545-1645 Afternoon Sessions III
APP   ldapbis  LDAP (v3) Revision WG
INT   ipv6     IP Version 6 WG *
OPS   hubmib   Ethernet Interfaces and Hub MIB WG
SEC   smime    S/MIME Mail Security WG
TSV   iptel    IP Telephony WG

1700-1800 Afternoon Sessions IV
APP   iea      Internationalizing Email Address BOF
GEN   newtrk   New IETF Standards Track BOF
INT   ipv6     IP Version 6 WG *
OPS   hubmib   Ethernet Interfaces and Hub MIB WG
TSV   rmt      Reliable Multicast Transport WG
TSV   speechsc Speech Services Control WG *

WEDNESDAY, March 3, 2004
0800-1700 IETF Registration
0800-0900 Continental Breakfast
0900-1130 Morning Sessions
APP   lemonade  Enhancements to Internet email to Support Diverse Service Environments
WG *
GEN   icar      Improved Cross Area Review BOF
OPS   multi6    Site Multihoming in IPv6 WG
RTG   ccamp     Common Control and Measurement Plane WG
SEC   inch      Extended Incident Handling WG
TSV   enum      Telephone Number Mapping WG

1130-1300 Break
1300-1500 Afternoon Sessions I
OPS   netconf   Network Configuration WG
SEC   pkix      Public-Key Infrastructure (X.509) WG
TSV   rserpool  Reliable Server Pooling WG

1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
IRTF  mobopts   IP Mobility Optimizations
OPS   capwap    Control and Provisioning of Wireless Access Points WG
SEC   syslog    Security Issues in Network Event Logging WG
TSV   avt       Audio/Video Transport WG *

1730-1930 Break
1930-2200 Plenary

2230	Late Night Session
PGP Key Signing

THURSDAY, March 4, 2004
0800-1700 IETF Registration
0800-0900 Continental Breakfast
0900-1130 Morning Sessions
OPS   netconf   Network Configuration WG
SEC   marid     MTA Authorization Records in DNS BOF *
TSV   mmusic    Multiparty Multimedia Session Control WG *

1130-1300 Break
1300-1500 Afternoon Sessions I
INT   l2vpn     Layer 2 Virtual Private Network WG
OPS   grow      Global Routing Operations WG *
SEC   ltans     Long-Term Archive and Notary Services WG
TSV   dccp      Datagram Congestion Control Protocol WG
TSV   nfsv4     Network File System Version 4 WG

1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
OPS   v6ops     IPv6 Operations WG *
SEC   saag      Open Security Area Directorate
TSV   pwe3      Pseudo Wire Emulation Edge to Edge WG

1730-1930 Break
1930-2200 Plenary

Friday, March 5, 2004
0800-0900 Continental Breakfast
0900-1130 Morning Sessions

------------------------------

Date: Thu, 5 Feb 2004 13:27:37 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: -protocol: transport mappings

I agree that having a separate RFC for mapping syslog into various
transports would be good. Then we could address Syslog over UDP, TCP,
BEEP, SNMP, yada yada.

Maybe also make a mention in protocol that it is transport independent
and refer them to the transport RFC name.

Cheers

Andrew

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chris Lonvick
Sent: Thursday, 5 February 2004 3:30 a.m.
To: Rainer Gerhards
Cc: [email-masked]
Subject: Re: -protocol: transport mappings

Hi Folks,

We need to get this resolved.  If you have an opinion on this, please
speak up.  If I don't hear anything about this then I will assume that
"0 responses" = "0 interest" and we'll ask Rainer to keep the mapping
as part of syslog-protocol.

Thanks,
Chris

On Tue, 3 Feb 2004, Rainer Gerhards wrote:

> Hi WG,
>
> I had a recent off-list discussion regarding transport mappings. This
> discussion targeted the quite important point what transport mappings
> are good for - and wether or not -protocol should contain an UDP
> transport mapping.
>
> My position is that -protocol should NOT contain any transport mapping
> and that there should be a short RFC outlining how -protocol is to be
> mapped on UDP transport. Just as it is done in RFC3080 and 3081 for
> BEEP. I would like to do this, because this will make crystal-clear
that
> -protocol is transport ignorant. This is the comment I received
(poster
> requested to remain anonymous):
>
> > I'm a bit doubtful about doing that
> > as it would
> > allow people to do syslog-protocol/tcp, or
> > syslog-protocol/sctp, etc.  In
> > one sense, I'd prefer to not open that opportunity as various
> > factions may
> > start doing things their own way which would not promote
> > interoperability.
> > Perhaps one company would choose to implement
> > syslog-protocol/soap while
> > another implements syslog-protocol/http.  If we do this, I'll
probably
> > insist that syslog-protocol/udp be a REQUIRED implementation
> > and others
> > are OPTIONAL.
>
> I think this is an very important comment in regard to the overall
> design. I think it is of advantage to facilitate the creation of other
> transport mappings, as for example is currently being discussed for
SNMP
> inform messages. I agree that it makes it easy to "abuse" -protocol to
> create non-standard transport mappings.
>
> On the other hand, those doing this would most probably do it anyhow,
> just not only with their own transport but with their own message
> format, too. I think even if a vendor goes ahead and creates
> syslog-protocol/tcp, this is advantagous over him creating just a
plain
> TCP implementation with a different message format. And as a reminder,
> this is current state of the art, there ARE many syslog/raw tcp
> implementations in the wild. So the lack of a standard way to do it
> obviously did not stop the implementation. I think it is an advantage
if
> such non-standard implementations at least abide to the same message
> format.
>
> I would deeply appreciate all feedback from the WG on this important
> topic.
>
> Rainer
>
>
>

------------------------------

Date: Thu, 5 Feb 2004 10:24:50 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -protocol: transport mappings

I agree with general consensus that there must be at least one mapping.
I guess UDP is easiest.  But I would prefer that compliance with this
transport is not required as far as -protocol.  We all know UDP may not
be an ideal transport, so a TCP-based syslog (provided it adheres to a
standard) should not be required to provide a UDP binding.

I think the cleanest approach is to put the transport into a separate
RFC and publish the UDP mapping concurrently with -protocol.  However,
considering that the whole transport description for UDP is just "use
port 514", I am not sure if the WG wants to go with the overhead of
extra RFC instead of just adding a section to -protocol.  Personally, I
don't mind a one page RFC.  And I think most security issues needs to be
moved to transport layer.

I think a separate transport RFC will promote multiple transports, which
I personally thing is a good thing.

If we make UDP part of -protocol, we should make it only conditionally
required.  Kinda like multiple levels of compliance in MIB that was
suggested.  I think it has to be stated that for UDP transport the
following conventions MUST be used.  But providing the UDP transport
itself is not a MUST.

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Andrew Ross
> Sent: Wednesday, February 04, 2004 7:28 PM
> To: 'Chris Lonvick'; 'Rainer Gerhards'
> Cc: [email-masked]
> Subject: RE: -protocol: transport mappings
>
>
>
> I agree that having a separate RFC for mapping syslog into
> various transports would be good. Then we could address
> Syslog over UDP, TCP, BEEP, SNMP, yada yada.
>
> Maybe also make a mention in protocol that it is transport
> independent and refer them to the transport RFC name.
>
> Cheers
>
> Andrew
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Chris Lonvick
> Sent: Thursday, 5 February 2004 3:30 a.m.
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: -protocol: transport mappings
>
>
> Hi Folks,
>
> We need to get this resolved.  If you have an opinion on
> this, please speak up.  If I don't hear anything about this
> then I will assume that "0 responses" = "0 interest" and
> we'll ask Rainer to keep the mapping as part of syslog-protocol.
>
> Thanks,
> Chris
>
> On Tue, 3 Feb 2004, Rainer Gerhards wrote:
>
> > Hi WG,
> >
> > I had a recent off-list discussion regarding transport
> mappings. This
> > discussion targeted the quite important point what
> transport mappings
> > are good for - and wether or not -protocol should contain an UDP
> > transport mapping.
> >
> > My position is that -protocol should NOT contain any
> transport mapping
> > and that there should be a short RFC outlining how
> -protocol is to be
> > mapped on UDP transport. Just as it is done in RFC3080 and 3081 for
> > BEEP. I would like to do this, because this will make crystal-clear
> that
> > -protocol is transport ignorant. This is the comment I received
> (poster
> > requested to remain anonymous):
> >
> > > I'm a bit doubtful about doing that
> > > as it would
> > > allow people to do syslog-protocol/tcp, or syslog-protocol/sctp,
> > > etc.  In one sense, I'd prefer to not open that opportunity as
> > > various factions may
> > > start doing things their own way which would not promote
> > > interoperability.
> > > Perhaps one company would choose to implement
> > > syslog-protocol/soap while
> > > another implements syslog-protocol/http.  If we do this, I'll
> probably
> > > insist that syslog-protocol/udp be a REQUIRED implementation and
> > > others are OPTIONAL.
> >
> > I think this is an very important comment in regard to the overall
> > design. I think it is of advantage to facilitate the
> creation of other
> > transport mappings, as for example is currently being discussed for
> SNMP
> > inform messages. I agree that it makes it easy to "abuse"
> -protocol to
> > create non-standard transport mappings.
> >
> > On the other hand, those doing this would most probably do
> it anyhow,
> > just not only with their own transport but with their own message
> > format, too. I think even if a vendor goes ahead and creates
> > syslog-protocol/tcp, this is advantagous over him creating just a
> plain
> > TCP implementation with a different message format. And as
> a reminder,
> > this is current state of the art, there ARE many syslog/raw tcp
> > implementations in the wild. So the lack of a standard way to do it
> > obviously did not stop the implementation. I think it is an
> advantage
> if
> > such non-standard implementations at least abide to the
> same message
> > format.
> >
> > I would deeply appreciate all feedback from the WG on this
> important
> > topic.
> >
> > Rainer
> >
> >
> >
>
>
>
>

------------------------------

Date: Thu, 5 Feb 2004 17:36:34 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol: transport mappings

David,

> > I think this is an very important comment in regard to the overall
> > design. I think it is of advantage to facilitate the
> creation of other
> > transport mappings, as for example is currently being
> > discussed for SNMP
> > inform messages.
>
> Where is this discussion taking place? In the syslog WG or in the SNMP
> community? As an active member of the SNMP community, I don't
> think I'm
> aware of this discussion. I am aware of discussions about adding TCP
> transport for all types of SNMP messages, not just informs, but that
> effort is dying the slow death of apathy.

Sorry, the grammer was not with the non-native speakers among us ;-).

What I intended to say was the there is discussion a discussin in the
syslog-sec WG on a transport mapping for *syslog* onto snmp inform
(actaully trap was written in the orginal thread). Bluntly said "syslog
over SNMP". I am refering to this here:

http://www.syslog.cc/ietf/autoarc/msg01027.html

I am not 100% sure if I expressed it right this time, if I haven't maybe
somebody can jump in and find the right words ;)

Thanks,
Rainer

------------------------------

Date: Thu, 5 Feb 2004 17:18:20 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol: transport mappings

> From: Anton Okmianski [mailto:[email-masked]]
>
> I agree with general consensus that there must be at least
> one mapping.
> I guess UDP is easiest.  But I would prefer that compliance with this
> transport is not required as far as -protocol.  We all know
> UDP may not
> be an ideal transport, so a TCP-based syslog (provided it adheres to a
> standard) should not be required to provide a UDP binding.

I think David has a valid point here (besides that he has obviously
brought "a little" of his SNMP experience in...). I think the value of
REQUIRING that there must be a simple mapping (I think UDP is this for
syslog) is that we can ensure that at least all implementations can
interoperate with each other. If we do not have a REQUIRED transport, we
may end up with two syslog implementations that can not talk to each
other, because one talks UDP while the other talks TCP. Neither of them
talks any other protocol.

I see much value in avoiding this situation. I think it is even worth
requiring a transport that one may think to be too simplistic. We can
leave it to the administrator to disable this transport, so this should
not be an issue. But a least common denominator should be available if
there is no other way to get it going (after all, getting things going
somehow is better than loosing the game at all...).

The only issue I see is with devices - or better said "pure senders" -
whom's vendor will not put in the extra effort to implement two
transports. I doubt, however, that a vendor who puts in a more
sophisticated transport like RFC3195 has an issue with providing an UDP
transport, too.

Anyhow, to avoid issues in this regard, we may want to relax the
REQUIRED transport mapping for "sole senders" (that is non-receivers,
not e.g. a relay). I am myself not sure yet if that is a good idea, but
after all, this is a discussion list ;)

>
> I think the cleanest approach is to put the transport into a separate
> RFC and publish the UDP mapping concurrently with -protocol.  However,
> considering that the whole transport description for UDP is just "use
> port 514", I am not sure if the WG wants to go with the overhead of
> extra RFC instead of just adding a section to -protocol.
> Personally, I
> don't mind a one page RFC.  And I think most security issues
> needs to be
> moved to transport layer.

I am in strong favour of a separate RFC, even though it is a pretty
short one (I doubt it will be short in respect to security
considerations ;)). But it will keep things cleanly separated. However,
I see that once we really require a transport (UDP), that it may only
complicate things. So I am not feeling as strong about a seperate RFC as
I did some days ago. I am still in favour of it, but things like "this
complicates the RFC process" may outweigh this concern.

I have CC'd mtr - I don't know if he has time and is willing to comment
on this issue, but I would deeply appreciate it because he obviously has
experience with this by doing RFC3080 and 3081 in the same manner.

> I think a separate transport RFC will promote multiple
> transports, which
> I personally thing is a good thing.

me too. I think it pays to open this possibility...

>
> If we make UDP part of -protocol, we should make it only conditionally
> required.  Kinda like multiple levels of compliance in MIB that was
> suggested.  I think it has to be stated that for UDP transport the
> following conventions MUST be used.  But providing the UDP transport
> itself is not a MUST.

I think this is a re-iteration of the first argument. At least my
comment from there applies here, too. ;)

Rainer

------------------------------

Date: Thu, 5 Feb 2004 17:49:22 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol open issues

Anton,

you have some very good points in your posting. When David suggested it,
I had the impression that it is useful and may even help with the
syslog-mib effort. I am still a bit positive in respect to the
enterprise ID.

As you probably have seen, I have just put very limited text into
- -protocol-02 re the enterprise ID. I would really appreciate some votes
on the mailing list on wheter or not we should continue with this.

> I am relatively neutral to this idea. But I am trying to
> understand how
> it will be used. What are the anticipated use cases for it?

What appealed me was that there is at least a minimum way to identify
the orginator. In our log parsers, knowing this would often come very
handy.

> If we want to use it to differentiate messages from a specific vendor
> because it may provide some additional formatting, then one could also
> argue that we also need vendor version and potentially vendor product
> and on and on.

Yes, this is right. But I would expect that the vendor should provide a
kind of its own indication of this - maybe with an optional structured
data element.
>
> If we do provide enterprise ID, does it have to be required and in the
> header as opposed to structured content?  Is filtering on vendor going
> to be a common use-case?

Good point. Maybe structured content does the trick. The enterprise ID
has the advantage that you know it is there, it is compact (message
size) and it is within already defined bounds, which probably eases
interoprability to other systems (SNMP, eventually NETCONF - I like to
reuse prooven technology if there is no really good argument against
it).

> One area of ambiguity, I think, is a situation where components are
> integrated into other applications.  Say component X from one
> company is
> integrated into product Y of another company.  Component X
> already does
> -protocol compliant syslog logging. Which enterprise ID should it use?
> Should we leave this as nondeterministic or provide recommendations?

Another good point. But I think this is mostly a commercial issue. OEM
agreements may force you to use a different vendor ID. I think this is
hard to address in an RFC. I would live with that and believe that there
will some sites appear that say "vendor ids x, y and z" are actually the
same" (as with devices using ZyNos).

> Another area of potential ambiguity is relaying. Suppose a
> relay gets a
> bad message from a Cisco device and needs to fire a diagnostic error
> message.  Does it use its own enterprise ID for this?  If so, my
> collector which catches messages only for vendor Cisco won't
> catch this,
> right?

This must go into (obviously to be written) relay rules. My first idea
is that if it is a malformed question, we should flag it as "don't know"
vendor. I am not sure if 0 would be appropriate, if there is already
such a vendor ID defined and if not if it would be within the scope of
vendor IDs to request IANA with the assignment of a "syslog I don't know
the vendor or don't care" ID.

Maybe David has a comment on this ;)

Rainer

------------------------------

Date: Thu, 5 Feb 2004 18:40:15 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

I would like to continue this discussion. I have listed it as issue #9.
For past dicussion milestones, please visit

http://www.syslog.cc/ietf/protocol/issue9.html

This issue is of vital importance for the message format and thus
- -protocol. I would like to settle it as quickly as possible, as some
other discussions can only be carried forward when this issue here is
solved.

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Thursday, January 29, 2004 11:25 PM

> Can we just allow any ASCII control characters and any UTF-8 encoded
> characters and leave it up to a different standard to define
> the storage
> format?

Though this sounds fair, I have the feeling that it does not work really
well for syslog. The reason is that syslog traditionally was printable
text (no control character) only (at least for the most part). This is
also in RFC 3195. Even more important is that syslog-sign depends on
printable characters, or better said on an equal on-the-wire and
on-storage representation. Otherwise, signatures will no longer be
useful. Of course, we could redefine -sign (it is not finished yet), but
I have the strong feeling that we are actually fiddling with a
fundamental syslog philosophy issue. We already went a long way from
syslog as it is currently defined and in use. I think we must be careful
that we do not define something that is totally different to current
syslog (and yields us a lot of acceptance issues...).

In short: I have a strong peferrence that we should insist on
non-nontrol-chars only. Escaping MUST be done by the (original) sender.

What does the rest of the group think?

> I think storage format must be standardized soon, but it is
> out of scope
> for -protocol, right? People will be looking to -protocol and try to
> infer the log file format so they can process messages.  We
> should make
> it clear in -protocol that syslog servers are free to store
> messages in
> whatever format they choose

I am about to mandate that they MUST implement a way to store raw
message data - for signed messages. Again, if we don't mandate this, we
have a fundamental issue with syslog-sign. And, yes, I found out about
the big scope of this issue when I began to think about implementing a
signature verifier for -sign ;)

In the light of this, what does the WG think?

Rainer

------------------------------

Date: Thu, 5 Feb 2004 14:20:31 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -protocol: transport mappings

Rainer and all:

I think there are two issues here:

1. Should UDP transport be required?

2. Should UDP transport be included in -protocol?

I think they are interdependent.  If the consensus of the WG that it
must be required, then I agree it is easiest to put it into -protocol.

But, I have a sense that requiring UDP would not be a good thing  I see
a few issues with requiring it:

1. It has a danger of making UDP a defacto-implementation and we know
UDP is not always ideal.  It can discourage other transport
implementations.  I think somebody mentioned the fate of SNMP in this
regard.

2.  I think requiring UDP implementation reduces the areas in which
syslog message format RFC could be utilized.  I can see many different
areas.  For example, if RFC came without UDP baggage, we, within Cisco,
could potentially standardize on this format for products which write
directly to log file (no syslog servers) should be compatible with the
format.  This would be a great thing for us to be able to have a
consistent format regardless of whether or not syslog transport is used
because it is inevitable that some products will use syslog and other
will write straight to file.

Another use case I have is writing log messages into Windows Event Log.
I would really like if that format be the same as on other platforms
which use syslog.  It would have been easier for us to establish this
requirement for products within Cisco if we could just refer to syslog
message format RFC and it did not come with a baggage of having to
implement a syslog UDP transport, which may not be applicable.

So, I am open on whether or not UDP binding is included in -protocol or
outside.  But I would really prefer if it was not required.

Thanks,
Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Thursday, February 05, 2004 11:18 AM
> To: Anton Okmianski; Andrew Ross; Chris Lonvick; Harrington,
> David; Marshall Rose
> Cc: [email-masked]
> Subject: RE: -protocol: transport mappings
>
>
> > From: Anton Okmianski [mailto:[email-masked]]
> >
> > I agree with general consensus that there must be at least one
> > mapping. I guess UDP is easiest.  But I would prefer that
> compliance
> > with this transport is not required as far as -protocol.
> We all know
> > UDP may not
> > be an ideal transport, so a TCP-based syslog (provided it
> adheres to a
> > standard) should not be required to provide a UDP binding.
>
> I think David has a valid point here (besides that he has
> obviously brought "a little" of his SNMP experience in...). I
> think the value of REQUIRING that there must be a simple
> mapping (I think UDP is this for
> syslog) is that we can ensure that at least all
> implementations can interoperate with each other. If we do
> not have a REQUIRED transport, we may end up with two syslog
> implementations that can not talk to each other, because one
> talks UDP while the other talks TCP. Neither of them talks
> any other protocol.
>
> I see much value in avoiding this situation. I think it is
> even worth requiring a transport that one may think to be too
> simplistic. We can leave it to the administrator to disable
> this transport, so this should not be an issue. But a least
> common denominator should be available if there is no other
> way to get it going (after all, getting things going somehow
> is better than loosing the game at all...).
>
> The only issue I see is with devices - or better said "pure
> senders" - whom's vendor will not put in the extra effort to
> implement two transports. I doubt, however, that a vendor who
> puts in a more sophisticated transport like RFC3195 has an
> issue with providing an UDP transport, too.
>
> Anyhow, to avoid issues in this regard, we may want to relax
> the REQUIRED transport mapping for "sole senders" (that is
> non-receivers, not e.g. a relay). I am myself not sure yet if
> that is a good idea, but after all, this is a discussion list ;)
>
> >
> > I think the cleanest approach is to put the transport into
> a separate
> > RFC and publish the UDP mapping concurrently with
> -protocol.  However,
> > considering that the whole transport description for UDP is
> just "use
> > port 514", I am not sure if the WG wants to go with the overhead of
> > extra RFC instead of just adding a section to -protocol.
> Personally, I
> > don't mind a one page RFC.  And I think most security issues
> > needs to be
> > moved to transport layer.
>
> I am in strong favour of a separate RFC, even though it is a
> pretty short one (I doubt it will be short in respect to
> security considerations ;)). But it will keep things cleanly
> separated. However, I see that once we really require a
> transport (UDP), that it may only complicate things. So I am
> not feeling as strong about a seperate RFC as I did some days
> ago. I am still in favour of it, but things like "this
> complicates the RFC process" may outweigh this concern.
>
> I have CC'd mtr - I don't know if he has time and is willing
> to comment on this issue, but I would deeply appreciate it
> because he obviously has experience with this by doing
> RFC3080 and 3081 in the same manner.
>
> > I think a separate transport RFC will promote multiple transports,
> > which I personally thing is a good thing.
>
> me too. I think it pays to open this possibility...
>
> >
> > If we make UDP part of -protocol, we should make it only
> conditionally
> > required.  Kinda like multiple levels of compliance in MIB that was
> > suggested.  I think it has to be stated that for UDP transport the
> > following conventions MUST be used.  But providing the UDP
> transport
> > itself is not a MUST.
>
> I think this is a re-iteration of the first argument. At
> least my comment from there applies here, too. ;)
>
> Rainer
>
>

------------------------------

Date: Thu, 5 Feb 2004 11:11:35 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: -protocol: transport mappings

> > I think the cleanest approach is to put the transport into a separate
> > RFC and publish the UDP mapping concurrently with -protocol.  However,
> > considering that the whole transport description for UDP is just "use
> > port 514", I am not sure if the WG wants to go with the overhead of
> > extra RFC instead of just adding a section to -protocol.
> > Personally, I
> > don't mind a one page RFC.  And I think most security issues
> > needs to be
> > moved to transport layer.
>
> I am in strong favour of a separate RFC, even though it is a pretty
> short one (I doubt it will be short in respect to security
> considerations ;)). But it will keep things cleanly separated. However,
> I see that once we really require a transport (UDP), that it may only
> complicate things. So I am not feeling as strong about a seperate RFC as
> I did some days ago. I am still in favour of it, but things like "this
> complicates the RFC process" may outweigh this concern.

certainly it is worthwhile to have a separate rfc, because that will allow you
to focus on explaining the security implications of that choice. (and when
datagram tls shows up later this year, you can make reference to that as
well...)

/mtr

------------------------------

Date: Thu, 5 Feb 2004 15:53:16 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

Hi,

SNMP is good at monitoring systems, but not as good at configuring
systems. The reason is fairly straightforward - Configuration requires a
much more in-depth knowledge of the thing being managed than does
monitoring.

I can tell if my car is working properly by asking some stock questions
- - does the motor start? Does it run without excessive and unexpected
noise? Do the tires inflate? Can you shift in various gears, etc. But if
I had to actually build or repair a car, I would need to know much more
about it.

SNMP is designed to allow the development of standard mib modules, and
to let those be supplemented by vendor-specific mib modules. We should
work to find a common set of attributes that can be monitored. If we
also want to be able to do common configuration tasks, then we should
also try to identify a common set of configuration parameters. But we
should expect that there will be vendor-specific mib modules to
supplement the standard mib module.

The goal is to agree on as much as we can, keeping the ease of
management by our customers/users in mind, and put that agreement into
the standard mib module, and keep any vendor-specific mib modules small.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, January 30, 2004 12:57 PM
> To: Glenn Mansfield Keeni; [email-masked]
> Subject: RE: SyslogMIB Issue-#4 // Issue-#2
>
> Let me make a comment here that applies to issue #2 (BSD Centric)
>
> > -----Original Message-----
> > From: Glenn Mansfield Keeni [mailto:[email-masked]]
> > Sent: Sunday, January 25, 2004 3:05 PM
> > To: Harrington, David
> > Cc: [email-masked]
> > Subject: Re: SyslogMIB Issue-#4
> >
> > Hi Dave,
> >     Thanks for the comments. I agree with you. Traps are useful.
> > They provide a uniform mechanism/console for the network manager
> > to manage the network, related devices and processes.
> >     There are two levels at which we may want SNMP traps in the
> > Syslog Messaging context.
> >     a. To provide another option of how a message will be
> >        processed. Presently we have
> >           - log (syslogCtlLogActionTable)
> >           - display on users console (syslogCtlUserActionTable)
> >           - relay/forward (syslogCtlFwdActionTable)
> >           - pipe (syslogCtlPipeActionTable)
>
> In our products, we have many more options. I know for sure that Kiwi
> syslogd also has many more options. I think many other vendors do have
> other options, too. Upcoming versions of our *nix based syslogd will
> definitely have more options. -sign may eventually require new actions
> (verify signature? log diagnostic warning?) [this is speculated, just
> for the records;)].
>
> What I am trying to convey is that this is a very limited set and
> different syslogd's may have totally different implementations. We can
> stick with the minimal set of generic things. I am not deep enough in
> SNMP to know if we (vendor) can define a mib to take care of
> the others
> (I am sure we can ;)). But the question is how this would
> relate to the
> "standard actions".
>
> As a side note, the filterig/rule processing system is also totally
> different in different implementations, this complicates things pretty
> much. So it is probably best to stick with the minimal possibilities
> from stock syslogd.
>
> Rainer
>
>
>
>

------------------------------

Date: Thu, 5 Feb 2004 15:28:12 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -international: trailer

Hi,

The goal should be to make it easier for operators to manage their
networks, not to make it easier for protocol designers to design
protocols.

I believe we should move to UTF-8 to allow operators who speak languages
other than ASCII-based characters to be able to get non-ASCII syslog
messages. Other management protocols are also using UTF-8, so vendors
are already moving in that direction, and syslog should do so as well.
Since ASCII is a subset of UTF-8, those systems that currently only
generate ASCII should have no problem. Those receivers that only know
how to process ASCII should learn how to process UTF-8, or filter out
the non-ASCII themselves.

In the long-term view, sooner or later, the IETF really needs to start
designing their management protocols to be somewhat interoperable. We
need to adopt common character set support for syslog, snmp, netconf,
etc. We should be trying to develop information models that are
consistent, and data models that consistent where possible. Without a
strong effort to make our protocols consistent, we will never be able to
develop security for our management interfaces that make sense across
the interfaces. Management protocols overlap in what they are good at;
no management protocol is good for every task. We should be designing
our protocols so they can share information. Having syslog only
understand ASCII makes integration with other management protocols much
more difficult. Syslog should use UTF-8.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Thursday, February 05, 2004 12:40 PM
> To: Anton Okmianski; [email-masked]
> Subject: RE: -international: trailer
>
> I would like to continue this discussion. I have listed it as
> issue #9.
> For past dicussion milestones, please visit
>
> http://www.syslog.cc/ietf/protocol/issue9.html
>
> This issue is of vital importance for the message format and thus
> -protocol. I would like to settle it as quickly as possible, as some
> other discussions can only be carried forward when this issue here is
> solved.
>
> > -----Original Message-----
> > From: Anton Okmianski [mailto:[email-masked]]
> > Sent: Thursday, January 29, 2004 11:25 PM
>
> > Can we just allow any ASCII control characters and any UTF-8 encoded
> > characters and leave it up to a different standard to define
> > the storage
> > format?
>
> Though this sounds fair, I have the feeling that it does not
> work really
> well for syslog. The reason is that syslog traditionally was printable
> text (no control character) only (at least for the most part). This is
> also in RFC 3195. Even more important is that syslog-sign depends on
> printable characters, or better said on an equal on-the-wire and
> on-storage representation. Otherwise, signatures will no longer be
> useful. Of course, we could redefine -sign (it is not
> finished yet), but
> I have the strong feeling that we are actually fiddling with a
> fundamental syslog philosophy issue. We already went a long way from
> syslog as it is currently defined and in use. I think we must
> be careful
> that we do not define something that is totally different to current
> syslog (and yields us a lot of acceptance issues...).
>
> In short: I have a strong peferrence that we should insist on
> non-nontrol-chars only. Escaping MUST be done by the
> (original) sender.
>
> What does the rest of the group think?
>
> > I think storage format must be standardized soon, but it is
> > out of scope
> > for -protocol, right? People will be looking to -protocol and try to
> > infer the log file format so they can process messages.  We
> > should make
> > it clear in -protocol that syslog servers are free to store
> > messages in
> > whatever format they choose
>
> I am about to mandate that they MUST implement a way to store raw
> message data - for signed messages. Again, if we don't
> mandate this, we
> have a fundamental issue with syslog-sign. And, yes, I found out about
> the big scope of this issue when I began to think about implementing a
> signature verifier for -sign ;)
>
> In the light of this, what does the WG think?
>
> Rainer
>
>
>

------------------------------

Date: Thu, 5 Feb 2004 15:38:59 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol: transport mappings

Hi,

I believe it will be important to have one transport that can be counted
on to be present in all compliant implementations.

dbh

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Thursday, February 05, 2004 10:25 AM
> To: 'Andrew Ross'; 'Chris Lonvick'; 'Rainer Gerhards'
> Cc: [email-masked]
> Subject: RE: -protocol: transport mappings
>
> I agree with general consensus that there must be at least
> one mapping.
> I guess UDP is easiest.  But I would prefer that compliance with this
> transport is not required as far as -protocol.  We all know
> UDP may not
> be an ideal transport, so a TCP-based syslog (provided it adheres to a
> standard) should not be required to provide a UDP binding.
>
> I think the cleanest approach is to put the transport into a separate
> RFC and publish the UDP mapping concurrently with -protocol.  However,
> considering that the whole transport description for UDP is just "use
> port 514", I am not sure if the WG wants to go with the overhead of
> extra RFC instead of just adding a section to -protocol.
> Personally, I
> don't mind a one page RFC.  And I think most security issues
> needs to be
> moved to transport layer.
>
> I think a separate transport RFC will promote multiple
> transports, which
> I personally thing is a good thing.
>
> If we make UDP part of -protocol, we should make it only conditionally
> required.  Kinda like multiple levels of compliance in MIB that was
> suggested.  I think it has to be stated that for UDP transport the
> following conventions MUST be used.  But providing the UDP transport
> itself is not a MUST.
>
> Anton.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Andrew Ross
> > Sent: Wednesday, February 04, 2004 7:28 PM
> > To: 'Chris Lonvick'; 'Rainer Gerhards'
> > Cc: [email-masked]
> > Subject: RE: -protocol: transport mappings
> >
> >
> >
> > I agree that having a separate RFC for mapping syslog into
> > various transports would be good. Then we could address
> > Syslog over UDP, TCP, BEEP, SNMP, yada yada.
> >
> > Maybe also make a mention in protocol that it is transport
> > independent and refer them to the transport RFC name.
> >
> > Cheers
> >
> > Andrew
> >
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Chris Lonvick
> > Sent: Thursday, 5 February 2004 3:30 a.m.
> > To: Rainer Gerhards
> > Cc: [email-masked]
> > Subject: Re: -protocol: transport mappings
> >
> >
> > Hi Folks,
> >
> > We need to get this resolved.  If you have an opinion on
> > this, please speak up.  If I don't hear anything about this
> > then I will assume that "0 responses" = "0 interest" and
> > we'll ask Rainer to keep the mapping as part of syslog-protocol.
> >
> > Thanks,
> > Chris
> >
> > On Tue, 3 Feb 2004, Rainer Gerhards wrote:
> >
> > > Hi WG,
> > >
> > > I had a recent off-list discussion regarding transport
> > mappings. This
> > > discussion targeted the quite important point what
> > transport mappings
> > > are good for - and wether or not -protocol should contain an UDP
> > > transport mapping.
> > >
> > > My position is that -protocol should NOT contain any
> > transport mapping
> > > and that there should be a short RFC outlining how
> > -protocol is to be
> > > mapped on UDP transport. Just as it is done in RFC3080
> and 3081 for
> > > BEEP. I would like to do this, because this will make
> crystal-clear
> > that
> > > -protocol is transport ignorant. This is the comment I received
> > (poster
> > > requested to remain anonymous):
> > >
> > > > I'm a bit doubtful about doing that
> > > > as it would
> > > > allow people to do syslog-protocol/tcp, or syslog-protocol/sctp,
> > > > etc.  In one sense, I'd prefer to not open that opportunity as
> > > > various factions may
> > > > start doing things their own way which would not promote
> > > > interoperability.
> > > > Perhaps one company would choose to implement
> > > > syslog-protocol/soap while
> > > > another implements syslog-protocol/http.  If we do this, I'll
> > probably
> > > > insist that syslog-protocol/udp be a REQUIRED implementation and
> > > > others are OPTIONAL.
> > >
> > > I think this is an very important comment in regard to the overall
> > > design. I think it is of advantage to facilitate the
> > creation of other
> > > transport mappings, as for example is currently being
> discussed for
> > SNMP
> > > inform messages. I agree that it makes it easy to "abuse"
> > -protocol to
> > > create non-standard transport mappings.
> > >
> > > On the other hand, those doing this would most probably do
> > it anyhow,
> > > just not only with their own transport but with their own message
> > > format, too. I think even if a vendor goes ahead and creates
> > > syslog-protocol/tcp, this is advantagous over him creating just a
> > plain
> > > TCP implementation with a different message format. And as
> > a reminder,
> > > this is current state of the art, there ARE many syslog/raw tcp
> > > implementations in the wild. So the lack of a standard
> way to do it
> > > obviously did not stop the implementation. I think it is an
> > advantage
> > if
> > > such non-standard implementations at least abide to the
> > same message
> > > format.
> > >
> > > I would deeply appreciate all feedback from the WG on this
> > important
> > > topic.
> > >
> > > Rainer
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>

------------------------------

Date: Fri, 6 Feb 2004 12:13:15 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: -protocol: transport mappings

My vote is for a separate RFC for transport mappings and their security
considerations. I also vote for a having at least a UDP mapping in
- -protocol.

Regards

Andrew

------------------------------

Date: Fri, 6 Feb 2004 11:59:31 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: -international: trailer

>In short: I have a strong preference that we should insist on
>non-control-chars only. Escaping MUST be done by the (original) sender.

Agreed

>I am about to mandate that they MUST implement a way to store raw
>message data - for signed messages. Again, if we don't mandate this, we
>have a fundamental issue with syslog-sign.

Yes, a standard format is essential for verifying data at a later stage.

------------------------------

Date: Fri, 6 Feb 2004 10:30:27 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

David,

> -----Original Message-----
> From: Harrington, David [mailto:[email-masked]]
> Sent: Thursday, February 05, 2004 9:53 PM
> To: Rainer Gerhards; Glenn Mansfield Keeni; [email-masked]
> Subject: RE: SyslogMIB Issue-#4 // Issue-#2
>
> Hi,
>
> SNMP is good at monitoring systems, but not as good at configuring
> systems. The reason is fairly straightforward - Configuration
> requires a
> much more in-depth knowledge of the thing being managed than does
> monitoring.
>
> I can tell if my car is working properly by asking some stock
> questions
> - does the motor start? Does it run without excessive and unexpected
> noise? Do the tires inflate? Can you shift in various gears,
> etc. But if
> I had to actually build or repair a car, I would need to know
> much more
> about it.
>
> SNMP is designed to allow the development of standard mib modules, and
> to let those be supplemented by vendor-specific mib modules. We should
> work to find a common set of attributes that can be monitored. If we
> also want to be able to do common configuration tasks, then we should
> also try to identify a common set of configuration parameters.

Let me phrase my question rather bluntly: does it pay to provide a very
minimal set of config settings given the fact that almost every vendor
has very different ways to do this. Also, in my experience customers
tend to use those vendor-specifc ways, simply because they need it. To
be honest, I think we will be hesitant to implement standard
configuration simply because I do not see any customer demand for such.
I think we can put our ressources to efforts that receive a higher
demand.

It may just be my personal feeling ... what do the other implementors
think?

Rainer

------------------------------

Date: Fri, 6 Feb 2004 12:24:27 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

David,

thanks for your wake-up call...

> I believe we should move to UTF-8 to allow operators who

UTF-8 is actually a MUST in syslog-protocol.

I have to admit that I did not fully understand UNICODE until now... I
always read RFC 2279 (UTF-8 encoding). It specifies (page 2):

- - Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
  correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
  consequence is that a plain ASCII string is also a valid UTF-8
  string.

- - US-ASCII values do not appear otherwise in a UTF-8 encoded
  character stream.  This provides compatibility with file systems
  or other software (e.g. the printf() function in C libraries) that
  parse based on US-ASCII values but are transparent to other
  values.

So I thought that control characters (US-ASCII below 0x20 & 0x7f) are
only present in this range. I assumed, however, that UNICODE as such
does not provide control characters  but only printable characters.

Obviously, I am wrong. I did some more research this morning and found
that at least pane 20xx does contain control characters:

http://www.unicode.org/charts/PDF/U2000.pdf

For a sample, see 0x200C and the characters following it. So my basic
assumption "just exclude US-ASCII control chars and you are done" is
wrong.

Having said this, I think we now have a bigger issue than I initially
thought. In the light of Unicode control characters, we are more or less
forced to allow any control characters inside the message part. If we
don't we can't comply with the (well thought-out) IETF Unicode
requirement (RFC 2277/BCP 18) for new RFCs.

As I wrote in my initial message, that not only affects -protocol, but
also -sign (though not to bad when it refers to -protocol for the format
description).

I think allowance for all character values affects also most of the
existing syslog software, as many work with C strings, where 0x00 is a
terminating character. I don't say it can't be dealt with in new
implementations. I just would like to mention that this will probably
get us a slow start, because the initial effort will be much higher for
an implementor - lot's of existing code could not be re-used.

Anyhow, I don't see an alternative to allowing all control characters.

I have included some Unicode links in my summary on this issue at
http://www.syslog.cc/ietf/protocol/issue9.html - this may be helpful for
others who need to dig a little into the Unicode requirement.

What does the rest of the WG think?

Rainer

------------------------------

Date: Fri, 6 Feb 2004 07:36:00 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: Re: -protocol: transport mappings

Hi,

It appears that we have consensus to adopt a new piece of work
specifically to document the transport mapping of syslog.  This work needs
to state that the REQUIRED mapping at this time is UDP for assured
interoperability.  It needs to stay short, and to the point so it can
progress with syslog-protocol through the RFC process.  It should leave
the door wide open for other transports to be identified and it must
clearly document the security considerations of the transports.

If there is consensus in the WG after this document and syslog-protocol ID
are accepted as RFCs, then we may consider updating that RFC to include
more mappings.  The ID to which Marshall referred is Eric Rescorla's work
on Datagram Security (like SSL for UDP):
  http://www.ietf.org/internet-drafts/draft-rescorla-dtls-00.txt
We can reference that as a Work In Progress at this time and (if all
proceeds smoothly) as an RFC upon the update.

An now for the really important question:  Who will volunteer to write
that ID?

Thanks,
Chris

------------------------------

Date: Fri, 6 Feb 2004 16:59:42 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol: transport mappings

> 2.  I think requiring UDP implementation reduces the areas in which
> syslog message format RFC could be utilized.  I can see many different
> areas.  For example, if RFC came without UDP baggage, we,
> within Cisco,
> could potentially standardize on this format for products which write
> directly to log file (no syslog servers) should be compatible with the
> format.  This would be a great thing for us to be able to have a
> consistent format regardless of whether or not syslog
> transport is used
> because it is inevitable that some products will use syslog and other
> will write straight to file.
>
> Another use case I have is writing log messages into Windows
> Event Log.
> I would really like if that format be the same as on other platforms
> which use syslog.  It would have been easier for us to establish this
> requirement for products within Cisco if we could just refer to syslog
> message format RFC and it did not come with a baggage of having to
> implement a syslog UDP transport, which may not be applicable.
>
> So, I am open on whether or not UDP binding is included in
> -protocol or
> outside.  But I would really prefer if it was not required.

I agree on your general comments. In fact, that was one of the
motivations of splitting -protocol. I think, however, that even if we
specify a required transport mapping in -protocol itself, that does not
necessarily prohibt this.

I think you are talking about storage here. It seems natural that no
transport is needed to store the message. I think the implementation
requirement can be worded so that a minimal transport mapping needs only
to be implemented if the program actually uses a transport.

Besides that, I think you can always say that "the format must adhere to
RFCxxxx, section 4." - that should leave out any ambiguity.

I will comment on the other issue in a summary mail I am right now
preparing.

Rainer

------------------------------

Date: Fri, 6 Feb 2004 17:28:17 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol: transport mappings

Hi all,

thanks for all the great comments. Let me try to sum up the current
concensus:

- - multiple transport mappings are a good thing
- - it is at least helpful to have one required transport. Some do not
  really like this idea, but would tolerate it (correct me if I got
  this wrong!)
- - a required transport should be the simplest one to implement.
  For syslog, UDP (more or less as in RFC 3164) qualfies for this.

Given that state of the discussion, I propose that we actually require
each implementation that talks to a transport MUST support the
to-be-written UDP transport mapping.

While UDP has many inherant issues, it can at least serve as an
easy-to-implement least common denominator if everything else fails. It
can't be so totally bad as a vast amount of syslog currently runs over
UDP. In fact, standards-compliant TCP syslog is rarely seen in today's
reality.

Now comes the issue if the UDP mapping should be a separate document or
included in -protocol. There are good arguments for both.

If we include the UDP transport mapping in -protocol, we gain:

- - a single, self-contained document that describes *all* essentials
- - this probably saves us some/much hassle during the IETF process

If we include UDP transport mapping in a separate document, we gain:

- - a crystal-clear separation of the protocol layers
- - focussed security considerations, which can relief from
  ambiguity
- - the ability to develop the transport mapping and the
  core format independently

Actually, it's a hard decision. I don't know which way offers more
advantages. From my software engineering point of view, I am still in
favour of a separate document for the UDP mapping. But it may not be
worth the extra effort. Specifically, I am totally inexperienced what
this additional hassle in the IETF process is and how costly (in terms
of time) it will be.

I would appreciate if those experienced with these issues could let me
know their qualified votes. I would also like to know if someone
violently objects either one of the two approaches.

I am trying to settle this issue by Tuesday morning, just so that we
have a chance to move forward in regard of our deadline. I would deeply
appreciate any comments.

If I don't receive strong votes, I will probably edit the document based
on the concensus I have summarized AND will assume that the UDP
transport mapping will be done in a separate document.

Rainer

------------------------------

Date: Fri, 6 Feb 2004 11:37:09 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

Rainer:

Good research.  I too did not realize there were control characters
outside of ASCII in Unicode.  The Unicode character range you referenced
had, for example, alternative line separator.  How many line separators
does the world need for God sake?  :)

I agree with your conclusion that we need to support all Unicode/UTF.  I
also think that doing any kind of escaping is generally bad and should
be deferred until it is absolutely necessary (like maybe escaping line
breaks for storage).

I guess this means, we can't have a line separator trailer unless we
escape all others inside of message.  I really would prefer no escaping.
I think alternatively, a UDP transport can define an optional/required
structured element for message length in octets, but it is tricky.

Anton.

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 6:24 AM
> To: Harrington, David; Anton Okmianski; [email-masked]
> Subject: RE: -international: trailer
>
>
> David,
>
> thanks for your wake-up call...
>
> > I believe we should move to UTF-8 to allow operators who
>
> UTF-8 is actually a MUST in syslog-protocol.
>
> I have to admit that I did not fully understand UNICODE until
> now... I always read RFC 2279 (UTF-8 encoding). It specifies (page 2):
>
> - Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
>   correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
>   consequence is that a plain ASCII string is also a valid UTF-8
>   string.
>
> - US-ASCII values do not appear otherwise in a UTF-8 encoded
>   character stream.  This provides compatibility with file systems
>   or other software (e.g. the printf() function in C libraries) that
>   parse based on US-ASCII values but are transparent to other
>   values.
>
> So I thought that control characters (US-ASCII below 0x20 &
> 0x7f) are only present in this range. I assumed, however,
> that UNICODE as such does not provide control characters  but
> only printable characters.
>
> Obviously, I am wrong. I did some more research this morning
> and found that at least pane 20xx does contain control characters:
>
http://www.unicode.org/charts/PDF/U2000.pdf

For a sample, see 0x200C and the characters following it. So my basic
assumption "just exclude US-ASCII control chars and you are done" is
wrong.

Having said this, I think we now have a bigger issue than I initially
thought. In the light of Unicode control characters, we are more or less
forced to allow any control characters inside the message part. If we
don't we can't comply with the (well thought-out) IETF Unicode
requirement (RFC 2277/BCP 18) for new RFCs.

As I wrote in my initial message, that not only affects -protocol, but
also -sign (though not to bad when it refers to -protocol for the format
description).

I think allowance for all character values affects also most of the
existing syslog software, as many work with C strings, where 0x00 is a
terminating character. I don't say it can't be dealt with in new
implementations. I just would like to mention that this will probably
get us a slow start, because the initial effort will be much higher for
an implementor - lot's of existing code could not be re-used.

Anyhow, I don't see an alternative to allowing all control characters.

I have included some Unicode links in my summary on this issue at
http://www.syslog.cc/ietf/protocol/issue9.html - this may be helpful for
others who need to dig a little into the Unicode requirement.

What does the rest of the WG think?

Rainer

------------------------------

Date: Fri, 6 Feb 2004 18:14:02 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

Anton:

> > I am still tempted to allow only octets in the range of 1..255. ;)
>
> I think at least technically this restriction is possible because 0x00
> never appears as part of any characters encoded as multi-octet
> characters in UTF-8.  See table here:
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

Technically it is possible ... my concern is more existing code. I am
still in the hope that existing syslog code can be upgraded to
- -protocol. Sure, it requires some change, but it is not that bad.
However, most of the code I have seen uses ANSI C string, that is a
string that is terminated by NUL (0x00). If we allow 0x00 in the
message, all of this code needs to be re-written to use byte-counting
string libraries. Far from trivial.

If we forbid 0x00, things are much easier. All the needs to be done is
that the receiver process (subsystem) needs to parse the message as it
arrives. If there is 0x00 in it, the receiver can log a diagnostic
message and do whatever else it is configured to do in this case. For
example, it could replace the 0x00 with a pre-configured replacement
char ("?" maybe?). Or it could drop the message altogether. Whatever it
does, it can ensure that the message passed on to its upper layers is a
valid C string (and, yes, it should do this sanity check, otherwise
things may become wild).

This is strictly speaking not a protocol issue, eventually not even one
that the IETF should care about (algorithms and implementations seem to
be out of scope ;)). However, I thinks this is an important real-world
issue. I even think this can be an issue that can be important for the
overall success of -protocol. Let's say we require that 0x00 is a valid
characters. How many implementors would be tempted to say "we don't
care, we don't allow it no matter what the RFC says". If we have the
impression that a fair amount would actually take this route, it may be
wise to forbid 0x00 inside the RFC. It may look ugly (especially for the
Java guys) ... but sometimes it is better to do things in a slightly
ugly way than to have a hell of interop problems later on.

Having written all this, I'd say I will forbid 0x00 in -protocol-03 and
allow everything else if nobody violently objects.

Rainer

------------------------------

Date: Fri, 6 Feb 2004 09:20:02 -0800 (PST)
From: Lonvick <[email-masked]>
Subject: RE: -international: trailer

- ---------- Forwarded message ----------
Date: Fri, 6 Feb 2004 12:02:14 -0500
From: Anton Okmianski <[email-masked]>
To: 'Rainer Gerhards' <[email-masked]>,
     "'Harrington, David'" <[email-masked]>, [email-masked]
Subject: RE: -international: trailer

Rainer:

> I am still tempted to allow only octets in the range of 1..255. ;)

I think at least technically this restriction is possible because 0x00
never appears as part of any characters encoded as multi-octet
characters in UTF-8.  See table here:
http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

However, I don't know if restricting this bit sequence is necessary.
What do other UTF-8 based protocols do?

Anton.

------------------------------

Date: Fri, 6 Feb 2004 17:51:14 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

Anton:

> I agree with your conclusion that we need to support all
> Unicode/UTF.  I
> also think that doing any kind of escaping is generally bad and should
> be deferred until it is absolutely necessary (like maybe escaping line
> breaks for storage).

I agree, escaping needs to be done when it goes to the storage subsystem
- - eventually. We always think "text file" though some use databases,
where this is no issue at all. But that's not the point.

I thought a while over this issue during the course of the day... We can
have the storage subsystem escape non-printable characters. Obviously,
it is up to the storage subsystem how it does this. When the data is
then read back, the storage subsystem should decode the persisted
message and provide the original block to e.g. the message verifier. So
we do not have an issue with -sign.

Obviously, a syslog-storage RFC comes into the mind, but I think we are
busy enough with current discussions ;) Let's make one step after
another...

So I am more or less prepared to edit protcol-03 so that all characters
are allowed, including ascii control characters.

The thing left that makes me really frightend is the 0x00 character. I
know allowing it will break a lot of existing code and make it hard to
update it to the new format. On the other hand, explicitely allowing it
will remove a potential security weakness... some of the bad guys may
have fun with sending 0x00 especially when we do not allow it.

I am still tempted to allow only octets in the range of 1..255. ;)

I'd appreciate comments on this issue. If we can solve this, we can
solve this issue here as well as the trailer. And I think we are close
to doing that.

>
> I guess this means, we can't have a line separator trailer unless we
> escape all others inside of message.  I really would prefer
> no escaping.

I agree to this - UTF-8 kills the TRAILER.

On second thought, the trailer was a bad idea initially. After all, my
intension was to have an extra sanity check for the framing - but that
is a transport issue, not a general format issue (for a
transport-ignorant message format).

> I think alternatively, a UDP transport can define an optional/required
> structured element for message length in octets, but it is tricky.

I am in favour to not do this. As you say, it is tricky - and the extra
sanity check does not buy us much in UDP (so many things that can go
wrong anyhow...)

Rainer

------------------------------

Date: Fri, 6 Feb 2004 12:38:36 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -international: trailer

Hi Rainer,

I don't know UTF-8 very well. I am of the impression that 0x00 can occur
in UTF-8, in multi-byte character sequences. You've been researching the
UTF-8. Can you determine if that's true? If it is, then we cannot limit
octets to 1..255 values.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 11:51 AM
> To: Anton Okmianski; Harrington, David; [email-masked]
> Subject: RE: -international: trailer
>
> Anton:
>
> > I agree with your conclusion that we need to support all
> > Unicode/UTF.  I
> > also think that doing any kind of escaping is generally bad
> and should
> > be deferred until it is absolutely necessary (like maybe
> escaping line
> > breaks for storage).
>
> I agree, escaping needs to be done when it goes to the
> storage subsystem
> - eventually. We always think "text file" though some use databases,
> where this is no issue at all. But that's not the point.
>
> I thought a while over this issue during the course of the
> day... We can
> have the storage subsystem escape non-printable characters. Obviously,
> it is up to the storage subsystem how it does this. When the data is
> then read back, the storage subsystem should decode the persisted
> message and provide the original block to e.g. the message
> verifier. So
> we do not have an issue with -sign.
>
> Obviously, a syslog-storage RFC comes into the mind, but I
> think we are
> busy enough with current discussions ;) Let's make one step after
> another...
>
> So I am more or less prepared to edit protcol-03 so that all
> characters
> are allowed, including ascii control characters.
>
> The thing left that makes me really frightend is the 0x00 character. I
> know allowing it will break a lot of existing code and make it hard to
> update it to the new format. On the other hand, explicitely
> allowing it
> will remove a potential security weakness... some of the bad guys may
> have fun with sending 0x00 especially when we do not allow it.
>
> I am still tempted to allow only octets in the range of 1..255. ;)
>
> I'd appreciate comments on this issue. If we can solve this, we can
> solve this issue here as well as the trailer. And I think we are close
> to doing that.
>
> >
> > I guess this means, we can't have a line separator trailer unless we
> > escape all others inside of message.  I really would prefer
> > no escaping.
>
> I agree to this - UTF-8 kills the TRAILER.
>
> On second thought, the trailer was a bad idea initially. After all, my
> intension was to have an extra sanity check for the framing - but that
> is a transport issue, not a general format issue (for a
> transport-ignorant message format).
>
> > I think alternatively, a UDP transport can define an
> optional/required
> > structured element for message length in octets, but it is tricky.
>
> I am in favour to not do this. As you say, it is tricky - and
> the extra
> sanity check does not buy us much in UDP (so many things that can go
> wrong anyhow...)
>
> Rainer
>

------------------------------

Date: Fri, 6 Feb 2004 12:49:06 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -international: trailer

Hi,

I see our messages crossed in transit. You've already researched whether
0x00 occurs in UTF-8.

I have a concern about making C-compatibility a requirement of
- -protocol. I understand the concern about the amount of work
implementors may need to do, and it spotential impact on adoption.
However, I think this is a red herring. All an implementor has to do is
put in one piece of code that looks at the incoming message and looks
for 0x00 octets, if they care, and handle however they choose in their
implementation. I do not believe it is appropriate for the standard to
impose a specific solution for this implementation-dependent issue.

Referring again to my SNMP experience, we have found that CLRs - crappy
little rules - constantly come back to bite us in unforeseen ways. We
should write the standard, without a lot of crappy little rules to deal
with corner cases, and let the implementors solve their own
implementation problems.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 12:14 PM
> To: Anton Okmianski; Harrington, David; [email-masked]
> Subject: RE: -international: trailer
>
> Anton:
>
> > > I am still tempted to allow only octets in the range of 1..255. ;)
> >
> > I think at least technically this restriction is possible
> because 0x00
> > never appears as part of any characters encoded as multi-octet
> > characters in UTF-8.  See table here:
> > http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8
>
> Technically it is possible ... my concern is more existing code. I am
> still in the hope that existing syslog code can be upgraded to
> -protocol. Sure, it requires some change, but it is not that bad.
> However, most of the code I have seen uses ANSI C string, that is a
> string that is terminated by NUL (0x00). If we allow 0x00 in the
> message, all of this code needs to be re-written to use byte-counting
> string libraries. Far from trivial.
>
> If we forbid 0x00, things are much easier. All the needs to be done is
> that the receiver process (subsystem) needs to parse the message as it
> arrives. If there is 0x00 in it, the receiver can log a diagnostic
> message and do whatever else it is configured to do in this case. For
> example, it could replace the 0x00 with a pre-configured replacement
> char ("?" maybe?). Or it could drop the message altogether.
> Whatever it
> does, it can ensure that the message passed on to its upper
> layers is a
> valid C string (and, yes, it should do this sanity check, otherwise
> things may become wild).
>
> This is strictly speaking not a protocol issue, eventually
> not even one
> that the IETF should care about (algorithms and
> implementations seem to
> be out of scope ;)). However, I thinks this is an important real-world
> issue. I even think this can be an issue that can be important for the
> overall success of -protocol. Let's say we require that 0x00
> is a valid
> characters. How many implementors would be tempted to say "we don't
> care, we don't allow it no matter what the RFC says". If we have the
> impression that a fair amount would actually take this route,
> it may be
> wise to forbid 0x00 inside the RFC. It may look ugly
> (especially for the
> Java guys) ... but sometimes it is better to do things in a slightly
> ugly way than to have a hell of interop problems later on.
>
> Having written all this, I'd say I will forbid 0x00 in
> -protocol-03 and
> allow everything else if nobody violently objects.
>
> Rainer
>

------------------------------

Date: Fri, 6 Feb 2004 12:02:14 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

Rainer:

> I am still tempted to allow only octets in the range of 1..255. ;)

I think at least technically this restriction is possible because 0x00
never appears as part of any characters encoded as multi-octet
characters in UTF-8.  See table here:
http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

However, I don't know if restricting this bit sequence is necessary.
What do other UTF-8 based protocols do?

Anton.

------------------------------

Date: Fri, 6 Feb 2004 18:54:40 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

> I don't know UTF-8 very well. I am of the impression that
> 0x00 can occur
> in UTF-8, in multi-byte character sequences. You've been
> researching the
> UTF-8. Can you determine if that's true? If it is, then we
> cannot limit
> octets to 1..255 values.

It can not happen. The reason is that all octets 0..127 are reserved for
US-ASCII, so these are never reused in multibyte sequences. These octets
are all in the range 128..255. Anton Okmianski has independently
verified this (this message has not been propagated to all list
subscribers).

Of course it can happen in deliberately invalidly crafted messages, just
as a reminer

Rainer

------------------------------

Date: Fri, 6 Feb 2004 10:34:02 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: RE: -international: trailer

Hi,

A couple of things:

Paul Hoffman, the author of RFC 3536 on "Terminology Used in
Internationalization in the IETF"
  ftp://ftp.rfc-editor.org/in-notes/rfc3536.txt
has been keeping up with most, if not all, efforts to internationalize
protocols and strings used in IP.  He has volunteered to help us out when
needed.  I would suggest that Rainer gather the thoughts and proposals and
send them to Paul off list - a very few others may volunteer to be cc'd on
that.  (I just think it impolite to involve someone in an on-going
discussion on a list that person is not subscribed to.)  Rainer can then
bring the results back to this discussion.  I'm certain that Paul will
review the ID when it goes to the IESG for Last Call.

We will probably not produce any work about storing syslog messages at
this time.  That seems to be outside of our scope.  Once we're well on our
way past this set of IDs/RFCs then we may consider something like that.
I'm not sure what reception that will get from the ADs since the IETF is
more about things on the wire than things in the end system.

Thanks,
Chris

On Fri, 6 Feb 2004, Rainer Gerhards wrote:

> Anton:
>
> > I agree with your conclusion that we need to support all
> > Unicode/UTF.  I
> > also think that doing any kind of escaping is generally bad and should
> > be deferred until it is absolutely necessary (like maybe escaping line
> > breaks for storage).
>
> I agree, escaping needs to be done when it goes to the storage subsystem
> - eventually. We always think "text file" though some use databases,
> where this is no issue at all. But that's not the point.
>
> I thought a while over this issue during the course of the day... We can
> have the storage subsystem escape non-printable characters. Obviously,
> it is up to the storage subsystem how it does this. When the data is
> then read back, the storage subsystem should decode the persisted
> message and provide the original block to e.g. the message verifier. So
> we do not have an issue with -sign.
>
> Obviously, a syslog-storage RFC comes into the mind, but I think we are
> busy enough with current discussions ;) Let's make one step after
> another...
>
> So I am more or less prepared to edit protcol-03 so that all characters
> are allowed, including ascii control characters.
>
> The thing left that makes me really frightend is the 0x00 character. I
> know allowing it will break a lot of existing code and make it hard to
> update it to the new format. On the other hand, explicitely allowing it
> will remove a potential security weakness... some of the bad guys may
> have fun with sending 0x00 especially when we do not allow it.
>
> I am still tempted to allow only octets in the range of 1..255. ;)
>
> I'd appreciate comments on this issue. If we can solve this, we can
> solve this issue here as well as the trailer. And I think we are close
> to doing that.
>
> >
> > I guess this means, we can't have a line separator trailer unless we
> > escape all others inside of message.  I really would prefer
> > no escaping.
>
> I agree to this - UTF-8 kills the TRAILER.
>
> On second thought, the trailer was a bad idea initially. After all, my
> intension was to have an extra sanity check for the framing - but that
> is a transport issue, not a general format issue (for a
> transport-ignorant message format).
>
> > I think alternatively, a UDP transport can define an optional/required
> > structured element for message length in octets, but it is tricky.
>
> I am in favour to not do this. As you say, it is tricky - and the extra
> sanity check does not buy us much in UDP (so many things that can go
> wrong anyhow...)
>
> Rainer
>
>
>

------------------------------

Date: Fri, 6 Feb 2004 13:56:02 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

Hi Rainer,

I agree that it may not be a good use of time to try to develop
configuration capabilities when there is little agreement about a common
approach. My main point was that SNMP is not a particularly good choice
for fully configuring a syslog implementation, and if that work were to
be done, then it should be done to be compatible with the netconf
standards-in-development-work for fully configuring managed entities.

I do believe that a small amount of SNMP configuration probably would be
worthwhile. SNMP configuration capabilities should focus on those
non-static aspects that are already relatively common in
implementations, and where small management operations are likely to be
useful and implementation-independent, such as enabling/disabling
operation or setting the IP addresses of clients/servers. I anticipate
that this would include probably less than ten managed objects, would
not be very time-consuming to include, and would be useful for managing
deployed implementations.

Lack of standardization of such basic configuration parameters makes it
harder for operators to use syslog.

My $.02
dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 4:30 AM
> To: Harrington, David; Glenn Mansfield Keeni; [email-masked]
> Subject: RE: SyslogMIB Issue-#4 // Issue-#2
>
> David,
>
> > -----Original Message-----
> > From: Harrington, David [mailto:[email-masked]]
> > Sent: Thursday, February 05, 2004 9:53 PM
> > To: Rainer Gerhards; Glenn Mansfield Keeni; [email-masked]
> > Subject: RE: SyslogMIB Issue-#4 // Issue-#2
> >
> > Hi,
> >
> > SNMP is good at monitoring systems, but not as good at configuring
> > systems. The reason is fairly straightforward - Configuration
> > requires a
> > much more in-depth knowledge of the thing being managed than does
> > monitoring.
> >
> > I can tell if my car is working properly by asking some stock
> > questions
> > - does the motor start? Does it run without excessive and unexpected
> > noise? Do the tires inflate? Can you shift in various gears,
> > etc. But if
> > I had to actually build or repair a car, I would need to know
> > much more
> > about it.
> >
> > SNMP is designed to allow the development of standard mib
> modules, and
> > to let those be supplemented by vendor-specific mib
> modules. We should
> > work to find a common set of attributes that can be monitored. If we
> > also want to be able to do common configuration tasks, then
> we should
> > also try to identify a common set of configuration parameters.
>
> Let me phrase my question rather bluntly: does it pay to
> provide a very
> minimal set of config settings given the fact that almost every vendor
> has very different ways to do this. Also, in my experience customers
> tend to use those vendor-specifc ways, simply because they need it. To
> be honest, I think we will be hesitant to implement standard
> configuration simply because I do not see any customer demand
> for such.
> I think we can put our ressources to efforts that receive a higher
> demand.
>
> It may just be my personal feeling ... what do the other implementors
> think?
>
> Rainer
>
>
>

------------------------------

Date: Fri, 6 Feb 2004 14:50:30 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

I agree.

Besides, it seems to me if we prohibit something like this, the
implementations would still need to be aware of it.  In fact, they will
need to check for it in order to be compliant with the RFC and log a
diagnostic message if they receive something non-compliant.

Also, most "modern" languages like C#, Java have built in support for
Unicode. At least in Java, 0x00 character has no special meaning in a
string. Example:

 char[] str = new char[] { 0x41, 0x42, 0x00, 0x43 };
 String string = new String( str );
 System.out.println("Length: " + string.length());
 System.out.println("String: [" + string + "]");

Output...

 Length: 4
 String: [AB C]

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Harrington, David
> Sent: Friday, February 06, 2004 12:49 PM
> To: Rainer Gerhards; Anton Okmianski; [email-masked]
> Subject: RE: -international: trailer
>
>
> Hi,
>
> I see our messages crossed in transit. You've already
> researched whether 0x00 occurs in UTF-8.
>
> I have a concern about making C-compatibility a requirement
> of -protocol. I understand the concern about the amount of
> work implementors may need to do, and it spotential impact on
> adoption. However, I think this is a red herring. All an
> implementor has to do is put in one piece of code that looks
> at the incoming message and looks for 0x00 octets, if they
> care, and handle however they choose in their implementation.
> I do not believe it is appropriate for the standard to impose
> a specific solution for this implementation-dependent issue.
>
> Referring again to my SNMP experience, we have found that
> CLRs - crappy little rules - constantly come back to bite us
> in unforeseen ways. We should write the standard, without a
> lot of crappy little rules to deal with corner cases, and let
> the implementors solve their own implementation problems.
>
> dbh
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Friday, February 06, 2004 12:14 PM
> > To: Anton Okmianski; Harrington, David; [email-masked]
> > Subject: RE: -international: trailer
> >
> > Anton:
> >
> > > > I am still tempted to allow only octets in the range of
> 1..255. ;)
> > >
> > > I think at least technically this restriction is possible
> > because 0x00
> > > never appears as part of any characters encoded as multi-octet
> > > characters in UTF-8.  See table here:
> > > http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8
> >
> > Technically it is possible ... my concern is more existing
> code. I am
> > still in the hope that existing syslog code can be upgraded to
> > -protocol. Sure, it requires some change, but it is not that bad.
> > However, most of the code I have seen uses ANSI C string, that is a
> > string that is terminated by NUL (0x00). If we allow 0x00 in the
> > message, all of this code needs to be re-written to use
> byte-counting
> > string libraries. Far from trivial.
> >
> > If we forbid 0x00, things are much easier. All the needs to
> be done is
> > that the receiver process (subsystem) needs to parse the
> message as it
> > arrives. If there is 0x00 in it, the receiver can log a diagnostic
> > message and do whatever else it is configured to do in this
> case. For
> > example, it could replace the 0x00 with a pre-configured
> replacement
> > char ("?" maybe?). Or it could drop the message altogether.
> Whatever
> > it does, it can ensure that the message passed on to its upper
> > layers is a
> > valid C string (and, yes, it should do this sanity check, otherwise
> > things may become wild).
> >
> > This is strictly speaking not a protocol issue, eventually not even
> > one that the IETF should care about (algorithms and
> > implementations seem to
> > be out of scope ;)). However, I thinks this is an important
> real-world
> > issue. I even think this can be an issue that can be
> important for the
> > overall success of -protocol. Let's say we require that 0x00
> > is a valid
> > characters. How many implementors would be tempted to say "we don't
> > care, we don't allow it no matter what the RFC says". If we have the
> > impression that a fair amount would actually take this route,
> > it may be
> > wise to forbid 0x00 inside the RFC. It may look ugly
> > (especially for the
> > Java guys) ... but sometimes it is better to do things in a slightly
> > ugly way than to have a hell of interop problems later on.
> >
> > Having written all this, I'd say I will forbid 0x00 in -protocol-03
> > and allow everything else if nobody violently objects.
> >
> > Rainer
> >
>
>

------------------------------

Date: Fri, 6 Feb 2004 15:26:20 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol: transport mappings

Hi,

Comments inline.

*snip*

> > 2.  I think requiring UDP implementation reduces the areas in which
> > syslog message format RFC could be utilized.  I can see
> many different
> > areas.  For example, if RFC came without UDP baggage, we,
> > within Cisco,
> > could potentially standardize on this format for products
> which write
> > directly to log file (no syslog servers) should be
> compatible with the
> > format.  This would be a great thing for us to be able to have a
> > consistent format regardless of whether or not syslog
> > transport is used
> > because it is inevitable that some products will use syslog
> and other
> > will write straight to file.

Any vendor can choose to develop supplementary uses for the syslog
message format without being forced to implement UDP. If they choose not
to implement the UDP transport, then the only thing this affects is

1) whether the vendor can honestly claim in their marketing that their
implementaion is fully compliant to the syslog standard,

2) and whether they can honestly market their proprietary logging
products as being fully compliant to the syslog standard.

Syslog is not being written with an interface to on-the-box storage or
with interfaces to other logging mechanisms. It is not being developed
to best meet the needs of marketing. It is being written as an IETF (the
I stands for Internet) protocol to standardize the on-the-wire format
for interoperability over IP between implementations from multiple
implementors.

There is no reason to not specify UDP (or whichever IP protocol) as a
standard transport just to accommodate a vendor's "potential" usage that
is totally out of scope for this WG, and is out of scope for the IETF in
general.

My $.02
dbh

> >
> > Another use case I have is writing log messages into Windows
> > Event Log.
> > I would really like if that format be the same as on other platforms
> > which use syslog.  It would have been easier for us to
> establish this
> > requirement for products within Cisco if we could just
> refer to syslog
> > message format RFC and it did not come with a baggage of having to
> > implement a syslog UDP transport, which may not be applicable.
> >
> > So, I am open on whether or not UDP binding is included in
> > -protocol or
> > outside.  But I would really prefer if it was not required.
>
> I agree on your general comments. In fact, that was one of the
> motivations of splitting -protocol. I think, however, that even if we
> specify a required transport mapping in -protocol itself,
> that does not
> necessarily prohibt this.
>
> I think you are talking about storage here. It seems natural that no
> transport is needed to store the message. I think the implementation
> requirement can be worded so that a minimal transport mapping
> needs only
> to be implemented if the program actually uses a transport.
>
> Besides that, I think you can always say that "the format
> must adhere to
> RFCxxxx, section 4." - that should leave out any ambiguity.
>
> I will comment on the other issue in a summary mail I am right now
> preparing.
>
> Rainer
>
>
>
>
>

------------------------------

Date: Fri, 6 Feb 2004 21:33:40 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol: transport mappings

I think this again is a good wake-up call. After all, here in this
group, we are talking about on-the wire protocols and specifications. In
the light of this, a "syslog-storage" RFC is something that inherently
is out of scope for IETF, as there is no communication involved.

Anyhow, I think the message format description is flexible enough to
even accomodate such secondary use cases. But they MUST not influence
tradeoff decisions in designing the on-the-wire protocol.

I think the discussion was very useful. And every vendor is still free
to use the same format for other purposes. Its just not a priority for
this group here.

Rainer

> -----Original Message-----
> From: Harrington, David [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 9:26 PM
> To: Rainer Gerhards; Anton Okmianski; [email-masked]
> Subject: RE: -protocol: transport mappings
>
> Hi,
>
> Comments inline.
>
> *snip*
>
> > > 2.  I think requiring UDP implementation reduces the
> areas in which
> > > syslog message format RFC could be utilized.  I can see
> > many different
> > > areas.  For example, if RFC came without UDP baggage, we,
> > > within Cisco,
> > > could potentially standardize on this format for products
> > which write
> > > directly to log file (no syslog servers) should be
> > compatible with the
> > > format.  This would be a great thing for us to be able to have a
> > > consistent format regardless of whether or not syslog
> > > transport is used
> > > because it is inevitable that some products will use syslog
> > and other
> > > will write straight to file.
>
> Any vendor can choose to develop supplementary uses for the syslog
> message format without being forced to implement UDP. If they
> choose not
> to implement the UDP transport, then the only thing this affects is
>
> 1) whether the vendor can honestly claim in their marketing that their
> implementaion is fully compliant to the syslog standard,
>
> 2) and whether they can honestly market their proprietary logging
> products as being fully compliant to the syslog standard.
>
> Syslog is not being written with an interface to on-the-box storage or
> with interfaces to other logging mechanisms. It is not being developed
> to best meet the needs of marketing. It is being written as
> an IETF (the
> I stands for Internet) protocol to standardize the on-the-wire format
> for interoperability over IP between implementations from multiple
> implementors.
>
> There is no reason to not specify UDP (or whichever IP protocol) as a
> standard transport just to accommodate a vendor's "potential"
> usage that
> is totally out of scope for this WG, and is out of scope for
> the IETF in
> general.
>
> My $.02
> dbh
>
>
> > >
> > > Another use case I have is writing log messages into Windows
> > > Event Log.
> > > I would really like if that format be the same as on
> other platforms
> > > which use syslog.  It would have been easier for us to
> > establish this
> > > requirement for products within Cisco if we could just
> > refer to syslog
> > > message format RFC and it did not come with a baggage of having to
> > > implement a syslog UDP transport, which may not be applicable.
> > >
> > > So, I am open on whether or not UDP binding is included in
> > > -protocol or
> > > outside.  But I would really prefer if it was not required.
> >
> > I agree on your general comments. In fact, that was one of the
> > motivations of splitting -protocol. I think, however, that
> even if we
> > specify a required transport mapping in -protocol itself,
> > that does not
> > necessarily prohibt this.
> >
> > I think you are talking about storage here. It seems natural that no
> > transport is needed to store the message. I think the implementation
> > requirement can be worded so that a minimal transport mapping
> > needs only
> > to be implemented if the program actually uses a transport.
> >
> > Besides that, I think you can always say that "the format
> > must adhere to
> > RFCxxxx, section 4." - that should leave out any ambiguity.
> >
> > I will comment on the other issue in a summary mail I am right now
> > preparing.
> >
> > Rainer
> >
> >
> >
> >
> >
>

------------------------------

Date: Fri, 6 Feb 2004 21:17:36 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol: transport mappings

> > Given that state of the discussion, I propose that we
> actually require
> > each implementation that talks to a transport MUST support the
> > to-be-written UDP transport mapping.
>
> I disagree with this on principle. This "that talks to a transport"
> crappy-little-rule is being done to accommodate a vendor-specific
> implementation issue. It has nothing to do with the
> on-the-wire standard
> we are developing. It has no place in the standard.

Good point. Do you agree on:

Given that state of the discussion, I propose that we require each
implementation MUST support the to-be-written UDP transport mapping.

Everybody is free to use the format when not talking to someone else.
After all, this is not really of our protocol business.

Thanks for keeping my on-track :)

Rainer

------------------------------

Date: Fri, 6 Feb 2004 15:07:58 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol: transport mappings

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 11:28 AM
> To: [email-masked]
> Subject: RE: -protocol: transport mappings
>
>
> Given that state of the discussion, I propose that we actually require
> each implementation that talks to a transport MUST support the
> to-be-written UDP transport mapping.

I disagree with this on principle. This "that talks to a transport"
crappy-little-rule is being done to accommodate a vendor-specific
implementation issue. It has nothing to do with the on-the-wire standard
we are developing. It has no place in the standard.

>
> I would appreciate if those experienced with these issues could let me
> know their qualified votes.

We don't vote in the IETF, but I'd be willing to hum for a separate
document ;-)

Seriously, as long as the document is not likely to get bogged down in
tar-pit discussions, it is unlikely to hold up progress of documents
that depend on it. Since it appears to be a very simple and
straightforward document, I expect it would have no impact on the
advancement of the -protocol document.

Dbh

------------------------------

Date: Fri, 6 Feb 2004 22:01:48 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

> I have a concern about making C-compatibility a requirement of
> -protocol. I understand the concern about the amount of work
> implementors may need to do, and it spotential impact on adoption.
> However, I think this is a red herring.

I know that we do not discuss progamming languages here in the IETF. I
hope I will be granted a quick exception because it is hard to otherwise
show the importance of this point.

One primary thing we need to keep in mind is that most syslog code today
is written in C and I guess that this will be the case for quite some
time. So it may be worth taking a closer look at it...

> All an implementor
> has to do is
> put in one piece of code that looks at the incoming message and looks
> for 0x00 octets, if they care, and handle however they choose in their
> implementation.

Actually, this is the issue. It is *not* easy to do this. It requires
architectural change to the application and even requires that the
normal run time library can NOT be used.

Why that? We are talking about Unicode. As such, all octet values are
defined, there is no single octet value that the 0x00 could be mapped
to. It can also not be mapped to a multi-byte sequence, because they,
too, are all taken up by the "normal" encodings. So in order to support
this in C, you must do either one of these:

A) extend the character size, e.g. use not 16 or 32 bit for the
character but 24 or 40. This gives you room for the extra "flag bit" to
escape the 0x00 value.
B) use (or write) a non-standard string library, that handles strings
based on a byte counter (as Java and hopefully C# does)

I think A) is an totally impractical approach. B) works, but requires
complete re-design of (most) existing applications. It also forces
developers to use a non-standard (but more secure!) approach. In the C
community, there is a lot of objection to byte-counted strings. This
alone can cause some acceptance problems.

Then, some other systems/tools that are written in C may also misbehave
if they have to deal with 0x00 characters. I think a number of *nix
system tools qualifies as victims. I have no idea about PERL, but I have
a weak feeling that it may have problems handling 0x00 inside strings,
too. If that would be the case, that would be bad, too, because a lot of
administrators use PERL to analyze their logs (just think about SWATCH).

Granted, this is a programming issue - and parts of it are not even
related to on-the-wire protocol.

I wouldn't care if the 0x00 could have *any* legitimate use. But is has
NOT. I can hardly envision any legitimate use for 0x00 inside a message.
For UTF-8, it is not needed (it is in the reserved US-ASCII pane). In
US-ASCII, it is traditionally a) the C string terminator and b) a
fill-character (NUL), thrown in a string to give a slow tty time to
catch up (eg after receiving a CR character) - remember those devices
connected at 110 baud ;). So why should it be in a syslog message? It
traditionally was never seen in syslog nor in any other message text.

Besides that, 0x00 has a prooven track record in causing security issues
(of course, all boiling down to the "smart" C string handling, which is
another issue in itself...).

So this is my point: we know that 0x00 potentially causes security
troubles, causes big implementation issues, costs us acceptance - and we
can't find a legit use for it. On the other hand (in my point of view),
we have the point that allowing 0x00 is cleaner and less crippled.

If I weight both of the arguments, I come to the conclusion that it may
be better to disallow 0x00, as it may not be as clean but has some
obvious advantages...

Rainer

------------------------------

Date: Fri, 6 Feb 2004 17:33:58 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

Rainer:

It is a tough one.  You almost convinced me.  But you talk about server
implementation's side only. What about client's side?

If I write a Java client and 0x00 is a prohibited character, do you
think I will have to scan each string passed to me to make sure it does
not include 0x00?  It would seem like an unnecessary overhead. And then
what should the client library do if it does get one?

We might be trading ease of writing a server for ease of writing a
client here.

I don't know why somebody would pass 0x00 character to a logging
library, but as a library writer, this is not my job to decide.  I just
have to ensure compliancy with standard, right?

Have a good weekend everyone!

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Friday, February 06, 2004 4:02 PM
> To: Harrington, David; [email-masked]
> Subject: RE: -international: trailer
>
>
> > I have a concern about making C-compatibility a requirement of
> > -protocol. I understand the concern about the amount of work
> > implementors may need to do, and it spotential impact on adoption.
> > However, I think this is a red herring.
>
> I know that we do not discuss progamming languages here in
> the IETF. I hope I will be granted a quick exception because
> it is hard to otherwise show the importance of this point.
>
> One primary thing we need to keep in mind is that most syslog
> code today is written in C and I guess that this will be the
> case for quite some time. So it may be worth taking a closer
> look at it...
>
> > All an implementor
> > has to do is
> > put in one piece of code that looks at the incoming message
> and looks
> > for 0x00 octets, if they care, and handle however they
> choose in their
> > implementation.
>
> Actually, this is the issue. It is *not* easy to do this. It
> requires architectural change to the application and even
> requires that the normal run time library can NOT be used.
>
> Why that? We are talking about Unicode. As such, all octet
> values are defined, there is no single octet value that the
> 0x00 could be mapped to. It can also not be mapped to a
> multi-byte sequence, because they, too, are all taken up by
> the "normal" encodings. So in order to support this in C, you
> must do either one of these:
>
> A) extend the character size, e.g. use not 16 or 32 bit for
> the character but 24 or 40. This gives you room for the extra
> "flag bit" to escape the 0x00 value.
> B) use (or write) a non-standard string library, that handles
> strings based on a byte counter (as Java and hopefully C# does)
>
> I think A) is an totally impractical approach. B) works, but
> requires complete re-design of (most) existing applications.
> It also forces developers to use a non-standard (but more
> secure!) approach. In the C community, there is a lot of
> objection to byte-counted strings. This alone can cause some
> acceptance problems.
>
> Then, some other systems/tools that are written in C may also
> misbehave if they have to deal with 0x00 characters. I think
> a number of *nix system tools qualifies as victims. I have no
> idea about PERL, but I have a weak feeling that it may have
> problems handling 0x00 inside strings, too. If that would be
> the case, that would be bad, too, because a lot of
> administrators use PERL to analyze their logs (just think
> about SWATCH).
>
> Granted, this is a programming issue - and parts of it are
> not even related to on-the-wire protocol.
>
> I wouldn't care if the 0x00 could have *any* legitimate use.
> But is has NOT. I can hardly envision any legitimate use for
> 0x00 inside a message. For UTF-8, it is not needed (it is in
> the reserved US-ASCII pane). In US-ASCII, it is traditionally
> a) the C string terminator and b) a fill-character (NUL),
> thrown in a string to give a slow tty time to catch up (eg
> after receiving a CR character) - remember those devices
> connected at 110 baud ;). So why should it be in a syslog
> message? It traditionally was never seen in syslog nor in any
> other message text.
>
> Besides that, 0x00 has a prooven track record in causing
> security issues (of course, all boiling down to the "smart" C
> string handling, which is another issue in itself...).
>
> So this is my point: we know that 0x00 potentially causes
> security troubles, causes big implementation issues, costs us
> acceptance - and we can't find a legit use for it. On the
> other hand (in my point of view), we have the point that
> allowing 0x00 is cleaner and less crippled.
>
> If I weight both of the arguments, I come to the conclusion
> that it may be better to disallow 0x00, as it may not be as
> clean but has some obvious advantages...
>
> Rainer
>
>

------------------------------

Date: Fri, 6 Feb 2004 18:31:34 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol: transport mappings

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
>
> Given that state of the discussion, I propose that we require each
> implementation MUST support the to-be-written UDP transport mapping.
>
> Everybody is free to use the format when not talking to someone else.
> After all, this is not really of our protocol business.
>
I agree that each implementation must support the to-be-written UDP
transport mapping to claim compliance to the standard.

dbh

------------------------------

Date: Sun, 8 Feb 2004 12:48:50 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

>Let me phrase my question rather bluntly: does it pay to provide a very
>minimal set of config settings given the fact that almost every vendor
>has very different ways to do this. Also, in my experience customers
>tend to use those vendor-specifc ways, simply because they need it. To
>be honest, I think we will be hesitant to implement standard
>configuration simply because I do not see any customer demand for such.
>I think we can put our ressources to efforts that receive a higher
>demand.
>
>It may just be my personal feeling ... what do the other implementors
>think?
>
>Rainer

Having a minimum set of configuration options would probably be a waste
of time in my view as all implementations are so different.

Since all implementations use (or can be made to use) a config file, my
vote is for a free form string variable. The format of the text depends
on the vendor. All we need to agree on is a standard cookie to identify
the vendor and version.

Regards

Andrew

------------------------------

Date: Sun, 8 Feb 2004 12:52:25 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: -international: trailer

It is not just the 0x00 that we have to worry about. For TCP transport
mappings, we need to have a stream delimiter. Currently it is generally
agreed that it is LF (0x0A). If we don't escape that character, we will
have to resort to a byte length field. Please don't make me have to drag
out my old Syslog over TCP proposal :-)

Cheers

Andrew

------------------------------

Date: Sun, 08 Feb 2004 15:21:05 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: SyslogMIB Issue-#4  // Issue-#2

Andrew Ross wrote:

> Having a minimum set of configuration options would probably be a waste
> of time in my view as all implementations are so different.
>
> Since all implementations use (or can be made to use) a config file, my
> vote is for a free form string variable. The format of the text depends
> on the vendor. All we need to agree on is a standard cookie to identify
> the vendor and version.
>
This makes sense.

If I have heard and understood correctly - we would love to have configuration
options - BUT given the diversity of the syslog implementations we do not have
one model for configuration that would allow us to develop a one-size-fits-all
MIB.
However there is the trivial model - which uses the configuration file to hide
all the implementation details. This model probably fits all implementation.

That would mean  -
     A. We remove the configuration details
     B. We introduce a configuration file object. Here we have two choices
        B-1. Just leave it at the fileName level of detail-  The fileName is
             writable
             Manager will set the syslogConf file name and expect that to
             be used. We have 1 MO in this case.
             Comment: This is simple. The manager aranges for the syslogConf
             to be present (by non-SNMP means) and just tells the syslog process
             to use the specific syslogConf file.
        B-2. Treat the file as a text file with one or more lines.
             Represent the file as a table: a row is a line.
             The semantics or syntax of the file is opaque to management process.
             It can read the file and display it on the console (using SNMP).
             For update of the file:  allow lines to be modified (using SNMP-Set)

             Comment: This is much more complex. To do this nicely we will effectively
             need a text file editor to be implemented using SNMP.

     C. At a later date, if there is interest and demand, we can have a
        BSD-Syslog configuration MIB where the parts removed from A can be
        used.
        I liked what it was doing- it is pretty good and useful when I want
        to remote-monitor (not control) the configuration of the syslog process.

Let me have your comments.

Cheers

Glenn

------------------------------

Date: Mon, 9 Feb 2004 10:48:09 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

Glenn,

Good summary of the options.

If we are going to have a remote SNMP config system, then I vote for
B-2.

Just specifying a local filename to load (option B-1) still requires us
to get the file to the remote system somehow.

My intention is to have an app that takes a text file, convert it into
SNMP format and send it to the remote syslog. If the config was
accepted, we get an ACK response, otherwise we get an error response.

With Kiwi Syslog and WinSyslog, the config file is not created or edited
by the user. It is a file created by the app in INI or XML type format.
It is possible that the user could edit it, but not recommended. The
program properties are set from within the GUI app, then the config file
is created from the settings.

With Syslog-ng and SDSC etc, the config files are human
readable/editable. So a simple SNMP-SET type command line app that sends
a text config file would be a good choice here.

Rainer, does that that work for you?

Cheers

Andrew

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Glenn Mansfield
Keeni
Sent: Sunday, 8 February 2004 7:21 p.m.
To: [email-masked]
Subject: Re: SyslogMIB Issue-#4 // Issue-#2

Andrew Ross wrote:

> Having a minimum set of configuration options would probably be a
waste
> of time in my view as all implementations are so different.
>
> Since all implementations use (or can be made to use) a config file,
my
> vote is for a free form string variable. The format of the text
depends
> on the vendor. All we need to agree on is a standard cookie to
identify
> the vendor and version.
>
This makes sense.

If I have heard and understood correctly - we would love to have
configuration
options - BUT given the diversity of the syslog implementations we do
not have
one model for configuration that would allow us to develop a
one-size-fits-all
MIB.
However there is the trivial model - which uses the configuration file
to hide
all the implementation details. This model probably fits all
implementation.

That would mean  -
     A. We remove the configuration details
     B. We introduce a configuration file object. Here we have two
choices
        B-1. Just leave it at the fileName level of detail-  The
fileName is
             writable
             Manager will set the syslogConf file name and expect that
to
             be used. We have 1 MO in this case.
             Comment: This is simple. The manager aranges for the
syslogConf
             to be present (by non-SNMP means) and just tells the syslog
process
             to use the specific syslogConf file.
        B-2. Treat the file as a text file with one or more lines.
             Represent the file as a table: a row is a line.
             The semantics or syntax of the file is opaque to management
process.
             It can read the file and display it on the console (using
SNMP).
             For update of the file:  allow lines to be modified (using
SNMP-Set)

             Comment: This is much more complex. To do this nicely we
will effectively
             need a text file editor to be implemented using SNMP.

     C. At a later date, if there is interest and demand, we can have a
        BSD-Syslog configuration MIB where the parts removed from A can
be
        used.
        I liked what it was doing- it is pretty good and useful when I
want
        to remote-monitor (not control) the configuration of the syslog
process.

Let me have your comments.

Cheers

Glenn

------------------------------

Date: Sun, 8 Feb 2004 13:35:23 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

Hi,

Rather than reinventing wheels, let's try to review work that has
already been done in the IETF for these purposes, and discuss any
experience that has already been had with these approaches. Please look
at the RFC3165 Script MIB
(ftp://ftp.rfc-editor.org/in-notes/rfc3165.txt) and the NETCONF work
(http://www.ietf.org/html.charters/netconf-charter.html).

The Script MIB is all about uploading/downloading scripts to execute on
a managed device. It is language-independent, but recognizes the
likelihood of Java, Perl, and CLI scripts.
This MIB has an (optional) on-line editing capability, which experience
has shown few operators want to use; they would rather get the script,
modify it offline, and send it back to the device.

The NETCONF work is trying to make it possible to download/upload script
files for configuring devices, as a way to standardize CLI scripting.

dbh

> -----Original Message-----
> From: Glenn Mansfield Keeni [mailto:[email-masked]]
> Sent: Sunday, February 08, 2004 1:21 AM
> To: [email-masked]
> Subject: Re: SyslogMIB Issue-#4 // Issue-#2
>
> Andrew Ross wrote:
>
> > Having a minimum set of configuration options would
> probably be a waste
> > of time in my view as all implementations are so different.
> >
> > Since all implementations use (or can be made to use) a
> config file, my
> > vote is for a free form string variable. The format of the
> text depends
> > on the vendor. All we need to agree on is a standard cookie
> to identify
> > the vendor and version.
> >
> This makes sense.
>
> If I have heard and understood correctly - we would love to
> have configuration
> options - BUT given the diversity of the syslog
> implementations we do not have
> one model for configuration that would allow us to develop a
> one-size-fits-all
> MIB.
> However there is the trivial model - which uses the
> configuration file to hide
> all the implementation details. This model probably fits all
> implementation.
>
> That would mean  -
>      A. We remove the configuration details
>      B. We introduce a configuration file object. Here we
> have two choices
>         B-1. Just leave it at the fileName level of detail-
> The fileName is
>              writable
>              Manager will set the syslogConf file name and
> expect that to
>              be used. We have 1 MO in this case.
>              Comment: This is simple. The manager aranges for
> the syslogConf
>              to be present (by non-SNMP means) and just tells
> the syslog process
>              to use the specific syslogConf file.
>         B-2. Treat the file as a text file with one or more lines.
>              Represent the file as a table: a row is a line.
>              The semantics or syntax of the file is opaque to
> management process.
>              It can read the file and display it on the
> console (using SNMP).
>              For update of the file:  allow lines to be
> modified (using SNMP-Set)
>
>              Comment: This is much more complex. To do this
> nicely we will effectively
>              need a text file editor to be implemented using SNMP.
>
>      C. At a later date, if there is interest and demand, we
> can have a
>         BSD-Syslog configuration MIB where the parts removed
> from A can be
>         used.
>         I liked what it was doing- it is pretty good and
> useful when I want
>         to remote-monitor (not control) the configuration of
> the syslog process.
>
> Let me have your comments.
>
> Cheers
>
> Glenn
>
>
>
>
>
>

------------------------------

Date: Mon, 09 Feb 2004 15:12:26 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: SyslogMIB Issue-#4  // Issue-#2

Dave,
Harrington, David wrote:
> Hi,
>
> Rather than reinventing wheels, let's try to review work that has
> already been done in the IETF for these purposes, and discuss any
> experience that has already been had with these approaches. Please look
> at the RFC3165 Script MIB
I fully agree.
> (ftp://ftp.rfc-editor.org/in-notes/rfc3165.txt) and the NETCONF work
> (http://www.ietf.org/html.charters/netconf-charter.html)
>
> The Script MIB is all about uploading/downloading scripts to execute on
> a managed device. It is language-independent, but recognizes the
> likelihood of Java, Perl, and CLI scripts.
> This MIB has an (optional) on-line editing capability, which experience
> has shown few operators want to use; they would rather get the script,
> modify it offline, and send it back to the device.
I am aware of the ScriptMIB. If we do design a configuration-download/upload
MIB we will certainly refer to and use the mechanisms used in RFC3165.

I am still trying to figure out whether we can use the scriptMIB itself
without defining any new Tables. It is all there .. we have to pretend that
the syslogConf is a script that is interpreted by the syslog process.
There does not seem to be any problem - but the compilance requirements may
be a bother- I need to look at the RFC to figure out before I can really
propose to use theScriptMIB.
>
> The NETCONF work is trying to make it possible to download/upload script
> files for configuring devices, as a way to standardize CLI scripting.
>
> dbh

Cheers

Glenn

------------------------------

Date: Mon, 9 Feb 2004 15:55:11 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

> From: Harrington, David [mailto:[email-masked]]
> Rather than reinventing wheels, let's try to review work that has
> already been done in the IETF for these purposes, and discuss any
> experience that has already been had with these approaches.
> Please look
> at the RFC3165 Script MIB
> (ftp://ftp.rfc-editor.org/in-notes/rfc3165.txt) and the NETCONF work
> (http://www.ietf.org/html.charters/netconf-charter.html).

That sounds like the thing to do for me. FC31655 MIB sounds much like
the proposed "B2" option.

I didn't have time to look at netconf in particular, but probably this
is a better route to take. I think the overall idea behind a standard
MIB is the ability to configure important base parameters in a
vendor-ignorant way. If we go ahead and upload config files, this is not
vendor-irgnorant. So I doubt that this is actually that useful in regard
to what the original idea was (I may be wrong here).

This brings me to the point of questioning if it really makes sense to
try to include that functionality in syslog-mib. Maybe it would be
better to take it off (simplyfying things), look if netconf or 3165
works and after some time-revaluate syslog-mib usage? I have the
impression that can save us a lot of time without loosing much. But
again, I have to say I am not very deep inside SNMP issues ;)

>
> The Script MIB is all about uploading/downloading scripts to
> execute on
> a managed device. It is language-independent, but recognizes the
> likelihood of Java, Perl, and CLI scripts.
> This MIB has an (optional) on-line editing capability, which
> experience
> has shown few operators want to use; they would rather get the script,
> modify it offline, and send it back to the device.

generally speaking, my own experience is the same. Operators love to
edit files which whatever prefrerred editor they have. Hard to believe
the will use another one. The only important feature is an import/export
of all the config file lines.
>
> The NETCONF work is trying to make it possible to
> download/upload script
> files for configuring devices, as a way to standardize CLI scripting.

That sounds useful.

Rainer

------------------------------

Date: Mon, 9 Feb 2004 15:47:21 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

This is a reply to a direct question - general comment following with
other reply.

> With Kiwi Syslog and WinSyslog, the config file is not
> created or edited
> by the user.

Just FYI: we (WinSyslog & similar products) are heading towards either
human-readable config file or skilled-human-readable, XML-based config
file in the long to medium term. Probably the later.

> Rainer, does that that work for you?

Yes, it does.

Rainer

------------------------------

Date: Mon, 9 Feb 2004 18:35:34 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol open issues

Hi WG,

I am coming back to the enterprise ID. Anton posted his opinion 5 days
ago. Besides my "not sure" reply
(http://www.syslog.cc/ietf/autoarc/msg01052.html), we got no response so
far.

Given the otherwise healthy discussion, I assume this is not a priority
for the WG. So I will remove the enterprise ID for -protocol-03 if
nobody speaks up (we can always get it back in at a later time). If
someone sees good reasons to have it in, I would appreciate comments now
;)

Thanks,
Rainer

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Wednesday, February 04, 2004 7:20 PM
> To: Rainer Gerhards; [email-masked]
> Subject: RE: -protocol open issues
>
> On issue #7 - enterprise ID:
>
> I am relatively neutral to this idea. But I am trying to
> understand how
> it will be used. What are the anticipated use cases for it?
>
> If we want to use it to differentiate messages from a specific vendor
> because it may provide some additional formatting, then one could also
> argue that we also need vendor version and potentially vendor product
> and on and on.
>
> If we do provide enterprise ID, does it have to be required and in the
> header as opposed to structured content?  Is filtering on vendor going
> to be a common use-case?
>
> One area of ambiguity, I think, is a situation where components are
> integrated into other applications.  Say component X from one
> company is
> integrated into product Y of another company.  Component X
> already does
> -protocol compliant syslog logging. Which enterprise ID should it use?
> Should we leave this as nondeterministic or provide recommendations?
>
> Another area of potential ambiguity is relaying. Suppose a
> relay gets a
> bad message from a Cisco device and needs to fire a diagnostic error
> message.  Does it use its own enterprise ID for this?  If so, my
> collector which catches messages only for vendor Cisco won't
> catch this,
> right?
>
> Anton.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> > Sent: Wednesday, February 04, 2004 9:36 AM
> > To: [email-masked]
> > Subject: -protocol open issues
> >
> >
> > Hi WG,
> >
> > I have updated my page of open issues in -protocol. I would
> > appreciate if you could comment on the open issues. They can
> > be found here:
> >
> http://www.syslog.cc/ietf/protocol.html
>
> Please note that these are just the issues which have definitely been
> identified. Others are lurking around, so I will add them
> when they are
> discovered ("other things to do" beneath the issues may provide an
> idea). I try to solve those issues before creating new ones, just so
> that it is easier to keep track and stay focussed.
>
> Any feedback is highly appreciated.
>
> Rainer
>
>
>

------------------------------

Date: Tue, 10 Feb 2004 18:15:09 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

Hi All,

I am a bit sad that I use Andrew's message to say this... but Andrew has
just made an important point that enlightens me on David's thought that
those CLRs  (crappy little rules [I like this term]) really cause
trouble. So Andrew please don't take my objection personally, I see your
reasoning behind it...

... but this is an excellent sample on how granting one exception (the
0x00 case) leads to calls for further exceptions (0x0a in this case). I
have to admit I didn't think well enough about this.

Also, I was technically incorrect in insisting on 0x00 to be too hard
for C. Actually, I worked out a surprisingly easy, obvious and
well-known escaping mechanism to handle 0x00 once the message is
received. It looks like I was just too narrow-minded to think with an
open enough mind to solve it. Thanks to all who kept pushing me :)

But, honestly, even if I would not see an easy solution for the C case,
I think we should follow David's advise and avoid any such rules (like
the 0x00 exception). In the long term, they cause more trouble in the
long term than the solve initially.

So I, too, now vote that we must support any valid UTF-8 sequence in the
MSG part, which includes 0x00. If nobody objects, I will change
- -protocol to specify this. If you have objections, I would appreciate if
you could reply relatively quickly, as I try to get -03 out before
Seoul.

Now let me come to the C implementation and other things, like syslog
storage format. As we have discussed on this list, these things are - at
least at first look - not relevant to IETF work. This is because they
simply don't talk about on-the-wire protocols. And only this is scope of
the IETF. Anyhow, it would definitely be a positive undertaking to reach
concensus among implementors how those things should be addressed. To
have a "least common denominator approach" that customers could expect
to be in syslog products they purchase/use. Even for the implementors
among us, such an approach would simplify things when it comes to the
parsing and analysis stage.

I have talked to Chris as well as Tina Bird, who is the moderator of the
loganalysis mailing list
(http://lists.shmoo.com/mailman/listinfo/loganalysis). We have agreed
that we can move discussion for non-IETF topics over to loganalysis. The
big plus in this is that there are also many, many administrators on the
list, so we will most probably get a lot of feedback from the end user
camp, too. I think this is extremely valuable.

I plan, however, to focus just some few days on -protocol and not
directly start this other discussion. I think this serves our deadlines
(Seoul meeting) better than doing too much in parallel. After that, I
plan to post an initial message for those topics on the loganalysis
list. If Chris permits, I would cross-post these message here to the WG
list (together with my whish to only reply to loganalysis;)).

I hope this is a good proposal, one that will allow us to make syslog
even more interoperable than it is today.

Rainer

> -----Original Message-----
> From: Andrew Ross [mailto:[email-masked]]
> Sent: Sunday, February 08, 2004 12:52 AM
> To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> [email-masked]
> Subject: RE: -international: trailer
>
>
> It is not just the 0x00 that we have to worry about. For TCP transport
> mappings, we need to have a stream delimiter. Currently it is
> generally
> agreed that it is LF (0x0A). If we don't escape that
> character, we will
> have to resort to a byte length field. Please don't make me
> have to drag
> out my old Syslog over TCP proposal :-)
>
> Cheers
>
> Andrew
>
>
>

------------------------------

Date: Tue, 10 Feb 2004 14:38:14 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

Rainer:

I am really struggling with that restriction not to standardize syslog
storage in IETF.  It diminishes the value of the syslog protocol as
people can't write a standard syslog parser.

It would be nice if we could find another standards body which could be
used to address that aspect. I assume log analysis mailing list is not
affiliated with a standards body, or is it? I wonder if there is good
precedent out there of two standards bodies working in tandem like this.
Maybe W3C?

Somebody suggested to me an idea that maybe a bit wild, but could
address this.  A protocol for syslog server to return messages it has
stored.  It could be UDP-based. How much less efficient would that be
than reading a file?  I don't think the difference will be huge as I/O
will likely be the bigger bottleneck anyway.   Essentially, the messages
could be returned using the same -protocol & -transport and we just need
to add some request/response semantics.  This does sound pretty wild,
but desperate times call for desperate measures :) and I thought I would
just pass it along.

Anton.

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 12:15 PM
> To: Andrew Ross; Harrington, David; Anton Okmianski;
> [email-masked]
> Subject: RE: -international: trailer
>
>
> Hi All,
>
> I am a bit sad that I use Andrew's message to say this... but
> Andrew has just made an important point that enlightens me on
> David's thought that those CLRs  (crappy little rules [I like
> this term]) really cause trouble. So Andrew please don't take
> my objection personally, I see your reasoning behind it...
>
> ... but this is an excellent sample on how granting one
> exception (the 0x00 case) leads to calls for further
> exceptions (0x0a in this case). I have to admit I didn't
> think well enough about this.
>
> Also, I was technically incorrect in insisting on 0x00 to be
> too hard for C. Actually, I worked out a surprisingly easy,
> obvious and well-known escaping mechanism to handle 0x00 once
> the message is received. It looks like I was just too
> narrow-minded to think with an open enough mind to solve it.
> Thanks to all who kept pushing me :)
>
> But, honestly, even if I would not see an easy solution for
> the C case, I think we should follow David's advise and avoid
> any such rules (like the 0x00 exception). In the long term,
> they cause more trouble in the long term than the solve initially.
>
> So I, too, now vote that we must support any valid UTF-8
> sequence in the MSG part, which includes 0x00. If nobody
> objects, I will change -protocol to specify this. If you have
> objections, I would appreciate if you could reply relatively
> quickly, as I try to get -03 out before Seoul.
>
> Now let me come to the C implementation and other things,
> like syslog storage format. As we have discussed on this
> list, these things are - at least at first look - not
> relevant to IETF work. This is because they simply don't talk
> about on-the-wire protocols. And only this is scope of the
> IETF. Anyhow, it would definitely be a positive undertaking
> to reach concensus among implementors how those things should
> be addressed. To have a "least common denominator approach"
> that customers could expect to be in syslog products they
> purchase/use. Even for the implementors among us, such an
> approach would simplify things when it comes to the parsing
> and analysis stage.
>
> I have talked to Chris as well as Tina Bird, who is the
> moderator of the loganalysis mailing list
> (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We
> have agreed that we can move discussion for
> non-IETF topics over to loganalysis. The big plus in this is
> that there are also many, many administrators on the list, so
> we will most probably get a lot of feedback from the end user
> camp, too. I think this is extremely valuable.
>
> I plan, however, to focus just some few days on -protocol and
> not directly start this other discussion. I think this serves
> our deadlines (Seoul meeting) better than doing too much in
> parallel. After that, I plan to post an initial message for
> those topics on the loganalysis list. If Chris permits, I
> would cross-post these message here to the WG list (together
> with my whish to only reply to loganalysis;)).
>
> I hope this is a good proposal, one that will allow us to
> make syslog even more interoperable than it is today.
>
> Rainer
>
> > -----Original Message-----
> > From: Andrew Ross [mailto:[email-masked]]
> > Sent: Sunday, February 08, 2004 12:52 AM
> > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> > [email-masked]
> > Subject: RE: -international: trailer
> >
> >
> > It is not just the 0x00 that we have to worry about. For
> TCP transport
> > mappings, we need to have a stream delimiter. Currently it is
> > generally agreed that it is LF (0x0A). If we don't escape that
> > character, we will
> > have to resort to a byte length field. Please don't make me
> > have to drag
> > out my old Syslog over TCP proposal :-)
> >
> > Cheers
> >
> > Andrew
> >
> >
> >
>

------------------------------

Date: Tue, 10 Feb 2004 15:59:08 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -international: trailer

Hi,

Comments inline

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
>> Subject: RE: -international: trailer
>
> Rainer:
>
> I am really struggling with that restriction not to standardize syslog
> storage in IETF.  It diminishes the value of the syslog protocol as
> people can't write a standard syslog parser.

I'm not sure I understand why you feel this. Assuming you are parsing
what was sent on the wire, that should be standard (to the degree that
we standardize it). How an implementation stores it after receipt is
implementation-dependent, and probably needs to consider the underlying
OS, the expected purposes of stored messages, the language used in the
implementation. These should not be of concern to us.

If you are interested in trying to standardize a post-storage parser,
there is no reason why the implementors cannot reach agreement on a
storage format and have it published in the IETF, but the
implementation-specific decisions should not affect the on-the-wire
designs.

>
> It would be nice if we could find another standards body
> which could be
> used to address that aspect. I assume log analysis mailing list is not
> affiliated with a standards body, or is it? I wonder if there is good
> precedent out there of two standards bodies working in tandem
> like this.
> Maybe W3C?

If you reach agreement and publish an informational RFC, you may be able
to convince the WG/IETF to put it on the standards track, if you can
show that it would help the industry.
>
> Somebody suggested to me an idea that maybe a bit wild, but could
> address this.  A protocol for syslog server to return messages it has
> stored.  It could be UDP-based. How much less efficient would that be
> than reading a file?  I don't think the difference will be huge as I/O
> will likely be the bigger bottleneck anyway.   Essentially,
> the messages
> could be returned using the same -protocol & -transport and
> we just need
> to add some request/response semantics.  This does sound pretty wild,
> but desperate times call for desperate measures :) and I
> thought I would
> just pass it along.

Let's not try to create a protocol just to standardzie something not
directly related to the internet. If you want to develop a parser and
have the parser accepted as a "standard" why don't you just develop it
as open source, say, on sourceforge? If everybody uses it, it will
become a defacto standard. You don't need to make it an IETF standard.

>
> Anton.
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Tuesday, February 10, 2004 12:15 PM
> > To: Andrew Ross; Harrington, David; Anton Okmianski;
> > [email-masked]
> > Subject: RE: -international: trailer
> >
> >
> > Hi All,
> >
> > I am a bit sad that I use Andrew's message to say this... but
> > Andrew has just made an important point that enlightens me on
> > David's thought that those CLRs  (crappy little rules [I like
> > this term]) really cause trouble. So Andrew please don't take
> > my objection personally, I see your reasoning behind it...
> >
> > ... but this is an excellent sample on how granting one
> > exception (the 0x00 case) leads to calls for further
> > exceptions (0x0a in this case). I have to admit I didn't
> > think well enough about this.
> >
> > Also, I was technically incorrect in insisting on 0x00 to be
> > too hard for C. Actually, I worked out a surprisingly easy,
> > obvious and well-known escaping mechanism to handle 0x00 once
> > the message is received. It looks like I was just too
> > narrow-minded to think with an open enough mind to solve it.
> > Thanks to all who kept pushing me :)
> >
> > But, honestly, even if I would not see an easy solution for
> > the C case, I think we should follow David's advise and avoid
> > any such rules (like the 0x00 exception). In the long term,
> > they cause more trouble in the long term than the solve initially.
> >
> > So I, too, now vote that we must support any valid UTF-8
> > sequence in the MSG part, which includes 0x00. If nobody
> > objects, I will change -protocol to specify this. If you have
> > objections, I would appreciate if you could reply relatively
> > quickly, as I try to get -03 out before Seoul.
> >
> > Now let me come to the C implementation and other things,
> > like syslog storage format. As we have discussed on this
> > list, these things are - at least at first look - not
> > relevant to IETF work. This is because they simply don't talk
> > about on-the-wire protocols. And only this is scope of the
> > IETF. Anyhow, it would definitely be a positive undertaking
> > to reach concensus among implementors how those things should
> > be addressed. To have a "least common denominator approach"
> > that customers could expect to be in syslog products they
> > purchase/use. Even for the implementors among us, such an
> > approach would simplify things when it comes to the parsing
> > and analysis stage.
> >
> > I have talked to Chris as well as Tina Bird, who is the
> > moderator of the loganalysis mailing list
> > (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We
> > have agreed that we can move discussion for
> > non-IETF topics over to loganalysis. The big plus in this is
> > that there are also many, many administrators on the list, so
> > we will most probably get a lot of feedback from the end user
> > camp, too. I think this is extremely valuable.
> >
> > I plan, however, to focus just some few days on -protocol and
> > not directly start this other discussion. I think this serves
> > our deadlines (Seoul meeting) better than doing too much in
> > parallel. After that, I plan to post an initial message for
> > those topics on the loganalysis list. If Chris permits, I
> > would cross-post these message here to the WG list (together
> > with my whish to only reply to loganalysis;)).
> >
> > I hope this is a good proposal, one that will allow us to
> > make syslog even more interoperable than it is today.
> >
> > Rainer
> >
> > > -----Original Message-----
> > > From: Andrew Ross [mailto:[email-masked]]
> > > Sent: Sunday, February 08, 2004 12:52 AM
> > > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> > > [email-masked]
> > > Subject: RE: -international: trailer
> > >
> > >
> > > It is not just the 0x00 that we have to worry about. For
> > TCP transport
> > > mappings, we need to have a stream delimiter. Currently it is
> > > generally agreed that it is LF (0x0A). If we don't escape that
> > > character, we will
> > > have to resort to a byte length field. Please don't make me
> > > have to drag
> > > out my old Syslog over TCP proposal :-)
> > >
> > > Cheers
> > >
> > > Andrew
> > >
> > >
> > >
> >
>
>

------------------------------

Date: Tue, 10 Feb 2004 15:59:09 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: SyslogMIB Issue-#6

Hi,

Not sure if this ever got sent.

If you want to use a text-file style of config, then you really should consider the work being done in the netconf WG, which is working on exactly this issue.

They are working to standardize the environment for configuration, by defining a running config, a startup config, and candidate configs, a fairly common approach to doing script-based configuration. They are working closely with the operator community to ensure that what gets produced will meet the real needs of real operators. It would be a really really good thing if the work done in the syslog WG was compatible with the work being done there.

They are focusing only on the transport mechanisms, and the basic message format, not the data models for specific types of functionality to be configured. The script format is XML, so if this group wants to be compatbile with the netconf work (and many other efforts under way in the IETF) then defining a configuration data model in XML would be a good thing (tm).

That said, there is also a place for SNMP. There are statistics and state about syslog operations that would be good to monitor. As observed, a read-only mib may be adeqaute for this. There may also be a place for writable objects in a mib. SNMP is a good protocol for monitoring a small number of objects, or repeatedly monitoring the changes to dynamic objects. It is also good for modifying small parameters that affect operational behavior.

The netconf WG is developing a system for configuring a system top-to-bottom, not functionality by functionality, and it isn't being designed to be good for "tweaking" a system that has already been configured; you wouldn't want to reload a complete device configuration to disable one port temporarily. I recommend that the WG consider which type of configuration information will likely be set or retrieved in a bulk mode, and which will likely be modified in little messages.

Netconf will have a "get-config" command that retrieves a complete snapshot of a device's configuration, which would include the syslog ruleset, presumably. Since netconf is based on a TCP transport, this would be better for retrieving a large configuration of rules than trying to do it with SNMP packets over UDP. You should check whether they are supporting requesting or configuring a subset of information, like syslog, but I think they probably will. Their first priority is to focus on the complete system config and snapshot, since that is needed badly since SNMP and other protocols do poorly at that.

Some considerations for writable objects in a syslog client mib:
	enable/disable syslog
	change the server address
	change the frequency of reporting

Some considerations for writable objects in a syslog server mib:
	add a client

And so on. There are already a couple mibs that have been reviewed in this WG, and I'm sure there is other info that would be useful to have writable.

Now, let me point out that writable mibs are a pain, but the mib can be written with two different compliance clauses - one for implementations that support the writable objects, and another for implenetationsthat choose to only support read-only mode. This approach allows for vendors that want to make their systems easily configurable via SNMP, and allows for vendors who don't. For some vendors, all the configuration can probably be completed in a scripting manner at startup, while still permitting SNMP monitoring. Some vendors will want to provide the flexibility of changing operational parameters while the system is running, using an SNMP-based front-end, rather than being forced to use a scripting approach and having to reboot their system or restart their syslog operation.

My $.02 (or $.05 if we pay by word count ;-)
dbh

> -----Original Message-----
> From: Andrew Ross [mailto:[email-masked]]
> Sent: Saturday, January 31, 2004 4:59 PM
> To: 'Rainer Gerhards'
> Cc: [email-masked]; 'Glenn Mansfield Keeni'
> Subject: RE: SyslogMIB Issue-#6
>
>
> Cool.
>
> If we work on using a text file type config system, we will still need
> to work out an identifying format.
>
> Maybe something like...
>
> Syslog Config File
> Vendor: Company Syslog
> Version: x.x
>
> # This configures the rule set
> Rules...
>
> # This configures the inputs
> Inputs/Listeners
>
> Etc
>
> Any line beginning with a # is a comment.
>
> The first line "Syslog Config File" is the magic cookie. This
> ensures we
> have a valid config file type.
> The vendor line identifies the syslog daemon vendor.
> The version line identifies the version of the syslog daemon that the
> rule set / config refers to.
>
> Apart from that, it could all be free form text.
>
> Comments?
>
> Cheers
>
> Andrew
>
>
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Saturday, 31 January 2004 11:06 p.m.
> To: [email-masked]
> Subject: RE: SyslogMIB Issue-#6
>
>
> On the ipaq, thus brief...
>
> Yes, this would be fine with me.
>
>
> ----- Ursprüngliche Nachricht -----
>    >Von: "Andrew Ross"<[email-masked]>
>    >Gesendet: 31.01.04 00:09:09
>    >An: "'Rainer Gerhards'"<[email-masked]>,
> "'Glenn Mansfield
> Keeni'"<[email-masked]>,
> "[email-masked]"<[email-masked]>
>    >Betreff: RE: SyslogMIB Issue-#6
>    >
>    >
>    >I concur on this point. I think read only would be fine.
> The rules,
>    >filters and settings in the new syslog products are too different
> and
>    >complex to map into a generic SNMP system at this stage.
>    >
>    >The only possibility I can think of would be the ability
> to dump the
>    >rule set and configuration in the form of a text file. In
> this way,
> you
>    >would rely on the syslog daemon app to process the text
> and extract
>    >rules and settings from the file.
>    >
>    >Sort of a GetConfigFile and SetConfigFile system. The size of the
> file
>    >could be an issue.
>    >
>    >Since most syslogs out there (WinSyslog, Kiwi Syslog, SDSC,
> Syslog-ng
>    >etc) use a config file, or can be made to read from a config file,
> the
>    >get/set system might work. You would have to place a
> meaningful tag
> at
>    >the beginning of the file to identify the format etc.
>    >
>    >Would that work for you Rainer?
>    >
>    >Regards
>    >
>    >Andrew
>    >
>    >
>    >
>    >
>    >-----Original Message-----
>    >From: [email-masked]
>    >[mailto:[email-masked]] On Behalf Of
> Rainer Gerhards
>    >Sent: Saturday, 31 January 2004 3:20 a.m.
>    >To: Glenn Mansfield Keeni; [email-masked]
>    >Subject: RE: SyslogMIB Issue-#6
>    >
>    >
>    >Sorry for the late follow up...
>    >
>    >I am not sure if we really desire this. As of my knowledge, most
>    >existing syslogds have far more sophisticated rules than the stock
>    >syslogd implementtions with just filtering on facility
> and severity.
> And
>    >they have, because there is a customer demand.
>    >
>    >You now can argue that by providing the generic configuration way,
> an
>    >administrator can at least configure all devices (in a
> vendor-ignorant
>    >way) to some desired common basic configuration. I just doubt that
> this
>    >"basic configuration" would just be too limited to be actually
> useful
>    >for the administrator. So I am not sure if it is really worth
> putting
>    >this effort in....
>    >
>    >I have no strong opinion on this, though. But I am a bit
> on the "we
>    >should stick with read-only" side...
>    >
>    >Rainer
>    >
>    >> -----Original Message-----
>    >> From: Glenn Mansfield Keeni [mailto:[email-masked]]
>    >> Sent: Friday, January 16, 2004 10:49 AM
>    >> To: [email-masked]
>    >> Subject: SyslogMIB Issue-#6
>    >>
>    >> Issue #6. Configuration Stuff - should it be there ?
>    >>
>    >> If the MIB is made read-only we cannot use it for configuration
>    >> of syslog processes. That is a disadvantage if we wanted to
>    >> configure our syslog processes in the first place. Otherwise,
>    >> the consequences are
>    >>       - implementations would be simpler
>    >>       - security implications are lesser
>    >>       - passage through the IESG-review process may be smoother
> (?)
>    >>
>    >> So, do we want to be able to configure Syslog
> processes? Community
>    >> input is required here.
>    >>
>    >> Status: Waiting on community input
>    >
>    >
>    >
>    >
>    >
>    >
>
>
>
>
>
>

------------------------------

Date: Tue, 10 Feb 2004 15:40:05 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -international: trailer

Hi Rainer,

For achieving implementation standards, you could write an informational
document called an implementor's argeement, as part of this WG, assuming
you can get approval of the chairs and ADs. I would definitley recommend
it should only be done by the WG AFTER the work we are supposed to do
gets done.

Of course, you could also just publish an informational document without
going through the WG.

I'm not sure I want to monitor the loganalysis discussion on this list;
anybody that wants to follow it can go to the loganalysis list.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 12:15 PM
> To: Andrew Ross; Harrington, David; Anton Okmianski;
> [email-masked]
> Subject: RE: -international: trailer
>
> Hi All,
>
> I am a bit sad that I use Andrew's message to say this... but
> Andrew has
> just made an important point that enlightens me on David's
> thought that
> those CLRs  (crappy little rules [I like this term]) really cause
> trouble. So Andrew please don't take my objection personally,
> I see your
> reasoning behind it...
>
> ... but this is an excellent sample on how granting one exception (the
> 0x00 case) leads to calls for further exceptions (0x0a in
> this case). I
> have to admit I didn't think well enough about this.
>
> Also, I was technically incorrect in insisting on 0x00 to be too hard
> for C. Actually, I worked out a surprisingly easy, obvious and
> well-known escaping mechanism to handle 0x00 once the message is
> received. It looks like I was just too narrow-minded to think with an
> open enough mind to solve it. Thanks to all who kept pushing me :)
>
> But, honestly, even if I would not see an easy solution for
> the C case,
> I think we should follow David's advise and avoid any such rules (like
> the 0x00 exception). In the long term, they cause more trouble in the
> long term than the solve initially.
>
> So I, too, now vote that we must support any valid UTF-8
> sequence in the
> MSG part, which includes 0x00. If nobody objects, I will change
> -protocol to specify this. If you have objections, I would
> appreciate if
> you could reply relatively quickly, as I try to get -03 out before
> Seoul.
>
> Now let me come to the C implementation and other things, like syslog
> storage format. As we have discussed on this list, these
> things are - at
> least at first look - not relevant to IETF work. This is because they
> simply don't talk about on-the-wire protocols. And only this
> is scope of
> the IETF. Anyhow, it would definitely be a positive
> undertaking to reach
> concensus among implementors how those things should be addressed. To
> have a "least common denominator approach" that customers could expect
> to be in syslog products they purchase/use. Even for the implementors
> among us, such an approach would simplify things when it comes to the
> parsing and analysis stage.
>
> I have talked to Chris as well as Tina Bird, who is the
> moderator of the
> loganalysis mailing list
> (http://lists.shmoo.com/mailman/listinfo/loganalysis). We have agreed
> that we can move discussion for non-IETF topics over to
> loganalysis. The
> big plus in this is that there are also many, many
> administrators on the
> list, so we will most probably get a lot of feedback from the end user
> camp, too. I think this is extremely valuable.
>
> I plan, however, to focus just some few days on -protocol and not
> directly start this other discussion. I think this serves our
> deadlines
> (Seoul meeting) better than doing too much in parallel. After that, I
> plan to post an initial message for those topics on the loganalysis
> list. If Chris permits, I would cross-post these message here
> to the WG
> list (together with my whish to only reply to loganalysis;)).
>
> I hope this is a good proposal, one that will allow us to make syslog
> even more interoperable than it is today.
>
> Rainer
>
> > -----Original Message-----
> > From: Andrew Ross [mailto:[email-masked]]
> > Sent: Sunday, February 08, 2004 12:52 AM
> > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> > [email-masked]
> > Subject: RE: -international: trailer
> >
> >
> > It is not just the 0x00 that we have to worry about. For
> TCP transport
> > mappings, we need to have a stream delimiter. Currently it is
> > generally
> > agreed that it is LF (0x0A). If we don't escape that
> > character, we will
> > have to resort to a byte length field. Please don't make me
> > have to drag
> > out my old Syslog over TCP proposal :-)
> >
> > Cheers
> >
> > Andrew
> >
> >
> >
>

------------------------------

Date: Tue, 10 Feb 2004 12:55:05 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: RE: -international: trailer

Hi Anton,

On Tue, 10 Feb 2004, Anton Okmianski wrote:

> Rainer:
>
> I am really struggling with that restriction not to standardize syslog
> storage in IETF.  It diminishes the value of the syslog protocol as
> people can't write a standard syslog parser.
>
> It would be nice if we could find another standards body which could be
> used to address that aspect. I assume log analysis mailing list is not
> affiliated with a standards body, or is it? I wonder if there is good
> precedent out there of two standards bodies working in tandem like this.
> Maybe W3C?

It may be that the IETF will accept that work.  However, it outside of our
current charter and that's not going to change until after we complete the
work we have going on in:
 - syslog-protocol
 - syslog-transport
 - syslog-sign
One could argue that without guidance from these documents, the question
of storage is rather ambiguous; what are you receiving to store and what
protection mechanisms are available with them.  I would also think that if
such work is undertaken in the future and it finds a problem with one of
these standards, then the standard may be changed.  However, at this
point, we need to put a stake in the ground and complete what's in front
of us.

If you really want to find another spot in the IETF, approach the OAM Area
Directors with a proposal.  If you'd like to go outside, I'd suggest NRIC
or T1M1 (through ATIS).

>
> Somebody suggested to me an idea that maybe a bit wild, but could
> address this.  A protocol for syslog server to return messages it has
> stored.  It could be UDP-based. How much less efficient would that be
> than reading a file?  I don't think the difference will be huge as I/O
> will likely be the bigger bottleneck anyway.   Essentially, the messages
> could be returned using the same -protocol & -transport and we just need
> to add some request/response semantics.  This does sound pretty wild,
> but desperate times call for desperate measures :) and I thought I would
> just pass it along.

Actually, I think I'd like to see what comes out of Netconf before this WG
looks down that path.

Thanks,
Chris

>
> Anton.
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Tuesday, February 10, 2004 12:15 PM
> > To: Andrew Ross; Harrington, David; Anton Okmianski;
> > [email-masked]
> > Subject: RE: -international: trailer
> >
> >
> > Hi All,
> >
> > I am a bit sad that I use Andrew's message to say this... but
> > Andrew has just made an important point that enlightens me on
> > David's thought that those CLRs  (crappy little rules [I like
> > this term]) really cause trouble. So Andrew please don't take
> > my objection personally, I see your reasoning behind it...
> >
> > ... but this is an excellent sample on how granting one
> > exception (the 0x00 case) leads to calls for further
> > exceptions (0x0a in this case). I have to admit I didn't
> > think well enough about this.
> >
> > Also, I was technically incorrect in insisting on 0x00 to be
> > too hard for C. Actually, I worked out a surprisingly easy,
> > obvious and well-known escaping mechanism to handle 0x00 once
> > the message is received. It looks like I was just too
> > narrow-minded to think with an open enough mind to solve it.
> > Thanks to all who kept pushing me :)
> >
> > But, honestly, even if I would not see an easy solution for
> > the C case, I think we should follow David's advise and avoid
> > any such rules (like the 0x00 exception). In the long term,
> > they cause more trouble in the long term than the solve initially.
> >
> > So I, too, now vote that we must support any valid UTF-8
> > sequence in the MSG part, which includes 0x00. If nobody
> > objects, I will change -protocol to specify this. If you have
> > objections, I would appreciate if you could reply relatively
> > quickly, as I try to get -03 out before Seoul.
> >
> > Now let me come to the C implementation and other things,
> > like syslog storage format. As we have discussed on this
> > list, these things are - at least at first look - not
> > relevant to IETF work. This is because they simply don't talk
> > about on-the-wire protocols. And only this is scope of the
> > IETF. Anyhow, it would definitely be a positive undertaking
> > to reach concensus among implementors how those things should
> > be addressed. To have a "least common denominator approach"
> > that customers could expect to be in syslog products they
> > purchase/use. Even for the implementors among us, such an
> > approach would simplify things when it comes to the parsing
> > and analysis stage.
> >
> > I have talked to Chris as well as Tina Bird, who is the
> > moderator of the loganalysis mailing list
> > (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We
> > have agreed that we can move discussion for
> > non-IETF topics over to loganalysis. The big plus in this is
> > that there are also many, many administrators on the list, so
> > we will most probably get a lot of feedback from the end user
> > camp, too. I think this is extremely valuable.
> >
> > I plan, however, to focus just some few days on -protocol and
> > not directly start this other discussion. I think this serves
> > our deadlines (Seoul meeting) better than doing too much in
> > parallel. After that, I plan to post an initial message for
> > those topics on the loganalysis list. If Chris permits, I
> > would cross-post these message here to the WG list (together
> > with my whish to only reply to loganalysis;)).
> >
> > I hope this is a good proposal, one that will allow us to
> > make syslog even more interoperable than it is today.
> >
> > Rainer
> >
> > > -----Original Message-----
> > > From: Andrew Ross [mailto:[email-masked]]
> > > Sent: Sunday, February 08, 2004 12:52 AM
> > > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> > > [email-masked]
> > > Subject: RE: -international: trailer
> > >
> > >
> > > It is not just the 0x00 that we have to worry about. For
> > TCP transport
> > > mappings, we need to have a stream delimiter. Currently it is
> > > generally agreed that it is LF (0x0A). If we don't escape that
> > > character, we will
> > > have to resort to a byte length field. Please don't make me
> > > have to drag
> > > out my old Syslog over TCP proposal :-)
> > >
> > > Cheers
> > >
> > > Andrew
> > >
> > >
> > >
> >
>
>
>
>

------------------------------

Date: Tue, 10 Feb 2004 17:04:27 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

David:

> > I am really struggling with that restriction not to
> standardize syslog
> > storage in IETF.  It diminishes the value of the syslog protocol as
> > people can't write a standard syslog parser.
>
> I'm not sure I understand why you feel this. Assuming you are
> parsing what was sent on the wire, that should be standard
> (to the degree that we standardize it).

Well, I am parsing a log file.  If I am parsing a syslog log file,
regardless of what we send, it does not match what is stored unless it
is standardized. The state of the art today is very sad and for no good
reason.  Consider two examples.  First, I send a well formed message:

<183>Oct 11 22:14:15 aokmians3-w2k su: Simple message 8

On Solaris, I have in the log file:

Oct 11 22:14:15 aokmians3-w2k aokmians3-w2k su: Simple message 8

On Linux -- same (only I assume hostname was not resolvable):

Oct 11 22:14:15 161.44.64.125 aokmians3-w2k su: Simple message 8

Why duplicate hostname or IP was added if it was a well-formed message?

Then consider platform implementation variations.  For example, Solaris
logs TLI endpoint identifier (IP + port) for forwarded messages if FQDN
can't be resolved:

Example of what's logged on server A:

Jun 20 11:26:57 bacdev1-cmts-1.cisco.com 715: My message

Same messages relayed to host B as stored:

Jun 20 11:26:57 [10.86.149.160.134.68] 715: My message

Great! And guess what the 10.86.149.160 is?  The IP of the relay A, not
of message originator "bacdev1-cmts-1.cisco.com"!  For one, this loses
the identity of message originator (which could be addressed in
- -protocol), but it is also a new log format to parse (TLIs).  Solaris
has also a features where it can add other stuff to the stored message
like message id.  Example:

Sep 29 21:41:18 cathy ufs: [ID 845546 kern.notice] alloc /: file system
full

I agree the -protocol and -transport are definitely higher priorities
and -storage is a separate topic. But without some agreed upon storage
format, writing a portable log parser is a challenge.  In the above
example, Sun had to invent a proprietary mechanism to store severity and
facility in the message, for example. Whichever is the appropriate way
to solve this, I don't think anyone benefits from the existing state of
the art, which will definitely continue if nothing is done about it.

Thanks,
Anton.

------------------------------

Date: Tue, 10 Feb 2004 16:44:21 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: SyslogMIB Issue-#4  // Issue-#2

Hi Glenn,

We can always write a "syslog compliance" statement to indicate what
subset of the Script MIB needs to be implemented to support syslog
configuration. As long as such a statement doesn't try to change the
semantics of any objects, but simply defines a subset of the mib module,
that should be no problem. That would essentially be the same as having
such a "limited" compliance statement in the script mib document itself.

dbh

> -----Original Message-----
> From: Glenn Mansfield Keeni [mailto:[email-masked]]
> Sent: Monday, February 09, 2004 1:12 AM
> To: Harrington, David
> Cc: [email-masked]
> Subject: Re: SyslogMIB Issue-#4 // Issue-#2
>
> Dave,
> Harrington, David wrote:
> > Hi,
> >
> > Rather than reinventing wheels, let's try to review work that has
> > already been done in the IETF for these purposes, and discuss any
> > experience that has already been had with these approaches.
> Please look
> > at the RFC3165 Script MIB
> I fully agree.
> > (ftp://ftp.rfc-editor.org/in-notes/rfc3165.txt) and the NETCONF work
> > (http://www.ietf.org/html.charters/netconf-charter.html)
> >
> > The Script MIB is all about uploading/downloading scripts
> to execute on
> > a managed device. It is language-independent, but recognizes the
> > likelihood of Java, Perl, and CLI scripts.
> > This MIB has an (optional) on-line editing capability,
> which experience
> > has shown few operators want to use; they would rather get
> the script,
> > modify it offline, and send it back to the device.
> I am aware of the ScriptMIB. If we do design a
> configuration-download/upload
> MIB we will certainly refer to and use the mechanisms used in RFC3165.
>
> I am still trying to figure out whether we can use the
> scriptMIB itself
> without defining any new Tables. It is all there .. we have
> to pretend that
> the syslogConf is a script that is interpreted by the syslog process.
> There does not seem to be any problem - but the compilance
> requirements may
> be a bother- I need to look at the RFC to figure out before I
> can really
> propose to use theScriptMIB.
> >
> > The NETCONF work is trying to make it possible to
> download/upload script
> > files for configuring devices, as a way to standardize CLI
> scripting.
> >
> > dbh
>
> Cheers
>
> Glenn
>
>

------------------------------

Date: Tue, 10 Feb 2004 17:14:18 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

BTW, one issue from my examples below, I think is relevant to -protocol.

In current implementations, syslog servers probably always add the
originator's IP or hostname because they don't want to trust the host
providing this in the message.  This brings up the question of what
should be done by relay in -protocol.

It seems to me it would be nice to provide a standard way for relay to
include the IP, FQDN or both of the originator of the message.  Maybe it
can be placed in the standard structured content parameter.  The
original packet has the IP, but the server receiving relayed message,
won't have access to it. The message manipulation by relay sucks, but I
think we should not lose any information in relay.

This information can be useful for cases when a host, for example,
thinks that it has a certain FQDN, while in fact, its IP resolves to
something else.

We have to distinguish between the first relay and subsequent relay for
this to work, right?  Maybe if information is already in the structured
content, then relay should not update it and the originator will
recommended no to use that parameter.

What do you think?

Anton.

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 5:04 PM
> To: 'Harrington, David'; 'Rainer Gerhards'; 'Andrew Ross';
> [email-masked]'
> Subject: RE: -international: trailer
>
>
> David:
>
> > > I am really struggling with that restriction not to
> > standardize syslog
> > > storage in IETF.  It diminishes the value of the syslog
> protocol as
> > > people can't write a standard syslog parser.
> >
> > I'm not sure I understand why you feel this. Assuming you are
> > parsing what was sent on the wire, that should be standard
> > (to the degree that we standardize it).
>
> Well, I am parsing a log file.  If I am parsing a syslog log
> file, regardless of what we send, it does not match what is
> stored unless it is standardized. The state of the art today
> is very sad and for no good reason.  Consider two examples.
> First, I send a well formed message:
>
> <183>Oct 11 22:14:15 aokmians3-w2k su: Simple message 8
>
> On Solaris, I have in the log file:
>
> Oct 11 22:14:15 aokmians3-w2k aokmians3-w2k su: Simple message 8
>
> On Linux -- same (only I assume hostname was not resolvable):
>
> Oct 11 22:14:15 161.44.64.125 aokmians3-w2k su: Simple message 8
>
> Why duplicate hostname or IP was added if it was a
> well-formed message?
>
> Then consider platform implementation variations.  For
> example, Solaris logs TLI endpoint identifier (IP + port) for
> forwarded messages if FQDN can't be resolved:
>
> Example of what's logged on server A:
>
> Jun 20 11:26:57 bacdev1-cmts-1.cisco.com 715: My message
>
> Same messages relayed to host B as stored:
>
> Jun 20 11:26:57 [10.86.149.160.134.68] 715: My message
>
> Great! And guess what the 10.86.149.160 is?  The IP of the
> relay A, not of message originator
> "bacdev1-cmts-1.cisco.com"!  For one, this loses the identity
> of message originator (which could be addressed in
> -protocol), but it is also a new log format to parse (TLIs).
> Solaris has also a features where it can add other stuff to
> the stored message like message id.  Example:
>
> Sep 29 21:41:18 cathy ufs: [ID 845546 kern.notice] alloc /:
> file system full
>
> I agree the -protocol and -transport are definitely higher
> priorities and -storage is a separate topic. But without some
> agreed upon storage format, writing a portable log parser is
> a challenge.  In the above example, Sun had to invent a
> proprietary mechanism to store severity and facility in the
> message, for example. Whichever is the appropriate way to
> solve this, I don't think anyone benefits from the existing
> state of the art, which will definitely continue if nothing
> is done about it.
>
> Thanks,
> Anton.
>

------------------------------

Date: Tue, 10 Feb 2004 16:50:03 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -protocol open issues

Hi,

I wrote a fairly long message, after your response to Anton, explaining
why I thought it would be a good thing, and clarifying how it should be
used. Did you not receive it?

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Monday, February 09, 2004 12:36 PM
> To: [email-masked]
> Subject: RE: -protocol open issues
>
> Hi WG,
>
> I am coming back to the enterprise ID. Anton posted his opinion 5 days
> ago. Besides my "not sure" reply
> (http://www.syslog.cc/ietf/autoarc/msg01052.html), we got no
> response so
> far.
>
> Given the otherwise healthy discussion, I assume this is not
> a priority
> for the WG. So I will remove the enterprise ID for -protocol-03 if
> nobody speaks up (we can always get it back in at a later time). If
> someone sees good reasons to have it in, I would appreciate
> comments now
> ;)
>
> Thanks,
> Rainer
>
> > -----Original Message-----
> > From: Anton Okmianski [mailto:[email-masked]]
> > Sent: Wednesday, February 04, 2004 7:20 PM
> > To: Rainer Gerhards; [email-masked]
> > Subject: RE: -protocol open issues
> >
> > On issue #7 - enterprise ID:
> >
> > I am relatively neutral to this idea. But I am trying to
> > understand how
> > it will be used. What are the anticipated use cases for it?
> >
> > If we want to use it to differentiate messages from a
> specific vendor
> > because it may provide some additional formatting, then one
> could also
> > argue that we also need vendor version and potentially
> vendor product
> > and on and on.
> >
> > If we do provide enterprise ID, does it have to be required
> and in the
> > header as opposed to structured content?  Is filtering on
> vendor going
> > to be a common use-case?
> >
> > One area of ambiguity, I think, is a situation where components are
> > integrated into other applications.  Say component X from one
> > company is
> > integrated into product Y of another company.  Component X
> > already does
> > -protocol compliant syslog logging. Which enterprise ID
> should it use?
> > Should we leave this as nondeterministic or provide recommendations?
> >
> > Another area of potential ambiguity is relaying. Suppose a
> > relay gets a
> > bad message from a Cisco device and needs to fire a diagnostic error
> > message.  Does it use its own enterprise ID for this?  If so, my
> > collector which catches messages only for vendor Cisco won't
> > catch this,
> > right?
> >
> > Anton.
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of
> Rainer Gerhards
> > > Sent: Wednesday, February 04, 2004 9:36 AM
> > > To: [email-masked]
> > > Subject: -protocol open issues
> > >
> > >
> > > Hi WG,
> > >
> > > I have updated my page of open issues in -protocol. I would
> > > appreciate if you could comment on the open issues. They can
> > > be found here:
> > >
> > http://www.syslog.cc/ietf/protocol.html
> >
> > Please note that these are just the issues which have
> definitely been
> > identified. Others are lurking around, so I will add them
> > when they are
> > discovered ("other things to do" beneath the issues may provide an
> > idea). I try to solve those issues before creating new ones, just so
> > that it is easier to keep track and stay focussed.
> >
> > Any feedback is highly appreciated.
> >
> > Rainer
> >
> >
> >
>
>
>

------------------------------

Date: Tue, 10 Feb 2004 17:36:29 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -international: trailer

Chris:

Sounds reasonable.  Let's get the other stuff completed first.

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Chris Lonvick
> Sent: Tuesday, February 10, 2004 3:55 PM
> To: Anton Okmianski
> Cc: [email-masked]
> Subject: RE: -international: trailer
>
>
> Hi Anton,
>
> On Tue, 10 Feb 2004, Anton Okmianski wrote:
>
> > Rainer:
> >
> > I am really struggling with that restriction not to
> standardize syslog
> > storage in IETF.  It diminishes the value of the syslog protocol as
> > people can't write a standard syslog parser.
> >
> > It would be nice if we could find another standards body
> which could
> > be used to address that aspect. I assume log analysis
> mailing list is
> > not affiliated with a standards body, or is it? I wonder if
> there is
> > good precedent out there of two standards bodies working in tandem
> > like this. Maybe W3C?
>
> It may be that the IETF will accept that work.  However, it
> outside of our current charter and that's not going to change
> until after we complete the work we have going on in:
>  - syslog-protocol
>  - syslog-transport
>  - syslog-sign
> One could argue that without guidance from these documents,
> the question of storage is rather ambiguous; what are you
> receiving to store and what protection mechanisms are
> available with them.  I would also think that if such work is
> undertaken in the future and it finds a problem with one of
> these standards, then the standard may be changed.  However,
> at this point, we need to put a stake in the ground and
> complete what's in front of us.
>
> If you really want to find another spot in the IETF, approach
> the OAM Area Directors with a proposal.  If you'd like to go
> outside, I'd suggest NRIC or T1M1 (through ATIS).
>
> >
> > Somebody suggested to me an idea that maybe a bit wild, but could
> > address this.  A protocol for syslog server to return
> messages it has
> > stored.  It could be UDP-based. How much less efficient
> would that be
> > than reading a file?  I don't think the difference will be
> huge as I/O
> > will likely be the bigger bottleneck anyway.   Essentially,
> the messages
> > could be returned using the same -protocol & -transport and we just
> > need to add some request/response semantics.  This does
> sound pretty
> > wild, but desperate times call for desperate measures :)
> and I thought
> > I would just pass it along.
>
> Actually, I think I'd like to see what comes out of Netconf
> before this WG looks down that path.
>
> Thanks,
> Chris
>
> >
> > Anton.
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[email-masked]]
> > > Sent: Tuesday, February 10, 2004 12:15 PM
> > > To: Andrew Ross; Harrington, David; Anton Okmianski;
> > > [email-masked]
> > > Subject: RE: -international: trailer
> > >
> > >
> > > Hi All,
> > >
> > > I am a bit sad that I use Andrew's message to say this...
> but Andrew
> > > has just made an important point that enlightens me on David's
> > > thought that those CLRs  (crappy little rules [I like this term])
> > > really cause trouble. So Andrew please don't take my objection
> > > personally, I see your reasoning behind it...
> > >
> > > ... but this is an excellent sample on how granting one exception
> > > (the 0x00 case) leads to calls for further exceptions
> (0x0a in this
> > > case). I have to admit I didn't think well enough about this.
> > >
> > > Also, I was technically incorrect in insisting on 0x00 to be too
> > > hard for C. Actually, I worked out a surprisingly easy,
> obvious and
> > > well-known escaping mechanism to handle 0x00 once the message is
> > > received. It looks like I was just too narrow-minded to
> think with
> > > an open enough mind to solve it. Thanks to all who kept
> pushing me
> > > :)
> > >
> > > But, honestly, even if I would not see an easy solution for the C
> > > case, I think we should follow David's advise and avoid any such
> > > rules (like the 0x00 exception). In the long term, they
> cause more
> > > trouble in the long term than the solve initially.
> > >
> > > So I, too, now vote that we must support any valid UTF-8
> sequence in
> > > the MSG part, which includes 0x00. If nobody objects, I
> will change
> > > -protocol to specify this. If you have objections, I would
> > > appreciate if you could reply relatively quickly, as I try to get
> > > -03 out before Seoul.
> > >
> > > Now let me come to the C implementation and other things, like
> > > syslog storage format. As we have discussed on this list, these
> > > things are - at least at first look - not relevant to IETF work.
> > > This is because they simply don't talk about on-the-wire
> protocols.
> > > And only this is scope of the IETF. Anyhow, it would
> definitely be a
> > > positive undertaking to reach concensus among
> implementors how those
> > > things should be addressed. To have a "least common denominator
> > > approach" that customers could expect to be in syslog
> products they
> > > purchase/use. Even for the implementors among us, such an
> > > approach would simplify things when it comes to the parsing
> > > and analysis stage.
> > >
> > > I have talked to Chris as well as Tina Bird, who is the
> moderator of
> > > the loganalysis mailing list
> > > (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We have
> > > agreed that we can move discussion for non-IETF topics over to
> > > loganalysis. The big plus in this is that there are also
> many, many
> > > administrators on the list, so we will most probably get a lot of
> > > feedback from the end user camp, too. I think this is extremely
> > > valuable.
> > >
> > > I plan, however, to focus just some few days on -protocol and not
> > > directly start this other discussion. I think this serves our
> > > deadlines (Seoul meeting) better than doing too much in parallel.
> > > After that, I plan to post an initial message for those topics on
> > > the loganalysis list. If Chris permits, I would cross-post these
> > > message here to the WG list (together with my whish to
> only reply to
> > > loganalysis;)).
> > >
> > > I hope this is a good proposal, one that will allow us to make
> > > syslog even more interoperable than it is today.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Andrew Ross [mailto:[email-masked]]
> > > > Sent: Sunday, February 08, 2004 12:52 AM
> > > > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> > > > [email-masked]
> > > > Subject: RE: -international: trailer
> > > >
> > > >
> > > > It is not just the 0x00 that we have to worry about. For
> > > TCP transport
> > > > mappings, we need to have a stream delimiter. Currently it is
> > > > generally agreed that it is LF (0x0A). If we don't escape that
> > > > character, we will have to resort to a byte length
> field. Please
> > > > don't make me have to drag
> > > > out my old Syslog over TCP proposal :-)
> > > >
> > > > Cheers
> > > >
> > > > Andrew
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
>

------------------------------

Date: Tue, 10 Feb 2004 18:38:06 -0500
From: Anton Okmianski <[email-masked]>
Subject: RFC 3339 & UTC offset

Just noticed this in RFC 3339 (Section 4.4):

"Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC."

Since -protocol is a distributed protocol where multiple hosts can generate syslog messages to one syslog server, one can say that syslog "depends on hosts synchronization with other Internet systems".  Does this mean that syslog clients and servers MUST be aware of their UTC offset?  Are we going to require this in -protocol?  Besides, I don't think RFC 3339 specifies any designation for "unknown" offset, so what will such client provide?

Anton.

PS:  BTW, just as an FYI, I searched rfc-editor.org web site and came across only one other RFC which uses RFC 3339 format (RFC3340).  I think if we are worried about acceptability of -protocol, this could be yet another slight concern.  I think RFC 3339 time stamp is unlike anything that is in wide use and people may have some initial reservations about it until it becomes more accepted.  I like it, accept for "T" and "Z" characters. Unfortunately, ANSI and ISO standards are worse.

------------------------------

Date: Wed, 11 Feb 2004 14:05:09 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

I could throw in a couple of comments to this thread ... but I think
Anton has well summed it up. I, too, vote that we get the current work
done. I'd like to begin to fiddle a little on the storage format before
the WG can actually look at it - I'll do so via loganalysis, but only
after -protocol-03 ;). Hopefully that loganalysis discussion will lead
to something that we can eventually reuse later here in the WG.

In fact, I am delighted to see that it seems possible to standardize
non-on-the-wire things in a RFC (or at least provide a best practice
reference). Honestly, going to another standards body is not an option
for me, simply because for all the others you seem to primarily need big
money and not tech arguments ;) Big money is out of scope for us ;) As
some suggested, we may later be able to integrate those things into
another standard, but that needs to be seen when there is time.

Again, my mail has become longer than it should: Quick summary: I, too,
think we should concentrate on finishing things ASAP, and then look into
further work.

Rainer

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 11:36 PM
> To: 'Chris Lonvick'
> Cc: [email-masked]
> Subject: RE: -international: trailer
>
> Chris:
>
> Sounds reasonable.  Let's get the other stuff completed first.
>
> Anton.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Chris Lonvick
> > Sent: Tuesday, February 10, 2004 3:55 PM
> > To: Anton Okmianski
> > Cc: [email-masked]
> > Subject: RE: -international: trailer
> >
> >
> > Hi Anton,
> >
> > On Tue, 10 Feb 2004, Anton Okmianski wrote:
> >
> > > Rainer:
> > >
> > > I am really struggling with that restriction not to
> > standardize syslog
> > > storage in IETF.  It diminishes the value of the syslog
> protocol as
> > > people can't write a standard syslog parser.
> > >
> > > It would be nice if we could find another standards body
> > which could
> > > be used to address that aspect. I assume log analysis
> > mailing list is
> > > not affiliated with a standards body, or is it? I wonder if
> > there is
> > > good precedent out there of two standards bodies working in tandem
> > > like this. Maybe W3C?
> >
> > It may be that the IETF will accept that work.  However, it
> > outside of our current charter and that's not going to change
> > until after we complete the work we have going on in:
> >  - syslog-protocol
> >  - syslog-transport
> >  - syslog-sign
> > One could argue that without guidance from these documents,
> > the question of storage is rather ambiguous; what are you
> > receiving to store and what protection mechanisms are
> > available with them.  I would also think that if such work is
> > undertaken in the future and it finds a problem with one of
> > these standards, then the standard may be changed.  However,
> > at this point, we need to put a stake in the ground and
> > complete what's in front of us.
> >
> > If you really want to find another spot in the IETF, approach
> > the OAM Area Directors with a proposal.  If you'd like to go
> > outside, I'd suggest NRIC or T1M1 (through ATIS).
> >
> > >
> > > Somebody suggested to me an idea that maybe a bit wild, but could
> > > address this.  A protocol for syslog server to return
> > messages it has
> > > stored.  It could be UDP-based. How much less efficient
> > would that be
> > > than reading a file?  I don't think the difference will be
> > huge as I/O
> > > will likely be the bigger bottleneck anyway.   Essentially,
> > the messages
> > > could be returned using the same -protocol & -transport
> and we just
> > > need to add some request/response semantics.  This does
> > sound pretty
> > > wild, but desperate times call for desperate measures :)
> > and I thought
> > > I would just pass it along.
> >
> > Actually, I think I'd like to see what comes out of Netconf
> > before this WG looks down that path.
> >
> > Thanks,
> > Chris
> >
> > >
> > > Anton.
> > >
> > > > -----Original Message-----
> > > > From: Rainer Gerhards [mailto:[email-masked]]
> > > > Sent: Tuesday, February 10, 2004 12:15 PM
> > > > To: Andrew Ross; Harrington, David; Anton Okmianski;
> > > > [email-masked]
> > > > Subject: RE: -international: trailer
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > I am a bit sad that I use Andrew's message to say this...
> > but Andrew
> > > > has just made an important point that enlightens me on David's
> > > > thought that those CLRs  (crappy little rules [I like
> this term])
> > > > really cause trouble. So Andrew please don't take my objection
> > > > personally, I see your reasoning behind it...
> > > >
> > > > ... but this is an excellent sample on how granting one
> exception
> > > > (the 0x00 case) leads to calls for further exceptions
> > (0x0a in this
> > > > case). I have to admit I didn't think well enough about this.
> > > >
> > > > Also, I was technically incorrect in insisting on 0x00 to be too
> > > > hard for C. Actually, I worked out a surprisingly easy,
> > obvious and
> > > > well-known escaping mechanism to handle 0x00 once the message is
> > > > received. It looks like I was just too narrow-minded to
> > think with
> > > > an open enough mind to solve it. Thanks to all who kept
> > pushing me
> > > > :)
> > > >
> > > > But, honestly, even if I would not see an easy solution
> for the C
> > > > case, I think we should follow David's advise and avoid any such
> > > > rules (like the 0x00 exception). In the long term, they
> > cause more
> > > > trouble in the long term than the solve initially.
> > > >
> > > > So I, too, now vote that we must support any valid UTF-8
> > sequence in
> > > > the MSG part, which includes 0x00. If nobody objects, I
> > will change
> > > > -protocol to specify this. If you have objections, I would
> > > > appreciate if you could reply relatively quickly, as I
> try to get
> > > > -03 out before Seoul.
> > > >
> > > > Now let me come to the C implementation and other things, like
> > > > syslog storage format. As we have discussed on this list, these
> > > > things are - at least at first look - not relevant to IETF work.
> > > > This is because they simply don't talk about on-the-wire
> > protocols.
> > > > And only this is scope of the IETF. Anyhow, it would
> > definitely be a
> > > > positive undertaking to reach concensus among
> > implementors how those
> > > > things should be addressed. To have a "least common denominator
> > > > approach" that customers could expect to be in syslog
> > products they
> > > > purchase/use. Even for the implementors among us, such an
> > > > approach would simplify things when it comes to the parsing
> > > > and analysis stage.
> > > >
> > > > I have talked to Chris as well as Tina Bird, who is the
> > moderator of
> > > > the loganalysis mailing list
> > > > (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We have
> > > > agreed that we can move discussion for non-IETF topics over to
> > > > loganalysis. The big plus in this is that there are also
> > many, many
> > > > administrators on the list, so we will most probably
> get a lot of
> > > > feedback from the end user camp, too. I think this is extremely
> > > > valuable.
> > > >
> > > > I plan, however, to focus just some few days on
> -protocol and not
> > > > directly start this other discussion. I think this serves our
> > > > deadlines (Seoul meeting) better than doing too much in
> parallel.
> > > > After that, I plan to post an initial message for those
> topics on
> > > > the loganalysis list. If Chris permits, I would cross-post these
> > > > message here to the WG list (together with my whish to
> > only reply to
> > > > loganalysis;)).
> > > >
> > > > I hope this is a good proposal, one that will allow us to make
> > > > syslog even more interoperable than it is today.
> > > >
> > > > Rainer
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Ross [mailto:[email-masked]]
> > > > > Sent: Sunday, February 08, 2004 12:52 AM
> > > > > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
> > > > > [email-masked]
> > > > > Subject: RE: -international: trailer
> > > > >
> > > > >
> > > > > It is not just the 0x00 that we have to worry about. For
> > > > TCP transport
> > > > > mappings, we need to have a stream delimiter. Currently it is
> > > > > generally agreed that it is LF (0x0A). If we don't escape that
> > > > > character, we will have to resort to a byte length
> > field. Please
> > > > > don't make me have to drag
> > > > > out my old Syslog over TCP proposal :-)
> > > > >
> > > > > Cheers
> > > > >
> > > > > Andrew
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>
>

------------------------------

Date: Wed, 11 Feb 2004 14:47:38 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

> Just noticed this in RFC 3339 (Section 4.4):
>
> "Systems that are configured with a local time, are unaware
> of the corresponding UTC offset, and depend on time
> synchronization with other Internet systems, MUST use a
> mechanism that ensures correct synchronization with UTC."
>
> Since -protocol is a distributed protocol where multiple
> hosts can generate syslog messages to one syslog server, one
> can say that syslog "depends on hosts synchronization with
> other Internet systems".  Does this mean that syslog clients
> and servers MUST be aware of their UTC offset?  Are we going
> to require this in -protocol?  Besides, I don't think RFC
> 3339 specifies any designation for "unknown" offset, so what
> will such client provide?

Actually, I think we can't ensure this. The real world is against us.
You are right, I should specify that a syslog sender MUST offer a way
learn its time zone, but I am very hesitant to demand time sync for
syslog. I guess everybody in this WG knows how important time sync is,
yet this is a real-life issue. Admin's don't use NTP, they don't
configure time zones and device clocks are often set to wild values.

So I think we should demand the capability to set the time zone in any
syslog sender - but not go any further.

>
> Anton.
>
> PS:  BTW, just as an FYI, I searched rfc-editor.org web site
> and came across only one other RFC which uses RFC 3339 format
> (RFC3340).  I think if we are worried about acceptability of
> -protocol, this could be yet another slight concern.  I think
> RFC 3339 time stamp is unlike anything that is in wide use
> and people may have some initial reservations about it until
> it becomes more accepted.  I like it, accept for "T" and "Z"
> characters.

I, too, disliked this when I came across it the first time. But when you
begin to actually develop applications, the "T" is a great, quick
shortcut to detect that it is actually an ISO date.

> Unfortunately, ANSI and ISO standards are worse.

I think this is the most important argument why I selected 3339 - I
don't like to invent yet another timestamp, the older timestamps either
lack the year or the time zone or resolution or ... and the other
standards are worse. Plus, I like to stick refering to RFCs, because
these are available without purchasing (expensive) books [which also
means RFCs are instantly available when you need them...].

Rainer

------------------------------

Date: Wed, 11 Feb 2004 15:59:18 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -international: trailer

> Let's not try to create a protocol just to standardzie something not
> directly related to the internet. If you want to develop a parser and
> have the parser accepted as a "standard" why don't you just develop it
> as open source, say, on sourceforge?

Just for the records: I plan to include support for -protocol and any
upcoming agreement on storage format (whenever this is) in my open
source, BSD license logging library implementation at
http://www.liblogging.org/. I hope this will facilitate things in the
future.

> If everybody uses it, it will
> become a defacto standard. You don't need to make it an IETF standard.

Rainer

------------------------------

Date: Wed, 11 Feb 2004 10:24:29 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Rainer:

> > "Systems that are configured with a local time, are unaware
> > of the corresponding UTC offset, and depend on time
> > synchronization with other Internet systems, MUST use a
> > mechanism that ensures correct synchronization with UTC."
> >
> > Since -protocol is a distributed protocol where multiple
> > hosts can generate syslog messages to one syslog server, one
> > can say that syslog "depends on hosts synchronization with
> > other Internet systems".  Does this mean that syslog clients
> > and servers MUST be aware of their UTC offset?  Are we going
> > to require this in -protocol?  Besides, I don't think RFC
> > 3339 specifies any designation for "unknown" offset, so what
> > will such client provide?
>
> Actually, I think we can't ensure this. The real world is
> against us. You are right, I should specify that a syslog
> sender MUST offer a way learn its time zone, but I am very
> hesitant to demand time sync for syslog. I guess everybody in
> this WG knows how important time sync is, yet this is a
> real-life issue. Admin's don't use NTP, they don't configure
> time zones and device clocks are often set to wild values.
>
> So I think we should demand the capability to set the time
> zone in any syslog sender - but not go any further.

Well, I think demanding that capability is more about host
implementation.  I think it is better to focus on the protocol and what
the client/sender must put into the UTC offset field if one is not set
on the system.  We can't tell them to put "-00:00" or "+00:00" as this
has special meaning in the RFC. I would say that UTC offset if a MUST,
while time sync is a SHOULD. If offset is not a MUST, then we MUST
specify what they put as offset to indicate it is unknown.  Yaks. Crappy
little rule? :)

Anton.

------------------------------

Date: Wed, 11 Feb 2004 17:57:04 +0100
From: Rainer Gerhards <[email-masked]>
Subject: syslog message size and fragmentation

Hi WG,

I had an off-list discussion with Anton that lead to the discovery of a
new issue in -protocol, that of message fragmentation. -protocol
specifies a message size limit of 1024 characters, but also assumes that
message of this size can always be transmitted without (transport)
fragemention. In the real world, datagram based transport mappings will
probably not be able to assure that the message will not become
fragmented. The MTU can at least be as low as 576 bytes.

Must this issue be addressed in the context of -protocol? If so, what is
the best solution?

Thanks,
Rainer

------------------------------

Date: Wed, 11 Feb 2004 17:22:10 +0100
From: Rainer Gerhards <[email-masked]>
Subject: Structured Data Elements anywhere in the message?

Hi WG,

I am trying to close up the current open issues for protocol before I
create new ones ;)

I would like to turn to issue 8, that is structured data element
placement. I have put together the (few) most important thoughts here:

http://www.syslog.cc/ietf/protocol/issue8.html

Anton proposed that we

a) allow elements only in their own, well-defined field
b) merge that with TAG

I personally think a) is a good idea while I am very sceptical about b).
I would appreciate any more feedback on this issue.

Many thanks,
Rainer

------------------------------

Date: Wed, 11 Feb 2004 18:35:28 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Anton,

this is a tough one ;)

> Well, I think demanding that capability is more about host
> implementation.  I think it is better to focus on the
> protocol and what
> the client/sender must put into the UTC offset field if one is not set
> on the system.

This is right. And I have to admit it is an important issue. We always
have nightmares about non-timesynced devices, as many customers have. In
fact, the default of our product is to use time of reception, not the
time from the message timestamp. I guess this shows it actually *is* a
real world issue...

> We can't tell them to put "-00:00" or "+00:00" as this
> has special meaning in the RFC. I would say that UTC offset if a MUST,
> while time sync is a SHOULD. If offset is not a MUST, then we MUST
> specify what they put as offset to indicate it is unknown.
> Yaks. Crappy
> little rule? :)

I spent some time reading and re-reading RFC 3339 and thinking how this
could be handled... I think all "clean" options are already used up.

I see three approaches:

#1 is more a spec-stunt than a real solution ;)
   In 4.4, RFC 3339 says

   ###
   o  Use another host in the same local time zone as a gateway to the
      Internet.  This host MUST correct unqualified local times that are
      transmitted to other hosts.
   ###

   If I look at syslog, that means we can require all systems that don't
know
   their TZ to talk to a syslog relay which does. That, of course
   means we leave everything as imperfect as it is (but it
   is within the specs ;)).

OK, now to the solutions...

#2 is to "tweak" the format a little bit. Honestly, I don't like this
messing with a standard, and this is very far to the edge...

All special sequences (like "-00:00") are already taken up. 3339,
however, specifies that the "Z" UTC indicator can be either upper or
lower case. I have choosen to allow only upper case for simplicity. We
*could* say that if the device does not know its ZT and does not know if
time is properly synced, it should use "z" (lower case) as the TZ
indicator. This would still be a valid 3339 indicator, but definitely
not be in the spirit of 3339.

#3 is to actually add a syslog header field "I know my TZ info or I am
synced" (Y/N) in -protcol, eventually adjecent to the timestamp field.
Honestly, this, too, does not smell really good to me.

In any case, I think we have a real-world problem and it would be good
to find a solution. Which options does the WG prefer? Or is there
another one I have not seen so far?

Thanks,
Rainer

PS: I have listed this as issue 12 now.

------------------------------

Date: Wed, 11 Feb 2004 13:24:12 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: Structured Data Elements anywhere in the message?

Rainer:

> I would like to turn to issue 8, that is structured data
> element placement. I have put together the (few) most
> important thoughts here:
>
> http://www.syslog.cc/ietf/protocol/issue8.html
>
> Anton proposed that we
>
> a) allow elements only in their own, well-defined field
> b) merge that with TAG
>
> I personally think a) is a good idea while I am very
> sceptical about b). I would >appreciate any more feedback
> on this issue.

I was actually going to raise the issue of TAG field as another issue if
we don't address it as part of this one.

As you yourself indicated, we are not sure about the whole business of
static and dynamic parts of TAG and what it is supposed to be used for.
I don't think we can allow such ambiguity in the -protocol. Whatever
this field is used for, it must be specified clearly IMO.  When I think
about what TAG field might be used for, I definitely see an overlap with
structured content field in concept.

Anton.

------------------------------

Date: Wed, 11 Feb 2004 16:12:03 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: syslog message size and fragmentation

Hi!

I think that the 1024 bytes limit is rather arbitrary (CLR?).  It does
not always avoid fragmentation, nor does it provide for efficient
transfer when larger messages need to be transmitted.

I assume we can't completely avoid fragmentation with -protocol, because
that would require a very small message size limit, and we will still
probably assume Ethernet.  Fragmentation is not inherently bad except
for some firewalls of vendor we won't mention which used to drop
fragmented UDP packets at will instead of reassembling them (I think
they call those stateless firewalls). But that's just broken - if they
need UDP port info, they must reassemble packets.

In IPv6, the clients learn the MTU of the network and must do
fragmentation themselves.  So, unexpected fragmentation should be less
of an issue and efficiency will be achieved by discovering optimal MTU.
It almost seems like we are re-inventing the IP fragmentation with out
support for syslog multi-part messages.

Solution proposal:

How about we just set the size limit at around 64Kb (max UDP datagram
size) and drop the whole fragmentation feature?  At least for the
foreseeable future 64Kb should be sufficient (although I am sure this
won't be enough forever).  Together with this, we can recommend that in
order to avoid IP fragmentation and potential firewall, performance and
reliability issues, it is recommended that on the Ethernet users strive
to restrict most syslog messages to 512 bytes. This recommendation will
also potentially improve readability of messages. By removing the syslog
fragmentation from -protocol, we will leave fragmentation in one place
- -- IP and allow for more efficient syslog implementations.

Anton.

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2004 11:57 AM
> To: [email-masked]; Anton Okmianski
> Subject: syslog message size and fragmentation
>
>
> Hi WG,
>
> I had an off-list discussion with Anton that lead to the
> discovery of a new issue in -protocol, that of message
> fragmentation. -protocol specifies a message size limit of
> 1024 characters, but also assumes that message of this size
> can always be transmitted without (transport) fragemention.
> In the real world, datagram based transport mappings will
> probably not be able to assure that the message will not
> become fragmented. The MTU can at least be as low as 576 bytes.
>
> Must this issue be addressed in the context of -protocol? If
> so, what is the best solution?
>
> Thanks,
> Rainer
>

------------------------------

Date: Thu, 12 Feb 2004 12:45:53 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog message size and fragmentation

Anton:

the max message size is a frequent topic on this list. I thought we had
reached a full agreement previously, but after some extensive archive
searching, I could not find a final concensus. The closest thing to a
concensus was discessed in this thread:

http://www.syslog.cc/ietf/autoarc/msg00855.html

I recommend to review it, it applies to this issue here, too. The thread
ended somewhere around the implicit concensus that fragmentation and
long messages are needed.

> I think that the 1024 bytes limit is rather arbitrary (CLR?).

It is a historical limitation. Though I know that we already have broken
with backwards compatibility, I really, really do not like to remove
this limitation. One important reason is that I think we should not come
up with a spec that does not even remotely look like traditional syslog.
We are already close to this point. Removing the size limitation will
get us over the edge. This will probably cost us a lot of momentum. I am
already concerned if implementors will pick up -protocol, because it
looks very different. I am really afraid of changing this...

> It does
> not always avoid fragmentation, nor does it provide for efficient
> transfer when larger messages need to be transmitted.
>
> I assume we can't completely avoid fragmentation with
> -protocol, because
> that would require a very small message size limit, and we will still
> probably assume Ethernet.  Fragmentation is not inherently bad except
> for some firewalls of vendor we won't mention which used to drop
> fragmented UDP packets at will instead of reassembling them (I think
> they call those stateless firewalls). But that's just broken - if they
> need UDP port info, they must reassemble packets.

My experience is that there is always trouble with fragmented UDP. I
can't proove it with hard arguments, though. But it is a strong feeling.

I have to admit I am not 100% sure what the UDP spec says: If a UDP
packet becomes fragmented (due to MTU), is it guaranteed that the packet
will be re-assembled by the receivers IP stack before it is passed up to
the app layer? What if a fragment is missing? Will the whole packet be
discarded by the stack (UDP is best effort, after all...)?

I would appreciate if someone saves me the time of reading the UDP
RFCs...

>
> In IPv6, the clients learn the MTU of the network and must do
> fragmentation themselves.  So, unexpected fragmentation should be less
> of an issue and efficiency will be achieved by discovering
> optimal MTU.
> It almost seems like we are re-inventing the IP fragmentation with out
> support for syslog multi-part messages.
>
> Solution proposal:
>
> How about we just set the size limit at around 64Kb (max UDP datagram
> size) and drop the whole fragmentation feature?

Based on previous discussion on the WG and other forums, I do not
support this. Fragmentation in -protcol is lightweight an truely
optional. If you don't need it, don't use it. It just gives you a way to
transmit "oversize data" in a standard way. I have to admit I am
insisting on this because we again could not create fully compliant
products, simply because 64K is not enough in some rare, but
to-be-supported, cases. Eventually others would have the same issue.

> At least for the
> foreseeable future 64Kb should be sufficient (although I am sure this
> won't be enough forever).

Windows Event Log records can become larger (mainly if binary data is
transmitted - very few of our customers insist on this).

> Together with this, we can
> recommend that in
> order to avoid IP fragmentation and potential firewall,
> performance and
> reliability issues, it is recommended that on the Ethernet
> users strive
> to restrict most syslog messages to 512 bytes.

With the added header fields, the potential 255 byte FQDN in the header
and the structured data elements, payload can be a very limited set of
these 512 bytes ... but I still agree, it should be fine for most
messages.

> This
> recommendation will
> also potentially improve readability of messages. By removing
> the syslog
> fragmentation from -protocol, we will leave fragmentation in one place
> -- IP and allow for more efficient syslog implementations.

I don't like this for the reasons stated above, mainly because of the
insufficient max size. I am also not sure if it can cause troubles with
other transport mappings (syslog over snmp trap was already discussed
recently in this WG).

What does the rest of the WG think?

Rainer

>
> Anton.
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Wednesday, February 11, 2004 11:57 AM
> > To: [email-masked]; Anton Okmianski
> > Subject: syslog message size and fragmentation
> >
> >
> > Hi WG,
> >
> > I had an off-list discussion with Anton that lead to the
> > discovery of a new issue in -protocol, that of message
> > fragmentation. -protocol specifies a message size limit of
> > 1024 characters, but also assumes that message of this size
> > can always be transmitted without (transport) fragemention.
> > In the real world, datagram based transport mappings will
> > probably not be able to assure that the message will not
> > become fragmented. The MTU can at least be as low as 576 bytes.
> >
> > Must this issue be addressed in the context of -protocol? If
> > so, what is the best solution?
> >
> > Thanks,
> > Rainer
> >
>
>
>
>

------------------------------

Date: Thu, 12 Feb 2004 08:49:49 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

You might also want to review draft-jones-opsec-03.txt concerning the
use of UTC time.

dbh

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2004 6:38 PM
> To: [email-masked]
> Subject: RFC 3339 & UTC offset
>
> Just noticed this in RFC 3339 (Section 4.4):
>
> "Systems that are configured with a local time, are unaware
> of the corresponding UTC offset, and depend on time
> synchronization with other Internet systems, MUST use a
> mechanism that ensures correct synchronization with UTC."
>
> Since -protocol is a distributed protocol where multiple
> hosts can generate syslog messages to one syslog server, one
> can say that syslog "depends on hosts synchronization with
> other Internet systems".  Does this mean that syslog clients
> and servers MUST be aware of their UTC offset?  Are we going
> to require this in -protocol?  Besides, I don't think RFC
> 3339 specifies any designation for "unknown" offset, so what
> will such client provide?
>
> Anton.
>
> PS:  BTW, just as an FYI, I searched rfc-editor.org web site
> and came across only one other RFC which uses RFC 3339 format
> (RFC3340).  I think if we are worried about acceptability of
> -protocol, this could be yet another slight concern.  I think
> RFC 3339 time stamp is unlike anything that is in wide use
> and people may have some initial reservations about it until
> it becomes more accepted.  I like it, accept for "T" and "Z"
> characters. Unfortunately, ANSI and ISO standards are worse.
>
>
>
>

------------------------------

Date: Thu, 12 Feb 2004 08:49:49 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Hi,

I agree that we cannot demand mechanisms for correct synchronization. We
can provide a means to set the timezone, and recommend it be set
automatically via NTP. Following the recommendations of
draft-jones-opsec-03.txt, we should also allow an admin to set an object
that contains the offset from UTC.

These are two objects that could be defined in the syslog mib. Since
other protocols may also want to have such a capability, and a standard
mib for time-sync could be done at some time, I recommend developing
syslog objects for this, which other protocols could reuse of desired,
but also design them such that they could rfelect the values set via
other mechanisms, such as NTP.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2004 8:48 AM
> To: Anton Okmianski; [email-masked]
> Subject: RE: RFC 3339 & UTC offset
>
> > Just noticed this in RFC 3339 (Section 4.4):
> >
> > "Systems that are configured with a local time, are unaware
> > of the corresponding UTC offset, and depend on time
> > synchronization with other Internet systems, MUST use a
> > mechanism that ensures correct synchronization with UTC."
> >
> > Since -protocol is a distributed protocol where multiple
> > hosts can generate syslog messages to one syslog server, one
> > can say that syslog "depends on hosts synchronization with
> > other Internet systems".  Does this mean that syslog clients
> > and servers MUST be aware of their UTC offset?  Are we going
> > to require this in -protocol?  Besides, I don't think RFC
> > 3339 specifies any designation for "unknown" offset, so what
> > will such client provide?
>
> Actually, I think we can't ensure this. The real world is against us.
> You are right, I should specify that a syslog sender MUST offer a way
> learn its time zone, but I am very hesitant to demand time sync for
> syslog. I guess everybody in this WG knows how important time sync is,
> yet this is a real-life issue. Admin's don't use NTP, they don't
> configure time zones and device clocks are often set to wild values.
>
> So I think we should demand the capability to set the time zone in any
> syslog sender - but not go any further.
>
> >
> > Anton.
> >
> > PS:  BTW, just as an FYI, I searched rfc-editor.org web site
> > and came across only one other RFC which uses RFC 3339 format
> > (RFC3340).  I think if we are worried about acceptability of
> > -protocol, this could be yet another slight concern.  I think
> > RFC 3339 time stamp is unlike anything that is in wide use
> > and people may have some initial reservations about it until
> > it becomes more accepted.  I like it, accept for "T" and "Z"
> > characters.
>
> I, too, disliked this when I came across it the first time.
> But when you
> begin to actually develop applications, the "T" is a great, quick
> shortcut to detect that it is actually an ISO date.
>
> > Unfortunately, ANSI and ISO standards are worse.
>
> I think this is the most important argument why I selected 3339 - I
> don't like to invent yet another timestamp, the older
> timestamps either
> lack the year or the time zone or resolution or ... and the other
> standards are worse. Plus, I like to stick refering to RFCs, because
> these are available without purchasing (expensive) books [which also
> means RFCs are instantly available when you need them...].
>
> Rainer
>
>
>

------------------------------

Date: Thu, 12 Feb 2004 08:49:49 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: syslog message size and fragmentation

Hi,

You should also keep in mind, for SNMP/syslog interaction, that SNMP/UDP
messages should not be fragmented if possible, to handle the case when
some packets are dropped.

To claim compliance with the standard, implementors must support
messages up to and including 484 octets. They are encouraged to support
larger sizes up to 1472 octets. The 1472 number is the largest SNMP
message that will fit into an Ethernet packet without forcing
fragmentation, if I remember correctly.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2004 11:57 AM
> To: [email-masked]; Anton Okmianski
> Subject: syslog message size and fragmentation
>
> Hi WG,
>
> I had an off-list discussion with Anton that lead to the
> discovery of a
> new issue in -protocol, that of message fragmentation. -protocol
> specifies a message size limit of 1024 characters, but also
> assumes that
> message of this size can always be transmitted without (transport)
> fragemention. In the real world, datagram based transport
> mappings will
> probably not be able to assure that the message will not become
> fragmented. The MTU can at least be as low as 576 bytes.
>
> Must this issue be addressed in the context of -protocol? If
> so, what is
> the best solution?
>
> Thanks,
> Rainer
>
>
>

------------------------------

Date: Thu, 12 Feb 2004 15:18:09 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog message size and fragmentation

David,

> You should also keep in mind, for SNMP/syslog interaction,
> that SNMP/UDP
> messages should not be fragmented if possible, to handle the case when
> some packets are dropped.
>
> To claim compliance with the standard, implementors must support
> messages up to and including 484 octets. They are encouraged
> to support
> larger sizes up to 1472 octets. The 1472 number is the largest SNMP
> message that will fit into an Ethernet packet without forcing
> fragmentation, if I remember correctly.

as I outlined in a message in reply to Anton (which probably did not
reach you by now), I am in strong favour of NOT extending beyond 1024
bytes. But do you have a recommendation/experience on what we should do
if the transport can not (reliably) support those 1024 bytes? 484 octets
is very short for syslog. So if we set a fixed limit and set it to 484,
there is virtually no space left for actual payload in some
circumstances.

And the bad thing... syslog is SIMPLEX... That means the sender has no
way to discover the MTU via the syslog protocol - simply because there
is no interaction with the receiver (and definitely not with the
ultimate receiver in a relay chain).

MTU discovery, at least in IPv4, does not work reliably (eg firewall
filtering ICMP), so I don't think this is an option. Its also quite
complex.

I have to admit I am currently struck and have no clue about what a good
way to handle this situation would be. Again, please keep in mind syslog
is SIMPLEX!

Any advise is deeply appreciated,
Rainer

>
> dbh
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Wednesday, February 11, 2004 11:57 AM
> > To: [email-masked]; Anton Okmianski
> > Subject: syslog message size and fragmentation
> >
> > Hi WG,
> >
> > I had an off-list discussion with Anton that lead to the
> > discovery of a
> > new issue in -protocol, that of message fragmentation. -protocol
> > specifies a message size limit of 1024 characters, but also
> > assumes that
> > message of this size can always be transmitted without (transport)
> > fragemention. In the real world, datagram based transport
> > mappings will
> > probably not be able to assure that the message will not become
> > fragmented. The MTU can at least be as low as 576 bytes.
> >
> > Must this issue be addressed in the context of -protocol? If
> > so, what is
> > the best solution?
> >
> > Thanks,
> > Rainer
> >
> >
> >
>

------------------------------

Date: Thu, 12 Feb 2004 10:11:23 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: syslog message size and fragmentation

Hi,

I pointed out the SNMP limitation only in consideration of SNMP/syslog
integration - for example, many SNMP managers and agents are probably
not going to be able to handle notifications with payloads in excess of
1472 bytes easily, and some won't handle payloads above 484 octets. I
don't think we should design for the worst case though. I think it is
reasonable to expect most current SNMP/UDP/Ethernet implementations to
support 1472 octets, especially since RFC3417 recommends supporting that
size for a UDP mapping.

The SNMP notification should set a limit on the size or mention that
there may be interoperability issues above 1472 octets.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Thursday, February 12, 2004 9:18 AM
> To: Harrington, David; [email-masked]; Anton Okmianski
> Subject: RE: syslog message size and fragmentation
>
> David,
>
> > You should also keep in mind, for SNMP/syslog interaction,
> > that SNMP/UDP
> > messages should not be fragmented if possible, to handle
> the case when
> > some packets are dropped.
> >
> > To claim compliance with the standard, implementors must support
> > messages up to and including 484 octets. They are encouraged
> > to support
> > larger sizes up to 1472 octets. The 1472 number is the largest SNMP
> > message that will fit into an Ethernet packet without forcing
> > fragmentation, if I remember correctly.
>
> as I outlined in a message in reply to Anton (which probably did not
> reach you by now), I am in strong favour of NOT extending beyond 1024
> bytes. But do you have a recommendation/experience on what we
> should do
> if the transport can not (reliably) support those 1024 bytes?
> 484 octets
> is very short for syslog. So if we set a fixed limit and set
> it to 484,
> there is virtually no space left for actual payload in some
> circumstances.
>
> And the bad thing... syslog is SIMPLEX... That means the sender has no
> way to discover the MTU via the syslog protocol - simply because there
> is no interaction with the receiver (and definitely not with the
> ultimate receiver in a relay chain).
>
> MTU discovery, at least in IPv4, does not work reliably (eg firewall
> filtering ICMP), so I don't think this is an option. Its also quite
> complex.
>
> I have to admit I am currently struck and have no clue about
> what a good
> way to handle this situation would be. Again, please keep in
> mind syslog
> is SIMPLEX!
>
> Any advise is deeply appreciated,
> Rainer
>
> >
> > dbh
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[email-masked]]
> > > Sent: Wednesday, February 11, 2004 11:57 AM
> > > To: [email-masked]; Anton Okmianski
> > > Subject: syslog message size and fragmentation
> > >
> > > Hi WG,
> > >
> > > I had an off-list discussion with Anton that lead to the
> > > discovery of a
> > > new issue in -protocol, that of message fragmentation. -protocol
> > > specifies a message size limit of 1024 characters, but also
> > > assumes that
> > > message of this size can always be transmitted without (transport)
> > > fragemention. In the real world, datagram based transport
> > > mappings will
> > > probably not be able to assure that the message will not become
> > > fragmented. The MTU can at least be as low as 576 bytes.
> > >
> > > Must this issue be addressed in the context of -protocol? If
> > > so, what is
> > > the best solution?
> > >
> > > Thanks,
> > > Rainer
> > >
> > >
> > >
> >
>

------------------------------

Date: Thu, 12 Feb 2004 11:06:25 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: syslog message size and fragmentation

Rainer:

> I have to admit I am not 100% sure what the UDP spec says: If
> a UDP packet becomes fragmented (due to MTU), is it
> guaranteed that the packet will be re-assembled by the
> receivers IP stack before it is passed up to the app layer?
> What if a fragment is missing? Will the whole packet be
> discarded by the stack (UDP is best effort, after all...)?

Postel's UDP RFC768 from 1980 is 3 pages long with references. Ah, the
good old times! :) It talks about very few things.  Besides,
fragmentation is an IP layer issue and not UDP.  IP layer must
reassemble the whole packet before providing it to the next layer - be
it UDP or TCP.  So, yes, if one fragment is lost, the whole datagram is
discarded.

From what I understand fragmentation should be avoided (but not at all
costs) due to the following:

 - performance of fragmenting & reassembly
 - higher risk of datagram loss due to fragment loss
 - broken "stateless" firewalls

Any other reasons we know of?

> I would appreciate if someone saves me the time of reading
> the UDP RFCs...

Some pointer on fragmentation and MTU size:

RFC1122 Section 3.3.3:

"It is generally desirable to avoid local fragmentation and to choose
EMTU_S low enough to avoid fragmentation in any gateway along the path.
In the absence of actual knowledge of the minimum MTU along the path,
the IP layer SHOULD use EMTU_S <= 576 whenever the destination address
is not on a connected network, and otherwise use the connected network's
MTU."

...

"In general, no host is required to accept an IP datagram larger than
576 bytes (including header and data), so a host must not send a larger
datagram without explicit knowledge or prior arrangement with the
destination host."

- ------

I think it would not hurt to point out some the potential fragmentation
issues in -transport and *recommend* a message size smaller than 548
bytes (576 minus IP/UDP headers).

From Stevens: "Many UDP applications are designed to restrict their
application data to 512 bytes or less, to stay below the [576 byte]
limit".  He also mentions his experiments in which very few OS actually
support transmitting or receiving maximum UDP packet size of 64Kb. So, I
guess 64Kb limit is problematic for reasons other than fragmentation.

But if we impose 1024 byte limit, let's at least make it something that
is closer to using the whole Ethernet 1500 frame or at least close to
IPv6 minimum MTU, which I think is 1280 bytes. This would still be
consistent with SNMP requirements, which seems to stem from the same
limitation of 1500 byte frame minus IP/UDP header of 28 bytes = 1472.

Thanks,
Anton.

------------------------------

Date: Thu, 12 Feb 2004 17:55:08 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog message size and fragmentation

Hi Anton,

thanks for this very helpful post.

> > I have to admit I am not 100% sure what the UDP spec says: If
> > a UDP packet becomes fragmented (due to MTU), is it
> > guaranteed that the packet will be re-assembled by the
> > receivers IP stack before it is passed up to the app layer?
> > What if a fragment is missing? Will the whole packet be
> > discarded by the stack (UDP is best effort, after all...)?
>
> Postel's UDP RFC768 from 1980 is 3 pages long with references. Ah, the
> good old times! :)

indeed ;)

> It talks about very few things.  Besides,
> fragmentation is an IP layer issue and not UDP.  IP layer must
> reassemble the whole packet before providing it to the next layer - be
> it UDP or TCP.  So, yes, if one fragment is lost, the whole
> datagram is
> discarded.

That's fine with me. If don't receive a partial message and everything
is lost, I think this is consistent. If you use UDP, you have accepted
packet loss ;)

[snip useful info for brevity]

> So, I
> guess 64Kb limit is problematic for reasons other than
> fragmentation.
>
> But if we impose 1024 byte limit, let's at least make it
> something that
> is closer to using the whole Ethernet 1500 frame or at least close to
> IPv6 minimum MTU, which I think is 1280 bytes. This would still be
> consistent with SNMP requirements, which seems to stem from the same
> limitation of 1500 byte frame minus IP/UDP header of 28 bytes = 1472.

That sounds like a good compromise from my point of view. I'd agree on
solving this issue as follows (just a sum-up of your points to show if I
have correctly understood):

#1 we allow up to 1280 bytes inside the syslog message
#2 we recommend to place important data early in the message
#3 we warn that a transport mapping may truncate the message
   after 484 bytes (SNMP lowest limit as of David's post)

Every transport mapping is allowed to use #3 at liberty (but should try
to avoid it). It is NOT required to ensure that the whole syslog message
will be transmitted.

This will cause potential interop issues in rare cases, but I think they
can be addressed, esepcially if

#4 we recommend / demand (?) that an implementation must
   provide an operator-configurable max message size
   (configurable between 484 and 1280 bytes)

So a proper implementation would look at the operator configured value
(default of 1280). So the operator can fine-tune is he has actually one
of the rare cases where the size limitation is very low.

That all sounds fine to me and I would edit -protcol-03 to include this
if nobody objects or has a better solution.

I would appreciate if somebody who eventually knows quickly could
confirm the 1280 byte IPv6 minimum MTU.

Thanks,
Rainer

------------------------------

Date: Thu, 12 Feb 2004 09:19:03 -0800
From: Devin Kowatch <[email-masked]>
Subject: Re: RFC 3339 & UTC offset

On Wed, Feb 11, 2004 at 06:35:28PM +0100, Rainer Gerhards wrote:
> Anton,
>
> this is a tough one ;)
>
> > Well, I think demanding that capability is more about host
> > implementation.  I think it is better to focus on the
> > protocol and what
> > the client/sender must put into the UTC offset field if one is not set
> > on the system.
>
> This is right. And I have to admit it is an important issue. We always
> have nightmares about non-timesynced devices, as many customers have. In
> fact, the default of our product is to use time of reception, not the
> time from the message timestamp. I guess this shows it actually *is* a
> real world issue...
[ snip ]

The problem that I have with these solutions is that they require the
syslog daemon to know if the time and timezone on the machine are valid.
I can't think of any way of doing that.  I'd would be perfectly happy
with a recomendadtion that the hosts should hove the correct
time/timezone information.  However, ultimatly it's the sys admin's
problem if their machines have incorrect time/timezone.  And the sys
admin which will suffer for it.

This isn't meat to trivialize the issue, but I don't think that it's a
problem which we should try to solve in the syslog protocol.  You can
only do so much to protect people from them selves.

My $0.02

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Thu, 12 Feb 2004 18:26:24 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

one more thing... I just got a - I think - good idea. We could say that
by default, we don't fully trust the timestamp. Then, we could define an
optional structured data element (hey, we've got those!) that says "yes,
you can trust my time". This could also be extended for use by
timestamper services.

Out of the options so far, I like this one most...

Rainer

> -----Original Message-----
> From: Devin Kowatch [mailto:[email-masked]]
> Sent: Thursday, February 12, 2004 6:19 PM
> To: Rainer Gerhards
> Cc: Anton Okmianski; [email-masked]
> Subject: Re: RFC 3339 & UTC offset
>
> On Wed, Feb 11, 2004 at 06:35:28PM +0100, Rainer Gerhards wrote:
> > Anton,
> >
> > this is a tough one ;)
> >
> > > Well, I think demanding that capability is more about host
> > > implementation.  I think it is better to focus on the
> > > protocol and what
> > > the client/sender must put into the UTC offset field if
> one is not set
> > > on the system.
> >
> > This is right. And I have to admit it is an important
> issue. We always
> > have nightmares about non-timesynced devices, as many
> customers have. In
> > fact, the default of our product is to use time of
> reception, not the
> > time from the message timestamp. I guess this shows it
> actually *is* a
> > real world issue...
> [ snip ]
>
> The problem that I have with these solutions is that they require the
> syslog daemon to know if the time and timezone on the machine
> are valid.
> I can't think of any way of doing that.  I'd would be perfectly happy
> with a recomendadtion that the hosts should hove the correct
> time/timezone information.  However, ultimatly it's the sys admin's
> problem if their machines have incorrect time/timezone.  And the sys
> admin which will suffer for it.
>
> This isn't meat to trivialize the issue, but I don't think that it's a
> problem which we should try to solve in the syslog protocol.  You can
> only do so much to protect people from them selves.
>
> My $0.02
>
> --
> Devin Kowatch
> [email-masked]
>

------------------------------

Date: Thu, 12 Feb 2004 18:24:12 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

> The problem that I have with these solutions is that they require the
> syslog daemon to know if the time and timezone on the machine
> are valid.
> I can't think of any way of doing that.

Actually, I think this is the easy part. Its a trivial solution, but I
think it works. I think we can require that a syslog implementation - by
default - sets a "I am not sure about my time" flag. This is changed
only after the operator configures it to be differently.

> I'd would be perfectly happy
> with a recomendadtion that the hosts should hove the correct
> time/timezone information.  However, ultimatly it's the sys admin's
> problem if their machines have incorrect time/timezone.  And the sys
> admin which will suffer for it.
>
> This isn't meat to trivialize the issue, but I don't think that it's a
> problem which we should try to solve in the syslog protocol.  You can
> only do so much to protect people from them selves.

I think this time its worth doing it. I see a real-world issue here. I
see a fairly simple solution for most of the part. I am still missing a
solution for this in the message. But I begin to recommend that we
actually put this "reliable time info" flag in a one-byte header field.
Looks ugly, but solves an issue...

Rainer

------------------------------

Date: Thu, 12 Feb 2004 18:46:19 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

> > Actually, I think this is the easy part. Its a trivial
> solution, but I
> > think it works. I think we can require that a syslog
> implementation - by
> > default - sets a "I am not sure about my time" flag. This is changed
> > only after the operator configures it to be differently.
> This isn't really solving the prbolem it is doging the
> problem.  Using a
> configuration variable for this parameter does not add any useful
> information to the syslog message.  If the admin set the parameter in
> the first place then they know their time is correct so why
> should enver
> syslog message tell them that?  Also it just lets the admin lie about
> how correct their time is, so whats the use.

I am just responding to this because I think the other comments boild
down to this one.

My point is that some things my simply be overlooked. OK, we may not
want to make it foolproof. But does it really hurt? IF the admin goes to
the box and says "hey, you are synced" than at least the admin has put
some manual effort and taken over the responsibility. If the box is just
plugged and not properly configured, it will use the default which says
"I can't be fully trusted". In a larger enterprise, a higher level admin
(or a co-worker) may detect this failure which otherwise may be
undetected.

As I said, this is a real-world issue. We have changed the default in
our products so that they DO NOT use the syslog message timestamp,
simply because this caused too much trouble. Once we told customers to
switch to replace it with the syslogd's local reception time, this
trouble ends.

I think this flag can adress the need. But maybe I am going overboard.
Anyone else with comments?

Rainer

------------------------------

Date: Thu, 12 Feb 2004 09:38:40 -0800
From: Devin Kowatch <[email-masked]>
Subject: Re: RFC 3339 & UTC offset

On Thu, Feb 12, 2004 at 06:24:12PM +0100, Rainer Gerhards wrote:
> > The problem that I have with these solutions is that they require the
> > syslog daemon to know if the time and timezone on the machine
> > are valid.
> > I can't think of any way of doing that.
>
> Actually, I think this is the easy part. Its a trivial solution, but I
> think it works. I think we can require that a syslog implementation - by
> default - sets a "I am not sure about my time" flag. This is changed
> only after the operator configures it to be differently.
This isn't really solving the prbolem it is doging the problem.  Using a
configuration variable for this parameter does not add any useful
information to the syslog message.  If the admin set the parameter in
the first place then they know their time is correct so why should enver
syslog message tell them that?  Also it just lets the admin lie about
how correct their time is, so whats the use.

>
> > I'd would be perfectly happy
> > with a recomendadtion that the hosts should hove the correct
> > time/timezone information.  However, ultimatly it's the sys admin's
> > problem if their machines have incorrect time/timezone.  And the sys
> > admin which will suffer for it.
> >
> > This isn't meat to trivialize the issue, but I don't think that it's a
> > problem which we should try to solve in the syslog protocol.  You can
> > only do so much to protect people from them selves.
>
> I think this time its worth doing it. I see a real-world issue here. I
> see a fairly simple solution for most of the part. I am still missing a
> solution for this in the message. But I begin to recommend that we
> actually put this "reliable time info" flag in a one-byte header field.
> Looks ugly, but solves an issue...

Again why.  Syslog is generally used internal to an organization.  It's
is the problem of each organization to determine how to get correct time
on their machines and if they care.  I agree that having correct time on
a box is important, but I don't think that we should add extra complexit
to syslog just to tell the sys admin that their time is incorrect.  I
guess the biggest problem I have with this is that if the "reliable time
info" flag is not reliable then what's the point?

If you are dead set on having some indication of time correctness, try
adding a timestamp for each relay that the message passes through (and
the final server, but that is a file format issue), or use RFC3195 with
SYSLOG/COOKED and path elements.
- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Thu, 12 Feb 2004 13:46:52 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: syslog message size and fragmentation

Hi,

An SNMP engine won't truncate an octet string to fit within 484 bytes to
my knowledge.

If the limitng factor is the sender, the sending engine probably just
won't send it; it might tell the requesting application it cannot handle
that size message, but that would be an implementation-specific detail
that is not part of SNMP. If you want to have the syslog engine trim the
data before sending it to the SNMP engine, you'll need to write that
into the syslog standard or recommendations; the syslog engine would
need to determine the max message size that the sending SNMP and
receiving SNMP engines can handle. SNMP does not provide an API for the
syslog application to use to get this info, although SNMPv3 messages
contain a max message size field to advise other snmp engines with which
it communicates about an engine's limits.

If the limiting factor is the snmp receiver, the snmp receiver will
simply refuse it with an error code of tooBig (and in snmpv3 will report
its maxmessagesize in the response message).

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Thursday, February 12, 2004 11:55 AM
> To: Anton Okmianski; [email-masked]
> Subject: RE: syslog message size and fragmentation
>
> Hi Anton,
>
> thanks for this very helpful post.
>
> > > I have to admit I am not 100% sure what the UDP spec says: If
> > > a UDP packet becomes fragmented (due to MTU), is it
> > > guaranteed that the packet will be re-assembled by the
> > > receivers IP stack before it is passed up to the app layer?
> > > What if a fragment is missing? Will the whole packet be
> > > discarded by the stack (UDP is best effort, after all...)?
> >
> > Postel's UDP RFC768 from 1980 is 3 pages long with
> references. Ah, the
> > good old times! :)
>
> indeed ;)
>
> > It talks about very few things.  Besides,
> > fragmentation is an IP layer issue and not UDP.  IP layer must
> > reassemble the whole packet before providing it to the next
> layer - be
> > it UDP or TCP.  So, yes, if one fragment is lost, the whole
> > datagram is
> > discarded.
>
> That's fine with me. If don't receive a partial message and everything
> is lost, I think this is consistent. If you use UDP, you have accepted
> packet loss ;)
>
> [snip useful info for brevity]
>
> > So, I
> > guess 64Kb limit is problematic for reasons other than
> > fragmentation.
> >
> > But if we impose 1024 byte limit, let's at least make it
> > something that
> > is closer to using the whole Ethernet 1500 frame or at
> least close to
> > IPv6 minimum MTU, which I think is 1280 bytes. This would still be
> > consistent with SNMP requirements, which seems to stem from the same
> > limitation of 1500 byte frame minus IP/UDP header of 28
> bytes = 1472.
>
> That sounds like a good compromise from my point of view. I'd agree on
> solving this issue as follows (just a sum-up of your points
> to show if I
> have correctly understood):
>
> #1 we allow up to 1280 bytes inside the syslog message
> #2 we recommend to place important data early in the message
> #3 we warn that a transport mapping may truncate the message
>    after 484 bytes (SNMP lowest limit as of David's post)
>
> Every transport mapping is allowed to use #3 at liberty (but
> should try
> to avoid it). It is NOT required to ensure that the whole
> syslog message
> will be transmitted.
>
> This will cause potential interop issues in rare cases, but I
> think they
> can be addressed, esepcially if
>
> #4 we recommend / demand (?) that an implementation must
>    provide an operator-configurable max message size
>    (configurable between 484 and 1280 bytes)
>
> So a proper implementation would look at the operator configured value
> (default of 1280). So the operator can fine-tune is he has
> actually one
> of the rare cases where the size limitation is very low.
>
> That all sounds fine to me and I would edit -protcol-03 to
> include this
> if nobody objects or has a better solution.
>
> I would appreciate if somebody who eventually knows quickly could
> confirm the 1280 byte IPv6 minimum MTU.
>
> Thanks,
> Rainer
>
>
>

------------------------------

Date: Thu, 12 Feb 2004 13:56:18 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Hi,

Who makes the assertion that "you can trust my timestamp"? An
application? As Devin points out, an application has no way to determine
whether a timestsamp is valid, and thus cannot be trusted to make a
valid assertion on its own.

The best you could do is allow an administrator to set a value (maybe
via a mib object) that asserts "the timestamps used by this syslog
engine are reasonably valid", and it would be up to the administrator to
make sure the assertion is reasonably valid.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Thursday, February 12, 2004 12:26 PM
> To: Devin Kowatch
> Cc: Anton Okmianski; [email-masked]
> Subject: RE: RFC 3339 & UTC offset
>
> one more thing... I just got a - I think - good idea. We
> could say that
> by default, we don't fully trust the timestamp. Then, we
> could define an
> optional structured data element (hey, we've got those!) that
> says "yes,
> you can trust my time". This could also be extended for use by
> timestamper services.
>
> Out of the options so far, I like this one most...
>
> Rainer
>
> > -----Original Message-----
> > From: Devin Kowatch [mailto:[email-masked]]
> > Sent: Thursday, February 12, 2004 6:19 PM
> > To: Rainer Gerhards
> > Cc: Anton Okmianski; [email-masked]
> > Subject: Re: RFC 3339 & UTC offset
> >
> > On Wed, Feb 11, 2004 at 06:35:28PM +0100, Rainer Gerhards wrote:
> > > Anton,
> > >
> > > this is a tough one ;)
> > >
> > > > Well, I think demanding that capability is more about host
> > > > implementation.  I think it is better to focus on the
> > > > protocol and what
> > > > the client/sender must put into the UTC offset field if
> > one is not set
> > > > on the system.
> > >
> > > This is right. And I have to admit it is an important
> > issue. We always
> > > have nightmares about non-timesynced devices, as many
> > customers have. In
> > > fact, the default of our product is to use time of
> > reception, not the
> > > time from the message timestamp. I guess this shows it
> > actually *is* a
> > > real world issue...
> > [ snip ]
> >
> > The problem that I have with these solutions is that they
> require the
> > syslog daemon to know if the time and timezone on the machine
> > are valid.
> > I can't think of any way of doing that.  I'd would be
> perfectly happy
> > with a recomendadtion that the hosts should hove the correct
> > time/timezone information.  However, ultimatly it's the sys admin's
> > problem if their machines have incorrect time/timezone.  And the sys
> > admin which will suffer for it.
> >
> > This isn't meat to trivialize the issue, but I don't think
> that it's a
> > problem which we should try to solve in the syslog
> protocol.  You can
> > only do so much to protect people from them selves.
> >
> > My $0.02
> >
> > --
> > Devin Kowatch
> > [email-masked]
> >
>
>
>

------------------------------

Date: Thu, 12 Feb 2004 16:43:08 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Hi!

I will reply to various emails in one.

> Who makes the assertion that "you can trust my timestamp"? An
> application? As Devin points out, an application has no way
> to determine whether a timestsamp is valid, and thus cannot
> be trusted to make a valid assertion on its own.

Application can know if NTP is configured.  Or administrator can set it.
In fact, Cisco devices follow a similar convention in logging (including
through syslog).  I am not advocating doing anything just because Cisco
does it and I work there :), but it just shows that some vendors find
some convention for time sync indication useful.

Cisco devices prefix the timestamp with "*" or "." when they know that
time is not authoritative, i.e. NTP is not setup or is not working
properly (i.e network connection lost).  NTP can be integrated into
whatever application I think. I like the general idea of some indication
since we can't require time synchronization AND what's important won't
always be possible.  What if you want to report an NTP client error?

> From: Devin Kowatch
...
> I guess the biggest problem I have with
> this is that if the "reliable time info" flag is not reliable
> then what's the point?

Well, what part of syslog is reliable?  Security is a different issue
IMO.  Sure people can lie, but that does not mean we should not give
good admins a useful option to simplify their administration of a large
farm of servers. How people decide to use or not use this indication
will be different in different deployments I think.  So, I'd go for
something that does not take to much space.

> From: Rainer Gerhards [mailto:[email-masked]]
...
> one more thing... I just got a - I think - good idea. We
> could say that by default, we don't fully trust the
> timestamp. Then, we could define an optional structured data
> element (hey, we've got those!) that says "yes, you can trust
> my time". This could also be extended for use by timestamper services.

I just don't like "punishing" the good client which has synchronized
time by making it send more data in a structured element.  I think the
overhead, if any should be on the clients which don't know if time is
authoritative. IMO we should assume that people should setup time sync
in most cases.

> -----Original Message-----
> From: Devin Kowatch
> Sent: Thursday, February 12, 2004 12:39 PM
...
> If you are dead set on having some indication of time
> correctness, try adding a timestamp for each relay that the
> message passes through (and the final server, but that is a
> file format issue),

I like this idea, but I don't think it solves the problem.  Time of
origination is what is used to establish message order for one and
multiple hosts. Time of reception can be different including order.

I think time of reception is a good thing to keep (for cases where
origin time is unreliable), and I think it would be nice if first relay
could add this information (but not overwrite original data).  Maybe add
a structured element?  BTW, is relay prohibited from adding information
to the message?  I also talked about source IP as potentially another
thing you may want relay to add.

>or use RFC3195 with SYSLOG/COOKED and
> path elements.

But what about UDP transport?

- ----------

We jumped to time synchronization issue (which is fine), while my
original issue got forgotten.  I was actually raising the issue of UTC
offset.  Some systems may know their time, but have no idea about their
offset from UTC.  What should they put as UTC offset value in the
timestamp?  Random value? I think this is an issue we have to address
even if we provide for some flag that is incorrect. I propose that they
put "-----" instead of an offset or we come up with another suffix like
"U" for unknown.

- ----------

Still on the same subject of timestamps, but yet another issue. Do we
want to come up with some timestamp format that devices can put when
they don't know their time?  For example: --------T-----------Z?  It
seems we have scoped it out, but it is a problem.  Cisco has a number of
devices that maybe unaware of their clock.  Cisco currently sends
messages with uptime (like 8d5h3m) instead of timestamp when this is the
case.  If Cisco where to adopt -protocol, they will need to deal with
this one way or the other. How?  Unless -protocol specifies this, they
will have to invent something, then Nortel will invent something,
Juniper, etc... Not good.

I am not speaking for Cisco, but from experience of trying to
standardize logging within Cisco.  When I tried to scope out devices
that have no knowledge of time, I got a pushback & we had to add support
for unknown date/time.

I think "uptime" can be left out of scope and be a vendor structured
parameter for now.

Thanks,
Anton.

------------------------------

Date: Thu, 12 Feb 2004 17:38:55 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Rainer:

> #1 is more a spec-stunt than a real solution ;)
>    In 4.4, RFC 3339 says
>
>    ###
>    o  Use another host in the same local time zone as a gateway to the
>       Internet.  This host MUST correct unqualified local
> times that are
>       transmitted to other hosts.
>    ###

Definitely a stunt. :)  This requirement is constraining deployment
options.

> #2 is to "tweak" the format a little bit. Honestly, I don't
> like this messing with a standard, and this is very far to the edge...
>
> All special sequences (like "-00:00") are already taken up.
> 3339, however, specifies that the "Z" UTC indicator can be
> either upper or lower case. I have choosen to allow only
> upper case for simplicity. We
> *could* say that if the device does not know its ZT and does
> not know if time is properly synced, it should use "z" (lower
> case) as the TZ indicator. This would still be a valid 3339
> indicator, but definitely not be in the spirit of 3339.

I think it is okay, although the distinction is not as clear as I'd
prefer.  I like "-----" for offset because this removes ambiguity.  I
know it is not consistent with RFC3339, but RFC3339 format is ONLY for
situations when you know the offset, which won't always be the case for
syslog clients.  So, I guess in some cases RFC3339 is not appropriate.

> #3 is to actually add a syslog header field "I know my TZ
> info or I am synced" (Y/N) in -protcol, eventually adjecent
> to the timestamp field. Honestly, this, too, does not smell
> really good to me.

I think the "I am sync'ed" maybe be different than "I know my TZ". For
example, you maybe no be sync'ed but know your time zone.

This brings up another question that maybe other people raised before.
I guess there are cases when you know the time is definitely NOT synced.
But when do we consider it synced? What's the precision of sync'ed? Does
it mean it is sync'ed with NTP or set manually yesterday?

I guess for some cases "set manually yesterday" is fine, but for other
cases (say when correlating messages from multiple systems based on
precise time) this is not good enough because clocks drift and manually
set time can't be precise. So, maybe this is a deployment-specific
decision how the "authoritative-time" flag is interpreted?

Anton.

------------------------------

Date: Thu, 12 Feb 2004 18:20:44 -0500
From: Anton Okmianski <[email-masked]>
Subject: Fragmentation terminology

Rainer:

If we keep the syslog fragmentation feature in -protocol, can we change
its name to something that can't be confused with IP fragments.
Otherwise, I think it can creates confusion when one talks about syslog
message fragments.  "Segments" I think is also a term that is already
commonly used in TCP.

Maybe "multi-part" message and "message part" instead?  I need a way to
refer to those pieces in -transport hopefully without having to explain
what kind of fragment I am referring to.

Thanks,
Anton.

------------------------------

Date: Fri, 13 Feb 2004 09:10:48 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Fragmentation terminology

Anton,

very reasonable ;)

I think "multi-part" is a good term. OK, it triggers "MIME" in my head,
but I think every term used to split up a message into multipe
parts/fragments/segemnts/whatever is already used in some other context.
As we don't do MIME in syslog, "multi-part" should cause the least
confusion. I am going to change this in -protocol-03 if nobody objects.

Rainer

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Friday, February 13, 2004 12:21 AM
> To: [email-masked]
> Subject: Fragmentation terminology
>
> Rainer:
>
> If we keep the syslog fragmentation feature in -protocol, can
> we change
> its name to something that can't be confused with IP fragments.
> Otherwise, I think it can creates confusion when one talks
> about syslog
> message fragments.  "Segments" I think is also a term that is already
> commonly used in TCP.
>
> Maybe "multi-part" message and "message part" instead?  I
> need a way to
> refer to those pieces in -transport hopefully without having
> to explain
> what kind of fragment I am referring to.
>
> Thanks,
> Anton.
>
>
>
>
>

------------------------------

Date: Fri, 13 Feb 2004 15:20:11 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

I have gone through all of the good posts on this issue. I have the
feeling that we currently have the following status:

- - some people argue that a "synced/I know my TZ" indicator for the
  timestmap has advantages in the real world
- - some people argue that a "synced/I know my TZ" indicator for the
  timestamp has no advantege in the real world, because nobody can
  automatically assert the timestamp
- - among those who would like to have a timestamp, there are some
  that would favour chaging the RFC3339 stamp and others who not like
  this idea. All of those who do not like the indicator do also not
  like changing the timestamp in a non-standard way.
- - if an indicator would be provided, I think it is concensus that this
  indicator should take up only very limited message space in the
  usual [?;)] case of synced time and known TZ
- - there is more than one issue, effectively, it is
  o am I synced to a reliable source?
  o do I know my TZ?
  o how good is my timesync (precision issue)
- - in the real world, there we can't demand timesync is in place, so
  we can't really follow RFC 3339 in this regard

This is my honest try to sum it up - PLEASE correct me if you think I am
wrong. I've tried to be neutral, but as I have my own opinion, it might
have influence the summary.

In the light of this sum-up, I propose the following compromise:

- - we will continue to use the rfc 3339 timestamp in its
  unmodified way
- - we will ignore that RFC 3339 calls for timesync (because
  we can't ensure it)
- - there will be NO header field indicating the reliability
  of the time flag
- - there will be an optional structured data element which
  allows to specify the timestamp reliability in all three
  cases. If it is absent, it is assumed that the timestamp is
  correct. If an implementor has a good indication this may
  not be the case, his implementation SHOULD write the
  respective element indicating this
- - the ID in general and/or its security considerations
  should list this imperfection

I know this probably is not the ideal form. But given the diversity of
good (!) thoughts on this issue, I think it is an agreeable compromise
... or may be not ;)

Rainer

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]]
> Sent: Thursday, February 12, 2004 11:39 PM
> To: Rainer Gerhards; [email-masked]
> Subject: RE: RFC 3339 & UTC offset
>
> Rainer:
>
> > #1 is more a spec-stunt than a real solution ;)
> >    In 4.4, RFC 3339 says
> >
> >    ###
> >    o  Use another host in the same local time zone as a
> gateway to the
> >       Internet.  This host MUST correct unqualified local
> > times that are
> >       transmitted to other hosts.
> >    ###
>
> Definitely a stunt. :)  This requirement is constraining deployment
> options.
>
> > #2 is to "tweak" the format a little bit. Honestly, I don't
> > like this messing with a standard, and this is very far to
> the edge...
> >
> > All special sequences (like "-00:00") are already taken up.
> > 3339, however, specifies that the "Z" UTC indicator can be
> > either upper or lower case. I have choosen to allow only
> > upper case for simplicity. We
> > *could* say that if the device does not know its ZT and does
> > not know if time is properly synced, it should use "z" (lower
> > case) as the TZ indicator. This would still be a valid 3339
> > indicator, but definitely not be in the spirit of 3339.
>
> I think it is okay, although the distinction is not as clear as I'd
> prefer.  I like "-----" for offset because this removes ambiguity.  I
> know it is not consistent with RFC3339, but RFC3339 format is ONLY for
> situations when you know the offset, which won't always be
> the case for
> syslog clients.  So, I guess in some cases RFC3339 is not appropriate.
>
> > #3 is to actually add a syslog header field "I know my TZ
> > info or I am synced" (Y/N) in -protcol, eventually adjecent
> > to the timestamp field. Honestly, this, too, does not smell
> > really good to me.
>
> I think the "I am sync'ed" maybe be different than "I know my TZ". For
> example, you maybe no be sync'ed but know your time zone.
>
> This brings up another question that maybe other people raised before.
> I guess there are cases when you know the time is definitely
> NOT synced.
> But when do we consider it synced? What's the precision of
> sync'ed? Does
> it mean it is sync'ed with NTP or set manually yesterday?
>
> I guess for some cases "set manually yesterday" is fine, but for other
> cases (say when correlating messages from multiple systems based on
> precise time) this is not good enough because clocks drift
> and manually
> set time can't be precise. So, maybe this is a deployment-specific
> decision how the "authoritative-time" flag is interpreted?
>
> Anton.
>
>
>
>

------------------------------

Date: Fri, 13 Feb 2004 10:40:47 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: RFC 3339 & UTC offset

Rainer:

> In the light of this sum-up, I propose the following compromise:
>
> - we will continue to use the rfc 3339 timestamp in its
>   unmodified way
> - we will ignore that RFC 3339 calls for timesync (because
>   we can't ensure it)
> - there will be NO header field indicating the reliability
>   of the time flag
> - there will be an optional structured data element which
>   allows to specify the timestamp reliability in all three
>   cases. If it is absent, it is assumed that the timestamp is
>   correct. If an implementor has a good indication this may
>   not be the case, his implementation SHOULD write the
>   respective element indicating this

This could be an ok compromise.  But some clarification is still needed.

1. What is "timestamp is correct"? Left to implementation to decide? I
am fine with that, if we can wordsmith it.

2. I am concerned about the "SHOULD" in the above. I think when
implementation does have good indication that time is wrong it MUST
provide a structured element to indicate this.  It is still kinda
voluntary because the implementation may not have a "good indication" or
may have its own definition of "wrong" time.

3. What do devices which have no time put in the timestamp?  Anything? I
understand they will provide the structured element (MUST), but why not
recommend what they should put in the timestamp instead of leaving it up
to them to invent a convention?

4. Do we want to make a distinction between non-authoritative time and
unknown time? Separate structured element?

I know this has been a big thread.  But there is a lot of intricate
issues to deal with here. The biggest problem, like you indicated, is
that our protocol is designed for a an environment which is not RFC 3339
compliant.

Anton.

------------------------------

Date: Fri, 13 Feb 2004 17:18:38 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -procotol relay operations

Rainer:

I was just thinking about the same! :)

I think relay is an extreme case of this situation.  Let's look at the
client (originator) first.  Suppose administrator knows that a
particular client is behind a low MTU network.  I have actually
tentatively (with a big TODO) specified in -transport that clients are
RECOMMENDED to have an option where MTU could be specified. This would
allow a client to fragment the message on IP level, thus avoiding having
to discover MTU or malfunction due to wrong MTU use (truncation by UDP
stack).

I was thinking, like you, that maybe in this case it is better if client
actually sent a multi-part message instead of IP-fragmenting them.  I
think multi-part messages have an advantage.  Normally (without
multi-part messages), if one IP fragment gets lost, syslog server will
not get the UDP datagram - IP layer will discard it and syslog server
may not get any indication that something got lost.  If, on the other
hand, reassembly is done on a higher level with multi-part messages,
then syslog server would at least know that some part was missing and
can log a diagnostic message.  Sure, this is not a great scheme for
detecting lost datagrams, but its better than alternative it seems.

I think I like this idea. Allowing relay to partition a message is the
next logical step.  I think it is more debatable as in this case message
is changed in flight, but same general argument holds.  You would just
have to deal with original multi-part messages being partitioned again
by a relay or prohibit this. Nasty, nasty....

It sucks that we have to re-invent IP fragmentation, but we basically
have no choice. There will always be messages greater than UDP datagram
size.

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Friday, February 13, 2004 12:55 PM
> To: [email-masked]
> Subject: -procotol relay operations
>
>
> Hi WG,
>
> we talked quite a bit about different MTUs for different
> transport mapping. We may run into a situation where a
> message is larger than is actually supported by the transport
> (e.g a hypothetical SNMP trap transport supporting only ~500
> octets). As we have multi-part message in -protocol, a relay
> COULD create a multi-part message at this time. This could be
> an elegant solution to the minimum size problem, too. You can
> directly compare it it IP fragmentation.
>
> Question now: Is there any objection against specifying it in
> that way, at least as a MAY rule for relays. I think it
> definitely has advantages
> - it allows us to care for the unsual cases...
>
> Rainer
>
>

------------------------------

Date: Sat, 14 Feb 2004 20:58:44 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: SyslogMIB Issue-#4  // Issue-#2

David,
      Excellent. That would mean that we can leave configuration matters
tobe handled by a "syslog compliant" scriptMIB implementation. And we
can remove the configuration tables from the SyslogMIB.

      Cheers

      Glenn

Harrington, David wrote:

> Hi Glenn,
>
> We can always write a "syslog compliance" statement to indicate what
> subset of the Script MIB needs to be implemented to support syslog
> configuration. As long as such a statement doesn't try to change the
> semantics of any objects, but simply defines a subset of the mib module,
> that should be no problem. That would essentially be the same as having
> such a "limited" compliance statement in the script mib document itself.
>
> dbh
>
>
>>-----Original Message-----
>>From: Glenn Mansfield Keeni [mailto:[email-masked]]
>>Sent: Monday, February 09, 2004 1:12 AM
>>To: Harrington, David
>>Cc: [email-masked]
>>Subject: Re: SyslogMIB Issue-#4 // Issue-#2
>>
>>Dave,
>>Harrington, David wrote:
>>
>>>Hi,
>>>
>>>Rather than reinventing wheels, let's try to review work that has
>>>already been done in the IETF for these purposes, and discuss any
>>>experience that has already been had with these approaches.
>>
>>Please look
>>
>>>at the RFC3165 Script MIB
>>
>>I fully agree.
>>
>>>(ftp://ftp.rfc-editor.org/in-notes/rfc3165.txt) and the NETCONF work
>>>(http://www.ietf.org/html.charters/netconf-charter.html)
>>>
>>>The Script MIB is all about uploading/downloading scripts
>>
>>to execute on
>>
>>>a managed device. It is language-independent, but recognizes the
>>>likelihood of Java, Perl, and CLI scripts.
>>>This MIB has an (optional) on-line editing capability,
>>
>>which experience
>>
>>>has shown few operators want to use; they would rather get
>>
>>the script,
>>
>>>modify it offline, and send it back to the device.
>>
>>I am aware of the ScriptMIB. If we do design a
>>configuration-download/upload
>>MIB we will certainly refer to and use the mechanisms used in RFC3165.
>>
>>I am still trying to figure out whether we can use the
>>scriptMIB itself
>>without defining any new Tables. It is all there .. we have
>>to pretend that
>>the syslogConf is a script that is interpreted by the syslog process.
>>There does not seem to be any problem - but the compilance
>>requirements may
>>be a bother- I need to look at the RFC to figure out before I
>>can really
>>propose to use theScriptMIB.
>>
>>>The NETCONF work is trying to make it possible to
>>
>>download/upload script
>>
>>>files for configuring devices, as a way to standardize CLI
>>
>>scripting.
>>
>>>dbh
>>
>>Cheers
>>
>>Glenn
>>
>>
>
>

------------------------------

Date: Mon, 16 Feb 2004 05:36:38 -0800 (PST)
From: Lonvick <[email-masked]>
Subject: ID submission

Approved: syslogsyslog
Date: Mon, 16 Feb 2004 22:15:22 +0900
From: Glenn Mansfield Keeni <[email-masked]>
To: "[email-masked]" <[email-masked]>,
     "[email-masked]" <[email-masked]>
Subject: ID submission

Hi,
   Attached please find the updated ID
         draft-ietf-syslog-device-mib-06.txt
This is a work of the ietf-syslog-wg.
I will appreciate it very much if you can
post this to the archives.

    Thanks.

Network Working Group                              Glenn Mansfield Keeni
INTERNET-DRAFT                                      Cyber Solutions Inc.
Expires: August 15, 2004                                         B. Pape
                                                      Enterasys Networks
                                                       February 16, 2004

                               Syslog MIB
                 <draft-ietf-syslog-device-mib-06.txt>

Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt.

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

      This Internet-Draft will expire on August 15, 2004.

   Copyright Notice

      Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This memo provides a MIB module that can be used to monitor and manage
   syslog processes. It defines objects that allow the collection of
   information related to syslog processes, it also defines objects that
   can be used to monitor and/or control syslog processes.

Expires: August 15, 2004                                        [Page 1]

Internet Draft                                         February 16, 2004

Table of Contents

        1. The SNMP Management Framework .................. 3
        2. Background ..................................... 3
        3. The MIB Design ................................. 4
        4. The Syslog MIB ................................. 6
        5. Intellectual Property Notice ...................28
        6  Acknowledgments ................................28
        7. Security Considerations ........................28
        8. References .....................................30
        9. Full Copyright Statement .......................32
       10. Authors Address ................................33
       11. Appendix .......................................34

Expires: August 15, 2004                                        [Page 2]

Internet Draft                                         February 16, 2004

1. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).

   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   This document defines a portion of the Management Information Base
   (MIB) for use with management protocols in the Internet community.
   In particular, this document describes managed objects used for
   configuring and monitoring syslog processes that handle syslog
   messages.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2. Background

   Operating systems, processes and applications generate messages
   indicating their own status or the occurance of events. These
   messages are useful for managing and/or debugging the network and its
   services. The BSD Syslog protocol is a widely adopted protocol that
   is used for transmission and processing of the messages.
   Essentially, a syslog process receives messages (from the kernel,
   processes, applications or other syslog processes) and processes
   those. The processing involves logging to a local file, displaying on
   console, user terminal, and/or relaying to syslog processes on other
   machines. The processing is determined by the "facility" that
   originated the message and the "severity" assigned to the message by
   the facility.

   This document defines a generic MIB that may be used to monitor and
   control one or more syslog processes running on a system.

   The syslogMIB will be used in conjunction with other MIBs - in
   particular the Host Resources MIB and the script MIB. The generic
   process related matters e.g. process control, status, resource usage

Expires: August 15, 2004                                        [Page 3]

Internet Draft                                         February 16, 2004

   etc. will be serviced by the corresponding entries in the Host
   Resources MIB. The configuration of the syslog process is not
   directly supported. The configuration process can be serviced by an
   implementation of a script MIB in which the configuration file is
   treated as the script which is interpreted by the syslog process,

                                    /
                          +------+ /
                          | SP-1 |------> SP-R1
                         /+------+ \
        Facility-1-->|  /
                  -->| /  +------+ /
        Facility-N-->|+---| SP-2 |------> SP-R2
                  -->| \  +------+ \
      SyslogHost-N-->|  \
                         \+------+ /
                          | SP-N |------> SP-RN
                          +------+ \
                                    \

             Facility: Facility originating the message (locally)
           SyslogHost: Remote SyslogHost relaying a message
                   SP: Syslog Process

                   Fig.1 Syslog Process Model

   The syslog process modelled by the MIB is shown in Fig.1. One or more
   syslog processes running on a system receive syslog messages from the
   local facilities and from other syslog processes on other hosts. The
   syslog process receives the message and processes it depending on the
   processing mandated for the facility and severity of the message in
   its local message-process configuration table.

3. The MIB Design.

   The purpose of the SyslogMIB is to allow the monitoring and control
   of the syslog process(es) on a system. This requires MOs representing

   o  Statistics on messages, received, processed locally, relayed,
   o  Syslog system wide parameters that are available to all syslog
      processes.
   o  Syslog run time parameters for each syslog process e.g.
            - maximum message size,
            - sockets and/or type of transport, port numbers on which
              the process will listen for messages, etc.

Expires: August 15, 2004                                        [Page 4]

Internet Draft                                         February 16, 2004

            - etc.

   The MIB comprises of four groups
   o  The syslogSystem group handles the system wide parameters
      that applies to all the syslog processes served by the
      SNMP agent.
   o  The syslog process group consisting of the
      - syslogStatsTable which deals with statistical information about
        the syslog processes.
      - syslogParamsTable for monitoring and controlling syslog
        processes. It contains MOs representing the run-time parameters
        of the syslog processes.
   o  The conformance group that defines the compliance statements.

Expires: August 15, 2004                                        [Page 5]

Internet Draft                                         February 16, 2004

4.  The Syslog MIB

   SYSLOG-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
                 Unsigned32, Counter32, mib-2
                 FROM SNMPv2-SMI
       RowStatus, TEXTUAL-CONVENTION, TimeStamp, TruthValue,
                 StorageType
                 FROM SNMPv2-TC
       InetAddressType, InetAddress, InetAddressPrefixLength
                 FROM INET-ADDRESS-MIB
       MODULE-COMPLIANCE, OBJECT-GROUP
                 FROM SNMPv2-CONF
       SnmpAdminString
                 FROM SNMP-FRAMEWORK-MIB;

   syslogMIB  MODULE-IDENTITY
       LAST-UPDATED "200306250000Z"  -- Wed June  25 00:00 GMT 2003
       ORGANIZATION "IETF Syslog Working Group"
       CONTACT-INFO
           "        Glenn Mansfield Keeni
            Postal: Cyber Solutions Inc.
                    6-6-3, Minami Yoshinari
                    Aoba-ku, Sendai, Japan 989-3204.
               Tel: +81-22-303-4012
               Fax: +81-22-303-4015
            E-mail: [email-masked]
            "

       DESCRIPTION
           "The MIB module pertaining to the reception and processing
            of Syslog compatible messages."

       REVISION "200306250000Z"  -- Wed June      25 00:00 GMT 2003
       DESCRIPTION
           "The initial version of this MIB module."
       ::= { mib-2 999999 }     -- Will be assigned by IANA

   -- -------------------------------------------------------------
   -- Textual Conventions
   -- -------------------------------------------------------------

Expires: August 15, 2004                                        [Page 6]

Internet Draft                                         February 16, 2004

   SyslogFacility  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This textual convention enumerates the facilities
            that originate syslog messages.
            The value noMap(99) indicates that the appropriate
            facility will be provided by the application on the
            managed entity.
            If this option is not available on a particular entity,
            attempts to set the facillity to this value will fail
            with an error-status of wrongValue.
           "
       REFERENCE
           "The BSD syslog Protocol (RFC 3164) sec. 4.1.1 (Table 1).
           "
       SYNTAX  INTEGER {
                         kernel          (0), -- kernel messages
                         user            (1), -- user-level messages
                         mail            (2), -- mail system
                         daemon          (3), -- system daemons
                         auth            (4), -- authorization messages
                         syslog          (5), -- messages generated by syslogd
                         lpr             (6), -- line printer subsystem
                         news            (7), -- network news subsystem
                         uucp            (8), -- UUCP subsystem
                         cron            (9), -- clock daemon
                         authPriv        (10),-- authorization messages
                                              --    (private)
                         ftp             (11),-- ftp daemon
                         ntp             (12),-- NTP subsystem
                         security        (13),-- security subsystems
                                              --    (firewalling, etc.)
                         console         (14),-- /dev/console output

                         local0          (16),
                         local1          (17),
                         local2          (18),
                         local3          (19),
                         local4          (20),
                         local5          (21),
                         local6          (22),
                         local7          (23),
                         noMap           (99)
                       }

Expires: August 15, 2004                                        [Page 7]

Internet Draft                                         February 16, 2004

   SyslogSeverity  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This textual convention enumerates the severity levels
            of syslog messages.  The syslog protocol uses the values
            0 (emergency), to 7 (debug)."
       REFERENCE
           "The BSD syslog Protocol (RFC 3164) sec. 4.1.1 (Table 2)
           "
       SYNTAX  INTEGER {
                         emergency       (0),  -- system is unusable
                         alert           (1),  -- action must be taken
                                               --          immediately
                         critical        (2),  -- critical conditions
                         error           (3),  -- error conditions
                         warning         (4),  -- warning conditions
                         notice          (5),  -- normal but significant
                                               --              condition
                         info            (6),  -- informational
                         debug           (7),  -- debug-level messages
                         other           (99)  -- none of the above
                       }

   SyslogSeverityCompOP  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The operator that will be applied to the severity
            before the selection for an action takes place.
           "
       SYNTAX INTEGER  {
                         none                  (1),
                         greaterThanOrEqual    (2),
                         lessThanOrEqual       (3),
                         greaterThan           (4),
                         lessThan              (5),
                         notGreaterThanOrEqual (6),
                         notLessThanOrEqual    (7),
                         notGreaterThan        (8),
                         notLessThan           (9),
                         equal                 (10),
                         notEqual              (11)
                       }

Expires: August 15, 2004                                        [Page 8]

Internet Draft                                         February 16, 2004

   SyslogTransport  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The Transport that will be used to send and/or
            receive messages.
           "
       REFERENCE
           "The The BSD syslog Protocol RFC 3164 Sec. 2.
           "
       SYNTAX INTEGER  {
                         any                   (1),
                         udp                   (2),
                         tcp                   (3)
                       }

   SyslogService  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The service name or port number that will be used to
            send and/or receive messages.
            The special name ''any'' is reserved. It denotes
            all ports and is applicable only in the context of
            message reception.
            In case the service name is given, and it is not ''any'',
            the service name must resolve to a port number on the
            local host.
           "
       SYNTAX OCTET STRING (SIZE (0..255))

   -- -------------------------------------------------------------
   -- syslogMIB - the main groups
   -- -------------------------------------------------------------

   syslogSystem              OBJECT IDENTIFIER
                         ::= { syslogMIB 1 }

   syslogProc                OBJECT IDENTIFIER
                         ::= { syslogMIB 2 }

Expires: August 15, 2004                                        [Page 9]

Internet Draft                                         February 16, 2004

   -- -------------------------------------------------------------
   -- syslogSystem
   -- -------------------------------------------------------------

   -- The system wide parameters

   syslogDefaultTransport OBJECT-TYPE
       SYNTAX      SyslogTransport
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default transport that a syslog process will use
            to send syslog messages.
           "
       REFERENCE
           "The BSD syslog Protocol RFC 3164 Sec. 2.
           "
       DEFVAL  {udp}
       ::= { syslogSystem 1 }

   syslogDefaultService OBJECT-TYPE
       SYNTAX      SyslogService
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default service name or port number that a syslog
            process will use to send syslog messages.
           "
       REFERENCE
           "The BSD syslog Protocol RFC 3164 Sec. 2.
           "
       DEFVAL  { "514" }
       ::= { syslogSystem 2 }

   syslogDefaultFacility OBJECT-TYPE
       SYNTAX      SyslogFacility
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default syslog facility that will be added to syslog
            messages when the message needs to be relayed and does not
            have priority specified.
           "
       ::= { syslogSystem 3 }

Expires: August 15, 2004                                       [Page 10]

Internet Draft                                         February 16, 2004

   syslogDefaultSeverity OBJECT-TYPE
       SYNTAX      SyslogSeverity
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default syslog severity that will be added to syslog
            messages when the message needs to be relayed and does not
            have priority specified.
           "
       ::= { syslogSystem 4 }

   syslogMaxMessageSize OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The maximum size of the syslog messages in bytes.
           "
       DEFVAL { 1024 }
       ::= { syslogSystem 5 }

   -- -------------------------------------------------------------
   -- syslogProc
   -- -------------------------------------------------------------
   syslogProcTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogProcEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the syslog processes
            serviced by an SNMP agent.
           "
       ::= { syslogProc 1 }

   syslogProcEntry OBJECT-TYPE
       SYNTAX      SyslogProcEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The information pertaining to a syslog process.
           "
       INDEX  { syslogProcIndex }
       ::= { syslogProcTable 1 }

Expires: August 15, 2004                                       [Page 11]

Internet Draft                                         February 16, 2004

   SyslogProcEntry ::=
       SEQUENCE {
           syslogProcIndex
                Unsigned32,
           syslogProcMsgsReceived
                Counter32,
           syslogProcMsgsRelayed
                Counter32,
           syslogProcMsgsDropped
                Counter32,
           syslogProcMsgsIllFormed
                Counter32,
           syslogProcMsgsIgnored
                Counter32,
           syslogProcMsgsRejected
                Counter32,
           syslogProcLastMsgRecdTime
                TimeStamp,
           syslogProcLastMsgDeliveredTime
                TimeStamp,
           syslogProcStartTime
                TimeStamp,
           syslogProcLastError
                SnmpAdminString,
           syslogProcLastErrorTime
                TimeStamp,
           syslogProcReference
                Integer32
       }

   -- option for allowed peers needs to be added

   syslogProcIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The Index that uniquely identifies the syslog process in the
            syslogProcess table.
           "
       ::= { syslogProcEntry 1 }

Expires: August 15, 2004                                       [Page 12]

Internet Draft                                         February 16, 2004

   syslogProcMsgsReceived OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages received by the syslog
            process. This includes messages that were ignored.
           "
       ::= { syslogProcEntry 2 }

   syslogProcMsgsRelayed OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages relayed by the syslog
            process to other syslog processes.
           "
       ::= { syslogProcEntry 3 }

   syslogProcMsgsDropped OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that could not be relayed
            (could not be queued for transmitting)."
       ::= { syslogProcEntry 4 }

   syslogProcMsgsIllFormed OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were rejected by the
            syslog process because these were not well-formed.
           "
       ::= { syslogProcEntry 5 }

Expires: August 15, 2004                                       [Page 13]

Internet Draft                                         February 16, 2004

   syslogProcMsgsIgnored OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were not processed by the
            syslog process because the message did not meet
            the specification of 'allowed specifications' ( either
            the program name or the priority level of the message
            or both did not match any selection specified
            for this process in the syslogCtlSelectionTable).
           "
       ::= { syslogProcEntry 6 }

   syslogProcMsgsRejected OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were rejected by the
            syslog process because the messsage was from a host/service
            that did not match any selection specified for this process
            in the syslogCtlSelectionTable and was not on the allowed
            host/services list.
           "
       ::= { syslogProcEntry 7 }

   syslogProcLastMsgRecdTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was received
            by the syslog process locally or from a remote
            syslog process.
           "
       ::= { syslogProcEntry 8 }

   syslogProcLastMsgDeliveredTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was delivered
            by the syslog process.
           "
       ::= { syslogProcEntry 9 }

Expires: August 15, 2004                                       [Page 14]

Internet Draft                                         February 16, 2004

   syslogProcStartTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when this process was started.
           "
       ::= { syslogProcEntry 10 }

   syslogProcLastError OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "A description of the last error that was encountered
            by this process.
           "
       ::= { syslogProcEntry 11 }

   syslogProcLastErrorTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last error was encountered.
           "
       ::= { syslogProcEntry 12 }

   syslogProcReference OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "If the Host resource MIB is serviced on the host then
            this will entry will have the value of the hrSWRunIndex
            of the corresponding entry in the hrSWRunTable.
            Otherwise this object will be inaccessible,
           "
       ::= { syslogProcEntry 1 }

   syslogParamsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogParamsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the parameters
           that control the syslog processes.
           "

Expires: August 15, 2004                                       [Page 15]

Internet Draft                                         February 16, 2004

       ::= { syslogProc 2 }

   syslogParamsEntry OBJECT-TYPE
       SYNTAX      SyslogParamsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The parameters pertaining to a syslog process."
       INDEX  { syslogProcIndex }
       ::= { syslogParamsTable 1 }

   SyslogParamsEntry ::=
       SEQUENCE {
           syslogParamsProcDescr
                SnmpAdminString,
           syslogParamsBindAddrType
                InetAddressType,
           syslogParamsBindAddr
                InetAddress,
           syslogParamsSendToAllAddresses
                TruthValue,
           syslogParamsCompression
                INTEGER,
           syslogParamsConfFileName
                SnmpAdminString,
           syslogParamsFacilityTranslation
                INTEGER,
           syslogParamsPIDFileName
                SnmpAdminString,
           syslogParamsDNSLookup
                INTEGER,
           syslogParamsSeverityCompOP
                SyslogSeverityCompOP,
           syslogParamsSecuritySpecs
                INTEGER,
           syslogParamsProcessStatus
                INTEGER,
           syslogParamsStorageType
                StorageType,
           syslogParamsRowStatus
                RowStatus
        }

Expires: August 15, 2004                                       [Page 16]

Internet Draft                                         February 16, 2004

   syslogParamsProcDescr OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A user definable description of the syslog process.
           "
       ::= { syslogParamsEntry 1 }

   syslogParamsBindAddrType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of Internet address which follows
            in syslogParamsBindAddr.
           "
       ::= { syslogParamsEntry 2 }

   syslogParamsBindAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The specific IP address or hostname the syslog process will
            bind to. If a hostname is specified, the IPv4 or IPv6 address
            corresponding to the hostname will be used.
           "
       ::= { syslogParamsEntry 3 }

   syslogParamsSendToAllAddresses OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "If the destination host, for a message to be forwarded,
            has more than one A or AAAA record process, Send the
            message to all the addresses (true) else send to only
            one of the addresses.
           "
       DEFVAL     { false }
       ::= { syslogParamsEntry 4 }

Expires: August 15, 2004                                       [Page 17]

Internet Draft                                         February 16, 2004

   syslogParamsCompression OBJECT-TYPE
       SYNTAX      INTEGER {
                   off       (1),
                   offIfPipe (2),
                   on        (3)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "If 'off', disable the compression of repeated instances
            of the same line into a single line of the form ``last
            message repeated N times''.
            If 'offIfPipe' disable the compression when the output
            is a pipe to another program. Otherwise the compression
            is enabled.
           "
       DEFVAL { on }
       ::= { syslogParamsEntry 5 }

   syslogParamsConfFileName OBJECT-TYPE
       SYNTAX       SnmpAdminString
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
         "The fullpath name of the configuration file where the
          syslog process's message selection and corresponding action
          rules will be read from.
          Data is loaded from this file into the syslogCtlSelectionTable
          and the syslogCtlLogActionTable.
          If the objects loaded from the file specified by this object
          have an access level of read-create this file MUST be
          be writable so that modifications to the corresponding objects,
          if any, will be effected in this file.
          If the system does not support the specification of a
          configuration file this field will not be accessible.
         "
       DEFVAL { "/etc/syslog.conf" }
       ::= { syslogParamsEntry 6 }

Expires: August 15, 2004                                       [Page 18]

Internet Draft                                         February 16, 2004

   syslogParamsFacilityTranslation OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "If false(2), disable the translation of messages received
            with facility ``kern'' to facility ``user''.  Usually the
            ``kern'' facility is reserved for messages read directly from
            /dev/klog.
           "
       DEFVAL { true }
       ::= { syslogParamsEntry 7 }

   syslogParamsPIDFileName OBJECT-TYPE
       SYNTAX       SnmpAdminString
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "The fullpath name of the file where the syslog process ID
            will be recorded.
            In case the system does not support the feature of recording
            syslog's process ID - this object will not be accessible.
           "
       DEFVAL { "/etc/syslog.pid" }
       ::= { syslogParamsEntry 8 }

   syslogParamsDNSLookup OBJECT-TYPE
       SYNTAX      INTEGER {
                   useLocalCache       (1),
                   doNotUseLocalCache  (2),
                   doNotUseLocalCache  (3)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "If doNotUseLocalCache is on, fresh DNS lookups will
            be carried out everytime a hostname is encountered.
            Else, DNS lookups will be carried out only once for
            each hostname.
           "
       DEFVAL { useLocalCache }
       ::= { syslogParamsEntry 9 }

Expires: August 15, 2004                                       [Page 19]

Internet Draft                                         February 16, 2004

   syslogParamsSeverityCompOP  OBJECT-TYPE
       SYNTAX SyslogSeverityCompOP
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "The default value of the operator that should be
            applied to the syslogCtlSelectionSeverity before the
            selection takes place.
           "
       DEFVAL      { greaterThanOrEqual }
       ::= { syslogParamsEntry 10 }

   syslogParamsSecuritySpecs   OBJECT-TYPE
       SYNTAX       INTEGER  {
                         none                      (1),
                         doNotRecvFromRemoteHosts  (2),
                         doNotOpenNetworkSockets   (3)
                       }
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "If doNotRecvFromRemoteHosts is selected then the
            corresponding syslog process will not receive messages
            from remote hosts.
            If doNotOpenNetworkSockets is selected then the syslog
            process will not receive from or forward to remote hosts.
           "
       DEFVAL      { none }
       ::= { syslogParamsEntry 11 }

   syslogParamsProcessStatus OBJECT-TYPE
       SYNTAX       INTEGER  {
                         unknown  (1),
                         started  (2),
                         suspended(3),
                         stopped  (4)
                       }
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The status of the process.
           "
       DEFVAL      { unknown }
       ::= { syslogParamsEntry 12 }

Expires: August 15, 2004                                       [Page 20]

Internet Draft                                         February 16, 2004

   syslogParamsStorageType OBJECT-TYPE
       SYNTAX       StorageType
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "This object defines whether the parameters defined in this
            row are kept in volatile storage and lost upon reboot or
            are backed up by non-volatile (permanent) storage.
            Conceptual rows having the value 'permanent' need not
            allow write-access to any columnar objects in the row.
           "
       ::= { syslogParamsEntry 13 }

   syslogParamsRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is used to create, modify and delete rows in
            the syslogParamsTable.
            Objects in a row can be modified only when the value of this
            object in the corresponding conceptual row is not ''active''.
            Thus to modify one or more of the objects in this conceptual
            row,
              a. change the row status to ''notInService'',
              b. change the values of the row
              c. change the row status to ''active''
            The syslogParamsRowStatus may be changed to ''active'' iff
            all the MOs in the conceptual row have been assigned valid
            values.
           "
       ::= { syslogParamsEntry 14 }

   syslogAllowedHostsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogAllowedHostsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the Hosts
           from which messages will be accepted.
           "
       ::= { syslogProc 3 }

Expires: August 15, 2004                                       [Page 21]

Internet Draft                                         February 16, 2004

   syslogAllowedHostsEntry OBJECT-TYPE
       SYNTAX      SyslogAllowedHostsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The host information."
       INDEX  { syslogProcIndex }
       ::= { syslogAllowedHostsTable 1 }

   SyslogAllowedHostsEntry ::=
       SEQUENCE {
           syslogAllowedHostsAddressType
                InetAddressType,
           syslogAllowedHostsAddress
                InetAddress,
           syslogAllowedHostsMaskLen
                InetAddressPrefixLength,
           syslogAllowedHostsTransport
                SyslogTransport,
           syslogAllowedHostsPort
                SyslogService,
           syslogAllowedHostsStorageType
                StorageType,
           syslogAllowedHostsRowStatus
                RowStatus
        }

   syslogAllowedHostsAddressType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of Internet address which follows
            in syslogAllowedHostsAddress.
           "
       ::= { syslogAllowedHostsEntry 1 }

   syslogAllowedHostsAddress OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The IP address or hostname specification of the host from
            which the syslog process will accept messages.
           "
       ::= { syslogAllowedHostsEntry 2 }

Expires: August 15, 2004                                       [Page 22]

Internet Draft                                         February 16, 2004

   syslogAllowedHostsMaskLen OBJECT-TYPE
       SYNTAX      InetAddressPrefixLength
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "If the syslogAllowedHostsAddressType is ipv4(1), ipv6(2)
            this object represents the number of bits that will be
            taken into account when the address of the originating
            is being compared with syslogAllowedHostsAddress.

            The default value of this MO will be the length of the
            corresponding syslogAllowedHostsAddress.

            If the syslogAllowedHostsAddressType is not ipv4(1) or
            ipv6(2) this object is not used.

            A value of 0 indicates that the prefix is not used or is
            not applicable.
           "
       DEFVAL     { 0 }
       ::= { syslogAllowedHostsEntry 3 }

   syslogAllowedHostsTransport OBJECT-TYPE
       SYNTAX      SyslogTransport
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The Transport specification that will be used to decide
            whether the messsage will be accepted from a host or
            not.
           "
       DEFVAL     { udp }
       ::= { syslogAllowedHostsEntry 4 }

   syslogAllowedHostsPort OBJECT-TYPE
       SYNTAX      SyslogService
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The port specification that will be used to decide
            whether the messsage will be accepted from a host or
            not.
           "
       DEFVAL     { "any" }
       ::= { syslogAllowedHostsEntry 5 }

Expires: August 15, 2004                                       [Page 23]

Internet Draft                                         February 16, 2004

   syslogAllowedHostsStorageType OBJECT-TYPE
       SYNTAX       StorageType
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "This object defines whether the parameters defined in this
            row are kept in volatile storage and lost upon reboot or
            are backed up by non-volatile (permanent) storage.
            Conceptual rows having the value 'permanent' need not
            allow write-access to any columnar objects in the row.
           "
       ::= { syslogAllowedHostsEntry 6 }

   syslogAllowedHostsRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is used to create and delete rows in the
            syslogAllowedHostsTable.
            All the columns in this conceptual row MUST have valid
            values before this column can be assigned the value
            ''active''.
           "
       ::= { syslogAllowedHostsEntry 7 }

   -- -------------------------------------------------------------
   -- Conformance Information
   -- -------------------------------------------------------------

   syslogConformance OBJECT IDENTIFIER
                             ::= { syslogMIB 4 }

   syslogGroups OBJECT IDENTIFIER
                             ::= { syslogConformance 1 }

   syslogCompliances OBJECT IDENTIFIER
                             ::= { syslogConformance 2 }

Expires: August 15, 2004                                       [Page 24]

Internet Draft                                         February 16, 2004

   -- -------------------------------------------------------------
   -- units of conformance
   -- -------------------------------------------------------------

   syslogSystemGroup OBJECT-GROUP
       OBJECTS {
                syslogDefaultTransport,
                syslogDefaultService,
                syslogDefaultFacility,
                syslogDefaultSeverity,
                syslogMaxMessageSize

       }
       STATUS  current
       DESCRIPTION
           "A collection of objects providing system-wide
            parameters for syslog processes.
           "
       ::= { syslogGroups 1}

   syslogStatsGroup OBJECT-GROUP
       OBJECTS {
               --  syslogProcIndex,
                   syslogProcMsgsReceived,
                   syslogProcMsgsRelayed,
                   syslogProcMsgsDropped,
                   syslogProcMsgsIllFormed,
                   syslogProcMsgsIgnored,
                   syslogProcMsgsRejected,
                   syslogProcLastMsgRecdTime,
                   syslogProcLastMsgDeliveredTime,
                   syslogProcStartTime,
                   syslogProcLastError,
                   syslogProcLastErrorTime,
                   syslogProcReference
               }
       STATUS  current
       DESCRIPTION
           "A collection of objects providing message related
            statistics."
       ::= { syslogGroups 2}

Expires: August 15, 2004                                       [Page 25]

Internet Draft                                         February 16, 2004

   syslogParamsGroup OBJECT-GROUP
       OBJECTS {
                   syslogParamsProcDescr,
                   syslogParamsBindAddrType,
                   syslogParamsBindAddr,
                   syslogParamsSendToAllAddresses,
                   syslogParamsCompression,
                   syslogParamsConfFileName,
                   syslogParamsFacilityTranslation,
                   syslogParamsPIDFileName,
                   syslogParamsDNSLookup,
                   syslogParamsSeverityCompOP,
                   syslogParamsSecuritySpecs,
                   syslogParamsStorageType,
                   syslogParamsRowStatus,
                   syslogAllowedHostsAddressType,
                   syslogAllowedHostsAddress,
                   syslogAllowedHostsMaskLen,
                   syslogAllowedHostsTransport,
                   syslogAllowedHostsPort,
                   syslogAllowedHostsStorageType,
                   syslogAllowedHostsRowStatus
               }
       STATUS  current
       DESCRIPTION
           "A collection of objects representing the run time parameters
            for the syslog processes.
           "
       ::= { syslogGroups 3}

Expires: August 15, 2004                                       [Page 26]

Internet Draft                                         February 16, 2004

   -- -------------------------------------------------------------
   -- compliance statements
   -- -------------------------------------------------------------

   syslogCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for an agent implememting the
            syslog MIB.
           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogStatsGroup
       }

       GROUP       syslogSystemGroup
       DESCRIPTION
           "The syslogSystemGroup group is mandatory only for
            agents which support monitoring and control of the
            syslog system wide parameters.
            If only monitoring is supported then the corresponding
            objects must have access read-only.
           "
       GROUP       syslogParamsGroup
       DESCRIPTION
           "The syslogParamsGroup group is mandatory only for
            agents which support monitoring and/or control of
            syslog processes.
            If only monitoring is supported then the corresponding
            objects must have access read-only.
           "
       ::= { syslogCompliances 1 }

   END

Expires: August 15, 2004                                       [Page 27]

Internet Draft                                         February 16, 2004

5.  Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

6.  Acknowledgments
   The authors would like to thank David Harrington, Mark Ellison, Mike
   MacFaden, Dave T Perkins and members of the WIDE-netman group for their
   comments and suggestions.

7.  Security Considerations

   Syslog plays a very important role in the computer and network
   security of an organization. SyslogMIB defines several managed
   objects that may be used to monitor configure and control syslog
   processes. As such improper manipulation of the objects represented
   by this MIB may lead to an attack on an important component of the
   computer and network security infrastructure.  The objects in
   syslogParamsTable, syslogAllowedHostsTable, syslogCtlSelectionTable,
   syslogCtlLogActionTable, syslogCtlUserActionTable
   syslogCtlFwdActionTable, syslogCtlPipeActionTable  may be
   misconfigured to cause syslog messages to be diverted or lost. A
   misconfiguration may also result in a DoS attack on a user or
   service.  There are a number of management objects defined in this
   MIB module with a MAX-ACCESS clause of read-write and/or read-create.
   Such objects may be considered sensitive or vulnerable in some
   network environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their

Expires: August 15, 2004                                       [Page 28]

Internet Draft                                         February 16, 2004

   sensitivity/vulnerability:

       o  syslogParamsTable: the objects in this table describe the
          configuration of the syslog processes.
       o  syslogAllowedHostsTable: the objects in this table describe the hosts
          from which syslog messages will be accepted. Improper configuration may
          lead to loss of messages from an important source or a flood of messages
          from a, potentially rogue, source.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

       o  syslogProcTable: objects in this table carry sensitive information.  The
          counters may reveal information about the deployment and effectiveness
          of the relevant security systems. The counters may be analyzed to tell
          whether the security systems are able to detect an event or not.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

Expires: August 15, 2004                                       [Page 29]

Internet Draft                                         February 16, 2004

8.  References:

[Normative References]

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Textual Conventions for
            SMIv2", STD 58, RFC 2579, April 1999

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999

[Informative References]

[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
            for Describing SNMP Management Frameworks", RFC 2571, April
            1999

[RFC1155]   Rose, M., and K. McCloghrie, "Structure and Identification
            of Management Information for TCP/IP-based Internets", STD
            16, RFC 1155, May 1990

[RFC1212]   Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
            16, RFC 1212, March 1991

[RFC1215]   M. Rose, "A Convention for Defining Traps for use with the
            SNMP", RFC 1215, March 1991

[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
            Network Management Protocol", STD 15, RFC 1157, May 1990.

[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Introduction to Community-based SNMPv2", RFC 1901, January
            1996.

[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Transport Mappings for Version 2 of the Simple Network
            Management Protocol (SNMPv2)", RFC 1906, January 1996.

[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
            Processing and Dispatching for the Simple Network Management
            Protocol (SNMP)", RFC 2572, April 1999

Expires: August 15, 2004                                       [Page 30]

Internet Draft                                         February 16, 2004

[RFC2574]   Blumenthal, U., and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", RFC 2574, April 1999

[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Protocol Operations for Version 2 of the Simple Network
            Management Protocol (SNMPv2)", RFC 1905, January 1996.

[RFC2573]   Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
            RFC 2573, April 1999

[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
            Access Control Model (VACM) for the Simple Network
            Management Protocol (SNMP)", RFC 2575, April 1999.

[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart,
            "Introduction to Version 3 of the Internet-standard Network
            Management Framework", RFC 2570, April 1999

[RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
           "Introduction and Applicability Statements for the
            Internet-Standard Management Framework", RFC 3410,
            December 2002.

[RFC3164]   C. Lonvick, "The BSD Syslog Protocol", RFC 3164,
            August 2001.

Expires: August 15, 2004                                       [Page 31]

Internet Draft                                         February 16, 2004

9.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires: August 15, 2004                                       [Page 32]

Internet Draft                                         February 16, 2004

10.  Authors Address

   Glenn Mansfield Keeni
   Cyber Solutions Inc.
   6-6-3 Minami Yoshinari
   Aoba-ku, Sendai 989-3204
   Japan

   Phone: +81-22-303-4012
   EMail: [email-masked]

   Bruno Pape
   Enterasys Networks, Inc.
   35 Industrial Way
   Rochester, NH 03867
   USA

   Email:  [email-masked]"
   Tel:    +1 603 337 0446

Expires: August 15, 2004                                       [Page 33]

Internet Draft                                         February 16, 2004

                                APPENDIX

This section documents the development of the draft. It will be deleted
when the draft bvecomes an RFC.

Revision History:

    REVISION "200406160000Z"  -- Mon Feb       16 00:00 GMT 2004
    DESCRIPTION
        "Major change.
             The configuration parts have been removed.

         Updated the description clauses.

         Editorial nits fixed.
        "

    REVISION "200306250000Z"  -- Wed June      25 00:00 GMT 2003
    DESCRIPTION
        "Changed the type of
             syslogProcLastError            SnmpAdminString,
             from Integer32.

         DEFVAL { 0 ] is added to syslogAllowedHostsMaskLen

         MO name changed from
         syslogCtlSelectionHostname to syslogCtlSelectionHostName

         Updated the description clauses.

         Fixed nits pointed out in Bert's mails of 20030319 and
         revised the document wrt the guidelines in
         draft-ietf-ops-mib-review-guidelines-01.txt

         Editorial nits fixed.
        "

    REVISION "200303030000Z"  -- Mon March     03 00:00 GMT 2003
    DESCRIPTION
        "Fixing of nits in descriptions, addition of references,
         addition of the following MOs
             syslogProcMsgsIllFormed        Counter32,
             syslogProcStartTime            TimeStamp,
             syslogProcLastError            Integer32,
             syslogProcLastErrorTime        TimeStamp,
             syslogParamsStorageType        StorageType,
             syslogCtlFwdActionSrcAddrType  InetAddressType,

Expires: August 15, 2004                                       [Page 34]

Internet Draft                                         February 16, 2004

             syslogCtlFwdActionSrcAddr      InetAddress,
         added enumeration ''suspended(2)'' to
             syslogParamsProcessStatus.
        "

    REVISION "200212252343Z"  -- Wed December  25 23:43 GMT 2002
    DESCRIPTION
        "Radical revision of the MIB structure and design."

    REVISION "200206061841Z"  -- Thu Jun  6 18:41 GMT 2002
    DESCRIPTION
        "The initial version of this MIB module."

Expires: August 15, 2004                                       [Page 35]

------------------------------

Date: Mon, 16 Feb 2004 18:14:50 +0100
From: Rainer Gerhards <[email-masked]>
Subject: -protocol-03

Hi WG,

I have edited syslog-protocol so that we are now at -protocol-03. I have
submitted it to the IETF this morning, but as the draft editor is
probably very swamped with the number of new IDs prior to the Seoul
meeting, I have agreed with Chris on publishing the not yet officially
relased ID on my site. I do so in the hope that this will allow us to
work out some of the issues before Seoul (and eventually identify new
ones).

It was a rather complete edit, I have placed a full change log on my
comment's page at

http://www.syslog.cc/ietf/drafts/comments-draft-ietf-syslog-protocol-03.
html

This page also links to the "unofficial" -protocol-03 version. This
version addresses many of the issues we discussed the past days. Rather
than individual replies, I'd appreciate if you could have a look at the
new ID.

For those without time to access the web, my edit summary is as follows:

- - general text-cleanup. Abstract and Intro modified. I noticed some old
text survived in the begininng of section 4, removed that, some typos
caught, probably twice as much added ;)

- - section 3, transport mappings clarified, section 3.1, UDP transport
required [see issue 10]

- - maximum syslog message size is now 1280 bytes (I assume this *is* the
minimum IPv6 MTU, had no time to check) [see issue 11]  ... oops, sorry
folks, accidently I removed the max size altogether ... shame on me for
rushing. 1280 will be back in in -protocol-04 ;)

- - section 4.2 - MSG - now specifies UTF-8 including including all
control characters [see issue 9]

- - section 4, TRAILER has been removed [see issue 6]

- - section 6, multi-part messages heavily changed. Name change from
fragmentation to "multi-part messaging", more definitions, hopefully
clearer description (some of the term names are *really* lenghty -
advise on better terms is taken thankfully).

- - section 7, definition of structured data element IDs (and semantics)
added

- - section 7.1 - time - tries to solve issue 12

- - section 7.2 - orgin - tries to provide a way to preserve originator IP
addresses inside the message. "origin" is also a key element when relay
RFC 3164 operations will be described (I didn't manage to get this into
the -03 version).

- - section 8, "relay operations" added, but so far it is more or less
empty.

- - section 9, "security considerations" cleaned up.

- - section 9.1 - diagnostic logging - added as a security consideration.
Comments on this are highly appreciated. This was not previously
discussed on the WG mailing list

I am looking forward to all comments.

Rainer
PS: I am unfortunately not able to attend the Seoul meeting personally,
but Chris has agreed to act as proxy (thanks, Chris!)

------------------------------

Date: Mon, 16 Feb 2004 22:15:22 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: ID submission

Hi,
   Attached please find the updated ID
         draft-ietf-syslog-device-mib-06.txt
This is a work of the ietf-syslog-wg.
I will appreciate it very much if you can
post this to the archives.

    Thanks.

Network Working Group                              Glenn Mansfield Keeni
INTERNET-DRAFT                                      Cyber Solutions Inc.
Expires: August 15, 2004                                         B. Pape
                                                      Enterasys Networks
                                                       February 16, 2004

                               Syslog MIB
                 <draft-ietf-syslog-device-mib-06.txt>

Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt.

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

      This Internet-Draft will expire on August 15, 2004.

   Copyright Notice

      Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This memo provides a MIB module that can be used to monitor and manage
   syslog processes. It defines objects that allow the collection of
   information related to syslog processes, it also defines objects that
   can be used to monitor and/or control syslog processes.

Expires: August 15, 2004                                        [Page 1]

Internet Draft                                         February 16, 2004

Table of Contents

        1. The SNMP Management Framework .................. 3
        2. Background ..................................... 3
        3. The MIB Design ................................. 4
        4. The Syslog MIB ................................. 6
        5. Intellectual Property Notice ...................28
        6  Acknowledgments ................................28
        7. Security Considerations ........................28
        8. References .....................................30
        9. Full Copyright Statement .......................32
       10. Authors Address ................................33
       11. Appendix .......................................34

Expires: August 15, 2004                                        [Page 2]

Internet Draft                                         February 16, 2004

1. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).

   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   This document defines a portion of the Management Information Base
   (MIB) for use with management protocols in the Internet community.
   In particular, this document describes managed objects used for
   configuring and monitoring syslog processes that handle syslog
   messages.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2. Background

   Operating systems, processes and applications generate messages
   indicating their own status or the occurance of events. These
   messages are useful for managing and/or debugging the network and its
   services. The BSD Syslog protocol is a widely adopted protocol that
   is used for transmission and processing of the messages.
   Essentially, a syslog process receives messages (from the kernel,
   processes, applications or other syslog processes) and processes
   those. The processing involves logging to a local file, displaying on
   console, user terminal, and/or relaying to syslog processes on other
   machines. The processing is determined by the "facility" that
   originated the message and the "severity" assigned to the message by
   the facility.

   This document defines a generic MIB that may be used to monitor and
   control one or more syslog processes running on a system.

   The syslogMIB will be used in conjunction with other MIBs - in
   particular the Host Resources MIB and the script MIB. The generic
   process related matters e.g. process control, status, resource usage

Expires: August 15, 2004                                        [Page 3]

Internet Draft                                         February 16, 2004

   etc. will be serviced by the corresponding entries in the Host
   Resources MIB. The configuration of the syslog process is not
   directly supported. The configuration process can be serviced by an
   implementation of a script MIB in which the configuration file is
   treated as the script which is interpreted by the syslog process,

                                    /
                          +------+ /
                          | SP-1 |------> SP-R1
                         /+------+ \
        Facility-1-->|  /
                  -->| /  +------+ /
        Facility-N-->|+---| SP-2 |------> SP-R2
                  -->| \  +------+ \
      SyslogHost-N-->|  \
                         \+------+ /
                          | SP-N |------> SP-RN
                          +------+ \
                                    \

             Facility: Facility originating the message (locally)
           SyslogHost: Remote SyslogHost relaying a message
                   SP: Syslog Process

                   Fig.1 Syslog Process Model

   The syslog process modelled by the MIB is shown in Fig.1. One or more
   syslog processes running on a system receive syslog messages from the
   local facilities and from other syslog processes on other hosts. The
   syslog process receives the message and processes it depending on the
   processing mandated for the facility and severity of the message in
   its local message-process configuration table.

3. The MIB Design.

   The purpose of the SyslogMIB is to allow the monitoring and control
   of the syslog process(es) on a system. This requires MOs representing

   o  Statistics on messages, received, processed locally, relayed,
   o  Syslog system wide parameters that are available to all syslog
      processes.
   o  Syslog run time parameters for each syslog process e.g.
            - maximum message size,
            - sockets and/or type of transport, port numbers on which
              the process will listen for messages, etc.

Expires: August 15, 2004                                        [Page 4]

Internet Draft                                         February 16, 2004

            - etc.

   The MIB comprises of four groups
   o  The syslogSystem group handles the system wide parameters
      that applies to all the syslog processes served by the
      SNMP agent.
   o  The syslog process group consisting of the
      - syslogStatsTable which deals with statistical information about
        the syslog processes.
      - syslogParamsTable for monitoring and controlling syslog
        processes. It contains MOs representing the run-time parameters
        of the syslog processes.
   o  The conformance group that defines the compliance statements.

Expires: August 15, 2004                                        [Page 5]

Internet Draft                                         February 16, 2004

4.  The Syslog MIB

   SYSLOG-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
                 Unsigned32, Counter32, mib-2
                 FROM SNMPv2-SMI
       RowStatus, TEXTUAL-CONVENTION, TimeStamp, TruthValue,
                 StorageType
                 FROM SNMPv2-TC
       InetAddressType, InetAddress, InetAddressPrefixLength
                 FROM INET-ADDRESS-MIB
       MODULE-COMPLIANCE, OBJECT-GROUP
                 FROM SNMPv2-CONF
       SnmpAdminString
                 FROM SNMP-FRAMEWORK-MIB;

   syslogMIB  MODULE-IDENTITY
       LAST-UPDATED "200306250000Z"  -- Wed June  25 00:00 GMT 2003
       ORGANIZATION "IETF Syslog Working Group"
       CONTACT-INFO
           "        Glenn Mansfield Keeni
            Postal: Cyber Solutions Inc.
                    6-6-3, Minami Yoshinari
                    Aoba-ku, Sendai, Japan 989-3204.
               Tel: +81-22-303-4012
               Fax: +81-22-303-4015
            E-mail: [email-masked]
            "

       DESCRIPTION
           "The MIB module pertaining to the reception and processing
            of Syslog compatible messages."

       REVISION "200306250000Z"  -- Wed June      25 00:00 GMT 2003
       DESCRIPTION
           "The initial version of this MIB module."
       ::= { mib-2 999999 }     -- Will be assigned by IANA

   -- -------------------------------------------------------------
   -- Textual Conventions
   -- -------------------------------------------------------------

Expires: August 15, 2004                                        [Page 6]

Internet Draft                                         February 16, 2004

   SyslogFacility  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This textual convention enumerates the facilities
            that originate syslog messages.
            The value noMap(99) indicates that the appropriate
            facility will be provided by the application on the
            managed entity.
            If this option is not available on a particular entity,
            attempts to set the facillity to this value will fail
            with an error-status of wrongValue.
           "
       REFERENCE
           "The BSD syslog Protocol (RFC 3164) sec. 4.1.1 (Table 1).
           "
       SYNTAX  INTEGER {
                         kernel          (0), -- kernel messages
                         user            (1), -- user-level messages
                         mail            (2), -- mail system
                         daemon          (3), -- system daemons
                         auth            (4), -- authorization messages
                         syslog          (5), -- messages generated by syslogd
                         lpr             (6), -- line printer subsystem
                         news            (7), -- network news subsystem
                         uucp            (8), -- UUCP subsystem
                         cron            (9), -- clock daemon
                         authPriv        (10),-- authorization messages
                                              --    (private)
                         ftp             (11),-- ftp daemon
                         ntp             (12),-- NTP subsystem
                         security        (13),-- security subsystems
                                              --    (firewalling, etc.)
                         console         (14),-- /dev/console output

                         local0          (16),
                         local1          (17),
                         local2          (18),
                         local3          (19),
                         local4          (20),
                         local5          (21),
                         local6          (22),
                         local7          (23),
                         noMap           (99)
                       }

Expires: August 15, 2004                                        [Page 7]

Internet Draft                                         February 16, 2004

   SyslogSeverity  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This textual convention enumerates the severity levels
            of syslog messages.  The syslog protocol uses the values
            0 (emergency), to 7 (debug)."
       REFERENCE
           "The BSD syslog Protocol (RFC 3164) sec. 4.1.1 (Table 2)
           "
       SYNTAX  INTEGER {
                         emergency       (0),  -- system is unusable
                         alert           (1),  -- action must be taken
                                               --          immediately
                         critical        (2),  -- critical conditions
                         error           (3),  -- error conditions
                         warning         (4),  -- warning conditions
                         notice          (5),  -- normal but significant
                                               --              condition
                         info            (6),  -- informational
                         debug           (7),  -- debug-level messages
                         other           (99)  -- none of the above
                       }

   SyslogSeverityCompOP  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The operator that will be applied to the severity
            before the selection for an action takes place.
           "
       SYNTAX INTEGER  {
                         none                  (1),
                         greaterThanOrEqual    (2),
                         lessThanOrEqual       (3),
                         greaterThan           (4),
                         lessThan              (5),
                         notGreaterThanOrEqual (6),
                         notLessThanOrEqual    (7),
                         notGreaterThan        (8),
                         notLessThan           (9),
                         equal                 (10),
                         notEqual              (11)
                       }

Expires: August 15, 2004                                        [Page 8]

Internet Draft                                         February 16, 2004

   SyslogTransport  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The Transport that will be used to send and/or
            receive messages.
           "
       REFERENCE
           "The The BSD syslog Protocol RFC 3164 Sec. 2.
           "
       SYNTAX INTEGER  {
                         any                   (1),
                         udp                   (2),
                         tcp                   (3)
                       }

   SyslogService  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The service name or port number that will be used to
            send and/or receive messages.
            The special name ''any'' is reserved. It denotes
            all ports and is applicable only in the context of
            message reception.
            In case the service name is given, and it is not ''any'',
            the service name must resolve to a port number on the
            local host.
           "
       SYNTAX OCTET STRING (SIZE (0..255))

   -- -------------------------------------------------------------
   -- syslogMIB - the main groups
   -- -------------------------------------------------------------

   syslogSystem              OBJECT IDENTIFIER
                         ::= { syslogMIB 1 }

   syslogProc                OBJECT IDENTIFIER
                         ::= { syslogMIB 2 }

Expires: August 15, 2004                                        [Page 9]

Internet Draft                                         February 16, 2004

   -- -------------------------------------------------------------
   -- syslogSystem
   -- -------------------------------------------------------------

   -- The system wide parameters

   syslogDefaultTransport OBJECT-TYPE
       SYNTAX      SyslogTransport
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default transport that a syslog process will use
            to send syslog messages.
           "
       REFERENCE
           "The BSD syslog Protocol RFC 3164 Sec. 2.
           "
       DEFVAL  {udp}
       ::= { syslogSystem 1 }

   syslogDefaultService OBJECT-TYPE
       SYNTAX      SyslogService
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default service name or port number that a syslog
            process will use to send syslog messages.
           "
       REFERENCE
           "The BSD syslog Protocol RFC 3164 Sec. 2.
           "
       DEFVAL  { "514" }
       ::= { syslogSystem 2 }

   syslogDefaultFacility OBJECT-TYPE
       SYNTAX      SyslogFacility
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default syslog facility that will be added to syslog
            messages when the message needs to be relayed and does not
            have priority specified.
           "
       ::= { syslogSystem 3 }

Expires: August 15, 2004                                       [Page 10]

Internet Draft                                         February 16, 2004

   syslogDefaultSeverity OBJECT-TYPE
       SYNTAX      SyslogSeverity
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default syslog severity that will be added to syslog
            messages when the message needs to be relayed and does not
            have priority specified.
           "
       ::= { syslogSystem 4 }

   syslogMaxMessageSize OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The maximum size of the syslog messages in bytes.
           "
       DEFVAL { 1024 }
       ::= { syslogSystem 5 }

   -- -------------------------------------------------------------
   -- syslogProc
   -- -------------------------------------------------------------
   syslogProcTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogProcEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the syslog processes
            serviced by an SNMP agent.
           "
       ::= { syslogProc 1 }

   syslogProcEntry OBJECT-TYPE
       SYNTAX      SyslogProcEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The information pertaining to a syslog process.
           "
       INDEX  { syslogProcIndex }
       ::= { syslogProcTable 1 }

Expires: August 15, 2004                                       [Page 11]

Internet Draft                                         February 16, 2004

   SyslogProcEntry ::=
       SEQUENCE {
           syslogProcIndex
                Unsigned32,
           syslogProcMsgsReceived
                Counter32,
           syslogProcMsgsRelayed
                Counter32,
           syslogProcMsgsDropped
                Counter32,
           syslogProcMsgsIllFormed
                Counter32,
           syslogProcMsgsIgnored
                Counter32,
           syslogProcMsgsRejected
                Counter32,
           syslogProcLastMsgRecdTime
                TimeStamp,
           syslogProcLastMsgDeliveredTime
                TimeStamp,
           syslogProcStartTime
                TimeStamp,
           syslogProcLastError
                SnmpAdminString,
           syslogProcLastErrorTime
                TimeStamp,
           syslogProcReference
                Integer32
       }

   -- option for allowed peers needs to be added

   syslogProcIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The Index that uniquely identifies the syslog process in the
            syslogProcess table.
           "
       ::= { syslogProcEntry 1 }

Expires: August 15, 2004                                       [Page 12]

Internet Draft                                         February 16, 2004

   syslogProcMsgsReceived OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages received by the syslog
            process. This includes messages that were ignored.
           "
       ::= { syslogProcEntry 2 }

   syslogProcMsgsRelayed OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages relayed by the syslog
            process to other syslog processes.
           "
       ::= { syslogProcEntry 3 }

   syslogProcMsgsDropped OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that could not be relayed
            (could not be queued for transmitting)."
       ::= { syslogProcEntry 4 }

   syslogProcMsgsIllFormed OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were rejected by the
            syslog process because these were not well-formed.
           "
       ::= { syslogProcEntry 5 }

Expires: August 15, 2004                                       [Page 13]

Internet Draft                                         February 16, 2004

   syslogProcMsgsIgnored OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were not processed by the
            syslog process because the message did not meet
            the specification of 'allowed specifications' ( either
            the program name or the priority level of the message
            or both did not match any selection specified
            for this process in the syslogCtlSelectionTable).
           "
       ::= { syslogProcEntry 6 }

   syslogProcMsgsRejected OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were rejected by the
            syslog process because the messsage was from a host/service
            that did not match any selection specified for this process
            in the syslogCtlSelectionTable and was not on the allowed
            host/services list.
           "
       ::= { syslogProcEntry 7 }

   syslogProcLastMsgRecdTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was received
            by the syslog process locally or from a remote
            syslog process.
           "
       ::= { syslogProcEntry 8 }

   syslogProcLastMsgDeliveredTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was delivered
            by the syslog process.
           "
       ::= { syslogProcEntry 9 }

Expires: August 15, 2004                                       [Page 14]

Internet Draft                                         February 16, 2004

   syslogProcStartTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when this process was started.
           "
       ::= { syslogProcEntry 10 }

   syslogProcLastError OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "A description of the last error that was encountered
            by this process.
           "
       ::= { syslogProcEntry 11 }

   syslogProcLastErrorTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last error was encountered.
           "
       ::= { syslogProcEntry 12 }

   syslogProcReference OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "If the Host resource MIB is serviced on the host then
            this will entry will have the value of the hrSWRunIndex
            of the corresponding entry in the hrSWRunTable.
            Otherwise this object will be inaccessible,
           "
       ::= { syslogProcEntry 1 }

   syslogParamsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogParamsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the parameters
           that control the syslog processes.
           "

Expires: August 15, 2004                                       [Page 15]

Internet Draft                                         February 16, 2004

       ::= { syslogProc 2 }

   syslogParamsEntry OBJECT-TYPE
       SYNTAX      SyslogParamsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The parameters pertaining to a syslog process."
       INDEX  { syslogProcIndex }
       ::= { syslogParamsTable 1 }

   SyslogParamsEntry ::=
       SEQUENCE {
           syslogParamsProcDescr
                SnmpAdminString,
           syslogParamsBindAddrType
                InetAddressType,
           syslogParamsBindAddr
                InetAddress,
           syslogParamsSendToAllAddresses
                TruthValue,
           syslogParamsCompression
                INTEGER,
           syslogParamsConfFileName
                SnmpAdminString,
           syslogParamsFacilityTranslation
                INTEGER,
           syslogParamsPIDFileName
                SnmpAdminString,
           syslogParamsDNSLookup
                INTEGER,
           syslogParamsSeverityCompOP
                SyslogSeverityCompOP,
           syslogParamsSecuritySpecs
                INTEGER,
           syslogParamsProcessStatus
                INTEGER,
           syslogParamsStorageType
                StorageType,
           syslogParamsRowStatus
                RowStatus
        }

Expires: August 15, 2004                                       [Page 16]

Internet Draft                                         February 16, 2004

   syslogParamsProcDescr OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A user definable description of the syslog process.
           "
       ::= { syslogParamsEntry 1 }

   syslogParamsBindAddrType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of Internet address which follows
            in syslogParamsBindAddr.
           "
       ::= { syslogParamsEntry 2 }

   syslogParamsBindAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The specific IP address or hostname the syslog process will
            bind to. If a hostname is specified, the IPv4 or IPv6 address
            corresponding to the hostname will be used.
           "
       ::= { syslogParamsEntry 3 }

   syslogParamsSendToAllAddresses OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "If the destination host, for a message to be forwarded,
            has more than one A or AAAA record process, Send the
            message to all the addresses (true) else send to only
            one of the addresses.
           "
       DEFVAL     { false }
       ::= { syslogParamsEntry 4 }

Expires: August 15, 2004                                       [Page 17]

Internet Draft                                         February 16, 2004

   syslogParamsCompression OBJECT-TYPE
       SYNTAX      INTEGER {
                   off       (1),
                   offIfPipe (2),
                   on        (3)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "If 'off', disable the compression of repeated instances
            of the same line into a single line of the form ``last
            message repeated N times''.
            If 'offIfPipe' disable the compression when the output
            is a pipe to another program. Otherwise the compression
            is enabled.
           "
       DEFVAL { on }
       ::= { syslogParamsEntry 5 }

   syslogParamsConfFileName OBJECT-TYPE
       SYNTAX       SnmpAdminString
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
         "The fullpath name of the configuration file where the
          syslog process's message selection and corresponding action
          rules will be read from.
          Data is loaded from this file into the syslogCtlSelectionTable
          and the syslogCtlLogActionTable.
          If the objects loaded from the file specified by this object
          have an access level of read-create this file MUST be
          be writable so that modifications to the corresponding objects,
          if any, will be effected in this file.
          If the system does not support the specification of a
          configuration file this field will not be accessible.
         "
       DEFVAL { "/etc/syslog.conf" }
       ::= { syslogParamsEntry 6 }

Expires: August 15, 2004                                       [Page 18]

Internet Draft                                         February 16, 2004

   syslogParamsFacilityTranslation OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "If false(2), disable the translation of messages received
            with facility ``kern'' to facility ``user''.  Usually the
            ``kern'' facility is reserved for messages read directly from
            /dev/klog.
           "
       DEFVAL { true }
       ::= { syslogParamsEntry 7 }

   syslogParamsPIDFileName OBJECT-TYPE
       SYNTAX       SnmpAdminString
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "The fullpath name of the file where the syslog process ID
            will be recorded.
            In case the system does not support the feature of recording
            syslog's process ID - this object will not be accessible.
           "
       DEFVAL { "/etc/syslog.pid" }
       ::= { syslogParamsEntry 8 }

   syslogParamsDNSLookup OBJECT-TYPE
       SYNTAX      INTEGER {
                   useLocalCache       (1),
                   doNotUseLocalCache  (2),
                   doNotUseLocalCache  (3)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "If doNotUseLocalCache is on, fresh DNS lookups will
            be carried out everytime a hostname is encountered.
            Else, DNS lookups will be carried out only once for
            each hostname.
           "
       DEFVAL { useLocalCache }
       ::= { syslogParamsEntry 9 }

Expires: August 15, 2004                                       [Page 19]

Internet Draft                                         February 16, 2004

   syslogParamsSeverityCompOP  OBJECT-TYPE
       SYNTAX SyslogSeverityCompOP
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "The default value of the operator that should be
            applied to the syslogCtlSelectionSeverity before the
            selection takes place.
           "
       DEFVAL      { greaterThanOrEqual }
       ::= { syslogParamsEntry 10 }

   syslogParamsSecuritySpecs   OBJECT-TYPE
       SYNTAX       INTEGER  {
                         none                      (1),
                         doNotRecvFromRemoteHosts  (2),
                         doNotOpenNetworkSockets   (3)
                       }
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "If doNotRecvFromRemoteHosts is selected then the
            corresponding syslog process will not receive messages
            from remote hosts.
            If doNotOpenNetworkSockets is selected then the syslog
            process will not receive from or forward to remote hosts.
           "
       DEFVAL      { none }
       ::= { syslogParamsEntry 11 }

   syslogParamsProcessStatus OBJECT-TYPE
       SYNTAX       INTEGER  {
                         unknown  (1),
                         started  (2),
                         suspended(3),
                         stopped  (4)
                       }
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The status of the process.
           "
       DEFVAL      { unknown }
       ::= { syslogParamsEntry 12 }

Expires: August 15, 2004                                       [Page 20]

Internet Draft                                         February 16, 2004

   syslogParamsStorageType OBJECT-TYPE
       SYNTAX       StorageType
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "This object defines whether the parameters defined in this
            row are kept in volatile storage and lost upon reboot or
            are backed up by non-volatile (permanent) storage.
            Conceptual rows having the value 'permanent' need not
            allow write-access to any columnar objects in the row.
           "
       ::= { syslogParamsEntry 13 }

   syslogParamsRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is used to create, modify and delete rows in
            the syslogParamsTable.
            Objects in a row can be modified only when the value of this
            object in the corresponding conceptual row is not ''active''.
            Thus to modify one or more of the objects in this conceptual
            row,
              a. change the row status to ''notInService'',
              b. change the values of the row
              c. change the row status to ''active''
            The syslogParamsRowStatus may be changed to ''active'' iff
            all the MOs in the conceptual row have been assigned valid
            values.
           "
       ::= { syslogParamsEntry 14 }

   syslogAllowedHostsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogAllowedHostsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the Hosts
           from which messages will be accepted.
           "
       ::= { syslogProc 3 }

Expires: August 15, 2004                                       [Page 21]

Internet Draft                                         February 16, 2004

   syslogAllowedHostsEntry OBJECT-TYPE
       SYNTAX      SyslogAllowedHostsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The host information."
       INDEX  { syslogProcIndex }
       ::= { syslogAllowedHostsTable 1 }

   SyslogAllowedHostsEntry ::=
       SEQUENCE {
           syslogAllowedHostsAddressType
                InetAddressType,
           syslogAllowedHostsAddress
                InetAddress,
           syslogAllowedHostsMaskLen
                InetAddressPrefixLength,
           syslogAllowedHostsTransport
                SyslogTransport,
           syslogAllowedHostsPort
                SyslogService,
           syslogAllowedHostsStorageType
                StorageType,
           syslogAllowedHostsRowStatus
                RowStatus
        }

   syslogAllowedHostsAddressType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of Internet address which follows
            in syslogAllowedHostsAddress.
           "
       ::= { syslogAllowedHostsEntry 1 }

   syslogAllowedHostsAddress OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The IP address or hostname specification of the host from
            which the syslog process will accept messages.
           "
       ::= { syslogAllowedHostsEntry 2 }

Expires: August 15, 2004                                       [Page 22]

Internet Draft                                         February 16, 2004

   syslogAllowedHostsMaskLen OBJECT-TYPE
       SYNTAX      InetAddressPrefixLength
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "If the syslogAllowedHostsAddressType is ipv4(1), ipv6(2)
            this object represents the number of bits that will be
            taken into account when the address of the originating
            is being compared with syslogAllowedHostsAddress.

            The default value of this MO will be the length of the
            corresponding syslogAllowedHostsAddress.

            If the syslogAllowedHostsAddressType is not ipv4(1) or
            ipv6(2) this object is not used.

            A value of 0 indicates that the prefix is not used or is
            not applicable.
           "
       DEFVAL     { 0 }
       ::= { syslogAllowedHostsEntry 3 }

   syslogAllowedHostsTransport OBJECT-TYPE
       SYNTAX      SyslogTransport
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The Transport specification that will be used to decide
            whether the messsage will be accepted from a host or
            not.
           "
       DEFVAL     { udp }
       ::= { syslogAllowedHostsEntry 4 }

   syslogAllowedHostsPort OBJECT-TYPE
       SYNTAX      SyslogService
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The port specification that will be used to decide
            whether the messsage will be accepted from a host or
            not.
           "
       DEFVAL     { "any" }
       ::= { syslogAllowedHostsEntry 5 }

Expires: August 15, 2004                                       [Page 23]

Internet Draft                                         February 16, 2004

   syslogAllowedHostsStorageType OBJECT-TYPE
       SYNTAX       StorageType
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "This object defines whether the parameters defined in this
            row are kept in volatile storage and lost upon reboot or
            are backed up by non-volatile (permanent) storage.
            Conceptual rows having the value 'permanent' need not
            allow write-access to any columnar objects in the row.
           "
       ::= { syslogAllowedHostsEntry 6 }

   syslogAllowedHostsRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is used to create and delete rows in the
            syslogAllowedHostsTable.
            All the columns in this conceptual row MUST have valid
            values before this column can be assigned the value
            ''active''.
           "
       ::= { syslogAllowedHostsEntry 7 }

   -- -------------------------------------------------------------
   -- Conformance Information
   -- -------------------------------------------------------------

   syslogConformance OBJECT IDENTIFIER
                             ::= { syslogMIB 4 }

   syslogGroups OBJECT IDENTIFIER
                             ::= { syslogConformance 1 }

   syslogCompliances OBJECT IDENTIFIER
                             ::= { syslogConformance 2 }

Expires: August 15, 2004                                       [Page 24]

Internet Draft                                         February 16, 2004

   -- -------------------------------------------------------------
   -- units of conformance
   -- -------------------------------------------------------------

   syslogSystemGroup OBJECT-GROUP
       OBJECTS {
                syslogDefaultTransport,
                syslogDefaultService,
                syslogDefaultFacility,
                syslogDefaultSeverity,
                syslogMaxMessageSize

       }
       STATUS  current
       DESCRIPTION
           "A collection of objects providing system-wide
            parameters for syslog processes.
           "
       ::= { syslogGroups 1}

   syslogStatsGroup OBJECT-GROUP
       OBJECTS {
               --  syslogProcIndex,
                   syslogProcMsgsReceived,
                   syslogProcMsgsRelayed,
                   syslogProcMsgsDropped,
                   syslogProcMsgsIllFormed,
                   syslogProcMsgsIgnored,
                   syslogProcMsgsRejected,
                   syslogProcLastMsgRecdTime,
                   syslogProcLastMsgDeliveredTime,
                   syslogProcStartTime,
                   syslogProcLastError,
                   syslogProcLastErrorTime,
                   syslogProcReference
               }
       STATUS  current
       DESCRIPTION
           "A collection of objects providing message related
            statistics."
       ::= { syslogGroups 2}

Expires: August 15, 2004                                       [Page 25]

Internet Draft                                         February 16, 2004

   syslogParamsGroup OBJECT-GROUP
       OBJECTS {
                   syslogParamsProcDescr,
                   syslogParamsBindAddrType,
                   syslogParamsBindAddr,
                   syslogParamsSendToAllAddresses,
                   syslogParamsCompression,
                   syslogParamsConfFileName,
                   syslogParamsFacilityTranslation,
                   syslogParamsPIDFileName,
                   syslogParamsDNSLookup,
                   syslogParamsSeverityCompOP,
                   syslogParamsSecuritySpecs,
                   syslogParamsStorageType,
                   syslogParamsRowStatus,
                   syslogAllowedHostsAddressType,
                   syslogAllowedHostsAddress,
                   syslogAllowedHostsMaskLen,
                   syslogAllowedHostsTransport,
                   syslogAllowedHostsPort,
                   syslogAllowedHostsStorageType,
                   syslogAllowedHostsRowStatus
               }
       STATUS  current
       DESCRIPTION
           "A collection of objects representing the run time parameters
            for the syslog processes.
           "
       ::= { syslogGroups 3}

Expires: August 15, 2004                                       [Page 26]

Internet Draft                                         February 16, 2004

   -- -------------------------------------------------------------
   -- compliance statements
   -- -------------------------------------------------------------

   syslogCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for an agent implememting the
            syslog MIB.
           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogStatsGroup
       }

       GROUP       syslogSystemGroup
       DESCRIPTION
           "The syslogSystemGroup group is mandatory only for
            agents which support monitoring and control of the
            syslog system wide parameters.
            If only monitoring is supported then the corresponding
            objects must have access read-only.
           "
       GROUP       syslogParamsGroup
       DESCRIPTION
           "The syslogParamsGroup group is mandatory only for
            agents which support monitoring and/or control of
            syslog processes.
            If only monitoring is supported then the corresponding
            objects must have access read-only.
           "
       ::= { syslogCompliances 1 }

   END

Expires: August 15, 2004                                       [Page 27]

Internet Draft                                         February 16, 2004

5.  Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

6.  Acknowledgments
   The authors would like to thank David Harrington, Mark Ellison, Mike
   MacFaden, Dave T Perkins and members of the WIDE-netman group for their
   comments and suggestions.

7.  Security Considerations

   Syslog plays a very important role in the computer and network
   security of an organization. SyslogMIB defines several managed
   objects that may be used to monitor configure and control syslog
   processes. As such improper manipulation of the objects represented
   by this MIB may lead to an attack on an important component of the
   computer and network security infrastructure.  The objects in
   syslogParamsTable, syslogAllowedHostsTable, syslogCtlSelectionTable,
   syslogCtlLogActionTable, syslogCtlUserActionTable
   syslogCtlFwdActionTable, syslogCtlPipeActionTable  may be
   misconfigured to cause syslog messages to be diverted or lost. A
   misconfiguration may also result in a DoS attack on a user or
   service.  There are a number of management objects defined in this
   MIB module with a MAX-ACCESS clause of read-write and/or read-create.
   Such objects may be considered sensitive or vulnerable in some
   network environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their

Expires: August 15, 2004                                       [Page 28]

Internet Draft                                         February 16, 2004

   sensitivity/vulnerability:

       o  syslogParamsTable: the objects in this table describe the
          configuration of the syslog processes.
       o  syslogAllowedHostsTable: the objects in this table describe the hosts
          from which syslog messages will be accepted. Improper configuration may
          lead to loss of messages from an important source or a flood of messages
          from a, potentially rogue, source.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

       o  syslogProcTable: objects in this table carry sensitive information.  The
          counters may reveal information about the deployment and effectiveness
          of the relevant security systems. The counters may be analyzed to tell
          whether the security systems are able to detect an event or not.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

Expires: August 15, 2004                                       [Page 29]

Internet Draft                                         February 16, 2004

8.  References:

[Normative References]

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Textual Conventions for
            SMIv2", STD 58, RFC 2579, April 1999

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999

[Informative References]

[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
            for Describing SNMP Management Frameworks", RFC 2571, April
            1999

[RFC1155]   Rose, M., and K. McCloghrie, "Structure and Identification
            of Management Information for TCP/IP-based Internets", STD
            16, RFC 1155, May 1990

[RFC1212]   Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
            16, RFC 1212, March 1991

[RFC1215]   M. Rose, "A Convention for Defining Traps for use with the
            SNMP", RFC 1215, March 1991

[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
            Network Management Protocol", STD 15, RFC 1157, May 1990.

[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Introduction to Community-based SNMPv2", RFC 1901, January
            1996.

[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Transport Mappings for Version 2 of the Simple Network
            Management Protocol (SNMPv2)", RFC 1906, January 1996.

[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
            Processing and Dispatching for the Simple Network Management
            Protocol (SNMP)", RFC 2572, April 1999

Expires: August 15, 2004                                       [Page 30]

Internet Draft                                         February 16, 2004

[RFC2574]   Blumenthal, U., and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", RFC 2574, April 1999

[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Protocol Operations for Version 2 of the Simple Network
            Management Protocol (SNMPv2)", RFC 1905, January 1996.

[RFC2573]   Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
            RFC 2573, April 1999

[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
            Access Control Model (VACM) for the Simple Network
            Management Protocol (SNMP)", RFC 2575, April 1999.

[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart,
            "Introduction to Version 3 of the Internet-standard Network
            Management Framework", RFC 2570, April 1999

[RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
           "Introduction and Applicability Statements for the
            Internet-Standard Management Framework", RFC 3410,
            December 2002.

[RFC3164]   C. Lonvick, "The BSD Syslog Protocol", RFC 3164,
            August 2001.

Expires: August 15, 2004                                       [Page 31]

Internet Draft                                         February 16, 2004

9.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires: August 15, 2004                                       [Page 32]

Internet Draft                                         February 16, 2004

10.  Authors Address

   Glenn Mansfield Keeni
   Cyber Solutions Inc.
   6-6-3 Minami Yoshinari
   Aoba-ku, Sendai 989-3204
   Japan

   Phone: +81-22-303-4012
   EMail: [email-masked]

   Bruno Pape
   Enterasys Networks, Inc.
   35 Industrial Way
   Rochester, NH 03867
   USA

   Email:  [email-masked]"
   Tel:    +1 603 337 0446

Expires: August 15, 2004                                       [Page 33]

Internet Draft                                         February 16, 2004

                                APPENDIX

This section documents the development of the draft. It will be deleted
when the draft bvecomes an RFC.

Revision History:

    REVISION "200406160000Z"  -- Mon Feb       16 00:00 GMT 2004
    DESCRIPTION
        "Major change.
             The configuration parts have been removed.

         Updated the description clauses.

         Editorial nits fixed.
        "

    REVISION "200306250000Z"  -- Wed June      25 00:00 GMT 2003
    DESCRIPTION
        "Changed the type of
             syslogProcLastError            SnmpAdminString,
             from Integer32.

         DEFVAL { 0 ] is added to syslogAllowedHostsMaskLen

         MO name changed from
         syslogCtlSelectionHostname to syslogCtlSelectionHostName

         Updated the description clauses.

         Fixed nits pointed out in Bert's mails of 20030319 and
         revised the document wrt the guidelines in
         draft-ietf-ops-mib-review-guidelines-01.txt

         Editorial nits fixed.
        "

    REVISION "200303030000Z"  -- Mon March     03 00:00 GMT 2003
    DESCRIPTION
        "Fixing of nits in descriptions, addition of references,
         addition of the following MOs
             syslogProcMsgsIllFormed        Counter32,
             syslogProcStartTime            TimeStamp,
             syslogProcLastError            Integer32,
             syslogProcLastErrorTime        TimeStamp,
             syslogParamsStorageType        StorageType,
             syslogCtlFwdActionSrcAddrType  InetAddressType,

Expires: August 15, 2004                                       [Page 34]

Internet Draft                                         February 16, 2004

             syslogCtlFwdActionSrcAddr      InetAddress,
         added enumeration ''suspended(2)'' to
             syslogParamsProcessStatus.
        "

    REVISION "200212252343Z"  -- Wed December  25 23:43 GMT 2002
    DESCRIPTION
        "Radical revision of the MIB structure and design."

    REVISION "200206061841Z"  -- Thu Jun  6 18:41 GMT 2002
    DESCRIPTION
        "The initial version of this MIB module."

Expires: August 15, 2004                                       [Page 35]

------------------------------

Date: Mon, 16 Feb 2004 14:13:35 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: -procotol relay operations

Hi,

Assuming you use snmpv3 with e2e encryption, the relay wouldn't be able
to access the message contents to fragment it. An SNMP message should
never be fragmented anyway, so using snmp for the example is a bad
choice.

You should definitely not think of snmp as just some type of transport;
it is a network management protocol at the same level as syslog. You
shouldn't talk about sending snmp over syslog, and you shouldn't talk
about sending syslog over snmp. SNMP is a parallel NM protocol for
specific types of management communications, such as notifications, so
syslog doesn't need to reinvent that wheel. It would be good if the
format selected for content in the syslog protocol could be reused
easily in the parallel SNMP protocol.

The idea of a syslog relay fragmenting an snmp notification is just
wrong. One protocol does not travel within the other; they are
independent protocols.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, February 13, 2004 12:55 PM
> To: [email-masked]
> Subject: -procotol relay operations
>
> Hi WG,
>
> we talked quite a bit about different MTUs for different transport
> mapping. We may run into a situation where a message is larger than is
> actually supported by the transport (e.g a hypothetical SNMP trap
> transport supporting only ~500 octets). As we have multi-part
> message in
> -protocol, a relay COULD create a multi-part message at this
> time. This
> could be an elegant solution to the minimum size problem, too. You can
> directly compare it it IP fragmentation.
>
> Question now: Is there any objection against specifying it in
> that way,
> at least as a MAY rule for relays. I think it definitely has
> advantages
> - it allows us to care for the unsual cases...
>
> Rainer
>
>
>

------------------------------

Date: Tue, 17 Feb 2004 11:42:45 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -procotol relay operations

Hi David,

I think we are probably talking about two different things here.

Let me start with this:

> One protocol does not travel within the other; they are
> independent protocols.

Honestly, I think there was something different being discussed on this list, and I used this as a sample. I am primarily refering to this thread here: http://www.syslog.cc/ietf/autoarc/msg00992.html

Let me sum it up as *I* understand it:

There is some concensus that it is helpful to allow a syslog message to be feed to an SNMP based system. To do so, there should be a mapping between a syslog message and an SNMP trap (or inform?) message. I think the quoted thread was about this.

So what I see is the following picture:

Device --> syslog relay/gateway --> SNMP

As written, the syslog relay is no less a simple relay but more an application level gateway between syslog protocol and SNMP protocol. It must encapsulate/map the syslog message to SNMP.

In general, this is relatively straightforward. Move the syslog MSG to the SNMP message equivalent and copy some of the header fields (like timestamp) to the SNMP properties.

It becomes complicated, if the syslog message is of large size (e.g. 1024 byte) and the SNMP implementation only supplies message text up to 512 bytes (due to MTU restrictions). Please note that the numbers are randomly taken - actual values may be different but I wanted to save some time on an exact research. I think the provided random numbers give a good-enough idea.

Now we have the issue that the syslog2SNMP gateway can not forward the full message via SNMP, simply because the message text does not fit.

So it has these choices:

- - discard message at all (if it can't deliver it completely, it does deliver nothing)
- - discard the 512 octets at the end that do not fit. These are LOST
- - use syslog multi-part messages and create 3 SNMP messages
  (why three? Syslog multi-part messaging takes some extra space, so the
  overall message size becomes larger than 1024.)

This is the model I have in mind. Now to the answers:

> Assuming you use snmpv3 with e2e encryption, the relay
> wouldn't be able
> to access the message contents to fragment it. An SNMP message should
> never be fragmented anyway, so using snmp for the example is a bad
> choice.

The SNMP message will not get "fragmented". It is syslog multi-part messaging, that is applied to the syslog part of the gateway, only. SNMP syntax and semantic will not be touched.

> You should definitely not think of snmp as just some type of
> transport;
> it is a network management protocol at the same level as syslog. You
> shouldn't talk about sending snmp over syslog, and you shouldn't talk
> about sending syslog over snmp. SNMP is a parallel NM protocol for
> specific types of management communications, such as notifications, so
> syslog doesn't need to reinvent that wheel.

Well, actually I find some value in the ability to integrate syslog message into an SNMP solution. I think we all know this is probably not the best way to do it, but it may be very handy if the syslog-talking device in question does not at all support SNMP...

I think that was the spirit behind the quoted discussion thread above.

> It would be good if the
> format selected for content in the syslog protocol could be reused
> easily in the parallel SNMP protocol.

I think the format is far different. The header fields and some other structured elements will probably be be able to be mapped to SNMP. But I think it is a mapping (gateway level), not a pure resue.

And keep in mind, I am *ONLY* talking about syslog-type message being sent as TRAPS. I am NOT talking about MIB GET/SET requests.

> The idea of a syslog relay fragmenting an snmp notification is just
> wrong.

I agree ... and a syslog relay will never fragment a SNMP message, because it does not know SNMP at this level. What I could forsee, however, is:

SNMP Trap --> SNMP/syslog Gateway --> syslog server

In this case, the same semantics as in my first example would need to apply. If I take the SNMP trap message AND its size is larger than what is supported in the syslog system, then the SNMP to syslog Gateway has the same choices. If I had to implement the gatway, I would probably use syslog multi-part messaging to transmit the whole message.

> One protocol does not travel within the other; they are
> independent protocols.

From a high-level point of view, I would find it desirable to have rules that would allow to travel syslog data over an SNMP tunnel and SNMP messages to travel over a syslog tunnel. In this case, if the sender AND receiver is both syslog (or both SNMP), I would assume that the message should be received as a native, unalterated message on the receiver. I think, however, that this goal is not worth putting big effort into achieving this. But I don't see anything bad to at least keep it in mind.

I don't see any bad per sé in allowing one protocol to travel inside another as long as this does not force any degradation in either of the protocols.

Rainer
>
> dbh
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Friday, February 13, 2004 12:55 PM
> > To: [email-masked]
> > Subject: -procotol relay operations
> >
> > Hi WG,
> >
> > we talked quite a bit about different MTUs for different transport
> > mapping. We may run into a situation where a message is
> larger than is
> > actually supported by the transport (e.g a hypothetical SNMP trap
> > transport supporting only ~500 octets). As we have multi-part
> > message in
> > -protocol, a relay COULD create a multi-part message at this
> > time. This
> > could be an elegant solution to the minimum size problem,
> too. You can
> > directly compare it it IP fragmentation.
> >
> > Question now: Is there any objection against specifying it in
> > that way,
> > at least as a MAY rule for relays. I think it definitely has
> > advantages
> > - it allows us to care for the unsual cases...
> >
> > Rainer
> >
> >
> >
>
>
>

------------------------------

Date: Tue, 17 Feb 2004 06:20:34 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: RE: -procotol relay operations

Hi,

Just a side-note: I don't mind having the discussion about this on the
list but the concept is outside the current scope of our work.  After
we get the current pieces of work submitted to the RFC editor, then we
can discuss if we want to formally address this (with the blessings of
the O&M ADs).

The concept does apply to Glenn's ID but I believe that he is asking if
the community feels that _any_ SNMP notification should be sent if
something goes wrong with sending a syslog message.  Defining a syslog to
SNMP gateway is out of scope for his work at this time as well.

Thanks,
Chris

On Tue, 17 Feb 2004, Rainer Gerhards wrote:

> Hi David,
>
> I think we are probably talking about two different things here.
>
> Let me start with this:
>
> > One protocol does not travel within the other; they are
> > independent protocols.
>
> Honestly, I think there was something different being discussed on this list, and I used this as a sample. I am primarily refering to this thread here: http://www.syslog.cc/ietf/autoarc/msg00992.html
>
> Let me sum it up as *I* understand it:
>
> There is some concensus that it is helpful to allow a syslog message to be feed to an SNMP based system. To do so, there should be a mapping between a syslog message and an SNMP trap (or inform?) message. I think the quoted thread was about this.
>
> So what I see is the following picture:
>
> Device --> syslog relay/gateway --> SNMP
>
> As written, the syslog relay is no less a simple relay but more an application level gateway between syslog protocol and SNMP protocol. It must encapsulate/map the syslog message to SNMP.
>
> In general, this is relatively straightforward. Move the syslog MSG to the SNMP message equivalent and copy some of the header fields (like timestamp) to the SNMP properties.
>
> It becomes complicated, if the syslog message is of large size (e.g. 1024 byte) and the SNMP implementation only supplies message text up to 512 bytes (due to MTU restrictions). Please note that the numbers are randomly taken - actual values may be different but I wanted to save some time on an exact research. I think the provided random numbers give a good-enough idea.
>
> Now we have the issue that the syslog2SNMP gateway can not forward the full message via SNMP, simply because the message text does not fit.
>
> So it has these choices:
>
> - discard message at all (if it can't deliver it completely, it does deliver nothing)
> - discard the 512 octets at the end that do not fit. These are LOST
> - use syslog multi-part messages and create 3 SNMP messages
>   (why three? Syslog multi-part messaging takes some extra space, so the
>   overall message size becomes larger than 1024.)
>
> This is the model I have in mind. Now to the answers:
>
>
> > Assuming you use snmpv3 with e2e encryption, the relay
> > wouldn't be able
> > to access the message contents to fragment it. An SNMP message should
> > never be fragmented anyway, so using snmp for the example is a bad
> > choice.
>
> The SNMP message will not get "fragmented". It is syslog multi-part messaging, that is applied to the syslog part of the gateway, only. SNMP syntax and semantic will not be touched.
>
> > You should definitely not think of snmp as just some type of
> > transport;
> > it is a network management protocol at the same level as syslog. You
> > shouldn't talk about sending snmp over syslog, and you shouldn't talk
> > about sending syslog over snmp. SNMP is a parallel NM protocol for
> > specific types of management communications, such as notifications, so
> > syslog doesn't need to reinvent that wheel.
>
> Well, actually I find some value in the ability to integrate syslog message into an SNMP solution. I think we all know this is probably not the best way to do it, but it may be very handy if the syslog-talking device in question does not at all support SNMP...
>
> I think that was the spirit behind the quoted discussion thread above.
>
> > It would be good if the
> > format selected for content in the syslog protocol could be reused
> > easily in the parallel SNMP protocol.
>
> I think the format is far different. The header fields and some other structured elements will probably be be able to be mapped to SNMP. But I think it is a mapping (gateway level), not a pure resue.
>
> And keep in mind, I am *ONLY* talking about syslog-type message being sent as TRAPS. I am NOT talking about MIB GET/SET requests.
>
> > The idea of a syslog relay fragmenting an snmp notification is just
> > wrong.
>
> I agree ... and a syslog relay will never fragment a SNMP message, because it does not know SNMP at this level. What I could forsee, however, is:
>
> SNMP Trap --> SNMP/syslog Gateway --> syslog server
>
> In this case, the same semantics as in my first example would need to apply. If I take the SNMP trap message AND its size is larger than what is supported in the syslog system, then the SNMP to syslog Gateway has the same choices. If I had to implement the gatway, I would probably use syslog multi-part messaging to transmit the whole message.
>
> > One protocol does not travel within the other; they are
> > independent protocols.
>
> >From a high-level point of view, I would find it desirable to have rules that would allow to travel syslog data over an SNMP tunnel and SNMP messages to travel over a syslog tunnel. In this case, if the sender AND receiver is both syslog (or both SNMP), I would assume that the message should be received as a native, unalterated message on the receiver. I think, however, that this goal is not worth putting big effort into achieving this. But I don't see anything bad to at least keep it in mind.
>
> I don't see any bad per sé in allowing one protocol to travel inside another as long as this does not force any degradation in either of the protocols.
>
> Rainer
> >
> > dbh
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[email-masked]]
> > > Sent: Friday, February 13, 2004 12:55 PM
> > > To: [email-masked]
> > > Subject: -procotol relay operations
> > >
> > > Hi WG,
> > >
> > > we talked quite a bit about different MTUs for different transport
> > > mapping. We may run into a situation where a message is
> > larger than is
> > > actually supported by the transport (e.g a hypothetical SNMP trap
> > > transport supporting only ~500 octets). As we have multi-part
> > > message in
> > > -protocol, a relay COULD create a multi-part message at this
> > > time. This
> > > could be an elegant solution to the minimum size problem,
> > too. You can
> > > directly compare it it IP fragmentation.
> > >
> > > Question now: Is there any objection against specifying it in
> > > that way,
> > > at least as a MAY rule for relays. I think it definitely has
> > > advantages
> > > - it allows us to care for the unsual cases...
> > >
> > > Rainer
> > >
> > >
> > >
> >
> >
> >
>
>
>
>

------------------------------

Date: Tue, 17 Feb 2004 15:42:42 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -procotol relay operations

Hi Chris,

thanks for the housekeeping call ;) I agree, we should first finish what is *now* on the agenda.

Just an important note: the discussion below was initiated by me using the SNMP mapping as an example. The initial question I rose was if a syslog relay (only taling syslog ;)) should be allowed to use multi-part messaging IF the received message is larger than the MTU of the target network. So the original discussion was not about SNMP/syslog, but about straight syslog. I would like to mention this to keep the thread on focus, instead of killing it.

So far, Anton commented that a syslog relay should use multi-part messaging if there is no other way to transmit a syslog message to another syslog server. I, too, feel that this is the right way to handle the situation.

If somebody does not like this idea, I would appreciate comments.

Thanks,
Rainer

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 3:21 PM
> To: Rainer Gerhards
> Cc: Harrington, David; [email-masked]
> Subject: RE: -procotol relay operations
>
> Hi,
>
> Just a side-note: I don't mind having the discussion about this on the
> list but the concept is outside the current scope of our work.  After
> we get the current pieces of work submitted to the RFC editor, then we
> can discuss if we want to formally address this (with the blessings of
> the O&M ADs).
>
> The concept does apply to Glenn's ID but I believe that he is
> asking if
> the community feels that _any_ SNMP notification should be sent if
> something goes wrong with sending a syslog message.  Defining
> a syslog to
> SNMP gateway is out of scope for his work at this time as well.
>
> Thanks,
> Chris
>
> On Tue, 17 Feb 2004, Rainer Gerhards wrote:
>
> > Hi David,
> >
> > I think we are probably talking about two different things here.
> >
> > Let me start with this:
> >
> > > One protocol does not travel within the other; they are
> > > independent protocols.
> >
> > Honestly, I think there was something different being
> discussed on this list, and I used this as a sample. I am
> primarily refering to this thread here:
> http://www.syslog.cc/ietf/autoarc/msg00992.html
> >
> > Let me sum it up as *I* understand it:
> >
> > There is some concensus that it is helpful to allow a
> syslog message to be feed to an SNMP based system. To do so,
> there should be a mapping between a syslog message and an
> SNMP trap (or inform?) message. I think the quoted thread was
> about this.
> >
> > So what I see is the following picture:
> >
> > Device --> syslog relay/gateway --> SNMP
> >
> > As written, the syslog relay is no less a simple relay but
> more an application level gateway between syslog protocol and
> SNMP protocol. It must encapsulate/map the syslog message to SNMP.
> >
> > In general, this is relatively straightforward. Move the
> syslog MSG to the SNMP message equivalent and copy some of
> the header fields (like timestamp) to the SNMP properties.
> >
> > It becomes complicated, if the syslog message is of large
> size (e.g. 1024 byte) and the SNMP implementation only
> supplies message text up to 512 bytes (due to MTU
> restrictions). Please note that the numbers are randomly
> taken - actual values may be different but I wanted to save
> some time on an exact research. I think the provided random
> numbers give a good-enough idea.
> >
> > Now we have the issue that the syslog2SNMP gateway can not
> forward the full message via SNMP, simply because the message
> text does not fit.
> >
> > So it has these choices:
> >
> > - discard message at all (if it can't deliver it
> completely, it does deliver nothing)
> > - discard the 512 octets at the end that do not fit. These are LOST
> > - use syslog multi-part messages and create 3 SNMP messages
> >   (why three? Syslog multi-part messaging takes some extra
> space, so the
> >   overall message size becomes larger than 1024.)
> >
> > This is the model I have in mind. Now to the answers:
> >
> >
> > > Assuming you use snmpv3 with e2e encryption, the relay
> > > wouldn't be able
> > > to access the message contents to fragment it. An SNMP
> message should
> > > never be fragmented anyway, so using snmp for the example is a bad
> > > choice.
> >
> > The SNMP message will not get "fragmented". It is syslog
> multi-part messaging, that is applied to the syslog part of
> the gateway, only. SNMP syntax and semantic will not be touched.
> >
> > > You should definitely not think of snmp as just some type of
> > > transport;
> > > it is a network management protocol at the same level as
> syslog. You
> > > shouldn't talk about sending snmp over syslog, and you
> shouldn't talk
> > > about sending syslog over snmp. SNMP is a parallel NM protocol for
> > > specific types of management communications, such as
> notifications, so
> > > syslog doesn't need to reinvent that wheel.
> >
> > Well, actually I find some value in the ability to
> integrate syslog message into an SNMP solution. I think we
> all know this is probably not the best way to do it, but it
> may be very handy if the syslog-talking device in question
> does not at all support SNMP...
> >
> > I think that was the spirit behind the quoted discussion
> thread above.
> >
> > > It would be good if the
> > > format selected for content in the syslog protocol could be reused
> > > easily in the parallel SNMP protocol.
> >
> > I think the format is far different. The header fields and
> some other structured elements will probably be be able to be
> mapped to SNMP. But I think it is a mapping (gateway level),
> not a pure resue.
> >
> > And keep in mind, I am *ONLY* talking about syslog-type
> message being sent as TRAPS. I am NOT talking about MIB
> GET/SET requests.
> >
> > > The idea of a syslog relay fragmenting an snmp
> notification is just
> > > wrong.
> >
> > I agree ... and a syslog relay will never fragment a SNMP
> message, because it does not know SNMP at this level. What I
> could forsee, however, is:
> >
> > SNMP Trap --> SNMP/syslog Gateway --> syslog server
> >
> > In this case, the same semantics as in my first example
> would need to apply. If I take the SNMP trap message AND its
> size is larger than what is supported in the syslog system,
> then the SNMP to syslog Gateway has the same choices. If I
> had to implement the gatway, I would probably use syslog
> multi-part messaging to transmit the whole message.
> >
> > > One protocol does not travel within the other; they are
> > > independent protocols.
> >
> > >From a high-level point of view, I would find it desirable
> to have rules that would allow to travel syslog data over an
> SNMP tunnel and SNMP messages to travel over a syslog tunnel.
> In this case, if the sender AND receiver is both syslog (or
> both SNMP), I would assume that the message should be
> received as a native, unalterated message on the receiver. I
> think, however, that this goal is not worth putting big
> effort into achieving this. But I don't see anything bad to
> at least keep it in mind.
> >
> > I don't see any bad per sé in allowing one protocol to
> travel inside another as long as this does not force any
> degradation in either of the protocols.
> >
> > Rainer
> > >
> > > dbh
> > >
> > > > -----Original Message-----
> > > > From: Rainer Gerhards [mailto:[email-masked]]
> > > > Sent: Friday, February 13, 2004 12:55 PM
> > > > To: [email-masked]
> > > > Subject: -procotol relay operations
> > > >
> > > > Hi WG,
> > > >
> > > > we talked quite a bit about different MTUs for
> different transport
> > > > mapping. We may run into a situation where a message is
> > > larger than is
> > > > actually supported by the transport (e.g a hypothetical
> SNMP trap
> > > > transport supporting only ~500 octets). As we have multi-part
> > > > message in
> > > > -protocol, a relay COULD create a multi-part message at this
> > > > time. This
> > > > could be an elegant solution to the minimum size problem,
> > > too. You can
> > > > directly compare it it IP fragmentation.
> > > >
> > > > Question now: Is there any objection against specifying it in
> > > > that way,
> > > > at least as a MAY rule for relays. I think it definitely has
> > > > advantages
> > > > - it allows us to care for the unsual cases...
> > > >
> > > > Rainer
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
>

------------------------------

Date: Wed, 18 Feb 2004 10:18:03 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-device-mib-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: Syslog MIB
	Author(s)	: G. Keeni, B. Pape
	Filename	: draft-ietf-syslog-device-mib-05.txt
	Pages		: 35
	Date		: 2004-2-18

This memo provides a MIB module that can be used to monitor and manage
syslog processes. It defines objects that allow the collection of
information related to syslog processes, it also defines objects that
can be used to monitor and/or control syslog processes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-05.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-device-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-device-mib-05.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------------------------------

Date: Wed, 18 Feb 2004 11:31:11 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -protocol-03

Rainer:

I have read the draft. Some comments here.  Lot of small ones in a
separate email I will send you directly.

1. I don't think you specified maximum message size anywhere.  Or did I
miss it?

2. You talk a lot about server parsing the syslog message. Are we making
an assumption that receiver must parse messages (for example 5th
paragraph in 4.1.1)? Generally, there seems to be a lot of stuff
dictating behavior for receiver. Why can't we just say: this is valid on
the wire, this is not and leave it up to implementation to decide what
it does with it. For example, we ask receivers to "log" diagnostic
messages.  What does "log" mean here?

3. You use enterprise ID of 0 (IETF) in examples.  Is this valid?
Should we say 0 is reserved and should never be used?  What does 0 mean?

4. Section 4.1.3.  "Any implementation MUST support free configuration
of the FACILITY on the sender."  I think by implementation you are
always assuming a dedicated sender or receiver library product.  I don't
see why I can't just implement sending logic in my app directly and not
have a fixed facility.  I think at best, this is a SHOULD.

5. Section 4.1.6 - Hostname.  So, we specify FQDN and if to present IP.
Not sure if we had a discussion on this, but did we decide to bypass
hostname?  I think it will be a common case where hostname is present,
but machine does not know its domain suffix. I would generally prefer IP
unless it is dynamic (DHCP).

6. Section 4.2.  Which version of Unicode do we support? UTF8 may
support all, but I think we should limit it to some basic Unicode
version.

7. Section 4.3.  Why do we restrict sec-frac to 3 digits?  If somebody
has better precision why not allow it?

8. Section 6.2.3.  I don't think you explain the purpose for allowing
partcount to grow.  I assume this is for streaming.  Needs to be
explained.  I also think it is a strange scheme.  Why don't you allow
incrementing it by one every time?

9. Section 7.2.  Can we use "yes" or "no" instead of "0" and "1"?

10. Section 8.1. If relay can't add structured data elements, it can't
record source IP of the message.  I think we should not lose such
information. Also, need to allow for recording of time or original
reception.

11. Section 8.3. You allow relay to break message into multiple parts.
What happens with a message that is already multi-part?  How do you
distinguish first level of fragmentation from second?

12. The ID is now 45 pages long and growing with every revision.  I
think it would help if we shortened it whenever possible.  After all it
is just a syslog protocol.  This is protocol used for troubleshooting.
It can't be itself overly complicated or give such impression.

Thanks,
Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Monday, February 16, 2004 12:15 PM
> To: [email-masked]
> Subject: -protocol-03
>
>
> Hi WG,
>
> I have edited syslog-protocol so that we are now at
> -protocol-03. I have submitted it to the IETF this morning,
> but as the draft editor is probably very swamped with the
> number of new IDs prior to the Seoul meeting, I have agreed
> with Chris on publishing the not yet officially relased ID on
> my site. I do so in the hope that this will allow us to work
> out some of the issues before Seoul (and eventually identify
> new ones).
>
> It was a rather complete edit, I have placed a full change
> log on my comment's page at
>
> http://www.syslog.cc/ietf/drafts/comments-draft-ietf-syslog-pr
> otocol-03.
> html
>
> This page also links to the "unofficial" -protocol-03
> version. This version addresses many of the issues we
> discussed the past days. Rather than individual replies, I'd
> appreciate if you could have a look at the new ID.
>
> For those without time to access the web, my edit summary is
> as follows:
>
> - general text-cleanup. Abstract and Intro modified. I
> noticed some old text survived in the begininng of section 4,
> removed that, some typos caught, probably twice as much added ;)
>
> - section 3, transport mappings clarified, section 3.1, UDP
> transport required [see issue 10]
>
> - maximum syslog message size is now 1280 bytes (I assume
> this *is* the minimum IPv6 MTU, had no time to check) [see
> issue 11]  ... oops, sorry folks, accidently I removed the
> max size altogether ... shame on me for rushing. 1280 will be
> back in in -protocol-04 ;)
>
> - section 4.2 - MSG - now specifies UTF-8 including including
> all control characters [see issue 9]
>
> - section 4, TRAILER has been removed [see issue 6]
>
> - section 6, multi-part messages heavily changed. Name change
> from fragmentation to "multi-part messaging", more
> definitions, hopefully clearer description (some of the term
> names are *really* lenghty - advise on better terms is taken
> thankfully).
>
> - section 7, definition of structured data element IDs (and
> semantics) added
>
> - section 7.1 - time - tries to solve issue 12
>
> - section 7.2 - orgin - tries to provide a way to preserve
> originator IP addresses inside the message. "origin" is also
> a key element when relay RFC 3164 operations will be
> described (I didn't manage to get this into the -03 version).
>
> - section 8, "relay operations" added, but so far it is more
> or less empty.
>
> - section 9, "security considerations" cleaned up.
>
> - section 9.1 - diagnostic logging - added as a security
> consideration. Comments on this are highly appreciated. This
> was not previously discussed on the WG mailing list
>
> I am looking forward to all comments.
>
> Rainer
> PS: I am unfortunately not able to attend the Seoul meeting
> personally, but Chris has agreed to act as proxy (thanks, Chris!)
>
>

------------------------------

Date: Wed, 18 Feb 2004 15:17:54 -0000
From: Tom Petch <[email-masked]>
Subject: Re: Fragmentation terminology

I think segmentation is the better term.  It is used elsewhere, but in many
places (ATM SAR immediately comes to my mind) and so IMHO only has
overtones of TCP if you limit your knowledge to TCP and IP.

And, of greater or lesser import depending on your religious convictions, I
recall that segmentation was the term chosen by OSI to describe this
mechanism regardless of which layer it appeared in.

Tom Petch

- -----Original Message-----
From: Rainer Gerhards <[email-masked]>
To: Anton Okmianski <[email-masked]>; [email-masked]
<[email-masked]>
Date: 13 February 2004 13:46
Subject: RE: Fragmentation terminology

>Anton,
>
>very reasonable ;)
>
>I think "multi-part" is a good term. OK, it triggers "MIME" in my head,
>but I think every term used to split up a message into multipe
>parts/fragments/segemnts/whatever is already used in some other context.
>As we don't do MIME in syslog, "multi-part" should cause the least
>confusion. I am going to change this in -protocol-03 if nobody objects.
>
>Rainer
>
>> -----Original Message-----
>> From: Anton Okmianski [mailto:[email-masked]]
>> Sent: Friday, February 13, 2004 12:21 AM
>> To: [email-masked]
>> Subject: Fragmentation terminology
>>
>> Rainer:
>>
>> If we keep the syslog fragmentation feature in -protocol, can
>> we change
>> its name to something that can't be confused with IP fragments.
>> Otherwise, I think it can creates confusion when one talks
>> about syslog
>> message fragments.  "Segments" I think is also a term that is already
>> commonly used in TCP.
>>
>> Maybe "multi-part" message and "message part" instead?  I
>> need a way to
>> refer to those pieces in -transport hopefully without having
>> to explain
>> what kind of fragment I am referring to.
>>
>> Thanks,
>> Anton.
>>
>>
>>
>>
>>
>
>

------------------------------

Date: Wed, 18 Feb 2004 13:15:21 -0500
From: Anton Okmianski <[email-masked]>
Subject: syslog-transport-udp ID 00

Hi!

Chris has posted the first draft of the syslog-transport-udp ID on the WG web site. This ID is a required transport mapping for syslog-protocol. Any comments (large and small) are appreciated.  I intend to wordsmith some more later.

HTML version:
http://www.employees.org/~lonvick/transport/draft-ietf-syslog-transport-udp-00.html

Text Version:
http://www.employees.org/~lonvick/transport/draft-ietf-syslog-transport-udp-00.txt

PowerPoint slides for Seoul to be presented by me or proxy:
http://www.employees.org/~lonvick/transport/draft-ietf-syslog-transport-udp.ppt

Two issues have been already raised that I will address.  Source port - will specify as undefined unless hear otherwise.  Terminology definitions will be synchronized with syslog-protocol.

Thanks,
Anton.

------------------------------

Date: Wed, 18 Feb 2004 10:14:45 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: Agenda for our Meeting at the 59th IETF

Hi Folks,

I've updated our web page:
  http://www.employees.org/~lonvick/index.shtml
It now contains pointers to Glenn's and Rainer's updated documents as well
as a pointer to Anton's new document.

Towards the bottom of it is a link to our proposed Agenda
  http://www.employees.org/~lonvick/Seoul_agenda/agenda.html

Please refer back to that page over the next two weeks as I'll be placing
the presentations there.

Would anyone like to volunteer for the exalted positions of scribe and
jabber-er?

Thanks,
Chris

------------------------------

Date: Thu, 19 Feb 2004 12:53:19 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog-transport-udp ID 00 - source port requirement

Hi Anton,

thanks for the fine ID :)

I am commenting on the source port issue. In RFC 3164, port 514/UDP is
recommended as source port. This recommendation is based on seen
behaviour. However, maintaining source port 514 severely limits
implementation options for new implementations.

Let's first see how a "classical" syslogd works:

It opens a single UDP socket (at port 514) and uses this socket both the
receive AND send data. As the listener - by definition - listens to 514,
the sender also uses the same port because the socket is bound to it. I
think this was actually a side-effect of the choosen application
structure (single socket) than a deliberately introduce feature. It is
seen on (many) existing syslogd's simply because that is their program
design. There are also modular implementations which do not support this
because they technically can/will not (more on this below).

Using port 514 as the source, requires an application design where a
single socket is shared between the sending and receiving parts of the
application. In those *nix syslogd's that I have looked at, this is not
a problem, because they are more or less monolythical.

If we now think about new implementations, some may want to go for a
modular model, one where the sender is only loosly coupled with the
receiver. This e.g. is important for multi-threading and burst queueing.
A simple, elegant and efficient way is to use one socket for the
receiver and (at least one) for the sender(s).

However, you can not bind a single socket to the same port/IP address on
a systemwide basis. So if we require port 514 to be the source, we limit
an implementation to use a single-socket design. Of course, this is
doable, but it leads to more and more complex code (locking / thread
sync), slower code (locking) and probably less reliable (locking /
thread sync) code. And it brings us ... nothing. At least I don't see
any value in requiring a client to send FROM a specific port. After all,
many operators will re-configure port assignments, anyhow.

In short, I propose that we completely drop any requirement for a
specific source port.

Rainer

------------------------------

Date: Thu, 19 Feb 2004 11:33:18 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: syslog-transport-udp ID 00 - source port requirement

Rainer:

I agree with your assessment.  I also don't see any benefit in
restricting the source port. Firewalls can be configured with target
port filtering.  So, why restrict something if it has no benefit to the
standard.

Instead of omitting discussion of source port like the current draft
does, I think it is a good point to explicitly mention that source port
is undefined, so there is no ambiguity for those familiar with RFC 3164.

If somebody thinks differently, please let me know.

Thanks,
Anton.

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 6:53 AM
> To: Anton Okmianski; [email-masked]
> Subject: RE: syslog-transport-udp ID 00 - source port requirement
>
>
> Hi Anton,
>
> thanks for the fine ID :)
>
> I am commenting on the source port issue. In RFC 3164, port
> 514/UDP is recommended as source port. This recommendation is
> based on seen behaviour. However, maintaining source port 514
> severely limits implementation options for new implementations.
>
> Let's first see how a "classical" syslogd works:
>
> It opens a single UDP socket (at port 514) and uses this
> socket both the receive AND send data. As the listener - by
> definition - listens to 514, the sender also uses the same
> port because the socket is bound to it. I think this was
> actually a side-effect of the choosen application structure
> (single socket) than a deliberately introduce feature. It is
> seen on (many) existing syslogd's simply because that is
> their program design. There are also modular implementations
> which do not support this because they technically can/will
> not (more on this below).
>
> Using port 514 as the source, requires an application design
> where a single socket is shared between the sending and
> receiving parts of the application. In those *nix syslogd's
> that I have looked at, this is not a problem, because they
> are more or less monolythical.
>
> If we now think about new implementations, some may want to
> go for a modular model, one where the sender is only loosly
> coupled with the receiver. This e.g. is important for
> multi-threading and burst queueing. A simple, elegant and
> efficient way is to use one socket for the receiver and (at
> least one) for the sender(s).
>
> However, you can not bind a single socket to the same port/IP
> address on a systemwide basis. So if we require port 514 to
> be the source, we limit an implementation to use a
> single-socket design. Of course, this is doable, but it leads
> to more and more complex code (locking / thread sync), slower
> code (locking) and probably less reliable (locking / thread
> sync) code. And it brings us ... nothing. At least I don't
> see any value in requiring a client to send FROM a specific
> port. After all, many operators will re-configure port
> assignments, anyhow.
>
> In short, I propose that we completely drop any requirement
> for a specific source port.
>
> Rainer
>

------------------------------

Date: Thu, 19 Feb 2004 17:55:46 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol-03

Anton,

thanks again for a great set of comments. Be prepared for a looooong
message - you raised many good points and you deserve a long break to
read my reply ;)

Before I go into detail to your points, please let me elaborate a little
on why the draft is sometimes very specific and lenghty.

I am working in the IT security space, as probably many of you do. If I
look at past and recent vulnerabilities, there are at least two classes:
one is "simple" program bugs and the other one is interoperability
weaknesses/differences. Let's dig down on the second class: Many attacks
are successful because the underlaying spec leave (too) much room for
interpretation. A good example is malware transported via email as
vector. To avoid misunderstanding, I am NOT bashing on the mail-related
RFCs - they are well thought-out and have prooven to be big drivers
behind the Internet. However, they were created in a time where the
Internet was a much friendlier space than it is today. In these days,
everybody was interested in getting things going and if something went
wrong, then it was an unintentional bug, not an intentional attack.
Consequently, it paid to try to understand what the other peer meant and
try to correct it so that things work.

Nowadays, I need to sadly admit, a lot of effort is put into trying to
*break* things. Wrack systems. Spread malware. And the like. If you
receive a malformed packet today, chances are greater that it is
intentionally malformed than they are that it is a simple program bug.

Trying to make things work with such malformed packets can actually
cause more trouble than it is worth. A good example was the email
malware vector recently discussed on e.g. the full disclosure mailing
list. As people pointed out there, different programs have different
ways of handling improperly formed MIME message. Each implementation
tries its best in guessing what the sender might have meant and work on
that assumption. Unfortunately, the assumptions are different from
vendor to vendor and program to program (some change even between
program versions). So you do not have a consistent behaviour. Malware
authors can use this to generate malformed MIME encodings which include
executable content, that the ultimate recipient (MUA) actually
interprets as executable. But they may do it in a way that the
malware-scanning MTA interprets differently. Thus, it does not think the
message contains executable code and does not scan it (it may not even
see a file at all). The end result is that malware is delivered to the
MUA (and executed there) because of different interpretations of a
malformed MIME encoding - different implementations implemented in the
MTA and MUA.

Keep in mind that this is not a hypothetical theory, but a practical
sample that has been discussed (and to be best of my knowledge,
exploited!) in the wild.

What does me lead this to? I am of the very strong opinion, that in
today's Internet, a specification must very precisely define what it
considers correct and what incorrect. And I think it should also provide
detailled instructions on what should happen to malformed packets. So
the goal should be that messages that are malformed in whatever way
should not be processed or at least treated in a consistent way. Of
course, even with such a detailled spec, not everybody will actually
implement it in this way, but chances are much greater that most will
do. Plus, sombody emiting invalidly formatted messages will quickly be
punished by not being understood by their peers. In today's highly
connected world, this should probably put enough pressure on the
misbehaving implementation to change - at least I hope so.

Before somebody else raises hands ... yes, I know I am in quite some
contrast to Jon Postel's "Be liberal in what you accept, and
conservative in what you send.". I don't claim I am wiser than Jon was.
I am in no way. In fact, there are many people on this list a lot
smarter than me (thanks for all their comments and letting me learn).
But I have to admit that I consider Jon's wisdom as wisdom from another
time (where the Internet was a friendly place).

If I look at todays highly "brutal" Internet, is it really a good idea
to assume that everybody is friendly and you try to help them out if
they made a little mistake? Or is it probably better to think "if this
guy sends me invalid parameters, I'll better tell him to do it right or
go away (as he is probably trying to probe me for weaknesses)". I have
to admit, I think the later is the case.

While conducting some search for actual cases, I found this thread here:

http://www.netsys.com/ietf/1999/5245.html

It is stated there:

###
Almost every time I see the "be liberal..." quote, the context in
which it is said it dropped. I belive the context is MORE IMPORTANT
than the quoted text. The context is achieving interoperability.
Interoperability is more important than any other thing.
###

This is a 1999 statement, where the Internet was much more healthier
than it is today (but I began to diminish...). I think a very good
summary of the spirit behind Jon's quote is:

"Interoperability is more important than any other thing."

This is what I am questioning today. I think in today's Internet,
security is the most important thing and then comes interop ... and then
the rest. So I think it is a valid point to require stricter adherance
to standards than in the past - which in turn requires the standards to
be more precise in what is valid and what not.

I guess I am asking for a quite some (not so positive) feedback, but I
am ready to stand it...

OK, now to the issues themselfs (please read on ;))

> 1. I don't think you specified maximum message size anywhere.
>  Or did I
> miss it?

No, that was an error I made. I rush-edited the draft to meet the ID
submission deadline. Unfortunately I deleted one paragraph too much.
That will be back in in -04 and the max size will be 1280 if nobody
objects. Apologies for any confusion... (I've put this info on my web
site and into my announcment mail, but it is easy to overlook).

> 2. You talk a lot about server parsing the syslog message.
> Are we making
> an assumption that receiver must parse messages (for example 5th
> paragraph in 4.1.1)?

I think you make a point here that I missed receivers that are not
interested at all in parsing a message. However, this case should be
very, very seldom because without parsing, there is nothing else that
you can do to the message - because you have just a bunch of octets
without semantics. OK, you can use this to write a raw log, but that's
it. To assign any meaningfullness to the message, you MUST parse it - no
way around it.

I can add a section for non-parsing receivers, but that won't reduce the
size of the draft ;) I am not sure if it pays to specify this very
uncommon case.

> Generally, there seems to be a lot of stuff
> dictating behavior for receiver. Why can't we just say: this
> is valid on
> the wire, this is not and leave it up to implementation to decide what
> it does with it.

See my intro ;)

> For example, we ask receivers to "log" diagnostic
> messages.  What does "log" mean here?

I assumed that "log" is a fairly well-known, well-defined term. If we
really need to define it, I can do this in the -protocol context, but
again this adds size.

To me, "to log" means to somehow persist a notification of an important
event that happened. How this is persisted and what the exact format is
purely depends on the application and environment. I have seen other
RFCs, too, that just say "SHOULD log a diagnostic message", so I still
assume this needs no further explanation. But as I said, I can add it
(but it would not be very detailled because that is actually not a
syslog issue).

> 3. You use enterprise ID of 0 (IETF) in examples.  Is this valid?
> Should we say 0 is reserved and should never be used?  What
> does 0 mean?

Enterprise ID is still a placeholder. I would have removed it if David
had not said he has some more good comments. I still see no real demand
for it, so it still is on my "to be removed list" (or probably better to
be moved to the origin structured data element, but that's another
topic).

>
> 4. Section 4.1.3.  "Any implementation MUST support free configuration
> of the FACILITY on the sender."  I think by implementation you are
> always assuming a dedicated sender or receiver library
> product.  I don't
> see why I can't just implement sending logic in my app
> directly and not
> have a fixed facility.  I think at best, this is a SHOULD.

I agree that a SHOULD is more appropriate here, we can not actually
enforce this. It's neither a protocol nor a security issue if it is not
configurable. It can be a big backdraw for the operator, but they can
choose to dictate this by not purchasing products which don't support
free configuration. Agree, it MUST be a SHOULD ;)

But I think it is a strong SHOULD, not a weak one. Because I have seen
soooo much troubles in the real world out of the inability of some
products to provide free configuration.

>
> 5. Section 4.1.6 - Hostname.  So, we specify FQDN and if to
> present IP.
> Not sure if we had a discussion on this, but did we decide to bypass
> hostname?

Yes, because it is not meaningful in most cases. I think this is the
best pointer to previous discussion:
http://www.syslog.cc/ietf/autoarc/msg00715.html.

> I think it will be a common case where hostname is present,
> but machine does not know its domain suffix. I would
> generally prefer IP
> unless it is dynamic (DHCP).

OK, I see the point.

Probably it is best to ask the sender to provide
a) FQDN
b) static IP
c) hostname only (if on dynamic ip)
d) dynamic IP
e) oops... what if it knows nothing? Well, it should, so this is a
no-case. Right? Or is it worth another paragraph (like puting
"DumbDevice" or "127.0.0.1" into the hostname)?

Of course, this is a sequence of SHOULDs, not MUSTs.

>
> 6. Section 4.2.  Which version of Unicode do we support? UTF8 may
> support all, but I think we should limit it to some basic Unicode
> version.

I think the UTF-8 specification I am quoting is a precise description.
If it isn't I am not educated enough on Unicode to note this. I would
appreciate if someone with in-depth knowledge could comment. I agree we
should precisely define what we expect to see.

>
> 7. Section 4.3.  Why do we restrict sec-frac to 3 digits?  If somebody
> has better precision why not allow it?

It's actually limited to *6* characters - I've just gone over the paper
for a typo, but I found no reference to 3. Can you pinpoint me to it.
But: it is limited to 6 because a) it is hardly envisable that this is
not sufficiently enough and b) we had comments on list that we should
limit field sizes to reasonables values so that a parser can be build in
a more robust manner. I think the size of 6 servers both needs (plus, I
don't trust a nanosecond time source on a normal computer without an
atomic clock).

>
> 8. Section 6.2.3.  I don't think you explain the purpose for allowing
> partcount to grow.  I assume this is for streaming.  Needs to be
> explained.  I also think it is a strange scheme.  Why don't you allow
> incrementing it by one every time?

Actually, I based this on some ideas that I took from you - eventually
not correctly understood. My reasoning is as follows:

You said that we must support devices that do not know in advance how
many message part message will be needed to send a single oversize
message (for streaming, as you mention). So we should allow a client to
increase the number of message part messages it needs to transmit the
original message. This means the partcount must grow (but it can grow
incrementally).

On the other hand, if my device knows in advance how many message part
messages are needed, it is a plus to pass this knowledge to the
receiver. The receiver can eventually use this knowledge for buffer
allocation and other internal processing (whatever this is). There is
also a plus that loss of the last message(s) in a multi-part message can
be detected in a scheme where the number of messages is known in
advance.

This can't be done if the partcount is just being incremented. If it
would just be incremented, it would be a redundant counter which we
could remove. In fact, I see the streaming case as an acceptable
degradation of the scheme (acceptable because its usefulness outweights
its backdraws). It definitley looses reliability. So we need to be able
to support a scheme were from the very first message part message the
partcount is fully correct.

To support both schemes, I could have specified that the partcount must
either bei incrementing OR never change. I decided to let it grow, but
not demand it to grow incrementally. This leaves a streaming
implementation that has learned something more about the expected number
of fragments to pass this information as soon as it knows it. There may
be benefits a recipient may gain from such advance knowledge. The only
thing I can not allow is to shrink the number of messages, as this looks
like something went wrong (a device witout a clue should not increase
the partcount to a value higher than it knows it will send - if it is in
doubt, it can still resort to just incrementing). Allowing it to grow -
but not necessarily increment - still provides us the ability to detect
missing end message(s) when the sender was aware of the actual number of
messages and the receiver could receive at least one message with this
information before the message loss occured.

In short: allowing growth, but not requiring incrementing provides added
reliablilty and eventually other (secondary) benefits.

I also think this scheme is not uncommon, I think I have seen similar
schemes in other protocols (but I have to admit I have no pointers at
hand).

>
> 9. Section 7.2.  Can we use "yes" or "no" instead of "0" and "1"?

I, too, thought about this. In respect to the message size limitation, I
decided to go for the shorter form. "0" and "1" should be fairly clear
as boolean indicator. But I will gladly change this if that is the
concensus on this list.

>
> 10. Section 8.1. If relay can't add structured data elements, it can't
> record source IP of the message.  I think we should not lose such
> information. Also, need to allow for recording of time or original
> reception.

That's a tough issue. It will cause us the loss of digital signatures?
Which goal has the higher priority? Or should we work around this issue?
Of course it's doable, but only on the expense of growing the spec. We
would "simply" need to define a way that a relay can add a container
structured data element, which in turn could contain other structured
data elements - and that are clearly flagged as being not part of the
original message so that a signature verifier could remove that part.
This also sounds like a call, again, for XML ;)

It's doable, but it will add considerable complexity.

On the other hand, we can allow a relay to break signatures. I am not
sure if that is a good mode.

Or we do not allow it to modify the message (as currently specified),
but then we are not able to save the information that you request - and
I agree this information is valuable...

>
> 11. Section 8.3. You allow relay to break message into multiple parts.
> What happens with a message that is already multi-part?  How do you
> distinguish first level of fragmentation from second?

Actually, I think that is easier as it first looks. I specified that a
message part message is a full syslog message in its own rights. As
such, you can apply all rules applying to any syslog message to a
message part message, too (because it is a regular message once it has
been formed). At least this is the sprit that I had on my mind.

So, when a (message part) message is disassembled (being broken in
parts), the multi-part message headers must also be disassembled. Then
an additional multi-part-message handler is added. We end up with a
message that, after reassembly, becomes the orginal message part
message, thus in itself a message that must be reassmbled to become the
original message.

In eventually more familiar terms: let's use "fragmentation" for a
moment. If a message fragement becomes further fragmented, an additional
fragmentation header is added and the fragments of this message will
then travel as a fragemented part of a fragmented message. Double
fragementation. Obviously, there is quite some overhead.

I consider relays splitting message into multi-part messages as a last
resort when there is no other way to handle the situation. It is
definitely NOT desirable.

> 12. The ID is now 45 pages long and growing with every revision.  I
> think it would help if we shortened it whenever possible.
> After all it
> is just a syslog protocol.  This is protocol used for troubleshooting.
> It can't be itself overly complicated or give such impression.

Well ... actually it get's larger with each of your well-thought out
comments ;)

Honestly, I like to keep it short. But just look at this mail. How often
do you rightly ask if we can specify something more precisely? So how
can we shrink it and also make it more precise? Well, I assume we can
save some pages if a good native English editor goes over it. In
general, however, I think it is expanding. Of course, we can move all
the specifics and clarifications out into a separate web page, but what
exactly is the value of this? And who guarantees that in implementor
will visit these pages?

Of course, the growth of the document is also related to my try to keep
things right in bounds (see my intro). But again, if you look at the WG
mailing list archive, you will see lots of comments that "this and that"
is unclear and needs to be specified. If we do, the spec obviously grows
;)

Besides its growing size, I think it is still moderately easy to
implement. There are few things that are actually required. Out of the
content, there are hints to implementors, which I assume make it easier
to implement syslog - and make implementation more robust, as I try to
fingerpoint those issues that are known to cause security problems in
the real world.

Also, in my experience, the more is in-depth specified, the easier it is
to implement the spec, because the developer does not need to think that
hard ... He or she will find most things in need inside the spec.

So for now, I think it is not a bad thing that it is growing ... but I
may be wrong ;)

Comments on everything higly appreciated...
Rainer

------------------------------

Date: Thu, 19 Feb 2004 09:36:59 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: RE: syslog-transport-udp ID 00 - source port requirement

Hi Anton,

On Thu, 19 Feb 2004, Anton Okmianski wrote:

> Rainer:
>
> I agree with your assessment.  I also don't see any benefit in
> restricting the source port. Firewalls can be configured with target
> port filtering.  So, why restrict something if it has no benefit to the
> standard.
>
> Instead of omitting discussion of source port like the current draft
> does, I think it is a good point to explicitly mention that source port
> is undefined, so there is no ambiguity for those familiar with RFC 3164.

It would be best to have it in there for completeness.  The goal should be
that implementers will be able to read syslog-transport-udp and
syslog-protocol without having to refer to any other documents about
syslog (like 3164) to produce an interoperable implementation.

Thanks,
Chris

------------------------------

Date: Fri, 20 Feb 2004 15:30:51 -0800
From: Devin Kowatch <[email-masked]>
Subject: Re: -protocol-03

I should make the disclaimer that I haven't read the latest draft, sorry
Rainer, as time has not been available.

On Thu, Feb 19, 2004 at 05:55:46PM +0100, Rainer Gerhards wrote:
[ snip ]
>
> > 2. You talk a lot about server parsing the syslog message.
> > Are we making
> > an assumption that receiver must parse messages (for example 5th
> > paragraph in 4.1.1)?
>
> I think you make a point here that I missed receivers that are not
> interested at all in parsing a message. However, this case should be
> very, very seldom because without parsing, there is nothing else that
> you can do to the message - because you have just a bunch of octets
> without semantics. OK, you can use this to write a raw log, but that's
> it. To assign any meaningfullness to the message, you MUST parse it - no
> way around it.

My experience is on the unix side of things, so the following may not
be true, or as true, for other platforms.

I'm wondering what you mean by "meaningfullness".  Having worked on the
odd syslog analyser or two, syslog messages are nearly impossible to
extract meaning from.  To clarify, because the actual meaning of a
syslog message (e.g. su to root failed) is in free form text (and there
is nothing that we can do about that) extracting the meaning involves
either matching the text to known patterns or natural language
processing.  Everything other than the message is really meta-data (the
time it was logged, where it come from, path information, etc).  The
syslog server really needs to know very little of the meta-data to do
it's job.

Syslog servers have existed for years with minimal parsing of the
message.  My own syslog server does parse the message, but I think (in
retrospect) that may have been a mistake.  The only useful place where
parsing must occure is when you are translating from one format to
another (e.g. classic syslog to SYSLOG/COOKED).

BTW, Reading section 4.1.1, I think you may be too specific about what a
server MUST/SHOULD (NOT) do with the version string.  I think it might
be enough to state that this document describes version 2, and an
unknown version should cause the reciever to log a message.  The last 3
paragraphs seem unecessary.  Also, I think they specify too much about
how the protocol (and application that uses it) should be written.
>
> I can add a section for non-parsing receivers, but that won't reduce the
> size of the draft ;) I am not sure if it pays to specify this very
> uncommon case.
>
> > Generally, there seems to be a lot of stuff
> > dictating behavior for receiver. Why can't we just say: this
> > is valid on
> > the wire, this is not and leave it up to implementation to decide what
> > it does with it.
>
> See my intro ;)
>
>
[ snip ]
> >
> > 4. Section 4.1.3.  "Any implementation MUST support free configuration
> > of the FACILITY on the sender."  I think by implementation you are
> > always assuming a dedicated sender or receiver library
> > product.  I don't
> > see why I can't just implement sending logic in my app
> > directly and not
> > have a fixed facility.  I think at best, this is a SHOULD.
>
> I agree that a SHOULD is more appropriate here, we can not actually
> enforce this. It's neither a protocol nor a security issue if it is not
> configurable. It can be a big backdraw for the operator, but they can
> choose to dictate this by not purchasing products which don't support
> free configuration. Agree, it MUST be a SHOULD ;)

Also note that on the unix side of the house, facilities are defined by
in a header file.  Furthermore, the actual library calls which log
messages will be sending the classic format, probably for years to come,
which combines the facility and priority.

>
> But I think it is a strong SHOULD, not a weak one. Because I have seen
> soooo much troubles in the real world out of the inability of some
> products to provide free configuration.
>
> >
> > 5. Section 4.1.6 - Hostname.  So, we specify FQDN and if to
> > present IP.
> > Not sure if we had a discussion on this, but did we decide to bypass
> > hostname?
>
> Yes, because it is not meaningful in most cases. I think this is the
> best pointer to previous discussion:
> http://www.syslog.cc/ietf/autoarc/msg00715.html.

Yes and no.  Syslog is usually only used within an organization.  Which
means that in many cases the hostname is enough information to find the
actual hardware that sent the message.  For larger organizations who use
sub-domains and other more complicated setups, the FQDN is more
important.

>
> > I think it will be a common case where hostname is present,
> > but machine does not know its domain suffix. I would
> > generally prefer IP
> > unless it is dynamic (DHCP).
>
> OK, I see the point.

I can make an argument for cases where the hostname is more useful than
even an static IP.  For example, think of a multihomed host.  Or think
of a web farm which has many (10+) virtual interfaces for apache
daemons.  However, leaving this as a SHOULD is good because then
implementations can simply make it configurable.

>
> Probably it is best to ask the sender to provide
> a) FQDN
> b) static IP
> c) hostname only (if on dynamic ip)
> d) dynamic IP
> e) oops... what if it knows nothing? Well, it should, so this is a
> no-case. Right? Or is it worth another paragraph (like puting
> "DumbDevice" or "127.0.0.1" into the hostname)?
>
> Of course, this is a sequence of SHOULDs, not MUSTs.

No, e is not needed.  I think that it's reasonable to assume that a) any
host sending syslog will have an IP address and b) all platforms allow
an application to get that IP address.

[ snip ]
>
> >
> > 8. Section 6.2.3.  I don't think you explain the purpose for allowing
> > partcount to grow.  I assume this is for streaming.  Needs to be
> > explained.  I also think it is a strange scheme.  Why don't you allow
> > incrementing it by one every time?
[ snip ]

I'm just going to take this opportunity to throw out a few general
comments I have about the fragmentation issue.

Maybe it's just me, but it seems like the protocol is getting more
complex than needed.  I understand, and agree with, the need to send
multi-part syslog messages in the event that the message exceeds the
maximum message size.  However, I don't think that there is a lot of
advantage to some of the directions that this is going in.

I'm not trying to pick at a specific issue here, but more to urge that
everyone take a step back and see how they can simplify the protocol.
Remember the saying about when software is done: It's not done until
there are no more things that you can _remove_.  I also don't mean this
to be diminishing the hard work that everyone has put into the syslog
protocol so far.  Often when I design software I go through the same
process, with the first draft overly complex and simplifing it later.
Ultimatly, the protocol will be stronger for process (more cases
considered).

On the fragmentation issue specifically, do we really need to fragment
packets when they would be larger than the MTU of the transport
protocol?  For -protocol, which I thought was transport independent, it
makes no sense.  For the UDP transport, why not just frame the message
and let the IP layer take care of MTU fragmentation.

The other aspect to consider, UDP is not the only transport (please
repeat that after me).  Not only is UDP not the only transport, but it
is not even a good transport (too lossy, yes even with low
messages/sec.).   Oddly enough it turns out to be slower than TCP
(according to someone else's tests) becaue the lossage causes the
messages/sec to level off well before the bandwidth is consumed.

An example would be syslog over BEEP (similar to SYSLOG/RAW).  There is no
good reason to restrict the maximum message size, there is no need to
frame the message, and there is no need to handle fragments in the
message.  All of that is handled at the BEEP layer, as is authentication
of sender/reciever, and more.  It might be a useful exercise for someone
to revisit SYSLOG/RAW and adapt -protocol to run over BEEP.  It may
provide some insights as to how many aspects of -protocol are designed
to get around UDPs limitations.

These are intended to be examples, I may have more specific comments on
this once I read the drafts (this weekend hopefully).  But in short, I
urge everyone to think about how to _simply_ the protocol.  A overly
complex protocol gets less takers on implementation.

Then again, maybe I'm wrong and all the features do need to be present.

> >
> > 9. Section 7.2.  Can we use "yes" or "no" instead of "0" and "1"?
>
> I, too, thought about this. In respect to the message size limitation, I
> decided to go for the shorter form. "0" and "1" should be fairly clear
> as boolean indicator. But I will gladly change this if that is the
> concensus on this list.

Might I suggest 'T' or 'F' (true or false) or 'Y' or 'N'?  just a
thought.
>
> >
> > 10. Section 8.1. If relay can't add structured data elements, it can't
> > record source IP of the message.  I think we should not lose such
> > information. Also, need to allow for recording of time or original
> > reception.
>
> That's a tough issue. It will cause us the loss of digital signatures?
> Which goal has the higher priority? Or should we work around this issue?
> Of course it's doable, but only on the expense of growing the spec. We
> would "simply" need to define a way that a relay can add a container
> structured data element, which in turn could contain other structured
> data elements - and that are clearly flagged as being not part of the
> original message so that a signature verifier could remove that part.
> This also sounds like a call, again, for XML ;)
>
> It's doable, but it will add considerable complexity.
>
> On the other hand, we can allow a relay to break signatures. I am not
> sure if that is a good mode.
>
> Or we do not allow it to modify the message (as currently specified),
> but then we are not able to save the information that you request - and
> I agree this information is valuable...

This should be easy, but you need to encapsulate.  The realy MUST NOT
alter the message it recived in any way (for signatures).  But, to track
the path of the message you could encapsulate the message recieved by
the relay (M) in a new message that contains PRIORITY RELAY-ADDED-HEADERS M.

Note that the priority is duplicated because it is most often used to
route the message.

Simple enough, no?  Now the real question is: would it work? :)

>
> >
> > 11. Section 8.3. You allow relay to break message into multiple parts.
> > What happens with a message that is already multi-part?  How do you
> > distinguish first level of fragmentation from second?
>
> Actually, I think that is easier as it first looks. I specified that a
> message part message is a full syslog message in its own rights. As
> such, you can apply all rules applying to any syslog message to a
> message part message, too (because it is a regular message once it has
> been formed). At least this is the sprit that I had on my mind.
>
> So, when a (message part) message is disassembled (being broken in
> parts), the multi-part message headers must also be disassembled. Then
> an additional multi-part-message handler is added. We end up with a
> message that, after reassembly, becomes the orginal message part
> message, thus in itself a message that must be reassmbled to become the
> original message.
>
> In eventually more familiar terms: let's use "fragmentation" for a
> moment. If a message fragement becomes further fragmented, an additional
> fragmentation header is added and the fragments of this message will
> then travel as a fragemented part of a fragmented message. Double
> fragementation. Obviously, there is quite some overhead.
>
> I consider relays splitting message into multi-part messages as a last
> resort when there is no other way to handle the situation. It is
> definitely NOT desirable.

I'm thinking I would really like to see only one level of syslog message
level fragmentation allowed.  If the transport needs to fragment, let
it.  If the transport can't fragment, let the transport mapping define a
mechanism for fragmentating messages that makes sense.  Basically this
will be a PIA to implement correctly and quickly (run time not
implementation time).   I haven't really the multi-part message spec
very closely.  Will we need to escape structured data elements in a
twice fragmented message? This may be necessary because the reassembly
code might not know which meta-data about message parts belongs to which
level of fragmentation?

>
> > 12. The ID is now 45 pages long and growing with every revision.  I
> > think it would help if we shortened it whenever possible.
> > After all it
> > is just a syslog protocol.  This is protocol used for troubleshooting.
> > It can't be itself overly complicated or give such impression.
>
> Well ... actually it get's larger with each of your well-thought out
> comments ;)
>
> Honestly, I like to keep it short. But just look at this mail. How often
> do you rightly ask if we can specify something more precisely? So how
> can we shrink it and also make it more precise? Well, I assume we can
> save some pages if a good native English editor goes over it. In
> general, however, I think it is expanding. Of course, we can move all
> the specifics and clarifications out into a separate web page, but what
> exactly is the value of this? And who guarantees that in implementor
> will visit these pages?
>
> Of course, the growth of the document is also related to my try to keep
> things right in bounds (see my intro). But again, if you look at the WG
> mailing list archive, you will see lots of comments that "this and that"
> is unclear and needs to be specified. If we do, the spec obviously grows
> ;)
[ snip ]

More precice specification is great, overly percise specification is
not.  Also, some verbiage may be better placed in other documents.  So
implementation advice could go on a web page.  Section 6.3 may be
better in the syslog-sign RFC, etc ...

my $0.01

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Tue, 24 Feb 2004 12:01:24 +0100
From: Rainer Gerhards <[email-masked]>
Subject: -protocol issue 15: describe relay operations?

Hi WG,

based on the recent comments I received on -protocol becoming too large
and in-depth, I wonder if it still makes sense to include relay
operations in -protocol? I think this could easily be split into a
separate document. If this is not done, I assume that it will take up
considerable space.

If it should be in -protocol depends on what we actually charter
- -protocol for. As of my current understanding, -protocol is chartered to
not just describe the format of the message but also outline how the
protocol itself works. If I am right with this, relay operations MAY be
described in -protocol. But I could also envision that -protocol just
says "there are relays" and leaves the details for a different document.

Leaving it for a different document would definitely help to finish
- -protocol soon(er). It would also streamline it, as probably not
everyone implementing syslog will necessarily implement relay mode (I
assume most will not be interested in this).

So my suggestion would be to remove in-depth description of relay mode
from -protocol and create a new document once -protocol is FINISHED (and
not before). I would volunteer (actually like;)) to write this doc,
because I already have a lot of content, which I just would not merge
into -protocol for now.

Rainer

------------------------------

Date: Tue, 24 Feb 2004 16:16:08 -0500
From: Anton Okmianski <[email-masked]>
Subject: RE: -protocol issue 15: describe relay operations?

Rainer:

I think it is may not a bad idea.  The only issue is that we will have
to produce all three IDs (-protocol, -transport and -relay) all at the
same time, right?  I think it would be a good idea or it would not
provide a complete replacement for RFC 3164.

However, if all of this is much more work for you or for the group, I
don't know if it is worth it.  It would make more sense if we indeed end
up having to add a lot more stuff for relay operations like ability to
envelop the message so it can include original IP, time of reception,
etc.

More so than relay operations, I think my issue with size was related to
various implementation guidance that may not be needed or could be
counterproductive in some cases. I know it is a fine line.  I have
pointed a few examples.

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Tuesday, February 24, 2004 6:01 AM
> To: [email-masked]
> Subject: -protocol issue 15: describe relay operations?
>
>
> Hi WG,
>
> based on the recent comments I received on -protocol becoming
> too large and in-depth, I wonder if it still makes sense to
> include relay operations in -protocol? I think this could
> easily be split into a separate document. If this is not
> done, I assume that it will take up considerable space.
>
> If it should be in -protocol depends on what we actually
> charter -protocol for. As of my current understanding,
> -protocol is chartered to not just describe the format of the
> message but also outline how the protocol itself works. If I
> am right with this, relay operations MAY be described in
> -protocol. But I could also envision that -protocol just says
> "there are relays" and leaves the details for a different document.
>
> Leaving it for a different document would definitely help to
> finish -protocol soon(er). It would also streamline it, as
> probably not everyone implementing syslog will necessarily
> implement relay mode (I assume most will not be interested in this).
>
> So my suggestion would be to remove in-depth description of
> relay mode from -protocol and create a new document once
> -protocol is FINISHED (and not before). I would volunteer
> (actually like;)) to write this doc, because I already have a
> lot of content, which I just would not merge into -protocol for now.
>
> Rainer
>
>

------------------------------

Date: Wed, 25 Feb 2004 10:41:07 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: -protocol issue 15: describe relay operations?

Anton,

> I think it is may not a bad idea.  The only issue is that we will have
> to produce all three IDs (-protocol, -transport and -relay) all at the
> same time, right?  I think it would be a good idea or it would not
> provide a complete replacement for RFC 3164.

I actually think we do not really need to publish a hyptothetical -relay
together with -protocol and -transport-udp.

Obviously, this will leave relay operations only vaguely described for
some time, but honestly I think it is better we have the base -protocol
part straightend out. Implementing -protocol alone will take some time
and I do not expect implementors to initially fully support relay
operations.

Let's look at a real-world scenario: RFC 3195 describes non-relay and
relay operations. To the best of my knowledge, there are currently two
implementation of RFC 3195: one is SDSC syslog, the other one is my own
liblogging (now found in several products). Neither of these two
supports relay operations. If it comes to relaying, the act as a
receiver and as a sender - but this is different from actual relay
operations. Both implementations will go for relaying, but AFIK only at
a later stage. liblogging will definitely first include -protocol (once
it is more mature and stable) and then look at the relay part.

So does it relly hurt if -relay would be e.g. 6 month delayed? I think
not. And one more thing to consider: if we really expect that -relay
will take quite some time, we must also assume that -relay described in
- -protocol will take the same time, too (after all, it is the same
content). So let's just pick the 6 month as a sample (wild guess). My
view on this issue is: if we take relay operations (except for some
rough sentences) out of -protocol, we will be able to publish -protocol
6 month in advance and will have -relay ready at the same time when
otherwise -protocol would be finished. So what do we have to loose?

From the protocol point of view, I think -relay is a very specific
issue, so I don't see any good reason that it MUST be described in
- -protocol itself.

>
> However, if all of this is much more work for you or for the group, I
> don't know if it is worth it.  It would make more sense if we
> indeed end
> up having to add a lot more stuff for relay operations like ability to
> envelop the message so it can include original IP, time of reception,
> etc.

If we need that stuff, we need it anyhow. Let's say -relay would be 20
pages (stripped of the boilerplate and such). These 20 pages would
either be a document in its own or 20 *additional* pages in -protocol.

>
> More so than relay operations, I think my issue with size was
> related to
> various implementation guidance that may not be needed or could be
> counterproductive in some cases. I know it is a fine line.  I have
> pointed a few examples.

Sorry for not replying on that - I am currently consolidating the
thoughts and also gathering additional feedback. Actually, I am not yet
fully prepared to answer on this topic, because I have not fully made my
mind up. So it isn't ignorance, but careful consideration what makes me
NOT reply now (also applies to Devin's post). Sorry for not telling this
straightly. I hope I can reply - at least with an interim post - before
Seoul. At least I'll try. Any more comments are obviously appreciated.

So far, I am tracking this as issue 13:
http://www.syslog.cc/ietf/protocol/issue13.html

Rainer

------------------------------