[secdir] draft-ietf-savi-framework-05 SECDIR review

Donald Eastlake <d3e3e3@gmail.com> Thu, 03 November 2011 03:06 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303B81F0C36; Wed, 2 Nov 2011 20:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.157
X-Spam-Level:
X-Spam-Status: No, score=-104.157 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjfn6erB+qiV; Wed, 2 Nov 2011 20:06:44 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA491F0C38; Wed, 2 Nov 2011 20:06:43 -0700 (PDT)
Received: by faas12 with SMTP id s12so1293372faa.31 for <multiple recipients>; Wed, 02 Nov 2011 20:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=p8rhI36eenW0VlV4Ds22ZvDh3NKqGU0u2JR/a6DGgQM=; b=ko0BirtQVPbvSjtQHf9fuCgLOHfCuLTWyWUPYANVHWbFenjHo8iEPl9dvYAWjV4TMv sNchO4G8GTULapfq+1gd6XLj3Chz/Ocp3OAZYFpmC2HIvh5DcAz4SloSNkL045aymweU qZcarMFWXH/Fn73is3rdf266ip9pNZ9mM8C2Y=
Received: by 10.223.75.150 with SMTP id y22mr12913902faj.29.1320289603268; Wed, 02 Nov 2011 20:06:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.43.4 with HTTP; Wed, 2 Nov 2011 20:06:19 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 02 Nov 2011 23:06:19 -0400
Message-ID: <CAF4+nEEMHsm-EHMNAvoMN-qhnRimGefa=bSjBYLAO+QfJPJDJg@mail.gmail.com>
To: draft-ietf-savi-framework.all@tools.ietf.org, IETF Discussion <ietf@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: secdir@ietf.org
Subject: [secdir] draft-ietf-savi-framework-05 SECDIR review
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2011 03:06:45 -0000

draft-ietf-savi-framework-05.txt

This document is a high level framework for SAVI and references a
number of other documents. As such, I think, that the Security
Considerations section is probably of adequate depth. However, there
are a number of wording problems, both clarity and grammar, that I
believe should be fixed, particularly in the Security Consideration
section (Section 10) where there is one sentence I really didn't
understand. See below.

Also, as an Information document, it cannot have Normative References
and all such should be reclassified as Informative.

  In the first sentence of the last paragraph of Section 3.1, it is a
  bit hard to tell that "single" is supposed to modify "method" rather
  ant "IP Address". I suggest replacing "each single IP address
  configuration method" with "each single method for IP address
  configuration individually". Unless, of course, I am more confused
  by this document than I think and "single" was supposed to modify
  "IP Address".

  Section 3.2, first bullet, suggest adding a reference to RFC 5342.

  Section 7, second setence has problems. Suggest replacing with "This
  document suggests 3 prefix configuration mechanisms for SAVI
  devices:".

  Section 7, first bullet, the acronym SLACC is used without
  definition or reference. Since it is only used twice, both instances
  being in this bullet, I suggest it bet spelled out in full.

  Section 7, first bullet item, what does "feasible" mean? Should "a
  feasible" by reaplced with "an allowed"?

  Section 7, second bullet item, the acronym RA is used without
  definition or reference. Since it is only used twice, both instances
  being in this bullet, I suggest it bet spelled out in full.

  Section 7, third bullet item, the acronym DHCP-PD is used without
  defintion or reference. Since it is only used twice, both instances
  being in this bullet, I suggest it bet spelled out in full (not
  "DHCP", just "PD").

  Section 7, last sentence: the word "present" seems to be used in the
  sense of displaying to someone. How and to whom is this
  presentation?

  Section 10: I was a bit befuddled by the sentence "Besides, the
  binding may not accord with the address management requirement,
  which can be more specified for each client." The word "client" is
  used nowhere else in this document. What does this sentence mean and
  to what does "client" refer?


Smaller Nits:

  People will probably figure it out but the first occurrence of
  Source Address Validation Improvement in the Introduction (and
  Abstract) should be followed by "(SAVI)".

  In the first sentence of Section 3.1, I would replace "traces" with
  "monitors" or "snoops". (The word "snoop" is used elsewhere in the
  document.)

  Section 5, third bullet, "in hosts to communicate" -> "in hosts
  communicating".

  Section 6, first paragraph, last sentence, "in mix scenario" -> "in
  this mixed scenario".

  Section 6, second paragraph, last three sentences have
  problems. Suggest "Current address assignment method standards
  documents have implied a prioritized relationship in general
  cases. However, in some scenarios, the default prioritizing may not
  be suitable. Configurable prioritization levels should be supported
  in a SAVI solution for the mixed scenario."

  Section 7, next to last sentence/paragraph, "is" -> "are" and insert
  "the" after "implies".

  Section 10, last sentence, suggest replacing with "Cryptographically
  based authentication is the only way to meet a requirement for
  strong security of IP addresses."


Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com