Friday, 2 February 2018

Number right?

There are many legal systems to create and protect certain rights, such as copyright, design right, database rights, patents, and so on.

However, unless I have missed something, there seems to be one obvious right that is missing. I am not suggested we make a law for this, but I am interested that this seems to be an obvious possible issue that does not have the same legal protection.

There are a lot of situations where some unique allocation of number or name space exists within an application that therefore needs some management and allocation. Some simple examples are :-
  • Credit/debit card numbers
  • Bank sort codes
  • Telephone numbers
  • MAC addresses
  • Product codes (for UPC/EAN barcodes)
  • IP addresses
  • AS numbers
  • Domain names
Now, in some cases, these are only usable within a specific group of people that all agree to follow a common authority. So, for example, ISPs all agree to work together and interconnect. Now, in theory, there is nothing to stop an ISP picking IP addresses at random without using the internationally agreed hierarchy for managing IP address allocations. However, other ISPs will simply not peer with them, or will not route those IP addresses to/for them. So it won't work. There is no need for a law to control who is allocated the numbers.

Indeed, I think, in most cases (a lot of the above examples) there is basically a club you have to join to be able to do anything, and the other members only play if you follow the club rules.

Even so, in some cases, there are laws for some specific things, like telephone numbers. It is defined by law how communications providers use numbers as part of the national numbering plan and that OFCOM manage the number allocations. But this is a specific law for that specific case.

There are some interesting edge cases though.

Barcodes is one. We have dealt with GS1. FireBrick paid for a small block of UK EAN product codes so we have barcodes for the sleeves of the FireBricks and for Ignis (the dragon). This is in the off chance that we managed to sell to some retail outlet like PC world. However, given that GS1 charge annually and nobody was actually using the barcodes, we decided not to renew. GS1, of course, said we could no longer use the numbers and had to ensure barcodes were not used with those numbers any more.

This led to an interesting discussion. Apparently they even have an "enforcement" team that look for unregistered numbers in-use. The question then is what do they do? They got quite stroppy when I asked questions, like why not? Well step 1 was easy, because FireBrick had a contract, so I said that was fine, A&A were using the numbers instead and A&A had no contract. They did not like that and pointed out that they retain all rights in the numbers allocated.

This is where it got interesting as I asked exactly what rights they were retaining. They had no answer. I pointed out copyright does not apply, neither do design rights, database rights, patents. There appears to be no generic legal mechanism for establishing a right to management of allocations within a namespace such as UPC/EAN product codes. So actually, from what I can see, nothing to stop A&A using the numbers that were allocated to FireBrick without paying GS1. What this meant is the existing printed sleeves and existing labels on Ignis dragons did not have to be scrapped.

Now, in practice if some retail outlet want to sell FireBricks we'll subscribe again I am sure. A retail outlet may well require as part of the contract with them the use of valid/current EAN product codes. So we are back to the enforcement by joining the club, which is fair enough. Though I did wonder if retailers really care as long as unique within their inventory. I did tell GS1 that as they know we have products (Ignis mostly) with these barcodes it would be negligent / irresponsible if they knowingly re-allocated the codes to someone else.

Of course, another thing may be that retailers only need a code that is valid and current which means one could perhaps get an ISBN (for the quick start guide in the box) and use the ISBN based barcode on the box. I see plenty of kids magazines with ISBN or ISSN and lego bricks attached, so this would be no different logically. It would be a unique product code, and allocated to us, and as it is a one-off fee for ISBNs, no annoying recurring fees. As a bonus, no dealing with the stroppy people at GS1 either. If ever we do a deal with a retailer I'll ask if an ISBN based code is any issue for them - I doubt it some how - it is, after all, just a number in their database.

It is rather amusing that GS1 felt some legal rights existed in the allocation of these numbers. They must know that no such rights exist, but still assert they control them in their documentation!

Another interesting case which we see quite often is MAC addresses.

These have to be unique, on a LAN. In practice the way to do this is to make them unique in the world by a central allocation of the OUI (first 6 characters / 24 bits) by the IEEE who charge over $2000 (one off) for such a prefix. We have paid for a prefix and use it.

But what we do see is some times people just make one up. This is partly because there is loads of unused space in the allocations so easy to pick one that is spare, and partly because the actual chance of a clash on a LAN is very very low even if some other manufacturers is using the same prefix. So devices with unregistered MACs exist. AFAIK there is nothing the IEEE can do about it, as, unlike many things, there is no need to join a club or contract with other users of MAC prefixes where you may be obliged to have a "proper" prefix.

Am I right that there is no generic legal right to numbering allocations?


  1. I don't know if it's still the case, but historically there was never any standard for endianness in MAC address encoding. In the mid-1990s I worked at IBM and discovered they encoded theirs backwards compared to everyone else, resulting in the potental for collisions.

    1. Wow, and indeed the way MACs are transmitted on the wire is rather counter intuitive.

  2. We bought 2 very dodgy webcams a couple of years back, and their vendors weren't even trying with the MAC addresses: 00:00:00:00:0F:46 and 00:00:00:00:0F:48 !

    1. Some years ago I bought some dirt cheap usb ethernet adapters on ebay. As well as being usb1.1 (sticker says 2.0) they all have identical MAC addresses!

      It appears there is no eeprom at all and this is 'by design'

      I only wanted them for some testing and I can change the MAC address at runtime so I kept them but caused quite a lot of head scratching when I first started trying to test some complex iptables rules - not least because which adapter was on which link wasn't stable and depended which usb port it was plugged in to.

      And twice now they've helped friends who have had network ports fail - leave them with one of them that gets things working again however slowly (and instructions to go and buy a proper one and then bin the toy)

  3. With MAC addresses you do have the distinction of whether they are universally or locally administered, indicated by the second LSB of the first octet - the latter not needing to be allocated by anybody and thus you are free to make them up.

    I don't know if there's anything which states e.g. that you should use universally administered addresses on items you sell or intend to be used outside of a network you control...

  4. Here's an interesting example, with IP addresses: EMC have a range of NAS boxes that use IP for their back-end traffic, on two dedicated networks that are only meant for inter-box traffic (end-user traffic use different ports).

    The back-end network interfaces use IPs in the,, and ranges. Yes, those are public IP addresses. But, EMC have the entire range. And, looking at routeviews, it seems that those three /24s are not being announced on the Internet.

    So, rather than pick some random range (that might conflict with customers), EMC allocated a chunk of their public range, and then ensured that it would not conflict with anything.

    1. We actually did that on the first FireBricks...

  5. If you ever need to sell on Amazon, their essential unique identifier for a product is the EAN/UPC barcode. They then group together "offers" from different sellers using that code. We hit problems where we listed items, and they were associated with completely different products, because somebody else had previously listed something that itself had no code against a then-unlisted barcode that actually belonged to the product we were trying to sell! Or they offer a multiple of an item (because it's small or low-value) using the code from the individual item.

    Because the sellercentral console lists items using the data *you* provided, not the generic, aggregated, data, you usually only find this out when somebody orders something, you ship it, and they then complain it's not what they expected. Much fun then ensues. ..not!

    The "solution" is to email amazon with photos of the real product, including barcode, and then, maybe, they will split the listing. But you still have an angry customer to deal with, who was expecting a product that you don't even have!