6LowApp/2010-09-29: 2010-09-29-minutes.txt

File 2010-09-29-minutes.txt, 13.0 KB (added by cabo@…, 9 years ago)


12010-09-29 CoRE Webex meeting
21500..1630 UTC.
4Chairs: Cullen Jennings and Carsten Bormann
5Notes taken by Markus Becker -- thanks!
6Massaged into minutes by Carsten Bormann.
10-- Document status
11-- Splitting draft-ietf-core-coap-02 and draft-shelby-link-format-00
12   (Zach Shelby)
13-- (Any other comments on
14   draft-bormann-core-coap-block-00, draft-hartke-coap-observe-02)
15-- Planning ahead of Beijing
16   -- Security Bootstrapping
17   -- Further Webex meetings (2010-10-27)
18   -- I-D deadline at 2010-10-18 (initial) and 2010-10-25 (update)
22Carsten welcomes the participants and introduces the agenda.
23Akbar Rahman asks about another CoAP plugfest at IETF79 in Beijing --
24see also discussion at the end.
26Carsten quickly goes through the status of the documents that are WG
27documents or are candidates for becoming ones:
29draft-shelby-core-link-format   -00     2010-09-28
30draft-ietf-core-coap            -02     2010-09-27      Active  2/24
31draft-hartke-coap-observe       -02     2010-08-24
32draft-bormann-core-coap-block   -00     2010-08-24
34draft-shelby-core-link-format has been split off from coap-02, as
35discussed on the list.  While draft-hartke-coap-observe and
36draft-bormann-core-coap-block were already discussed in the previous
37Webex call, these had been newly submitted/split off, so there is some
38space for discussion at this call.
40Akbar mentioned that he is attempting to split off their Group
41communication / sleeping nodes draft; the intention is to spawn two
42new documents: one about group communication (to be integrated with
43the one by Kerry Lynn) and one about sleeping nodes.
44The group communication document is on track for Beijing -00 deadline.
45Not so sure about the sleeping nodes document.
47Carsten noted that, as the current deliverables are chartered to
48complete in December, Beijing will be the last physical meeting of the
49WG in the current schedule.  It would therefore help to have these
50documents a week earlier than cut-off date; enabling discussion and
51possibly a re-spin before the final deadline.
53Carsten asked whether any other documents are in the pipeline for
54Beijing that we should be aware of -- silence.
58Zach presented the updates to draft-ietf-core-coap and the split-off
59draft-shelby-core-link-format submitted earlier this week (slides are at
62<Slide 2: Changes in coap-02>
64Zach: Implemented the list of tickets, straightforward changes.
65Better in line with RFC 2616. Use of Uri-authority clarified.
66Resource discovery section split off to separate document
67draft-shelby-core-link-format based on decision in Maastricht.
68Placeholder section on security started by Zach.
70Carsten mentioned that there are security considerations in some
71satellite documents. It might be useful to move the discussion of the
72CoAP threat model to the base document.
74<Slide 3: Finishing the Security Section>
76Zach: The objective is to submit a coap-03 before the Beijing
77deadline, focusing on a better security section (otherwise, bugfixing
80Description of how to secure CoAP should be content of the section.
81Mention IPsec, DTLS.  Point to bootstrapping document.
82Zach would be happy to hear feedback about the section.
84Cullen volunteers to help writing text on DTLS.
86Zach: Solution of threats is not needed, but identification of the
87threats is needed.  Anyone help with the threats?  Rene volunteers.
89Kerry wonders whether the MSEC work might bring something to the table
90for multicast and IPsec or higher protocols.
91A discussion ensues on other then stream-(session-)based models (such
92as IPsec or DTLS).
93Cullen mentions that the charter brings up CMS, considers
94session-/stream-based much simpler though:  It is unlikely that we
95will find the magic bullet that suddenly simplifies CMS.
96Zach agrees that we should at least have a section on CMS.
97DTLS is simpler, IPsec even simpler.
98Carsten points out that Bob Moskowitz' work on a HIP diet exchange
99would lend itself naturally to work with IPsec (as HIP usually uses
101Cullen points out that 50 different ways to do security is a problem.
102More than one way will be needed, but not 50.
104Zach proposes to keep the outline close to what we have, describe
105IPSec and DTLS each in one configuration (just DTLS or just IPSec
106won't work), and reference payload encryption.
108Akbar reminds us that the existing Web world has HTTPS as a standard
109security protocol; is there an analogue at a CoAP level?
110Zach: last bullet point on this slide: CoAPS.
112A discussion of port number allocation ensues.
113Zach: Do we need to register a separate CoAPS port?
114Cullen thinks that a separate port number for CoAPS is reasonable;
115running both on same port would need a mechanism like STARTTLS that
116would require extra RTTs.
118Kerry asks about the impact on 6LoWPAN header compression.
119We would like to be able to use ports in the compressed range.
120These are in dynamic space; this argues for requiring the same
121resources to be available from multiple ports.
122Otherwise, when storing URIs, a port change would break the URI.
123Zach asks how is this in the HTTP world.
124Carsten points out that the assumption is that a different port is a
125completely different server, with a different URI space, and calls
126Kerry's idea to make the port number irrelevant for the URI interesting.
128Kerry: Even IP addresses may not be static.
129Lifetime of the binding should not be longer than DHCP.
130Zach: Let's stick with HTTP model.
131Different port is a different server, because we have the
132requirement to run multiple servers on the same node.
133This does not stop you from serving the same resources on different
134ports.  /.wellknown/core would be served on the default port, would
135contain pointers to other (possibly dynamic) ports.
136Requiring them to be the same would be a problem...
137I.e., dynamic ports should be made discoverable.
138Kerry states that in HTTP/HTTPS, the convention is to serve the same
139resources.  Cullen points out that these may generally be similar, not
140the same (e.g., http://x/y might redirect to secure https://x/y).
142Zach: registering a port in the compressed range would require changes
143to 6LoWPAN.  Cullen argues that this might be a very simple change.
144Zach: The 61616 is not reserved for just CoAP.  DNS-SD might find the ports.
145Carsten points out that there is little need to transfer the scheme in
146coap, as by the time that happens the client already has decided
147between raw UDP and DTLS. (It might be useful to find out whether the
148server can look at the packets and decide which one it is.)
150<Slide 4: Threat Analysis>
152Any other comments on the security?
153Rene Struik and Cullen volunteer to help.
155<Slide 5: core-link-format-00>
157Zach: ABNF is reused from draft-nottingham-http-link-header --
158forces us to use quotations etc.  Comma notation stays the same.
159We need to decide on the character set: US-ASCII, TBD?
161The main discussion point is the meaning of the relation attribute.
162As this points from the description of a server to a service on that
163server, the "service" relation seems appropriate.  Syntax-wise, we are
164extending the HTTP link header.  The previous discussion of DNS-SD and
165mDNS are removed from link-format document, as that kind of service
166discovery is a different issue. Is this discussion needed in base
169Kerry: The text from CoAP needs to be reworked. It is in charter. A
170more scalable solution is needed. Link-by-link information extraction.
172Zach: Do WE need to define DNS-SD?  There was considerable pushback in
173Maastricht.  Web discovery vs. DNS-SD.  Might have separate draft on
174DNS-SD.  Might use link-format to create DNS-SD records.
176Carsten says that this might be the job of a Roadmap document, an
177overview document that explains how to glue the components together.
178Carsten: In IETF protocol standards not system standards, but here we
179need system overview.
180Cullen: informational document with pointers.
181Akbar: Does this need to be ready by Beijing?
182Cullen: Probably after Beijing.
183(There is some discussion on why this isn't properly a BCP.)
185Zach: The URI path was changed to /.well-known/core (/r was to short
186to be registered).  Filtering was changed to a MAY: if a simple
187implementation does not understand the query part, return just as if
188the query was not there.  For a client, implementation wise this is
189not much different.
191A discussion ensued why the resolution of Issue 21 (Resource discovery
192changes): removed the discussion of multicast.
193Zach pointed out that multicast is irrelevant to link-format.
194If the protocol used supports multicastf, good.
195Mentioning multicast caused push-back because of DNS-SD (mDNS).
196Kerry: We are planning to do multicast with CoAP.
197Zach: We are not prohibiting multicast.  However, Carsten has pointed
198out that the multicast text was the weakest part of -01 (apart from
200We might want to do more multicast testing on Plugfest.
201Peter: How do you do REST over multicast? Multiple responses are
202interesting in an HTTP gateway?
203Akbar: As part of the groups communications document we'll take a stab
204at that.
205Zach: Does multicast even make sense for an HTTP proxy?
206In the implementation, noticed waiting for multiple responses from a
207multicast request was a lot like waiting for subscription responses
208(on a different time horizon).
209Kerry: There was an old I-D from Microsoft that had Group URIs; two
210separate schemes, one for multicast requests.
211(Discussion of Multicast vs. REST)
212Zach: This is a group of authorities.
213Peter: REST: resource has a description, this is a special resource
214that has different descriptions.
215Zach: we have to look at the Microsoft work.
216Cullen: Studied a lot in WebDAV... WebDAV area might help. Figure out
217what we need.
218Zach: Let's talk to Lisa about this.
219Zach: Pass this on to the list.
223Carsten: we now have three documents that are candidates for WG
224adoption.  draft-shelby-core-link-format is not really new (just split
225out from draft-core-coap-02), but we can ask all of them in a batch.
226At the last meeting we already discussed
227draft-bormann-core-coap-block-00 and draft-hartke-coap-observe-02, and
228some people said there was not enough time to look at these (although
229these were just a splitoff and a minor update).  Any new
230considerations on the two drafts within the last month?
232Kerry: I wanted to do a survey about lightweight transaction
233protocols.  I did discover that the WAP forum put considerable effort
234into a transaction layer for non-idempotent operations.
235I'm still thinking about this. But there should be no hold up.
236Carsten: block is a baseline protocol, if a more efficient mechanism
237(e.g., selective acknowledgment) is needed, it can be done later.
239Peter: Zach and I had a discussion on the mailing list about handling
240big ressource, losses, automatically using block on startup.
241How do you do the initial negotiation?
242Carsten: Block option is an option. You don't need to implement it,
243but can still know what it means when it appears.
244Peter: I think that the client needs to request block option for
246Zach: Take that to the list...
247Carsten: We need to discuss this on the list with detailed examples of
248the problem.
249Zach: But this should not hold up WG adoption.
250Peter: One paragraph will fix it.
254Re Planning for Beijing:
255Carsten reminded the WG that there are 2 deliverables on the agenda
256for this year. Security bootstrapping is progressing a bit slow.
258Behcet Sarikaya asked Colin O'Flynn to give an update.
259Colin: With the current draft; we are moving towards specific examples
260and actual protocols being used.  So far it has been mostly about
261bootstrapping, moving to more about security setup. Behcet is picking
262up some of this and I'll be dropping off from the draft.
263Behcet: We are shooting for the I-D update deadline 2010-10-25.
264Carsten: More than one iteration before Beijing would be preferable.
265Behcet: Will try, by 2010-10-18.
269Carsten proposes to stick with the plan to have another WebEx meeting
270on 2010-10-27 at 1500 UTC, i.e. after the Internet-draft deadlines:
271Initial deadline is 18th, update deadline is 25th.
272Zach: Works for me.
274Cullen: There might be problems with scheduling so close to the
275meeting. I will look into that.  [After the meeting, we ascertained:
276There are no problems with a phone call.]
278Carsten: Let me repeat our intention to have a Plugfest in Beijing, on
279Sunday 2010-11-07 from 10 to 16. We have asked for a room to be
280assigned, but have to wait for confirmation.
281Will be announced on mailing list when organization is finalised.
283Cullen and Kerry will not be in Beijing.
284Zach, Akbar and Carsten are planning to be there; Peter is trying.
286Zach proposes to have a "Plugfest revisited" for people in other
288Carsten: What time would work (timezones/continents)?
289Zach: Check on mailing list with people who want to participate.
291Akbar asks whether we will have online plugging facilities available
292before the meeting.
293Zach: Yes, we will be hosting our resource directory again.
294Carsten/Zach: Multicast check needs some equipment.
295Zach: Hard to run multicast with remote participants.
296Zach: Getting into shape for Beijing: A Wireshark CoAP dissector would
297be a useful tool.  Shoichi Sakane has been working on that.
299Meeting closes at 16:30Z.