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

"Reinaldo Penno (repenno)" <repenno@cisco.com> Fri, 03 May 2013 01:58 UTC

From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "behave@ietf.org" <behave@ietf.org>, David Harrington <ietfdbh@comcast.net>
Thread-Topic: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters
Thread-Index: AQHOR5qLxG8kIZ+LcU+tQGjun+gyWJjzA32A///SEYA=
Date: Fri, 03 May 2013 01:57:54 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409062ADD@xmb-rcd-x04.cisco.com>
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D023250E321@xmb-rcd-x15.cisco.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B0AE07E148B99444A4C4E32D5C4855AB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters
Precedence: list

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] SYSLOG strategy for organizing NAT loggi… Tom Taylor
Re: [BEHAVE] SYSLOG strategy for organizing NAT l… Senthil Sivakumar (ssenthil)
Re: [BEHAVE] SYSLOG strategy for organizing NAT l… Reinaldo Penno (repenno)
Re: [BEHAVE] SYSLOG strategy for organizing NAT l… Chris Lonvick