Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Writing tools

Jaco Kroon jaco at uls.co.za
Mon Jul 20 15:02:43 UTC 2026


Hi Rob,

On 2026/07/20 16:40, Rob Evans wrote:
> Mike, all
>
>> But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post.
> As someone with no hats to wear, but an occasional interest in global
> address policy.
>
> One of the challenges I've found reading the list traffic over the
> last few days has been that some of the emails generated using
> 'writing tools' can appear vague and flowery[1].  It can be difficult
> to debate a point when it's almost impossible to fathom what point is
> being made.
You and me both.
> I fully appreciate that having a discussion take place in English when
> that is, at best, the second language of many of the participants
> means that using tools to translate the discussion can be invaluable
> for having an inclusive discussion, but I wonder if it is also
> possible to ask the tools to be more concise as part of whatever
> prompt is being used?
In support of short concise language.  And actually making the point.
>
>  From what I can see, the major objections relating to the hierarchical
> AS-SET naming are:
>    - The solution isn't perfect and doesn't state its limitations.

No one claimed it's perfect.  But it does two things:

* It protects against naming collisions between multiple RIR (having 
been on the victim side ...).  The long and the short is that it causes 
major routing filter problems when these collisions happen.  The effects 
of which we all know too well I expect.
* It assigns ownership, as in, we can know which AS published it.

It still does not state how authentic the data is, in other words, let's 
say AS65500 decides to include AS65511 into it's set, who's to say that 
AS65511 wants to be included?  There are attributes in the autnum 
objects which relates to this problem, but they are only meaningful if 
we can protect against collisions.

In other words - it improves upon the current situation.  There's a 
saying that done is better than perfect.  Or as Nishal points out - 
incremental improvements, which is obviously better than no improvement.

No software, and pretty much no system gets held back until it's perfect 
- if that was the case we'd still be waiting for ... well, even the most 
basic of operating system to be released.  There's good enough, and risk 
is low enough.  Since the current level of risk exceeds that of the 
proposed change it overall lowers risk, and as such is a move in the 
right direction.  Is it complete?  By no means.  But we can't wait for 
the bricks on top of the wall to be manufactured before we start laying 
down useful foundations.

>    - This is an overreach of the RIR into something that doesn't need policy.

I'm getting the same.  But this isn't being driven by the RIR, it's a 
community desired policy related to IRR data being kept by the RIR in 
accordance with the wishes of it's members - and those people against 
the policy has (to the best of my knowledge) not disclosed their 
affiliations, or what operational problems (as implied) this policy can 
cause that worries them.

As such my only logical conclusion is that they are opposed against 
accountability and overall routing security.  This has been disclaimed, 
but I've yet to see a reasonable motivation as to why this policy is a 
bad thing for internet governance.

Andrew Alston also points out rough consensus, and frankly, until we see 
a proper objection to this policy based on operational issues that it 
will cause, I personally think discussions are done.  Nothing more to be 
said IMHO.

Kind regards,
Jaco

>
> Cheers,
> Rob
>
> [1] Google AI helpfully describes flowery language as "Flowery
> language—often called purple prose—is writing or speech that is overly
> ornate, intricate, and packed with decorative adjectives."
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd



More information about the RPD mailing list