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. As
far as I am concerned the output from the IESG in such a situation
should be to send a message to the DNSEXT WG to fix the percieved
problem. I do not see why it helps matters for the PKIX group to do so.
In fact the particular 'issues' raised were from a reviewer who
essentially demonstrated a complete lack of understanding of what the
SRV and NAPTR schemes do and what the proposal being made was. If I
propose to use IETF specification X and the approach works then the IESG
should respect that decision and not start redesigning the protocol and
second guessing the design decisions.
I do NOT put design rationale in normative specifications. It is
generally considered to be an error in a specification to include that
type of material because it leads to ambiguity (c.f. interpretive issues
concerning the 2nd amendment resulting from the rationale "A well
regulated militia...").
If someone does want to second guess my design decisions then they
should make the effort to actually contact me and discuss them with me,
in this particular case no effort was made to do so.
My other complaint about the IESG process is that despite the existence
of an issues tracker there does not seem to be any facility for telling
the authors of the IDs about the status of their documents. I only
became aware that there were two IESG DISCUSS holds on my draft many
months after the objections were made. It is possible that the mails
bounced but I doubt it. Why doesn't every message from the ID editor
tell the authors of the status of their document in the issue tracker?
My bigger objection here is to the way that the IESG treated the draft.
It was submitted in July of 2003, the first time it was discussed was
February of 2004. The discussion resulted in a number of editing nits
which might well have been reasonable to raise if they had been pointed
out in August of 2003 but not six months later. The format of the
references should not be a reason to hold up a draft seven months after
it is submitted.
It was March 2004, almost 8 months after the draft was submitted before
any substantive comments were made. By that time the draft is almost
completely forgotten and I have to re-read the document to remember what
any of the arguments were. It is also way down my list of priorities
which are now focused on stopping Internet crime.
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Thursday, April 28, 2005 7:49 PM
To: Hallam-Baker, Phillip
Cc: Joe Touch; John C Klensin; ietf(_at_)ietf(_dot_)org;
john(_dot_)loughney(_at_)kolumbus(_dot_)fi
Subject: Re: text suggested by ADs
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