(2:58:25 AM) spencerdawkins: Spencer is being volunteered to jabber scribe - please feel free to correct anything I type, because I'm in a coma from taking notes yesterday
(2:59:42 AM) spencerdawkins: and this is, of course, the smart objects tutorial ...
(3:05:18 AM) ꈲ [cabo--tzi--org@jabber.org/cabo] entered the room.
(3:06:21 AM) spencerdawkins: Unlike the workshop yesterday, this IS under the IETF standards policy and covered by IPR policy/note well
(3:08:26 AM) suzukisn [suzukisn@jabber.org/157a6e5974abecce] entered the room.
(3:08:35 AM) adrianfarrel: "interesting" comments only?
(3:08:37 AM) sal [sal@jabber.freenet.de/Salvatore Loreto’s MacBook Pro] entered the room.
(3:08:40 AM) angelo.castellani [angelo.castellani@gmail.com/airEB27E4F1] entered the room.
(3:08:47 AM) spencerdawkins: And thanks to our sponsors ... 
(3:08:56 AM) sal: :-)
(3:09:06 AM) spencerdawkins: ("for some value of 'interesting'...")
(3:09:57 AM) spencerdawkins: Getting Started with IPv6 in Low-Power Wireless Personal Area Networks (Carsten Bormann)


(3:10:45 AM) Alissa Cooper [coopdanger@jabber.org/Alissa-Cooper] entered the room.
(3:10:52 AM) Alissa Cooper left the room.
(3:11:04 AM) Gonzalo [gcamaril@jabber.org/Home] entered the room.
(3:11:38 AM) spencerdawkins: Core Internet > "fringe Internet" -> Internet of Things
(3:12:16 AM) spencerdawkins: Up to a trillion nodes (and that's not too far out)
(3:14:33 AM) spencerdawkins: wires and wiring are too expensive for most of these notes. (1 billion nodes = GDP of Kuwait)
(3:18:44 AM) adrianfarrel: So, we are making these "nodes" out of silicon. So everytime we make a node we reduce the number of grains of sand available in the world. What impact does this have on IPv6 address availability?
(3:20:13 AM) spencerdawkins: constrained devices are constrained on processng power, storage, and battery life - so they sleep 99 percent of the time.
(3:21:17 AM) angelo.castellani left the room.
(3:21:27 AM) spencerdawkins: Moore's Law is not our friend for these devices (power consumption grows at the same rate)
(3:23:26 AM) spencerdawkins: We use cheap, old chips so we don't get much bump from Moore's Law
(3:25:02 AM) spencerdawkins: counter-intuitive - chips that use more power receiving than sending ...
(3:25:58 AM) spencerdawkins: most nodes aren't listening most of the time...
(3:27:44 AM) spencerdawkins: assume links are slow, lossy, variable, limited packet sized
(3:29:26 AM) spencerdawkins: can't rely on multicast - this is a mindset shift...
(3:34:59 AM) spencerdawkins: four working groups in this space - 6LowPAN, ROLL, CoRE, LWIG
(3:35:59 AM) spencerdawkins: Not doing a new Internet - optimizing the architecture we've already got.
(3:37:41 AM) dcrocker [dcrocker@jabber.org/BBTAB] entered the room.
(3:43:20 AM) spencerdawkins: RFC 4494 - encapsulation, fragmentation, mesh forwarding, mimimal use of complex MAC-layer concerpts
(3:46:53 AM) spencerdawkins: "dispatch" byte acts as ethertype (there's not something like this in 802.15.4)
(3:48:21 AM) spencerdawkins: New 6LowPAN header compression (still in drat form) does UDP over IPv6 in 6 bytes
(3:51:05 AM) spencerdawkins: IESG DISCUSSes were about compressing the UDP checksum - but that's still in the current version of the draft
(3:51:51 AM) spencerdawkins: Dave Crocker - are you doing fragmentation and letting the far end reassemble?
(3:52:13 AM) dcrocker: I don't do fragmentation.
(3:52:21 AM) dcrocker: Oh. That wasn't a question to me? (...)
(3:53:02 AM) spencerdawkins: sorry - no, i'm taking notes and don't know how to flag the person asking the question :-)
(3:53:44 AM) spencerdawkins: 6LowPAN allows you to forward fragments without reassembling the packet
(3:54:01 AM) dcrocker: (yeah but it's early and the jabber window isn't all that active and I felt like indulging in a little creative misunderstanding.)
(3:55:31 AM) spencerdawkins: still have the same problem with IP fragmentation that everyone else has - want transports to handle this on their own!
(3:56:26 AM) spencerdawkins: both mesh-under and route-over are included in a single architecture
(3:56:40 AM) adrianfarrel: Dave, it isn't really a question of whether you do fragmentation. It is more about whether someone who has to carry you needs to fragment you. And if they do, it is important to understand how the bits are put back together.
(3:57:56 AM) spencerdawkins: :-X
(3:58:44 AM) spencerdawkins: no one in 6LowPAN actually wants to do mesh-under...
(4:03:33 AM) spencerdawkins: not really interested in host-host communication because the other host is probably turned off anyway ... hosts talk to routers.
(4:08:16 AM) angelo.castellani [angelo.castellani@gmail.com/air9491DB75] entered the room.
(4:08:47 AM) spencerdawkins: don't have a duplicate address detection at MAC layer (did have it, but it's complex and they assumed it wasn't needed)
(4:10:41 AM) Cullen Jennings [cullenfluffyjennings@gmail.com/Adium51E361D8] entered the room.
(4:11:12 AM) spencerdawkins: using RFC 4861 neighbor discovery with Address Registration Option (this is new)
(4:12:02 AM) angelo.castellani: will the slides be available online?
(4:14:03 AM) spencerdawkins: traditional header compression is flow-based stateful, RFC 4944 is stateless
(4:14:43 AM) spencerdawkins: @angelo.castellani - i expect so, but hannes didn't have carsten's slides until he arrived in the room :D
(4:19:18 AM) spencerdawkins: would we do header compression if we had a longer payload? carsten thinks so, because it lets us finish sending/receiving sooner (back to battery life)
(4:21:59 AM) spencerdawkins: can also compress "next protocol" headers, including UDP port numbers
(4:23:12 AM) angelo.castellani left the room.
(4:23:13 AM) spencerdawkins: new proposal to compress payloads with header-like characteristics
(4:25:19 AM) spencerdawkins: Current -HC and -ND dtafts are stable
(4:25:38 AM) angelo.castellani [angelo.castellani@gmail.com/airF86FDEE2] entered the room.
(4:27:00 AM) spencerdawkins: ? Is 6LowPAN still interoperable with IPv6?
(4:28:05 AM) spencerdawkins: Haven't actually made changes to IPv6 end-to-end, still interoperates
(4:28:57 AM) spencerdawkins: ?why speak IP end-to-end? 
(4:29:46 AM) spencerdawkins: don't want to have to evolve gateways - limits evolition and innovation
(4:30:56 AM) spencerdawkins: ? security is ignored in header compression? cannot compess IKE, etc.
(4:31:47 AM) spencerdawkins: can't compress security because there's no redundancy
(4:32:07 AM) spencerdawkins: but AH isn't encrypted ... 
(4:32:26 AM) spencerdawkins: might be able to do this, don't remember why we don't :D
(4:32:54 AM) Cullen Jennings: I'm not sure I buy the generic statement that you can't compress encrypted data. 
(4:33:27 AM) spencerdawkins: GHC getting 1.65-1.85 compression - perhaps generic compression is better?
(4:34:35 AM) adrianfarrel left the room.
(4:34:40 AM) Stewart Bryant left the room.
(4:37:05 AM) suzukisn left the room.
(4:37:46 AM) suzukisn [suzukisn@jabber.org/f52c26600944a7f2] entered the room.
(4:40:32 AM) Stewart Bryant [stewart.bryant@gmail.com/stewart-brB5D31F81] entered the room.
(4:45:04 AM) spencerdawkins: Understanding Routing in Low-Power and Lossy Networks (JP Vasseur)


(4:45:49 AM) spencerdawkins: Microcontroller capabilities aren't changing in the last 10 years ...
(4:46:30 AM) spencerdawkins: very large scale - even if you aren't battery-powered, you don't want to use more energy with smart meters than you save ;-)
(4:46:31 AM) adrianfarrel [adrianfarrel@jabber.org/c2f180c235b72129] entered the room.
(4:47:05 AM) ꈲ left the room.
(4:47:51 AM) spencerdawkins: not talking about converging a few thousand routers - scale is much larger for Internet of Things
(4:49:49 AM) spencerdawkins: not just wireless - power line communication has own unique problems, very similar to wireless
(4:50:28 AM) spencerdawkins: very hard to model both types of networks
(4:51:47 AM) spencerdawkins: cannot converge fast without oscillating on these networks
(4:52:28 AM) spencerdawkins: ? what conditions are traces from in your presentation?
(4:52:59 AM) spencerdawkins: 802.15.4 in outdoor environments, 60-100 percent packet delivery
(4:54:35 AM) spencerdawkins: ROLL formed in 2008, goal was to change directions (trend was to have a public Internet completely surrounded by gatewayed proprietary networks)
(4:54:48 AM) ꈲ [cabo--tzi--org@jabber.org/cabo] entered the room.
(4:56:06 AM) spencerdawkins: ROLL did requirements from4 vertical environments
(4:58:00 AM) spencerdawkins: five criteria - routing table scalability, loss response, control cost, link cost, node cost
(4:59:42 AM) spencerdawkins: all existing routing protocols did not meet all o these criteria, so needed to develop a new routing protocol
(5:00:33 AM) spencerdawkins: RPL stole ideas from deployed proprietary protocols - not a lot of invention
(5:01:56 AM) angelo.castellani left the room.
(5:05:21 AM) angelo.castellani [angelo.castellani@gmail.com/airCAF6B69D] entered the room.
(5:07:36 AM) catmv [catmv@jabber.org/coba] entered the room.
(5:10:32 AM) spencerdawkins: (JP talking through slides on RPL internals - not trying to captutre this in my notes)
(5:10:44 AM) catmv left the room.
(5:12:55 AM) dcrocker left the room.
(5:13:11 AM) spencerdawkins: adaptive link metrics not new (this was in ARPANETII), but it's complex and hard to control (with routing oscillations).
(5:15:47 AM) spencerdawkins: routing metrics include node metrics and link metrics
(5:23:53 AM) spencerdawkins: using tricklle timer to reduce redundant messages
(5:30:06 AM) ꈲ left the room.
(5:30:09 AM) ꈲ [cabo--tzi--org@jabber.org/f4fd8c2837cc638d] entered the room.
(5:33:51 AM) sal left the room (Replaced by new connection).
(5:33:51 AM) angelo.castellani left the room.
(5:35:06 AM) ꈲ left the room.
(5:39:14 AM) spencerdawkins: (JP showing how repair works)
(5:43:32 AM) spencerdawkins: low-passfilters can dramatically improve routing stability.
(5:44:04 AM) sal [sal@jabber.freenet.de/Salvatore Loreto’s MacBook Pro] entered the room.
(5:44:30 AM) spencerdawkins: Is RPLready for "prime time"? More than 15 implementations including commercial products this year.
(5:45:13 AM) spencerdawkins: Adopted by ZIGBEE/IP, Wavenis, IEEE P1901.2 ... 
(5:46:05 AM) spencerdawkins: Two interop events (IPSO testing storing mode, ZIGBEE/IP testing non-storing mode)
(5:46:49 AM) spencerdawkins: for four implementations - under 2K of RAM, 10K of flash
(5:48:22 AM) spencerdawkins: ROLL rechartering - possible candidates are lightweight security, label switching, routing admission control, PCE
(5:48:30 AM) Gonzalo left the room.
(5:48:36 AM) sal left the room.
(6:51:53 AM) suzukisn [suzukisn@jabber.org/7061067ce0c988e2] entered the room.
(6:51:53 AM) sal [sal@jabber.freenet.de/Salvatore Loreto’s MacBook Pro] entered the room.
(6:51:53 AM) Stewart Bryant [stewart.bryant@gmail.com/stewart-br17A1A5BC] entered the room.
(6:51:53 AM) ꈲ [cabo--tzi--org@jabber.org/2ebfd621d3cc8a73] entered the room.
(6:51:53 AM) spencerdawkins [spencerdawkins@gmail.com/HomeB7956A6D] entered the room.
(6:51:53 AM) stpeter has set the subject to: CoRE WG | http://tools.ietf.org/wg/core/
(6:52:57 AM) Stewart Bryant left the room.
(6:55:48 AM) Stewart Bryant [stewart.bryant@gmail.com/stewart-br2F8A9253] entered the room.
(7:03:18 AM) spencerdawkins: Introduction to Resource-Oriented Applications in Constrained Networks (Zach Shelby)


(7:05:43 AM) spencerdawkins: Not just the Internet of Things, but the Web of Things
(7:06:59 AM) spencerdawkins: With RESTas the new wasp-waist of the Internet ... um, the Web
(7:09:28 AM) spencerdawkins: "The Web is the only way we know that could scale to billions of devices" - loosely coupled, resilient, with intermediate proxies
(7:09:57 AM) Stewart Bryant left the room.
(7:12:09 AM) spencerdawkins: Focusing on URLs, not URNs, initially.
(7:14:39 AM) spencerdawkins: ... landing right in the ugly middle of REST vs SOAP ... :-x
(7:28:53 AM) spencerdawkins: ? What is NOT part of the Web? 
(7:29:39 AM) spencerdawkins: it's not just HTTP - even though people think you have to be doing HTTP to be doing the Web.
(7:30:15 AM) spencerdawkins: ?What is REST the theory vs REST the actual HTTP-over-TCP that's out there today?
(7:30:43 AM) spencerdawkins: This is really a grey area.
(7:31:20 AM) spencerdawkins: Shelby - agree! but we're te talking about more than one protocol
(7:31:46 AM) spencerdawkins: ?Using REST versus RESTful might make the distinction clearer
(7:31:56 AM) angelo.castellani [angelo.castellani@gmail.com/airE8F0755A] entered the room.
(7:32:20 AM) Cullen Jennings [cullenfluffyjennings@gmail.com/Adium3EB67729] entered the room.
(7:32:39 AM) spencerdawkins: CoAP can be pipelined
(7:35:51 AM) spencerdawkins: Encoding options as deltas from previous options - requires option ordering, and that helps with small devices trying to parse the message.
(7:37:34 AM) spencerdawkins: This is also a pseudo-compression mechanism - you can encode more than 15 options by using deltas
(7:42:02 AM) spencerdawkins: ?Why don't you return a result immediately?
(7:42:19 AM) spencerdawkins: Server may not have a result (POST, etc.)
(7:43:09 AM) spencerdawkins: ?Why not reuse Token for multiplexing?
(7:43:15 AM) spencerdawkins: Just more complex
(7:43:44 AM) spencerdawkins: Same problems reusing toekns and message IDs - how long you need to wait
(7:45:31 AM) spencerdawkins: ?Do applications know whether they will get their response back on an ACK or in a later message? 
(7:45:50 AM) spencerdawkins: No, need to handle either possibility
(7:46:47 AM) spencerdawkins: ? How do you know the request has been lost? 6LowPAN can have a large variation in RTT, etc.
(7:48:09 AM) spencerdawkins: Don't have a good answer, not estimating RTTs, either - using fixed timeouts. Working with Lars on this, congestion control, etc. Said we needed more work on Internet of Things transport at the workshop yesterday.
(7:50:52 AM) spencerdawkins: CoAP includes Observer model (register for ongoing state changes for a resource).
(7:52:53 AM) spencerdawkins: Allows the server to push content to the client as states change
(7:53:31 AM) angelo.castellani left the room.
(7:54:51 AM) spencerdawkins: CoAP includes "block transfer" - allows transfers of "chunks" that are too big to be carried in a single message.
(7:56:12 AM) spencerdawkins: Don't support block transfers in both directions (more of a SOAP thing than a REST thing).
(7:59:52 AM) spencerdawkins: DNS-SD for Service Discovery, Resource Discovery with CoRE Link Format - web linking re: RFC 5988. Can be used to discover the links available from a server.
(8:02:01 AM) Stewart Bryant [stewart.bryant@gmail.com/stewart-br80BCF79F] entered the room.
(8:02:36 AM) spencerdawkins: Could reasonably do IETF work on formats (how do you encode a binary integer in XML?)
(8:04:05 AM) Stewart Bryant left the room.
(8:04:55 AM) spencerdawkins: ?Interest from other SDOs? 
(8:04:58 AM) spencerdawkins: ETSI looking at CoAP, also seeing interop testing in industry forums. 
(8:05:55 AM) spencerdawkins: ?CoAP as additional protocol? What about congestion avoidance? Especially with multicast? Do you say this is "local-only"?
(8:06:35 AM) spencerdawkins: Lars Eggert has a good draft about this (thinking about credit control, which works for multicast as well).
(8:07:17 AM) spencerdawkins: ? Also thinking about monitoring applications on systems, not at all a sensor network but it starts to look like one.
(8:07:44 AM) spencerdawkins: Need to get away from binary UDP protocols - haunting us for 20 years
(8:08:11 AM) spencerdawkins: ?What about XDR? Libraries, experience, works well ...
(8:08:41 AM) spencerdawkins: ? MTU - how do you figure this out using UDP? 
(8:09:06 AM) spencerdawkins: Changed this so many times in the working group - read the draft, because Shelby doesn't remember :D
(8:09:40 AM) spencerdawkins: Service Discovery (Stuart Cheshire)


