I don't see anything wrong with that. It's the ADs' job to push back on documents with technical flaws. They're supposed to use their judgments as technical experts, not just be conduits of information supplied by others.
My proposal for an SRV prefix to be defined for LDAP PKIX repositories is currently held up because of a series of issues that all have to do with the administration of issuing SRV prefixes and the SRV mechanism itself.
Phill,
I haven't read your proposal or IESGs feedback on your proposal so this isn't a comment on either of those. But if your proposal uses technology X in such a way that it raises or uncovers technical issues about X, I don't see anything wrong (from a process point-of-view) with the IESG examining and attempting to resolve those issues before it lets your document go forward. If X is flawed (or the process of administering X is flawed), and your proposal depends on X, then in some sense that is a flaw in your proposal. This is true regardless of whether X is SRV, RSA, TCP, or whatever. Of course if a flaw were found in X it would make sense to reexamine the status of other protocols using X, but those are separate issues from whether _your_ document should move forward.
It might be a poor decision on IESG's part, but that's what appeals are for. Judgment errors are not the same as process flaws, nor are they necessarily evidence of process flaws.
Keith
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf