Re: Public Release of Z-Wave G.9959 TAP Specification

[James Ko via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: James Ko <jck () exegin com>
>
> Date: Fri, 9 Dec 2022 10:51:55 -0800
>
> Just two comments inline.
>
> On Mon, Dec 5, 2022 at 3:45 PM Denis Ovsienko via tcpdump-workers <
> tcpdump-workers () lists tcpdump org> wrote:
>
> > ---------- Forwarded message ----------
> > From: Denis Ovsienko <denis () ovsienko info>
> > To: tcpdump-workers () lists tcpdump org
> > Cc:
> > Bcc:
> > Date: Mon, 5 Dec 2022 23:44:46 +0000
> > Subject: Re: [tcpdump-workers] Public Release of Z-Wave G.9959 TAP
> > Specification
> > On Mon, 5 Dec 2022 11:53:11 -0800
> > Chris Brandson via tcpdump-workers <tcpdump-workers () lists tcpdump org>
> > wrote:
> >
> > > Hello everyone,
> > >
> > > We are pleased to publish the draft Z-Wave G.9959 TAP Specification
> > [...]
> >
> > Hello Chris.
> >
> > Thank you for preparing the document.  I am not familiar with the
> > standard to make more substantial comments, but a few things seem to
> > require some attention:
> >
> > * Page 7: "Length is a minimum of 4 octets and must be a multiple of 4.
> >   The addition of new TLVs does not and must not require incrementing
> >   the version number." -- this definition automatically creates a
> >   problem space on the receiving/reading end of this encoding because
> >   slightly more than 75% of all possible length values are invalid by
> >   definition. The classic solution would be not to include the first 4
> >   octets into the length, and to count in multiples of 4, this way any
> >   length value would be valid, free of underflows and better consumable
> >   by simple parsers such as BPF bytecode.
> >
> > Note that the TAP header length field differs from the TLV header length
> field.  I'm not opposed to omitting the header bytes from the TAP header
> length but just wanted to make sure we all understood the difference in
> this part of the document.  For a little background: I know this
> specification was based on IEEE802.15.4-TAP (
> https://github.com/jkcko/ieee802.15.4-tap) and that was based on
> IEEE802.11-RADIOTAP (https://www.radiotap.org/).  This was also likely
> because IP header length and total length fields also includes the header
> bytes.
>
> * Page 8: "Z-Wave PHY Payload" -- is this the PPDU from Figure A.7 of
> >   G.9959 2015/01, starting from "preamble sequence"?
> >
> > * Page 9: "length - number of octets for type in value field (not
> >   including padding)" -- this definition looks better, but in the next
> >   three TLV diagrams the length does include the T and the L.
> >
> > 4.1 FCS length should be 1 rather than 4 here.  Padding not included.
>
> Regards,
> James
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers