[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Photuris Security



Bill,
	I've got some general comments on the Photuris draft and a number
of specific suggestion for wording changes.  Where the wording changes are
to clarify and do not involve any question of meaning I will send them to
you directly.  I'll make the more general comments here.

	As you and I  have talked about a number of times, I am a fan of
description, reason and context.  The IETF documents that are most often
cited to me as a "good" standards are the host requirements documents.  In
particular, the inclusion of a section of discussion about specific topics
is seen to be very helpful in understanding not only why something was
suggested but also why something else was not.  Many of the reasons that
particular paths were chosen have been made clear on the mailing lists but
that information will not be generally available to someone reading the
final standard a few years from now.  (Note, I think the Implementation
notes are a *very* good thing to have.)

	In addition I think that a paragraph of overview can be very
helpful in setting the context in which the details of a protocol are
defined.

	I would like to have IETF standards be easily readable and
understandable by a range of people, from students to implementers. 
 
	With the above in mind, I'd like to make a number of specific
suggestions.

move sections 1.2 and 1.3 later into the document, they are quite confusing
to encounter before understanding just what the protocol is.

add an introductory part to section 2 describing, in prose, what the
protocol is providing to the user and the process it uses to do so.

in section 2.2 - include the reason that the cookies are 16 octets long
(rather than some other length)

sec 2.3 - paragraph 2 - I'm confused by "such as moduli"

sec 3.1, 3.2, 4.1 4.2, 5, 6.1, and 6.5 - add a paragraph at the start
saying what each procedure or message is for

(a general comment, I think it is better to say for reserved fields
"unused, MUST be set to zero when transmitted and MUST be ignored when
received" )

(oops - I've gone past the chapt 5 boundary, more later)

Thanks

Scott