[BEHAVE] SYSLOG strategy for organizing NAT logging event parameters

[Tom Taylor <[e-mail]>]

In organizing the encoding for the SYSLOG approach, I need to decide how 
to define the structured data elements. Each such element is identified 
by an SD-ID and contains a specified set of parameters.

I have eight events in all (including "invalid port detected"), and 
twenty different parameters. The accounting is a little different from 
IPFIX because some IPFIX parameters end up in the SYSLOG headers 
instead. One parameter is common to all of the events, a few are common 
to at least four of them, and the rest are more scattered. There may be 
some reconciliation required when I submit the SYSLOG update.

The question is how to define the structured data elements. Here are the 
possibilities:

(a) define only one structured data element, within which all parameters 
are optional from the point of view of SYSLOG, but individual parameters 
may be mandatory from the application point of view depending on the 
event type. Every event would use the same structured data element.

(b) define one structured data element per event, with mandatory and 
optional parameters as required. The same parameter would then be 
registered formally with IANA once for each event using it.

(c) variation on (a): partition the parameters amongst multiple 
structured data elements, more than one of which may be needed to make 
up a complete event report. One possible use is to group parameters 
relating to a given NAT type. The disadvantage is a bit longer log 
lengths because of the additional structured data headers.

Are there any opinions on all this? SYSLOG is defined in RFC 5424.

Tom Taylor