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

["Sharon Chisholm" <schishol@nortel.com>]

hi

Part II of my response

<Rainer>
> 
> S3. In section 6.1, we need some guidelines on how to truncate 
> SD-BOUNDARIES. Can the structured data become non-compliant or must it 
> still be valid? If
> within the message part, is it just arbitrary?  Should we indicate
> truncation has occurred in the header or at the very end of 
> the message? Do
> we need to leave room for some extra characters at the end to 
> signify the
> message has been truncated?

This is being discussed in a separate thread.
</Rainer>

I'll respond to the separate thread


<Rainer>
> 
> S4. In section 6.1, this should really only recommend
> truncation. Delete the
> bit about dropping the message or indicate that it is only 
> dropped when
> truncation cannot result in a valid message. That assumes we 
> think that is a
> possibility, if not, lose the bit about dropping all together.

I am not fully with you here. The "drop it" rule was added for receivers in
embedded devices. Among others, it was argued that it might not be possible
to receive the full message. Though we currently do not have a trailer, it
can be argued that in this case the trailer could not be received and thus
not only the payload, but the message itself would be truncated. It was
assumed that embedded devices might prefer to drop the message instead of
truncating it.

Also, with the UDP transport, it is sheer reality that messages can be
dropped on the network, especially if the network itself is experiencing
troubles. So allowing a device to drop a message larger than 480 bytes
could/should encourage implementers to keep them shorter than that.

Of course, it can be argued that this is something that should be moved to
security considerations or implementers notes - where it also is present.
The two arguments together, however, seem to justify the "drop rule". I have
to admit, though, that I am not very strong with this argument. If you feel
this is really bad, please press again for change, I think a good argument
can break my current one.

</Rainer>

What we need to get to is predictability. I had suggested that the only
reason to allow a message to be dropped would be in the case that truncation
can not be performed in a manner that could result in a valid message. You
have suggested a second, where the system has enough resources to process
messages to a given MTU, but not enough to perform truncation. I'm not sure
how valid this case is, but if we feel it is, then we should phrase it in
these sort of terms to increase the predictability of it all.

<Rainer>
> 
> 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>
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'.
"

<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>

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?

<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>

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 Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec