I agree with Carsten here; There is no ethertype in 15.4 and the networks do what they like. I'm sure that if we dig around we'll find networks that actually employ the same bits as what we understand as the mesh header dispatch sequence. A way to sort networks out that used by Wireless HART is to define a well-known key in the standard for use during the join process. We are considering doing the same thing in 6TiSCH. I read in a recent thread that the mesh header is even being used to carry IPv6 addresses in a compressed form as opposed to short and long 802.15.4 addresses. How could a standard implementation know that this is happening and deal with it? Inside a particular network, the expectation is that the mesh header dispatched is used in an interoperable way. From the above, that expectation is already untrue between standards that claim 6LowPAN compliance. If a network uses the RFC4944 mesh header format, then it cannot be extended and things are cast in stone forever. In my view, the only real worry is right there. That network will not be able to use new stuff that the renovation format enables tomorrow. Which can be tons of stuff since now that the format is widely extensible. And yes, a manufacturer will have to design his software for the particular network(s) it aims at. Because different standards and compliances require different things, and 6LowpAN is only a little portion of that. Cheers, Pascal > -----Original Message----- > From: 6lo [mailto:6lo-bounces@xxxxxxxx] On Behalf Of Carsten Bormann > Sent: vendredi 1 mai 2015 23:37 > To: James Woodyatt > Cc: IETF discussion list; Thierry LYS; cedric.chauvenet@xxxxxxx; 6lo@xxxxxxxx > Subject: Re: [6lo] Possible 6LoWPAN dispatch type deprecation and re-use for > route over purposes > > James Woodyatt wrote: > > No standard way of announcing this operational parameter is described > > in the mesh header renovation proposal. > > Yes, and there never has been a standard way of announcing the use (and the > purported semantics) of the RFC 4944 mesh header either, so nothing would > change in that respect. As defined in RFC 4944, the mesh header is an empty > shell, to be filled in by a specific agreement that all interoperating nodes in a > mesh need to be aware of before they can start using it. > Again, no change at all by the new proposal, except that the syntax now would > also be allowed to change with that special agreement. > > If those who want to use the old syntax would actually tell what they plan to use > it for, there might maybe be a basis for some argument. I still haven't seen > anything but political maneuvering. Why is it so hard to argue at a technical > level? > > Grüße, Carsten > > _______________________________________________ > 6lo mailing list > 6lo@xxxxxxxx > https://www.ietf.org/mailman/listinfo/6lo