[routing-wg] Adding an "exclude-member" field

Hi Markus;

> Or in this particular case: Adding members-exclude to as-set without
> defining it somewhere "officially" (syntax and semantic) BEFORE, seems
> to me NOT the right way. (Esp., as the target is to get this into the
> complete IRR "eco system" and not just into RIPE.)

As I have said multiple times, getting this standardised isn't the sticking point for me. This is:

> - As I said in my email to Markus, if we pretend I got a new draft into GROW and eventually published, "then what?". How does one get that implemented in the RIR DBs (RIPE to start with)?

I think, that you think, I'm against documenting and standardising this. I am not. The big questions for me is, what happens after going to the IETF?

It's a waste of time getting an RFC published if all I can do is print it off and make paper aeroplanes with it. So the question is, what comes after that? Just because there is an RFC, would RIPE implement? What is required for them to implement it? Do they need any additional documentation or testing? Does the RIPE RIPE DB docs website need updating too? Would I have to request that?

There is no point talking about getting this standardised, if RIPE wouldn't implement it, and I can't find any information on what is required in order for RIPE to implement this.

Kind regards,
James Bensley (he/him)
Inter.link GmbH

Boxhagener Str. 80, 10245 Berlin, Germany
Email: hello at inter.link,
Phone (general): (+49) 030577123821
Phone (mobile): (+49) 015792522412
Registry: Local court Charlottenburg, HRB 138876
Managing directors: Marc Korthaus, Theo Voss

________________________________________
From: Netmaster (exAS286) <netmaster at as286.net>
Sent: 14 November 2023 10:45
To: James Bensley; Nick Hilliard; routing-wg at ripe.net
Subject: RE: [routing-wg] Adding an "exclude-member" field

JB wrote on Tuesday, November 14, 2023 9:22 AM CET:
> See my discussion with Markus. TL;DR:

Does that help?

> It reads to me a bit like Markus' response, that (paraphrasing) we
> shouldn't be trying to improve something that isn't working as well
> as it could, and just implement hacks to work around it.

Did I?

My point - and I'll stick with it until I'm taught better:

Improvements (often) do not justify breaking existing rules.

Or in this particular case: Adding members-exclude to as-set without
defining it somewhere "officially" (syntax and semantic) BEFORE, seems
to me NOT the right way. (Esp., as the target is to get this into the
complete IRR "eco system" and not just into RIPE.)

Markus