Document: draft-ietf-pkix-certstore-http-08.txt
From: Michael A. Patton
Date: 27 september 2004 

Summary: This draft is basically ready for publication, but has
concerns that should be considered before publication.

As a general comment, although reading the document made my head hurt,
I believe that was just because of all the intricate connections to
other security stuff that I'm just not that familiar with.  Other than
that it seemed reasonably well written and clear, except for one
concern with an over long section (see next paragraph).  I especially
liked the section on being "technology neutral" and suggesting an
implementation using "trained chimpanzees" and "books" :-).



My only real concern is that Section 2.5 seems a bit long.  This
creates some minor readability problems.  If any non-trivial work is
done on the document, I'd suggest breaking it up a bit.  In fact, I
think 2.5 should probably be promoted to a top level section
(i.e. Section 3, bumping the number on following sections) with
subdivisions, however that would require promoting Section 2.6 as
well.  I also note that Section 2.5 duplicates parts of the Security
Considerations but with different words.  I'd suggest that a reworked
Section 2.5 could describe it better and that the Security
Considerations section could just mention it and refer back to the
appropriate subsection, thus making the document more concise.  On the
other hand, the parts of Section 2.5 that duplicate the Security
Considerations could be removed and a simple "additional
considerations are given in the Security Considerations section"
reference used instead.  This might make 2.5 acceptable without the
other changes.  Additionally, it seems there are some items in Section
2.5 that should be included in the Security Considerations, but aren't
(specifically the paragraph starting "Pre-constructed URIs ..." but
maybe others)


The last sentence of the second paragraph of Section 3.5 makes some
unsupported assertions about the difficulty of using CNAME RRs and
their not working across domains.  I don't believe either of those
assertions and think that sentence is at best misleading and
potentially damaging as it may lead readers down the wrong path.



Minor comments:
---------------

At the beginning of Section 2.1 I'd suggest expanding "column in the
tables" to "column in the tables below"

I'd like to suggest that you see if Keith concurs with their
assertions about RFC3205 concerns.

The description (in Section 3.2) of use of DNS SRV RRs should probably
mention the priority and weight fields and their application.  I
assume they intend the default usage from RFC2782, but I think for
completeness that should be explicitly said.

I am somewhat disconcerted by the paragraph at the start of Section
3.5 that states that a certain amount of the complication of this spec
is due to an attempt to be compatible with limitations of aome
implementations of a single vendor, while in Section 2.5 there is a
description of specific non-compatibility with a number of
implementations.  I lament the days when the IETF really was vendor
neutral.


Simple typos:
-------------

Section 2. "an error conditions" => "an error condition"

In the table in Section 2.2, the third column for "name" needs to be
indented one more space.

Several locations: "sanitisation" => "sanitization"

Section 2.5 "provide a slight a performance" =>
	    "provide a slight performance"

Section 3.5 "the mechanism describe here" =>
	    "the mechanism described here"