[Gen-art] Gen-ART Review: draft-ietf-mboned-addrarch-07.txt

Mary Barnes <mary.ietf.barnes@gmail.com> Thu, 07 April 2011 21:33 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6A5283A69E2 for <gen-art@core3.amsl.com>; Thu, 7 Apr 2011 14:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.359
X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id suX5VEyvqWKo for <gen-art@core3.amsl.com>; Thu, 7 Apr 2011 14:33:29 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id F09E43A69D4 for <gen-art@ietf.org>; Thu, 7 Apr 2011 14:33:28 -0700 (PDT)
Received: by vws12 with SMTP id 12so2790704vws.31 for <gen-art@ietf.org>; Thu, 07 Apr 2011 14:35:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=sEDO2YmGSxf8fEW24lgLALfe7V55qWv455dHnyn26vE=; b=d2FI4eszfHuoGJeJPfevB0Ez8L5sb/Vt9Mhh6ZSzdpd7Zm8qLeCTuCa1aFU2tlgpAs 1yJi59OXLXq0IC73d5rkTvFCgFzrL9Q7eSZXCovjZN68RLll4ogIYhQGR01DHUkOFVOq Rx4u3774oqGdJ5K0t3LbuZrCxJrKGJk8n14x8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=W/lYY5GjUKLzcgQVaXVcjb5gKVh21EPheDbPnTeY8r03O6OiGSO5xAOtV00ZvjvBKU qNphduSar049bahSnuU31oX9eh5Ewz/YvYOs+Sc7X6voV0OvmcVGmcUGt4lzDvrvx18S uKETBQ7EO4ka+xbIxYfw47MFHjrKfDMCJJxwk=
MIME-Version: 1.0
Received: by with SMTP id r2mr1981206vdv.263.1302212113428; Thu, 07 Apr 2011 14:35:13 -0700 (PDT)
Received: by with HTTP; Thu, 7 Apr 2011 14:35:13 -0700 (PDT)
Date: Thu, 7 Apr 2011 16:35:13 -0500
Message-ID: <BANLkTik35DGAHdpPJc1gkN3XOfdc_9YYfg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: draft-ietf-mboned-addrarch.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=bcaec5016627716f7004a05ae2e7
Cc: gen-art@ietf.org
Subject: [Gen-art] Gen-ART Review: draft-ietf-mboned-addrarch-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 21:33:30 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-mboned-addrarch-07.txt
Reviewer:  Mary Barnes
Review Date:  07 April 2011
IETF LC End Date:  28 March 2011

Summary:  Ready with minor issues.

Minor issues:

- Introduction, 3rd paragraph notes that this document only deals with the
ASM model, yet the 2nd paragraph in section 2 notes that the address
assignment inside the node for SSM is discussed.   I would suggest to reword
the 3rd paragraph in section 1 and it seems that the 2nd paragraph is
section 2 is redundant.

- Section 7, 1st paragraph notes that "the security analysis of the
mentioned protocols is out of scope of this memo". However, the next
paragraph notes that "the dynamic assignment protocol are inherently
vulnerable…".  Thus, I would suggest changing the first paragraph to
something like the following (and removing 2nd):
   This memo only describes the approaches to allocating and
   assigning multicast addresses for existing protocols and thus
   adds no additional security considerations beyond those
   specified for the referenced protocols. Additional security
   analysis of these protocols is outside the scope of this
   document. Although, it should be noted the dynamic assignment
   protocols are inherently vulnerable to resource exhaustion attacks
   as discussed in [RFC2730].

In addition, if the intention was to highlight a security issue that should
be resolved, then perhaps adding another bullet to section 4.3 would be
   Obviously, especially the dynamic assignment protocols are inherently
   vulnerable to resource exhaustion attacks, as discussed e.g., in

Nits/editorial comments:
- Section 2, "as described below" might be better worded as "as described in
subsequent sections", although I think it would make the document more
readable to summarize the mechanisms in a bulleted list and add section

- Section 3 - same comment as for section 2.