Fwd: [digitalvoice] Re: Authentication confirmed!

[Bruce Perens]

Hi Steve,

License class isn't really sufficient because they aren't the same from one country to another. A callbook database will be helpful. In some cases the license class can be established from the format of the call letters.

We are offering the remote Amateur the control-operator position as if they had traveled to the country of the station and were at the control position. Thus, we need to consider what sort of agreement exists between the two nations.

Consider that the station is in the U.S.

An automatic reciprocal agreement exists between the U.S. and Canada, and we can arrive at some correlation of license classes between the two.

You can read about CEPT here: http://www.arrl.org/files/file/Regulatory/DA-11-221A1.pdf

There is a list of bilateral country agreements and their requirements at http://www.arrl.org/reciprocal-permit

And then there is the CITEL agreement, which you can read about at http://www.arrl.org/iarp

Not all of this is automatic, some of it requires that the Amateur get a license from the remote government or an IARP from ARRL (as the administrator of IARU), etc. And codifying this into software is non-trivial. A simpler alternative would be pointing the remote Amateur to the above material and requiring them to certify that they have gone through the necessary process and understand what frequencies they are permitted to operate upon. They can make a legal signature online.

Having passed the legal hurdles, the operator would have to sign K6/<their-callsign> and would have to create a new station location in the trusted QSL program if they wanted to be scored properly for contests, etc.

    Thanks

    Bruce

---------- Forwarded message ----------
From: Steve <coupay...@gmail.com>
Date: Sat, Jun 20, 2015 at 2:07 PM
Subject: [digitalvoice] Re: Authentication confirmed!
To: digita...@googlegroups.com

Does the certificate include license class, and expiration, or will you have to look that up in each countries national database?

[Stuart Longland]

On 21/06/15 15:18, Bruce Perens wrote:
> License class isn't really sufficient because they aren't the same from
> one country to another. A callbook database will be helpful. In some
> cases the license class can be established from the format of the call
> letters.

That won't tell you expiry information, but useful for establishing
privileges, if the country in question has organised it that way.

e.g. in Australia, if a callsign matches:
^(VK|AX)\dF[A-Z]{3}$
→ Foundation:
10W PEP SSB, 10W FM
Analogue voice (FM/SSB/AM)
or hand-keyed morse only.
80m: 3500-3700kHz
40m: 7000-7300kHz
15m: 21000-21450kHz
10m: 28000-29700kHz
2m: 144000-148000kHz
70cm: 430000-450000kHz

^(VK|AX)\d[LMNPV][A-Z]{2}$
→ Standard:
100W PEP SSB, 30W FM
All modes.
80m: 3500-3700kHz
40m: 7000-7300kHz
20m: 14000-14350kHz
15m: 21000-21450kHz
10m: 28000-29700kHz
6m: 52000-54000kHz
2m: 144000-148000kHz
70cm: 430000-450000kHz
23cm: 1240-1300MHz
13cm: 2400-2450MHz
6cm: 5650-5850MHz

^(VK|AX)\d[^LMNPQRV]?[A-Z]{2}$
→ Advanced:
400W PEP SSB, 100W FM
All modes.
2.2km: 135.7-137.8kHz
630m: 472-479kHz
160m: 1800-1875kHz
80m: 3500-3700kHz, 3776kHz-3800kHz
40m: 7000-7300kHz
30m: 10100-10150kHz
20m: 14000-14350kHz
17m: 18068-18168kHz
15m: 21000-21450kHz
12m: 24890-24990kHz
10m: 28000-29700kHz
6m: 50000-54000kHz
2m: 144000-148000kHz
70cm: 430000-450000kHz
23cm: 1240-1300MHz
13cm: 2300-2302MHz, 2400-2450MHz
9cm: 3300-3600MHz
6cm: 5650-5850MHz
3cm: 10000-10500MHz
12mm: 24000-24250MHz
6mm: 47000-47200MHz
4mm: 76000-81000MHz
and a few above that we don't have bandplans[1] for.

Then there's the "special event" callsigns, which usually match
^VI\d.*$. Don't get me started on oddball ones like VK100WIA[2].

I wonder if there's a database that collates the above for various
license classes around the world?
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

1.
http://www.wia.org.au/members/bandplans/data/documents/Australian%20Band%20Plans%20150606.pdf
2.
http://gallery.longlandclan.yi.org/gallery.cgi/qsl/201006270350-vk100wia.png/photo.html

[Matthew Pitts]

Stuart,

Probably not, as there have been "issues" with people trying to compile such a system; as I understand it, the EU has some laws about this that essentially prohibit a publicly accessible database of callsigns from containing EU callsigns unless the user allows it. This is why there is an "opt-in" requirement for callsign display on the D-STAR ircDDB website.

Matthew Pitts

N8OHU

---

From: Stuart Longland <stu...@longlandclan.yi.org>
To: digita...@googlegroups.com
Sent: Sunday, June 21, 2015 4:29 PM
Subject: Re: Fwd: [digitalvoice] Re: Authentication confirmed!

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice+unsub...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.
Visit this group at http://groups.google.com/group/digitalvoice.
For more options, visit https://groups.google.com/d/optout.

[Stuart Longland]

On 22/06/15 06:45, 'Matthew Pitts' via digitalvoice wrote:
> Probably not, as there have been "issues" with people trying to compile
> such a system; as I understand it, the EU has some laws about this that
> essentially prohibit a publicly accessible database of callsigns from
> containing EU callsigns unless the user allows it. This is why there is
> an "opt-in" requirement for callsign display on the D-STAR ircDDB website.

How about a catalogue of license classes per country that's
machine-searchable?

Surely there's no EU privacy issues there? Not sure if the ARRL LoTW
system supplies the license class as part of the certificate (it should
in my opinion).

[John Hays]

Not the responsibility of the network to enforce local regulations.

Software can and should implement an api that a system administrator can extend for filtering access as per their own needs, but don't try to build the universal filter.

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "digitalvoice" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.

[Bruce Perens]

The EU database law means that such a database would have to be hosted outside of the EU. Which isn't much of a problem.

To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.

[Bruce Perens]

Under section II, article 7, part c of the EU database directive, the data processing is legitimate within the law if it is necessary for compliance with a legal directive that the controller (the station owner, in this case) is subject to. We don't actually need the consent of the person who is the subject of the data in this case. So as far as I can see, you can host such a database in the EU and you don't need consent. I would consult a lawyer and see if they agree with my read before I do that, but it looks clear enough.

[Kristoff]

Matthew,


The privacy-problem for ircddb was a of completely different nature. In that case, the issue was that information was "leaked" outside its original intented purpose.
The callsign routing information collected by ircddb was in its original form intented for a very specific purpose: to allow callsign-routing, i.e. internal routing inside the DSTAR network. The problem arose when somebody took that information and made it public so that it became visible for people who had no business with the original "use" of the information.


The application here is very different. If the goal is simply to set up "generic" rules to map a callsign to a class of license, there is no personal information involved so there surely is no issue with that. In fact, that would be a good example of "open data".

If it would be the case that such a generic rule is not possible and that this mapping needs to be done on the level of individual callsigns (and therefor can be traced to a individual user), that would be a different matter. The question then is "does this have to be a public database?"

OK, what is the goal you want to achieve?
If it is just to control access to services  and if you are using X.509, why not embed this information in the X.509 certificate? In that case, this information is only known by the CA, the user and the service you access and there is absolutely no need for a public database.


73
kristoff - ON1ARF

To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.