Re: What hierarchies are still active?

[Adam H. Kerman]

D. Stussy <newsgroup...@kd6lvw.ampr.org> wrote:

>What hierarchies are still active? From the point of view of
>"checkgroups" messages, here are the results:

>About 24 hierarchies have posted checkgroups messages during 2017.
>Another 30 hierarchies had older, locatable checkgroups messages since
>2012 OR had a web page with a checkgroups listing.
>About 93 PGP keys exist for checkgrouped hierarchies.

>A total of about 289 hierarchies have (or had) a checkgroups maintainer.

>This means that about 10% of hierarchies are actively checkgrouping.
>Another 10% has a checkgroups list available but haven't sent it recently.

>This leaves 80% of checkgroupable hierarchies that are INACTIVE (i.e.
>not being maintained).

>Except for those who have already sent a checkgroups message during 2017
>PLEASE ISSUE A CHECKGROUPS MESSAGE in July 2017. A failure
>to issue a checkgroups message could lead to a recommendation that the
>hierarchy be marked inactive and subsequently removed from
>the "control.ctl" file. Thank you for your cooperation.

So spaketh D.Stussy, the new Fluffy.

Cloo:

If you don't wish to offer a hierarchy, don't offer it, but please
don't make petty threats like the little tyrant you are.

Any number of hierarchies, especially regional hierarchies, have never
issued checkgroups and have never bothered with PGP signing. If anyone
played hierarchy administrator in the past, they may have moved away.

I can think of one notorious incident in which the PGP key to a
regional hierarchy was lost for a number of years. Every one of us
knows the story and there's no need to mention the name (to protect
the guilty party). No one dreamed of threatening to remove the
hierarchy's entry in control.ctl.

It's meaningless whether a hierarchy is currently administered or was
ever administered in a way that anyone might call "well organized".
Who cares. The act of hierarchy administration is irrelevant to whether
users are posting articles in a *.general group or some other group
in that hierarchy.

Unless there's a problem to be addressed, leave well enough alone.
If there's no reason to amend control.ctl, don't alter it.

[Matija Nalis]

On Sun, 2 Jul 2017 22:50:04 +0000 (UTC), Adam H. Kerman <a...@chinet.com> wrote:
> D. Stussy <newsgroup...@kd6lvw.ampr.org> wrote:
>>Except for those who have already sent a checkgroups message during 2017
>>PLEASE ISSUE A CHECKGROUPS MESSAGE in July 2017. A failure
>>to issue a checkgroups message could lead to a recommendation that the
>>hierarchy be marked inactive and subsequently removed from
>>the "control.ctl" file. Thank you for your cooperation.

D.Stussy, why? Has checkgroups support somehow become mandatory lately?

> Any number of hierarchies, especially regional hierarchies, have never
> issued checkgroups and have never bothered with PGP signing. If anyone
> played hierarchy administrator in the past, they may have moved away.

this IIRC stands correct for hr.* hierarchy at least. Any new groups issued
by documented procedures will send appropriate newgroups, but checkgroups
were not automated...

> Unless there's a problem to be addressed, leave well enough alone.
> If there's no reason to amend control.ctl, don't alter it.

sounds reasonable.

--
Opinions above are GNU-copylefted.

[Julien ÉLIE]

Hi Dieter,

> About 24 hierarchies have posted checkgroups messages during 2017.
> Another 30 hierarchies had older, locatable checkgroups messages since
> 2012 OR had a web page with a checkgroups listing.
> About 93 PGP keys exist for checkgrouped hierarchies.

Do you happen to know how many PGP keys are considered "obsolete" and no
longer widely accepted? Recent versions of GnuPG reject unsafe keys
using MD5 algorithm hashes.
This is a problem which should be dealt with but I do not see a smooth
transition. Regenerating new keys for hierarchy maintainers and adding
them for news administrators are huge changes.

--
Julien ÉLIE

« – Chef ! On vient !
– On se met en carré ?
– Non ! En bosquet ! » (Astérix)

[Thomas Hochstein]

Julien ÉLIE schrieb:

> Recent versions of GnuPG reject unsafe keys
> using MD5 algorithm hashes.
> This is a problem which should be dealt with but I do not see a smooth
> transition.

I fear one will have to deal with it by using older version of GnuPG
for that use case.

> Regenerating new keys for hierarchy maintainers and adding
> them for news administrators are huge changes.

Yes. And I don't see those changes as feasible in a dead, dying or at
least stale Usenet.

[Adam H. Kerman]

Thomas Hochstein <t...@inter.net> wrote:
>Julien schrieb:

Of all the problems, I see this one as being unimportant, and not just
because D.Stussy raised it. There's no issue unless a legitimate proponent
proposes a newsgroup in an administered hierarchy, following its rules
for proposing newsgroups. At that point, if he can argue that the hierarchy
administrator has abandoned his duties, yank the key from future
control.ctl.

Please don't do anything unless there's an issue.

Note that I said "legitimate proponent", which rules out typical unjustified
proposals: I just know it'll work! and There's no where to post on this topic!

Also, a legitimate proponent is someone known for posting on the topic
on Usenet.

[Thomas Hochstein]

Adam H. Kerman schrieb:

> Thomas Hochstein <t...@inter.net> wrote:
>> Julien schrieb:
>
>>> Recent versions of GnuPG reject unsafe keys
>>> using MD5 algorithm hashes.
>>> This is a problem which should be dealt with but I do not see a smooth
>>> transition.
>
>> I fear one will have to deal with it by using older version of GnuPG
>> for that use case.

[...]

> Of all the problems, I see this one as being unimportant, and not just
> because D.Stussy raised it. There's no issue unless a legitimate proponent
> proposes a newsgroup in an administered hierarchy, following its rules
> for proposing newsgroups.

There _is_ an issue, re-occuring about monthly, as checkgroups are
signed, too.

> At that point, if he can argue that the hierarchy
> administrator has abandoned his duties, yank the key from future
> control.ctl.

I'm not sure I can follow your reasoning here.

> Please don't do anything unless there's an issue.

The issue at hand are old hierarchy keys that will possibly be
rejected in future due to newer GnuPG versions.

Changing the hierarchy key is no easy feat as it requires cooperation
(and manual intervention) of (all) newsmasters carrying the hierarchy.

-thh

[Adam H. Kerman]

Thomas Hochstein <t...@inter.net> wrote:
>Adam H. Kerman schrieb:
>>Thomas Hochstein <t...@inter.net> wrote:
>>>Julien schrieb:

>>>>Recent versions of GnuPG reject unsafe keys
>>>>using MD5 algorithm hashes.
>>>>This is a problem which should be dealt with but I do not see a smooth
>>>>transition.

>>>I fear one will have to deal with it by using older version of GnuPG
>>>for that use case.

>[...]
>>Of all the problems, I see this one as being unimportant, and not just
>>because D.Stussy raised it. There's no issue unless a legitimate proponent
>>proposes a newsgroup in an administered hierarchy, following its rules
>>for proposing newsgroups.

>There _is_ an issue, re-occuring about monthly, as checkgroups are
>signed, too.

Abandoned cron job left running are rather irritating.

I agreed with your suggestion about continuing to use an older version
of GnuPG. It's extra work, I suppose, but control.ctl could include a
note about which version the key was created with.

I disagree with the suggestion of just removing the keys.

>>At that point, if he can argue that the hierarchy
>>administrator has abandoned his duties, yank the key from future
>>control.ctl.

>I'm not sure I can follow your reasoning here.

"He" in question is a proponent. I'm saying that there's no need to
declare the hierarchy unadministered unless an issue with a legitimate
proponent arises.

>>Please don't do anything unless there's an issue.

>The issue at hand are old hierarchy keys that will possibly be
>rejected in future due to newer GnuPG versions.

>Changing the hierarchy key is no easy feat as it requires cooperation
>(and manual intervention) of (all) newsmasters carrying the hierarchy.

The only alternative, if the hierarchy administrator doesn't generate new
keys with stronger encryption, is to declare the hierarchy unadministrated.
I'm saying don't do that. That the old key will fail isn't a reason to
do that.

[Moses]

What's this mean to cn.*? I believe the administrator and
main server of cn.* is missing for awhile, so there is no
one post checkgroups, but there are still some active
groups. Dose this mean the whole cn.* will be removed?


>>>>> "D" == D Stussy <sp...@spam.org> writes:

