Consider being more strict in a note regarding trust chain loops

[cicnavi]

In 10.1. Fetching Entity Statements to Establish a Trust Chain, there is a note regarding trust chain loops:

Note: Federation participants SHOULD NOT attempt to fetch Entity Statements they already have obtained during this process to prevent loops.

Explanation of SHOULD NOT from RFC2119:

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

Those implementing trust chain resolution don't really have a choice regarding allowing loops. If they do allow it, they risk ending up with timeouts / resource depletion / process, system crashing... Detecting loops seems as a "must" from that perspective.

The note could also be more specific in a sense that a loop can be detected for particular chain path, and also that it can be (easily) detected during the (initial) fetch of configuration statements, instead of regarding it like "...during this process...". If you try to fetch the same configuration on the same chain path, there is a loop.

Just for context, a made-up scenario with cross-trust between IM1 and IM2 which brings a path with a loop, but also potential valid paths:

 LE ─► IM1 ─► TA1 
        ▲         
        │         
        ▼         
       IM2 ─► TA2 

Paths:

• LE -> IM1 -> TA1 (OK)
• LE -> IM1 -> IM2 -> IM1 (loop, must discard this path)
• LE -> IM1 -> IM2 -> TA2 (OK)

Maybe include "SHOULD NOT" like note regarding loops for "federation architects" in the 16. Implementation Considerations, but for those implementing trust chain resolution, regard loop detection on particular chain path as a must.

[selfissued]

This seems like it belons in the Federation Topologies discussion.