Last Call Review of draft-ietf-mboned-rfc3171bis-
review-ietf-mboned-rfc3171bis-secdir-lc-tsou-2009-10-22-00

Request Review of draft-ietf-mboned-rfc3171bis
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-11-05
Requested 2009-10-16
Other Reviews
Review State Completed
Reviewer Tina Tsou
Review review-ietf-mboned-rfc3171bis-secdir-lc-tsou-2009-10-22
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg01184.html
Draft last updated 2009-10-22
Review completed: 2009-10-22

Review
review-ietf-mboned-rfc3171bis-secdir-lc-tsou-2009-10-22



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