D> What hierarchies are still active? From the point of
D> view of "checkgroups" messages, here are the results:

D> About 24 hierarchies have posted checkgroups messages
D> during 2017. Another 30 hierarchies had older,
D> locatable checkgroups messages since 2012 OR had a
D> web page with a checkgroups listing. About 93 PGP
D> keys exist for checkgrouped hierarchies.

D> A total of about 289 hierarchies have (or had) a
D> checkgroups maintainer.

D> This means that about 10% of hierarchies are actively
D> checkgrouping. Another 10% has a checkgroups list
D> available but haven't sent it recently.

D> This leaves 80% of checkgroupable hierarchies that
D> are INACTIVE (i.e. not being maintained).

D> Except for those who have already sent a checkgroups
D> message during 2017 PLEASE ISSUE A CHECKGROUPS
D> MESSAGE in July 2017. A failure to issue a
D> checkgroups message could lead to a recommendation
D> that the hierarchy be marked inactive and
D> subsequently removed from the "control.ctl" file.
D> Thank you for your cooperation.

[Adam H. Kerman]

Moses <moses...@gmail.com> wrote:

>What's this mean to cn.*? I believe the administrator and
>main server of cn.* is missing for awhile, so there is no
>one post checkgroups, but there are still some active
>groups. Dose this mean the whole cn.* will be removed?

D.Stussy is making a mere suggestion that readily ignored. If you
were to subscribe to a News server, it's up to the News administrator
to offer cn.* groups to his users, not D.Stussy.

D.Stussy may make any suggestion he likes, but utterly lack authority,
except over his own News server and its non-existent users.

Please don't top post.

[Thomas Hochstein]

Adam H. Kerman schrieb:

> Thomas Hochstein <t...@inter.net> wrote:
>> There _is_ an issue, re-occuring about monthly, as checkgroups are
>> signed, too.
>
> Abandoned cron job left running are rather irritating.

Manual signing doesn't solve the problem ...

> I agreed with your suggestion about continuing to use an older version
> of GnuPG. It's extra work, I suppose, but control.ctl could include a
> note about which version the key was created with.

You'll have the same problem on the receiving end: newsservers with
newer versions of GnuPG can't cope with old keys.

> I disagree with the suggestion of just removing the keys.

A transition period will be necessary in any case, yes.

>> The issue at hand are old hierarchy keys that will possibly be
>> rejected in future due to newer GnuPG versions.
>
>> Changing the hierarchy key is no easy feat as it requires cooperation
>> (and manual intervention) of (all) newsmasters carrying the hierarchy.
>
> The only alternative, if the hierarchy administrator doesn't generate new
> keys with stronger encryption, is to declare the hierarchy unadministrated.

Changing hierarchy keys is no simple feat ...

> I'm saying don't do that. That the old key will fail isn't a reason to
> do that.

Yes, of course!

-thh

[Adam H. Kerman]

Thomas Hochstein <t...@inter.net> wrote:
>Adam H. Kerman schrieb:
>>Thomas Hochstein <t...@inter.net> wrote:

>>>There _is_ an issue, re-occuring about monthly, as checkgroups are
>>>signed, too.

>>Abandoned cron job left running are rather irritating.

>Manual signing doesn't solve the problem ...

Now you're changing the topic. If the hierarchy administrator is issuing
these manually, then the hierarchy is still being actively administered.
It's not abandoned. He's reachable and might be encouraged to implement
a higher-security key.

>>I agreed with your suggestion about continuing to use an older version
>>of GnuPG. It's extra work, I suppose, but control.ctl could include a
>>note about which version the key was created with.

>You'll have the same problem on the receiving end: newsservers with
>newer versions of GnuPG can't cope with old keys.

Do you not see how stupid this is, not to plan for backwards compatibility?

Then add a field to control.ctl stating which version the key was signed
with.

>>I disagree with the suggestion of just removing the keys.

>A transition period will be necessary in any case, yes.

Transition? You've been talking about exactly the opposite, that News
administrators are expected to implement the latest applications, only,
which won't support keys made in previous versions.

The problem you've been alluding to is that an older and newer version
of GnuPG cannot both be running on the same host. Right?

>>>The issue at hand are old hierarchy keys that will possibly be
>>>rejected in future due to newer GnuPG versions.

>>>Changing the hierarchy key is no easy feat as it requires cooperation
>>>(and manual intervention) of (all) newsmasters carrying the hierarchy.

>>The only alternative, if the hierarchy administrator doesn't generate new
>>keys with stronger encryption, is to declare the hierarchy unadministrated.

>Changing hierarchy keys is no simple feat ...

>>I'm saying don't do that. That the old key will fail isn't a reason to
>>do that.

>Yes, of course!

Glad we agree.

But my point all along has been that there's no problem to solve unless
and until a decent proponent known for discussing the topic proposes that a
properly justified group be created. Old hierarchy administrator abandoned
the hierarchy? Then a new one will just have to step forward. Otherwise
the topic can be discussed in the *.misc or *.general group and the list
of recognized newsgroups in that hierarchy will remain static.

[Thomas Hochstein]

Adam H. Kerman wrote:

> Thomas Hochstein <t...@inter.net> wrote:
>> Adam H. Kerman schrieb:

>>> Abandoned cron job left running are rather irritating.
>> Manual signing doesn't solve the problem ...
>
> Now you're changing the topic.

Oh, sorry. Perhaps we talk past each other.

My point was what I'd quoted in my first followup to Julien: the
problems around signing control messages with the upcoming changes in
GPG, and how to tackle that problems.

> If the hierarchy administrator is issuing
> these manually, then the hierarchy is still being actively administered.
> It's not abandoned.

Yes, of course.

> He's reachable and might be encouraged to implement
> a higher-security key.

And I was (and am) looking for the best way to do that - in a Usenet
that is shrinking and mostly stale.

>>> I disagree with the suggestion of just removing the keys.
>> A transition period will be necessary in any case, yes.
>
> Transition? You've been talking about exactly the opposite, that News
> administrators are expected to implement the latest applications, only,
> which won't support keys made in previous versions.

No, I am talking about the problem that we have - on the one hand -
old server installations that can only cope with the current, very old
keys, and that most probably won't be updated: those servers are left
over from the past and are "just running", so they will be rather
switched off than updated. And on the other hand we will - hopefully!
- have new installations with current versions of GnuPG that (some
day) can't cope with the old keys, but will require new keys. I'm not
sure they want to roll their old GnuPG installations.

So I'm looking for the best way to cope with that problem in the
future. For now we can just use the old keys - but that won't last.

> The problem you've been alluding to is that an older and newer version
> of GnuPG cannot both be running on the same host. Right?

I think it can, but it won't run "out of the box".

The problem is not the hierarchy maintainer - I can keep an older
version of GnuPG around -, but the "consumers" of the signed messages.

> But my point all along has been that there's no problem to solve unless
> and until a decent proponent known for discussing the topic proposes that a
> properly justified group be created. Old hierarchy administrator abandoned
> the hierarchy? Then a new one will just have to step forward. Otherwise
> the topic can be discussed in the *.misc or *.general group and the list
> of recognized newsgroups in that hierarchy will remain static.

I agree.

Sorry, I think I didn't make clear enough that I was discussing the
point Julien brought up in his followup (as that is something
bothering me, too), but not the question of "active" hierarchies.

(Which is another problem, but mostly one of missing participants, not
of missing checkgroups.)

-thh
--
/'\ --- JOIN NOW! ---
\ / ASCII ribbon campaign
X against HTML
/ \ in mail and news

[Julien ÉLIE]

Hi Thomas,

> Sorry, I think I didn't make clear enough that I was discussing the
> point Julien brought up in his followup (as that is something
> bothering me, too), but not the question of "active" hierarchies.

Here are a few ideas (of course not fully satisfying):

- encourage news admins to synchronize their newsgroups list with the
ftp.isc.org active file. With INN, actsync can be used. Other news
servers may provide a similar utility.
https://www.eyrie.org/~eagle/software/inn/docs/actsync.html

Admins will need updating their configuration for that way to work.

The control-archive program used by ftp.isc.org of course must be able
to correctly process control articles with old and recent PGP keys.



- provide some way for news servers to keep the PGP keys up-to-date.
For instance with INN, adding an /updatekey/ keyword in control.ctl to
specify the hierarchies for which to do that. A cron job would
periodically achieve that (against PGPKEYS in ftp.isc.org or for
instance
<http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).

Admins will need updating their news server for that way to work.



- use the NAS protocol (RFC 4707) instead of control articles, with the
addition of permitting to send several PGP keys in Section 6.7. It
would then fix the issue. Well, that would be a huge transition...
(less realistic than the above ideas)



- for a solution using only NNTP (and not an out-of-band way like HTTP
or NAS), we would need a new kind of control message permitting to
update keys. And find a way to authenticate that control message... I
bet we would still have issues of old PGP key with that solution.



Any other ideas?

--
Julien ÉLIE

« Je m'incline de bonne grâce devant tant de grâce. » (César
devant Cléopâtre)

[Adam H. Kerman]

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

>Hi Thomas,

>>Sorry, I think I didn't make clear enough that I was discussing the
>>point Julien brought up in his followup (as that is something
>>bothering me, too), but not the question of "active" hierarchies.

>Here are a few ideas (of course not fully satisfying):

>- encourage news admins to synchronize their newsgroups list with the
>ftp.isc.org active file. With INN, actsync can be used. Other news
>servers may provide a similar utility.
> https://www.eyrie.org/~eagle/software/inn/docs/actsync.html

>Admins will need updating their configuration for that way to work.

>The control-archive program used by ftp.isc.org of course must be able
>to correctly process control articles with old and recent PGP keys.

Isn't the synching typically done with one's upstream provider?

This has come up any number of times over the years. The argument
against it is ftp.isc.org is a test News server used to illustrate to
the proponent or hierarchy administrator how the control message would
be processed. Hence, any number of newsgroups were created here that
may not meet any News administrator's criteria for creation locally.

But the bigger counterargument is that hierarchies exist for which
checkgroups was never issued and for which newgroups and rmgroups were
issued inconsistently over the years, especially true of institutional and
regional hierarchies. You have personal experience of this with respect
to the unadministered microsoft.public.* hierarchy.

ftp.isc.org as an example of how to set up a new News server is better
than nothing, but there are superior choices.

>- provide some way for news servers to keep the PGP keys up-to-date.
>For instance with INN, adding an /updatekey/ keyword in control.ctl to
>specify the hierarchies for which to do that. A cron job would
>periodically achieve that (against PGPKEYS in ftp.isc.org or for
>instance
><http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).

>Admins will need updating their news server for that way to work.

What would it take to use control.ctl to distribute keys, given that it's
maintained on a regular basis? Is there a routine that could be written
to take the key from this file to be added to one's News server? That
would require control.ctl to be maintained its own key control to
avoid mischief.

[Thomas Hochstein]

Adam H. Kerman schrieb:

> Isn't the synching typically done with one's upstream provider?

Peers are peers and do not have an "upstream" ...

[Adam H. Kerman]

Eh.

You peer with an established News server. You receive articles from that
server. That's "down". It's hard to count something as peering till the
new News server has something to offer the rest of Usenet. "Peering" implies
something other than the extreme imbalance created when first setting
up a News server.

Lots of networking terms are somewhat euphemistic.

[Julien ÉLIE]

Hi Adam,

>> - encourage news admins to synchronize their newsgroups list with the
>> ftp.isc.org active file. With INN, actsync can be used. Other news
>> servers may provide a similar utility.
>> https://www.eyrie.org/~eagle/software/inn/docs/actsync.html

[...]

> This has come up any number of times over the years. The argument
> against it is ftp.isc.org is a test News server used to illustrate to
> the proponent or hierarchy administrator how the control message would
> be processed. Hence, any number of newsgroups were created here that
> may not meet any News administrator's criteria for creation locally.
>
> But the bigger counterargument is that hierarchies exist for which
> checkgroups was never issued and for which newgroups and rmgroups were
> issued inconsistently over the years, especially true of institutional and
> regional hierarchies. You have personal experience of this with respect
> to the unadministered microsoft.public.* hierarchy.

I understand the argument; yet, I do not see how news admins could
easily get the "common" list of newsgroups for such hierarchies. Using
the ftp.isc.org news server can serve, as there does not seem to exist
any better option.
If "reasonable" newsgroups should be added/deleted in these hierarchies,
people can ask for such a change.

