The following has two sets of draft minutes. CORE Meeting Minutes ==================== Minute Taker: Hannes Tschofenig and Olaf Bergmann Jabber Scribe: Martin Thomson Slides can be found here: http://www.ietf.org/proceedings/78/slides/core-0.pdf Minutes: Olaf Bergmann * Intro * milestone status done: WG doc selected for coap protocol (currently -01) todo: coap spec with mapping to HTTP REST (-> dec 2010) todo: security bootstrapping (scheduled for dec, will start today) * inofficial plugfext on last Sunday (2010-07-25) about 10 implementations, all implementing coap-06 basic interop (message format, options encoding, transaction model, GET method) POST and DELETE not really tested observe: will test today, three implementations claim to support this coap-misc: 3--4 impl another ad-hoc plugfest today (13--15) * CoAP (Zach Shelby) current version is -01, was basis for plugfest since -00 removed TCP, magic byte, URI-Code option subscription moved into separate draft (draft-hartke-observe) CoAP is especially about M2M want a REST design that can be mapped to HTTP and back do not want to re-invent HTTP use-cases are very targeted header format has not much changed since -00 plugfest: saw that not many options are typically used, most of the time 0--2, at most 5 have been seen now have a clean transaction model underneath CoAP message semantics synchronous transactions (informally using HTTP response codes) asynchronous: note that transaction id for delayed response is different from the original retransmissions use the same transaction id Martin Thomson: how to correlate two POST requests to the same resource? A: must match on URI or use Token Carsten Bormann: Web browsers only use GET/POST, but keep in mind that we have also PUT and DELETE to make things clearer Caching currently only defined for GET refresh and versioning with Etag caching usually on behalf of a sleeping node resource discovery (chartered item) service discovery may be needed but is not our business (use e.g. DNS-SD) register _coap with dns-sd.org (alreay in progress) instead discover links offered by CoAP servers (GET /.well-known/r) Stuart Cheshire: what is the list of resources to discover? A: Sensei example: return list of device sensors; path names and content-type, possible description and name Stuart: draft is unclear, talks about what protocols are offered; "service of reporting temperature, actuators, light switches..." client knows the protocol, no need to announce this -> need to improve wording Stuart: clearly describe granularity of service discovery two step approach: first determine the hardware to talk to and then query for its services, but this does not fit here, recommendation: forget GET /.well-known/r as you first need to discover the service and then the hardware that supports this (the wk-approach needs to know the hardware first) from Jabber: Kerry Lynn(sp?): perhaps need subtypes in DNS-SD Peter Bigot: current option encoding is too complex, please consider alternatives A: take this to the open nits discussion at the end Ralph Droms: - Stuart Cheshire: you cannot force things to implement TCP, ARP for DNS-SD avoid duplication between optional DNS-SD and nebulous own mechanism just pick one option and make it mandatory Carsten Bormann: actually, you can implement this without TCP and ARP we did this using UDP and ND our trade-offs are different e.g. Peter Bigot : 148 bytes for encoding are too complex note that smart meters are big platforms compared to light switches etc. we may not even have multicast Stuart Cheshire: ok, not TCP and ARP but UDP and ND think about how somebody makes devices like this (had this im mind when DNS-SD was designed) e.g. cameras have to enter the network by themselves, need self-configuration how to do useful things when you cannot device this Kerry Lynn(sp?) (via Jabber) DNS-SD and mDNS still have to become RFC Stuart Cheshire: pick one and make it mandatory but keep in mind the retransmission problems with multicast designing your own protocol is hard work Cullen: Stuart, please write IAB advice on discovery design failures to the list (Stuart agrees) Peter: better take this to apps-discuss (Cullen and Stuart agree) Hannes Tschofenig: where to find the requirements A: (something -req) HTTP mapping: Mark Nottingham: HTTP server/clients needs to know about the CoAP resources to query concerned about the overlapping will send these concerns to the ML I-D proposals: coap-misc: most important? -> the Block option will be tested this afternoon coap-congestion-00: hints to try bugs seen during the interop events link format clarificiations needed URI-Authority wrt proxy error behavior on unknown critical options? .may change /.well-known to shorter /w/r and do not care about /.well-known registry Julian Reschke: what is the difference to link relations header? A: we don't have relations; Mark Nottingham: the draft confuses things more than it clarfies A: need to figure out what the right way to map HTTP Link header is open issues: proposals from the ML Carsten Bormann: on design aspects (wrt 2-byte option): danger of saving on options because 2-byte type-encoding seems to expensive Martin Thomson: costs for implementing XRD on constrained devices? A: yes, generating/parsing XML could be too expensive Martin Thomson: that's why link headers seem to be a good idea? A: but avoid overloading Mark Nottingham: suggest to look at draft-hammer-hostmeta-13 (in LC) wrap up need to integrate subscription option block expect coap-02 about 2 weeks after Maastricht any opinions on the option encoding? Sampo KellomŠki: what is the length limit for a single option? does it change? * Observing Resources in CoAP (-> Subscription Option) (Klaus Hartke) Mcharlesr (Jabber): if I try to subscribe to a resource that doesn't support subcriptions, I guess that I don't get a subscription-lifetime: value in the 200 OK, so I know that I have to poll? Martin Thomson: long polling pattern in HTTP Klaus: or use WebSockets Kerry Lynn: can this polling be modeled as resources Carsten: why do we want this? Stuart Cheshire: you want to say when you want to be notified e.g. "notify me when temperature changes by more than 2ˇ celsius" Martin Thomson: we have experience in presence systems Cabo (Chair): there are many ways to do this, discuss later Martin Thomson: observation: Etag in request is probably more an If-header (in terms of HTTP) Martin Thomson: option 3 (subscribing to IPv6 multicast group) is a good method for attacking CoAP nodes Adam Roach: options 2 and 3 do not give devices the opportunity to define authorization policies Angelo Castellani: concerns regarding proxies Carsten Bormann: answer jabber questions: get rid of subscriptions: subscribe with lifetime 0 or send RST when you got a request you do not want what to do when you have different answers to different users? -> do not use REST Zach: like this proposal as all pre-requisites are already in coap-01 option 2/3: maybe too complex, we want the simplest we can get Martin Thomson: use long polling instead, you do not even need an option for this this would avoid issues of getting rid of subscriptions etc. and would simplify HTTP mapping suggestion: do not use this Robby Simpson: Can use options 2/3 to configure large number of devices Zach: you do not have to use that Cullen: option 3 has sever security implications, so do not do that (message amplification in particular) Tom ?. do not put this in the base spec as long as there is no deployment experience Martin Thomson: we already have caching to offload multiple subscriptions Carsten Bormann: issues with long poll in UDP-based protocol: need an acknowledgement, so the message flow will be the same -> hence no real difference in this protocol repeated sending of notifications can be non-confirmable as optimization Carsten (Chair): there are implementations of observe but need more move this to the base spec to make implementers notice Cullen (Chair): do people think this is required? Zach Shelby: make it optional therefore a separate spec would be ok BoF said, just do a single document Hannes Tschofenig: is not menadatory to use, so why make it mandatory to implement Robert ?: should be optional, as it can be achieved by long poll as well if needed Carsten Bormann (individual): must be optional as it makes no sense to subscribe a resource that does not change Robby Simpson: recommend this to be optional, esp. if HTTP mapping is focused Mark Nottingham: have many options to implement the functionality so do not define an overwhelming framework to achieve this * coap-misc (Carsten Bormann) block option is the really important thing Kerry Lynn(sp?): may want to look at AppleTalk Transaction Protocol A: you can add state to make protocol more efficient but goal is to mimize state ?: use reliable multicast? A: this is very hard and it will take long time to get it right Zach Shelby: is this optional? A: some nodes might not have resources that have resources big enough Hannes: be clear if optional to implement or to use? Cullen (Chair): have the critical flag in base spec Yves Lafon: partial PUT does not work well, consider HTTP PATCH A: PUT will create state similar to what was there before but PATCH means to define delta encoding (but have small RAM resources) here, you can e.g. upload a firmware using PUT+Block will be slow but work Ed ?: block works as expected. what does it mean for multicast or non-confirmable How to deal with non-supported block sizes? A: with GET, client indicates the block size it wants to use in request a server may reduce the value and send smaller chunks Accept option TeRIs Zach: do not do this ?: interaction with caches A: none, since caches never look on TeRIs Token Zach: does this remove the need for URI option in the response * Congestion Control:(Lars Eggert) no slides, did not request this slot... resources are really constrained, so path over-utilization might not be a problem routes may change, so you have no stable path where you can estimate network conditions goals: avoid congestion collapse, but cannot guarantee fairness and avoid wasting battery for useless retransmissions IETF toolbox has no existing mechanisms to recommend here proposal hence is experimental use simplistic AIMD scheme usually: CC of each flow, cannot tell how many flows to use currently, in core, node theoretically can create unlimited flows (although radio capacity wont suffice to overload the network) how to handle unreliable messages? multicast vs. unicast? possibly be more conservative when sending multicast traffic Michael ?: link-layer provides some fairness anyway. Can we just leave it up to the link-layer A: yes, if we can make certain assumptions on the link-layer Robby Simpson: packet-loss always relates to congestion? we can also have corruption A: conservative: treat corruption like congestion ECN might give you better capabilities, but cannot handle every aggregate scheme penalizes every transmission as it is less sufficient Martin Thomson (Jabber): what about collision? A: yes avoid nodes simultaneus retries mcharlesr (Jabber): other layers? A: yes, if you can do it on layer 3, but I do not see how this oould work w/o being end-to-end Zach Shelby: valuable work; need to do this in this WG? Charter? people have very specizalied applications in mind some of this is very domain specific and thus can be used safely without CC A: it is more general, have contributed to core to make core-people pay attention JLCJohn: which WG? A: took it here as it makes sense in this particular environment * Wrap up some presentations missing make phone call some time next week? -> a number of people agreed Cullen to schedule plugfest from 13:00 to 15:30 in the terminal room ------------------------------------------------------------------------- 0) Agenda Bashing (Chairs) No decisions to made. 1) Base CoAP Protocol (Zach) draft-ietf-core-coap-01.txt Zach talks about the new transaction model. Martin Thomson: What ab out reliable delivery responses? Zach: TID is used for matching transactions. For retransmit the same TID is used. Tokens are used Martin Thomson: What about asynchronous transactions? Zach: Currently a URI is used for matching the response to the request. Currently there are some limitations. Tokens could be useful. Carsten: The important aspect is to unlearn the knowledge you obtained from the browser environment. Resource Discovery Stuart: What are the examples of the links you use? Zach: In one of our projects we use the links of the different sensors These links tell you the path to the resources, content type. Stuart: In the example on the slide you register CoAP, which is a framework. Zach: There is a difference between the service discovery and the resource discovery. Stuart: You know the protocol first and then you discover what instances you support (not the other way around) Zach: We might need to improve the wording. Stuart: I wrap up with one example. You are going to down a path that is very common. I find a hardware and then interact with a specific hardware. Rather than finding the hardware it is better to turn the procedure around. Forget the .well-known thing. Example: iTunes You don't want to advertise all your songs since they made be many. Examples: Printers You want to distribute the 3 printers regardless of the server they are attached to. It is the logical server. It is the meter you want to report as a logical entity. Zach: CoAP is the transport mechanism rather than the actual mechanism to made these resources available. Martin Thomson (Jabber): We need the sub-types in the DNS-SD. Martin Thomson (Jabber): The current option encoding is unnecessary complex. Zach: There is an open issue slide on the end. Zach: We cannot force nodes to run DNS-SD. Ralph: Why not? Zach: Application and deployment specific thing. Stuart: Actually, we can. If we say it is inside then you you have to implement it. You need to pick how you discover resources and services. Microchip, for example, as an implementation of DNS-SD. The code requirements are not high. Carsten: You can implement this without using TCP and ARP. We use UDP and use ND in an optimized form. This is about optimized nodes and there are tradeoffs. We just have an example where 128 bytes to implement. We are talking about big things, such as temperature sensors. We may not even have multicast. We have to be a bit careful to say what we take for granted. Stuart: I used bad examples but the point is still the same. There are some requirements and the working group decides about them. You need to think of how one makes a device and how this is going to be used. When I did service discovery I was not thinking about PCs, who still have a lot of input / UI possibilities. We need things that are self-configurable. I am not sure how someone is going to use some of these devices in a useful and user friendly way. Martin (Jabber): DNS-SD and multicast DNS still have to become RFCs. Cullen: That problem will be solved soon. Zach: We have a simple requirement here. Stuart: You should document one. When you do your own discovery protocol then after some time you will be at the level of multicast DNS after a few years. You should pick path A or path B and not let people chose. Cullen: Maybe you could post a mail about your thinking on discovery to the list, Stuart. Stuart: Yes. Hannes: Have you written down the assumptions somewhere? Zach: Yes, they are in the requirements document. HTTP Mapping Mark: I am concerned that an HTTP server may need to know that they are in fact talking to a constraint device. Julien: What is the difference between HTTP Zach: We don't have link relations? Julien: Why not? Zach: These are lists of resources and the description of the resources. Julien: This is what the link header is for. Mark: This is what the link header is for. Zach: The relationship is very different in the environment we use it. Carsten: Cost of the 2 byte-option. 1) cost for additional byte 2) huge cost if people stop using the options. Martin: Have you considered the cost of implementing XRD? Zach: It is just a blob Martin: Well, you have to parse the XML. Zach: Yes, this can be complex. Mark: Those folks who have had concerns about discovery might want to read through the host-meta draft. Sampo: What is the length limit for a given option? Carsten: 217 bytes Sampo: In the mobile world where we had restrictions on the URLs was a huge constraint. Zach: I am personally happy with the current header. There were no problems in the header format during the interop. 2) Subscriptions Options (Klaus) draft-hartke-coap-observe-01 Martin (Jabber): If I describe to a resource that does not support it then I do not get a subscription lifetime in the 200 OK. There is a pattern in HTTP that can be used as well, Martin argues. Martin (Jabber): Can observers also be modelled as resources? Stuart: You also need to say by how much. Sensor temperature might change regularly by very small values. Martin: I have some experience with filters from the location work. Carsten: We have to cut the line to let Klaus present his approach. Martin: The HTTP representation of the eTag usage would be different. Klaus: Yes. Martin: Option3 looks like a good attack opportunity. I like it. Adam: Option 2 and 3 does not allow the observers to receive different values. Angelo: The design of the proxy is really hard when it has to keep a lot of state. Carsten: To answer adam's question: If you have different answers for different users of the same resource then you should not use REST. Zach: I like this work because it makes heavy usage of the core protocol. I would be happy to integrate this into the base doc. Martin: I made my case for long polling. There are various things that other designs aspects need to be considered and long polling is a good alternative that allows mapping into HTTP easy. My suggestion - don't invent a new mechanism. Robby: Option 2 and option 3 are very important. I fear that long polling would be more complicated. Zach: On Martin's comment. We already have it in the base spec because of the async communication. We have these low power requirements and long polling does not help. Cullen: The security implementation of option 3 is from a security implementation is not really an option. Thomas: Rollling this into the base spec seems to be the wrong thing. We don't have deployment experience. Martin: You also have the option of using caching and it might be the best option for taking the load away. You don't need to build a new mechanism for it either. Carsten: There is not a big difference to long polling. After you get the GET you have to provide an ack. So, you have the exchange already. When the actual response comes back you need an ack. Any protocol would look very similar. Carsten: We need to decide whether this should become part of the base specification. Cullen: Do people envision that this is a mandatory requirement for those implementing the base specification? Zach: I would envision that this is optional. You should not force people to use subscriptions. Robert: The protocol should be optional to implement. This could be implemented in other ways as well. Carsten: I also think it should be optional to implement. Robby: Optional to implement. 3) CoAP Miscellaneous Changes (Carsten) draft-bormann-coap-misc-05 Martin (Jabber): You should look at AppleTalk protocol. Carsten: There are many protocols that do look like that. The main question is how much state you maintain. We optimize state. Zach: Is this optional? Carsten: The base protocol has the CRITICAL flag already. Hence, there is some form of negotiation. ?: Partial PUT does not quite well. You should use PATCH instead. Carsten: This is a good point. In many cases the PUT will create a resource state that is already there. For a PATCH you have to think about the encoding of the data. That's a next step.... ?: I found it simple to implement. Still I have two questions: a) usage of multicast b) negotiation of block sizes. On (b) the draft needs to be improved. Joerg: The server has to ensure that they don't get re-assigned. So, it is the server responsibility. Carsten: Yes. Zach: I don't think we need to do this. ?: What is the interaction with the cache. Zach: No interaction with the URI. This is between two parties. Angelo: Question about charter. We are not chartered to do transport but we still do lot of work about transport. Token: Zach: Does this remove the need of the URI in the rsponse for matching? Carsten: yes, good question. Yes, this would be possible. 4) Congestion Control (Lars) draft-eggert-core-congestion-control-00 Lars talks about congestion control. Michael: I agree that the concern is the wireless part and that it is very different to TCP. But what you impose is a fairness on what the link layer provides you anyway. We could leave it to the link layer anyway. Lars: If we can require what the link layer does this for us then it gets simpler. ?: There is an assumption that packet loss correlates to congestion. Additionally, looking at traditional TCP on individual flows was always considered questionable. Lars: The conservative thing is to treat corruption as congestion (in absence of any other mechanism). These mechanisms ?: Are you opposing ECN? Lars: No, ECN is a good mechanism but in this environment you might get very rapidly changing ECN marking (from nothing to all). On your point two you are certainly right. ?: You might be on a collision domain and we have some experience there and we might not want to consider it here as well. Lars: I would consider this congestion. ?: It is a different problem that we also need to address. Martin (Jabber): Is this something for the application to consider or should it go somewhere else? Lars: Don't know. Maybe you can do something in a lower layer. It does not need to be end-to-end (if you make some strong assumptions). I put it in core because I was reading the drafts for a Perl implementation. Zach: This work is really valuable. I am wondering how much we really need to do in this charter. Many of the application spaces are very different and other SDOs are working on it. They make it safe in their specific domain. HTTP Mapping - 15 min (Zach) No draft on this Sleeping Nodes - 15 min (Akbar) draft-rahman-core-sleeping-00 Bootstrap Approach - 15 min (Colin) draft-oflynn-core-bootstrapping-01 CoAP Usage - 20 min (TBD 1 or 2 people) draft-vanderstok-core-bc-01 draft-braun-core-compressed-ipfix-01 -------------------------------------------------------------------------- Base CoAP Protocol Points were raised that we need to think carefully about the granularity of the service and sort out some of our language and ways we want to do Service discovery. Cheshire suggested right level os services was like: a power meter, or a temperature sensor. Should investigate the pros / cons of using dyn-dns on constrained code. A bunch more dissection of service discover is needed. Would be nice to hear more about concerns to do with the overlap of CoAP and HTTP. Comments was made it might be nice to see them more separated. We might want to add the link relation type and add new types of relations to the registry. Subscription option (-observe) Chair will work with ADs to set up a milestone for Subscription mechanism. Block Options / Coap Misc TeRI - probably need more discussions on how this interacts with Cache