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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf