Alfred, Thx for your review. The changes indicated inline below are being made in -03, which will be published shortly.
On Wed, Feb 24, 2010 at 3:15 PM, Alfred HÎnes <[email protected]> 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: [email protected] | > +------------------------+--------------------------------------------+ > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
