On Mon, Dec 10, 2007 at 08:45:10PM +0100, Carsten Bormann wrote: > C) Daniel has reminded us that there needs to be a management solution > at some point. I'm not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place?
[...] > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? [...] Just to let you know that I am still lurking on this list. I am not sure what is needed at this point in time concering management. SNMP can be reasonably byte efficient (and there were proposals in the past to make it even more efficient) but it uses a polling approach which may be questioned on some 6lowpan scenarios where you might want to save the requests and perhaps even do aggregation along the routing path. On the other hand, we might be able to reuse some of the IPv6 MIBs and that might be goodness. During our 6lowpan implementation exercise, we found a few things in the RFC that would be nice to fix and which we have posted to this list (without much feedback I must say). From my perspective, I think there should be continued work on the 6lowpan specifications - either as an implementors guide or simply work towards revised specifications. And it might help to actually have interoperability tests carried out to see how much implementations interoperate in terms of the various compression schemes and fragmentation. Who would participate in some interoperability test at one of the upcoming IETFs? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
