Split `SkipReason` cases

[SichangHe]

SkipReason cases sorted

Operators' fault because they did not put stuff in IRR (Right, @cunha?):

• FilterSetUnrecorded
• AsRoutesUnrecorded
• RouteSetUnrecorded
• AsSetUnrecorded
• AsSetRouteUnrecorded
• AsSetRouteSomeUnrecorded
• PeeringSetUnrecorded
• AutNumUnrecorded

Invalid RPSL met:

• UnknownFilter

Our limitations:

• AsRegexWithTilde
• AsRegexPathWithSet
• CommunityCheckUnimplemented

Operators' fault because they did not write any rules (maybe I should move these to SpecialCase):

• ImportEmpty
• ExportEmpty

There was another skip:

• SkippedNotFilterResult
• SkippedExceptPeeringResult

What do we do

• We might as well move most of these to SpecialCase and only leave our limitations.
• [ ] UnknownFilter should be considered an RpslError.
• The skip messages to indicate there are other skips have been useless, so maybe we remove them.

@cunha, what do you think about these?

[cunha]

The breakdown looks good to me. Don't we just Skip/Ignore the ASes with no import/export?

I am not sure I get the last bullets:

We might as well move most of these to SpecialCase and only leave our limitations.

Maybe we could have three classes? The special cases are valid RPSL with valid data, but in a pattern that isn't exactly accurate; it's somewhat different from the unrecorded and limitations.

UnknownFilter should be considered an RpslError.

+1

The skip messages to indicate there are other skips have been useless, so maybe we remove them.

Not sure I understand this. We can discuss in the next call.

[SichangHe]

Don't we just Skip/Ignore the ASes with no import/export?

Okay, keeping them, then.

Maybe we could have three classes? The special cases are valid RPSL with valid data, but in a pattern that isn't exactly accurate; it's somewhat different from the unrecorded and limitations.

So how would the report cases be like?

The skip messages to indicate there are other skips have been useless…

Not sure I understand this.

They are generated e.g. when a NOT is met and the thing under the NOT is skipped.

[cunha]

So how would the report cases be like?

I think there are two things: The label we attach to an export/import between a specific pair of ASes in an AS-path. These can be Ok, Bad, Skip, and Special. Maybe we could aplit Skip into Unrecorded and Limitation.

Then there are the reports for a whole path. For the whole path, I think we could have matching classes, and take the min across all AS-pair import/exports, sorting them (from good to bad) in this order: Ok, Skip, Special, Unrecorded, Bad.

[cunha]

They are generated e.g. when a NOT is met and the thing under the NOT is skipped.

Sorry, still not sure I understand. Maybe an example would help? 🤔

[SichangHe]

I just realized that we can get rid of SkipReason, SpecialCase, etc. entirely in report.rs and flatten all cases under the ReportItem enum.

The other benefit would be to make the report 1 word smaller (5 → 4).