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.