[secdir] SecDir review of draft-ietf-mboned-rfc3171bis-07

Tina TSOU <tena@huawei.com> Thu, 22 October 2009 06:50 UTC

Date: Thu, 22 Oct 2009 14:50:49 +0800
From: Tina TSOU <tena@huawei.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mboned-rfc3171bis@tools.ietf.org, mboned-chairs@tools.ietf.org
Message-id: <007c01ca52e3$fdd32ed0$8e27460a@china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_3QKpis9ZSmhNcMUFIlpyRA)"
References: <00d701ca51fe$2fff1630$8e27460a@china.huawei.com>
Subject: [secdir] SecDir review of draft-ietf-mboned-rfc3171bis-07
Precedence: list

Hi,
I have reviewed draft-ietf-mboned-rfc3171bis-07 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138.

1. Introduction

...
In general, due to the relatively small size of the IPv4 multicast
address space, further assignment of IPv4 multicast address space is
recommended only in limited circumstances. Specifically, the IANA
should only assign addresses in those cases where the dynamic
selection (SDP/SAP), GLOP, SSM or Administratively Scoped address
spaces cannot be used.

[Tina: Why should we emphasize the purpose of SDP/SAP here is used for dynamic selection? Should the purpose GLOP or SSM be highlighted as well?
“The dynamic selection (SDP/SAP), GLOP, SSM or Administratively scoped address space cannot be used" in the last sentence is a little bit ambiguous. Is "the dynamic selection (SDP/SAP), GLOP,SSM can not be used" identical to the description "the dynamic selection (DSP/SAP)address spaces, GLOP address spaces, SSM address space can not be used"? If yes, I am okay with the text as it was. If not, I would like suggest you to fix this ambiguous issue.]

...

3. Definition of Current Assignment Practice

...

224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block I

...

The IANA generally assigns addresses from the Local Network Control,
Internetwork Control and AD-HOC blocks. Assignment guidelines for
each of these blocks, as well as for the Source Specific Multicast,
GLOP and Administratively Scoped Blocks, are described below.

[Tina: What (65024) in the size field are denoted as? how about (251/16s)? I would like to suggest you to add some text to explain what the format of size field is?]

...

8. Source Specific Multicast Block (232/8)

The Source Specific Multicast (SSM) is an extension of IP Multicast
in which traffic is forwarded to receivers from only those multicast
sources for which the receivers have explicitly expressed interest,
and is primarily targeted at one-to-many (broadcast) applications.
Note that this block was initially assigned to the VMTP transient
groups [IANA].

[Tina: Would you like to provide some reference to SSM? What are VMTP transient groups? How is it related to IPv4 multicast addresses?]

...

9. GLOP Block (233/8)

Addresses in the GLOP block are globally scoped statically assigned
addresses. The assignment is made, for a domain with 16 bit
Autonomous System Number (ASN), by mapping a domain's autonomous
system number, expressed in octets as X.Y, into the middle two octets
of the GLOP block, yielding an assignment of 233.X.Y.0/24. The
mapping and assignment is defined in [RFC3180]. Domains with 32 bit
ASN should apply for space in AD-HOC Block III, or consider using
IPv6 multicast addresses.

[Tina: Is it better to replace the *should* in the last sentence of section 9 with *MAY*?]

B. R.
Tina
http://tinatsou.weebly.com/contact.html

[secdir] SecDir re-check of draft-ietf-syslog-sig… Tina TSOU
[secdir] SecDir review of draft-ietf-mboned-rfc31… Tina TSOU