Subject: [Gen-art] Gen art LC+TC review of: draft-ietf-tcpm-tcp-ao-crypto-02

From: Avshalom Houri <[email-masked]>
Date: Wed, 10 Mar 2010 00:20:06 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-tcp-ao-crypto-02
Reviewer: Avshalom Houri
Review Date: 2010-03-09
IETF LC date: 2010-03-10
IESG Telechat date: 2010-03-11

Summary: The draft is ready for a standard track RFC (see minor issues and 
nits).
The document is a reasonable basis on which to build the salient part of 
the
Internet infrastructure.

Major issues: None

Minor issues:

Line 211
   This is the initial specification of required cryptography for

Why it is initial? Initial RFC?

Lines 232-238
I do not see the requirements only MUSTs.

Line 260
   "MUST" to implement, in order to drive vendors toward its use, and to

Should the IETF include something as a must in order to drive its 
implementation?

Line 862:
   above.  We simply attempted to "put a fence around stupidity", in as

Maybe change the language for the RFC?

Nits/editorial comments:

Line 182
   verification between to end-points.  In order to accomplish this
->    verification between two end-points.  In order to accomplish this

Line 384
                   starts = 1.

-> starts at 1.

--Avshalom

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 24 Mar 2010 02:02:57 -0700

Avshalom,
Thanks for your review. The indicated changes inline below have been made in
-03, which will be issued shortly. See inline...

> Why it is initial? Initial RFC?

TCP-AO is brand new, and this is the first ever specification of required
cryptography for -AO. We assume, as time goes on, that others could follow.
No change to text.

> I do not see the requirements only MUSTs.

Not sure what you mean here. The "Requirement" is "MUST" as opposed to
SHOULD or MAY. No change.

> Should the IETF include something as a must in order to drive its

This decision/text was re-worked several times and reflects WG consensus. No
change.

> Maybe change the language for the RFC?

makes sense.  s/stupidity/foolishness/

> ->    verification between two end-points.  In order to accomplish this

done

> -> starts at 1.

because "i" is a counter, I think being precise with the "=" is appropriate.
No change.

Thanks again for the review,
Gregory.

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Avshalom Houri <[email-masked]>
Date: Sun, 28 Mar 2010 18:04:34 +0300

Gregory Lebovitz <[email-masked]> wrote on 24/03/2010 11:02:57 AM:

> Re: Gen art LC+TC review of: draft-ietf-tcpm-tcp-ao-crypto-02
> 
> Gregory Lebovitz 
> 
> to:
> 
> Avshalom Houri
> 
> 24/03/2010 11:03 AM
> 
> Cc:
> 
> General Area Review Team, ekr, Russ Housley, lars.eggert, tcpm
> 
> Avshalom,
> Thanks for your review. The indicated changes inline below have been
> made in -03, which will be issued shortly. See inline...

> Summary: The draft is ready for a standard track RFC (see minor 
> issues and nits). 
the 
> TCP-AO is brand new, and this is the first ever specification of 
> required cryptography for -AO. We assume, as time goes on, that 
> others could follow. No change to text.

Initial sounds as an initial version. Maybe say the first in a series or
similar?

> Not sure what you mean here. The "Requirement" is "MUST" as opposed 
> to SHOULD or MAY. No change.
>  

I meant that I see the word MUST but I do not see the requirement itself.
Is the algorithm or the key derivation function are the requirements?

> This decision/text was re-worked several times and reflects WG 
> consensus. No change.

I still think that the IESG should address this. Many times even WG
consensus is not accepted at the IESG level.

> makes sense.  s/stupidity/foolishness/

Why to use an offensive word?

> because "i" is a counter, I think being precise with the "=" is 
> appropriate. No change.
>