[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part 1
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: syslog-sec-bounces@www.employees.org
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> Sharon Chisholm
> Sent: Thursday, March 17, 2005 10:02 PM
>
> 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>
>
<Sharon>
> 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). "
>
</Sharon>
changed
>
> <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>
>
<Sharon>
> 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."
</Sharon>
changed
>
> <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>
>
<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.
>
> <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?
>
<Sharon>
> 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>
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?
>
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec