Re: [IPv6] [HAM-AG] Request for feedback: draft-evan-amateur-radio-ipv6

[Evan Pratten <[e-mail]>]

David,

I like this approach.

Interestingly, this also segregates nodes into permanent and temporary
callsign subnets. Plus, *not* hashing permanent callsigns allows
country-specific callsign prefixes to be treated as subnets.

On Wed, Feb 15, 2023 at 7:52 PM David Farmer <[e-mail]> wrote:
>
> How about the most significant bit be labeled the hash bit, when it is set to 1 it allows for 59 bit hash of the callsign or set to 0 it allows for a base-36 encoded callsign, with the last nibble being the node ID.
>
> Kind of the best of both worlds.
>
> Just a thought.
>
> On Wed, Feb 15, 2023 at 18:34 Nick Harper <[e-mail]> wrote:
>>
>> I had to look up that ITU regulation, so I don't know if there's a max length on temporary callsigns.
>>
>> If you treat the callsign as a base-36 number, you could squeeze up to 11 characters into 60 bits.
>>
>> If you really want to handle callsigns of arbitrary length, you could use some of the 60-bit space for direct encodings of short (e.g. <=7 characters) callsigns and the rest of the space for the hash of longer callsigns.
>>
>> On Wed, Feb 15, 2023 at 4:13 PM Evan Pratten <[e-mail]> wrote:
>>>
>>> I have personally held temporary callsigns longer than 7 characters,
>>> which is why I wanted to handle that.
>>>
>>> Using a more space efficient encoding scheme is an interesting idea.
>>> Do you know if there is a maximum length on temporary callsigns by
>>> chance?
>>>
>>> I'll think about doing away with the hash in favor of space-efficient encoding.
>>>
>>> On Wed, Feb 15, 2023 at 7:10 PM Nick Harper <[e-mail]> wrote:
>>> >
>>> > Why hash the callsign at all?
>>> >
>>> > Article 19 of ITU's Radio Regulations specifies the format of callsigns, and they are at most 7 characters long. The ASCII representation of the callsign could be used to generate 7 bytes (56 bits) to use in the address without needing any hashing. For the exception in 19.68A (on special occasions, for temporary use, callsigns could be longer than 7 characters), a 6-bit encoding scheme could be devised so that alphanumeric callsigns up to 10 characters long could be encoded in 60 bits.
>>> >
>>> > On Wed, Feb 15, 2023 at 3:28 PM Donald Eastlake <[e-mail]> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> On Wed, Feb 15, 2023 at 3:03 PM Evan Pratten <[e-mail]> wrote:
>>> >> >
>>> >> > On Wed, Feb 15, 2023 at 2:58 PM Donald Eastlake <[e-mail]> wrote:
>>> >> > > I'm not sure the hash even needs to be cryptographic.
>>> >> >
>>> >> > Agreed. I would call a cryptographic hash *undesierable*. Why waste
>>> >> > processing power hiding the callsign when you have to ID yourself
>>> >> > anyways?
>>> >> >
>>> >> > I am admittedly far from an expert on hashing algorithms. Donald, do
>>> >> > you have any suggestions that fit the properties you outlined by
>>> >> > chance?
>>> >>
>>> >> Indeed, I would suggest using FNV-64 truncated to the top 60 bits, See
>>> >> https://datatracker.ietf.org/doc/draft-eastlake-fnv/
>>> >>
>>> >> Here is an article on using FNV-32 for IPv6 flow label
>>> >> https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf
>>> >>
>>> >> Thanks,
>>> >> Donald
>>> >> =============================
>>> >>  Donald E. Eastlake 3rd   [phone] (cell)
>>> >>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>> >>  [e-mail]
>>> >>
>>> >> --
>>> >> HAM-AG mailing list
>>> >> [e-mail]
>>> >> https://www.ietf.org/mailman/listinfo/ham-ag
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================