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.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------