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

[David Farmer <[e-mail]>]

I'm no expert, but yes, the base call sign can be up to 7 characters.
However, there are prefixes and suffixes that can be added to the base call
sign, when operating in different environments or outside their home area
or country, easily extending the call sign to 10 or more characters, see
the following;

https://en.wikipedia.org/wiki/Amateur_radio_call_signs#Secondary_prefix_or_suffix_types

Hope that helps;

On Fri, Feb 17, 2023 at 1:02 PM Ron Bonica <[e-mail]> wrote:

> Evan,
>
>
>
> I also question hashing the call sign. Since the longest possible call
> sign is 7 characters long, it can be encoded in 56 bits.
>
>
>
> Moreover, there is a problem on hash collisions. Let’s say that I operate
> two call signs from the same node and (my luck) the hashes collide?
>
>
>
>            Ron
>
>            /no hats
>
>            W4OSG
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* David Schinazi <[e-mail]>
> *Sent:* Wednesday, February 15, 2023 8:06 PM
> *To:* Evan Pratten <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Cc:* David Farmer <[e-mail]>; Nick Harper <[e-mail]>;
> Alexandre Petrescu <[e-mail]>; IPv6 <[e-mail]>;
> [e-mail]
> *Subject:* Re: [IPv6] [HAM-AG] Request for feedback:
> draft-evan-amateur-radio-ipv6
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Evan,
>
>
>
> I think this draft is a good idea, and I like the latest proposals with a
> hash bit and a node ID so that a callsign can map to multiple physical
> devices.
>
>
>
> Hello esteemed chairs and corresponding ADs for IPv6 WGs, which WG do you
> think would be best suited to discuss this draft?
>
>
>
> Thanks,
>
> David, IPv6 enthusiast and wannabe radio enthusiast
>
>
>
>
>
>
>
> On Wed, Feb 15, 2023 at 4:55 PM Evan Pratten <[e-mail]> wrote:
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-eastlake-fnv/__;!!NEt6yMaO-gk!BMVJ4gJQ-Us5qYSgbvo-6GIokRahWrBn1tkKmdJbGDvegIFs0q13p8LqTF2HkPRB61TjoyEu5R-rHdxlV9Ct3Dy8$>
> >>> >>
> >>> >> Here is an article on using FNV-32 for IPv6 flow label
> >>> >>
> https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf
> <https://urldefense.com/v3/__https:/researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf__;!!NEt6yMaO-gk!BMVJ4gJQ-Us5qYSgbvo-6GIokRahWrBn1tkKmdJbGDvegIFs0q13p8LqTF2HkPRB61TjoyEu5R-rHdxlVxMk6YZN$>
> >>> >>
> >>> >> 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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ham-ag__;!!NEt6yMaO-gk!BMVJ4gJQ-Us5qYSgbvo-6GIokRahWrBn1tkKmdJbGDvegIFs0q13p8LqTF2HkPRB61TjoyEu5R-rHdxlV7IimQGZ$>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!BMVJ4gJQ-Us5qYSgbvo-6GIokRahWrBn1tkKmdJbGDvegIFs0q13p8LqTF2HkPRB61TjoyEu5R-rHdxlVwMDRcCj$>
> >> --------------------------------------------------------------------
> >
> > --
> > ===============================================
> > 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
> > ===============================================
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!BMVJ4gJQ-Us5qYSgbvo-6GIokRahWrBn1tkKmdJbGDvegIFs0q13p8LqTF2HkPRB61TjoyEu5R-rHdxlVwMDRcCj$>
> --------------------------------------------------------------------
>
>

-- 
===============================================
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
===============================================