Document: draft-ietf-pkix-pkixrep-02.txt
Reviewer: Michael Patton
Date: March 18, 2004

Summary: This draft has serious issues, described in the review, and
	needs to be rethought.

which, it seems to me might be a bit of a strong way to say it about
an Experimental RFC, but that's what I feel about this design.


This document has a somewhat twisted interpretation of how SRV records
were intended to be used (e.g. elevating HTTP to a protocol at the
same level as TCP), but as an Experimental it might be alright to
stretch that.  However, by using SRV records in this way, they are
probably adding constraints both on use by applications and on
possible deployment in the DNS, which are the kind of things the
Experiment would show.  Personally, I would have thought that NAPTR
would have been better suited to the problem area addressed by this
document.

One of the things they are trying to do is allow selection between
several protocols.  However, their one and only example is in an
environment where only one protocol is available.  I don't see how
this proposal using SRV, which was designed for finding a SeRVer host
for a given protocol, actually helps selecting between multiple
protocols, which is what they describe as a goal.

On the other hand, NAPTR was designed for selecting between multiple
protocols that could resolve the same data, which is exactly their
problem domain as I understand it from the description.  For these
reasons I believe the basic design is flawed.

However, if they were going ahead with this design, the document
needs more examples showing how it works in environments where both
ends have multiple, but not identical, protocols available.  It would
also need some discussion of why they were perverting SRV in this way,
and I'd like to see something about why NAPTR is not suitable.
_______________________________________________
Gen-ART mailing list
Gen-ART@alvestrand.no
http://eikenes.alvestrand.no/mailman/listinfo/gen-art