I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Grüße, Carsten
---------------------------------

Document: draft-ietf-mboned-64-multicast-address-format-01
Title: IPv4-Embedded IPv6 Multicast Address Format
Reviewer: Carsten Bormann
Review Date: 2012-05-06
IETF Last Call Date: 2012-04-19

** Summary: This draft is NOT ready for publication as a Proposed
Standard and should be revised before publication.

The document appears as an attempt to extend the reasoning of RFC 6052
to multicast IPv4 addresses.  However, while unicast IPv4 addresses
and their IPv6 counterparts are assigned as part of network
configuration, multicast addresses are decided upon by applications.
The document is very short on information how an application should
decide when to make use of the newly defined formats.  It is therefore
also hard to understand why these formats are needed in the first
place.  There appears to be a transition model in the minds of the
authors that makes this necessary or practical, and this information
must be made part of the document for it to be useful.

** Major Issues:

To continue the summary: I don't understand which network elements
need to be able to determine, by looking at an IP address, that this
document is in use.  What for?  More generally, which entities need to
interoperate based on a common understanding of this format?

Of the various fields left "configurable according to local policies
of the entity managing the IPv4-IPv6 Interconnection Function", which
are important for applications?  How do they know these policies?  If
that information is all in the two parameters "ASM_MPREFIX64" and
"SSM_MPREFIX64", what is the protocol that will be used to make this
information available to applications?  I don't think this can be a
standards-track document without defining at least one MTI protocol
for disseminating this information.  What is an implementation
supposed to do that receives an address that looks like it is governed
by this document but does not conform to either of the agreed
prefixes disseminated to the implementation?

This document needs editorial attention.  I will abstain from trying
to make detailed corrections, as this would become tedious quickly.
While much of this work could be done by the RFC editor, some of the
editorial decisions will enter e.g. IANA registries, so the technical
terms need to be decided now.  More importantly, understanding this
document during its development process (including mine as a reviewer)
may be hampered by its editorial shortcomings.

** Minor Issues:

My first editorial problem is with the title.  This address format is
not embedded in IPv4, as the title wants to make us believe.  Instead,
it is talking about an multicast address format for IPv6 that embeds
an IPv4 multicast address.  (While this misleading naming repeats the
same mistake that has been made in RFC 6052, at least there it is not
part of the title.)

3

The role of 64IX is very unclear.  My conjecture is that this draft is
defining the address format for the case M=1 only (i.e., address[16] =
1).  No text defines what happens for M=0, so the assumption appears
to be that RFC 4291 applies unchanged in this case.  If this
conjecture is correct, this needs to be made much clearer.

What is "r"?  Define.

4

Why is 64IX moving around here?
(The discriminating bit M now seems to be address[32].)
How does one find out which of the two positions of the M bit to use?

.          o  sub-group-id: The default value is all zeros.
How does an application find out when to choose a different one?

.             232.0.0.1-232.0.0.255 range is being
.             reserved to IANA.
Who is making this reservation?  ("is being reserved" means the
resernation is going on right now, but I don't find anything in 9.)

7

7 seems to imply this format is only useful where RFC 6052 is in use.
If this is true, this should be clearly stated.  More specifically,
the assumption appears to be that all nodes that need to exchange
information that concerns IPv4 sources need to have the same RFC 6052
parameters in effect.  How is that ensured?

** Nits:

10 -- s/defined/defines/

(And many more, see above.)