[rpd] Forum for policy discussions?

[Sylvain BAYA]

Le 12 octobre 2026 11:25:16 GMT+01:00, Hendrik Visage via RPD <rpd at afrinic.net> a écrit :
>
>
>On 12 Oct 2026, at 12:02, Sylvain BAYA wrote:
>
>> Le 8 octobre 2026 12:49:02 GMT+01:00, Jaco Kroon via RPD <rpd at afrinic.net> a écrit :
>>> Hi,
>>>
>>> If people stop using digests the problem would sort itself out on the spot.
>>>
>>
>> Dear Jaco,
>> Thanks for your email; brother!
>>
>> ...imho! it's not a matter of existance of
>> a particular *feature*; which particularly
>> exists for a *good* reason.
>
>The only reason for digests, I’ll contend to not be relevant in the RPD case as mentioned in another email
>

Hi Henrik,

Thanks for your email; brother :-)
...my suspicion is that, there are other 
acceptable usages; in the RPD mailing 
list context. That's why i have suggested 
to look at it more than twice ;-)

For example: 
|-1. if you are a PDWG member, and you 
| read your RPD emails on weekly basis 
| (which is, imho, compatible with Policy 
| Development lifecycle); 
|-2. then nothing prevent you to: 
|-3. contribute effectively;
|-4. because you still have the ability to 
| send an appropriately wrote email in 
| response to only the topic/thread you 
| chose to respond to.
| etc.

In my understanding, again, the feature 
availability/existance is not the *cause* 
of the *effects* some of us denounced...
and/or agreed to be *abusive* behavior.

>
>> What i suspect is that: some use of that
>> feature may result to an abuse behavior.
>>
>> If we observed it; then the recommended
>> reaction, imho, should be to look at the
>> causes and apply an appropriate fix.
>
>The cause:
>1) Humans not following Netiquette
> 

...we should be reminded that: 
human being *disabilities*, regarding 
Netiquette acceptance, may not actually 
be our main concern.

The main risk we are actually facing is: 
"humans to become unable to effectively 
participate to RPD discussions; due to AI based agents invasion".

...and, 
that should mostly concern us; at least 
more than a feature *misusedability*.

...as said: we should not set a precedent; 
on which we are not ready to deal with 
possible outcomes :'-(

>
>2) Humans feeding digests into LLM/AI/SI instead of the real email thus causing the issue.
>

Right! they certainly do! they shouldn't; imho.

...imho, if a human is doing that, it's not 
only because there is no other mean to 
automate (i) mailbox analysis, (ii) email 
response writing and (iii) posting to the 
appropriate mailing list.

They would have first changed the mail 
delivery option; which allows a mailing 
list subscriber to receive separate emails 
on its mailbox.

...my fear is that: removing the feature 
may cause more harm than good.

>
>I do have the theory that the use of the digests are also to hide the intentions or methods of entities that is out to frustrate AfriNIC and the RPD
>

...well! i suspect that your theory is *not* 
a sort of void conspiracy one; then this 
is the inference i can draw based on it: 

<proposed_procedure>
Dgst#1. If an email is in response to a 
digest email; then
Dgst#2. Hold it; 
Dgst#3. Run a script; in order to check 
for AI-based agent/automaton behavior; 
then 
Dgst#4. If (Dgst#3.) confirmed; then do 
the followings:
Dgst#4.1 Send an email to the sender 
with guidelines on how to appropriately 
post on mailinglists, including how to 
acceptably deal with digest emails.
Dgst#4.2 Drop that email or keep it on 
an alternative *ai-bad-posting* public archive.
Dgst#4.3 Remove posting rights when 
same poster keeps its posting trend for 
at least three times.
Dgst#5. If not (Dgst#3.) confirmed; then 
do the followings:
Dgst#5.1 Do the same as on Dgst#4.1; 
Dgst#5.2 Do the same as on Dgst#4.3, 
for a *reasonable* waiting time.
</proposed_procedure>

>
>> ...i propose to look at it twice or more;
>> because, we need to avoid to easily set
>> a precedent.
>> We should note that, next time our preferred *feature* would be abused by
>> some *exceptional* use; then next step
>> would be obviously to call for removing it.
>
>Where the “Feature” is not adding value
> 

Please see above; for some usecase; i'm 
considering that those affected users 
may become disadvantaged in the avent 
the *culprit* feature is dismantled :-/ 

>
> or absolute minimal given the use of archives and LLMs/AI/SI, and all the while the feature is a source of abuse and frustration, I’ll be the first to vote for the removal.
>

...i would be the first to défend your right 
to vote; brother :-)
but; as you know! voting helps not on the 
PDWG ;-)

>
>In this case, I’m content that the actual value is near minimal in the age of copilot/claude/clawd/etc. and (given the prevalence and increasing use of AI/SI/LLMs/Copilot/clawd/claude/hermes/etc. for doing exactly what digests are good for) will become more and more a source of frustration rather than adding value.
>

Interesting! regarding frustration...
Do kindly allow to state again what i forsee as what we might fear the most 
for the RPD mailing list participation: 

<do-not-read-twice>
The main risk we are actually facing is: 
"humans to become unable to effectively 
participate to RPD discussions; due to AI based agents invasion".
</do-not-read-twice>

>
>> This is not what we want?
>>
>> ...i recall that, there is this old resource:
>>
>> The rules of netiquette | Software Reference
>> :: https://web.archive.org/web/20120710021154/http://www.swref.com/story/20090705/the_rules_of_netiquette
>>
>> Etiquette in technology#Netiquette
>> :: https://en.wikipedia.org/wiki/Etiquette_in_technology#Netiquette
>
>
>Problem: the LLMs/AI/SI doesn’t adhere to that ;(
>We have seen that the past 6months ;(
> 

...thanks for voicing for us! i'm definitely 
not supporting both: 
(i) AI-based email 
response writing and 
(ii) AI-agentic email management where 
humans' Working Group (WG) mailing lists 
are the destination address.

It's a serious risk; on my understanding, 
at least :'-(

...i hope as a human-based WG, we would 
be able to correctly address that kind of 
subtile so-called "human replacement" 
attempt/initiative.

Hope it makes more sense now; brother.

Shalom,
--sb.