On Thu, Apr 30, 2015 at 12:21 PM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:
The proposed changes do not deprecate anything; they really just
make mesh-under and route-over unable to operate in the same PANID.
I would say this is a serious understatement of the mesh header renovation
proposal [option 1]. It's not relevant whether the renovation "deprecates"
the Mesh Header dispatch type selector codes. It's enough to redefine them
without considering backward compatibility. That has a profound effect.
Sufficiently profound that I would argue that marking RFC 4944 as Obsolete
would be entailed.
Accepting the mesh header renovation proposal goes beyond making it
impossible to operate both mesh-under and route-over in the same PANID. It
also makes it impossible to build hardware or microcoded implementations of
6LoWPAN capable of operating in either mode without being configured first
with an operating parameter to distinguish between them. No standard way of
announcing this operational parameter is described in the mesh header
renovation proposal.
Furthermore the mesh header renovation proposal implies that hardware and
microcode implementations may claim to be compliant with the revised
standard, which includes the renovation, despite not supporting the current
standard in RFC 4944 [which, as I say, would seem to need marking as
Obsolete], and this could bring undesirable fragmentation in the technical
ecology, i.e. when I'm building a new device, I may choose at manufacturing
time which of the two standards the device can support— by selecting the
appropriate part or by burning in the appropriate microcode— but I may not
be able to support both modes in a single unit, even with a software
cut-out to enable the older mesh header standard.
This is why we need to use the Liaison Statement process and the IESG
review if we are to give serious consideration to the mesh header
renovation proposal. It's not a trivial step to redefine the Mesh Header
dispatch type selector codes, and if the proposal is to be seriously
considered, then it must be carefully scrutinized by the IESG and all the
external standards organizations with an interest in 6LoWPAN.
--
james woodyatt <jhw(_at_)nestlabs(_dot_)com>
Nest Labs, Communications Engineering