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

[Mojan Mohajer <[e-mail]>]

I think going forward the best compromise solution would be as you mention continued support for global settings, i.e. single attributes set, as well as per-observe override. This will have least impact on the existing implementations and currently released specifications by other SDOs. 

If IETF decides to go down this route, it would be good clearly state the rules for how the override should be applied and maybe couple of examples showing its application and effect. For example one scenario that may require some clarification is where a resource has already got some observation attributes set up by observer 1 and a new observer, Observer 2,  wishes to simply be notified of any change to the resource and as such does not normally require to explicitly specify any observe parameters in its get request for observation.

Best Regards,

Mojan

 

 
From: Michael Koster [mailto:[e-mail]] 
Sent: 13 March 2017 15:29
To: Mojan Mohajer
Cc: core
Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02

 
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] <mailto:[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] <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.