Re: CEE Field List

> Dear All,
>
>  Let me break it down:
>
>
>  >Feb 22 08:57:21
>
> This is the date and time when the request is performed. For
>  consistency if the other fields are formatted something=something
>  else, this should be
>  datetime=Feb 22 08:57:21
>
>  >ram sudo[11033]:
>  I assume this is the agent of the request. For consistency
>
>  agentid=ram sudo[11033]
>
>  If we want the syntax to be universal, perhaps an agentdirectoryid
>  would be desirable, as other systems might have their own "ram
>  sudo[110033]"
>
>
>  >src_ip=10.2.2.1
>
> I assume this is the address of the agent. I suppose MAC address (and
>  other types) can be logged as well, so I suggest:
>
>  agentaddress=10.2.2.1
>
>  >dest_host=ram
>  This must be the address of the subject/resource of the request.
>
>  I'd write subjectadddress=ram or resourceaddress=ram
>
>  If we want the syntax to be universal, perhaps an resourcedirectoryid
>  or subjectdirectoryid would be desirable, as other systems might have
>  their own "ram"
>
>  >name=what an event
>  "name" is not very explicit, I suggest:
>  requesttype=what an event
>
>  >dvc_location=home
>  This must be the id of the subject/resource of the request.
>
>  I'd write either subjetcid=ram or resourceid=ram
>
>
>  >  - is the list more or less complete?
>
> I'd like to have a field to store a "serial number", a requestid
>
>  The event can be logged by the subject, the object or a third party
>  (listener). I would add fields than can distinguish that.
>
>  If user/password or other credentials are necessary to perform the
>  request, I would add fields than can express that.
>
>  I would add fields for the payload, for a signature and for a hash
>
>
>  >  - do the data types make sense?
>
> What do you mean exactly? For example datetime does not seem
>  universal, some systems might use more digits for subsecond
>  divisions...
>
>
>  >  - how should we handle lists of values? For example, an event might
>  >  talk about multiple ports.
>
> That should go in the payload.
>
>  >  - any other comments?
>  The request can be successful, fail or an error can happen. I would
>  add a field for the result of the request, and a separate field for
>  the associated message.
>
>  I feel excluded too, BTW
>
>  Best Regards
>
>
>  Vicente
>