Re: [openxdas-devel] Discussion about changes to specification

[Wayne H. <wh...@no...>]

Although having comma separated <idname>=3D<idvalue> pairs in the =
correlation id field is more flexible, it adds complexity when parsing or =
analyzing the data. I suspect one string value for the correlation id will =
be fine for most of the applications. In a database's term, every record =
has only one primary key that serves to correlate the records within =
tables, even though there may be other unique keys that identifies the =
same record. Application can create a compound correlation id with the =
xdas naming format or store other unique keys in the EVT section for this =
type of scenario. They can even stores the <idname>=3D<idvalue> pairs. My =
point is not to impose any rule on this field.=20

In the database logger, this will make querying the data tables easier. =
For example, if I want to find a series of actions of a perticular =
workflow request, I can just do "select * from table_name where correlation=
_id =3D '<request_id_value>'.

A free form, <idname>=3D<idvalue> pairs in the correlation if field will =
make this type of query harder to write.

Wayne Hsu
Senior Software Engineer,
eXtend Engineering
(703) 967-4980
Novell, Inc., the leading provider of Net Business Solutions.
www.novell.com


>>> "David Corlette" <dco...@no...> 04/19/07 12:38 PM >>>
Hi Wayne,

Yes, that's fine, but mostly I'm curious what kind of event interrelationsh=
ips people expect to see.  This in part is because on the backend Sentinel =
would split the data off into separate fields for easy filtering, most =
likely.

>>> On Thu, Apr 19, 2007 at 10:01 PM, Wayne Hsu wrote:=20
> Are we confined to these names for the Correlation only? I thought the =
field=20
> is extensible, therefore, instrumenation application can use whatever =
names=20
> that make sense within its domain, be it sessionid or auid, as long as =
it=20
> follows the name=3Dvalue format.
>=20
> Wayne Hsu
> Senior Software Engineer,
> eXtend Engineering
> (703) 967-4980
> Novell, Inc., the leading provider of Net Business Solutions.
> www.novell.com
>=20
>=20
>>>> "David Corlette" <dco...@no...> 04/13/07 7:43 PM >>>
> John,
>=20
> I agree with what you are saying, exactly.  Correlation has a slightly=20=

> broader meaning in the context of Sentinel, but the use of that word =
here -=20
> e.g. to help us correlate between several related events - is perfect.
>=20
> As for the field format, that also works for me.
>=20
> So far we seem to have come up with:
> sessionid
> processid
> threadid
> requestid
>=20
> I notice that the LAF (SuSE Linux audit framework) uses "auid" -  but=20
> perhaps this could be considered a "sessionid" or "requestid"?
> Anyone else care to comment?
>=20
>>>> On Sat, Apr 14, 2007 at 12:58 AM, in message=20
> <461...@no...>,
> John Calcote wrote:=20
>> Okay, I see now.=20
>> =20
>> You called it instanceid, but in reality, it's a form of general =
purpose=20
>> correlation id, right? I think the concept of correlation id is =
generic=20
>> enough (regardless of the domain) to put it into the HDR section.=20
>> Furthermore, why not define some standardized correlation id types, =
and=20
> apply=20
>> them within a single field in the HDR section?=20
>> =20
>> For instance, you called it instanceid, but that could mean anything. =
Why=20
>> not have a field in the HDR section called <correlation> whose format =
is comma=20
>=20
>> separated <idname>=3D<idvalue> pairs. For instance:
>> =20
>> sessionid=3D096v432lkna9er8h42okn,processid=3D12345,threadid=3D27
>> =20
>> That way, we can add id types as we see the need - the field is =
extensible,=20
>> like the event data field, but it is specialized enough, and globally=20=

>> important enough to warrant its own field, and is generic enough in =
nature=20
> to=20
>> events in general to warrant a place in the HDR section.
>> =20
>> From an API perspective, header information is VERY controlled - most =
of it=20
>> is self generated. That is, not specified by the caller, but rather by =
the=20
>> XDAS client library. This is not always true, but where it's not true - =
as=20
> in=20
>> the cases of (eg) event number and outcome code - the client API =
provides=20
>> well-defined functions to set those values and ensures that they =
conform to=20
>> the XDAS standard. We would want to provide similar additions to the =
API to=20
>> set correlation information, and we would want to auto-generate some of =
the=20
>> more obvious id values such as process and thread. The auto-generated =
values=20
>=20
>> could be policy controlled by configuration file entries.
>> =20
>> Whereas event data is very free form and user-defined/specified, =
correlation=20
>=20
>> information is very controlled.
>> =20
>> I believe correlation information is important enough to warrant this =
sort=20
>> of management. What do you think?
>> =20
>> John
>>=20
>>>>> On 4/12/2007 at 7:04 PM, in message <461...@no...>=
, David=20
> Corlette <dco...@no...> wrote:
>>=20
>> Hi John,
>>=20
>> I debated about this - I think the Instance ID will be wildly useful =
outside=20
>=20
>> the EVT structure (NVP) as a way of connecting multiple events together =
into=20
>=20
>> a stream of related events.  So I *absolutely* think that it needs to =
have=20
>> its own field, and I think it can be domain-specific as to the meaning =
of=20
> the=20
>> ID (NAM, for instance, creates some sort of connection ID which is =
opaque,=20
>> but would serve this purpose).
>>=20
>> As for putting it in EVT, I don't actually care - HDR seemed to be =
more=20
>> information about the structure of this event, not actually any event =
data. =20
>=20
>> But I could see pulling it up to that level as well.
>>=20
>>=20
>>> May I ask why you've decided to add this value here? Event Data has a =
very=20
>>> well-defined format: comma separated name=3Dvalue pairs. You could =
have=20
>>> specified that instanceid be added as a well-known name/value pair. =
Better=20
>>> still, if it's supposed to be a process id, then simply call it=20
>>> processid=3Dxxx, as a well known name/value pair. The standard doesn't =
define=20
>>> any well-known name/value pairs today. If it's something that is =
really=20
>> useful=20
>>> in all cases, perhaps we should consider adding it to the HDR section.
>>=20
>>=20
>>=20
>=20
>=20
> -------------------------------------------------------------------------=

> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> openxdas-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxdas-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
openxdas-devel mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openxdas-devel