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

From: Mojan Mohajer <[email-masked]>
Date: Fri, 10 Mar 2017 11:52:19 +0100

1)The latest draft has renamed "gt" and "lt" attributes to "gth" and "lth" respectively. Has any consideration been given to the impact of this name change on other SDOs and their specifications where CoAP and these attributes are used. For example, OMA LwM2M v1.0 which has recently been formally released uses CoAP as its application layer protocol and these attributes for notification purposes.

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.

Best Regards,
Mojan

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Fri, 10 Mar 2017 20:12:45 +0000

Mojan,

I certainly agree - we should be careful about renaming these attributes; the attributes have been around for a while and are used by OMA for sure.

Yes you are indeed correct the examples do not align with normative language of section 4.2 - this again can cause problems in other SDOs.

BR,
Tim

-----Original Message-----
From: Mojan Mohajer [mailto:[email-masked]] 
Sent: Friday, March 10, 2017 4:52 AM
To: core <[email-masked]>
Subject: [core] Questions/comments on draft-ietf-core-dynlink-02

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.

Best Regards,
Mojan

---

From: Christian Groves <[email-masked]>
Date: Mon, 13 Mar 2017 17:18:55 +1100

Hello Mojan and Tim,

For the attribute renaming there was already discussion on the list 
about it and it seemed there was agreement to change the dynlink 
parameter and not the RD parameter. Usage by other SDOs was raised. My 
plan is to raise this issue in the upcoming Chicago meeting to see if we 
can get it resolved there.

Thanks for pointing out the error in the examples. I'll fix it in the 
next version.

Regards, Christian

On 11/03/2017 7:12 AM, Carey, Timothy (Nokia - US) wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Mar 2017 05:58:08 -0700

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 <[email-masked]> wrote:
>

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Mar 2017 06:08:09 -0700

To summarize, I recommend that we change 4.2 to specify using observe attributes as query parameters in the OBSERVE operation to which they apply.

We could optionally make them writeable as a single set of attributes to apply to all observations of that resource.

If we want to make the single set readable, we will need to add more specification. about the returned representation.

Best regards,

Michael

> On Mar 13, 2017, at 5:58 AM, Michael Koster <[email-masked]> wrote:
> 
> Hi Mojan,
> 
>> On Mar 10, 2017, at 2:52 AM, Mojan Mohajer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Mar 2017 06:08:09 -0700

Best regards,

Michael

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Mar 2017 05:58:08 -0700

Hi Mojan,

Does this make sense?

Best regards,

Michael

---

From: Mojan Mohajer <[email-masked]>
Date: Mon, 13 Mar 2017 16:05:49 +0100

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:[email-masked]] 
Sent: 13 March 2017 12:58
To: Mojan Mohajer
Cc: core
Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02

Hi Mojan,

Does this make sense?

Best regards,

Michael

On Mar 10, 2017, at 2:52 AM, Mojan Mohajer <[email-masked] <mailto:[email-masked]> > wrote:

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Mar 2017 08:28:47 -0700

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 <[email-masked]> wrote:
> 
> Hi Michael,

---

From: Mojan Mohajer <[email-masked]>
Date: Mon, 13 Mar 2017 17:01:27 +0100

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

Best regards,

Michael

On Mar 13, 2017, at 8:05 AM, Mojan Mohajer <[email-masked] <mailto:[email-masked]> > wrote:

Hi Michael,

Best Regards,

Mojan

 
From: Michael Koster [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: 13 March 2017 12:58
To: Mojan Mohajer
Cc: core
Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02

Hi Mojan,

Does this make sense?

Best regards,

Michael