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

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 6 May 2005 18:14:54 +0200

Clément,

you are right, vendor extensions are covered by the "x-" rule. I have changed the confusing text as follows:

####
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-".  The first character MUST NOT be
   anything other than "x" if the second character is a hyphen ('-').
   The same SD-ID MUST NOT exist more than once in a message.
####

This text reserves all names with a hyphen in the second position and declares everything invalid, except those that have a "x" in front of the hyphen.

We could alternatively say that the full name space can be used and is controlled by IANA, with the exception of SD-IDs starting with "x-", which are reserved for vendor use. In this case, the "x-" header would delegate part of the name space.

Any comments on this?

Many thanks,
Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Clement MATHIEU
> Sent: Monday, May 02, 2005 7:57 PM
> To: [email-masked]
> Subject: Re: [Syslog-sec] Syslog protocol 
> draft(draft-ietf-syslog-protocol-11.txt)
> 
> Le lundi 02 mai 2005 à 08:47 -0700, Alexander Clemm (alex) a écrit :
> 
> > 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?    
> 
> 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
> 
> _______________________________________________
> Syslog-sec mailing list
> [email-masked]
> http://www.employees.org/mailman/listinfo/syslog-sec
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 6 May 2005 18:37:57 +0200

Alexander,

Many thanks for the good points. Please see my comments inline below. 

Rainer

> Alexander Clemm (alex)
> Sent: Monday, May 02, 2005 5:47 PM
> Subject: [Syslog-sec] Syslog protocol 
> 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.)

Relay operations were explicitely excluded from the -protocol draft. There might come up a specific ID just for this. The list in section 4 is not meant to cover all potential scenarios, just to give an idea. Of course, I can add the scenario you mentioned if you think that would make it easier to grasp.

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

The order of fields was initially kept as consistent with RFC 3164 as possible. Over time, the value in this is actually becoming very weak. If there is support, we could move some fields to make them look "more natural".

> - Why would facility consist only of digits, not alphanumeric 
> characters

This was done for historical reasons, too. Numeric facilities worked well. However, the format has much been modified since it was initially introduced. I stil think numeric facilites help us preserve some of the momentum that syslog has (it makes it look somewhat more similar to folks used to current syslog). But I wouldn't object if there is really strong support for alphanumeric facilities.

> - 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?  

This has been discussed many times. For a recent discussion please see

http://www.syslog.cc/ietf/autoarc/msg01406.html

Some pointers can also be found here (I didn't manage to keep the web page updated through all the discussions):

http://www.syslog.cc/ietf/protocol/issue16.html

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

This was discussed in great length over the past month. A pointer to the early discussion is here:

http://www.syslog.cc/ietf/protocol/issue11.html

If you search the archive (http://www.syslog.cc/search/search.html) for "message size", "multi-part messages" and "fragmentation" you will find plenty of reading.

The -03 draft had a complete section on those messages: http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-03.txt

Further discussion indicated the concensus that fragementation/multi-part messaging should not be done at this layer. Even further discussion indicated no interest in messages with a larger size.

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

I have to admit that I have not good enough knowledge to suggest anything in this regard. I see the utility of defining the relationship, but the text was thankfully provided by Sharon Chisholm. 

Sharon, can you comment on this?

> character (for example, the underscore character) for the SD-name that

Clément commented correctly that "x-" is reserved for vendor extensions. Please see separate post.

> --- Alex