If the process of administering SRV needs to be fixed then the people who see the problem should be responsible for suggesting fixes to it.
The relevant question here is whether _your proposal_ depends on some facet of SRV or its administration that isn't working properly at present. If it does, that's a valid reason to delay your proposal until SRV is fixed. If not, then I would say that it's probably not a valid reason. But whether your proposal depends on SRV is a technical judgment that the IESG is empowered to make. If you disagree, that's what appeals are for. Nothing you could reasonably change about the process is likely to change the fact that _somebody_ has to make such judgments and whoever makes them can sometimes be wrong.
I keep getting the impression that you are trying to make a personal gripe into a failure of the entire IETF process, and I just don't see it. But if you really do feel it is a process violation, you can appeal on that basis also.
Keith
p.s. I agree that design rationale rarely belong in normative specifications. we tend to put design rationale in I-Ds in order to convince WGs and IESG to approve them, and often fail to include a note to the RFC Editor that says "leave this out of the final publication" or to otherwise clearly separate normative text from background material.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf