review of draft-ietf-kitten-rfc2853bis-02

I promised to do this (from a Java-programming) perspective at the last
IETF so here goes:

My overall problem with the draft is that it seems to be directed at
both future users of the
API and implementors. For instance it is hardly necessary to explain
that Java has built-in
memory management to an implementor. This split focus makes the document
longer and
harder to follow.

I have decided to ignore any comments I might have made if this API had
not been already
widely deployed.

Apart from a general feeling that IETF api documents are much more
complicated than
they should be: I'm wanting a self-extracting perl-script which
generates the API code and
javadoc really :-)

A couple of specific comments (which in some cases examplify general
problems in the text)

5.1 Package Name

Generally its not considered a good idea to import the entire package
but java programmers
know what to do with packages. Strike the second sentence for brevity.

5.7 Object Identifier Sets

The last sentence of the second paragraph is value-laden and
unnecessary: Use of words like
complicated should (imho) be used very carefully in technical
specifications.

5.13 page 26, 2:nd paragraph:

This seems to violate the (very sensible) principle of never changing
user input data, i.e if
the user says 'foo' to a routine and then asks for something which she
can reasonably expect
to be the same value back it should be 'foo', not 'dc=foo' or 'ou=Foo,c=SE'.

5.14 page 28, last paragraph

This text about channel bindings seems dated. I really think this text
needs attention from Nico
before it goes out.

6.2 last paragraph

The expression "safe for sharing" (occurs elsewhere) is imprecise. If 
thread-safety  is what
is intended this needs to be stated.

         Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten