Subject: [core] My Notes about draft-ietf-core-interfaces-05

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 3 Aug 2016 09:49:32 +0200

Hi all,

I read through draft-ietf-core-interfaces-05 and I have a few questions.

I understand the functionality and the desire to standardize interfaces
since the CoRE Link Format only introduces the concepts but leaves the
details (i.e., the value for the if parameter) unspecified.

1) Who came up with these terms?

Here, for example, is the definition of the 'collection':

"A Collection is a resource which represents one or more related
resources. Within this document, a collection refers to a collection
with characteristics defined in this document."

My understanding of the collection function is that of a view in an SQL
database. Is this correct?

The definition of function set, interface, and other terms also appears
to be somewhat unusual. Isn't there something we could re-use from the
Web context?

2) Is this document only applicable to CoAP or also to HTTP? In general,
I get worried when functionality is only defined for use with CoAP and
is not usable with HTTP, and HTTP/2.

3) Is it possible to include some practical examples? The document
currently includes a number of examples but those are abstract.

4) I am curious why SenML was selected. I have been trying to understand
the relationship with LWM2M and LWM2M, for example, does not use SenML.
SenML feels like a somewhat heavy format since it includes meta-data
that most applications don't need.

5) For most functionality no use cases are presented. The exception is
the collection where a use case is presented in Section 4.2. I am,
however, not sure that the 'Gradual Reveal' functionality is really
useful as such.

6) Who is using the functionality described in this document? The
editor's note talks about alignment with OCF. Since I am not familiar
with the functionality standardized by the OCF I cannot say how much
different this document is from the OCF-defined features.

7) The structure of the document is not well-balance. For example,
Section 3 consists of one sentence. The content of Section 5.8 is
meaningless and Section 6.3 "Versioning" is difficult to understand. The
security consideration section as well as the IANA consideration section
is at best incomplete. Appendix A contains no textual description of
what is shown in the tables.

7) Who is the editor of this document?

Ciao
Hannes

---

From: Christian Groves <[email-masked]>
Date: Fri, 26 Aug 2016 17:09:31 +1000

Hello Hannes,

Please see below.

Regards, Christian

> 1) Who came up with these terms?
[CNG] I'm not sure, various related technologies such as Java and HTML 
utilise some of the concepts e.g. collection. I'll let one of the 
original authors answer this. I agree the definitions could use some 
more "meat" on them. Something that i'll work on.
> is not usable with HTTP, and HTTP/2.
[CNG] Also to HTTP, as Core-Link format may be used by HTTP.
> currently includes a number of examples but those are abstract.
[CNG] Did you have something in mind?
> that most applications don't need.
[CNG] You mention LWM2M and LWM2M I'm not sure what the 2nd instance is? 
With regards to LWM2M the specification uses the "interface" concept in 
a similar manner to what is defined in the draft. I.e. what operations 
may be performed on resources via the interface is described. The LWM2M 
specification does reference the core interfaces draft but that's only 
in the context of a note i.e. "/Note: How to indicate the Attributes in 
the message payload is specified in [CoRE_Interface]./" I think that 
needs to be updated to make reference to the dynamic linking draft we 
have split out.

> however, not sure that the 'Gradual Reveal' functionality is really
[CNG] The draft was accepted back in mid 2013 (before I started 
following the CORE WG) I would have assumed there were some use cases 
presented in order for the WG to adopt the work. Perhaps one the 
original authors has them?
> different this document is from the OCF-defined features.
[CNG] The note was simply a place holder for further work that needs to 
be done. The relationship with OCF is something that needs further 
description. This is something hopefully Michael will be able to help with.
> what is shown in the tables.
[CNG] Yes it needs work. I explained at the meeting this document was a 
simple split of the existing text. I intend to provide some enhancements 
for the next version.
> 7) Who is the editor of this document?
[CNG] I'm now the editor. So thanks for the comments there something to 
consider for the next revision.
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Koster <[email-masked]>
Date: Wed, 31 Aug 2016 08:35:07 -0700

Hi Hannes,

Thanks!

Comments below:

> On Aug 26, 2016, at 12:09 AM, Christian Groves <[email-masked]> wrote:
> 
> Hello Hannes,
> 
> Please see below.
> 
> Regards, Christian
> 
> 
> [CNG] I'm not sure, various related technologies such as Java and HTML utilise some of the concepts e.g. collection. I'll let one of the original authors answer this. I agree the definitions could use some more "meat" on them. Something that i'll work on.
>> 

[MJK] The concept of a collection is very common in web architecture. Check out RFC6573  https://tools.ietf.org/html/rfc6573 <https://tools.ietf.org/html/rfc6573>  I think we could add examples to CoRE Interfaces using the item relation type to illustrate this.

[MJK] The concept of "interface" was invented by an earlier author than me, but has been adopted by OCF in their specification. It fills a gap between media types and "profiles", which are not well adopted either.

[MJK] Function set is not so well adopted and may be changed to a more colloquial description.

Which other terms need further definition?

> [CNG] You mention LWM2M and LWM2M I'm not sure what the 2nd instance is? With regards to LWM2M the specification uses the "interface" concept in a similar manner to what is defined in the draft. I.e. what operations may be performed on resources via the interface is described. The LWM2M specification does reference the core interfaces draft but that's only in the context of a note i.e. "/Note: How to indicate the Attributes in the message payload is specified in [CoRE_Interface]./" I think that needs to be updated to make reference to the dynamic linking draft we have split out.
> 
[MJK] "LWM2M, for example, does not use SenML." (?) I don't understand this comment. As far as I can tell, LWM2M normatively requires SenML. From the LWM2M TS, Sec. 6.3.4, JSON:
"LWM2M Clients supporting the JSON format MUST use the format defined in this section for responses with multiple resource values. They MAY use the format defined in this section for responses with single value. The format MUST comply to [SENML] JSON representation extended for supporting LWM2M Object Link data type and MUST support for all attributes defined in Table 17. According to [SENML] semantics, JSON data format in LWM2M, is composed of optional attributes (Base Time, Base Name) and of a mandatory Resource Array having one or more entries. Each array entry contains several optional or mandatory parameters (Name, Time...)."

> [CNG] The draft was accepted back in mid 2013 (before I started following the CORE WG) I would have assumed there were some use cases presented in order for the WG to adopt the work. Perhaps one the original authors has them?
>> 
> [CNG] The note was simply a place holder for further work that needs to be done. The relationship with OCF is something that needs further description. This is something hopefully Michael will be able to help with.

[MJK] OCF uses the "if" link atttriute in much the same way as described in this draft. It is registered in the IANA CoRE Parameters registry.
> [CNG] Yes it needs work. I explained at the meeting this document was a simple split of the existing text. I intend to provide some enhancements for the next version.
> [CNG] I'm now the editor. So thanks for the comments there something to consider for the next revision.
>> 
>> Ciao
>> Hannes
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: Michael Koster <[email-masked]>
Date: Wed, 31 Aug 2016 08:45:36 -0700

Hi Hannes,

SenML is used because it is a lightweight data model that can represent a collection of resources. 

The "n" attribute in SenML identifies the resource instance and allows multiple resources to be transmitted in a single representation.

The array format has some advantages in processing vs. map formats that use application semantics as JSON keys.

SenML maps to CBOR in a compact way.

Most meta data in SenML is optional, and should not need to burden applications that don't need it.

Michael

> On Aug 3, 2016, at 12:49 AM, Hannes Tschofenig <[email-masked]> wrote:
>