[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Syslog-sec] Sender-INST
hi
I think you just need to add some of this text to the document. It seems
that this field is not terribly useful to me, but perhaps for other
applications.
Also, renaming the field should help.
Sharon
----------
<Rainer>
>
> <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?
</Rainer>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec