Subject: FW: syslog mib review
From: "Harrington, David" <[email-masked]>
Date: Wed, 1 Jan 2003 18:25:12 -0500

Hi,

I have some comments based on a fairly quick review of the mib in -01-. I will do a more thorough review when Glenn publishes a new revision.

The bulk of section 2 should be replaced with the new mib boilerplate, which can be copied from RFC3418. The paragraphs on RowStatus and RFC2119 should probably be made separate subsections under section 2.

Section 3 looks like it could use a complete rewrite. I'll consider providing text if Glenn hasn't already rewritten this. Much of this seems to reflect implementation-specific considerations.

I recommend chaging the name from DRAFT-IETF-SYSLOG-DEVICE-MIB to simply SYSLOG-DEVICE-MIB. If this mib is oriented toward the client, it might be better named as the SYSLOG-CLIENT-MIB and have another for server configuration.

The object-types typically start with snmpSyslog or etsysSyslog. Both the "snmp" and "etsys" prefixes can be removed, and object descriptors can start with "syslog".

Bruno Pape should be removed from the CONTACT-INFO, although I think he should be acknowledged in an Acknowledgement or Authors section (the chairs can decide how they want to handle that issue).

IANA should provide a number to replace the 999999 in the MODULE-IDENTITY. The chairs can handle that. I'm not sure that this should be directly under snmpModules.

The Textual Conventions use syslog enumerations. REFERENCE clauses should be included to document where the values are officially defined.

The message counters don't indicate whether they are persistent or not, and do not define "successfully delivered", which could lead to varying interpretations and subsequent problems with interoperability.

LastMessageTime - I'm not sure this will be useful in practice. What is the anticipated rate of queueing versus the anticipated rate of polling?

I'm not sure the DeviceControl BITS object is justified if there is only one value.

CollectorMaxEntries has a range (1..8). This looks to be an implementation-specific decision. The same for NextAvailableIndex. I don't like the last paragraph of the description for NextAvailableIndex, or understand why it is needed. Row creation should follow the normal constraints of SNMP SETs for row creation.

CollectorEntry: There may be better ways to specify the non-volatile requirements, such as the StorageType Textual Convention. I would change "across entity resets" to "across re-initializations of the network management portion of the system".

CollectorIndex should not be constrained to the (1..8) range.

If syslog is ever used over transports that are not IP-based, then using transport address conventions as discussed in RFC3419 might be appropriate.

CollectorUDPPort might be better as simply CollectorPort to allow TCP ports to be specified.

I'm not sure I understand why the MessagesIgnored counter is important to maintain.

I would eliminate the DefaultUdpPort, DefaultFacility, and DefaultSeverity options as adding unnecessary complexity, unless the WG feels this is justified.

The security boilerplate is under review by the O&M Area. It should be updated when the new boilerplate becomes available.

References should be updated. SNMPv3 has been published in new RFCs, and th eboilerplate for mibs has been simplified, so many of the references can be eliminated from this document, and some need to be modified.

dbh
- ---
David Harrington
[email-masked]
co-chair, IETF SNMPv3 WG

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

Date: Thu, 2 Jan 2003 05:00:48 -0800 (PST)
From: Lonvick <[email-masked]>
Subject: Re: Remarks on syslog-sign (draft 07)

- ---------- Forwarded message ----------
Date: Thu, 02 Jan 2003 06:43:22 +0100
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Remarks on syslog-sign (draft 07)

{Resend, because oif wrong To:]

Hi All,

Been a bit busy lately, but catching up soon, I hoop.
But a quick responds on a comment on a comment ..

 >>>** The TAG is defined to be ending ('MUST')with a _colon_.
 >>> This wrong, as rfc3164 defines it can end with a _space_
 >>>Adv   Rewrite: it terminates with any not alfanum char.

 > We discussed (a long time ago) that the TAG should be included in the
 > HEADER rather than in the MSG for people writing code.

Very true, It was I who made the suggestion ...

 > This should mean that the TAG should be able to contain things like:
 >    syslog[1234]:
 > Since the next character may, or may not be a space, [...]

 > I'll suggest that the colon stay.

The point is, syslog-sign messages should be syslog-rfc3164 "parsable".
And, syslog-sign-deamons should handle "old" syslog messages.
In other words: when a UDP message is arriving over the syslog-port, the
daemon should be able to handle (so parse) it. WITHOUT knowing it is
syslog-rfc3164 or -sign.
Based on my implementation, we need the space "definition" in the
syslog-sign rfc, to make a 100% correct implementation.

I have to look up the work for details, I hope you trust "my word" :-)

NB traditional syslog can be without the colon!

 > That does bring up a point, however.  In "traditional" syslog messages,
 > there is nothing between the ":" and the message itself in many cases.
 > Should there be a space between the ":" and the Signature Block, and the
 > Certifiate Block in the syslog-sign messages?  If so then a Signature
 > Block would look like:
 >    syslog[1234]: @#sigSIG 0111 ...
 > and the Certificate Block would be:
 >    syslog[1234]: @#sigCER 0111 ...

Based on early posting(s): I suggest to allow one or more spaces between
ANY 2 syslog-sign-fields. (for reading). And send 1 space between any 2
fields. Personally, I would like to have 2 spaces at the frond. It make
(manual) parsing nice. But that only a matter of style.

- --ALbert Mietus
Sent prive mail to:      [email-masked]
Sent business  mail to: [email-masked]

- -- 
- --ALbert Mietus
Sent prive mail to:      [email-masked]
Sent business  mail to: [email-masked]

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

Date: Thu, 2 Jan 2003 11:13:44 -0500
From: "Pape, Bruno" <[email-masked]>
Subject: RE: syslog mib review

With some trepidation I will offer some limited explanation of the
history
of the MIB, hopefully I will not try to constrain or influence the
future
direction as I have abdicated my editorial duties.

The MIB, as it was in draft -01-, was an attempt to provide SNMP
management
support for syslog devices.  Since file and GUI based management of
syslog
relays and collectors is already well established, possibly more
complex,
and not something that needed to be performed on 10's, 100's, 1000's,
etc.
of entities at a time no effort was expended in that area.

The text in section 3 was an attempt to describe what were considered
the
two major classes of implementations.  The first class is what is
offered
in vxWorks, the OS handles the distribution of the syslog messages to
the
various configured servers, all servers are fed from the same queue, and
are sent the same messages.  The second class of implementations would
allow the messages to be filtered on a per application and per priority
basis, per server.  Some of the text discusses this in the context of
managing network equipment, I could see the need to rewrite that in more
general terms, or the rest of it in more easily understandable terms.

The DefaultUdpPort, DefaultFacility, and DefaultSeverity objects were an
attempt to provide unambiguous or straight forward support for both
classes
of implementations described in section 3.  Initially the MIB was
written
for the second class of implementations and then extended to support the
vxWorks implementation.  There might be simpler ways to achieve this.

The indexes for the table could be unconstrained, if they are there
might
be value in having objects that describe the maximum number of entries
that
are supported in the tables, if it is considered best, or reasonable,
current practice.

LastMessageTime and MessagesIgnored where for diagnostic purposes, one
could poll 1000's of devices and see when the most recent message was
sent,
might be reassuring if ones collector had not seen any messages for some
time period and one wanted verification that none had been sent.
MessagesIgnored would let one know that applications had been generating
messages but that they had been filtered.

Hopefully what I have written does not impede anyone from finding a
cleaner, simpler, more all encompassing management interface for syslog.

With friendly Greetings,

Bruno

- -----Original Message-----
From: Harrington, David
Sent: Wednesday, January 01, 2003 6:25 PM
To: [email-masked]
Subject: FW: syslog mib review

Hi,

I have some comments based on a fairly quick review of the mib in -01-.
I will do a more thorough review when Glenn publishes a new revision.

The bulk of section 2 should be replaced with the new mib boilerplate,
which can be copied from RFC3418. The paragraphs on RowStatus and
RFC2119 should probably be made separate subsections under section 2.

Section 3 looks like it could use a complete rewrite. I'll consider
providing text if Glenn hasn't already rewritten this. Much of this
seems to reflect implementation-specific considerations.

I recommend chaging the name from DRAFT-IETF-SYSLOG-DEVICE-MIB to simply
SYSLOG-DEVICE-MIB. If this mib is oriented toward the client, it might
be better named as the SYSLOG-CLIENT-MIB and have another for server
configuration.

The object-types typically start with snmpSyslog or etsysSyslog. Both
the "snmp" and "etsys" prefixes can be removed, and object descriptors
can start with "syslog".

Bruno Pape should be removed from the CONTACT-INFO, although I think he
should be acknowledged in an Acknowledgement or Authors section (the
chairs can decide how they want to handle that issue).

IANA should provide a number to replace the 999999 in the
MODULE-IDENTITY. The chairs can handle that. I'm not sure that this
should be directly under snmpModules.

The Textual Conventions use syslog enumerations. REFERENCE clauses
should be included to document where the values are officially defined.

The message counters don't indicate whether they are persistent or not,
and do not define "successfully delivered", which could lead to varying
interpretations and subsequent problems with interoperability.

LastMessageTime - I'm not sure this will be useful in practice. What is
the anticipated rate of queueing versus the anticipated rate of polling?

I'm not sure the DeviceControl BITS object is justified if there is only
one value.

CollectorMaxEntries has a range (1..8). This looks to be an
implementation-specific decision. The same for NextAvailableIndex. I
don't like the last paragraph of the description for NextAvailableIndex,
or understand why it is needed. Row creation should follow the normal
constraints of SNMP SETs for row creation.

CollectorEntry: There may be better ways to specify the non-volatile
requirements, such as the StorageType Textual Convention. I would change
"across entity resets" to "across re-initializations of the network
management portion of the system".

CollectorIndex should not be constrained to the (1..8) range.

If syslog is ever used over transports that are not IP-based, then using
transport address conventions as discussed in RFC3419 might be
appropriate.

CollectorUDPPort might be better as simply CollectorPort to allow TCP
ports to be specified.

I'm not sure I understand why the MessagesIgnored counter is important
to maintain.

I would eliminate the DefaultUdpPort, DefaultFacility, and
DefaultSeverity options as adding unnecessary complexity, unless the WG
feels this is justified.

The security boilerplate is under review by the O&M Area. It should be
updated when the new boilerplate becomes available.

References should be updated. SNMPv3 has been published in new RFCs, and
th eboilerplate for mibs has been simplified, so many of the references
can be eliminated from this document, and some need to be modified.

dbh
- ---
David Harrington
[email-masked]
co-chair, IETF SNMPv3 WG

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

Date: Mon, 06 Jan 2003 10:35:14 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: syslog-mib

Hi,
   I have been working on the draft-ietf-syslog-device-mib-01.txt.
And I have a draft design ready. The document will be posted to
internet-draft archives shortly. Meanwhile it is avaliable from
http://www.cysol.co.jp/contrib/materials/draft-ietf-syslog-device-mib-02.txt

   The document has grown in size  to 43 pages and will probably be
making tedious reading. The major part of it is the MIB definitions.
But before we go into the definitions and/or editorial nits, I would
look for consensus on the MIB design goals and the structure itself.
   In the design I have kept the BSD Syslog as the target [ The MIB
should map onto the syslog.conf and variuos syslogd run time parameters
and, viceversa] Whereever possible I have tried to introduce more
flexibility. [Transports other than UDP can be be used ]

   To quote from the draft [Section 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.
               - etc.
      o  Rules for selecting messages and applying the corresponding
         specified actions for each syslog process

   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 syslog control group which handles the definition of the rules
      for message selection and action(s) that will be carried out on
      the selected message. The tables in this group represent the rules
      that would generally be present in the syslog.conf file of
      traditional syslogd process.
      The control group consists of
       - a syslogCtlSelectionTable which defines the message selection
         rule.
       - several action tables viz.
          + syslogCtlLogActionTable defining the logging actions
          + syslogCtlUserActionTable defining the users on whose console
            the message will need to be displayed.
          + syslogCtlForwardActionTable defining destinations to which
            a message will be forwarded
   o  The conformance group that defines the compliance statements.

I would like to have comments and opinions on the above.

Thanks

Glenn

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

Date: Mon, 06 Jan 2003 20:18:05 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: FW: syslog mib review

Dave,

Thanks for the comments. Most of them have been incorporated in the -02 draft
or are not-applicable as the draft has changed. Some remain as TBDs. Hope to
get those in the next version.

My reactions are inline.

Harrington, David wrote:
> Hi,
>
> I have some comments based on a fairly quick review of the mib in -01-.
> I will do a more thorough review when Glenn publishes a new revision.
>
> The bulk of section 2 should be replaced with the new mib boilerplate,
> which can be copied from RFC3418.
This is done.

> The paragraphs on RowStatus and RFC2119
> should probably be made separate subsections under section 2
This probably does not apply.

>
> Section 3 looks like it could use a complete rewrite.
>I'll consider providing text if Glenn hasn't already rewritten this.
Yes it has been completely rewritten. Please feel free to add or
suggest modifications.
Much of this seems to reflect implementation-specific considerations.
>
> I recommend chaging the name from DRAFT-IETF-SYSLOG-DEVICE-MIB to
> simply SYSLOG-DEVICE-MIB. If this mib is oriented toward the client, it
> might be better named as the SYSLOG-CLIENT-MIB and have another for server
> configuration.

I have left the draft name the same but as far as the contents are
concerned it is a syslog-MIB.
>
> The object-types typically start with snmpSyslog or etsysSyslog.
>  Both the "snmp" and "etsys" prefixes can be removed, and object
>  descriptors can start with "syslog".
This is already done.

>
> Bruno Pape should be removed from the CONTACT-INFO, although I
> think he should be acknowledged in an Acknowledgement or Authors
> section (the chairs can decide how they want to handle that issue).
This is not yet done. I was under the impression that Bruno will be
on the team. Let me know if I am wrong.
>
> IANA should provide a number to replace the 999999 in the MODULE-IDENTITY.
> The chairs can handle that. I'm not sure that this should be directly under
> snmpModules.
TBD.

>
> The Textual Conventions use syslog enumerations. REFERENCE clauses should be
> included to document where the values are officially defined.
This is yet to be done.

>
> The message counters don't indicate whether they are persistent or not, and
> do not define "successfully delivered", which could lead to varying interpretations
> and subsequent problems with interoperability.
TBD
>
> LastMessageTime - I'm not sure this will be useful in practice. What is the
> anticipated rate of queueing versus the anticipated rate of polling?
>
> I'm not sure the DeviceControl BITS object is justified if there is only one value.
Not Applicable.

>
> CollectorMaxEntries has a range (1..8). This looks to be an implementation-specific
>decision. The same for NextAvailableIndex. I don't like the last paragraph of the
>description for NextAvailableIndex, or understand why it is needed. Row creation
>should follow the normal constraints of SNMP SETs for row creation.
Not Applicable.

>
> CollectorEntry: There may be better ways to specify the non-volatile requirements, such as the StorageType Textual Convention. I would change "across entity resets" to "across re-initializations of the network management portion of the system".
>
> CollectorIndex should not be constrained to the (1..8) range.
>
> If syslog is ever used over transports that are not IP-based, then using transport address conventions as discussed in RFC3419 might be appropriate.
>
> CollectorUDPPort might be better as simply CollectorPort to allow TCP ports to be specified.
Not applicable.
>
> I'm not sure I understand why the MessagesIgnored counter is important to maintain.
This could be of interest to a Manager to know how many useless messages are being directed
to it.

>
> I would eliminate the DefaultUdpPort, DefaultFacility, and DefaultSeverity options as adding
> unnecessary complexity, unless the WG feels this is justified.
Not really. Let me have other opinions.

>
> The security boilerplate is under review by the O&M Area. It should be updated when the new
> boilerplate becomes available.
Absolutely. I have not worked on this section at all.

>
> References should be updated. SNMPv3 has been published in new RFCs, and the boilerplate for
> mibs has been simplified, so many of the references can be eliminated from this document, and
> some need to be modified.

Some cleaning has been done. I will take another look at this.

>
> dbh
> ---
> David Harrington
> [email-masked]
> co-chair, IETF SNMPv3 WG

Thanks a lot.

Glenn

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

Date: Mon, 6 Jan 2003 13:05:20 -0500
From: "Pape, Bruno" <[email-masked]>
Subject: RE: FW: syslog mib review

Please feel free to remove my name.  My participation will probably
be limited to that of a passive observer, from somewhere up in the
peanut gallery.

Greetings,

Bruno

>
> Bruno Pape should be removed from the CONTACT-INFO, although I
> think he should be acknowledged in an Acknowledgement or Authors
> section (the chairs can decide how they want to handle that issue).

This is not yet done. I was under the impression that Bruno will be
on the team. Let me know if I am wrong.

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

Date: Tue, 7 Jan 2003 12:36:36 +0100
From: Rainer Gerhards <[email-masked]>
Subject: Any early syslog-sign implementations?

Hi,

We are currently spawning off a project that will hopefully around
may/june bring a basic implementation of syslog-sign. A few things need
to be finalized, but I am positive it will happen. Question: are there
some implementations already out? Any planned within that time frame?
Our project will most probably run initially under win32, so I guess
that would proivide for good interop tests.

Rainer Gerhards
Adiscon

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

Date: Tue, 07 Jan 2003 22:32:35 +0100
From: "[email-masked]" <[email-masked]>
Subject: Re: Any early syslog-sign implementations?

>
> We are currently spawning off a project that will hopefully around
> may/june bring a basic implementation of syslog-sign. A few things need
> to be finalized, but I am positive it will happen. Question: are there
> some implementations already out? Any planned within that time frame?
> Our project will most probably run initially under win32, so I guess

I have already a (open source) implementation for syslog-sign.
It is based on FreeBSD's syslog; and currently aimed ad FreeBSD. Porting
to others is simple.

It is based on the previous draft.

I have given a presentation about it, on BSDEuroCon 2002
See
	http://2002.eurobsdcon.org/
	http://2002.eurobsdcon.org/papers/#mietus
	http://2002.eurobsdcon.org/papers/mietus_presentation.pdf

Email mee for more info

- --ALbert Mietus
Sent prive mail to:      [email-masked]
Sent business  mail to: [email-masked]

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

Date: Thu, 9 Jan 2003 16:38:55 +0000
From: Magosányi Árpád <[email-masked]>
Subject: Re: syslog-mib

Hi!

How do you plan to address that each syslog implementation
have different configureable parameters and configuration
approaches? For an example see syslog-ng documentation at
http://www.balabit.hu/static/syslog-ng/reference/book1.html

I could not see if this is a goal of the MIB, But if it
isn't, then I cannot see the point of having one.

- -- 
GNU GPL: csak tiszta forrásból

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

Date: Thu, 9 Jan 2003 13:51:57 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: syslog-mib

Hi,

I think the answer to your question is "by defining a standard so vendors are encouraged to use a common approach rather than everybody using their own vendor-specific proprietary approach."

If we were not trying to define an industry standard, I wouldn't see the point of doing this work in the IETF.

dbh
- ---
David Harrington
[email-masked]
co-chair, IETF SNMPv3 WG

> -----Original Message-----
> From: Magosányi Árpád [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 11:39 AM
> To: Glenn Mansfield Keeni
> Cc: [email-masked]
> Subject: Re: syslog-mib
>
>
> Hi!
>
> How do you plan to address that each syslog implementation
> have different configureable parameters and configuration
> approaches? For an example see syslog-ng documentation at
> http://www.balabit.hu/static/syslog-ng/reference/book1.html
>
> I could not see if this is a goal of the MIB, But if it
> isn't, then I cannot see the point of having one.
>
> --
> GNU GPL: csak tiszta forrásból
>
>
>
>

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

Date: Thu, 9 Jan 2003 21:04:54 +0000
From: Magosányi Árpád <[email-masked]>
Subject: Re: syslog-mib

A levelezõm azt hiszi, hogy Harrington, David a következõeket írta:
> Hi,
>
> I think the answer to your question is "by defining a standard so vendors
> are encouraged to use a common approach rather than everybody using their
> own vendor-specific proprietary approach."
>
> If we were not trying to define an industry standard, I wouldn't see the
> point of doing this work in the IETF.

In this case I guess you should encourage current vendors to agree on
an apprach which is feasible for most of them. I guess it should be more
flexible than what you have shown so far. (I hope I err.)

- -- 
GNU GPL: csak tiszta forrásból

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

Date: Thu, 9 Jan 2003 22:14:44 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog-mib

Hi,

> I think the answer to your question is "by defining a
> standard so vendors are encouraged to use a common approach
> rather than everybody using their own vendor-specific
> proprietary approach."
>
> If we were not trying to define an industry standard, I
> wouldn't see the point of doing this work in the IETF.

I agree with this approach, but I have to admit that in my point of view this can only provide a basic configuration set for some typical uses. We, for example, have flexible, firewall-like rule sets in our products (which consume and emit syslog but are not limited to this) which can not be configured by the MIB.

Anyhow, I think providing a guideline to vendors is definitely helpful and there are many syslog devices out that can work perfectly with the provided config info.

Just my 2 cents...

Rainer Gerhards
Adiscon

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

Date: Thu, 9 Jan 2003 19:04:06 -0500
From: "Harrington, David" <[email-masked]>
Subject: RE: syslog-mib

It is fairly common to provide a standard mib for basic configuration (least common denominator).

Such a standard mib is often supplemented by a vendor-specific mib to allow users to provide more fine-tuned configuration.

Vendors can support a standard configuration request by using default values for all the non-standard attributes, where a standard configuration is adequate for the operator. This has the benefit that an operator can use a standard configuration request across vendors.

dbh

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 4:15 PM
> To: Harrington, David; [iso-8859-1] [iso-8859-1] Magosányi
> Árpád; Glenn
> Mansfield Keeni
> Cc: [email-masked]
> Subject: RE: syslog-mib
>
>
> Hi,
>
> > I think the answer to your question is "by defining a
> > standard so vendors are encouraged to use a common approach
> > rather than everybody using their own vendor-specific
> > proprietary approach."
> >
> > If we were not trying to define an industry standard, I
> > wouldn't see the point of doing this work in the IETF.
>
> I agree with this approach, but I have to admit that in my
> point of view this can only provide a basic configuration set
> for some typical uses. We, for example, have flexible,
> firewall-like rule sets in our products (which consume and
> emit syslog but are not limited to this) which can not be
> configured by the MIB.
>
> Anyhow, I think providing a guideline to vendors is
> definitely helpful and there are many syslog devices out that
> can work perfectly with the provided config info.
>
> Just my 2 cents...
>
> Rainer Gerhards
> Adiscon
>
>
>
>

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

Date: Fri, 10 Jan 2003 12:37:09 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-device-mib-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		: Syslog MIB
	Author(s)	: G. Keeni, B. Pape
	Filename	: draft-ietf-syslog-device-mib-02.txt
	Pages		: 43
	Date		: 2003-1-10

This memo provides a MIB module that can be used to configure which
syslog collectors or relays a syslog device will attempt to send
syslog messages to.  In addition it defines objects that allow the
collection of statistics related to the generation of syslog messages.
And finally it provides a means for controlling the messages that
individual applications on a device will generate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-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-device-mib-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-device-mib-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.

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

Date: Wed, 15 Jan 2003 08:14:13 -0500
From: Mark Ellison <[email-masked]>
Subject: draft-ietf-syslog-device-mib-02.txt

Hi,

A small nit regarding syslogParamsSendToAllAddresses.

Would it be possible to use the TruthValue TC defined in
SNMPv2-TC (RFC 2579) as the defined syntax for
syslogParamsSendToAllAddresses instead of reinventing a
boolean syntax?

Regards,

Mark

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

Date: Fri, 17 Jan 2003 14:07:28 +0100
From: Johan Bosaeus <[email-masked]>
Subject: Compariing Syslog and SNMP

Hi,
We are considering to to implement an improved Syslog. Does anybody have any opinion of in which aspects the Syslog facility will outperform SNMP.

                                                           Regards,
                                                                    Johan Bosaeus

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

Date: Mon, 20 Jan 2003 13:13:36 -0800
From: Mike MacFaden <[email-masked]>
Subject: Re: Compariing Syslog and SNMP

On Fri, Jan 17, 2003 at 02:07:28PM +0100, Johan Bosaeus wrote:
>We are considering to to implement an improved Syslog. Does anybody have any opinion of in which aspects the Syslog facility will outperform SNMP.

simplicity....but that comes at a high price.

Typcially on network gear the two systems are still
used in parallel.

syslog is presently used for vendor/platform specific
debug and notification messages.

SNMP is used for platform and vendor independent
standard notifications (v1/v2 traps, informs)
acked and non-acked forms which can be passed through
VACM (involved filtering mechanism)
to send different notifications to different receivers
as well as send such notifications
with/without authentication and/or encryption. Also works
through one or more snmp proxies.

Mike MacFaden

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

Date: Tue, 21 Jan 2003 12:36:22 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: TIMESTAMP format (One Last Time :-)

Hi Folks,

I've looked through Rainer's proposal for a better TIMESTAMP and have
some slight modifications to propose.  These are for:

 - TIMESTAMP field and formats of TIMESTAMP-3339 and TIMESTAMP-3164
   (Rather than 3339-TIMESTAMP.)
 - Maximum TIMESTAMP field length of 30 characters (that should give
   4 secfrac characters if the rest of the field is maximally filled -
   having 5 characters in the offset with a "+"/"-" rather than "Z".)
   [I just like bounding these things. :-) ]
 - A note about using TIMESTAMP-3339 in syslog-sign packets.
 - A note about the concern for the overall length of the packet if
   using TIMESTAMP-3339.

Please look this over and send back comments to the list.  If this looks
good, then we can ask Jon to place it into the next version of the ID.

- ---vvv--- Proposed change to Section 2.2 ---vvv---

The TIMESTAMP field is either a timestamp as defined in RFC 3164 denoted
as TIMESTAMP-3164, or as a formalized timestamp as taken from RFC 3339.
A sender SHOULD format the timestamp as a RFC 3339 timestamp described
below as TIMESTAMP-3339.  A receiver MUST accept both formats.

The TIMESTAMP-3164 is the local time and is in the format of "Mmm
dd hh:mm:ss" (without the quote marks) where:

       Mmm is the English language abbreviation for the month of the
       year with the first character in uppercase and the other two
       characters in lowercase. The following are the only acceptable
       values:

           Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

       dd is the day of the month. If the day of the month is less than
       10, then it MUST be represented as a space and then the number.
       For example, the 7th day of August would be represented as "Aug
       7", with two spaces between the "g" and the "7".

       hh:mm:ss is the local time. The hour (hh) is represented in a
       24-hour format. Valid entries are between 00 and 23, inclusive.
       The minute (mm) and second (ss) entries are between 00 and 59
       inclusive.

The following syntax MUST be used when using a TIMESTAMP-3339. This
is specified using the syntax description notation defined in [ABNF].

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

RFC 3339 makes allowances for multiple formats for a timestamp to be
used in various cases.  This document mandates a single format.  The
primary characteristics of TIMESTAMP-3339 used in this document are
as follows.

  - the "T" and "Z" characters in this syntax MUST be upper case.
  - usage of the "T" character is mandatory. It MUST NOT be replaced by
    any other character (like a space character).
  - the sender SHOULD include time-secfrac (fractional seconds) if its
    clock accuracy permits.
  - the entire length of the TIMESTAMP-3339 field MUST NOT exceed 30
    characters.

A sample of this format is:

      1985-04-12T23:20:50.52Z

This represents 20 minutes and 50.52 seconds after the 23rd hour of
April 12th, 1985 in UTC.

Messages containing Signature Blocks and Certificate Blocks as
described in this document SHOULD use the TIMESTAMP-3339 format in
the TIMESTAMP field.  It is not mandated that they do so at this time
since most of the receivers in use today will not be able to understand
that format and may modify those packets according to Section 4.3 of
RFC 3164.

A single space character MUST follow the TIMESTAMP field.

Receivers parsing the date format SHOULD check if the TIMESTAMP is a
TIMESTAMP-3339. The "T" character at position 11 of the string can be
used as a rough indication for this. However, the receiver MUST NOT rely
solely on the "T" character but also parse the other data for validity.
A receiver SHOULD check for TIMESTAMP-3339 format first and, if
unsuccessful, assume a TIMESTAMP-3164. If it is also not a TIMESTAMP-3164
format, the receiver MUST NOT try any other timestamp format but consider
the TIMESTAMP to be invalid or missing from the received syslog message.

If a relay receives a TIMESTAMP-3164, it SHOULD forward the message
with a TIMESTAMP-3164 but MAY reformat it to a TIMESTAMP-3339 if
configured to do so. Relays should be aware that the TIMESTAMP-3339 may
be longer than the TIMESTAMP-3164 and a replacement of the TIMESTAMP-3164
with a TIMESTAMP-3339 may increase the length of the entire packet beyond
1024 bytes.  If a relay receives a TIMESTAMP-3339 it MUST forward the
message with a TIMESTAMP-3339. It MUST NOT reformat it to a
TIMESTAMP-3164.

- ---^^^--- Proposed change to Section 2.2 ---^^^---

Thanks,
Chris

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

Date: Tue, 21 Jan 2003 12:40:58 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: HOSTNAME Field

Hi Folks,

Going along with the proposed changes to the TIMESTAMP field, perhaps it
would be good to address the HOSTNAME field.  First, the HOSTNAME field is
just that; the host name without the domain name.  This goes against
almost everything else Internet-ish and IETF-ish so I'd like to propose
that the HOSTNAME field contain either a HOSTNAME-3164 format, for legacy
compatability, or a HOSTNAME-STD13 format which provides for a full host
name and fqdn.  Currently, Section 2.2 of the syslog-sign ID has the
following text:

- ---vvv--- Currently in Section 2.2 ---vvv---

   The HOSTNAME field will contain only the hostname, the IPv4 address,
   or the IPv6 address of the originator of the message. The preferred
   value is the hostname. If the hostname is used, the HOSTNAME field
   MUST contain the hostname of the device as specified in STD-13 [4].
   The Domain Name MUST NOT be included in the HOSTNAME field. If the
   IPv4 address is used, it MUST be shown as the dotted decimal
   notation as used in STD-13 [5]. If an IPv6 address is used, any
   valid representation used in RFC-2373 [6] MAY be used. A single
   space character MUST also follow the HOSTNAME field.

- ---^^^--- Currently in Section 2.2 ---^^^---

I would propose that it be changed to the following:

- ---vvv--- Proposed change to Section 2.2 ---vvv---

   The HOSTNAME field will contain an indication of the originator of
   the message in one of four formats:  only the hostname, the hostname
   and domainname, the IPv4 address, or the IPv6 address.  The preferred
   value is the hostname and domainname in the format specified in
   STD-13 [RFC 1034 and 1035].  This format will be referred to in this
   document as HOSTNAME-STD13.  If only the hostname is used, the
   HOSTNAME field MUST contain the hostname only of the device as
   specified in STD-13 [4].  This format is discouraged but provides for
   legacy compatability with the format described in RFC 3164.  This
   format will be referred to in this document as HOSTNAME-3164.  In
   this format, the Domain Name MUST NOT be included in the HOSTNAME
   field.  If the IPv4 address is used, it MUST be shown as the dotted
   decimal notation as used in STD-13 [5], and will be referred to as
   HOSTNAME-IPV4.  If an IPv6 address is used, any valid representation
   used in RFC-2373 [6] MAY be used and will be referred to as
   HOSTNAME-IPV6. A single space character MUST also follow the
   HOSTNAME field.

   Messages containing Signature Blocks and Certificate Blocks as
   described in this document MUST use the HOSTNAME-STD13 format in
   the HOSTNAME field.

- ---^^^--- Proposed change to Section 2.2 ---^^^---

Please respond to the list about your thoughts on this.

Thanks,
Chris

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

Date: Tue, 21 Jan 2003 17:10:23 -0500
From: Marshall Glen <[email-masked]>
Subject: RE: HOSTNAME Field

Chris,

I conceptually agree with the proposed change.

At the same time, at the risk of duplicating prior comments, I see this
allows for the HOSTNAME to reference a logical entity which may be a subset
or superset of a physical entity.  For example, foo.bar.com may easily refer
to a web server process, a load-balancing switch for several e-mail servers,
or a vanilla-flavor physical host machine of arbitrary use.  This suggests
that HOSTNAME does not and cannot unambiguously (or authentically) identify
the source of the message.  Is this a problem?

Glen

- -----Original Message-----
From: Christopher Lonvick

- --vvv--- Proposed change to Section 2.2 ---vvv---

   The HOSTNAME field will contain an indication of the originator of
   the message in one of four formats:  only the hostname, the hostname
   and domainname, the IPv4 address, or the IPv6 address.  The preferred
   value is the hostname and domainname in the format specified in
   STD-13 [RFC 1034 and 1035].  This format will be referred to in this
   document as HOSTNAME-STD13.  If only the hostname is used, the
   HOSTNAME field MUST contain the hostname only of the device as
   specified in STD-13 [4].  This format is discouraged but provides for
   legacy compatability with the format described in RFC 3164.  This
   format will be referred to in this document as HOSTNAME-3164.  In
   this format, the Domain Name MUST NOT be included in the HOSTNAME
   field.  If the IPv4 address is used, it MUST be shown as the dotted
   decimal notation as used in STD-13 [5], and will be referred to as
   HOSTNAME-IPV4.  If an IPv6 address is used, any valid representation
   used in RFC-2373 [6] MAY be used and will be referred to as
   HOSTNAME-IPV6. A single space character MUST also follow the
   HOSTNAME field.

   Messages containing Signature Blocks and Certificate Blocks as
   described in this document MUST use the HOSTNAME-STD13 format in
   the HOSTNAME field.

- ---^^^--- Proposed change to Section 2.2 ---^^^---

- -------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
Health Services Corporation and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information.  Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful.  If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to [email-masked].  Thank you

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

Date: Wed, 22 Jan 2003 12:47:58 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: HOSTNAME Field

Hi Chris,

I agree with your proposal for the hostname and FQDN. I can't see any
major problems with it.

Regards

Andrew

- ---vvv--- Proposed change to Section 2.2 ---vvv---

   The HOSTNAME field will contain an indication of the originator of
   the message in one of four formats:  only the hostname, the hostname
   and domainname, the IPv4 address, or the IPv6 address.  The preferred
   value is the hostname and domainname in the format specified in
   STD-13 [RFC 1034 and 1035].  This format will be referred to in this
   document as HOSTNAME-STD13.  If only the hostname is used, the
   HOSTNAME field MUST contain the hostname only of the device as
   specified in STD-13 [4].  This format is discouraged but provides for
   legacy compatability with the format described in RFC 3164.  This
   format will be referred to in this document as HOSTNAME-3164.  In
   this format, the Domain Name MUST NOT be included in the HOSTNAME
   field.  If the IPv4 address is used, it MUST be shown as the dotted
   decimal notation as used in STD-13 [5], and will be referred to as
   HOSTNAME-IPV4.  If an IPv6 address is used, any valid representation
   used in RFC-2373 [6] MAY be used and will be referred to as
   HOSTNAME-IPV6. A single space character MUST also follow the
   HOSTNAME field.

   Messages containing Signature Blocks and Certificate Blocks as
   described in this document MUST use the HOSTNAME-STD13 format in
   the HOSTNAME field.

- ---^^^--- Proposed change to Section 2.2 ---^^^---

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

Date: Wed, 22 Jan 2003 12:58:56 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: TIMESTAMP format (One Last Time :-)

Hi Chris,

>Maximum TIMESTAMP field length of 30 characters (that should give
>4 secfrac characters if the rest of the field is maximally filled -
>having 5 characters in the offset with a "+"/"-" rather than "Z".)
>[I just like bounding these things. :-) ]

I know that 30 is a nice round number and all, but if we are going to
limit the length, we should make it 32 chrs. This gives 6 digits for the
secfrac. Millisecond timing is fine now, but with 3GHz+ CPUs and 10Gb
Ethernet around these days, I think microsecond timing may be useful.
The PIX blade on a Cat6000 for example can *theoretically* log over 30K
messages per second with debug on. Greater secfrac granularity may be
required sooner than we think.

Cheers

Andrew

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

Date: Wed, 22 Jan 2003 09:29:45 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: HOSTNAME Field

> Chris,
>
> I conceptually agree with the proposed change.
>
> At the same time, at the risk of duplicating prior comments,
> I see this allows for the HOSTNAME to reference a logical
> entity which may be a subset or superset of a physical
> entity.  For example, foo.bar.com may easily refer to a web
> server process, a load-balancing switch for several e-mail
> servers, or a vanilla-flavor physical host machine of
> arbitrary use.  This suggests that HOSTNAME does not and
> cannot unambiguously (or authentically) identify the source
> of the message.  Is this a problem?

I don't think so - the current RFC3164 hostname has the same problem.
Also, if you think about the front-ended web servers, the text does not
require that you put the public name (e.g. www.example.net) into the
hostname field - it could also be www-head.example.net, www1.example.net
and www2.example.net if these are the three servers making up the farm.
In fact, I would expect the later in, as these are what I think the real
hostnames of the devices.

I think the change Chris proposes makes life much easier - and is also
already seen in many implementations.

I need to re-read the RFC in regard to relays. In my view, we should
allow a relay to reformat a hostname (any kind) in case it knows better
about the real name. I am picking up on Andrew Ross' sample of many
devices sending with a hostname of 10.0.0.1. A local relay could then be
configured to rewrite the name to a more meaningful one before
forwarding it to the central relay.

Rainer

> -----Original Message-----
> From: Christopher Lonvick
>
> --vvv--- Proposed change to Section 2.2 ---vvv---
>
>    The HOSTNAME field will contain an indication of the originator of
>    the message in one of four formats:  only the hostname,
> the hostname
>    and domainname, the IPv4 address, or the IPv6 address.
> The preferred
>    value is the hostname and domainname in the format specified in
>    STD-13 [RFC 1034 and 1035].  This format will be referred
> to in this
>    document as HOSTNAME-STD13.  If only the hostname is used, the
>    HOSTNAME field MUST contain the hostname only of the device as
>    specified in STD-13 [4].  This format is discouraged but
> provides for
>    legacy compatability with the format described in RFC 3164.  This
>    format will be referred to in this document as HOSTNAME-3164.  In
>    this format, the Domain Name MUST NOT be included in the HOSTNAME
>    field.  If the IPv4 address is used, it MUST be shown as the dotted
>    decimal notation as used in STD-13 [5], and will be referred to as
>    HOSTNAME-IPV4.  If an IPv6 address is used, any valid
> representation
>    used in RFC-2373 [6] MAY be used and will be referred to as
>    HOSTNAME-IPV6. A single space character MUST also follow the
>    HOSTNAME field.
>
>    Messages containing Signature Blocks and Certificate Blocks as
>    described in this document MUST use the HOSTNAME-STD13 format in
>    the HOSTNAME field.
>
> ---^^^--- Proposed change to Section 2.2 ---^^^---

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

Date: Wed, 22 Jan 2003 10:21:52 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: TIMESTAMP format (One Last Time :-)

I agree with Andrew,

We so often have seen those limits that we do not envision to become
limits turn into hard ones... Did you ever envision having 1 GB of
memory in your laptop...

Rainer

> >Maximum TIMESTAMP field length of 30 characters (that should give 4
> >secfrac characters if the rest of the field is maximally filled -
> >having 5 characters in the offset with a "+"/"-" rather than
> "Z".) [I
> >just like bounding these things. :-) ]
>
> I know that 30 is a nice round number and all, but if we are
> going to limit the length, we should make it 32 chrs. This
> gives 6 digits for the secfrac. Millisecond timing is fine
> now, but with 3GHz+ CPUs and 10Gb Ethernet around these days,
> I think microsecond timing may be useful. The PIX blade on a
> Cat6000 for example can *theoretically* log over 30K messages
> per second with debug on. Greater secfrac granularity may be
> required sooner than we think.
>
> Cheers
>
> Andrew
>
>
>

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

Date: Wed, 22 Jan 2003 12:49:41 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: TIMESTAMP format (One Last Time :-)

Chris,

Based on feedback I received on related issues, I would now suggest to
add a second sample for the timestamp, one which does work with an
actual time offset. Like this:

- ---- Proposed Change
A sample of this format is:

      1985-04-12T23:20:50.52Z

This represents 20 minutes and 50.52 seconds after the 23rd hour of
April 12th, 1985 in UTC.

The same timestamp can be expressed in local time. In US Eastern
Standard Time (5 hours behind UTC), the exact same time would look as
follows:

      1985-04-12T18:20:50.52-0500
- ---- End Proposed Change

I don't think it is absolutely vital, especially as all of this is
covered in RFC3339 in detail. But my experience shows this might help to
prevent implementation errors.

Rainer

> -----Original Message-----
> From: Christopher Lonvick [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 9:36 PM
> To: [email-masked]
> Subject: TIMESTAMP format (One Last Time :-)
>
>
> Hi Folks,
>
> I've looked through Rainer's proposal for a better TIMESTAMP
> and have some slight modifications to propose.  These are for:
>
>  - TIMESTAMP field and formats of TIMESTAMP-3339 and TIMESTAMP-3164
>    (Rather than 3339-TIMESTAMP.)
>  - Maximum TIMESTAMP field length of 30 characters (that should give
>    4 secfrac characters if the rest of the field is maximally filled -
>    having 5 characters in the offset with a "+"/"-" rather than "Z".)
>    [I just like bounding these things. :-) ]
>  - A note about using TIMESTAMP-3339 in syslog-sign packets.
>  - A note about the concern for the overall length of the packet if
>    using TIMESTAMP-3339.
>
> Please look this over and send back comments to the list.  If
> this looks good, then we can ask Jon to place it into the
> next version of the ID.
>
> ---vvv--- Proposed change to Section 2.2 ---vvv---
>
> The TIMESTAMP field is either a timestamp as defined in RFC
> 3164 denoted as TIMESTAMP-3164, or as a formalized timestamp
> as taken from RFC 3339. A sender SHOULD format the timestamp
> as a RFC 3339 timestamp described below as TIMESTAMP-3339.  A
> receiver MUST accept both formats.
>
> The TIMESTAMP-3164 is the local time and is in the format of
> "Mmm dd hh:mm:ss" (without the quote marks) where:
>
>        Mmm is the English language abbreviation for the month of the
>        year with the first character in uppercase and the other two
>        characters in lowercase. The following are the only acceptable
>        values:
>
>            Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
>
>        dd is the day of the month. If the day of the month is
> less than
>        10, then it MUST be represented as a space and then the number.
>        For example, the 7th day of August would be represented as "Aug
>        7", with two spaces between the "g" and the "7".
>
>        hh:mm:ss is the local time. The hour (hh) is represented in a
>        24-hour format. Valid entries are between 00 and 23, inclusive.
>        The minute (mm) and second (ss) entries are between 00 and 59
>        inclusive.
>
> The following syntax MUST be used when using a
> TIMESTAMP-3339. This is specified using the syntax
> description notation defined in [ABNF].
>
>    date-fullyear   = 4DIGIT
>    date-month      = 2DIGIT  ; 01-12
>    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
>                              ; month/year
>    time-hour       = 2DIGIT  ; 00-23
>    time-minute     = 2DIGIT  ; 00-59
>    time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on
> leap second
>                              ; rules
>    time-secfrac    = "." 1*DIGIT
>    time-numoffset  = ("+" / "-") time-hour ":" time-minute
>    time-offset     = "Z" / time-numoffset
>
>    partial-time    = time-hour ":" time-minute ":" time-second
>                      [time-secfrac]
>    full-date       = date-fullyear "-" date-month "-" date-mday
>    full-time       = partial-time time-offset
>
>    date-time       = full-date "T" full-time
>
> RFC 3339 makes allowances for multiple formats for a
> timestamp to be used in various cases.  This document
> mandates a single format.  The primary characteristics of
> TIMESTAMP-3339 used in this document are as follows.
>
>   - the "T" and "Z" characters in this syntax MUST be upper case.
>   - usage of the "T" character is mandatory. It MUST NOT be
> replaced by
>     any other character (like a space character).
>   - the sender SHOULD include time-secfrac (fractional seconds) if its
>     clock accuracy permits.
>   - the entire length of the TIMESTAMP-3339 field MUST NOT exceed 30
>     characters.
>
> A sample of this format is:
>
>       1985-04-12T23:20:50.52Z
>
> This represents 20 minutes and 50.52 seconds after the 23rd
> hour of April 12th, 1985 in UTC.
>
> Messages containing Signature Blocks and Certificate Blocks
> as described in this document SHOULD use the TIMESTAMP-3339
> format in the TIMESTAMP field.  It is not mandated that they
> do so at this time since most of the receivers in use today
> will not be able to understand that format and may modify
> those packets according to Section 4.3 of RFC 3164.
>
> A single space character MUST follow the TIMESTAMP field.
>
> Receivers parsing the date format SHOULD check if the
> TIMESTAMP is a TIMESTAMP-3339. The "T" character at position
> 11 of the string can be used as a rough indication for this.
> However, the receiver MUST NOT rely solely on the "T"
> character but also parse the other data for validity. A
> receiver SHOULD check for TIMESTAMP-3339 format first and, if
> unsuccessful, assume a TIMESTAMP-3164. If it is also not a
> TIMESTAMP-3164 format, the receiver MUST NOT try any other
> timestamp format but consider the TIMESTAMP to be invalid or
> missing from the received syslog message.
>
> If a relay receives a TIMESTAMP-3164, it SHOULD forward the
> message with a TIMESTAMP-3164 but MAY reformat it to a
> TIMESTAMP-3339 if configured to do so. Relays should be aware
> that the TIMESTAMP-3339 may be longer than the TIMESTAMP-3164
> and a replacement of the TIMESTAMP-3164 with a TIMESTAMP-3339
> may increase the length of the entire packet beyond 1024
> bytes.  If a relay receives a TIMESTAMP-3339 it MUST forward
> the message with a TIMESTAMP-3339. It MUST NOT reformat it to
> a TIMESTAMP-3164.
>
> ---^^^--- Proposed change to Section 2.2 ---^^^---
>
> Thanks,
> Chris
>
>
>

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

Date: Wed, 22 Jan 2003 08:36:57 -0500
From: Marshall Glen <[email-masked]>
Subject: RE: HOSTNAME Field

Rainer,

OK, that sounds reasonable.  The examples you give are a good ones and
probably should be included in the RFC text.

Glen

- -----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]]
Sent: Wednesday, January 22, 2003 03:30
To: Marshall Glen; [email-masked]
Subject: RE: HOSTNAME Field

> Chris,
>
> I conceptually agree with the proposed change.
>
> At the same time, at the risk of duplicating prior comments,
> I see this allows for the HOSTNAME to reference a logical
> entity which may be a subset or superset of a physical
> entity.  For example, foo.bar.com may easily refer to a web
> server process, a load-balancing switch for several e-mail
> servers, or a vanilla-flavor physical host machine of
> arbitrary use.  This suggests that HOSTNAME does not and
> cannot unambiguously (or authentically) identify the source
> of the message.  Is this a problem?

I don't think so - the current RFC3164 hostname has the same problem. Also,
if you think about the front-ended web servers, the text does not require
that you put the public name (e.g. www.example.net) into the hostname field
- - it could also be www-head.example.net, www1.example.net and
www2.example.net if these are the three servers making up the farm. In fact,
I would expect the later in, as these are what I think the real hostnames of
the devices.

I think the change Chris proposes makes life much easier - and is also
already seen in many implementations.

I need to re-read the RFC in regard to relays. In my view, we should allow a
relay to reformat a hostname (any kind) in case it knows better about the
real name. I am picking up on Andrew Ross' sample of many devices sending
with a hostname of 10.0.0.1. A local relay could then be configured to
rewrite the name to a more meaningful one before forwarding it to the
central relay.

Rainer

> -----Original Message-----
> From: Christopher Lonvick
>
> --vvv--- Proposed change to Section 2.2 ---vvv---
>
>    The HOSTNAME field will contain an indication of the originator of
>    the message in one of four formats:  only the hostname,
> the hostname
>    and domainname, the IPv4 address, or the IPv6 address.
> The preferred
>    value is the hostname and domainname in the format specified in
>    STD-13 [RFC 1034 and 1035].  This format will be referred
> to in this
>    document as HOSTNAME-STD13.  If only the hostname is used, the
>    HOSTNAME field MUST contain the hostname only of the device as
>    specified in STD-13 [4].  This format is discouraged but
> provides for
>    legacy compatability with the format described in RFC 3164.  This
>    format will be referred to in this document as HOSTNAME-3164.  In
>    this format, the Domain Name MUST NOT be included in the HOSTNAME
>    field.  If the IPv4 address is used, it MUST be shown as the dotted
>    decimal notation as used in STD-13 [5], and will be referred to as
>    HOSTNAME-IPV4.  If an IPv6 address is used, any valid
> representation
>    used in RFC-2373 [6] MAY be used and will be referred to as
>    HOSTNAME-IPV6. A single space character MUST also follow the
>    HOSTNAME field.
>
>    Messages containing Signature Blocks and Certificate Blocks as
>    described in this document MUST use the HOSTNAME-STD13 format in
>    the HOSTNAME field.
>
> ---^^^--- Proposed change to Section 2.2 ---^^^---

- -------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
Health Services Corporation and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information.  Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful.  If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to [email-masked].  Thank you

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

Date: Wed, 22 Jan 2003 08:29:17 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: RE: TIMESTAMP format (One Last Time :-)

Hi Rainer,

32 octets sounds good.  It would probably be a good idea to put an note in
the IANA Concerns section that additional TIMESTAMP formats may be defined
as the granularity becomes more definable and is needed.

In your example, you have:
>       1985-04-12T18:20:50.52-0500
Shouldn't that be:
        1985-04-12T18:20:50.52-05:00
with a colon here ---------------^

(I'm also assuming that you've checked the relevent daylight savings
shifts to ensure that the time in your second example _is_ actually the
same time as in the first example.  :)

Thanks,
Chris

On Wed, 22 Jan 2003, Rainer Gerhards wrote:

> Chris,
>
> Based on feedback I received on related issues, I would now suggest to
> add a second sample for the timestamp, one which does work with an
> actual time offset. Like this:
>
> ---- Proposed Change
> A sample of this format is:
>
>       1985-04-12T23:20:50.52Z
>
> This represents 20 minutes and 50.52 seconds after the 23rd hour of
> April 12th, 1985 in UTC.
>
> The same timestamp can be expressed in local time. In US Eastern
> Standard Time (5 hours behind UTC), the exact same time would look as
> follows:
>
>       1985-04-12T18:20:50.52-0500
> ---- End Proposed Change
>
> I don't think it is absolutely vital, especially as all of this is
> covered in RFC3339 in detail. But my experience shows this might help to
> prevent implementation errors.
>
> Rainer
>
> > -----Original Message-----
> > From: Christopher Lonvick [mailto:[email-masked]]
> > Sent: Tuesday, January 21, 2003 9:36 PM
> > To: [email-masked]
> > Subject: TIMESTAMP format (One Last Time :-)
> >
> >
> > Hi Folks,
> >
> > I've looked through Rainer's proposal for a better TIMESTAMP
> > and have some slight modifications to propose.  These are for:
> >
> >  - TIMESTAMP field and formats of TIMESTAMP-3339 and TIMESTAMP-3164
> >    (Rather than 3339-TIMESTAMP.)
> >  - Maximum TIMESTAMP field length of 30 characters (that should give
> >    4 secfrac characters if the rest of the field is maximally filled -
> >    having 5 characters in the offset with a "+"/"-" rather than "Z".)
> >    [I just like bounding these things. :-) ]
> >  - A note about using TIMESTAMP-3339 in syslog-sign packets.
> >  - A note about the concern for the overall length of the packet if
> >    using TIMESTAMP-3339.
> >
> > Please look this over and send back comments to the list.  If
> > this looks good, then we can ask Jon to place it into the
> > next version of the ID.
> >
> > ---vvv--- Proposed change to Section 2.2 ---vvv---
> >
> > The TIMESTAMP field is either a timestamp as defined in RFC
> > 3164 denoted as TIMESTAMP-3164, or as a formalized timestamp
> > as taken from RFC 3339. A sender SHOULD format the timestamp
> > as a RFC 3339 timestamp described below as TIMESTAMP-3339.  A
> > receiver MUST accept both formats.
> >
> > The TIMESTAMP-3164 is the local time and is in the format of
> > "Mmm dd hh:mm:ss" (without the quote marks) where:
> >
> >        Mmm is the English language abbreviation for the month of the
> >        year with the first character in uppercase and the other two
> >        characters in lowercase. The following are the only acceptable
> >        values:
> >
> >            Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
> >
> >        dd is the day of the month. If the day of the month is
> > less than
> >        10, then it MUST be represented as a space and then the number.
> >        For example, the 7th day of August would be represented as "Aug
> >        7", with two spaces between the "g" and the "7".
> >
> >        hh:mm:ss is the local time. The hour (hh) is represented in a
> >        24-hour format. Valid entries are between 00 and 23, inclusive.
> >        The minute (mm) and second (ss) entries are between 00 and 59
> >        inclusive.
> >
> > The following syntax MUST be used when using a
> > TIMESTAMP-3339. This is specified using the syntax
> > description notation defined in [ABNF].
> >
> >    date-fullyear   = 4DIGIT
> >    date-month      = 2DIGIT  ; 01-12
> >    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
> >                              ; month/year
> >    time-hour       = 2DIGIT  ; 00-23
> >    time-minute     = 2DIGIT  ; 00-59
> >    time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on
> > leap second
> >                              ; rules
> >    time-secfrac    = "." 1*DIGIT
> >    time-numoffset  = ("+" / "-") time-hour ":" time-minute
> >    time-offset     = "Z" / time-numoffset
> >
> >    partial-time    = time-hour ":" time-minute ":" time-second
> >                      [time-secfrac]
> >    full-date       = date-fullyear "-" date-month "-" date-mday
> >    full-time       = partial-time time-offset
> >
> >    date-time       = full-date "T" full-time
> >
> > RFC 3339 makes allowances for multiple formats for a
> > timestamp to be used in various cases.  This document
> > mandates a single format.  The primary characteristics of
> > TIMESTAMP-3339 used in this document are as follows.
> >
> >   - the "T" and "Z" characters in this syntax MUST be upper case.
> >   - usage of the "T" character is mandatory. It MUST NOT be
> > replaced by
> >     any other character (like a space character).
> >   - the sender SHOULD include time-secfrac (fractional seconds) if its
> >     clock accuracy permits.
> >   - the entire length of the TIMESTAMP-3339 field MUST NOT exceed 30
> >     characters.
> >
> > A sample of this format is:
> >
> >       1985-04-12T23:20:50.52Z
> >
> > This represents 20 minutes and 50.52 seconds after the 23rd
> > hour of April 12th, 1985 in UTC.
> >
> > Messages containing Signature Blocks and Certificate Blocks
> > as described in this document SHOULD use the TIMESTAMP-3339
> > format in the TIMESTAMP field.  It is not mandated that they
> > do so at this time since most of the receivers in use today
> > will not be able to understand that format and may modify
> > those packets according to Section 4.3 of RFC 3164.
> >
> > A single space character MUST follow the TIMESTAMP field.
> >
> > Receivers parsing the date format SHOULD check if the
> > TIMESTAMP is a TIMESTAMP-3339. The "T" character at position
> > 11 of the string can be used as a rough indication for this.
> > However, the receiver MUST NOT rely solely on the "T"
> > character but also parse the other data for validity. A
> > receiver SHOULD check for TIMESTAMP-3339 format first and, if
> > unsuccessful, assume a TIMESTAMP-3164. If it is also not a
> > TIMESTAMP-3164 format, the receiver MUST NOT try any other
> > timestamp format but consider the TIMESTAMP to be invalid or
> > missing from the received syslog message.
> >
> > If a relay receives a TIMESTAMP-3164, it SHOULD forward the
> > message with a TIMESTAMP-3164 but MAY reformat it to a
> > TIMESTAMP-3339 if configured to do so. Relays should be aware
> > that the TIMESTAMP-3339 may be longer than the TIMESTAMP-3164
> > and a replacement of the TIMESTAMP-3164 with a TIMESTAMP-3339
> > may increase the length of the entire packet beyond 1024
> > bytes.  If a relay receives a TIMESTAMP-3339 it MUST forward
> > the message with a TIMESTAMP-3339. It MUST NOT reformat it to
> > a TIMESTAMP-3164.
> >
> > ---^^^--- Proposed change to Section 2.2 ---^^^---
> >
> > Thanks,
> > Chris
> >
> >
> >
>
>
>

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

Date: Wed, 22 Jan 2003 09:19:53 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: RE: TIMESTAMP format (One Last Time :-)

Hi,

On Wed, 22 Jan 2003, Rainer Gerhards wrote:

> Hi Chris,
>
> Hi Rainer,
> >
> > 32 octets sounds good.  It would probably be a good idea to
> > put an note in the IANA Concerns section that additional
> > TIMESTAMP formats may be defined as the granularity becomes
> > more definable and is needed.
> >
> > In your example, you have:
> > >       1985-04-12T18:20:50.52-0500
> > Shouldn't that be:
> >         1985-04-12T18:20:50.52-05:00
> > with a colon here ---------------^
>
> Oops - I just included this to proove that the example is useful and
> really read ;)

Riiiiiiiight.  :)

>
> > (I'm also assuming that you've checked the relevent daylight
> > savings shifts to ensure that the time in your second example
> > _is_ actually the same time as in the first example.  :)
>
> To the best of *my* knowledge, it is. But, good point, it might be
> better to have someone from the timezone verify it with a date from last
> year, which might be easier to check. Or change it to PST and you do the
> math ;)

While my wife accuses me of spending too much time out on the left coast,
I actually live in Austin, TX, USA.  ;)

> (I would prefer to have an US timezone in - I have that feeling
> that this is not only easier as an example for the Americans but also
> for the Europeans - but I don't intend to start a discussion on this).
> How does this sound?

I went here:
  http://www.timeanddate.com/worldclock/meeting.html
and entered 11pm, April 12, 2003 UTC.  The output said that it was
7pm, April 12, 2003 in New York (observing daylight savings time).
Hoping that timezone stuff hasn't changed over the years, that would make
your example:

  1985-04-12T18:20:50.52-06:00

How's that?

Thanks,
Chris

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

Date: Thu, 23 Jan 2003 10:45:24 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: TIMESTAMP format (One Last Time :-)

Can we add a couple of secfrac examples too? One with 3 digits, one with
6 digits?

Cheers

Andrew

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rainer Gerhards
Sent: Wednesday, 22 January 2003 11:50 p.m.
To: Christopher Lonvick; [email-masked]
Subject: RE: TIMESTAMP format (One Last Time :-)

Chris,

Based on feedback I received on related issues, I would now suggest to
add a second sample for the timestamp, one which does work with an
actual time offset. Like this:

- ---- Proposed Change
A sample of this format is:

      1985-04-12T23:20:50.52Z

This represents 20 minutes and 50.52 seconds after the 23rd hour of
April 12th, 1985 in UTC.

The same timestamp can be expressed in local time. In US Eastern
Standard Time (5 hours behind UTC), the exact same time would look as
follows:

      1985-04-12T18:20:50.52-0500
- ---- End Proposed Change

I don't think it is absolutely vital, especially as all of this is
covered in RFC3339 in detail. But my experience shows this might help to
prevent implementation errors.

Rainer

> -----Original Message-----
> From: Christopher Lonvick [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 9:36 PM
> To: [email-masked]
> Subject: TIMESTAMP format (One Last Time :-)
>
>
> Hi Folks,
>
> I've looked through Rainer's proposal for a better TIMESTAMP
> and have some slight modifications to propose.  These are for:
>
>  - TIMESTAMP field and formats of TIMESTAMP-3339 and TIMESTAMP-3164
>    (Rather than 3339-TIMESTAMP.)
>  - Maximum TIMESTAMP field length of 30 characters (that should give
>    4 secfrac characters if the rest of the field is maximally filled -
>    having 5 characters in the offset with a "+"/"-" rather than "Z".)
>    [I just like bounding these things. :-) ]
>  - A note about using TIMESTAMP-3339 in syslog-sign packets.
>  - A note about the concern for the overall length of the packet if
>    using TIMESTAMP-3339.
>
> Please look this over and send back comments to the list.  If
> this looks good, then we can ask Jon to place it into the
> next version of the ID.
>
> ---vvv--- Proposed change to Section 2.2 ---vvv---
>
> The TIMESTAMP field is either a timestamp as defined in RFC
> 3164 denoted as TIMESTAMP-3164, or as a formalized timestamp
> as taken from RFC 3339. A sender SHOULD format the timestamp
> as a RFC 3339 timestamp described below as TIMESTAMP-3339.  A
> receiver MUST accept both formats.
>
> The TIMESTAMP-3164 is the local time and is in the format of
> "Mmm dd hh:mm:ss" (without the quote marks) where:
>
>        Mmm is the English language abbreviation for the month of the
>        year with the first character in uppercase and the other two
>        characters in lowercase. The following are the only acceptable
>        values:
>
>            Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
>
>        dd is the day of the month. If the day of the month is
> less than
>        10, then it MUST be represented as a space and then the number.
>        For example, the 7th day of August would be represented as "Aug
>        7", with two spaces between the "g" and the "7".
>
>        hh:mm:ss is the local time. The hour (hh) is represented in a
>        24-hour format. Valid entries are between 00 and 23, inclusive.
>        The minute (mm) and second (ss) entries are between 00 and 59
>        inclusive.
>
> The following syntax MUST be used when using a
> TIMESTAMP-3339. This is specified using the syntax
> description notation defined in [ABNF].
>
>    date-fullyear   = 4DIGIT
>    date-month      = 2DIGIT  ; 01-12
>    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
>                              ; month/year
>    time-hour       = 2DIGIT  ; 00-23
>    time-minute     = 2DIGIT  ; 00-59
>    time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on
> leap second
>                              ; rules
>    time-secfrac    = "." 1*DIGIT
>    time-numoffset  = ("+" / "-") time-hour ":" time-minute
>    time-offset     = "Z" / time-numoffset
>
>    partial-time    = time-hour ":" time-minute ":" time-second
>                      [time-secfrac]
>    full-date       = date-fullyear "-" date-month "-" date-mday
>    full-time       = partial-time time-offset
>
>    date-time       = full-date "T" full-time
>
> RFC 3339 makes allowances for multiple formats for a
> timestamp to be used in various cases.  This document
> mandates a single format.  The primary characteristics of
> TIMESTAMP-3339 used in this document are as follows.
>
>   - the "T" and "Z" characters in this syntax MUST be upper case.
>   - usage of the "T" character is mandatory. It MUST NOT be
> replaced by
>     any other character (like a space character).
>   - the sender SHOULD include time-secfrac (fractional seconds) if its
>     clock accuracy permits.
>   - the entire length of the TIMESTAMP-3339 field MUST NOT exceed 30
>     characters.
>
> A sample of this format is:
>
>       1985-04-12T23:20:50.52Z
>
> This represents 20 minutes and 50.52 seconds after the 23rd
> hour of April 12th, 1985 in UTC.
>
> Messages containing Signature Blocks and Certificate Blocks
> as described in this document SHOULD use the TIMESTAMP-3339
> format in the TIMESTAMP field.  It is not mandated that they
> do so at this time since most of the receivers in use today
> will not be able to understand that format and may modify
> those packets according to Section 4.3 of RFC 3164.
>
> A single space character MUST follow the TIMESTAMP field.
>
> Receivers parsing the date format SHOULD check if the
> TIMESTAMP is a TIMESTAMP-3339. The "T" character at position
> 11 of the string can be used as a rough indication for this.
> However, the receiver MUST NOT rely solely on the "T"
> character but also parse the other data for validity. A
> receiver SHOULD check for TIMESTAMP-3339 format first and, if
> unsuccessful, assume a TIMESTAMP-3164. If it is also not a
> TIMESTAMP-3164 format, the receiver MUST NOT try any other
> timestamp format but consider the TIMESTAMP to be invalid or
> missing from the received syslog message.
>
> If a relay receives a TIMESTAMP-3164, it SHOULD forward the
> message with a TIMESTAMP-3164 but MAY reformat it to a
> TIMESTAMP-3339 if configured to do so. Relays should be aware
> that the TIMESTAMP-3339 may be longer than the TIMESTAMP-3164
> and a replacement of the TIMESTAMP-3164 with a TIMESTAMP-3339
> may increase the length of the entire packet beyond 1024
> bytes.  If a relay receives a TIMESTAMP-3339 it MUST forward
> the message with a TIMESTAMP-3339. It MUST NOT reformat it to
> a TIMESTAMP-3164.
>
> ---^^^--- Proposed change to Section 2.2 ---^^^---
>
> Thanks,
> Chris
>
>
>

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

Date: Fri, 24 Jan 2003 17:35:34 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: syslog-mib

Hi,
    Apologies for the delayed to the syslog-mib related queries and
comments.
    As Dave has said it - the proposed syslog-mib attempts to provide
the dials and knobs that would be required my most if not all syslog
implementations. I have used the present BSD Syslog as the least common
denominator. I have consulted the BSD Syslog documentation and man pages
to arrive at the MIB design.
    If there are some Objects that are "required" but left out in the MIB
or Objects that are in the MIB but are unlikely to be used - we would
like to hear about it. The present MIB is far from its final form.
I am yet to refer to the document
        http://www.balabit.hu/static/syslog-ng/reference/book1.html
cited by [email-masked] (sorry I do not have the name). I
intend doing that sometime before revising the present draft. But
meanwhile I would like to hear "I want to do this and the MIB does not
offer a way to do it". Lets try to arrive at some consensus on such
requirements. If there is consensus we add it to the MIB otherwise we
leave it for vendor specific MIBs. Adding MOs to the MIB to provide
more dials and knobs is the smaller of the problems.
    I plan to have a revised version of the MIB ready by Mid February-
the major changes will be in the "DESCRIPTION" and the "REFERENCE"
clauses of the MOs in the MIB and the Security  Considerations section.
The "DESCRIPTIONS" need to be accurate and unambigious as these will
guide implementors. In the present draft I have not done been able to
put in enough efforts on the descriptions.
The "REFERECNCES" will supplement the "DESCRIPTIONS" and here I need
some advice. I intend using the BSD manpages in the "REFERENCES" clause.
Will this be OK? Is there any other more specific reference ? It seems
to be difficult to specify the objects for managing a protocol that does
not have a standard reference.
     Dave, did you volunteer to help me with the Security Considerations
scetion? I will greatly appreciate any help.

      Thanks and Cheers

           Glenn

Harrington, David wrote:
 > It is fairly common to provide a standard mib for basic configuration
  > (least common denominator).
 >
 > Such a standard mib is often supplemented by a vendor-specific mib to
  > allow users to provide more fine-tuned configuration.
 >
 > Vendors can support a standard configuration request by using default
  > values for all the non-standard attributes, where a standard configuration
  > is adequate for the operator. This has the benefit that an operator can use
 > a standard configuration request across vendors.
 >
 > dbh
 >
 >
 >>-----Original Message-----
 >>From: Rainer Gerhards [mailto:[email-masked]]
 >>Sent: Thursday, January 09, 2003 4:15 PM
 >>To: Harrington, David; [iso-8859-1] [iso-8859-1] Magosányi
 >>Árpád; Glenn
 >>Mansfield Keeni
 >>Cc: [email-masked]
 >>Subject: RE: syslog-mib
 >>
 >>
 >>Hi,
 >>
 >>
 >>>I think the answer to your question is "by defining a
 >>>standard so vendors are encouraged to use a common approach
 >>>rather than everybody using their own vendor-specific
 >>>proprietary approach."
 >>>
 >>>If we were not trying to define an industry standard, I
 >>>wouldn't see the point of doing this work in the IETF.
 >>
 >>I agree with this approach, but I have to admit that in my
 >>point of view this can only provide a basic configuration set
 >>for some typical uses. We, for example, have flexible,
 >>firewall-like rule sets in our products (which consume and
 >>emit syslog but are not limited to this) which can not be
 >>configured by the MIB.
 >>
 >>Anyhow, I think providing a guideline to vendors is
 >>definitely helpful and there are many syslog devices out that
 >>can work perfectly with the provided config info.
 >>
 >>Just my 2 cents...
 >>
 >>Rainer Gerhards
 >>Adiscon
 >>
 >>
 >>
 >
 >

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

Date: Tue, 28 Jan 2003 07:24:11 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: 56th IETF - San Francisco, CA

Hi Folks,

I'd like to call a meeting at the 56th IETF.  Glenn will be there to
discuss the work going on in the syslog MIB ID.  Are there any other
discussion items that should be brought up?

Thanks,
Chris

- ---------- Forwarded message ----------
Date: Mon, 13 Jan 2003 16:49:14 -0500
From: [email-masked]
To: IETF-Announce:  ;
Subject: 56th IETF - San Francisco, CA

Registration is now open for the 56th IETF Meeting in San Francisco,
March 16-21, 2003.

Please visit the web page at:
http://www.ietf.org/meetings/IETF-56.html
to register and obtain hotel information.

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

Date: Tue, 28 Jan 2003 10:21:18 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: Length of syslog messages

Hi,

We've talked about changing the TIMESTAMP and the HOSTNAME fields which
will increase them.  From that, we may be pushing the length of previously
valid messages over the 1024 byte limit.  Perhaps an explicit statement
about the length of syslog messages would be appropriate in the
syslog-sign ID?

- ---vvv--- Currently in Section 2 ---vvv---

   The full format of a syslog sign message seen on the wire has three
   discernible parts. The first part is called the PRI, the second part
   is the HEADER, and the third part is the MSG. The total length of
   the packet MUST be 1024 bytes or less. There is no minimum length of
   the syslog message although sending a syslog packet with no contents
   is worthless and SHOULD NOT be transmitted.

- ---^^^--- Currently in Section 2 ---^^^---

I believe that Eric Allman chose 1024 since that was a hardware buffer
size and blobs that fit within that space could be processed more
efficiently.  Increasing that size may be appropriate now.  We could
specify some actual maximum size of syslog packets but that might not be
appropriate for all cases.  Somehow, it just doesn't feel right to have IP
fragment syslog messages.  How about stating the the default maximum size
is 1024 bytes but that may be increased to be the MTU between the device
and the collector when using UDP?  This would cover the expansion of the
HOSTNAME and TIMESTAMP fields and allow all previously valid messages to
be sent without having something truncate it or fragment it.

Thoughts?

Thanks,
Chris

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

Date: Tue, 28 Jan 2003 21:01:12 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Length of syslog messages

Chris,

> We've talked about changing the TIMESTAMP and the HOSTNAME
> fields which will increase them.  From that, we may be
> pushing the length of previously valid messages over the 1024
> byte limit.  Perhaps an explicit statement about the length
> of syslog messages would be appropriate in the syslog-sign ID?

In general, I applaud every additional byte of payload that becomes
available..

[snip]

> I believe that Eric Allman chose 1024 since that was a
> hardware buffer size and blobs that fit within that space
> could be processed more efficiently.  Increasing that size
> may be appropriate now.  We could specify some actual maximum
> size of syslog packets but that might not be appropriate for
> all cases.  Somehow, it just doesn't feel right to have IP
> fragment syslog messages.  How about stating the the default
> maximum size is 1024 bytes but that may be increased to be
> the MTU between the device and the collector when using UDP?
> This would cover the expansion of the HOSTNAME and TIMESTAMP
> fields and allow all previously valid messages to be sent
> without having something truncate it or fragment it.

... But what if the MTU is below the default? I remember some
installations that really used 576 bytes as the max MTU to work around
some software problems. I don't think this was (or is) clever design,
but I would like to point out that there can be cases where the MTU is
below 1024.

Other than that, I really like the idea of some additional bytes ;)

On the similar issue, I am wondering if syslog-reliable does allow for
much large message sizes in the COOKED profile. I unfortunately had no
time to re-read RFC3195 in this regard and hope someone out here will
provide a helping hand. We are dealing for example with Windows Event
Log Messages, and these can become *really* lengthy (16 KB is even
moderate in some cases). But I also think that we will run into the size
limit in other cases (if it is around the MTU size). RFC3195 could
handle larger messages. Does it do so? If not, is there any support for
such in this WG?

Rainer Gerhards
Adiscon

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

Date: Tue, 28 Jan 2003 18:36:44 -0800
From: Mike MacFaden <[email-masked]>
Subject: Re: Length of syslog messages

On Tue, Jan 28, 2003 at 10:21:18AM -0800, Chris Lonvick wrote:
>We've talked about changing the TIMESTAMP and the HOSTNAME fields which
>will increase them.  From that, we may be pushing the length of previously
>valid messages over the 1024 byte limit.  Perhaps an explicit statement
>about the length of syslog messages would be appropriate in the
>syslog-sign ID?

As you stated in rfc3164 sec 6.1:
   "Various behaviors have been seen on receivers that do
    receive messages greater than 1024 bytes."

I'd prefer just specifying what a conformant sender/
receiver should do when it receives a message (or field)
larger than is expected.

Simply stating: "must not malfunction" may lead to
deployment/operational problems. When mpls/l2 vpns are introduced
to a network, l2 switches may see valid frames with size larger than
1500 bytes. A conformant switch (either older or misconfigured)
will exhibit the same behavior:
  increment dot3StatsFrameTooLongs and discard.

>[snip] How about stating the the default maximum size
>is 1024 bytes but that may be increased to be the MTU between the device
>and the collector when using UDP?  This would cover the expansion of the
>HOSTNAME and TIMESTAMP fields and allow all previously valid messages to
>be sent without having something truncate it or fragment it.

The message size might also be decreased by the discovered MTU
between the device and the collector as well.

I prefer that the minimum size a conformant
implementation must support be defined.
SNMP over UDP specifies a minimum message size of 484.
If one wants to support a larger msg size, just configure for it.
The same goes for switches these days too.
Otherwise why not just recommend a transport that has
path mtu discovery in cases where syslog msg length > 1024.

Regards,
Mike

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

Date: Sun, 02 Feb 2003 14:25:02 +0100
From: "[email-masked]" <[email-masked]>
Subject: [Fwd: Re: Remarks on syslog-sign (draft 07)]

Se below.

Soru, kind of busy now, so I didn't have time to explain more

- -------- Original Message --------
Subject: Re: Remarks on syslog-sign (draft 07)
Date: Tue, 28 Jan 2003 07:27:06 -0800 (PST)
From: Chris Lonvick <[email-masked]>
To: "[email-masked]" <[email-masked]>

Hi Albert,

I see your point now.  Please bring it back up on the mailing list.  If
you can, please indicate some revisions to the syslog-sign ID that will
straighten it out.  :-)

Thanks,
Chris

On Wed, 22 Jan 2003, [email-masked] wrote:

 >
 >
 > [email-masked] wrote:
 > > Hi All,
 > >
 > > Been a bit busy lately, but catching up soon, I hoop.
 > > But a quick responds on a comment on a comment ..
 > >
 > >
 > >>>> ** The TAG is defined to be ending ('MUST')with a _colon_.
 > >>>> This wrong, as rfc3164 defines it can end with a _space_
 > >>>> Adv   Rewrite: it terminates with any not alfanum char.
 > >>>
 > >
 > >
 > >> We discussed (a long time ago) that the TAG should be included in the
 > >> HEADER rather than in the MSG for people writing code.
 > >
 > >
 > > Very true, It was I who made the suggestion ...
 > >
 > >> This should mean that the TAG should be able to contain things like:
 > >>    syslog[1234]:
 > >> Since the next character may, or may not be a space, [...]
 > >
 > >
 > >> I'll suggest that the colon stay.
 > >
 > >
 > > The point is, syslog-sign messages should be syslog-rfc3164 "parsable".
 > > And, syslog-sign-deamons should handle "old" syslog messages.
 > > In other words: when a UDP message is arriving over the
syslog-port, the
 > > daemon should be able to handle (so parse) it. WITHOUT knowing it is
 > > syslog-rfc3164 or -sign.
 > > Based on my implementation, we need the space "definition" in the
 > > syslog-sign rfc, to make a 100% correct implementation.
 > >
 > > I have to look up the work for details, I hope you trust "my word" :-)
 > >
 > > NB traditional syslog can be without the colon!
 > >
 > >
 > >> That does bring up a point, however.  In "traditional" syslog
messages,
 > >> there is nothing between the ":" and the message itself in many cases.
 > >> Should there be a space between the ":" and the Signature Block,
and the
 > >> Certifiate Block in the syslog-sign messages?  If so then a Signature
 > >> Block would look like:
 > >>    syslog[1234]: @#sigSIG 0111 ...
 > >> and the Certificate Block would be:
 > >>    syslog[1234]: @#sigCER 0111 ...
 > >
 > >
 > > Based on early posting(s): I suggest to allow one or more spaces
between
 > > ANY 2 syslog-sign-fields. (for reading). And send 1 space between any 2
 > > fields. Personally, I would like to have 2 spaces at the frond. It make
 > > (manual) parsing nice. But that only a matter of style.
 > >
 > >
 > > --ALbert Mietus
 > > Sent prive mail to:      [email-masked]
 > > Sent business  mail to: [email-masked]
 > >
 >
 >
 > --
 > --ALbert Mietus
 > Sent prive mail to:      [email-masked]
 > Sent business  mail to: [email-masked]
 >
 >

- -- 
- --ALbert Mietus
Sent prive mail to:      [email-masked]
Sent business  mail to: [email-masked]

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