Subject: RE: text suggested by ADs

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

> Behalf Of Keith Moore
> Sent: Thursday, April 28, 2005 6:29 PM

> 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. In order to answer these objections I will have to spend quite a
lot of time to compile a reply which has absolutely nothing to do with
the technology and to the extend that there is a technology issue the
question concerns the working of the SRV mechanism rather than the
proposal.

I don't think that I should have to fix SRV in order to get a prefix
assignment. I don't think I should have to suggest administravia either.
There should be a uniform policy here and it should have come from
DNSEXT not PKIX.

In every other forum I simply make up the SRV prefixes myself and stick
them in the draft. The chance of accidental collision is insignificant.
There are far more Windows applications than Internet communication
protocols yet people seem to be able to cope with a 3 letter filetype
extension astonishingly well.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Apr 2005 19:49:02 -0400

> 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