RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt

2006-12-19 Thread Chris Lonvick

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
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; 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.





--

Version field: I recommend renaming it to something like Sig-Version
to avoid mistaking -protocol VERSION and -sign Version.


There are actually two Version fields.  The first is an SD-Param called 
VER in the SD-ID of ssign.  The second is an SD-Param, also called 
VER, in ssign-cert.  This type of duplication is acceptable in the rules 
of syslog-protocol.  I can't think of any way that it could be confused 
with the version number in the header of the syslog message.




--

I hope I will be able to do a full review by the end of the week.


Looking forward to it.

Thanks,
Chris

___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog


RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt

2006-12-19 Thread Rainer Gerhards
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
  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