> ftp.isc.org as an example of how to set up a new News server is better
> than nothing, but there are superior choices.

What are the superior choices?

>> - provide some way for news servers to keep the PGP keys up-to-date.
>> For instance with INN, adding an /updatekey/ keyword in control.ctl to
>> specify the hierarchies for which to do that. A cron job would
>> periodically achieve that (against PGPKEYS in ftp.isc.org or for
>> instance
>> <http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).
>
>> Admins will need updating their news server for that way to work.
>
> What would it take to use control.ctl to distribute keys, given that it's
> maintained on a regular basis?

There is also the PGPKEYS file similarly maintained on a regularly
basis, and made available through ftp.isc.org.
https://ftp.isc.org/pub/pgpcontrol/

It therefore does not need any addition to control.ctl.
One can regularly import all these keys. Moreover, it would work for
any news server (and not those based upon control.ctl like INN).

--
Julien ÉLIE

« Quand on sait que le pied vaut environ 33 cm et que l'alexandrin
compte 12 pieds, il est facile de calculer qu'un stade vaut environ 42
alexandrins. » (Astérix)

[Adam H. Kerman]

Julien wrote:
>Hi Adam,

>>>- encourage news admins to synchronize their newsgroups list with the
>>>ftp.isc.org active file. With INN, actsync can be used. Other news
>>>servers may provide a similar utility.

>>> https://www.eyrie.org/~eagle/software/inn/docs/actsync.html

>[...]

>>This has come up any number of times over the years. The argument
>>against it is ftp.isc.org is a test News server used to illustrate to
>>the proponent or hierarchy administrator how the control message would
>>be processed. Hence, any number of newsgroups were created here that
>>may not meet any News administrator's criteria for creation locally.

>>But the bigger counterargument is that hierarchies exist for which
>>checkgroups was never issued and for which newgroups and rmgroups were
>>issued inconsistently over the years, especially true of institutional and
>>regional hierarchies. You have personal experience of this with respect
>>to the unadministered microsoft.public.* hierarchy.

>I understand the argument; yet, I do not see how news admins could
>easily get the "common" list of newsgroups for such hierarchies. Using
>the ftp.isc.org news server can serve, as there does not seem to exist
>any better option.

If an institutional hierarchy wasn't administered with control messages,
then anything in the sample active file at ftp.isc.org is arbitrary.

>If "reasonable" newsgroups should be added/deleted in these hierarchies,
>people can ask for such a change.

One can request a newsgroup be created from one's News administrator, yes.
One cannot request that it appear in the active file at ftp.isc.org,
for that requires declaring one's self hierarchy administrator in order
to issue control messages.

The only reasonable way is to peer with the institution's own News server
and copy the groups it created.

>>ftp.isc.org as an example of how to set up a new News server is better
>>than nothing, but there are superior choices.

>What are the superior choices?

Copying the active files from the News servers one peers with. Isn't that
the traditional way? Sorry, but setting up a News server with all of the
groups in the active file at ftp.isc.org is usually some misguided notion
of obtaining an arbitrarily comprehensive set of newsgroups, misunderstading
its purpose.

>>>- provide some way for news servers to keep the PGP keys up-to-date.
>>>For instance with INN, adding an /updatekey/ keyword in control.ctl to
>>>specify the hierarchies for which to do that. A cron job would
>>>periodically achieve that (against PGPKEYS in ftp.isc.org or for
>>>instance
>>><http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).

>>>Admins will need updating their news server for that way to work.

>>What would it take to use control.ctl to distribute keys, given that it's
>>maintained on a regular basis?

>There is also the PGPKEYS file similarly maintained on a regularly
>basis, and made available through ftp.isc.org.

> https://ftp.isc.org/pub/pgpcontrol/ . . .

Ok. You're already doing that. Suggestion about control.ctl withdrawn.

[Julien ÉLIE]

Hi Adam,

>> I understand the argument; yet, I do not see how news admins could
>> easily get the "common" list of newsgroups for such hierarchies. Using
>> the ftp.isc.org news server can serve, as there does not seem to exist
>> any better option.
>
> If an institutional hierarchy wasn't administered with control messages,
> then anything in the sample active file at ftp.isc.org is arbitrary.
>
>> If "reasonable" newsgroups should be added/deleted in these hierarchies,
>> people can ask for such a change.
>
> One can request a newsgroup be created from one's News administrator, yes.
> One cannot request that it appear in the active file at ftp.isc.org,
> for that requires declaring one's self hierarchy administrator in order
> to issue control messages.
>
> The only reasonable way is to peer with the institution's own News server
> and copy the groups it created.

I beg to differ as the control.ctl file has the notion of "syncable
server" to mention the news server name of the institution. I then
believe that the groups present in that institution server can be
declared in the active file at ftp.isc.org, if asked.

BTW, if Russ reads us, the msnews.microsoft.com news server has retired.
It can be removed from control.ctl. Maybe the microsoft.* hierarchy
should now be considered historic or at least unmanaged? (there are
still a few discussions in some newsgroups)

--
Julien ÉLIE

« Dieu a dit : il faut partager. Les riches auront la nourriture, les
pauvres de l'appétit. » (Coluche)

[Adam H. Kerman]

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

>Hi Adam,

>>>I understand the argument; yet, I do not see how news admins could
>>>easily get the "common" list of newsgroups for such hierarchies. Using
>>>the ftp.isc.org news server can serve, as there does not seem to exist
>>>any better option.

>>If an institutional hierarchy wasn't administered with control messages,
>>then anything in the sample active file at ftp.isc.org is arbitrary.

>>>If "reasonable" newsgroups should be added/deleted in these hierarchies,
>>>people can ask for such a change.

>>One can request a newsgroup be created from one's News administrator, yes.
>>One cannot request that it appear in the active file at ftp.isc.org,
>>for that requires declaring one's self hierarchy administrator in order
>>to issue control messages.

>>The only reasonable way is to peer with the institution's own News server
>>and copy the groups it created.

>I beg to differ as the control.ctl file has the notion of "syncable
>server" to mention the news server name of the institution. I then
>believe that the groups present in that institution server can be
>declared in the active file at ftp.isc.org, if asked.

Well, if the hierarchy's control is listed, one would write and request
peering. If it's a regional hierarchy, I think it's wise to peer with
someone responsible physically located in the region. I wouldn't expect
it would be noted in control.ctl.

>BTW, if Russ reads us, the msnews.microsoft.com news server has retired.
> It can be removed from control.ctl. Maybe the microsoft.* hierarchy
>should now be considered historic or at least unmanaged? (there are
>still a few discussions in some newsgroups)

The category should be "abandoned by its institution".

[RS Wood]

On 2017-08-04, Moses <moses...@gmail.com> wrote:
>
> What's this mean to cn.*? I believe the administrator and
> main server of cn.* is missing for awhile, so there is no
> one post checkgroups, but there are still some active
> groups. Dose this mean the whole cn.* will be removed?
>
>
>>>>>> "D" == D Stussy <sp...@spam.org> writes:
>
> D> What hierarchies are still active? From the point of
> D> view of "checkgroups" messages, here are the results:
>
> D> About 24 hierarchies have posted checkgroups messages
> D> during 2017. Another 30 hierarchies had older,
> D> locatable checkgroups messages since 2012 OR had a
> D> web page with a checkgroups listing. About 93 PGP
> D> keys exist for checkgrouped hierarchies.
>
> D> A total of about 289 hierarchies have (or had) a
> D> checkgroups maintainer.
>
> D> This means that about 10% of hierarchies are actively
> D> checkgrouping. Another 10% has a checkgroups list
> D> available but haven't sent it recently.

I manage the dictator.* hierarchy, which as far as I can tell has a total of
two readers. Looks like I'm in the second category: checkgroups sent since
2012 but not recently.

I sent out a checkgroups in mid-2017, and another one just now. I don't see
that either has been archived, which makes me think it hasn't propogated.
How can I check?

Regardless, the info in the control.ctl file is correct at ftp.isc.org.

I'd like to verify control messages are propogating as I'd like to send one
every six months or so, just as a sign of life.

[Grant Taylor]

On 06/21/2018 12:02 PM, RS Wood wrote:
> I sent out a checkgroups in mid-2017, and another one just now.
> I don't see that either has been archived, which makes me think it
> hasn't propogated. How can I check?

I'm not sure how to check off the top of my head.

That being said, I did just receive checkgroups message.

Message-ID: <checkgroups...@stalin.dictatorshandbook.net>

> I'd like to verify control messages are propogating as I'd like to send
> one every six months or so, just as a sign of life.

--
Grant. . . .
unix || die

[RS Wood]

On 2018-06-21, Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 06/21/2018 12:02 PM, RS Wood wrote:
>> I sent out a checkgroups in mid-2017, and another one just now.
>> I don't see that either has been archived, which makes me think it
>> hasn't propogated. How can I check?
>
> I'm not sure how to check off the top of my head.
>
> That being said, I did just receive checkgroups message.
>
> Message-ID: <checkgroups...@stalin.dictatorshandbook.net>

Thanks Grant. That seems to confirm the checkgroup messages are
propogating.

Kind regards. R

[Grant Taylor]

On 06/21/2018 05:33 PM, RS Wood wrote:
> Thanks Grant.

You're welcome.

> That seems to confirm the checkgroup messages are propogating.

Agreed.

[Julien ÉLIE]

Hi RS Wood,

> I sent out a checkgroups in mid-2017, and another one just now. I don't see
> that either has been archived, which makes me think it hasn't propogated.
> How can I check?

You can check the logs of ftp.isc.org here:
https://ftp.isc.org/pub/usenet/CONFIG/LOGS/

You'll then see that the 2 checkgroups you sent on June 21st failed to
be processed (a line with the keyword "processed" should be present):

2018-06-21 17:00:03 [11306]
<checkgroups...@stalin.dictatorshandbook.net> archived checkgroups
2018-06-21 17:20:02 [12427]
<checkgroups...@stalin.dictatorshandbook.net> PGP: gpg:
Signature made Thu Jun 21 10:08:14 2018 PDT using RSA key ID 8361E3C3
2018-06-21 17:20:02 [12427]
<checkgroups...@stalin.dictatorshandbook.net> PGP: gpgv exited
with status 2
2018-06-21 17:20:02 [12427]
<checkgroups...@stalin.dictatorshandbook.net> archived checkgroups

> Regardless, the info in the control.ctl file is correct at
> ftp.isc.org.

Configuration can also be seen here:
http://usenet.trigofacile.com/hierarchies/index.py?see=DICTATOR

> I'd like to verify control messages are propogating as I'd like to send one
> every six months or so, just as a sign of life.

That's pretty good practise!

--
Julien ÉLIE

« Vanitas uanitatum et omnia uanitas. » (Ecclésiaste)

[Adam H. Kerman]

Julien <iul...@nom-de-mon-site.com.invalid> wrote:
>Hi RS Wood,

>>I sent out a checkgroups in mid-2017, and another one just now. I don't see
>>that either has been archived, which makes me think it hasn't propogated.
>>How can I check?

>You can check the logs of ftp.isc.org here:
> https://ftp.isc.org/pub/usenet/CONFIG/LOGS/

>You'll then see that the 2 checkgroups you sent on June 21st failed to
>be processed (a line with the keyword "processed" should be present):

>2018-06-21 17:00:03 [11306]
><checkgroups...@stalin.dictatorshandbook.net> archived checkgroups
>2018-06-21 17:20:02 [12427]
><checkgroups...@stalin.dictatorshandbook.net> PGP: gpg:
>Signature made Thu Jun 21 10:08:14 2018 PDT using RSA key ID 8361E3C3
>2018-06-21 17:20:02 [12427]
><checkgroups...@stalin.dictatorshandbook.net> PGP: gpgv exited
>with status 2
>2018-06-21 17:20:02 [12427]
><checkgroups...@stalin.dictatorshandbook.net> archived checkgroups

Because the key isn't in the keyring?

[RS Wood]

On 2018-07-02, Adam H. Kerman <a...@chinet.com> wrote:
> Julien <iul...@nom-de-mon-site.com.invalid> wrote:
>>Hi RS Wood,

>>You'll then see that the 2 checkgroups you sent on June 21st failed to
>>be processed (a line with the keyword "processed" should be present):
>

> Because the key isn't in the keyring?

That's my question as well - is there something I should do, as
administrator? Is it possible the key wasn't updated when I had to rebuild
my server a few years ago?

[Adam H. Kerman]

Send Russ a message in email.