On Thu, Apr 30, 2015 at 12:21 PM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> 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.