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.
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. 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.
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 xxxx
[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
the happen to be right for -sign while they are invalid
from the overall
application point of view.
We're going to have "ssign" and "ssign-cert" as the SD-IDs used for
syslog-sign. I don't think that there are any dependencies
on APP-NAME,
PROCID and MSGID for the proper working of syslog-sign;
From the quoted text above:
value for ####APP-NAME MUST be "syslog"#### (without the double
quotes).
The value for ####MSG-ID MUST be "sig"#### (without the double
If APP-NAME and MSG-ID *MUST* contain something specific, I think there
is a strong dependency.
they're just there
to make sure that these messages are placed consistently into
the right
bins. The "ssign" and "ssign-cert" SD-IDs will be reserved for this.
I do not see how this addresses the concerns I mentioned above. I can
not implement it without interfering with my application design in a way
that I do not find justified. How does mandating a specific APP-NAME and
MSG-ID make sure that they are put into the right bins? Many stock
syslogds can not even filter on these fields...
Rainer
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
