Re: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters

["Senthil Sivakumar (ssenthil)" <[e-mail]>]

Option b would be my preference, as it seems the most straight forward
approach, 
easy to understand and implement.

Senthil

On 5/2/13 9:07 PM, "Tom Taylor" <[e-mail]> wrote:

>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
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave