RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09- Part II

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Sharon,

I snipped some things which now have separate threads - I'll post the
reply to those threads. 

> S7. In relation to section 6.2.3, do we want to add a 
> section called 
> > 'Relationship to the Alarm MIB' so we can discuss the mapping of 
> > severities? This is something that has come up in private 
> discussions
> > since these do
> > differ somewhat from ever popular OSI severities. I could 
> > write this section
> > up if there is interest. Terribly useful in the case of 
> > someone logging
> > alarms.
> > 
> 
> This has been added - text proposed to WG, some feedback 
> received but should
> be further reviewed
> 
> </Rainer>
<Sharon>
> Um. I seem to have missed this. Let me propose the following text
> 
> "Relation to the Alarm MIB"
> 
> The Alarm MIB [RFC3877] defines ITU perceived severities 
> which are useful to
> be able to relate to the syslog severities, particularly in 
> the case where
> alarms are being logged. The ITU perceived severities relate 
> to the syslog
> severities as follows: A value of 'cleared' for ITUPerceivedSeverity
> corresponds to a syslog severity of 'notice'. A value of 
> 'indeterminate' for
> ITUPerceivedSeverity corresponds to a syslog severity of 
> 'notice'. A value
> of 'critical' for ITUPerceivedSeverity corresponds to a 
> syslog severity of
> 'critical'.  A value of 'major' for ITUPerceivedSeverity 
> corresponds to a
> syslog severity of 'error'. A value of 'minor' for 
> ITUPerceivedSeverity
> corresponds to a syslog severity of 'error'. A value of 'warning' for
> ITUPerceivedSeverity corresponds to a syslog severity of 'warning'.
> "
</Sharon>

I added this text to the section on severities.

> 
> <Rainer>
> > 
> > S9  In section 6.2.6, have we not already identified the device via 
> > hostname? Should this not just be application? Should we 
> rename it to 
> > reflect this?
> 
> This is very similar to a comment Anton Okmianski made. He 
> suggested that
> SENDER-NAME and SENDER-INST be renamed to APP-NAME and 
> PROCESS. Please see
> my arguments at
> 
> http://www.employees.org/pipermail/syslog-sec/2005-January/000092.html
> 
> After reading your post, I begin to think that Anton was 
> right and we should
> rename this. What do you think?
> 
> </Rainer>
> 
<Sharon>
> I can support APP-NAME, but not PROCESS, since I don't think 
> process id will
> make sense in most of the cases I expect to see. How about APP-INST?
</Sharon>

I changed the terms to APP-NAME and APP-INST...

>
> <Rainer>
>  
> > S10. In section 6.2.7, it includes the operating system
> > process ID? Does
> > this make sense in the typical IETF problem space? What about 
> > multi-computer
> > network element? Can we just delete this part of the description?
> 
> The idea in recommending a process id is that we need some relative
> uniqueness to detect restarts of the syslog daemon. So we do 
> not necessarily
> need the process ID, we need something that changes when the 
> instance of the
> sender changes. Of course, this is not absolutely vital (just 
> helpful), this
> is why we allow the "-" nil value.
> 
> </Rainer>
> 
<Sharon>
> I still say either remove the bit about the process ID or 
> indicate only that
> it may be a process ID.
> 
> "The APP-INST uniquely identifies one of multiple instances 
> of APP-NAME that
> may be running. For example, it may be a process ID."
> 
> Ideally I'd also like to suggest it might be a virtual router 
> ID, but I'm
> not sure that is correct.
</Sharon>

I am now proposing the following text for APP-INST (formerly
SENDER-INST):

####
6.2.7  APP-INST

   The APP-INST field SHOULD identify a specific instance of the sender.
   It is similiar to a reboot ID.  It is a number or string that
   identifies a given "incarnation" of the syslog sender.

   On a router, it might actually be a reboot ID, generated each time
   the system is reset.  On a general-purpose device (with a general
   purpose operating system), it identifies a specific instantiation of
   the syslog sender process.  In such an environment, it may be a
   process ID.

   The dash ("-") is a reserved APP-INST field value that MUST only be
   used to indicate an unidentified instance.

   APP-INST is primarily meaningful for analysis tools.  Properly used,
   it should enable log analyzers to detect which messages were
   genereted by the same sender instance.  For example, on a UNIX system
   the syslog daemon (syslogd) might emit messages to the log.  All
   messages logged by the same instance of syslogd will bear the same
   APP-INST (for example its process ID).  When the syslogd is
   restarted, the APP-INST changes.  That enables the analysis script to
   detect the syslogd restart.  This information might be used to detect
   unexpected restarts and/or provide some judgement over the
   reliability of the received messages.
####

Rainer
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec