Strictly speaking, if you have a rigorous quality process in place, there should be no reason for a discussion of rework. In fact, it might be said that rework is the result of not having rigorous enough quality processes in place to begin with.
But, let's be practical as well. No project can afford to spend the time and effort that would be required to guarantee that every deliverable is perfect the first time. Even a company operating at a "Six Sigma" level has some small probability of error.
Rework is not the same as your normal process of gathering feedback on deliverables. If you create a document, for instance, and you circulate it to gather feedback, the resulting changes are not considered rework. These changes to the document are your way of making sure that you have a good document to begin with. However, if you publish your completed document and then find errors in the content, the resulting updates would be considered rework. Likewise, let's say you are developing a software module. If you test the module and declare that is complete, the assumption is that it is, in fact, complete and final. However, if further testing reveals flaws that need to be addressed, this additional effort is considered rework.
Although you may accept some rework as inevitable based on the nature of the project, it does not mean the project manager and project team should not strive to eliminate it. You and your team should always strive to eliminate defects and rework by continually improving your processes.
If there is to be rework, focus on finding it as early in the lifecycle as possible. Remember that errors in the analysis will propagate into errors in design and errors in construction. If you don't find the errors until the testing phase, there might be rework required throughout the lifecycle, including the prior analysis, design and construct phases. On the other hand, there is less of a chance of propagating requirements errors downstream if you have a rigorous process to validate that your deliverables are complete and correct before moving to subsequent project phases.
You can track rework to determine how much of your project time is spent "thrashing" or working on the same problems twice. For instance, in the testing process you can track the number of errors and the effort associated with resolving the errors. Much of this problem resolution will require rework of previously "completed" deliverables. When these errors are corrected, you may find that the change does not work adequately, which will cause more rework. You may find that fixing one problem may break something else. This second, unintended error will cause even more rework. You can track the total number of errors that require rework, as well as the effort hours associated with the rework.
The nature of rework is that it is caused by problems in your quality management process. Rework is needed to bring a deliverable up to the level of quality it should have been at to begin with. One of the responsibilities of a project manager is to put into place a quality management process that seeks to keep rework to a minimum.