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(_at_)ietf(_dot_)org] On Behalf Of Carsten
Bormann
Sent: vendredi 1 mai 2015 23:37
To: James Woodyatt
Cc: IETF discussion list; Thierry LYS;
cedric(_dot_)chauvenet(_at_)erdf(_dot_)fr; 6lo(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/6lo