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