Thx for your review. The changes indicated inline below are being made in -03, which will be published shortly.
--
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks
On Wed, Feb 24, 2010 at 3:15 PM, Alfred HÎnes <ah@xxxxxxxxx> wrote:
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.
s/It then specifies/It specifies/
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 )
this one was used
or
(i || Label || Context || Output_Length)
Also, "Context :" recurs in the draft, while other items are written
with no white space before the colon.
removed the spaces
(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.
Understood. There were fairly long debates about this in the WG, and the current formulation reflects WG's conclusion. You may well be right about future collisions, which we can address by making the future label more precise, e.g. "AES128-GMAC" in your example.
(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.
deleting them both in -03.
(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
found 2 instances, and deleted.
* in 3.1.1: s/mutiple/multiple/
done
* please fix hyphenation (if used as an attribute, e.g.
"128-bit key", 16-byte jey" etc.)
Did not find anything matching what I thought you meant. No change.
* Section 3.1.1.3 should betted be numbered 3.1.2;
it does not introduce a 3rd "Concrete KDF".
Subjective. 3.1.1 is about KDFs, and 3.1.1.3 is about the UI for these KDFs. No change.
* Section 3.2, last line: there's no "TCP-AO header";
please use "TCP header" (or maybe "TCP-AO option").
s/TCP-AO header/TCP-AO option field/
* Section 3.2.1: s/that has function/that hash function/ .
done
^ ^^
* Section 6, 2nd para:
"cryptographic-based systems" ?? -- I suggest to use
"cryptography-based systems" or better
done
"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.
done
Thanks a ton for the thorough reading and suggestions, Alfred.
Gregory
Kind regards,
Alfred HÎnes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx |
+------------------------+--------------------------------------------+
--
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf