1 May
2021
1 May
'21
2:23 a.m.
On Wed, 7 Apr 2021, pete M wrote:
>> And no, we wont talk about it here as it is a
work in progress.
> Seems like a missed opportunity to gain from the benefits of
> collaborative iteration, feedback, and sharing---the very spirit of
>Ham + open source + internet, where AMPRnet sits at the junction of.
Hello Pierre et al,
And it will be discussed here, but not before it will
be more
structured and close to its final form.
Hope so...: tomorrow, 2021-05-01 is T+2 years since 44.192/10 went.
...and 2021 is T+20 years since CAIDA published the Code Red
data-analysis produced from the 2001-era 44/8 Amprnet logging.
That is 18 years of keeping one's mouth shut, participating in an
"open secret" because the published research was good and useful---and
politely ignoring the Miltech/DARPA/etc funding for development of
large-scale automated capture + tapping infrastructure, occuring in
the process, on HAM allocations.
That changed in mid-2019 with the (*apparently unanimous) decision of
the three directors [all associated with UCSD/CAIDA]---removing a
quarter of the monitored blackhole space (44.192/10), through enabling
and allowing a sale to proceed.
Hence, my interpretion of that action (rightly or wrongly) was as
implying that the primary research activities were substantially
complete---and so no further need to participate in sustaining an open
secret still unknown by many (including TAC members of the time).
Hence:
https://en.wikipedia.org/wiki/AMPRNet#UCSD_Network_Telescope
(Again, an open secret ... the research papers and slashdot commentary
have been published for years---it's all cited with quotes and links
to the biblography to assist others in their own reading).
The Tecnical Advisory Commitee (TAC) been created for
such task.
It is a nice working commitee that works on such project.
(To the best of my knowledge) members of the TAC were under-informed
of the plans for 44.192/10 beforehand two years ago---leading to the
corresponding technial breakage because of the lack of opportunity for
meaningful input. And...
(To the best of my knowledge) members of the TAC remain (today)
under-informed, not being proactively informed of the contractual
arrangements with UCSD for on-going data-collection/colocation---or
even the existence and timeline of those arrangements. ;-)
There seems little point scheming up ideas behind closed doors,
whilst being simulataneously behind another closed door.
Maybe you can apply to work on it at the next opening?
Thank you for the thought----the TAC has [already] just recently
gained a new chair, to try and pull things together; so there is the
opportunity to transition to being meaningful open---but that requires
buy-in from everyone.
My standing offer, remains to help assist in
organising/filtering/curating the information already available, in
order to provide a foundation for others (TAC, Hams, Directors,
Employees, ...) to discussion and work effectively.
We can review:
https://git.ampr.org/explore
Not a single eg. board minute has been published, so far.
Not a single like of ARDC-funded portal code has been pushed, so far.
Should that situation change, you are welcome to re-approach me!
...IMHO, at the moment it is a more effective contribution to
provide encouragement from the sidelines.
It would be kind of counterproductive to have a
commitee and then
have everyone commenting on a project,
Might be worth a try :-)
You don't know until you've done it, and it's highly likely that TAC
may learn a thing-or-two about Amprnet in the process.
Of course some people wont be happy, there is always
someone,
don't ask why I know ;-)
Please share openly and tell us more... particularly so when
excouraging others to sign up for roles within Ampr/ARDC/TAC it would
be great to hear what's going on. At the moment it's the usual
deafening radio silence.
But with planification, and change, the futur of the
whole adress
space will be taken into account and the plan does not account for
selling any part of it,
Based on two years ago---TAC had/have _zero_ control over whether any
address space is sold. What the TAC /could/ do, would be to be plan
for how address migrations/realloc()ations should happen in response
to such events.
(...If a plan cannot cope with sudden address space resizing/
dynamically adjusting (larger or smaller), then the plan is probably
flawed...)
Keep watching here, when it will be more finish every
one will see it.
We do, keep watching. CQ? CQ? CQ?
-Paul