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