[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

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
Date: Thu, 07 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
Precedence: list

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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
appropriate.
   Obviously, especially the dynamic assignment protocols are inherently
   vulnerable to resource exhaustion attacks, as discussed e.g., in
   [RFC2730].

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
references.

- Section 3 - same comment as for section 2.

[Gen-art] Gen-ART Review: draft-ietf-mboned-addra… Mary Barnes