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

For those interested in the weird things people get up to with special
event callsigns, please take a look at Canada's registry of future,
current, and past authorizations.

https://apc-cap.ic.gc.ca/pls/apc_anon/query_spev$.startup

On Fri, Feb 17, 2023 at 2:29 PM Evan Pratten <ewpratten@gmail.com> wrote:
>
> This is another good point. Suffixes are super common (/QRP for
> example), plus I've yet to find an actual length restriction on
> special event calls.
>
> On Fri, Feb 17, 2023 at 2:28 PM David Farmer <farmer@umn.edu> wrote:
> >
> > 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 <rbonica@juniper.net> 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 <dschinazi.ietf@gmail.com>
> >> Sent: Wednesday, February 15, 2023 8:06 PM
> >> To: Evan Pratten <ewpratten@gmail.com>; v6ops-chairs@ietf.org; 6man-chairs@ietf.org; v6ops-ads@ietf.org; 6man-ads@ietf.org
> >> Cc: David Farmer <farmer@umn.edu>; Nick Harper <nharper@nharper.org>; Alexandre Petrescu <alexandre.petrescu@gmail.com>; IPv6 <ipv6@ietf.org>; ham-ag@ietf.org
> >> 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 <ewpratten@gmail.com> 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 <farmer@umn.edu> 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 <nharper@nharper.org> 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 <ewpratten@gmail.com> 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 <nharper@nharper.org> 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 <d3e3e3@gmail.com> wrote:
> >> >>> >>
> >> >>> >> Hi,
> >> >>> >>
> >> >>> >> On Wed, Feb 15, 2023 at 3:03 PM Evan Pratten <ewpratten@gmail.com> wrote:
> >> >>> >> >
> >> >>> >> > On Wed, Feb 15, 2023 at 2:58 PM Donald Eastlake <d3e3e3@gmail.com> 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   +1-508-333-2270 (cell)
> >> >>> >>  2386 Panoramic Circle, Apopka, FL 32703 USA
> >> >>> >>  d3e3e3@gmail.com
> >> >>> >>
> >> >>> >> --
> >> >>> >> HAM-AG mailing list
> >> >>> >> HAM-AG@ietf.org
> >> >>> >> https://www.ietf.org/mailman/listinfo/ham-ag
> >> >>
> >> >> --------------------------------------------------------------------
> >> >> IETF IPv6 working group mailing list
> >> >> ipv6@ietf.org
> >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> >> --------------------------------------------------------------------
> >> >
> >> > --
> >> > ===============================================
> >> > David Farmer               Email:farmer@umn.edu
> >> > Networking & Telecommunication Services
> >> > Office of Information Technology
> >> > University of Minnesota
> >> > 2218 University Ave SE        Phone: 612-626-0815
> >> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> >> > ===============================================
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> >
> >
> > --
> > ===============================================
> > David Farmer               Email:farmer@umn.edu
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE        Phone: 612-626-0815
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================