Subject: mboned: WGLC for draft-ietf-mboned-addrarch-02.txt

From: David Meyer <[email-masked]>
Date: Fri, 23 Sep 2005 09:30:37 -0700

Folks

	This note starts the Working Group Last Call (WGLC) for
	comments on draft-ietf-mboned-addrarch-02.txt, "Overview
	of the Internet Multicast Addressing Architecture". It
	can be found on  
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-addrarch-02.txt

	The document's proposed status is Informational.

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG.  

	This WGLC will end on 07 Oct 2005 at 1400 PDT (UTC/GMT-7).

	Thanks,

	Dave

---

From: John Kristoff <[email-masked]>
Date: Fri, 23 Sep 2005 14:43:46 -0500

On Fri, 23 Sep 2005 09:30:37 -0700

> 	not you believe that this document is ready to go to the

I don't see any major problems with the content.  Personally I'd
be interested in seeing something more focused on the history of
all the proposed solutions and an analysis of where they have
succeeded and where they have failed, but perhaps that is something
better for a research-oriented paper.  For example, it would be
helpful to understand more about the reasons, at least for me
since I don't know, for MADCAP's failure.

There are lots of instances of the text "Unicast-prefix -based"
throughout the document.  Not sure if the space was intended.

  It is important to note that Source-specific Multicast (SSM)
  [I-D.ietf-ssm-arch] does not have these addressing problems; hence,
  this document focuses on Any Source Multicast (ASM) model.

Insert a "the" before "Any Source Multicast".

  A minor operational debugging issue with GLOP addresses is that the
  connection between the AS and the prefix is not apparent from the
  prefix, but has to be calculated (e.g., from [RFC3180], AS 5662 maps
  to 233.22.30.0/24).

Insert "when the ASN is greater than 255" after "from the prefix,".

  Topologies which act under a single administration can easily use the
  scoped multicast addresses for their internal groups.  Groups which
  need to be shared between multiple routing domains (but not
  propagated through Internet) are more problematic and typically need
  an assignment of a global multicast address because their scope is
  undefined.

Insert a "the" before "Internet".

  There is a large number of multicast applications (such as "Norton
  Ghost") which are restricted either to a link or a site, but it is
  extremely undesirable to propagate them further (either to the rest
  of the site, or beyond the site).

Change the "but" to "and".

  of the site, or beyond the site).  Typically many such applications
  have been given a static IANA address assignment; this makes it
  challenging to implement proper propagation limiting -- which could
  be easier if such applications could have been assigned specific
  scope-relative addresses instead.  This is an area of further future

Add "or have hijacked" after "have been given".  Feel free to use a
gentler term if appropriate, but that's how I feel about it.  :-)

  There has also been work on protocol to automatically discover
  multicast scope zones [RFC2776], but it has never been seriously
  implemented or deployed.

Add "a" before "protocol" and change "seriously" to "widely".

  addresses).  However, this is a bad approach architecturally, as we
  should focus on enhancing and deploying service discovery and address
  assignment (as needed) instead of encouraging a "land-grab" of
  multicast addresses.

I don't particularly like the "we should focus" part.  I don't think
this document should dictate what solution should be worked and I'm
not sure I agree with the sentiment in any case.  I would probably
reword as follows:

  However, there is a scaling problem with this approach
  architecturally, as it encourages a "land-grab" of the limited
  multicast address space.

Then change the following:

  In summary, there are applications which have obtained a static IANA
  assignment, some of which are really needed, and some of which
  probably should not have been granted.

to:

  In summary, there are applications which have obtained a static IANA
  assignment and while some of which are really needed, some of which
  probably should not have been granted.  Conversely, there are some
  applications that have not obtained a static IANA assignment, yet
  should requested an assignment and been granted one.

The following:

  o  Static IANA allocations are an architecturally unacceptable
     approach.

I don't think is unconditionally true so I would add "generally" after
"are".

  o  Dynamic assignment, e.g., using MADCAP have been implemented, but
     there is no wide deployment, so a solution is there.  However,

Strike "using" and replace "have" with "has".

John
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/