Subject: [Syslog-sec] Syslog protocol draft (draft-ietf-syslog-protocol-11.txt)

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 2 May 2005 08:47:23 -0700

Resending due to apparent mailer problems, apologies if you receive multiple
copies

Hello,
 
I am currently going through the syslog protocol draft,
draft-ietf-syslog-protocol-11.txt.  A couple of thoughts, suggestions,
topics for discussion:
 
Basic principles (section 4):  May want to clarify:  Will relays be allowed
to send messages to multiple receivers?  (Not listed as one of the
scenarios.)  May relays alter a message?  (Currently, yes, at least with
regards to truncation; should be explicit in discussing what aspects of a
message may and what aspects may not be altered.)
 
Required syslog format:  There are essentially 3 parts of the message which
identify the originator of the message, not even counting the host name:
Facility, App-Name, Proc-ID.  
- Should they be grouped together - why separate them for example with the
truncate field - may want to take a look at the order of the fields.  I
would think that the truncate field should in fact either appear after the
version field, or right before the structured data field.  
- Why would facility consist only of digits, not alphanumeric characters
- Are three fields really needed?  It seems that it makes sense to allow to
identify the type of the subsystem or application that generates the syslog
message, as well as the particular instance in case there are several.  This
makes two fields.  Why a third field?  
 
Concerning message length: would it make sense to allow for a means by which
messages could be fragmented, as an option in addition to truncating?  This
could be addressed by having standard structured data elements that specify
a message as part 1 of 2, for example.  Of course, with regards to relays it
may imply that messages may need to be altered by relays accordingly.  
 
Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that
lists the corresponding relation.  Also, really the proper reference to use
is probably the ITU specification, X.733.  
 
The structured data  is an extremely important concept, as this provides for
extensibility and separates the "core" fields from the "extension" fields.
For the structured data, would it make sense considering to reserve a prefix
character (for example, the underscore character) for the SD-name that
should not be used for vendor-defined SD elements, so that if later
extensions to the syslog protocol are standardized in form of new SD
elements there won't be conflicts - or vice versa, to require vendor
extensions to start with it?    
 
--- Alex
 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: Clement MATHIEU <[email-masked]>
Date: Mon, 02 May 2005 19:56:49 +0200

> extensions to start with it?    

Please correct me if I am wrong but i think this issue is already
addressed.

>From grammar:
      STRUCTURED-DATA = *SD-ELEMENT / "-"
      SD-ELEMENT      = "[" SD-ID 0*(1*SP SD-PARAM) "]"
      SD-ID           = SD-NAME
      SD-NAME         = 1*32OCTET ; VALID UTF-8 String
                        ; except '=', SP, ']', %d34 (")

---------------- draft 11 -------------------
6.3.2  SD-ID

   IANA controls ALL SD-IDs without a hyphen ('-') in the second
   character position.  SD-IDs are case-sensitive and uniquely identify
   the type and purpose of the SD-ELEMENT.  Experimental or vendor-
   specific SD-ID MUST start with "x-".  Anything that doesn't is
   managed by IANA.  The same SD-ID MUST NOT exist more than once in a
   message.
----------------------------------------------

To my understanding a vendor-defined SD-ID can not conflict with a
standardize one. 

BTW, i find 6.3.2 quite unclear. Firstly we say that IANA controls all
SD-ID without a - in second position.

	IANA controlled:
		plop
		foo-bar
		42

	(probably) Not IANA controlled:
		z-yyyy
		a-b-c

Then we add "Anything that doesn't is managed by IANA.". So, finally,
"z-yyyy" and "a-b-c" are controlled by IANA...

Confusing isn't it ?

Theses two sentences are not contradictory; the second one defines a
larger set of SD-ID.

Am I wrong ?
	
Clément MATHIEU

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 3 May 2005 14:52:01 -0700

Hi, 

please see my response below, at the bottom of the message

--- Alex

-----Original Message-----
From: Clement MATHIEU [mailto:[email-masked]] 
Sent: Monday, May 02, 2005 10:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Syslog-sec] Syslog protocol
draft(draft-ietf-syslog-protocol-11.txt)

[...]

---------------- draft 11 -------------------
6.3.2  SD-ID

BTW, i find 6.3.2 quite unclear. Firstly we say that IANA controls all SD-ID
without a - in second position.

	IANA controlled:
		plop
		foo-bar
		42

Confusing isn't it ?

Theses two sentences are not contradictory; the second one defines a larger
set of SD-ID.

Am I wrong ?
	
Clément MATHIEU

**** Response Alex
Clement,
thanks for clarifying.  The "hypen" part of the specification escaped me.
Yes, I agree the wording needs to be clarified.  Specifically, what is it
that IANA controls - everything without a hyphen in the second character
position, or anything that doesn't start with "x-"?  I would think the
second one is too restrictive.  That is, everything with hyphen in the
second position is proprietary, everything that is not, is not.  If you want
to reserve further characters such as "x" for experimental purposes, then so
be it, but not ALL characters except one should be reserved.  Otherwise,
this may result in a a tendency of proprietary SD IDs to get longer than
otherwise necessary, and there is probably value in keeping things compact.