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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 17 Mar 2005 16:02:09 -0500

hi

Here is part one of my response ....

<Rainer>
> 
> G2 - Not much is said about change control and backwards
> compatibility other
> than the discussion buried in  A.2 which seems to imply there 
> isn't any. I
> propose the following:
> 
> G.2.1. Make a statement to set expectations about change
> control within the
> body of the document.
> 
> G.2.2. Suggest two levels of expectations - one for the
> header, which is
> governed by the version number and one for the SD-PARAMs 
> which should be
> somewhat independent of it. I recommend that people try not 
> to break things
> in the SD area within a version and between versions. Same 
> name has same
> general semantics. If not a MUST, this needs to be a SHOULD. 
> I vote for
> MUST.

I added some descriptive text to 6.2.1 (VERSION). But I think it already
covered that no header modifications are allowed. So some folks on this list
might reject this as a duplicate.
</Rainer>

I think the only duplication in the text is in the way it was phrased.
Suggest the following replacement.

"The VERSION field denotes the version of the syslog protocol
   specification.  The version number MUST be incremented for any new
   syslog protocol specification that changes any part of the HEADER
   format.  Changes include addition or removal of fields or a change 
   syntax or semantics of existing fields. This document uses a VERSION
   value of "1".  The VERSION
   values are IANA-assigned (Section 10.1). "

<Rainer>
For STRUCTURED-DATA, I have added the following new section:

###
6.3.4  Change Control

   Once SD-IDs and PARAM-NAMEs are defined in a specification and their
   IANA assignment has been done, syntax and semantics of these objects
   MUST NOT be altered.  So they begin to exist with their initial
   definition and are never allowed to change.  Should a change to an
   existing object be needed, a new one MUST be created.  It is advised
   to use a name the reflects the close relationship between the two
objects.
   For example, if the semantics of the "tzKnown" PARAM-NAME were to be
   changed, a good name for the new element would be "tzKnown2". ###

</Rainer>

This behaviours should not be made so specific to the ones allocated by
IANA. And the bit about the naming does not seem necessary. 
Suggest the following replacement:

"  Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of these
objects
   MUST NOT be altered.  Should a change to an
   existing object be desired, a new one MUST be created and the old one
remain unchanged."

<Rainer>
> S1. In section 6, what is the relationship between Facility
> and MSG-ID? They
> seem to serve the same purpose. Is Facility just historical? 
> Is MSG-ID what
> we need to use moving forward? (see G3)

I added this text to the description of FACILITY:

####
It is RECOMMENDED that the facility
reflects a type of subsystem, something that a number of different messages
might be issued from. So it is a kind of corase group. ####

Does this clarify? Do we need to add similar text to MSGID (in that it
identifies a specific message)? To keep it short, I've not done this yet.

</Rainer>

Now I'm left wondering how this relates to a category. 

<Rainer>
> 
> S2. Is the length of SENDER-NAME and SENDER-INST sensible?
> SENDER-INST seems
> way too short. Consider needing to name something which is 
> the concatenation
> of two IP addresses. It does not fit. Remember this is the 
> encoding the
> string, not the integer. We will end up forcing people to 
> make up something
> which does fit instead of using something existing.

Actually, SENDER-NAME and -INST are not meant to be IP addresses. We have
HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should identify the type
of sender, most probably a process name or something similar (like
"postfix", "su" in current messages in TAG). I think the size is sufficient
for this purpose. Given the size limitation we have in UDP based syslog, I
would like to keep the HEADER size as small as possible. Obviously, we
should not sacrifice things for a short size, but I think we do not need the
longer sizes here.
</Rainer?

I think you misunderstood my example. This was not the IP address of the
originator, but a pair of IP addresses that indicated the instance of
something which is referenced using a set of (different) IP address. What
exactly is a 'process name' suppose to be in IETF land? While I appreciate
the need for backwards compatibility with deployed syslog, I think we need
to understand how this naming can be used in a router and how it maps to
traditional IETF naming. I think some of the more intuitive ways we have to
name things won't fit in the size indicated. Or is instance really not an
instance and that is the disconnect?

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Mar 2005 18:20:35 +0100

Sharon,

many thanks for the comments. Special thanks for the text suggestions,
which are very helpful. Please browse through this post, the main
questions are towards the end of it.

I will try to follow up at least your second post tomorrow. After that,
I am out of office for the week after easter (until april, 4th).

Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Sharon Chisholm
> Sent: Thursday, March 17, 2005 10:02 PM
>
<Sharon>
>    values are IANA-assigned (Section 10.1). "
</Sharon>

changed

>    changed, a good name for the new element would be "tzKnown2". ###
<Sharon>
>    existing object be desired, a new one MUST be created and 
</Sharon>

changed

> identifies a specific message)? To keep it short, I've not 

<Sharon>
> Now I'm left wondering how this relates to a category. 

</Sharon>

Yes, you are right. It is a category. But it is not a fixed one, the
administrator can assign it.

How about this text:

####
6.2.2  FACILITY

   FACILITY is an integer in the range from 0 to 2,147,483,647.  It can
   be used for filtering by the receiver.  It is a category, allowing a
   corase grouping of messages.  There exist some traditional FACILITY
   code semantics for the codes in the range from 0 to 23.  These
   semantics are not closely followed by all senders, and practice has
   shown that common semantics for message categories are hard to
   establish.  Therefore, no specific semantics for FACILITY codes are
   specified or implied in this document.

   There is no relationship between MSGID (Section 6.2.8) and FACILITY,
   because MSGID identifies a specific message whereas FACILITY
   specifies a corase message group and is expected to be operator
assigned
   most-often.
####

We could add an example that MSGIDs 1000 to 2000 could have a specific
FACILITY assigned to "authentication realted messages" where MSGId 2001
to 3000 have a specific FACILITY assigned to "linkUpDown messages".

A key point is that FACILITY is often operator assigned (as it is
currently) and the operator uses this mostly for filtering. In
real-world case of Unix syslogd, facility often tells syslogd the log
file a message is to be written to. So it is extremely common that this
is customized.

> should not sacrifice things for a short size, but I think we 
<Sharon>
> instance and that is the disconnect?
</Sharon>

Probably you are right, this is the disconnect. An instance in my point
of view is something that others might call a reboot ID. It is a number
or string that identifies a given "incarnation" of a the syslog sender.
Let me provide some examples:

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
OS), it identifies a specific instantiation of the syslog sender
process. To use an easy to grip real world example: when you start
syslogd on Unix, the first one is instance 4711 (whatever the actual
number is is irrelevant). Then you stop syslogd and restart it. Now its
ID is 8753 (again, the actual value is irrelevant). I am saying the
actual values are irrelevant because duplicates might occur (after
another restart, syslogd might again have 4711 - even on successive
restarts it might get the same ID). This field is meant as a shortcut to
identify a new "instantiation", but not a definite or formal ID.

Does this bring us any further?