Re: [core] Questions/comments on draft-ietf-core-dynlink-02

[Michael Koster <[e-mail]>]

OK, that makes sense.

Do you think there is still a use case for a simple implementation (as I did in ARM mbed) that only keeps a single set of attributes?

Should we support both the global setting and a per-observe override?

Or should we deprecte the single attribute set and only support per-observe attributes going forward?

FWIW, There is another SDO that is in the process of specifying an optional (single) setting for each resource instance, using a "composed" resource.

Best regards,

Michael

> On Mar 13, 2017, at 8:05 AM, Mojan Mohajer <[e-mail]> wrote:
> 
> Hi Michael,
> Yes, the current version of LwM2M requires the use of “Write Attribute” which as you pointed out provides a single set of notifications parameters. This in itself could be rather problematic in use cases where there are two observers of the same resource with differing requirements of observe attributes. As per example A in the document and your suggestion it seems more logical to pass the observation attributes in the get operation and make them somewhat transaction oriented rather than simply attached to the resource. By doing so, a resource can accommodate multiple observers with different observation rules as required. BTW, couple of companies have already put forward proposals to add support for passing of these attributes in the GET operation in the next version of OMA LwM2M specification. 
> Best Regards,
> Mojan
>  
>  
>  
> From: Michael Koster [mailto:[e-mail]] 
> Sent: 13 March 2017 12:58
> To: Mojan Mohajer
> Cc: core
> Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02
>  
> Hi Mojan,
>  
> I think this is the default behavior for OMA LWM2M using the "Write Attributes" operation. The effect is to provide a single set of notification parameters for all observe operations on that resource.
>  
> I believe that we improve on that pattern and allow each observe request to have its own attributes, set by including query parameters in the GET operation.
>  
> Section 4.2 also indicates that they are readable, but it's not clear to me how that would work? In what format are they returned, also as query parameters? These could be made readable (and updateable) througn a special CoRE Interface, but we would need to specify how the content format of these works vs. the content format of the resource state.
>  
> LWM2M could be described in this draft as a legacy pattern.
>  
> Does this make sense?
>  
> Best regards,
>  
> Michael
>  
>  
> On Mar 10, 2017, at 2:52 AM, Mojan Mohajer <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 2) Section 4.2 which covers resource observation attributes (pmin, pmax, st, …) states that that: …”These query parameters MUST be treated as resources that are read using GET and updated using PUT, and MUST NOT be included in the Observe request” ….
> However, looking at newly added Annex A which provides observation examples, these observation attributes are passed as query parameters of a Get request with Observe option set to 0. There seems to be some contradiction between the text in section 4.2 and the example in Annex A.