gmane.ietf.core

Re: draft-shelby-core-interfaces: call for adoption

Lishitao — 2013-05-25T01:55:01


 I am not quite understand about this, if the resource represents using JSON instead of link format, the client just needs to understand 
about the JSON format before sending any request. It is not a problem only for observe. 

And since the JSON object for resource representation is still under working, it needs a way to solve this problem if it has.


I think OMA LWM2M just defines the requirements and its structure. The detail about how to use coap is out of scope. 



Yes, using option is one of the possible solution, and can solve most of the problems, URI-query also has its limits.


HTTP does not has observe mechanism(something like HTTP streaming may provide the almost same function, but not using the same mechanism),
So I don't think that is a problem, anyway you need a way for interworking between coap and HTTP. Not all the HTTP staff can be used in coap, and vice versa.


Yes, I also believe that conditional observe is not an easy issue, our draft has not cover all the problems. 
And it is also

Outstanding tickets on core-coap-16

Carsten Bormann — 2013-05-24T22:47:45

I think we have had a good discussion on #325, so we should be ready to close that ticket after the authors generate a little more text.
I plan to include the list Robert provided as an implementation note.

#323, #324 have strawman text that we can use and that should be fine.

#326 has a reply that indicates a direction; the authors still have to generate some text for that, but that should be easy.

#327 has strawman text that may not be great, but if we want to give advice on ICMP errors, it is likely the best advice we can give.
I'd like to hear some opinions from implementers on the list before closing this.

I expect to cover a bit more of the extensive editorial feedback from the IESG, as well.

My plan is to have -17 submitted by the end of the weekend, so that we can work next week on clearing more of the IESG DISCUSSes.

Shortcut to the bug tracker: http://i-e.tf/,,core/9

Grüße, Carsten

Re: #325: Define curve for keys and certs

Richard Kelsey — 2013-05-24T22:13:50

Zach,

I wouldn't worry too much about trying to avoid including these
as options.  They add something like 23 bytes to one not-too-large
handshake message.  This seems like a small price to pay for
general interoperability.

The record layer seems like a better target for optimization,
given that you will likely send a lot more application messages
than handshake messages.

                                       -Richard Kelsey

[...]

This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product.  If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message i

Re: draft-shelby-core-interfaces: call for adoption

Floris Van den Abeele — 2013-05-24T16:25:08

Hi Zach & all,

