Question about Event Log (object 20) data format

[sbernard31]

Recently, I took a look at Event Log object (id 20) :

• v1.0.1
• v2.0
• v2.1

And I think that maybe there is issue with log data format ?

My current understanding is that a standard aim to allow interoperability.
In case of Even Log object, to be really interoperable, the LogData ressource format should be clearly defined.

Looking at specification :

ID	Name	Operations	Instances	Mandatory	Type	Description
4014	LogData	R	Single	Mandatory	Opaque	Read Access on that Resource returns the Data Collection associated to the current Object Instance.
4015	LogDataFormat	RW	Single	Optional	Integer	when set by the Server, this Resource indicates to the Client, what is the Server preferred data format to use when the LogData Resource is returned . when retrieved by the Server, this Resource indicates which specific data format is used when the LogData Resource is returned to the Server 0 or Resource not present : no specific data format (sequence of bytes) 1 : OMA-LwM2M TLV format 2 : OMA-LwM2M JSON format 3: OMA-LwM2M CBOR format [4..99] reserved [100..255] vendor specific data format

The only "not vendor" specific data format (so which allow interoperability) are :

1. OMA-LwM2M TLV format
2. OMA-LwM2M JSON format
3. OMA-LwM2M CBOR

But I have strictly no idea what could mean to use that format to encode logs ?
Those format are used to encode LWM2M Nodes (Object / Object Instance / Resource / Resource Instance) not for logs ?

There is an example in the specification :

Resource Name	Resource ID	Value	Notes
LogDataFormat	4015	1	OMA-LwM2M TLV format
LogData	4014	61-7C-E3-01-C1-11- 00-00-05-00-60-18- 18-18-0C-00-01-41- 06-00-02-00-40-0C- 00-00-00-00	4545> 2017/8/1 0:46:37.803 - NAS_DBG_TIMER: (00:00:31.685729): LAYER_NAS => LAYER_NAS: action: (TIMER_STOP), prim_id: (EMM_T3410_TIMER_EXPIRY_MSG), duration: 0x00 (0)

So I tried to decode 617CE301C11100000500601818180C00014106000200400C00000000 using a TLV decoder hoping this will help me to understand but the TLV seems invalid.. and the "notes" doesn't help to understand how TLV should looks like...

So I would appreciate some clarification about that. 🙏

To be totally honest instead of LWM2M data format to encode logs, I was expected more commonly used one like :

• Common Log Format CLF
• Syslog Format : RFC5424
• or even a very simple format defined specifically for this object using plain text, json and/or cbor.

Maybe :

//  JSON
{
  "timestamp": "2023-10-26T15:34:12Z",
  "level": "INFO",
  "message": "Request received for product with ID 123",
}

// PLAIN TEXT
TIMESTAMP LEVEL MESSAGE
2023-10-26T15:34:12Z INFO Request received for product with ID 123

[mkgillmore]

@sbernard31 This proposed change could be achieved with a new EventLog object or adding an optional resource to the existing object 20. Do you have a preference?

[sbernard31]

@mkgillmore I"m not sure how do you solve this issue with an optional resource ? Could you describe a little bit your idea 🙏

[mkgillmore]

Your options are 1) add an additional optional resource 2) create a new object. FYI, OMA feels changing EventLog data format will break backwards interoperability

[sbernard31]

I'm sorry I still don't get it.
I understand that creating a new object could solve the issue. (but maybe a bit overkill)
But I don't get how adding an optional resource could solve that ? If you describe that new resource usage maybe I will understand 🙏 .

OMA feels changing EventLog data format will break backwards interoperability

I'm not so sure of that.
I mean we already have a resource which contains the log format and another the log content.
Could we just add a new format using reserved range [4..99]
Naively I was thinking this exist on that purpose ?