A retrospective should not ban topics. And a retrospective must not waste people's time, either.
With that said, what you could do is categorise the retrospective items according to different influence categories:
Items the team can change
Items the team can influence
Everything else / Items the team needs to accept
Once you have done that, the team ...
The Scrum team alone cannot solve every impediment. It is a good idea to have some kind of escalation path for issues that are outside of the control of the team, but are recurring and damaging.
As a Scrum Master I would often look to escalate this kind of issue using a reporting process.
For example, I might produce a sprint report that says something ...
Is this a standard or good practice in facilitating a retro to 'censor' known issues like this?
Yes and no. I feel it's wrong to censor anything, especially talking about impediments at a retrospective. On the other hand, discussing the whole issue again and again and again when nothing has changed is unproductive and wasteful.
As an example: in my old ...
If the same impediment is being raised Sprint after Sprint, that brings up a few questions.
Is someone actively working on resolving the impediment? Maybe it can't be resolved within the Scrum Team and maybe it can't be resolved in a Sprint, but what is being done to minimize its impact and ultimately resolve the underlying issues?
During Sprint Planning, ...
Censoring an impediment from the retrospective doesn't solve it. As it looks to be a major impediment that's blocking the team, maybe it's worthwhile to arrange a separate meeting to analyze the problem to get a shared understanding and find a way out of the impediment?
The advantages of planning a specific meeting are:
You can focus on the impediment and ...