It seems to me that the approach in the interfaces draft limits the 
values that a REST resource will actually publish to the 'entire world'? 
Say that 2 clients want to observe the same resource with different 
conditions, with the current approach this isn't possible. A 
'REST-compatible way' to solve this (there might be other, better ideas) 
could be to create a new temporary (sub)resource (e.g. /temp/1, /temp/2) 
in response to the PUT requests for every client and let the client 
observe the 'tailor-made' sub-resource. Whether this is feasible for 
constrained devices, I am unsure. Are you using more than 1 client in 
your deployments? Another critique that I wanted to make is that there 
might be overlap with the URI-query parameters the resource itself 
actually wants to use (related to me reply to your point #3).

I was also wondering why the draft decided to move to a separate PUT 
request for specifying the conditions? Why didn't you keep it in the 
observe request as in previous v

Re: draft-shelby-core-interfaces: call for adoption

Zach Shelby — 2013-05-24T15:05:16


Yes. It defines a REST design paradigm that can just simply be used by a developer, or referenced by other documents/standards building REST interfaces over CoAP.  We can surely (as a WG) explain the scope and purpose better. 

Zach

Re: draft-shelby-core-resource-directory: call for adoption

Zach Shelby — 2013-05-24T15:03:01

Peter,

I agree, as discussed in Orlando, we should integrate the DNS-SD mapping to this document. 

Thanks,
Zach 

On May 21, 2013, at 9:47 AM, peter van der Stok <stokcons< at >xs4all.nl> wrote:

Re: #325: Define curve for keys and certs

Zach Shelby — 2013-05-24T14:54:54

Robert,

Thanks. This matches what ticket #325 is saying CoAP implementations using this Cipher suite MUST support. The proposed text in #325 also says that other curve settings MAY be used. So I think we are fine with that ticket. 

I would also love to have a way to "defaut" these MUST settings in the handshake, however I agree with Carsten that might not work with all DTLS implementations (without including the extensions).  What is your opinion?

We are currently working on a new DTLS for IoT working group proposal, and we plan on having a BOF in Berlin. The mailing list for this new group will be announced very soon. One work item proposed will be profiling DTLS for IoT applications (mainly for CoAP). This could be one of the things that could be possible defined in that profile. In the mean time, we do have a Google doc with information on the activity:

https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4eDo3g8

Zach

On May 24, 2013, at 3:36 PM, Robert Cragie <robert.cragie< at >gridm

Re: #325: Define curve for keys and certs

Robert Cragie — 2013-05-24T12:36:12

We used the following extensions for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 
when testing ZigBee IP:

* elliptic_curves
* ec_points_format
* signature_algorithms

Wireshark decodes it thus:

Extension: elliptic_curves
   Type: elliptic_curves (0x000a)
   Length: 4
   Elliptic Curves Length: 2
   Elliptic curves (1 curve)
     Elliptic curve: secp256r1 (0x0017)

Extension: ec_point_formats
   Type: ec_point_formats (0x000b
   Length: 2
   EC point formats Length: 1
   Elliptic curves point formats (1)
     EC point format: uncompressed (0)

Extension: signature_algorithms
   Type: signature_algorithms (0x000d)
   Length: 4
   Data (4 bytes): 00 02 04 03

The signature_algorithms field further decodes to sha256, ecdsa

Robert


On 23/05/2013 11:33, Hauke Mehrtens wrote:

Re: draft-shelby-core-interfaces: call for adoption

Zach Shelby — 2013-05-24T09:43:29

Hi Shitao,

Thanks for the feedback, I am aware of the work on using options for this purpose.

However, there are several reasons why I do believe the URI is the correct place for this, and that we should definitely include this feature in CoRE interfaces.

1. The Origin Server and the Resource, should be in control over any semantics regarding the resource representation. Working with parameters that affect the representation of the resource, MUST be handled as part of the REST interface. Confusing that into the CoAP options, which should be agnostic to what is inside the resource representation, would be the wrong thing to do. What happens if e.g. your resource representation is a more complex JSON object - how are you going to work on thresholds with CoAP options then? 

2. Other standards, e.g. OMA LWM2M are already using this same URI attribute model for controlling observations. It would be best that we try to align multiple standards using CoAP to do this in the same way where possible.

3. You are n

Re: draft-shelby-core-interfaces: call for adoption

Lishitao — 2013-05-24T09:27:46

First, I would like to say, this is a useful draft. It really gives some help and guidance when implementing M2M applications in the real world. 

But, I have concerns about section 5.9 "Resource Observation Attributes" in the interface draft.

I believe the best solution to express the observation condition is to use options, instead of using query parameters contained in the URI.

See the following draft for the detailed solution:
http://tools.ietf.org/id/draft-li-core-conditional-observe-03.txt

I remember that we discussed this before in PairsF2F meeting, and there was no conclusion yet.
http://www.ietf.org/proceedings/83/minutes/minutes-83-core.txt

And I think more discussion is needed for this feature. And I hope we can move this section out before accepting it as WG draft.

Note that the authors currently updating the draft and will upload it very soon.

Regards
Shitao

Re: #325: Define curve for keys and certs

Hauke Mehrtens — 2013-05-23T10:33:32

Yes that's correct.


The code used for creating and parsing the elliptic_curves TLS extension
is not that huge to justify a new exception in the DTLS standard for
this cipher algorithm or this use case. This TLS extension extends the
Client Hello and the Server Hello by 6 bytes in case just one curve is
supported.

What about the signature_algorithms TLS extension, for me it was not
clear if I have to add this extension or not when using
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I removed it because Californium did
not liked it. ;-)

Hauke

Re: #322: Clarify that security SHOULD be used for issuing secure requests to a proxy

core issue tracker — 2013-05-22T21:22:34

#322: Clarify that security SHOULD be used for issuing secure requests to a proxy

Changes (by cabo< at >tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in [1389]:

 Fix #322

Re: Fwd: New Version Notificationfordraft-shelby-core-resource-directory-05.txt

Kovatsch Matthias — 2013-05-22T13:44:15

Dear Zach,
dear list

I was looking at the draft to clean up the experimental implementation included in Californium. Thereby I stumbled over the following things:

4. Simple Directory Discovery:
I think it should be clearer that POSTed links do not end up in the RD's /.well-known/core resource as absolute URIs. Giving a Location in the 2.01 Created response should fix that. Some reference to the lifetime of the RD entry and the possibility of periodic validation might be useful here.

5.1. Discovery:
The IP part overlaps with "4.1. Finding a Directory Server." Maybe this can be separated into a common section before the simple and function set RD.
"discovering the RD using the CoRE Link Format (also see Section 4.1)" is also a bit confusing. I guess this is referring to multicast discovery, so this should be mentioned directly (possibly in this new section mentioned above).

5. Resource Directory Function Set:
I was wondering what should happen when someone performs a GET on the EP location, e.g., GET /rd/4

Re: draft-bormann-core-links-json: call for adoption

Kovatsch Matthias — 2013-05-22T11:50:11

Thank you very much for digging that up!


Yes, that perfectly matches the experience we are currently making in a "Cloud + Internet of Things" project. There is some appeal to make this format more general, but pushing it forward within CoRE sounds good (as it is pretty simple there).

Ciao
Matthias

Re: draft-bormann-core-links-json: call for adoption

Carsten Bormann — 2013-05-22T10:57:42


Oops, the file name in the minutes was wrong (fixed); make that ietf86-caribbean5-20130313-1300-pm1.mp3

What I said:

Re: draft-bormann-core-links-json: call for adoption

Carsten Bormann — 2013-05-22T10:37:01


The minutes are at:

http://www.ietf.org/proceedings/86/minutes/minutes-86-core

Specifically:


Well, maybe the audio is more useful... (http://www.ietf.org/audio/ietf86/ietf86-caribbean6-20130312-1300-pm1.mp3, if you actually look into it, start at 65:00).

Grüße, Carsten

Re: draft-bormann-core-links-json: call for adoption

Kovatsch Matthias — 2013-05-22T10:05:41

+1

I think this is useful for building larger "Cloud services" around constrained devices and M2M applications. I do not see a direct connection to core-interfaces, though.

In Orlando Carsten recalled the original incentive for writing up this format. Unfortunately, the minutes etherpad keeps resetting my connection attempts and I cannot recall the outcome. Anyone can? :)

Ciao
Matthias


From: core-bounces< at >ietf.org [mailto:core-bounces< at >ietf.org] On Behalf Of Andrew Mcgregor
Sent: Tuesday, May 21, 2013 2:28
To: core< at >ietf.org
Subject: [core] draft-bormann-core-links-json: call for adoption

Consensus of the room in Orlando was to adopt draft-bormann-core-links-json as a working group document.  This email is a call for confirmation of that consensus.  Please respond if you support the adoption of this document.

From the charter:

    5) A definition of how to use CoAP to advertise about or query for a
    Device's description. This description may include the device name and
    a list of its Resources, ea

Re: #325: Define curve for keys and certs

core issue tracker — 2013-05-22T09:44:56

#325: Define curve for keys and certs


Comment (by kovatsch< at >inf.ethz.ch):

 We definitely need text on which hash function to use, as this is not
 clear at the moment.
 Defining a MUST for SHA-256 looks good to me.

Re: draft-shelby-core-resource-directory: call for adoption

Kovatsch Matthias — 2013-05-22T09:32:55

+1

Matthias


From: core-bounces< at >ietf.org [mailto:core-bounces< at >ietf.org] On Behalf Of Andrew Mcgregor
Sent: Tuesday, May 21, 2013 2:26
To: core< at >ietf.org
Subject: [core] draft-shelby-core-resource-directory: call for adoption

Consensus of the room in Orlando was to adopt draft-shelby-core-resource-directory as a working group document.  This email is a call for confirmation of that consensus.  Please respond if you support the adoption of this document.

From the charter:

    5) A definition of how to use CoAP to advertise about or query for a
    Device's description. This description may include the device name and
    a list of its Resources, each with a URL, an interface description URI
    (pointing e.g. to a Web Application Description Language (WADL)
    document) and an optional name or identifier. The name taxonomy used
    for this description will be consistent with other IETF work,
    e.g. draft-cheshire-dnsext-dns-sd.

