Chris,
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 20, 2006 3:37 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog]
clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Hi Rainer,
Ahh.. I see your point now. (Sorry - being a little slow this week.)
All: I'm tending to agree with Rainer's point that no value should be
specified for APP-NAME. Does anyone think that the document should
suggest something for fixed-function devices such as printers which
might
not have a syslogd? Currently syslog-protocol allows a NILVALUE if
nothing better can be used.
I think they should use whatever the use with other messages. For
example, they might use router. Sure, this is not intelligent. But my
point is that this should not be of concern for syslog-sign.
Similarly, PROCID may be NIVALUE in syslog-protocol if the device
cannot
produce it. I'm OK with that for syslog-sign as well.
Finally, I'd still like to keep sig for the MSGID. This should
allow
for parsers (automated and manual searches) to find syslog-sign
messages
quickly.
I do not object it, as long as we caution implementors that a MSGID of
sig does not necessarily indicate this is a syslog-sign message. We
can not guarantee that, because we did not reserve any message ids at
all. So it may be a clue, but it is nothing to rely on. Which brings me
to the point: what is the advantage of an unreliable indicator?
This won't be the only mechanism to identify a syslog-sign
message. I believe that a syslog-sign message would have to:
- be sent to PRI = 110
- have MSGID = sig
- contain an SD-ID with the SD-PARAM of ssign or ssign-cert
I don't think that we need a registry of MSGIDs for this.
For me, the SD-ID is the only valid indicator that this is a syslog-sign
message. We can not rely on PRI as operators like to reconfigure PRI.
Even if we mandate a fixed PRI in the specification, real-world
implementations will ignore that requirement and still allow the
operator to override it (and this for a good reason). On the other hand,
SD-IDs *are* under IANA control and the absolutely positively identify
the element that they are contained in. This is what we designed them
for. So why not use them for their design purpose?
With RFC 3164 syslog, we obviously can not totally be assured that the
SD-ID will be valid. But we should keep in mind that we most probably
will try to obsolete 3164 either via -protocol or a follow-up RFC. I
already questioned the point in supporting this (informational!)
document in a new standard. Is this really a wise idea?
Rainer
If anyone has issues with any of this, please speak up now. I'd like
to
get this settled so we can update and send this to the IESG when the
WGLC
ends.
Thanks,
Chis
On Tue, 19 Dec 2006, Rainer Gerhards wrote:
Chris,
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 10:18 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] clonvick WGLC Review of
draft-ietf-syslog-sign-20.txt
Hi Rainer,
On Mon, 18 Dec 2006, Rainer Gerhards wrote:
Hi,
So far, I have not been able to do a full review. But this
triggers my
attention immediately...
Perhaps restructure that as:
A Signature Block message that is compliant with RFC
[14] MUST
contain valid APP-NAME, PROCID, and MSGID fields.
Specifically, the
value for APP-NAME MUST be syslog (without the
double quotes).
The value for MSG-ID MUST be sig (without the double
quotes). The
value for the PRI field MSUT be 110, corresponding to
facility 13
and severity 6 (informational). The Signature Block
is carried as
Structured Data within the Signature Block message, per the
definitions that follow in the next section.
Similar in Section 5.3.1.
Syslog-protocol does not reserve any specific values for APP-NAME,
PROCID and MSGID. So (at least theoretically), another
implementor migth
use the suggested values for any other case.
As an implementor, I would probably like to consistenly use the
same
APP-NAME. For example, all messages in rsyslog will be logged as
rsyslogd.
I have just quickly read the IANA section (9.1): there is no such
registry like APP-NAME. It might eventually be a good
idea to create
one, but I am not sure if it is worth the trouble. In any
case, I think
that must be spelled out in -protocol (else I can implement
somthing
compliant to -protocol but not -sign). Same goes for MSGID.
My recommendation (without a full read of the document...)
is to remove
any dependencies on APP-NAME, PROCID and MSGID and use
structured data
fields for them. Otherwise, I foresee that I need a lot of
hardcoded
exception inside a syslog implementation to mangle this
fields so that
