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

Reply via email to