Re: Last Call: draft-ietf-tcpm-tcp-ao-crypto ... -- editorials

[Alfred Hönes <[e-mail]>]

It looks like draft-ietf-tcpm-tcp-ao-crypto-02 is not yet ready for
publication.


Here is a collection of some editorials (found on a quick pass
over the draft) that should be fixed:

(1)  Section 1, last para

The text there does not reflect the order of presentation in the
remainder of the document.  In particular, "It then specifies ..."
is confusing.  Please consider rearranging that text to reflect
the document content and not confuse the reader.

OTOH, it might make sense to indeed first present the general
requirements and then the specific requirements (i.e. swap
Sections 2.2 and 2.3 and leave that paragraph unchaged).

(2) Section 3.1.1 ff. (recurring)

The input representation repeatedly uses unbalanced spacing:

           ( i || Label || Context || Output_Length)
           ^^                                      ^

Please use a balanced form, either

           ( i || Label || Context || Output_Length )
or
            (i || Label || Context || Output_Length)

Also, "Context :" recurs in the draft, while other items are written
with no white space before the colon.

(3) Sections 3.1.1.3 (see below, as well!) and 7:

I seriously doubt that the very short names given to IANA and
as a SHOULD for UIs are useful.

In particular not using "HMAC", only the shorthand "SHA1", will
likely raise again these concerns against SHA-1 that do not
properly distinguish between the cyptographical strenght/weekness
of plain SHA-1 and the HMAC construct employing SHA-1.

The name "AES128" also seems to be confusing; future algorithms
for TCP-AO might also be based on AES-128 -- e.g. AES in GMAC mode.
Thus, a bit more precision would certainly help to avoid confusion.

(4) Sections 4 and 5

Usually, such sections are supplied as appendices, so that
the numbered sections do no need renumbering upon cleanup.

OTOH, it's not clear why Section 5 (and the final editorial remark
in section 2.3) are still present at all in a document forwarded
to the IESG and subject to IETF LC.

(5)  idnits results

I once assumed that documents forwarded to the IESG had to pass the
idnits checks beforehand -- besides actual "false alarms".
Please clean up the references and address all the other general
items and details that idnits reports (too much to reproduce here).

(6) Further nits:

*   clean up non-paired spurious square brackets

*   in 3.1.1:  s/mutiple/multiple/

*   please fix hyphenation (if used as an attribute, e.g.
    "128-bit key", 16-byte jey" etc.)

*  Section 3.1.1.3 should betted be numbered 3.1.2;
   it does not introduce a 3rd "Concrete KDF".

*  Section 3.2, last line:  there's no "TCP-AO header";
   please use "TCP header" (or maybe "TCP-AO option").

*  Section 3.2.1:  s/that has function/that hash function/ .
                            ^                 ^^

*  Section 6, 2nd para:
   "cryptographic-based systems" ?? -- I suggest to use
   "cryptography-based systems" or better
   "systems based on cryptography".

*  Section 6, last para:
   There are no algorithms with a requirement level of
         or "SHOULD implement"
   These three words should be deleted.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+