[09:56:09] --- yowada has joined
[09:56:24] --- yowada has left
[10:03:33] --- igarashi has joined
[10:03:44] --- pete.stpierre@gmail.com has joined
[10:04:36] <pete.stpierre@gmail.com> Carsten is doing a brief introduction.
[10:05:01] <pete.stpierre@gmail.com> C: please be aware of the IPR principles according to RFC 3979
[10:05:21] <pete.stpierre@gmail.com> reviewing agenda
[10:07:20] --- dthaler has joined
[10:09:00] <pete.stpierre@gmail.com> Carsten: Draft status review
[10:09:14] <pete.stpierre@gmail.com> What is 6lowpan? (slide)
[10:09:29] <pete.stpierre@gmail.com> C: we're trying to solve a number of problem
[10:10:09] <pete.stpierre@gmail.com> status - 6lowpan-probem is @IESG, as is the format draft
[10:10:30] <pete.stpierre@gmail.com> we're technically done - we're not actually chartered for anything we're doing today.
[10:10:41] <pete.stpierre@gmail.com> we need to finalize charter proposal & start future work
[10:11:06] <pete.stpierre@gmail.com> DCuller: do we need to demonstrate interop to to advance.
[10:11:27] <pete.stpierre@gmail.com> Carsten: Yes we need to demonstrate a level of interop.
[10:11:32] <pete.stpierre@gmail.com> get feedback from implementors
[10:12:44] <pete.stpierre@gmail.com> rechartering status:
[10:13:03] <pete.stpierre@gmail.com> Geoff mulligan(GM) speaking
[10:13:22] <pete.stpierre@gmail.com> GM: we sent out an e-mail with proposed chartering items
[10:13:34] <pete.stpierre@gmail.com> chairs feel they have consensus on 5 items
[10:13:49] <pete.stpierre@gmail.com> question is on mesh under vs. route over.
[10:14:14] --- keyajima has joined
[10:14:23] <pete.stpierre@gmail.com> slide: produce "6lp mesh routing" to evaluate different protocols for use in 6 lowpan
[10:14:50] <pete.stpierre@gmail.com> mesh routing will not be in the text of the charter so we can move forward with other items under approved charter
[10:15:10] --- ltn22@jabber.org has joined
[10:15:27] <pete.stpierre@gmail.com> Mark(AD) speaking:
[10:16:00] <pete.stpierre@gmail.com> leaving #5 off will allow group to focus on work without burden of getting charter accepted by IETF
[10:16:05] --- sureshk has joined
[10:16:14] <pete.stpierre@gmail.com> part of routing debate will be held in other WGs
[10:16:38] <pete.stpierre@gmail.com> need to understand what IP routing guys will do before 6lp moves forward in this area.
[10:16:57] <pete.stpierre@gmail.com> still have work to do in plenty of other areas
[10:17:17] <pete.stpierre@gmail.com> Gabe Montenegro: this is a change from the consensus a while ago.
[10:17:39] <pete.stpierre@gmail.com> GM: back with trill, there was room for work in multiple groups
[10:18:11] <pete.stpierre@gmail.com> GM: this group would adapt work from manet, etc.
[10:19:16] <pete.stpierre@gmail.com> Geoff: the intent wasn't to uncharter other groups. (geoff opinion: IP routing isn't within 6lp charter)
[10:19:50] <pete.stpierre@gmail.com> Geoff: some contention whether l2Routing is necessary. Do we want to wait to recharter?
[10:20:09] <pete.stpierre@gmail.com> Gabe: does not agree it should delay recharter
[10:20:36] <pete.stpierre@gmail.com> Mark: has to take charter to higher ups. leaving routing in will cause questions with other IESG members.
[10:21:11] <pete.stpierre@gmail.com> Mark: IESG needs to make sure things are clear who is providing what
[10:21:45] <pete.stpierre@gmail.com> Mark: Other 4 charter items are clear and can be "fast tracked". should be accepted and we can begin work.
[10:22:00] <pete.stpierre@gmail.com> Mark: mesh under or IP routing work can be chartered later
[10:23:09] --- yowada has joined
[10:23:10] <pete.stpierre@gmail.com> Carsten: is it possible to work on these requirements without answering the over/under routing question.
[10:23:31] <pete.stpierre@gmail.com> kim: I'm curious about why we have to consider route over in this working group
[10:23:54] --- ShoichiSakane has joined
[10:25:16] <pete.stpierre@gmail.com> kim: many here may not understand what the relationship is. we have limited resources of hardware. we have worked on the mesh items for over a year. do we need to define the routing protocols or just the adaptation? what is the relationship of this WG to others.
[10:25:40] <pete.stpierre@gmail.com> Mark: that is exactly what causes hesitation and wanting to delay chartering that item.
[10:26:11] <pete.stpierre@gmail.com> JP: I don't know how you can specify requirements when you haven't decided the under/over Q.
[10:27:10] <pete.stpierre@gmail.com> JP: Propsal: should the routing area decide to charter a working group, can this group use the work produced.
[10:27:55] <pete.stpierre@gmail.com> mark: lay out the requirements. working out the requirements for mesh under presuposes a solution. it's a chick and egg problem
[10:29:43] <pete.stpierre@gmail.com> Geoff Mul: the working group is done. if we don't get rechartered we dismiss the group. we don't want to do that. we have other work to do. what you (Mark) are proposing is that we get the first 4 items chartered (path of least resistance), while we continue to understand the issues around mesh under/route over. In my view we need to have both. the various ADs don't understand the nuances. we need to educate them what l2 routing is for us.
[10:30:29] <pete.stpierre@gmail.com> geoff M: talked with Phil Levin last night and he is now starting to get it. it's just going to take time. we just need to get the other charter items done so we can get moving.
[10:32:17] <pete.stpierre@gmail.com> David Culler: I'd like to distingush those discussions from 'format'. A lot of what we do it define the packet formats. there is a whole family of discussions on format that need to go forward. is the current format expressive enough to support mesh under. can we support compression of global addrs. General discussion on is the format appropriate.
[10:33:46] <pete.stpierre@gmail.com> speak: I'm in favor of keeping the charter to include under/over. this WG has to be chartered to address this low power device. we start out with something and let others decide what to include and what not to include. waiting on an unchartered group (RSN) is just holding up this group. again - I support rechartering to include mesh under.
[10:33:50] <pete.stpierre@gmail.com> one more comment -
[10:34:16] <pete.stpierre@gmail.com> change of topic: would like to strike the item on stateful header compression.
[10:34:40] <pete.stpierre@gmail.com> speaker: our efforts can be put to better use.
[10:35:26] <pete.stpierre@gmail.com> Carsten: there is a discussion on the agenda for header compression. we will probably revist that issue again and again.
[10:35:37] <pete.stpierre@gmail.com> mark: we can make this decsiion at that point.
[10:36:22] <pete.stpierre@gmail.com> speaker: also - we seem to be making decisions without an architecture document. I thought we had a decsion that 6lp nodes wouldn't do IPsec, but we didn't write it down.
[10:36:52] <pete.stpierre@gmail.com> mark: an arch doc should be at the top of the WG list. it would make things more clear in general. if someone is willing to work on it.
[10:37:01] <pete.stpierre@gmail.com> Geof: will be discussed shortly
[10:37:10] --- fp has joined
[10:37:37] <pete.stpierre@gmail.com> (room noise from construction is making some of this difficult to hear)
[10:39:07] <pete.stpierre@gmail.com> mark: at the end of the day- try to get a hum on whether we should strike item 5 or reduce it to routing requirements or charter mesh routing. between the 3 items the first will get approved more quickly. mark will take whatever we decide to IESG and attempt to defend it.
[10:40:12] <pete.stpierre@gmail.com> speaker: I don't understand why this is a problem
[10:41:10] <pete.stpierre@gmail.com> mark: reiterates that we don't understand the requirements fully and what the IP routing guys are going to meet. it's difficult to decide what needs to be produced in the terms of mesh routing. we don't want two competing groups trying to invalidate each others work.
[10:41:45] <pete.stpierre@gmail.com> geoff: OK -- we're done discussing this. we'll discuss this at the end when we have a presentation on route over. we need to get on with the schedule
[10:41:56] <pete.stpierre@gmail.com> topic: applications scenarios
[10:42:12] <pete.stpierre@gmail.com> geoff: it would be nice to see an architecture
[10:42:47] <pete.stpierre@gmail.com> presentation E. Kim "Design and Application Space for 6lowpan"
[10:43:33] <pete.stpierre@gmail.com> EK: draft will list scnarios and markets to define design parameters
[10:44:33] <pete.stpierre@gmail.com> EK: scenario presents basic parameters (see draft for details)
[10:46:07] <pete.stpierre@gmail.com> EK: for routing we're focusing on the topology
[10:46:58] <pete.stpierre@gmail.com> EK: we address mobilty and types of connectivity (always/intermittent)
[10:47:39] <pete.stpierre@gmail.com> first scenario: structure montoring
[10:50:05] <pete.stpierre@gmail.com> second scenario (new speaker): hospital/home healthcare
[10:51:20] <pete.stpierre@gmail.com> scenario 3: vehicular networks
[10:51:28] <pete.stpierre@gmail.com> motion monitoring - smart roads
[10:51:44] <pete.stpierre@gmail.com> car-to-car work TBD
[10:52:19] <pete.stpierre@gmail.com> new speaker(Dominc Kaspar)
[10:52:38] <pete.stpierre@gmail.com> scenario 4: home and industrial - will collaborate with JP, work TBD
[10:52:50] <pete.stpierre@gmail.com> Scenario 5: agricultural
[10:54:05] <pete.stpierre@gmail.com> scenarios out of scope: no motivation for 15.4 network or regional/wide area
[10:54:20] <pete.stpierre@gmail.com> Questions and future work? - feedback wanted.
[10:55:03] <pete.stpierre@gmail.com> did we capture the imortant dimentions. feedback wanted from industrial partners. please read the draft and comment on the list.
[10:55:27] <pete.stpierre@gmail.com> preso done. carsten speaking:
[10:55:52] <pete.stpierre@gmail.com> this may seem boring, but is important that we can use this work as a base for talking about actual industry requirements
[10:56:48] <pete.stpierre@gmail.com> please provide feedback and additional scenarios to the authors.
[10:57:23] <pete.stpierre@gmail.com> floor speaker: this is important and we should include things that aren't 15.4 based, as we may still benefit those problem areas.
[10:57:25] --- arifumi has joined
[10:57:57] <pete.stpierre@gmail.com> Geoff M: 15.4 is engrained in our charter/mindset. but we can include discussions about other area.
[10:58:56] <pete.stpierre@gmail.com> Phil levis: point of concern: some parts of the document included conclusions (ie. what is the topology). To specific in solving requirements, not just presenting them. makes assumptions on ways to solve a problem when there are multiple solutions.
[11:01:07] <pete.stpierre@gmail.com> floor comment: I'm new to 6lowpan, one important area to include is industrial sensing and monitoring, factories, large currently wired scenarios
[11:01:48] <pete.stpierre@gmail.com> David Culler: we need to talk about workload we're carrying. it involved traffic flow. what we're carrying and what the node density is.
[11:02:50] <pete.stpierre@gmail.com> Geoff: wrapup - ISASP100 has adopted 6lowpan for industrial sensing (shell, exxon, etc) can affort expensive radios/equipment.
[11:03:17] <pete.stpierre@gmail.com> next topic: 6lowpan archicture ID (JP Vassur presenting)
[11:03:45] <pete.stpierre@gmail.com> JP: Geoff and I had hoped to have this document planned for Chicago mtg, but were not able to complete.
[11:03:53] <pete.stpierre@gmail.com> first revision looking to end of august.
[11:04:11] <pete.stpierre@gmail.com> will be a very iterative process
[11:04:25] <pete.stpierre@gmail.com> see slides for proposed TOC
[11:07:44] --- rbless has joined
[11:07:53] <pete.stpierre@gmail.com> Carsten: we need to be clear what we're doing with this arch. draft.
[11:08:56] <pete.stpierre@gmail.com> JP: we can send to the list other arch. documents as an example.
[11:09:13] <pete.stpierre@gmail.com> carsten: we have a 6lowpan wiki - could use that to collect TOC items.
[11:09:33] <pete.stpierre@gmail.com> Carsten: can be organized in a draft later
[11:10:13] <pete.stpierre@gmail.com> Samita: this is a good way to put the information together. show people how they can make use of 6lowpan architecture.
[11:10:45] <pete.stpierre@gmail.com> geoff: we don't want to take this discussion into TOC details. let's use the list and wiki to discuss
[11:11:14] <pete.stpierre@gmail.com> Samita: in the ND draft we assume some architecure the draft is based on and we would like to contribute that to this draft.
[11:11:34] <pete.stpierre@gmail.com> geoff: let's hum on whether this is a good idea (an arch. doc).
[11:56:21] --- LOGGING STARTED
[12:00:54] --- jhlim has joined
[12:01:48] --- jhlim has left
[12:04:17] --- jhlim has joined
[12:04:23] --- jhlim has left
[12:06:33] --- dthaler has joined
[12:07:55] --- igarashi has joined
[12:08:12] --- keyajima has joined
[12:08:15] <dthaler> discussion of multiple prefixes
[12:08:23] <dthaler> on the same link
[12:10:12] <dthaler> and impact on compression, since compression proposal could only compress one
[12:10:51] <dthaler> next presentation
[12:11:04] <dthaler> what it will take to advance format doc to draft std
[12:12:26] <dthaler> interop testing
[12:13:11] --- behcet.sarikaya has joined
[12:14:28] --- pete.stpierre@gmail.com has joined
[12:14:43] --- pete.stpierre@gmail.com has left
[12:14:43] <dthaler> currently doc is mac-layer agnostic
[12:14:56] --- pete.stpierre@gmail.com has joined
[12:19:46] --- pete.stpierre@gmail.com has left
[12:24:00] --- pete.stpierre@gmail.com has joined
[12:24:02] <dthaler> routing issue... how should we handle it
[12:24:28] <dthaler> 1) remove from charter for now?
[12:24:39] <dthaler> 2) put requirements work into the charter but not solutions work
[12:25:37] <dthaler> 3) put solutions work in the charter
[12:26:06] --- behcet.sarikaya has left
[12:27:23] <dthaler> Gabriel Montenegro: 4? requirements, but do some work here?
[12:27:27] <dthaler> Carsten: same as 3
[12:33:41] --- pete.stpierre@gmail.com has left
[12:44:46] --- shamus has joined
[12:45:32] --- shamus has left
[12:54:26] --- keyajima has left
[12:54:50] --- keyajima has joined
[12:55:21] --- igarashi has left: Computer went to sleep
[12:55:24] --- keyajima has left
[13:06:18] --- keyajima has joined
[13:11:17] --- keyajima has left
[13:11:49] --- keyajima has joined
[13:13:05] --- dthaler has left
[13:20:52] --- keyajima has left
[13:43:41] --- dthaler has joined
[13:49:34] --- keyajima has joined
[13:54:12] --- dthaler has left
[13:54:19] --- dthaler has joined
[13:57:22] --- dthaler has left
[13:59:13] --- keyajima has left: Replaced by new connection
[15:36:27] --- ShoichiSakane has joined
[15:36:48] --- ShoichiSakane has left