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

Hi,

The thought that went into structured data in RFC5424 was to keep it 
simple for the sender to put together, and easy for the receiver to parse. 
The latter is especially critical if the receiver is going to immediately 
parse the message upon receipt.  If anyone is interested, John Kelsey 
wrote some things about that in Section 7 of RFC 5848, "Signed Syslog 
Messages".

I'd also agree that B gives the most flexibility.

Thanks,
Chris

On Thu, 2 May 2013, Reinaldo Penno (repenno) wrote:

> I agree Senthil's proposal.
>
> On 5/2/13 10:42 PM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
> wrote:
>
>> 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" <tom.taylor.stds@gmail.com> 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
>>> Behave@ietf.org
>>> https://www.ietf.org/mailman/listinfo/behave
>>
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>