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

Hi James,

> sorry for the delay in my response, I did not intend to be so late

We are all busy with something, so don't worry, I didn't waste time
in waiting.

>> Haven't said that. But as-set with members and mbrs-by-ref are
>> defined. True, we see additional fields, but - beside source: -
>> none of them have a meaning in the context of as-set and it's
>> purpose. But exclude-member would introduce such. And this should
>> then IMHO also reflected in the RFC.

> Yes, and no. There are example of updates which affect the as-set class:
> - RFC7909 introduces the "signature" attribute for all existing objects.

And it's a RFC (but beside this, it doesn't alter much of how to read an
as-set).

> - RFC2725 Section 9.6 "Other Objects" introduces the use of "::" notation
> to indicate the source of an object.

[Probably badly translated: Sovereignty of interpretation] - I don't read
this to make e.g. SOURCE::ASN:AS-CUSTOMER a compliant as-set name (which
goes back to the previous discussions for AS-SET naming). But if, I would
be more than happy (as that suggestion you made once, was something I'd
love to see happening).

> But there are various instances of non-standardised attributes being added
> to IRR-DBs, including the RIPE DB:

> -Various RIPE documents [1], [2], [3], make use of the attribute "assignment-
> size" but, it isn't defined in any RFC.

And the use outside RIPE is <?>. Compared to assignment-size, you for sure
want to have exclude-members accepted/implemented/... by other IRRs. Just
"starting in the RIPE island" and hoping others follow is IMHO too optimistic.

> [...]
> - Only hierarchical AS-SETs can be created in the RIPE DB now, this is not
> RFC2280 Section 5.4 complaint.

RIPE DB supports legacy non-hierarchical as-sets. But in any way, this
restriction does not introduce something "new". It's a restriction of what
you can enter.

> RFC9092 Section 3 "inetnum: Class":
> [...]

The interesting part follow past the quoted:

<<Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in
the inetnum: class. Until such time, this document defines the syntax of a
Geofeed remarks: attribute
[...]
While we leave global agreement of RPSL modification to the relevant parties,
we specify that a proper geofeed: attribute in the inetnum: class MUST be 
"geofeed:" and MUST be followed by a single URL that will vary, but it MUST
refer only to a single geofeed [RFC8805] file.
    inetnum: 192.0.2.0/24 # example
    geofeed: https://example.com/geofeed.csv
>> 

> I assume the authors of RFC9092 for example, chose their approach of
> repurposing the remarks attribute (which is suboptimal when compared to
> adding a new attribute), because presumably they didn't want to face the
> pain of adding a new attribute?

I don't know, maybe one of them can comment, but to be honest, it reads more
like a nice "workaround" to avoid touching RPSL itself, but defining *in a
RFC* a new attribute ... by describing the repurposed attribute and defining
at the same time, how such attribute MUST be named if ever officially defined
in RPSL - that's a definition itself. [Just thinking loud: a template for
future added attributes without touching RPSL?]


> I also see plenty of evidence (which I listed above) that plenty of changes
> are made without engaging the IETF.

I see them targeting something different or taking another approach. Maybe
others - beside you - see this differently. 

If you consider exclude-members that valuable and just start with RIPE and 
without thinking the next steps, it might become an island solution. Just
the naming could become an endless discussion, e.g. if RIPE starts using 
exclude-members: and later others insist on using members-exclude:. 

>> Your proposal is IMHO a workaround. Not totally wrong, but the approach
>> "just do it" is wrong. Like introducing a new BGP code for something "very
>> useful", but never getting it officially somewhere documented.
> I never said "just do it". You skipped the conversation forward to implemen-
> tation but, I started by asking how useful might this feature be, and asked
> for feedback on the feature/idea itself first.

Quoting your opening:
>>> I am thinking about the usefulness of adding a new field to the RIPE database
which is an AS-SET "exclude-member" field, to compliment the "member" field.

First part fine with me (discuss the usefulness of such attribute, the pro
and cons and alternatives), second part is for me the "just do it" part.
I miss the "how to get the broader community now/later following" step before
seeing it in RIPE DB.


But I hate where we now end, turning words arounds and drifting away from
discussing your idea and proposal, if this is of use for the RIPE and -as
IMHO otherwise it doesn't make much sense- a wider community, what are 
obstacles (or just /me seeing problems, which don't exist) and potential
alternatives. 


> But, currently we don't have any way to tackle this problem. I am
> proposing something because, something is better than nothing.

Sometimes something could be better than nothing, sometimes nothing could
be better than something. But this we really don't need to discuss.

> Are you suggesting we stick with nothing? I think, if we have a problem,
> we should try to do something about it. Or, do you have a better idea of
> how to tackle this problem?

No - sticking to nothing. There's a problem - but that doesn't imply /me
accepting the first proposal nor forces me to supply an alternative solution.
If that's the rule of discussing an idea these days ... uh, back again where
I don't want this to end, sorry.


Split discussion. 

Parts of my comments are about the usefulness - as I see it with my current
understanding.

I understand what you want to achieve (and "bad" networks is one example,
expressing commercial implied exclusions [as you wrote in another - not
quoted here paragraph] could be another - as Nick wrote much clearer: a
set exclusion operator).

If you want to achieve it today, explode your members, list all the ASNs
-except the ones you don't want to have listed- as members and publish
this as to-be-used as-set for you. A few script lines should be enough
to make this work (and a few more with proper error handling ;-). [Not
sure, if not some tools choke on way-too-many-direct-ASN-members listed,
but also this could be solved with some "own-managed" sub-as-sets to list
ASNs.]

Ugly, true, an exclude operator is much more charming. 

If of use? I see it for some, for others quite unlikely. If the ones -having
a use case for it- are enough to justify this to become real, I can't say.


The other part is about the "how to achieve/implement this". And there I have 
my strong doubts which I brought up. And I still stick to these concerns.
But if you/we/whoever gets this "properly" defined, then it's another story.
[If the geofeed "way" would work? Not sure, as exclude-members would link back
to the semantics of members: - while the geofeed: is "additional information".]


If others think this is useful AND the suggested approach is reasonable for
the majority - well, who would I be to stop it? 

By now, with that "many" other comments and input, it's you asking for it
and me coming back with some concerns (and Nick putting it in some nicer,
clearer words). If that's all, well, I think we should save the time for
something else.


Markus