Dear Carsten, Thank you for the review.
Please see inline. Cheers, Med >-----Message d'origine----- >De : Carsten Bormann [mailto:c...@tzi.org] >Envoyé : dimanche 6 mai 2012 22:58 >À : >draft-ietf-mboned-64-multicast-address-format....@tools.ietf.or >g; apps-disc...@ietf.org application-layer protocols >Cc : The IESG; 6...@ietf.org; mbo...@ietf.org >Objet : APPSDIR review of >draft-ietf-mboned-64-multicast-address-format-01 > >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/ApplicationsAreaD >irectorate >). > >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. Med: There are plenty of applications using this address format: e.g., [I-D.ietf-softwire-mesh-multicast], [I-D.ietf-softwire-dslite-multicast], [I-D.ietf-softwire-multicast-prefix-option], [I-D.venaas-behave-v4v6mc-framework], [I-D.sarikaya-behave-netext-nat64-pmip], [I-D.sarikaya-behave-mext-nat64-dsmip], etc. We had pointers to some of those drafts in earlier versions of the document but we removed them and adopted the same approach as RFC6052: only the address format is defined while the usage is defined in companion documents. More details are also documented here: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.1 and http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2. There is also a problem statement, available at: http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03 which can be cited in the introduction. > >** 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? Med: Elements which make use of the address format are deployment-specific; this can be a receiver, an IPv4-IPv6 PIM interworking function, IGMP/MLD Interworking function. We didn't quoted these interworking functions because this is deployment-specific. Do you think your issue can be solved if we add a pointer to one of the solutions documented listed above? > >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? Med: The content of this filed is left configurable. Its value will depend on the policies enforced by the administrative entity. Examples of these policies are: embedded-RF, use unicast-based prefix, etc. Applications are not aware of these policies since a prefix will (likely /96) will be provisioned (see Section 6). 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. Med: The provisioning of the ASM_PREFIX64 and the SSM_PREFIX is orthogonal to the address format itself. Various methods can be used but this is out of scope of the document. We can add a pointer to http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 as a provisioning example. Would you be fine with adding such reference? 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? Med: This is an issue for the provisioning method and not for the specification of the address format itself. > >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.) Med: Could you please suggest a better 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. Med: The current text says: "When "M-bit" is set to 1, it indicates that a multicast IPv4 address is embedded in the low-order 32 bits of the multicast IPv6 address.". I can add: "When "M-bit" is set to 0, the address format follows [RFC4291].". Would this be fine with you? > >What is "r"? Define. Med: This means "reserved". The text says: "All the remaining bits are reserved and MUST be set to 0.". Do you think the text should be clarified further? > >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? Med: Once the prefix is configured to a receiver, an IPv4-IPv6 PIM interworking function, the question of the location of the M-bit is not relevant anymore. If both ASM and SSM modes are supported, two prefixes will be used. > >. o sub-group-id: The default value is all zeros. >How does an application find out when to choose a different one? Med: Applications are provisioned with the full prefix; see Section 6. > >. 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.) Med: We removed that sentence as a result of a comment I received from SM (see mboned archives). > >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? Med: This is a generic issue for RFC6052. We can document the issue if it is specific to the multicast context. > >** Nits: > >10 -- s/defined/defines/ Med: Fixed. Thanks. > >(And many more, see above.) > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
