Convince a vendor to improve their payload format

Here is one attampt to explain things to them:

Hi <vendor>

I’ve been reading through your documentation on the LoRa protocol. I understand it well.

One thing that I am concerned about is the protocol you use. ASCII!! LoRaWAN’s guidelines clearly states that one should not waste space and use ascii, but rather compact binary protocols.
https://www.thethingsnetwork.org/docs/devices/bytes.html

For example a normal request to your meters look like this:
30 31 30 34 30 30 30 36 30 30 30 32 39 31 36 61 (16 bytes)

By doing it in pure binary, skipping the unnecessary conversion to ascii, one can make it:
01 04 00 06 00 02 91 CA (8 bytes)

Because the first byte is always 01, we can leave it out.
04 00 06 00 02 91 CA (7 bytes)

The Function Code can move to the LoRaWAN fport, as this is meant to describe the function:
FPORT 04: 00 06 00 02 91 CA (6 bytes)

Because the LoRaWAN payload already has a Message Integrity Check (MIC), and the uplinks have a CRC, we do not need to put a CRC into the command:
FPORT 04: 00 06 00 02 (4 bytes)

So we just decreased the downlink command from 16 bytes to 4 bytes, by using LoRaWAN properly.

On the uplink side we can do exactly the same and decrease the message from
(3 + N + 2) x 2 = 2N+12
TO
3+N

LoRaWAN uses the shared ISM band, and we all should do our best to decrease the airtime of our devices, to keep the ISM band as free as possible. I am also very concerned with using your meters in big residential buildings where we will have thousands of these meters. With the current system they will fill the ISM band completely. Using a proper binary protocol will clear it up a lot!

Would you please consider improving the protocol you use over LoRaWAN?

Best regards
JP Meijers

Unfortunately I got no response from them.

Is there perhaps a way one can report vendors like these to the LoRaWAN Alliance, and then the alliance forcing them to fix it otherwise their devices won’t be certified?