I have a strong feeling that on a RFC witch includes technical issues to solve, this technical descriptions that describes step by step what is going to be executed by the analyst should not be included (or may not).

Thats because I think that not everybody that approves an RFC have the aknowledgment of this steps. The most important information for them is the impact and the priority.
For me, this informations should be included on a internal documentation, or somewhere else.

RFC means request for (a) change. Asking for a change does not imply any technical knowledge as to whether the change is even feasible. It merely requires a description of the change, its purpose or objective expressed as a benefit and an indication of whenabouts the requestor would like it to happen. more information would also be valuable (for example, who would be impacted by the change and whose authority it would be under), but the change management procedure can be designed to elicit that if necessary

How you manage the acquisition of all the technical and planning details is up to you and will vary from place to place for various obvious reasons. It would seem a risk to go into too much technical detail before ensuring that the requested change was, in general feasible and acceptable, but obviously, the more preparation done before the first meeting on the change, the better able the meeting is to plan the change.

That said, some organizations tend to use the term RFC to mean the dynamic document that accompanies the change through various parts of the overall process. In this case then obviously at some point all the technical details will be incorporated._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718