Subject: RE: text suggested by ADs

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 28 Apr 2005 18:43:08 -0700

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Apr 2005 01:26:18 -0400

> 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.