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