(8:10:23 AM) spencerdawkins: This is service discovery in ZEROCONF/Bonjour (depending on whether you're an Apple Marketing guy)
(8:12:20 AM) spencerdawkins: Wide area converged on IP. LAN has been DIVERGING - lots of chaos...
(8:12:35 AM) Stewart Bryant [stewart.bryant@gmail.com/stewart-br14AE305E] entered the room.
(8:13:07 AM) spencerdawkins: No technical reason that TCP/IP couldn't be as easy to plug in as USB...
(8:13:56 AM) spencerdawkins: Three technologies - naming, addressing, and discovery
(8:17:22 AM) adrianfarrel [adrianfarrel@jabber.org/cea43856a37fc2af] entered the room.
(8:19:37 AM) sal left the room.
(8:20:13 AM) spencerdawkins: Addressing is a done deal. Naming is very close to being an RFC. Discovery is the part that's left to do.
(8:21:00 AM) spencerdawkins: Don't want to add code to small devices - can reuse Multicast DNS for service discovery, and reuse that code.
(8:27:33 AM) spencerdawkins: Using name/address indirection - addresses can change, but names shouldn't change.
(8:32:01 AM) spencerdawkins: Not just lowering support costs, fewer returns, but new product categories, "network products that are a joy to use"
(8:36:37 AM) ꈲ left the room.
(8:37:03 AM) Cullen Jennings left the room.
(8:40:44 AM) spencerdawkins: Awesome hacks - ping the unconfigured device 3 times and it decides "that must be MY address"...
(8:45:40 AM) ꈲ [cabo--tzi--org@jabber.org/a84c7be77fa706ac] entered the room.
(8:46:45 AM) ꈲ: Slides for Zach's and my talk are at http://6lowpan.net
(8:56:30 AM) spencerdawkins: Stuart demo'ed the Apple Bonjour framework as part of his presentation
(9:01:19 AM) spencerdawkins: ? For sleeping - client doesn't change IP address, only sleeps, right?
(9:02:06 AM) spencerdawkins: clients are responsible for renewing DHCP lease, so, if it wakes up and renews its address, it didn't move
(9:02:50 AM) spencerdawkins: this is stale-state garbage collection, so we don't have phantom devices on the network forever
(9:03:12 AM) spencerdawkins: default timeout is 2 hours
(9:03:24 AM) spencerdawkins: ? Is a NAT a problem?
(9:04:51 AM) spencerdawkins: Needs to be on the same LAN segment - there's a "magic packet" that you have to see to wake up. IP doesn't work because you get to the gateway and it does an ARP - and no one answers because the system is asleep :D
(9:05:25 AM) spencerdawkins: subnet broadcast used to work, but has been disabled for a long time, for security reasons
(9:06:17 AM) spencerdawkins: ?How does multicast DNS work for Internet of Things, which has problems with multicast?
(9:07:53 AM) spencerdawkins: "Internet of Things isn't a technology, it's a funding source", but you need to solve the naming/addressing/discovering problem some way, or you'll be manually configuring your Internet of Things.
(9:07:56 AM) adrianfarrel left the room.
(9:08:14 AM) spencerdawkins: You could be using unicast DNS - that would also work
(9:08:36 AM) Stewart Bryant left the room.
(9:10:00 AM) spencerdawkins: Game kits with iPhone 3 uses peer-to-peer bluetooth - with no application configuration
(9:10:11 AM) spencerdawkins: "network configuration" (sorry)
(9:11:40 AM) spencerdawkins: ? We know how to configure names, addresses, and services - what about routers? 
(9:12:48 AM) spencerdawkins: was assuming one subnet, one broadcast domain. that's a great simplifying assumption. appletalk would handle this (back in the day) - something like this might work over IP, but you're trying to connect to the rest of the world - that's more complicated
(9:14:12 AM) spencerdawkins: ? we would still have many link layers - don't see that converging
(9:15:47 AM) spencerdawkins: not opposed to new link layers with new properties - people who invent new link layers ignore IP and think they're in their own little world. Bluetooth could have just done FTP, but they came up with unique file transfer, unique printing ...
(9:16:29 AM) spencerdawkins: wifi go it right - "I'm just like eithernet" - that's why we use Wifi and not Bluetooth to connect to LANs at the airport
(9:17:56 AM) suzukisn left the room.
(9:21:59 AM) suzukisn [suzukisn@jabber.org/eece7e8c01e12d0f] entered the room.
(9:40:20 AM) adrianfarrel [adrianfarrel@jabber.org/426ca262080d2e64] entered the room.
(9:44:44 AM) spencerdawkins: Considerations for Constrained Devices (Adam Dunkels)


(9:44:56 AM) adrianfarrel left the room.
(9:45:16 AM) adrianfarrel [adrianfarrel@jabber.org/24da18d600a39a53] entered the room.
(9:45:20 AM) spencerdawkins: Using IP to wire up hockey players (IwIP)
(9:47:36 AM) spencerdawkins: Web-enabled Lego brick ...
(9:47:58 AM) spencerdawkins: Contiki uIPv6
(9:48:56 AM) adrianfarrel left the room.
(9:49:02 AM) adrianfarrel [adrianfarrel@jabber.org/243569cdf7a20f87] entered the room.
(9:52:38 AM) spencerdawkins: ? "Lack of visibility"?
(9:53:14 AM) spencerdawkins: Not just no-UI, it's about not knowing much about what the nodes are doing - power consumption, etc.
(9:54:37 AM) spencerdawkins: "IP is heavywight" - yeah, in traditional implementations :D
(9:55:45 AM) spencerdawkins: Tuning IP down with shared packet buffers and event-driven API.
(10:01:59 AM) spencerdawkins: TCP delayed ACKs are KILLER (200 ms timeout if you only send one packet at a time, because the delayed ACK timer has to expire for each individual packet you send) - but there are applications where that's OK.
(10:04:17 AM) spencerdawkins: uIP uses event-driven API instead of sockets, because sockets add lots of complexity/code size.
(10:05:26 AM) adrianfarrel left the room.
(10:05:33 AM) adrianfarrel [adrianfarrel@jabber.org/9357b1268c972b1d] entered the room.
(10:18:31 AM) angelo.castellani [angelo.castellani@gmail.com/air636EA089] entered the room.
(10:22:02 AM) spencerdawkins: Have to turn your radio off to save battery life, but turning your radio off most of the time gives you very strange semantics - how do you do multihop, for example?
(10:30:54 AM) spencerdawkins: Long and detailed description of how radio scheduling affects radio power requirements.
(10:39:15 AM) spencerdawkins: ?are ou saying vontrol energy uses more broadcasts? Yes
(10:41:27 AM) spencerdawkins: ?Is this storing or non-storing? 
(10:42:33 AM) spencerdawkins: Actuallty, neither. Storing model control traffic gives you a burst while you learn where everything is. Non-storing mode is smoother.
(10:43:47 AM) spencerdawkins: Duty cycle ONLY changes a few things about the way protocols work, but does not fundamentally change things. 
(10:44:30 AM) spencerdawkins: Duty cycle is being pushed through IEEE 802.15.4 now - we'll see chips that do this within a year.
(10:46:02 AM) spencerdawkins: ? is there work on duty cycles preventing collisions? Can you make both worlds happy?
(10:46:51 AM) spencerdawkins: Stretching out wake-ups conserves power, but there's always someone waiting to send you something,
(10:47:15 AM) spencerdawkins: This is an active research topic.
(10:49:42 AM) spencerdawkins: Putting IETF Building Blocks Together -  ZigBee IP (Robert Cragie)


(10:51:27 AM) adrianfarrel left the room.
(10:52:09 AM) angelo.castellani left the room.
(10:53:23 AM) spencerdawkins: ZigBee/IP is a completely new stack from previous ZigBee stacks
(10:54:02 AM) spencerdawkins: SmartGrid was motivation for doing ZigBee/IP.
(10:55:52 AM) spencerdawkins: First ZigBee was designed for 802.15.4, but encountering needs to support multiple MAC/PHYs - also drives you to IP.
(10:56:40 AM) spencerdawkins: Adding HomePlug, Ethernet, 802.11 support
(10:58:55 AM) spencerdawkins: doing IPv6 only - see no need to implement IPv4.
(11:00:08 AM) spencerdawkins: Finding that they need to have a "super-specification" of what they are actually implementing - more than just a pile of RFCs.
(11:08:56 AM) spencerdawkins: Will use XML, but looking at gzip/deflate, EXI ("efficient XML interchange").
(11:11:21 AM) spencerdawkins: PANA similar to EAPOL, but using it because topology is more complex than EAPOL/flat network, no direct access to authenticator, efficient UDP transport.
(11:16:32 AM) spencerdawkins: Still need to think about gaps, multiple-subnet behavior
(11:18:45 AM) spencerdawkins: Still need to do a neiighbor exchange protocol fot link status (routing) and alternative layer-two address.
(11:19:00 AM) Stewart Bryant [stewart.bryant@gmail.com/stewart-br226C1F8E] entered the room.
(11:19:35 AM) spencerdawkins: Multiple-subnet behavior isn't a ZigBee-specific problem - being worked in v6ops
(11:25:50 AM) spencerdawkins: Not concerned about EXTREMELY limited RAM/ROM - working with 128-256KB RAM and 48-64KB ROM now
(11:26:02 AM) spencerdawkins: ? What do certificates look like?
(11:26:47 AM) angelo.castellani [angelo.castellani@gmail.com/air7B578B62] entered the room.
(11:26:56 AM) spencerdawkins: Standard X.509v3. Key thing is that devices are given an indentity and a function (an electric vehicle, for example).
(11:28:31 AM) spencerdawkins: ? application and link-layer securtity - do you compress TLS at 6LowPAN? If your data size fragments, you have to secure each fragment, multihop makes that worse ... why not use IP-layer security?
(11:29:14 AM) spencerdawkins: 6LowPAN has no compression for IPsec (at this time), and AH doesn't compress much because it's random numbers
(11:29:29 AM) spencerdawkins: Living with fragmentation ...
(11:30:22 AM) spencerdawkins: Multihop doesn't get worse (on size)
(11:31:07 AM) spencerdawkins: Can't replace one kind of security with another ... you have to have link-layer security to get access to the local link.
(11:31:35 AM) spencerdawkins: Need to talk about this offline.
(11:31:59 AM) spencerdawkins: ? Gaps and overlaps - how do you deal with overlaps?
(11:32:31 AM) angelo.castellani left the room.
(11:33:35 AM) spencerdawkins: Overlap at the application level is OK. We're doing MUSTs, but writing down what MAYs we are doing.