RFC 6690 has some of this; the resource directory would add protocol
eleme

Re: draft-bormann-core-links-json: call for adoption

Carsten Bormann — 2013-05-22T07:13:21


I'd say: stick with RFC 6690 in the constrained environment...


Again, I don't argue for moving over the constrained nodes to JSON links.


Yep:    application/link-format+json
(Section 3; the IANA boilerplate has to filled in, next).


Yes, it does (and no, it wouldn't break link-format or RFC 5988):

   If a Link attribute ("parmname") is present more than once in a
   "link-value", its values are then represented as a JSON array of JSON
   string values; this array becomes the value of the JSON name/value
   pair where the attribute name is the JSON name. 

(Section 2).


I think the jcardcal format is constrained by the need to do round-tripping into the legacy format, so you want to make the type information explicit.
I'm not sure we have the same considerations here.
(Also, since link-format attributes are RFC 5988 attributes and thus always string values, we follow this by even handling "ct" as a string:

   [{"href":"/sensors","ct":"40","title":"Sensor Index"},{"href":"/
   sensors/temp","rt":"tem

Re: draft-bormann-core-links-json: call for adoption

Bert Greevenbosch — 2013-05-22T06:28:06

+1

Not sure if I agree with the fact that it is only suitable outside the constraint environment though; the JSON variant seems easy enough to parse. How to avoid IOP trouble due to two endpoints using the different formats?

Some things for consideration:
- Change ".well-known/core" to ".well-known/jlink" or something?
- Register new mime type?
- Does this allow multivalue attributes, e.g. through arrays? Definitely possible in JSON, but it would break easy conversion to the conventional link format.
- In JCARD, we started with a similar construction. However we later changed to a construction of {"name", "parameter", "type", "value"} to allow more flexibility and signalling, especially concerning the type (e.g. string or integer) of the value.

Bert


From: core-bounces< at >ietf.org [mailto:core-bounces< at >ietf.org] On Behalf Of Rahman, Akbar
Sent: 2013年5月21日 11:50
To: Andrew Mcgregor; core< at >ietf.org
Subject: Re: [core] draft-bormann-core-links-json: call for adoption

+1

Akbar

From: