There is certainly no intent, at least with any of the documents I have
posted regarding PAN ID compression, to change behaviors as understood
by those using 802.15.4e as published, the intention is to clear up
ambiguity in amendment and correct obvious errors (like the inclusion of
MP-frames in the PAN ID compression table, which makes no sense). We
received comments from people who could not unambiguously determine what
to implement given the text published in 2012. It is therefore our job
to "fix" the text so that it can be implemented consistently. There were
also several errors introduced WRT the "legacy" behavior (frame version
< 2) which were not intended by TG4e, such as losing the text which
specified that PAN ID compression is only used when the source and
destination PAN IDs are equal.
The point of querying implementers and developers of other
specifications based upon the published standard is to resolve
ambiguities in a rational and realistic way. It would be of great help
to the revision task if you can clarify what "following the information
from Table 2a" means specifically.
Thanks for the consideration
Benjamin A. Rolfe
Blind Creek Associates
On 7/6/2015 11:07 AM, Thomas Watteyne wrote:
Tero,
One of the strong wishes of the participants of the plugtest is to
stick to the standards that are published. We therefore are following
information from Table 2a.
Thomas
On Monday, July 6, 2015, Tero Kivinen <[email protected]
<mailto:[email protected]>> wrote:
Xavier Vilajosana writes:
> Yes we are refering to the 2nd last line of table 2.a.
>
> Most of us know that you are right and what you are indicting makes
> sense. However vendors have already implemented or are implementing
> what an standard document says (w.r.t table 2.a).
Are you sure about that? I.e. have you verified this from the vendors
themselves?
I mean, if they do implement this, then there is no way to provide
both PAN IDs for frame version 0b10 frames, and that means this
feature is not available for 802.15.4 at all.
> At this point and understanding that we had some consensus on only
> citing work that is already published as standard we need to refer
> to table 2.a as it is now (in the 2012 version).
It would be better to verify this from the actual vendors implementing
this, and not to get fixated with the table 2.a...
> This is strange but if we adopt the changes proposed in some of this
> mentor documents, how do we ensure that everybody that has
> implemented or is implementing 15.4e (2012) will follow this
> amendments which are not part of any standard yet.
If I have understood correctly the document in mentor is trying to
reflect what vendors have implemented, i.e. what 802.15.4e was
supposed to say, and how it was implemented, not necessarely what was
written in 802.15.4e...
As this is confusing issue, it would be best to poll some vendors and
ask what they actually have implemented and specify that for our
draft.
This draft is the one that is used for the testing, so for that they
should implement what is said here. On the other hand if vendors have
ignored the table 2a in the 4e and instead implemented things
differently, it would be annoying to require them to change their
implementations just for the minimal testing, even when we are
following what 4e says...
> What others think, does anybody have experience on such situations?
I would suggest that those who are planning to participate in testing
to check their implementations and verify what they do and change the
draft to reflect that (provided there is one common way). If different
vendors have implemented this differently, then this question gets bit
harder to solve.
--
[email protected] <javascript:;>
_______________________________________________
6tisch mailing list
[email protected] <javascript:;>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
