[Gen-art] Partial review of draft-ietf-v6ops-security-overview-04.txt

"Sharon Chisholm" <schishol@nortel.com> Thu, 25 May 2006 14:55 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHF7-0003UT-Qg; Thu, 25 May 2006 10:55:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHF6-0003UO-E7 for gen-art@ietf.org; Thu, 25 May 2006 10:55:16 -0400
Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHF5-0008S1-3a for gen-art@ietf.org; Thu, 25 May 2006 10:55:16 -0400
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4PEt8S20040; Thu, 25 May 2006 10:55:08 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 May 2006 10:54:44 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B408AADFBD@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Partial review of draft-ietf-v6ops-security-overview-04.txt
Thread-Index: AcaACyiWjGUrL1Q8RwWUPsWWuAATiQ==
From: Sharon Chisholm <schishol@nortel.com>
To: gen-art@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: david.kessens@nokia.com, fred.baker@cisco.com, suresh.krishnan@ericsson.com, kurtis@kurtis.pp.se, psavola@funet.fi
Subject: [Gen-art] Partial review of draft-ietf-v6ops-security-overview-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Attached is my review of the specified document, submitted as part of
the Gen-ART process.  For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Document:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-0
4.txt

Summary: This draft is basically ready for publication, but has nits
that
	should be fixed before publication.

Comments:

I somehow wasn't paying attention and only realized at the last minute
that I was assigned this review for today's meeting. Apologies for the
lateness and incompleteness of this review. I only managed to review to
the end of section 2.3.

1. In section 1, second paragraph, it says "It is important to
understand that we have to be concerned not about replacing IPv4 with
IPv6", which seems a bit bold of a statement without a clarification
like "in the near future" or some form of explanation.

2. In section 2.1.1, second paragraph and after the bullets, there is a
typo - "point wher it is being "

3. The document contains a number of references to internet drafts that
originally defined the problems discussed. The document claims "Several
of these issues have been discussed in separate drafts but are
summarized here to avoid normative references that may not become RFCs",
but it isn't clear what the RFC editor should do. Should it delete all
these references or just delete the ones that are not RFCs at the time
of publication, or should it evaluate which it thinks will someday
become RFCs and then wait for them?

4. Section 2.1.9. 1 does not make a recommendation. Are we suggesting
that middleware boxes should inspect these packets or just letting
people know about the conflict. A recommendation of some sort would seem
more satisfying.

5. In section 2.1.9.2, third paragraph says that "This either limits the
security that can be applied in firewalls or makes it difficult to
deploy new extension header types", but I did not find information in
this section to support that conclusion. It may well be true, but it
isn't supported. Why is it difficult to skip over header extensions I
don't recognize, for example?

6. In section 2.3.2, second paragraph, second bullet, isn't it mandatory
to implement ipsec in IPv6 but it isn't mandatory to deploy it is it?
I'm not sure this distinction is clear in this bullet. (Assuming my
understanding is correct that is) 

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art