19 May
2022
19 May
'22
8:42 p.m.
Hello 44Net Mailing List,
There has been a lot of discussion on this list about the state of
44Net. Some people like how it works, some would like to see an upgrade.
In order to make an informed decision that takes a variety of viewpoints
into account, ARDC is conducting an assessment. For the first phase,
we’ve put together a survey, which we'd love for you to fill out. Our
aim is to get input from as many people as possible to help influence
the network’s next chapter.
Click here to go to the survey:
survey.ardc.net
(Please note that the above is a redirect.)
We expect that it will take around 15 minutes to complete.
The survey is currently being translated into French, German, and
Japanese, shoud you prefer to take it in another language. Thank you for
your patience as we complete professional translations. We’ll post them
here as soon as they are ready!
It’s important to note: the survey is not a voting mechanism - it’s a
research tool. We’ll also be conducting interviews and focus groups with
a subset of users. Results from all research will be shared publicly
(personal information excluded) on ampr.org.
If you have questions about this survey or are interested in being
interviewed or part of a focus group, reach out to us at any time:
contact(a)ardc.net. You can also follow the assessment’s progress by
signing up for our newsletter.
Thank you in advance for sharing your input - we look forward to reading
your responses!
Warmly,
Rosy & the ARDC team
--
Rosy Schechter - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
19 May
19 May
8:18 p.m.
On Thu, 19 May 2022, Rosy Schechter - KJ7RYV via 44net wrote:
Rosy, ...
There has been a lot of discussion on this list ...
... which was summarised, by yourself, on 2022-04-26 with:
... migrating this mailing list to any new system will
likely come
with pain and user drop-off, [so] it makes sense for this mailing
list to remain on its existing and updated mailman instance.
Which seems to be a very sensible and wise summary.
This is the only reliable method we have for communication, reporting
bugs, searching for missing HAMs, advertising meeting, requesting
feedback, and having discussion ... it would make sense to leave it
alone.
"If it ain't broken don't fix it".
-Paul
10:14 p.m.
On 19 May 2022, at 21:21, Paul Sladen via 44net
<44net(a)mailman.ampr.org> wrote:
:
This is the only reliable method we have for communication, reporting
bugs, searching for missing HAMs, advertising meeting, requesting
feedback, and having discussion ... it would make sense to leave it
alone.
"If it ain't broken don't fix it".
The survey is not about this mailing list and whether *it* needs an upgrade. It’s about
the whole of 44Net and how we look to the future.
Chris - G1FEF
11:20 p.m.
On 20/5/22 5:42 am, Rosy Schechter - KJ7RYV via 44net wrote:
Hello 44Net Mailing List,
There has been a lot of discussion on this list about the state of
44Net. Some people like how it works, some would like to see an
upgrade. In order to make an informed decision that takes a variety of
viewpoints into account, ARDC is conducting an assessment. For the
first phase, we’ve put together a survey, which we'd love for you to
fill out. Our aim is to get input from as many people as possible to
help influence the network’s next chapter.
Just finished the survey, covers a lot
of good issues. Only thing I'd
comment on is it's hard to summarise across my two allocations - they
are _very_ different in many respects, both technologically (BGP vs
IPIP), use (infrastructure vs experimentation), degree of use (fully
utilised vs limited deployment), and importance (mission critical vs
experimental/tinkering).
Also, in future, could you please use both the redirect and direct URL
in emails. This PC has an IPIP based 44net address and has issues
reaching some ARDC hosted content(at best, veeery slow). I had to use
another PC without a 44net address to access the survey.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
20 May
20 May
12:32 a.m.
Hi Tony,
Just finished the survey, covers a lot of good
issues. Only thing I'd
comment on is it's hard to summarise across my two allocations - they
are _very_ different in many respects, both technologically (BGP vs
IPIP), use (infrastructure vs experimentation), degree of use (fully
utilised vs limited deployment), and importance (mission critical vs
experimental/tinkering).
Thank you for sharing this, Tony. This insight is super helpful.
Also, in future, could you please use both the
redirect and direct URL
in emails. This PC has an IPIP based 44net address and has issues
reaching some ARDC hosted content(at best, veeery slow). I had to use
another PC without a 44net address to access the survey.
Yes! For anyone who wants the direct link, here it is:
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sour…
Thanks again for sharing your thoughts!
Rosy
--
Rosy Schechter - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
1:13 a.m.
On 20/5/22 9:32 am, Rosy Schechter - KJ7RYV via 44net wrote:
That may help someone else, thanks for posting the link for those who
need it.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
Hi Tony,
You're
welcome Rosy, and I've left my email address in the survey, if
you want to follow up when the time comes. Next time around, it might
pay to have a facility in the survey to allow people with IP allocations
to be able to list each one separately and answer the questions
separately for them.
Just finished the survey, covers a lot of good
issues. Only thing I'd
comment on is it's hard to summarise across my two allocations - they
are _very_ different in many respects, both technologically (BGP vs
IPIP), use (infrastructure vs experimentation), degree of use (fully
utilised vs limited deployment), and importance (mission critical vs
experimental/tinkering).
Thank you for sharing this, Tony. This insight is super helpful. Also, in future, could you please use both the
redirect and direct URL
in emails. This PC has an IPIP based 44net address and has issues
reaching some ARDC hosted content(at best, veeery slow). I had to use
another PC without a 44net address to access the survey.
Yes! For anyone who wants the direct link, here it is:
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sour…
8:16 a.m.
On 19 May 2022, at 23:20, Tony Langdon via 44net
<44net(a)mailman.ampr.org> wrote:
Just finished the survey, covers a lot of good issues. Only thing I'd
comment on is it's hard to summarise across my two allocations - they
are _very_ different in many respects, both technologically (BGP vs
IPIP), use (infrastructure vs experimentation), degree of use (fully
utilised vs limited deployment), and importance (mission critical vs
experimental/tinkering).
You could always complete the survey twice, once for each allocation - you might need to
do the second one from a private/incognito browser session though.
Chris - G1FEF
Chris - G1FEF
—
ARDC IT Director
Web: https://www.ardc.net
22 May
22 May
7:24 p.m.
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are
interested in learning routing has been an invaluable learning
exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One
being supporting internet connected infrastructure (ie. IRLP, Allstar,
DMR, D-Star etc). All of which mostly require a public IPV4 address
and the ability to port forward. Such is not the case with cellular
providers and will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be
deployed. The POP’s might want to use OpenVPN as it's well supported
and issues automated keys or the ARRL LoTW method. It would be wise
to limit the bandwidth to something modest and employ a DPI technique
to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups
making this happen. But these will likely be service specific. Ex, I
believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF
networks. Perhaps a portal question should exist to point them to
their geographic allocation or not. If the intent is non RF or mesh,
then a different allocation methodology should be employed (next chunk
in sequence)
I’ll stress again knowing who is doing what is always good so one can
privately coordinate forwarding partners, etc, and just folks to
experiment with.
Steve, KB9MWR
7:43 p.m.
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a
bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think
there's a balance to be struck - ham radio is about learning, but there shouldn't
be a high barrier to entry.
Dave/ad8g
-----Original Message-----
From: Steve L via 44net <44net(a)mailman.ampr.org>
Sent: Sunday, May 22, 2022 14:25
To: Rosy Schechter - KJ7RYV <rosy(a)ardc.net>
Cc: Amprnet 44 Net <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning
routing has been an invaluable learning exercise. I hope something like this can always
continue.
However there are other use cases that are more plug and play. One being supporting
internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which
mostly require a public IPV4 address and the ability to port forward. Such is not the
case with cellular providers and will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might
want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW
method. It would be wise to limit the bandwidth to something modest and employ a DPI
technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen.
But these will likely be service specific. Ex, I believe IRLP has done so with some
assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a
portal question should exist to point them to their geographic allocation or not. If the
intent is non RF or mesh, then a different allocation methodology should be employed (next
chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate
forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an email to
44net-leave(a)mailman.ampr.org
7:49 p.m.
My 2-pence (or cents)…
I typically use Pfsense for routing and the export tool for OpenVPN makes
creating certificates and exporting configs as easy as any other solution.
The subnets are plenty big enough for someone to create a platform that
supports more than one VPN type and people can choose what they prefer…
L2TP is built-in to some Huawei 4G routers for example, OVPN has an app for
just about every platform and Wireguard is good for Site-to-Site VPNs.
I have a service offering static addresses on both L2TP and OVPN, I may add
Wireguard later on.
On Sun, 22 May 2022 at 19:44, David Andrzejewski via 44net <
44net(a)mailman.ampr.org> wrote:
I might suggest WireGuard instead of OpenVPN. I know
it's newer but it's
also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of
routing. I think there's a balance to be struck - ham radio is about
learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message-----
From: Steve L via 44net <44net(a)mailman.ampr.org>
Sent: Sunday, May 22, 2022 14:25
To: Rosy Schechter - KJ7RYV <rosy(a)ardc.net>
Cc: Amprnet 44 Net <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are
interested in learning routing has been an invaluable learning exercise. I
hope something like this can always continue.
However there are other use cases that are more plug and play. One being
supporting internet connected infrastructure (ie. IRLP, Allstar, DMR,
D-Star etc). All of which mostly require a public IPV4 address and the
ability to port forward. Such is not the case with cellular providers and
will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be deployed.
The POP’s might want to use OpenVPN as it's well supported and issues
automated keys or the ARRL LoTW method. It would be wise to limit the
bandwidth to something modest and employ a DPI technique to drop bittorrent
fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups
making this happen. But these will likely be service specific. Ex, I
believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF
networks. Perhaps a portal question should exist to point them to their
geographic allocation or not. If the intent is non RF or mesh, then a
different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can
privately coordinate forwarding partners, etc, and just folks to experiment
with.
Steve, KB9MWR
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an email
to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
24 May
24 May
2:39 p.m.
New subject: VPN Tech (Was:Re: Re: 44Net Assessment Kickoff - Survey!)
On Sun, 22 May 2022, Mark Stevenson via 44net wrote:
I typically use Pfsense for routing and the export
tool for OpenVPN makes
creating certificates and exporting configs as easy as any other solution.
There's also opnsense, the white-box version of pfSense.
It is also possible to configure OpenVPN to use a cipher of "none",
which turns off encryption, but it leaves the connection subject to some
attacks. This may be useful if you need to cross a NAT by means of a
port forward, cross another network that doesn't permit encryption (like
Part 97 over the air), or are stacking VPNs in a VPN like VLANs. Another
possible use case for cipher = none is to eliminate delays and CPU
overhead however the hash function will contribute to jitter anyway.
prefer… L2TP is built-in to some Huawei 4G routers for
example, OVPN
has an app for just about every platform and Wireguard is good for
Site-to-Site VPNs.
I have a service offering static addresses on both L2TP and OVPN, I
may add Wireguard later on.
tinc is also an option and don't forget about IPSEC.
The IPIP mesh is not plug and play, which for
folks like me who
are interested in learning routing has been an invaluable
learning exercise. I hope something like this can always
continue.
Moreover, using IPIP requires the ability to load kernel modules, which
in some enviroments simply isn't possible but some of those environments
already support PPP, GRE, tun, and/or tap interfaces.
However there are other use cases that are more
plug and play.
One being supporting internet connected infrastructure (ie.
IRLP, Allstar, DMR, D-Star etc). All of which mostly require a
public IPV4 address and the ability to port forward. Such is
not the case with cellular providers and will only become more
of an issue as the global pool IPv4 addresses shrinks.
IPv6 is a solution for dealing with mobile connectivity providers and
other providers using Carrier-Grade NAT (CGNAT). Many of them already
have end-to-end IPv6 networks. Your mileage may vary (YMMV) based on the
quality of the IPv6 implementation in your edge device.
A system of geographic (Points Of Presence) POPs
should be
deployed. The POPs might want to use OpenVPN as it's well
supported and issues automated keys or the ARRL LoTW method. It
would be wise to limit the bandwidth to something modest and
employ a DPI technique to drop bittorrent fingerprints to ease
overall administration.
A CA and PKI portal isn't a bad idea but that can be an expensive,
on-going process depending on the solution implemented. ICANN provides
great examples of this with the various KSK key signing ceremonies on
YouTube. Certificates also reinforce authenticity, one of the three legs
of the "CIA Triad" for data security and assurance.
I think most of the hams using IP space for regional networks are going
to be thinking locally, regionally, or by state in terms of connectivity
and looking for where the internet traffic is likely exchanged as a way
of avoiding impacts due to disasters.
For the purposes of ARDC, open non-profit internet exchanges like SIX
https://www.seattleix.net/ are the best places for PoPs.
--
Kris Kirby, KE4AHR
Disinformation Architect, Systems Mangler, & Network Mismanager
22 May
22 May
11:27 p.m.
Wireguard is indeed very easy to set up and run, I am a big fan of it in general. But
Wireguard has the distinct disadvantage of being UDP only. OpenVPN can use UDP or TCP
based tunnels. For IRLP we chose to use TCP based tunnels.
While TCP has much more overhead, we found that with some connection technologies, TCP can
work wonders over flaky infrastructure, and high jitter connections. IRLP actually
requires very little bandwidth, less than 100 kbps maximum. But to work well, the packets
must arrive in the correct order, even if there is a bit of added delay. TCP numbers each
packet and always will deliver them in the correct order, or asks for retransmission. TCP
sessions are also easier to maintain over uncooperative routers or networks. Many
repeaters use cellular based links, the quality of which can vary a lot, especially if the
node/repeater is mobile.
—
Dave K9DC, K9IP
On May 22, 2022, at 14:43, David Andrzejewski via
44net <44net(a)mailman.ampr.org> wrote:
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a
bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think
there's a balance to be struck - ham radio is about learning, but there shouldn't
be a high barrier to entry.
Dave/ad8g
-----Original Message-----
From: Steve L via 44net <44net(a)mailman.ampr.org>
Sent: Sunday, May 22, 2022 14:25
To: Rosy Schechter - KJ7RYV <rosy(a)ardc.net>
Cc: Amprnet 44 Net <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in
learning routing has been an invaluable learning exercise. I hope something like this can
always continue.
However there are other use cases that are more plug and play. One being supporting
internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which
mostly require a public IPV4 address and the ability to port forward. Such is not the
case with cellular providers and will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s
might want to use OpenVPN as it's well supported and issues automated keys or the ARRL
LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI
technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen.
But these will likely be service specific. Ex, I believe IRLP has done so with some
assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a
portal question should exist to point them to their geographic allocation or not. If the
intent is non RF or mesh, then a different allocation methodology should be employed (next
chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately
coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR
23 May
23 May
8:50 a.m.
A big advantage of POPs over the current IPIP mesh is that you do not need to have
everyone
use the same tunneling protocol. POPs can offer multiple tunneling protocols and can
experiment
with new ones, without impact on all the other users of the network.
So there is no need to have a broad discussion about "do we use OpenVPN OR
wireguard", we can
offer both of them, and when a new protocol comes around next year we can just add it,
first
to one or a couple of POPs to try and test it, and then to all of them.
With the IPIP mesh we are stuck with using the same protocol everywhere, and when some
user
cannot use it due to limitations of their internet connection, they simply cannot join.
Also, having POPs as an intermediate makes the network scale much better, as each user
only
has a tunnel to one or a couple of POPs, instead of having a full mesh to everyone else.
The number of POPs can increase with demand and they can be located where demand is
highest.
Rob
On 5/22/22 20:43, David Andrzejewski via 44net wrote:
I might suggest WireGuard instead of OpenVPN. I know
it's newer but it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think
there's a balance to be struck - ham radio is about learning, but there shouldn't
be a high barrier to entry.
Dave/ad8g
-----Original Message-----
From: Steve L via 44net <44net(a)mailman.ampr.org>
Sent: Sunday, May 22, 2022 14:25
To: Rosy Schechter - KJ7RYV <rosy(a)ardc.net>
Cc: Amprnet 44 Net <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in
learning routing has been an invaluable learning exercise. I hope something like this can
always continue.
However there are other use cases that are more plug and play. One being supporting
internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which
mostly require a public IPV4 address and the ability to port forward. Such is not the
case with cellular providers and will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s
might want to use OpenVPN as it's well supported and issues automated keys or the ARRL
LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI
technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen.
But these will likely be service specific. Ex, I believe IRLP has done so with some
assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a
portal question should exist to point them to their geographic allocation or not. If the
intent is non RF or mesh, then a different allocation methodology should be employed (next
chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately
coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an email to
44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
26 May
26 May
6:36 p.m.
I like the regional pops idea and add the ability to have redundant
connectivity for an end user (individual or entity). So I connect to a
west coast and a central or east coast pop in the US. Europe and others
can do something similar. If I wanted, maybe I can connect to as many
pops as I think I need to. Could also be admin limited to keep things
from getting too crazy. POPs are a full mesh between regions.
End user setup is MUCH more simple at that point as well. No scripts to
install hundreds of tunnels into a MikroTik router.
I like the idea that a POP can support multiple tunnel methods. I mean
why not right? :D
Are there any programs or ham friendly datacenters that could help with
regional bandwidth and transport between hops? When I think regional, I
think of things like AWS, Azure and Google Cloud with their multi-region
setups. Maybe a bit overkill but something to consider I guess?
Charlie/K7AKT
On 2022-05-23 00:50, Rob PE1CHL via 44net wrote:
A big advantage of POPs over the current IPIP mesh is
that you do not
need to have everyone
use the same tunneling protocol. POPs can offer multiple tunneling
protocols and can experiment
with new ones, without impact on all the other users of the network.
So there is no need to have a broad discussion about "do we use
OpenVPN OR wireguard", we can
offer both of them, and when a new protocol comes around next year we
can just add it, first
to one or a couple of POPs to try and test it, and then to all of them.
With the IPIP mesh we are stuck with using the same protocol
everywhere, and when some user
cannot use it due to limitations of their internet connection, they
simply cannot join.
Also, having POPs as an intermediate makes the network scale much
better, as each user only
has a tunnel to one or a couple of POPs, instead of having a full mesh
to everyone else.
The number of POPs can increase with demand and they can be located
where demand is highest.
Rob
On 5/22/22 20:43, David Andrzejewski via 44net wrote:
I might suggest WireGuard instead of OpenVPN. I
know it's newer but
it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of
routing. I think there's a balance to be struck - ham radio is about
learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message-----
From: Steve L via 44net <44net(a)mailman.ampr.org>
Sent: Sunday, May 22, 2022 14:25
To: Rosy Schechter - KJ7RYV <rosy(a)ardc.net>
Cc: Amprnet 44 Net <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are
interested in learning routing has been an invaluable learning
exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One
being supporting internet connected infrastructure (ie. IRLP, Allstar,
DMR, D-Star etc). All of which mostly require a public IPV4 address
and the ability to port forward. Such is not the case with cellular
providers and will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be
deployed. The POP’s might want to use OpenVPN as it's well supported
and issues automated keys or the ARRL LoTW method. It would be wise
to limit the bandwidth to something modest and employ a DPI technique
to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups
making this happen. But these will likely be service specific. Ex, I
believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF
networks. Perhaps a portal question should exist to point them to
their geographic allocation or not. If the intent is non RF or mesh,
then a different allocation methodology should be employed (next chunk
in sequence)
I’ll stress again knowing who is doing what is always good so one can
privately coordinate forwarding partners, etc, and just folks to
experiment with.
Steve, KB9MWR
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an
email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
6:59 p.m.
On 5/26/22 19:36, charlie--- via 44net wrote:
I like the regional pops idea and add the ability to have redundant connectivity for an
end user (individual or entity). So I connect to a west coast and a central or east coast
pop in the US. Europe and others can do something similar. If I wanted, maybe I can
connect to as many pops as I think I need to. Could also be admin limited to keep things
from getting too crazy. POPs are a full mesh between regions.
Yes, that is also part of my design. An entry-level user can connect to a single PoP and
get "their subnet" routed to them, and route all other Net44 space towards that
PoP. Simple, static routing.
A more advanced user can make multiple PoP connections and use BGP to send and receive
individual subnet routes, and let their local router decide to which of the PoPs to send
each packet. That would also cover the case where a PoP is down and all traffic is routed
via the remaining one(s).
These users can also have cross-connections to other users (via radio or direct tunnels)
and the routing remains correct.
End user setup is MUCH more simple at that point as well. No scripts to install hundreds
of tunnels into a MikroTik router.
Indeed, the setup of one or more tunnel connections and (if desired) BGP peers is very
simple in a MikroTik router.
Are there any programs or ham friendly datacenters
that could help with regional bandwidth and transport between hops? When I think
regional, I think of things like AWS, Azure and Google Cloud with their multi-region
setups. Maybe a bit overkill but something to consider I guess?
Several HAMs have stuff in datacenters and could be part of such a network, but a PoP
could be an inexpensive VPS in such a cloud network as well. Some platforms have
difficulty with protocols like IPIP, but it would be phased out anyway.
The PoPs would be interlinked using a (partial) mesh of tunnels, and when possible in that
VPS service they can also announce a local part of the Net44 space on internet using BGP,
so traffic between local users and internet takes a shorter path.
The advantage is that a PoP can announce a larger network ( /24 .. /16 for example) and
the local users take a smaller subnet out of that, reducing the number of BGP subnet
announcements on internet while keeping the efficiency of a local announcement.
Also many users now announce a /24 because that is the minimum size on internet, while
they require much less than that.
Centralizing the BGP announcements also makes the administrative effort much less, both
for users and network admins.
Of course to make this efficient it is best when IP allocations, also when they are to be
BGP announced, remain roughly tied to geographical region.
Unfortunately that is not what is currently happening.
Rob
27 May
27 May
12:02 a.m.
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net <
44net(a)mailman.ampr.org> wrote:
Yes, that is also part of my design. An entry-level user can connect to a
single PoP and get "their subnet" routed to them, and route all other Net44
space towards that PoP. Simple, static routing.
A more advanced user can make multiple PoP connections and use BGP to send
and receive individual subnet routes, and let their local router decide to
which of the PoPs to send each packet. That would also cover the case
where a PoP is down and all traffic is routed via the remaining one(s).
These users can also have cross-connections to other users (via radio or
direct tunnels) and the routing remains correct.
--
John D. Hays
Kingston, WA
K7VE / WRJT-215
12:10 a.m.
That sort of thing can be accomplished with routing protocols like BGP, of course.
Along these lines, I might be interested in participating in a 44net network built to use
a routed topology. Maybe it’s something like, we use iBGP among ourselves, and those with
access to PoPs (like via Vultr etc), can manage access to the public internet on our
behalf.
Someday maybe anyway
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: John D. Hays via 44net <44net(a)mailman.ampr.org>
Sent: Thursday, May 26, 2022 6:02:34 PM
To: Rob PE1CHL <44net(a)pe1chl.nl>
Cc: 44net(a)mailman.ampr.org <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net
<44net@mailman.ampr.org<mailto:44net@mailman.ampr.org>> wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP and
get "their subnet" routed to them, and route all other Net44 space towards that
PoP. Simple, static routing.
A more advanced user can make multiple PoP connections and use BGP to send and receive
individual subnet routes, and let their local router decide to which of the PoPs to send
each packet. That would also cover the case where a PoP is down and all traffic is routed
via the remaining one(s).
These users can also have cross-connections to other users (via radio or direct tunnels)
and the routing remains correct.
--
John D. Hays
Kingston, WA
K7VE / WRJT-215
9:52 a.m.
Of course, but the reason I proposed this was that when suggesting a PoP network where
everyone would connect and send their traffic via probably 2 PoP hops to the destination
was that there was the immediate reaction that "this would be so much less
efficient" and
"I want to send my traffic directly to the guy I am BBS forwarding to" etc.
So in my design that is perfectly possible, you can setup a private tunnel to anyone and
when using BGP that will automatically be taken as a shorter path. Of course it would
even
be possible with static routing.
And indeed, a first level of fallback could be created using some list of PoPs to call and
selecting
an alternative when the first is unreachable. Will depend on the router software what is
easier to achieve: two permanent connections and autorouting, or two connections with
only one being active at any time.
My point is that the such a network is much more flexible than the IPIP mesh we have now,
which essentially is using static routing and cannot handle any alternatives.
Rob
On 5/27/22 01:02, John D. Hays via 44net wrote:
Another approach would be auto-failover between PoPs
in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net <44net(a)mailman.ampr.org>
wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP
and get "their subnet" routed to them, and route all other Net44 space towards
that PoP. Simple, static routing.
A more advanced user can make multiple PoP connections and use BGP to send and
receive individual subnet routes, and let their local router decide to which of the PoPs
to send each packet. That would also cover the case where a PoP is down and all traffic
is routed via the remaining one(s).
These users can also have cross-connections to other users (via radio or direct
tunnels) and the routing remains correct.
--
John D. Hays
Kingston, WA
K7VE / WRJT-215
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
10:43 a.m.
I think the main issue in this endeavor is to attract more users to our
network.
Proficient users may use whatever alternatives they like, and they have
the necessary knowledge to do it.
The problem is the networking novice, which may have basic networking
skills, but lack the "advanced" part, and of course the regular or
occasional user, which requires plain network access, without backups,
fall backs, roaming, fixed location independent addresses and other
goodies, using SOHO class equipment..
For such users, a regional POP access using standard VPN technologies
and optional standard routing protocols is a perfect opportunity to get
a foothold in this domain while the POPs themselves provide network
integration and backbone routing (no matter what the technology behind -
it may well be our current mesh for the beginning, and various
connection techniques to the POP really don't matter as long as they are
well supported). The most important thing is that the access should be
as plain and transparent as possible for a novice, and require the
dumbest equipment possible for permanent access.
Advanced features may come late on a need to use basis, after the
initial learning curve. Let's create momentum by expanding the user base
first and worry about advanced user level stuff later, keeping the
wizardry at POP level.
Marius, YO2LOJ
On 27/05/2022 11:52, Rob PE1CHL via 44net wrote:
Of course, but the reason I proposed this was that
when suggesting a
PoP network where
everyone would connect and send their traffic via probably 2 PoP hops
to the destination
was that there was the immediate reaction that "this would be so much
less efficient" and
"I want to send my traffic directly to the guy I am BBS forwarding to"
etc.
So in my design that is perfectly possible, you can setup a private
tunnel to anyone and
when using BGP that will automatically be taken as a shorter path. Of
course it would even
be possible with static routing.
And indeed, a first level of fallback could be created using some list
of PoPs to call and selecting
an alternative when the first is unreachable. Will depend on the
router software what is
easier to achieve: two permanent connections and autorouting, or two
connections with
only one being active at any time.
My point is that the such a network is much more flexible than the
IPIP mesh we have now,
which essentially is using static routing and cannot handle any
alternatives.
Rob
On 5/27/22 01:02, John D. Hays via 44net wrote:
Another approach would be auto-failover between
PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net
<44net(a)mailman.ampr.org> wrote:
Yes, that is also part of my design. An entry-level user can
connect to a single PoP and get "their subnet" routed to them,
and route all other Net44 space towards that PoP. Simple, static
routing.
A more advanced user can make multiple PoP connections and use
BGP to send and receive individual subnet routes, and let their
local router decide to which of the PoPs to send each packet.
That would also cover the case where a PoP is down and all
traffic is routed via the remaining one(s).
These users can also have cross-connections to other users (via
radio or direct tunnels) and the routing remains correct.
--
John D. Hays
Kingston, WA
K7VE / WRJT-215
_______________________________________________
44net mailing list --44net(a)mailman.ampr.org
To unsubscribe send an email to44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list --44net(a)mailman.ampr.org
To unsubscribe send an email to44net-leave(a)mailman.ampr.org
11:04 a.m.
Marius,
I fully agree with that. But as you have seen, when suggestions are made here to change
towards such a network, there always is negative feedback from some people who just
do not want to change, and bring up "advantages" of the current IPIP mesh to
explain
why we should keep it like that.
That is why I tried to provide solutions to enable those people to come on board.
Probably the vast majority of users is well served with a single VPN tunnel to a single
PoP
somewhere in their network neighborhood, routing only their own subnet. They will
never get involved in the "more advanced" topics like running multiple tunnels
to either
more than one PoP and/or to a friend, and using automatic routing protocols.
Having a local PoP to enable connections from end-users and have that PoP on the
IPIP mesh (and on internet BGP), yes, that is what we have been doing here for many
years.
But in many other places, this local solution does not exist and new users are forced to
setup an IPIP mesh node themselves, which as you know is possible but presents a lot
of challenges.
Rob
On 5/27/22 11:43, Marius Petrescu via 44net wrote:
I think the main issue in this endeavor is to attract more users to our network.
Proficient users may use whatever alternatives they like, and they have the necessary
knowledge to do it.
The problem is the networking novice, which may have basic networking skills, but lack
the "advanced" part, and of course the regular or occasional user, which
requires plain network access, without backups, fall backs, roaming, fixed location
independent addresses and other goodies, using SOHO class equipment..
For such users, a regional POP access using standard VPN technologies and optional
standard routing protocols is a perfect opportunity to get a foothold in this domain while
the POPs themselves provide network integration and backbone routing (no matter what the
technology behind - it may well be our current mesh for the beginning, and various
connection techniques to the POP really don't matter as long as they are well
supported). The most important thing is that the access should be as plain and transparent
as possible for a novice, and require the dumbest equipment possible for permanent
access.
Advanced features may come late on a need to use basis, after the initial learning curve.
Let's create momentum by expanding the user base first and worry about advanced user
level stuff later, keeping the wizardry at POP level.
Marius, YO2LOJ
On 27/05/2022 11:52, Rob PE1CHL via 44net wrote:
Of course, but the reason I proposed this was
that when suggesting a PoP network where
everyone would connect and send their traffic via probably 2 PoP hops to the destination
was that there was the immediate reaction that "this would be so much less
efficient" and
"I want to send my traffic directly to the guy I am BBS forwarding to" etc.
So in my design that is perfectly possible, you can setup a private tunnel to anyone and
when using BGP that will automatically be taken as a shorter path. Of course it would
even
be possible with static routing.
And indeed, a first level of fallback could be created using some list of PoPs to call
and selecting
an alternative when the first is unreachable. Will depend on the router software what
is
easier to achieve: two permanent connections and autorouting, or two connections with
only one being active at any time.
My point is that the such a network is much more flexible than the IPIP mesh we have
now,
which essentially is using static routing and cannot handle any alternatives.
Rob
On 5/27/22 01:02, John D. Hays via 44net wrote:
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org Another approach would be auto-failover between
PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net <44net(a)mailman.ampr.org>
wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP
and get "their subnet" routed to them, and route all other Net44 space towards
that PoP. Simple, static routing.
A more advanced user can make multiple PoP connections and use BGP to send and
receive individual subnet routes, and let their local router decide to which of the PoPs
to send each packet. That would also cover the case where a PoP is down and all traffic
is routed via the remaining one(s).
These users can also have cross-connections to other users (via radio or direct
tunnels) and the routing remains correct.
--
John D. Hays
Kingston, WA
K7VE / WRJT-215
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
11:26 a.m.
But the use of POPs does not preclude keeping the current mesh.
From the point of view of the existing users, POPs are just gateways in
the mesh, announcing a bigger network, like e.g. a /16 for national
services, maybe even a /16 via BGP if possible. Nothing changes at
first, and established setups will continue to work, and there is no
change needed to their configurations. Of course, if they want, they can
alter their setup later on.
It is not changing/replacing existing functionalities, but adding to them.
At least this is how I would see such a development.
Marius
On 27/05/2022 13:04, Rob PE1CHL via 44net wrote:
Marius,
I fully agree with that. But as you have seen, when suggestions are
made here to change
towards such a network, there always is negative feedback from some
people who just
do not want to change, and bring up "advantages" of the current IPIP
mesh to explain
why we should keep it like that.
That is why I tried to provide solutions to enable those people to
come on board.
6:24 p.m.
The disadvantage of the IPIP mesh it that it cannot cope with node outages or rerouting to
users.
So, when the IPIP mesh would be used as the backbone between the PoPs, the functions of
PoP failover and redundancy by connecting to multiple PoPs or using a fallback mechanism
(connect to an alternative PoP when one is unreachable) cannot be realized.
To have that, we need a (possibly partial) tunnel mesh between the PoPs, where a routing
protocol
like BGP is used between the PoPs so they can tell eachother about the connected users
and
their subnets, instead of the "static" system that the IPIP mesh uses.
(where routing of a subnet to a PoP/gateway is fixed and determined by configuration
only,
not by network state)
So I think to have a real improvement in the network, the IPIP mesh as it exists now
should be abandoned.
Of course first the PoP network can be built first, then the users can be encouraged to
move over,
then the IPIP mesh can be shut down.
Large announcements on the IPIP mesh would be moved first, end-users can follow later.
Rob
On 5/27/22 12:26, Marius Petrescu via 44net wrote:
But the use of POPs does not preclude keeping the
current mesh.
From the point of view of the existing users, POPs are just gateways in the mesh,
announcing a bigger network, like e.g. a /16 for national services, maybe even a /16 via
BGP if possible. Nothing changes at first, and established setups will continue to work,
and there is no change needed to their configurations. Of course, if they want, they can
alter their setup later on.
It is not changing/replacing existing functionalities, but adding to them.
At least this is how I would see such a development.
Marius
On 27/05/2022 13:04, Rob PE1CHL via 44net wrote:
Marius,
I fully agree with that. But as you have seen, when suggestions are made here to change
towards such a network, there always is negative feedback from some people who just
do not want to change, and bring up "advantages" of the current IPIP mesh to
explain
why we should keep it like that.
That is why I tried to provide solutions to enable those people to come on board.
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org 
4 Jun
4 Jun
9:22 p.m.
New subject: 44Net Assessment Survey Now Also Available in German, Japanese, and French
**
*Der „44Net Assessment Survey“ ist jetzt auch auf Deutsch, Japanisch und
Französisch verfügbar*
**
L’enquête d’évaluation de 44Net est désormais également disponible en
allemand, japonais et français
44Net評価アンケート調査は、ドイツ語版、日本語版、フランス語版があります。
**
*--- *
*
Hello 44Net Mailing List,
We have now completed professional translations of the 44Net Assessment
survey released on this mailing list. Please use either link below to
access the survey in your preferred language. Translations of the
original outreach message are included below.
http://survey.ardc.net/ <http://survey.ardc.net/>
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sour…
<https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website>
We appreciate your patience and look forward to reading your responses!
Warmly,
Merideth & the ARDC team
Hallo 44Net-Mailingliste,
wir haben jetzt die professionelle Übersetzung der
44Net-Bewertungsumfrage abgeschlossen, die auf dieser Mailingliste
veröffentlicht wurde. Bitte verwenden Sie die nachstehenden Links, um
die Umfrage in Ihrer bevorzugten Sprache abzurufen. Nachstehend finden
Sie die Übersetzungen der Originalbotschaft.
http://survey.ardc.net/ <http://survey.ardc.net/>
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sour…
<https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website>
Wir danken Ihnen für Ihre Geduld und freuen uns darauf, Ihre Antworten
zu lesen!
Mit freundlichen Grüßen,
Merideth und das ARDC-Team
Bonjour membre de la liste de diffusion 44Net,
Nous avons maintenant terminé les traductions professionnelles de
l'enquête d'évaluation 44Net diffusée via cette liste de diffusion.
Merci d’utiliser les liens ci-dessous pour accéder à l'enquête dans la
langue de votre choix. Les traductions du message de sensibilisation
initial sont incluses ci-dessous.
http://survey.ardc.net/ <http://survey.ardc.net/>
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sour…
<https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website>
Nous vous remercions pour votre temps et sommes impatient(e)s de lire
vos réponses !
Chaleureusement,
Merideth et l'équipe de l'ADRC
44Netメーリングリスト購読者各位
今回、このメーリングリストでリリースされた、44Net評価アンケート調査の専門家による翻訳が完了いたしました。以下のリンクを使用して、ご希望の言語で本アンケート調査にアクセスしてください。元のアウトリーチメッセージの翻訳は、以下にございます。
http://survey.ardc.net/ <http://survey.ardc.net/>
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sour…
<https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website>
本アンケート調査へのご協力ありがとうございます。ご回答をお待ちしております。
敬具
Merideth & ARDCチーム
*
On 5/19/22 12:42 PM, Rosy Schechter - KJ7RYV via 44net wrote:
Hello 44Net Mailing List,
There has been a lot of discussion on this list about the state of
44Net. Some people like how it works, some would like to see an
upgrade. In order to make an informed decision that takes a variety of
viewpoints into account, ARDC is conducting an assessment. For the
first phase, we’ve put together a survey, which we'd love for you to
fill out. Our aim is to get input from as many people as possible to
help influence the network’s next chapter.
Click here to go to the survey:
survey.ardc.net
(Please note that the above is a redirect.)
We expect that it will take around 15 minutes to complete.
The survey is currently being translated into French, German, and
Japanese, shoud you prefer to take it in another language. Thank you
for your patience as we complete professional translations. We’ll post
them here as soon as they are ready!
It’s important to note: the survey is not a voting mechanism - it’s a
research tool. We’ll also be conducting interviews and focus groups
with a subset of users. Results from all research will be shared
publicly (personal information excluded) on ampr.org.
If you have questions about this survey or are interested in being
interviewed or part of a focus group, reach out to us at any time:
contact(a)ardc.net. You can also follow the assessment’s progress by
signing up for our newsletter.
Thank you in advance for sharing your input - we look forward to
reading your responses!
Warmly,
Rosy & the ARDC team
Hallo 44Net-Mailinglist,
auf dieser Liste wurde viel über den Stand des 44Net diskutiert. Einige
Leuten sind mit dem gegenwärtigen Stand zufrieden, andere würden gerne
ein Upgrade sehen. ARDC führt eine Bewertung durch, um eine fundierte
Entscheidung treffen zu können, die eine Vielzahl von Gesichtspunkten
berücksichtigt. Für die erste Phase haben wir eine Umfrage
zusammengestellt, und wir würden uns freuen, wenn Sie diese ausfüllen
würden. Unser Ziel ist es, von so vielen Menschen wie möglich Beiträge
zu erhalten, die als Grundlage zur Gestaltung des nächsten Kapitels des
Netzwerks dienen werden.
Klicken Sie hier, um zur Umfrage zu gelangen:
survey.ardc.net (Hinweis: Dies ist eine URL-Weiterleitung)
Wir gehen davon aus, dass das Ausfüllen der Umfrage etwa 15 Minuten in
Anspruch nehmen wird.
Wichtiger Hinweis: Die Umfrage ist kein Abstimmungsmechanismus, sondern
ein Forschungsinstrument. Darüber hinaus werden wir mit einem Teil der
Nutzer Interviews durchführen und Fokusgruppen bilden. Die Ergebnisse
der Forschung werden auf ampr.org öffentlich zugänglich gemacht (ohne
personenbezogene Informationen).
Wenn Sie Fragen zu dieser Umfrage bzw. Interesse daran haben, an einer
Befragung oder einer Fokusgruppe teilzunehmen, können Sie sich jederzeit
an uns wenden: contact(a)ardc.net. Sie können die Fortschritte der
Bewertung auch verfolgen, indem Sie sich für unseren Newsletter anmelden.
Wir bedanken uns im Voraus für Ihren Beitrag und freuen uns darauf, Ihre
Antworten zu lesen!
Mit freundlichen Grüßen, Rosy und das ARDC-Team
Bonjour membre de la liste de diffusion 44Net,
Beaucoup de discussions ont eu lieu dans cette liste à propos de l'état
de 44Net. Certaines personnes aiment la façon dont les choses
fonctionnent, certaines aimeraient voir une mise à niveau. L’ARDC
réalise une évaluation afin de prendre une décision éclairée tenant
compte d'un éventail de points de vue. Pour la première phase, nous
avons préparé une enquête à laquelle nous serions heureux que vous
répondiez. Notre objectif est de recueillir des retours du plus grand
nombre de personnes possible pour nous guider vers le prochain chapitre
du réseau.
Cliquez ici pour accéder à l’enquête :
survey.ardc.net
(Veuillez noter que le lien ci-dessus implique une redirection.)
Nous estimons que cela prendra 15 minutes environ.
Il est important de noter que cette enquête n'est pas un outil de vote,
mais un outil de recherche. Nous réaliserons également des entretiens et
mettrons en place des groupes de discussion avec de plus petits groupes
d’utilisateurs et utilisatrices. Les résultats de cette enquête seront
partagés publiquement (données personnelles exclues) sur ampr.org.
En cas de questions sur cette enquête ou si vous souhaitez être
interrogé(e) ou faire partie d'un groupe de discussion, contactez-nous à
l’adresse : contact(a)ardc.net. Vous avez également la possibilité de
suivre les avancées de l’évaluation en vous abonnant à notre newsletter.
Nous vous remercions par avance de partager vos commentaires, nous
serons heureux de connaitre vos réponses !
Chaleureusement,
Rosy et l’équipe de l’ARDC
44Netメーリングリスト購読者各位
44Netの状況について、このメーリングリストでたくさんの討議がなされてきました。機能方法を好む方、アップグレードを希望している方もいます。さまざまな視点を考慮した上で、十分な情報に基づく決定を行うために、ARDCでは評価を実施しております。この第一段階として、アンケート調査を作成いたしました。皆様からご回答いただければ幸いです。ARDCの将来に良い影響をもたらすために役立つよう、できるだけ多くの方々からご意見を伺うことを目的としております。
アンケート調査に進むには、ここをクリックしてください。
survey.ardc.net
（上記のリンクに転送されます。）
このアンケート調査の所要時間は約15分です。
ご注意いただきたい点は、このアンケート調査は投票機構ではなく、調査ツールであることです。一部のユーザーの方々には、インタビューやフォーカスグループも実施いたします。アンケート調査結果（個人情報を除く）はすべて、ampr.orgに公開されます。
本アンケート調査について何かご質問がある場合、またはインタビューやフォーカスグループに参加することに興味をお持ちの場合、いつでもcontact@ardc.netまでご連絡ください。また、ニュースレターに登録して、進捗状況を追跡することもできます。
あなたのご意見を共有いただけることに前もってお礼を申し上げます。ご回答をお待ちしております。
敬具
Rosy & the ARDCチーム
--
Merideth Stroh - KK7BKI
Operations Manager
Amateur Radio Digital Communications (ARDC)
www.ardc.net
695
days inactive
711
days old
22 comments
15 participants
participants (15)
-
charlie＠theboenings.com -
Chris Smith -
Dave Gingrich -
David Andrzejewski -
John Burwell -
John D. Hays -
Kris Kirby -
Marius Petrescu -
Mark Stevenson -
Merideth Stroh -
Paul Sladen -
Rob PE1CHL -
Rosy Schechter - KJ7RYV -
Steve L -
Tony Langdon