Hi Adam,

> We've always referred to alt.* and free.* as unmanaged or
> unadministered. I don't think a hierarchy de-listed from control.ctl
> should be referred to in that manner.

I've at last reorganized the listing, following our previous discussion.
Only alt.* and free.* are now in the unmanaged page. The previously
listed ones were now in the historic section.

http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

--
Julien ÉLIE

« PowerPoint allows speakers to pretend that they are giving a real
talk, and audiences to pretend that they are listening. » (Edward R.
Tufte, _The Cognitive Style of PowerPoint_)

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

>Hi Adam,

>>We've always referred to alt.* and free.* as unmanaged or
>>unadministered. I don't think a hierarchy de-listed from control.ctl
>>should be referred to in that manner.

>I've at last reorganized the listing, following our previous discussion.
> Only alt.* and free.* are now in the unmanaged page. The previously
>listed ones were now in the historic section.

> http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

That's reasonable. Thank you

I don't have any new comments about the categories that you haven't
heard me make in the past.

Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
as well, but you listed it as historic.

Hi Adam,

>> I've at last reorganized the listing, following our previous discussion.
>> Only alt.* and free.* are now in the unmanaged page. The previously
>> listed ones were now in the historic section.
>
>> http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
>
> That's reasonable. Thank you

Thanks for having had a look.

> I don't have any new comments about the categories that you haven't
> heard me make in the past.

Yes, sure, I remember. The point is that these web pages are a visual
representation of the control.ctl / PGPKEYS / newsgroups files. Changes
should be made upstream.

> Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
> as well, but you listed it as historic.

For example, if mod.* should be listed as reserved (which it could, like
example.*, general.* or test.*), the change to do is in the following file:
https://github.com/rra/control-archive/blob/master/config/mod
"type: defunct" should be changed to "type: reserved"

Incidentally, I see in
https://github.com/rra/control-archive/blob/master/forms/control.ctl.pre

that example.*, local.* and private.* (other already reserved groups)
could also be added to this special entry:

## Special reserved groups
newgroup:*:control|general|junk|test|to:drop
rmgroup:*:control|general|junk|test|to:drop

If you already have a list of such changes to do, you may want to put it
into an issue in https://github.com/rra/control-archive/issues
When Russ has a bit of time for that, it will facilitate the integration
instead of digging in threads in this newsgroup.
(Or course, a direct pull request with the changed files would be even
better if you happen to know how git works.)

net.* is said to be "a failed experiment which has now been abandoned"
in the comments. Would you have seen it in another category than historic?
As the control.ctl entry is "drop" for newgroup and rmgroup, it is not a
"public managed" hierarchy. I previously listed it under "public
unmanaged" but now that only alt.* and free.* are considered to be
unmanaged, I moved all these hierarchies without a control.ctl entry
with an explicit e-mail adress to the "historic" state.

--
Julien ÉLIE

« Ta remise sur pied lui a fait perdre la tête ! » (Astérix)

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:

it-alt.*
oesterreich.*

>>Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
>>as well, but you listed it as historic.

>For example, if mod.* should be listed as reserved (which it could, like
>example.*, general.* or test.*), the change to do is in the following file:
> https://github.com/rra/control-archive/blob/master/config/mod
>"type: defunct" should be changed to "type: reserved"

>Incidentally, I see in
> https://github.com/rra/control-archive/blob/master/forms/control.ctl.pre

>that example.*, local.* and private.* (other already reserved groups)
>could also be added to this special entry:

>## Special reserved groups
>newgroup:*:control|general|junk|test|to:drop
>rmgroup:*:control|general|junk|test|to:drop

>If you already have a list of such changes to do, you may want to put it
>into an issue in https://github.com/rra/control-archive/issues

Ok. I'll see if I can do that.

>When Russ has a bit of time for that, it will facilitate the integration
>instead of digging in threads in this newsgroup.
>(Or course, a direct pull request with the changed files would be even
>better if you happen to know how git works.)

>net.* is said to be "a failed experiment which has now been abandoned"
>in the comments. Would you have seen it in another category than historic?
>As the control.ctl entry is "drop" for newgroup and rmgroup, it is not a
>"public managed" hierarchy. I previously listed it under "public
>unmanaged" but now that only alt.* and free.* are considered to be
>unmanaged, I moved all these hierarchies without a control.ctl entry
>with an explicit e-mail adress to the "historic" state.

net.* was of course the pre-Great Renaming top-level hierarchy in B News
days. Usenet II reused the defunct hierarchy because it hadn't been
reserved, but that's not the reason for failure. I suppose leave it
listed as historic but add a note about its pre-Great Renaming use.

mod.* was the B News top-level hierarchy for moderated groups before
things were recoded so that a proto-article could be sent in email to
the moderator in the newsreader.

This hierarchy should definitely be reserved.

fa.* (from ARPANET) were gatewayed mailing lists. I have no idea how
clients worked in B News days, but I'm guessing that you had the same
problem as moderated groups, no way to send the proto-article to the
list posting address with the newsreader.

I'd reserve that too.

I recall fj.* (from Japan), which I think were gated mailing lists as well.
Good heavens. It's listed as still active.

I'll write up some notes and send it to github.

Hi Adam,

> Now that I've glanced at control.ctl again, two other unmanaged
> hierarchies are listed:
>
> it-alt.*
> oesterreich.*

Oh indeed, I could especially mark them as "unmanaged" too.
I see there is no newsgroups for these two hierarchies in the
ftp.isc.org newsgroups file though, contrary to alt.* and free.*.

oesterreich.* seems to still be somehow active as their web site was
updated in 2022 :
http://www.tahina.priv.at/~cm/oe/index.en.html

> mod.* was the B News top-level hierarchy for moderated groups before
> things were recoded so that a proto-article could be sent in email to
> the moderator in the newsreader.
>
> fa.* (from ARPANET) were gatewayed mailing lists. I have no idea how
> clients worked in B News days, but I'm guessing that you had the same
> problem as moderated groups, no way to send the proto-article to the
> list posting address with the newsreader.
[...]> I'll write up some notes and send it to github.

These are pretty useful and interesting information.
Worthwhile keeping somewhere. I open a new thread about that.

--
Julien ÉLIE

« Passion is inversely proportional to the amount of real information
available. » (Benford's law)

Hi Adam,

> Now that I've glanced at control.ctl again, two other unmanaged
> hierarchies are listed:
>
> it-alt.*
> oesterreich.*

While looking at making the change in the web pages, I see we did not
speak about other alternative hierarchies.

Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a
validation by a sort of Board?

no.alt.* has 41 newsgroups listed in ftp.isc.org, nl-alt.* only 3.

And what for de.alt.*? Shouldn't it be considered as "unmanaged"?
If I remember well, there's a possibility to create any newsgroup in
de.alt.* (its control.ctl entry has a doit for a newgroup control
article) and for the sake of not removing them with de.* PGP-signed
checkgroups, they are included in de.* checkgroups.

--
Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

>Hi Adam,

>>Now that I've glanced at control.ctl again, two other unmanaged
>>hierarchies are listed:

>> it-alt.*
>> oesterreich.*

>While looking at making the change in the web pages, I see we did not
>speak about other alternative hierarchies.

I had simply noticed it-alt.* and oesterreich.* in rone's unified
control.clt and your generated list. I don't have first hand knowledge.

>Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
>They both have an associated PGP key but I do not know what is the
>policy to create a newsgroup? Is it intended after any demand of
>someone and a signed control article is then sent, or is there a
>validation by a sort of Board?

>no.alt.* has 41 newsgroups listed in ftp.isc.org, nl-alt.* only 3.

I cannot guess what the policies are, but if the control messages
use a PGP key, even if there is some informality about adding a group to
checkgroups, I'd call that "managed", given that the proponent would
never send the newgroup message himself. The keyholder has got to be
considered to be the hierarchy manager for this purpose.

This has the advantage that there can be checkgroups issued regularly,
an impossibility in truly unmanaged hierarchies.

>And what for de.alt.*? Shouldn't it be considered as "unmanaged"?
>If I remember well, there's a possibility to create any newsgroup in
>de.alt.* (its control.ctl entry has a doit for a newgroup control
>article) and for the sake of not removing them with de.* PGP-signed
>checkgroups, they are included in de.* checkgroups.

Is that why no.alt.* control messages are signed as well, because these
newsgroups are listed in the checkgroups for no.*?

It seems to me that the hierarchy manager's main job is to list groups
he recognizes in checkgroups, even if there are groups newgrouped in a
second-level hierachy with informal procedures.

If there's a checkgroups, that provides satisfactory evidence of
hierarchy management. Similarly, a PGP key provides satisfactory
evidence of hierarchy management.

But if the proponent and not the hierarchy administrator issues newgroup
messages in de.alt.* that would never include a PGP key, that requires
a comment.

I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as
unmanaged.

Hi Adam,

>>> Now that I've glanced at control.ctl again, two other unmanaged
>>> hierarchies are listed:
>
>>> it-alt.*
>>> oesterreich.*
>
>> While looking at making the change in the web pages, I see we did not
>> speak about other alternative hierarchies.
>
> I had simply noticed it-alt.* and oesterreich.* in rone's unified
> control.clt and your generated list. I don't have first hand knowledge.

You're one of the most knowledgeable about Usenet hierarchies, that's
why I asked. :)

>> Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
>> They both have an associated PGP key but I do not know what is the
>> policy to create a newsgroup? Is it intended after any demand of
>> someone and a signed control article is then sent, or is there a
>> validation by a sort of Board?
>
> I cannot guess what the policies are, but if the control messages
> use a PGP key, even if there is some informality about adding a group to
> checkgroups, I'd call that "managed", given that the proponent would
> never send the newgroup message himself. The keyholder has got to be
> considered to be the hierarchy manager for this purpose.
>
> This has the advantage that there can be checkgroups issued regularly,
> an impossibility in truly unmanaged hierarchies.
>
> If there's a checkgroups, that provides satisfactory evidence of
> hierarchy management. Similarly, a PGP key provides satisfactory
> evidence of hierarchy management.

Agreed.

> But if the proponent and not the hierarchy administrator issues newgroup
> messages in de.alt.* that would never include a PGP key, that requires
> a comment.

I believe it is the case.

For instance, the last de.alt.comm.iphone+ipad+co created in 2012:
https://ftp.isc.org/pub/usenet/control/de/de.alt.comm.iphone+ipad+co.gz

Message-ID:
<newgroup-dac.iphone+ipad+co-20120518@thorongil.babylonsounds.com>
From: Simon Paquet <[snipped]>
Control: newgroup de.alt.comm.iphone+ipad+co
Newsgroups: de.alt.admin,de.alt.fan.ipod
Date: Fri, 18 May 2012 12:27:03 +0200

de.alt.comm.iphone+ipad+co is an unmoderated newsgroup, it has been
discussed in de.alt.admin and there was no significant protest.

Bitte richten Sie die unmoderierte Newsgroup de.alt.iphone+ipad+co ein.
Ueber die Einrichtung wurde in de.alt.admin diskutiert und es gab
keinen heftigen Protest.

For your newsgroups file:
de.alt.comm.iphone+ipad+co Apples mobile Geraete und ihre Software.

And afterwards, Thomas takes this newsgroup into account when sending
checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.
That's the sort of things we could mention in a revived "hierarchy
notes" file that I could display along with hierarchy information.

> I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as
> unmanaged.

Noted. Thanks for your motivated reasons. I agree with you.

BTW, I've added it-alt.* and oesterreich.* in the list of unmanaged
hierarchies:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

--
Julien ÉLIE

« Le chemin n'est pas difficile, c'est le difficile qui est le chemin. »
(Kierkegaard)

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

>Hi Adam,

>>>>Now that I've glanced at control.ctl again, two other unmanaged
>>>>hierarchies are listed:

>>>> it-alt.*
>>>> oesterreich.*

>>>While looking at making the change in the web pages, I see we did not
>>>speak about other alternative hierarchies.

>>I had simply noticed it-alt.* and oesterreich.* in rone's unified
>>control.clt and your generated list. I don't have first hand knowledge.

>You're one of the most knowledgeable about Usenet hierarchies, that's
>why I asked. :)

I don't read articles in groups in those hierarchies. The Italian and
German words I recognize are mainly from music lessons.

>>>Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
>>>They both have an associated PGP key but I do not know what is the
>>>policy to create a newsgroup? Is it intended after any demand of
>>>someone and a signed control article is then sent, or is there a
>>>validation by a sort of Board?

>>I cannot guess what the policies are, but if the control messages
>>use a PGP key, even if there is some informality about adding a group to
>>checkgroups, I'd call that "managed", given that the proponent would
>>never send the newgroup message himself. The keyholder has got to be
>>considered to be the hierarchy manager for this purpose.

>>This has the advantage that there can be checkgroups issued regularly,
>>an impossibility in truly unmanaged hierarchies.

>>If there's a checkgroups, that provides satisfactory evidence of
>>hierarchy management. Similarly, a PGP key provides satisfactory
>>evidence of hierarchy management.

>Agreed.

>>But if the proponent and not the hierarchy administrator issues newgroup
>>messages in de.alt.* that would never include a PGP key, that requires
>>a comment.

>I believe it is the case.

>For instance, the last de.alt.comm.iphone+ipad+co created in 2012:
> https://ftp.isc.org/pub/usenet/control/de/de.alt.comm.iphone+ipad+co.gz

>Message-ID:
><newgroup-dac.iphone+ipad+co-20120518@thorongil.babylonsounds.com>
>From: Simon Paquet <[snipped]>
>Control: newgroup de.alt.comm.iphone+ipad+co
>Newsgroups: de.alt.admin,de.alt.fan.ipod
>Date: Fri, 18 May 2012 12:27:03 +0200

>de.alt.comm.iphone+ipad+co is an unmoderated newsgroup, it has been
>discussed in de.alt.admin and there was no significant protest.

>Bitte richten Sie die unmoderierte Newsgroup de.alt.iphone+ipad+co ein.
>Ueber die Einrichtung wurde in de.alt.admin diskutiert und es gab
>keinen heftigen Protest.

>For your newsgroups file:
>de.alt.comm.iphone+ipad+co Apples mobile Geraete und ihre Software.

>And afterwards, Thomas takes this newsgroup into account when sending
>checkgroups for the de.* hierarchy.
>And he also cleans up no longer used groups in de.alt.* when appropriate.

He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.

>That's the sort of things we could mention in a revived "hierarchy
>notes" file that I could display along with hierarchy information.

I appreciate your enthusiasm. That file might be edited every 20 years
or so, heh.

>>I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as
>>unmanaged.

>Noted. Thanks for your motivated reasons. I agree with you.

>BTW, I've added it-alt.* and oesterreich.* in the list of unmanaged
>hierarchies:
> http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged

Thank you.

Hi Adam,

>> And afterwards, Thomas takes this newsgroup into account when sending
>> checkgroups for the de.* hierarchy.
>> And he also cleans up no longer used groups in de.alt.* when appropriate.
>
> He won't list the group in the next checkgroups. I don't think I've
> noticed that he issues rmgroups for defunct de.alt.* groups.

There are PGP-signed rmgroup control articles for the removals too.
Example with the last one removed:
https://ftp.isc.org/usenet/control/de/de.alt.rec.flugsimulation.gz

Control: rmgroup de.alt.rec.flugsimulation
Message-ID:
<rmgroup-de.alt.rec.flugsimulation-20220205@thangorodrim.ancalagon.de>
Date: Sat, 05 Feb 2022 21:29:34 -0000

But the From address (at thh.name) is not the one expected by the
control.ctl entry (at dana.de) so they were not processed by ftp.isc.org.
However, checkgroups for de.* are properly processed, and the de.alt.*
newsgroups are then removed at that time according to the ftp.isc.org rules.

>> That's the sort of things we could mention in a revived "hierarchy
>> notes" file that I could display along with hierarchy information.
>
> I appreciate your enthusiasm. That file might be edited every 20 years
> or so, heh.

:)

--
Julien ÉLIE

« Non omnia possumus omnes. » (Virgile)

Julien <iulius@nom-de-mon-site.com.invalid> wrote:

>Hi Adam,

>>>And afterwards, Thomas takes this newsgroup into account when sending
>>>checkgroups for the de.* hierarchy.
>>>And he also cleans up no longer used groups in de.alt.* when appropriate.

>>He won't list the group in the next checkgroups. I don't think I've
>>noticed that he issues rmgroups for defunct de.alt.* groups.

>There are PGP-signed rmgroup control articles for the removals too.
>Example with the last one removed:
> https://ftp.isc.org/usenet/control/de/de.alt.rec.flugsimulation.gz

>Control: rmgroup de.alt.rec.flugsimulation
>Message-ID:
><rmgroup-de.alt.rec.flugsimulation-20220205@thangorodrim.ancalagon.de>
>Date: Sat, 05 Feb 2022 21:29:34 -0000

>But the From address (at thh.name) is not the one expected by the
>control.ctl entry (at dana.de) so they were not processed by ftp.isc.org.

That's very interesting; thanks.

>However, checkgroups for de.* are properly processed, and the de.alt.*
>newsgroups are then removed at that time according to the ftp.isc.org rules.

>>>. . .

Adam H. Kerman wrote:

> He won't list the group in the next checkgroups. I don't think I've
> noticed that he issues rmgroups for defunct de.alt.* groups.

Newsgroups in de.alt.* are removed after a discussion period of at least
7-14 days when there is no "too strong" protest. They are removed by
rmgroup messages sent and signed by the proponent. As most people won't
execute control messages not signed by a hierarchy key, they are really
removed when they are subsequently dropped from the (joined) checkgroups
for de.* (including de.alt.*) sent by the hierarchy maintainers.

All other newsgroups in de.* (excluding de.alt.*) are removed by a formal
process of (at least) a RfD, submitted to a moderated newsgroup and posted
by the hierarchy maintainers, followed by a discussion period of (at
least) 14 days, followed by a CfV with a voting period of (at least) for
weeks, needing a majority and a quorum, followed by a result, all
according to a set of rules, posted to a moderated group and arbitrated by
hierarchy maintainers, who will sent and sign the control messages after a
objection period has passed.

That holds true even if the proponent for the removal of a de.alt.* group
_is_ the member of the hierarchy maintainer team tasked with sending the
checkgroups. :-)

-thh

Adam H. Kerman wrote:

> But if the proponent and not the hierarchy administrator issues newgroup
> messages in de.alt.* that would never include a PGP key, that requires
> a comment.

de.alt.* had been modelled after alt.*, as de.* had been modelled after
the Big8, so control messages for de.alt.* are traditionally sent by
proponents (signed with their keys) or by someone acting for the
proponent. Those groups are added to or removed from the checkgroups for
de.* by the hierarchy maintainer team; while - theoretically - just a
technical necessity, that makes the hierarchy maintainers the final
arbiter of disputes whether due process was followed before the control
message was send.

Historically, the rights and sinecures of de.alt.* have been jealously
defended against perceived infringements by hierarchy maintainers. :-)
Today, that's mainly moot as there are not many users left (and even less
interested in hierarchy administration or technically inclined or
qualified to sent control message).

Anyway, all groups in the checkgroups are created (and all missing groups
have been removed) by due process; it's just a very different process for
de.alt.*

-thh

Julien ÉLIE wrote:

> And what for de.alt.*? Shouldn't it be considered as "unmanaged"?

It's not really unmanaged, as de.* (including de.alt.*) is a managed
hierarchy, so de.alt.* is included in checkgroups messages for de.*.
Historically, that was the only option, and after a spectacularly
unsuccessful attempt with a scoped checkgroups we never tried again.

Today, it's mostly moot, due to declining Usenet usage and even more
declining interest and participation in "hierarchy management" of any
kind.

> If I remember well, there's a possibility to create any newsgroup in
> de.alt.* (its control.ctl entry has a doit for a newgroup control
> article) and for the sake of not removing them with de.* PGP-signed
> checkgroups, they are included in de.* checkgroups.

Yes and no; only "legitimate" de.alt.* groups are included in the
checkgroups for de.*, i.e. new groups are not added automatically, but by
hand by someone reading de.alt.admin, the "administrative" group for
de.alt.*

Excluding de.alt.*, de.* is using a formalised RfD/CfV process modelled
after the Big 8 in the 90s while de.alt.* has a kind of consensus-based
process: when a proposal is posted and there is no "strong" protest in the
next week (or two weeks), the group may be created by a newgroup message
sent and signed by the proponent (or someone on his or her behalf, if the
proponent lacks the expertise to send those messages). Theoretically,
every news server operator can then decide for him- or herself whether
(s)he wants to add that group or not, which ultimately presupposes that
(s)he's either reading de.alt.admin or just listening to their users;
honoring every newgroup message is not a good idea (as in alt.*). In
practice, however, server operators usually simply follow the checkgroups
for de.* - be it by setting up de.alt.* groups only after the checkgroups
has been received or by removing them again if not included in the
checkgroups. So in fact the person sending out the checkgroups for .de*
decides which groups in de.alt.* are "legitimate", i.e. were rightly set
up due to a lack of "too strong" protest.

So we have, on one hand, de.* (excluding de.alt.*) with the moderator (or
moderation) of de.admin.news.announce as hierarchy maintainer (or a team
of hierarchy maintainers, since 1997) and strict rules, a formal process
of RfDs, discussion periods, CfV and votes, where all control messages are
sent by the hierarchy maintainer team and signed with their key - and, on
the other hand, de.alt.*, with a fairness based approach, where control
messages (new/rmgroups) are sent and signed by the proponent.
Theoretically, both systems co-exist; in fact, the hierarchy maintainer
team has the last say even on groups in de.alt.* due to their inclusion in
the checkgroups for the whole hierarchy. While mostly theoretical, there
were instances of "control message wars" when not all participants agreed
wether there was "strong protest" or not.

Today, that's mostly just of historical interest, as most people able to
send control messages or conduct votes (or even interested in discussing
changes in the list of newsgroups) that are still active _are_ members of
the hierarchy maintainer team. *shrug*

tl;dr: Technically and factually, de.* is a managed hierarchy; newgroup
(and rmgroup) messages for de.alt.* are vetted before inclusion in the
checkgroups to check that "due process" was followed.