Hi Carsten, I answered a similar note privately from Michael. Let me share part of that here for everyone:
...... (part of note to Michael deleted....)....... We are just sharing our experience of now 2 years of monthly interops using 6LoWPAN, ROLL RPL, PANA and now MLE. Many of us participated in 6LoWPAN ND and ROLL RPL in IETF (including the author of the MLE draft). We are simply offering up that body of experience to point out the remaining gaps in deploying these protocols. We are pretty close to having a sizable number of semiconductor manufacturers go through commercial certification on these RFCs and drafts. We do have a specification but it simply calls out the RFCs and drafts then provides a baseline configuration used in our commercial deployment. We think many other commercial groups will need to do the same to make interoperability a reality using these protocols. I do believe our specification will be made publicly available once our initial certification is complete (maybe 6 months from now?). The interesting part is product developers should have access to IP enabled IEEE 802.15.4 written in such a way to provide multi-vendor interoperability. One thing though: We realized we needed MLE rather late in our interop process so we don't have a lot of time to close on MLE (commercially). Certainly your ideas to use either ROLL RPL messages or ICMP messages for MLE would not work for us schedule wise. We would have to continue using MLE as written (using UDP) if it goes in another direction within IETF. That said, if we can find a way to *extend* the protocol using input from the ROLL WG (or others) in a way that allows us to continue through certification using MLE (maybe with even some small changes) that would be a win for everyone. ........ (end of note.....)........ Don On 6/15/12 3:43 AM, "Carsten Bormann" <c...@tzi.org> wrote: >> we don't have time for all these changes > >It's likely that the next question that will come up is: > >Should this be published as an informational RFC called "ZigBee's MLE >protocol" because the protocol is no longer really meant to be modified >in the process or should it be pursued as a standards track document? > >(Don't get me wrong, I'm all for stability of protocols when there is >running code. >Stability against gratuitous change and Brownian motion, that is. >But not when there are good technical reasons to have the change. >We should be having the discussion on whether that's the case, I think. >And how the encapsulation of MLE works in the first place, something I >don't understand yet.) > >Grüße, Carsten > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------