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@xxxxxxxxxx] > Sent: Thursday, April 28, 2005 7:49 PM > To: Hallam-Baker, Phillip > Cc: Joe Touch; John C Klensin; ietf@xxxxxxxx; > john.loughney@xxxxxxxxxxx > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf